From aland@deployingradius.com Tue Nov 1 02:16:04 2011 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 9B73521F8E7E for ; Tue, 1 Nov 2011 02:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.323 X-Spam-Level: X-Spam-Status: No, score=-102.323 tagged_above=-999 required=5 tests=[AWL=0.276, 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 fRNCUoB6qAt7 for ; Tue, 1 Nov 2011 02:15:59 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id DA65721F8E7D for ; Tue, 1 Nov 2011 02:15:55 -0700 (PDT) Message-ID: <4EAFB88B.4000108@deployingradius.com> Date: Tue, 01 Nov 2011 10:14:51 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <4E64DD35.4030306@deployingradius.com> <94DBA75C-3D10-4487-8C56-303901E55704@gmail.com> <4EA710E3.7010206@deployingradius.com> <4EAAA2A9.9050708@deployingradius.com> <4EABA20C.6000901@deployingradius.com> <4EABE2EF.3040803@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" Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-01 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, 01 Nov 2011 09:16:04 -0000 Leaf yeh wrote: > One more editorial on the title of the draft, remember someone express the same in the ML, I just repeat it here. That was me. > 'Remote Authentication Dial In User Service (RADIUS) Protocol Extensions ' > > But RFC2869 has the title of 'RADIUS Extensions'. They looks very similarly. Yes. > How about to re-title your draft? My suggesting might be 'RADIUS Extension Plus on the Type Space of Attributes with more Data Types', just for your reference. That's a little long. I welcome suggestions. Maybe "RADIUS Data Types and Type Code Additions" > ---------------------------------------------------------- > One more argument on the text in section 9.1 > > 'New allocations are > normally taken from the Extended Type space, starting with lower > numbered attributes.' > > But the attributes, including > > 241.26 Extended-Vendor-Specific-1 > 242.26 Extended-Vendor-Specific-2 > 243.26 Extended-Vendor-Specific-3 > 244.26 Extended-Vendor-Specific-4 > 245.26 Extended-Vendor-Specific-5 > 246.26 Extended-Vendor-Specific-6 > > seem not follow the above words. Yes. Those are allocated simply for consistency with the current type space. 26 is Vendor-Specific, and there is some benefit in re-using it here, so that people don't have to remember a *new* number for Vendor-Specific extended attributes. > Could it let to be decided by IANA? IANA follows guidelines set by others. They don't set guidelines themselves. Alan DeKok. From radext-bounces@ietf.org Tue Nov 1 02:16:06 2011 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 ECDB821F8E7E; Tue, 1 Nov 2011 02:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320138965; bh=EgBBQF55BvB9YVleJfpWpD+d85hVKiqsfAOIkDxR87g=; 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=kMm7sLRZi+PxfkPGueoYxL4d1ZBGXJ+5zR5HRf96WtFE3yZABERy039yl3Itx8QAr GvJwE34q2nEZQ0zJTixYeXEZmHfISelSIQif/Qh2gJsEbJgafVYdGuKcz/zV9s6+tW UL+qZpaAeHk7NF1SvuA2jtRWcE5XAuK3SEU9jn2w= 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 9B73521F8E7E for ; Tue, 1 Nov 2011 02:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.323 X-Spam-Level: X-Spam-Status: No, score=-102.323 tagged_above=-999 required=5 tests=[AWL=0.276, 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 fRNCUoB6qAt7 for ; Tue, 1 Nov 2011 02:15:59 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id DA65721F8E7D for ; Tue, 1 Nov 2011 02:15:55 -0700 (PDT) Message-ID: <4EAFB88B.4000108@deployingradius.com> Date: Tue, 01 Nov 2011 10:14:51 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <4E64DD35.4030306@deployingradius.com> <94DBA75C-3D10-4487-8C56-303901E55704@gmail.com> <4EA710E3.7010206@deployingradius.com> <4EAAA2A9.9050708@deployingradius.com> <4EABA20C.6000901@deployingradius.com> <4EABE2EF.3040803@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-01 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: > One more editorial on the title of the draft, remember someone express the same in the ML, I just repeat it here. That was me. > 'Remote Authentication Dial In User Service (RADIUS) Protocol Extensions ' > > But RFC2869 has the title of 'RADIUS Extensions'. They looks very similarly. Yes. > How about to re-title your draft? My suggesting might be 'RADIUS Extension Plus on the Type Space of Attributes with more Data Types', just for your reference. That's a little long. I welcome suggestions. Maybe "RADIUS Data Types and Type Code Additions" > ---------------------------------------------------------- > One more argument on the text in section 9.1 > > 'New allocations are > normally taken from the Extended Type space, starting with lower > numbered attributes.' > > But the attributes, including > > 241.26 Extended-Vendor-Specific-1 > 242.26 Extended-Vendor-Specific-2 > 243.26 Extended-Vendor-Specific-3 > 244.26 Extended-Vendor-Specific-4 > 245.26 Extended-Vendor-Specific-5 > 246.26 Extended-Vendor-Specific-6 > > seem not follow the above words. Yes. Those are allocated simply for consistency with the current type space. 26 is Vendor-Specific, and there is some benefit in re-using it here, so that people don't have to remember a *new* number for Vendor-Specific extended attributes. > Could it let to be decided by IANA? IANA follows guidelines set by others. They don't set guidelines themselves. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Tue Nov 1 02:30:38 2011 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 B04ED21F8F32 for ; Tue, 1 Nov 2011 02:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.358 X-Spam-Level: X-Spam-Status: No, score=-102.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 cUOV9rHKzlpB for ; Tue, 1 Nov 2011 02:30:38 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 1F61E21F8F33 for ; Tue, 1 Nov 2011 02:30:38 -0700 (PDT) Message-ID: <4EAFBC28.40902@deployingradius.com> Date: Tue, 01 Nov 2011 10:30:16 +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" Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-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: Tue, 01 Nov 2011 09:30:38 -0000 Leaf yeh wrote: > Dear Group, > > 1. draft-yeh-radext-ext-traffic-statistics-01 is ready for your comment on whether it deserves a WG item at RADEXT. > > 2. It defined 8 new attributes of traffic statistics for the separate IPv4 & IPv6 stack (queue or counter), and employed the new date type of integer64, but the format of new attributes might be still a question now. It has 2 options now: a. the traditional format defined in [RFC2865]; b. the new extended format defined in [draft-ietf-radext-radius-extensions-02]. Looking at the names of the new attributes: Acct-Input-IPv4-Octets Acct-Output-IPv4-Octets Acct-Input-IPv4-Packets Acct-Output-IPv4-Packets Acct-Input-IPv6-Octets Acct-Output-IPv6-Octets Acct-Input-IPv6-Packets Acct-Output-IPv6-Packets They're of the form: Acct- Input/Output - IPv4/IPv6 - Packets/Octets This looks like a good case for grouping by type, which means TLVs. If you use the new format, TLVs would be preferred to using a "flat" name space, and allocating 8 attributes from that space. One option would be to define two attributes: "Acct-Input-Stats" and Acct-Output-Stats". They could be > 252 octets long, and contain TLVs. They could share the same set of sub-TLVs. The sub-TLVs could be: Acct-IPv4-Stats for IPv4 data Acct-IPv6-Stats for IPv6 data Those sub-TLVs in turn could contain: Acct-Packet-Stats Acct-Octet-Stats The Acct-Input-IPv4-Octets attribute you define would then map to: Acct-Input-Stats ( Acct-IP4-Stats ( Acct-Packet-Stats (value))) This uses more space in the packet, but is more general. Other specifications could add TCP stats, UDP stats, etc. You mention draft-winter-radext-fancyaccounting-00. I haven't compared the two documents in detail, but I'd like to know what overlap (if any) exists between them. Having the WG converge on one proposal would be a good thing. Alan DeKok. From radext-bounces@ietf.org Tue Nov 1 02:30:40 2011 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 27EE821F8F21; Tue, 1 Nov 2011 02:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320139840; bh=vjEwsUDsuTQX6kzbgx/p1uJI9lrIxlNslm/okzN3uEM=; 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=V96UldLbsNmCEXczFBk8yTd9FrtoTzhSRgnFW1SubWFhIySi17vZUX07yd80tMNqP Ng0ejKI08EIxA78rbPOf4XOGuEEWLeWYjP1zosFcPfDHWdndRd5jri3M1nJ1ZYDNPq LtMUdMquFudAgUqwC2G51iWqvN0gazKopb3/vi2c= 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 B04ED21F8F32 for ; Tue, 1 Nov 2011 02:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.358 X-Spam-Level: X-Spam-Status: No, score=-102.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 cUOV9rHKzlpB for ; Tue, 1 Nov 2011 02:30:38 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 1F61E21F8F33 for ; Tue, 1 Nov 2011 02:30:38 -0700 (PDT) Message-ID: <4EAFBC28.40902@deployingradius.com> Date: Tue, 01 Nov 2011 10:30:16 +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" Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Leaf yeh wrote: > Dear Group, > > 1. draft-yeh-radext-ext-traffic-statistics-01 is ready for your comment on whether it deserves a WG item at RADEXT. > > 2. It defined 8 new attributes of traffic statistics for the separate IPv4 & IPv6 stack (queue or counter), and employed the new date type of integer64, but the format of new attributes might be still a question now. It has 2 options now: a. the traditional format defined in [RFC2865]; b. the new extended format defined in [draft-ietf-radext-radius-extensions-02]. Looking at the names of the new attributes: Acct-Input-IPv4-Octets Acct-Output-IPv4-Octets Acct-Input-IPv4-Packets Acct-Output-IPv4-Packets Acct-Input-IPv6-Octets Acct-Output-IPv6-Octets Acct-Input-IPv6-Packets Acct-Output-IPv6-Packets They're of the form: Acct- Input/Output - IPv4/IPv6 - Packets/Octets This looks like a good case for grouping by type, which means TLVs. If you use the new format, TLVs would be preferred to using a "flat" name space, and allocating 8 attributes from that space. One option would be to define two attributes: "Acct-Input-Stats" and Acct-Output-Stats". They could be > 252 octets long, and contain TLVs. They could share the same set of sub-TLVs. The sub-TLVs could be: Acct-IPv4-Stats for IPv4 data Acct-IPv6-Stats for IPv6 data Those sub-TLVs in turn could contain: Acct-Packet-Stats Acct-Octet-Stats The Acct-Input-IPv4-Octets attribute you define would then map to: Acct-Input-Stats ( Acct-IP4-Stats ( Acct-Packet-Stats (value))) This uses more space in the packet, but is more general. Other specifications could add TCP stats, UDP stats, etc. You mention draft-winter-radext-fancyaccounting-00. I haven't compared the two documents in detail, but I'd like to know what overlap (if any) exists between them. Having the WG converge on one proposal would be a good thing. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From dromasca@avaya.com Tue Nov 1 06:28:37 2011 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 C4DE611E8180 for ; Tue, 1 Nov 2011 06:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.326 X-Spam-Level: X-Spam-Status: No, score=-103.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiUGBkn5lTbe for ; Tue, 1 Nov 2011 06:28:37 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0E64511E8171 for ; Tue, 1 Nov 2011 06:28:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoBAF3zr07GmAcF/2dsb2JhbABCmWdDjxCBBYFyAQEBAQMBAQEPHgo0FwYBCA0EBAEBCwYMCwEHJh8HAQEFBAEEEwgBGYdolRSEEpteiCZhBJlbjBQ X-IronPort-AV: E=Sophos;i="4.69,438,1315195200"; d="scan'208";a="275425764" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Nov 2011 09:28:35 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Nov 2011 09:26:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Nov 2011 14:28:33 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt thread-index: AcyYJvS+zXVkHIIdTGao0iNygFqKAgAcsvlA From: "Romascanu, Dan (Dan)" To: Subject: [radext] FW: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.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, 01 Nov 2011 13:28:37 -0000 FYI. Dan -----Original Message----- From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Tuesday, November 01, 2011 1:44 AM To: i-d-announce@ietf.org Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF. Title : A RADIUS Attribute, Binding and Profiles for SAML Author(s) : Josh Howlett Sam Hartman Filename : draft-ietf-abfab-aaa-saml-02.txt Pages : 14 Date : 2011-10-31 This document specifies a RADIUS attribute, binding and two profiles for the Security Assertion Mark-up Language (SAML). The attribute provides RADIUS encapsulation of SAML protocol messages, while the binding describes the transport of this attribute, and the SAML protocol messages within, using RADIUS. The profiles describe the application of this binding for Abfab authentication and assertion query/request. The SAML RADIUS attribute and binding are defined generically to permit application in other scenarios, such as network access. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-02.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-abfab-aaa-saml-02.txt _______________________________________________ abfab mailing list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab From radext-bounces@ietf.org Tue Nov 1 06:28:38 2011 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 4DF5911E8180; Tue, 1 Nov 2011 06:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320154118; bh=wsL7qgMBmAa7V77KirRyhgzXZSY7l549Uoqfo2xD6Qk=; h=MIME-Version:Date:Message-ID:From:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=IbZLbZCrcCN8/wlQYoEjhNulYGIIYdT7yOshBIBz/z6EiN80e8RS+sTlB9DYgBCEp zYehw/D2pt+QzdQ1SDDdCGp0PH1p3EbyVLFGKkRNNtif2bfmeLpJm8c8DMJx0Ns7T0 LKbgpaqknBHe28MFFAhy9l4NI0MJpfSEY09cA9wA= 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 C4DE611E8180 for ; Tue, 1 Nov 2011 06:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.326 X-Spam-Level: X-Spam-Status: No, score=-103.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiUGBkn5lTbe for ; Tue, 1 Nov 2011 06:28:37 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0E64511E8171 for ; Tue, 1 Nov 2011 06:28:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoBAF3zr07GmAcF/2dsb2JhbABCmWdDjxCBBYFyAQEBAQMBAQEPHgo0FwYBCA0EBAEBCwYMCwEHJh8HAQEFBAEEEwgBGYdolRSEEpteiCZhBJlbjBQ X-IronPort-AV: E=Sophos;i="4.69,438,1315195200"; d="scan'208";a="275425764" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Nov 2011 09:28:35 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Nov 2011 09:26:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Nov 2011 14:28:33 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt thread-index: AcyYJvS+zXVkHIIdTGao0iNygFqKAgAcsvlA From: "Romascanu, Dan (Dan)" To: Subject: [radext] FW: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.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 FYI. Dan -----Original Message----- From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Tuesday, November 01, 2011 1:44 AM To: i-d-announce@ietf.org Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF. Title : A RADIUS Attribute, Binding and Profiles for SAML Author(s) : Josh Howlett Sam Hartman Filename : draft-ietf-abfab-aaa-saml-02.txt Pages : 14 Date : 2011-10-31 This document specifies a RADIUS attribute, binding and two profiles for the Security Assertion Mark-up Language (SAML). The attribute provides RADIUS encapsulation of SAML protocol messages, while the binding describes the transport of this attribute, and the SAML protocol messages within, using RADIUS. The profiles describe the application of this binding for Abfab authentication and assertion query/request. The SAML RADIUS attribute and binding are defined generically to permit application in other scenarios, such as network access. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-02.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-abfab-aaa-saml-02.txt _______________________________________________ abfab mailing list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Tue Nov 1 15:28:52 2011 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 6757211E812B; Tue, 1 Nov 2011 15:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320186532; bh=UdGslIuDIHJxESz8zMGsvd2N7JrJ6ChupZn8O2IKnR4=; 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=aIoAPGy0AsnV0X8TBtrNNXAdd3lz53hbb7xpUxiunzT1Gn+uB49uUkmxXLv3JqOvj 8iUN0lrx4GMEXffbGsVIt6v992SnRiwX3XjTpHV+AGz3y+QwYLuZ0KQGMVWxk7hlGU 1E7+A8Bzxgs88p/1ccBjqu5xfpinWmh2L+tJkLYg= 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 3FCA611E812D for ; Tue, 1 Nov 2011 15:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.411 X-Spam-Level: X-Spam-Status: No, score=-102.411 tagged_above=-999 required=5 tests=[AWL=0.187, 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 JfKIb-t6b2Wz for ; Tue, 1 Nov 2011 15:28:50 -0700 (PDT) Received: from blu0-omc3-s33.blu0.hotmail.com (blu0-omc3-s33.blu0.hotmail.com [65.55.116.108]) by ietfa.amsl.com (Postfix) with ESMTP id 58C7E11E8128 for ; Tue, 1 Nov 2011 15:28:50 -0700 (PDT) Received: from BLU152-W34 ([65.55.116.72]) by blu0-omc3-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Nov 2011 15:28:49 -0700 Message-ID: X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: "dromasca@avaya.com" , Date: Tue, 1 Nov 2011 15:28:49 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 01 Nov 2011 22:28:49.0848 (UTC) FILETIME=[A0BB8B80:01CC98E5] Subject: Re: [radext] RFC 4282 and RADIUS implementations (was abfab and SAML) 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="===============8481533865568840569==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============8481533865568840569== Content-Type: multipart/alternative; boundary="_ba2e4557-7e6c-4fd0-b565-849f2560d0d3_" --_ba2e4557-7e6c-4fd0-b565-849f2560d0d3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This document includes a requirement for encoding of the NAI as per RFC 428= 2.=20 Today=2C RADIUS implementations do not convert U-labels within the domain-p= ortion of the NAI to A-labels=2C because the User-Name attribute is 8-bit c= lean and designed to handle UTF-8=2C as described within RFC 2865=2C Sectio= n 5.1. As a result=2C RFC 4282 doesn't really apply to RADIUS=2C and mentioning th= at with respect to User-Name encoding is potentially confusing (and could c= reate an interoperability problem that doesn't exist today).=20 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Tuesday=2C November 01=2C 2011 1:44 AM > To: i-d-announce@ietf.org > Cc: abfab@ietf.org > Subject: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Application Bridging for > Federated Access Beyond web Working Group of the IETF. >=20 > Title : A RADIUS Attribute=2C Binding and Profiles for > SAML > Author(s) : Josh Howlett > Sam Hartman > Filename : draft-ietf-abfab-aaa-saml-02.txt > Pages : 14 > Date : 2011-10-31 >=20 > This document specifies a RADIUS attribute=2C binding and two profiles > for the Security Assertion Mark-up Language (SAML). The attribute > provides RADIUS encapsulation of SAML protocol messages=2C while the > binding describes the transport of this attribute=2C and the SAML > protocol messages within=2C using RADIUS. The profiles describe the > application of this binding for Abfab authentication and assertion > query/request. The SAML RADIUS attribute and binding are defined > generically to permit application in other scenarios=2C such as networ= k > access. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-02.txt > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext = --_ba2e4557-7e6c-4fd0-b565-849f2560d0d3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This document includes a requirement for encoding of the NAI as per RFC 428= 2.

Today=2C RADIUS implementations do not convert U-labels within t= he domain-portion of the NAI to A-labels=2C because the User-Name attribute= is 8-bit clean and designed to handle UTF-8=2C as described within RFC 286= 5=2C Section 5.1.

As a result=2C RFC 4282 doesn't really apply to RA= DIUS=2C and mentioning that with respect to User-Name encoding is potential= ly confusing (and could create an interoperability problem that doesn't exi= st today).





>=3B -----Original Message----->=3B From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Be= half
>=3B Of internet-drafts@ietf.org
>=3B Sent: Tuesday=2C Novem= ber 01=2C 2011 1:44 AM
>=3B To: i-d-announce@ietf.org
>=3B Cc: ab= fab@ietf.org
>=3B Subject: [abfab] I-D Action: draft-ietf-abfab-aaa-sa= ml-02.txt
>=3B
>=3B A New Internet-Draft is available from the o= n-line Internet-Drafts
>=3B directories. This draft is a work item of = the Application Bridging for
>=3B Federated Access Beyond web Working = Group of the IETF.
>=3B
>=3B Title : A RADIUS Attribu= te=2C Binding and Profiles for
>=3B SAML
>=3B Author(s) : = Josh Howlett
>=3B Sam Hartman
>=3B Fil= ename : draft-ietf-abfab-aaa-saml-02.txt
>=3B Pages = : 14
>=3B Date : 2011-10-31
>=3B
>=3B This d= ocument specifies a RADIUS attribute=2C binding and two profiles
>=3B = for the Security Assertion Mark-up Language (SAML). The attribute
&g= t=3B provides RADIUS encapsulation of SAML protocol messages=2C while th= e
>=3B binding describes the transport of this attribute=2C and the= SAML
>=3B protocol messages within=2C using RADIUS. The profiles = describe the
>=3B application of this binding for Abfab authenticat= ion and assertion
>=3B query/request. The SAML RADIUS attribute an= d binding are defined
>=3B generically to permit application in oth= er scenarios=2C such as network
>=3B access.
>=3B
>=3B <= br>>=3B A URL for this Internet-Draft is:
>=3B http://www.ietf.org/i= nternet-drafts/draft-ietf-abfab-aaa-saml-02.txt
>=3B
>=3B Intern= et-Drafts are also available by anonymous FTP at:
>=3B ftp://ftp.ietf.= org/internet-drafts/
>=3B
>=3B This Internet-Draft can be retrie= ved at:
>=3B ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-aaa-s= aml-02.txt
>=3B _______________________________________________
>= =3B abfab mailing list
>=3B abfab@ietf.org
>=3B https://www.ietf.= org/mailman/listinfo/abfab
>=3B ______________________________________= _________
>=3B radext mailing list
>=3B radext@ietf.org
>=3B= https://www.ietf.org/mailman/listinfo/radext
= --_ba2e4557-7e6c-4fd0-b565-849f2560d0d3_-- --===============8481533865568840569== 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 --===============8481533865568840569==-- From bernard_aboba@hotmail.com Tue Nov 1 15:28:51 2011 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 3FCA611E812D for ; Tue, 1 Nov 2011 15:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.411 X-Spam-Level: X-Spam-Status: No, score=-102.411 tagged_above=-999 required=5 tests=[AWL=0.187, 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 JfKIb-t6b2Wz for ; Tue, 1 Nov 2011 15:28:50 -0700 (PDT) Received: from blu0-omc3-s33.blu0.hotmail.com (blu0-omc3-s33.blu0.hotmail.com [65.55.116.108]) by ietfa.amsl.com (Postfix) with ESMTP id 58C7E11E8128 for ; Tue, 1 Nov 2011 15:28:50 -0700 (PDT) Received: from BLU152-W34 ([65.55.116.72]) by blu0-omc3-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Nov 2011 15:28:49 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_ba2e4557-7e6c-4fd0-b565-849f2560d0d3_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: "dromasca@avaya.com" , Date: Tue, 1 Nov 2011 15:28:49 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 01 Nov 2011 22:28:49.0848 (UTC) FILETIME=[A0BB8B80:01CC98E5] Subject: Re: [radext] RFC 4282 and RADIUS implementations (was abfab and SAML) 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, 01 Nov 2011 22:28:51 -0000 --_ba2e4557-7e6c-4fd0-b565-849f2560d0d3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This document includes a requirement for encoding of the NAI as per RFC 428= 2.=20 Today=2C RADIUS implementations do not convert U-labels within the domain-p= ortion of the NAI to A-labels=2C because the User-Name attribute is 8-bit c= lean and designed to handle UTF-8=2C as described within RFC 2865=2C Sectio= n 5.1. As a result=2C RFC 4282 doesn't really apply to RADIUS=2C and mentioning th= at with respect to User-Name encoding is potentially confusing (and could c= reate an interoperability problem that doesn't exist today).=20 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Tuesday=2C November 01=2C 2011 1:44 AM > To: i-d-announce@ietf.org > Cc: abfab@ietf.org > Subject: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Application Bridging for > Federated Access Beyond web Working Group of the IETF. >=20 > Title : A RADIUS Attribute=2C Binding and Profiles for > SAML > Author(s) : Josh Howlett > Sam Hartman > Filename : draft-ietf-abfab-aaa-saml-02.txt > Pages : 14 > Date : 2011-10-31 >=20 > This document specifies a RADIUS attribute=2C binding and two profiles > for the Security Assertion Mark-up Language (SAML). The attribute > provides RADIUS encapsulation of SAML protocol messages=2C while the > binding describes the transport of this attribute=2C and the SAML > protocol messages within=2C using RADIUS. The profiles describe the > application of this binding for Abfab authentication and assertion > query/request. The SAML RADIUS attribute and binding are defined > generically to permit application in other scenarios=2C such as networ= k > access. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-02.txt > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext = --_ba2e4557-7e6c-4fd0-b565-849f2560d0d3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This document includes a requirement for encoding of the NAI as per RFC 428= 2.

Today=2C RADIUS implementations do not convert U-labels within t= he domain-portion of the NAI to A-labels=2C because the User-Name attribute= is 8-bit clean and designed to handle UTF-8=2C as described within RFC 286= 5=2C Section 5.1.

As a result=2C RFC 4282 doesn't really apply to RA= DIUS=2C and mentioning that with respect to User-Name encoding is potential= ly confusing (and could create an interoperability problem that doesn't exi= st today).





>=3B -----Original Message----->=3B From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Be= half
>=3B Of internet-drafts@ietf.org
>=3B Sent: Tuesday=2C Novem= ber 01=2C 2011 1:44 AM
>=3B To: i-d-announce@ietf.org
>=3B Cc: ab= fab@ietf.org
>=3B Subject: [abfab] I-D Action: draft-ietf-abfab-aaa-sa= ml-02.txt
>=3B
>=3B A New Internet-Draft is available from the o= n-line Internet-Drafts
>=3B directories. This draft is a work item of = the Application Bridging for
>=3B Federated Access Beyond web Working = Group of the IETF.
>=3B
>=3B Title : A RADIUS Attribu= te=2C Binding and Profiles for
>=3B SAML
>=3B Author(s) : = Josh Howlett
>=3B Sam Hartman
>=3B Fil= ename : draft-ietf-abfab-aaa-saml-02.txt
>=3B Pages = : 14
>=3B Date : 2011-10-31
>=3B
>=3B This d= ocument specifies a RADIUS attribute=2C binding and two profiles
>=3B = for the Security Assertion Mark-up Language (SAML). The attribute
&g= t=3B provides RADIUS encapsulation of SAML protocol messages=2C while th= e
>=3B binding describes the transport of this attribute=2C and the= SAML
>=3B protocol messages within=2C using RADIUS. The profiles = describe the
>=3B application of this binding for Abfab authenticat= ion and assertion
>=3B query/request. The SAML RADIUS attribute an= d binding are defined
>=3B generically to permit application in oth= er scenarios=2C such as network
>=3B access.
>=3B
>=3B <= br>>=3B A URL for this Internet-Draft is:
>=3B http://www.ietf.org/i= nternet-drafts/draft-ietf-abfab-aaa-saml-02.txt
>=3B
>=3B Intern= et-Drafts are also available by anonymous FTP at:
>=3B ftp://ftp.ietf.= org/internet-drafts/
>=3B
>=3B This Internet-Draft can be retrie= ved at:
>=3B ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-aaa-s= aml-02.txt
>=3B _______________________________________________
>= =3B abfab mailing list
>=3B abfab@ietf.org
>=3B https://www.ietf.= org/mailman/listinfo/abfab
>=3B ______________________________________= _________
>=3B radext mailing list
>=3B radext@ietf.org
>=3B= https://www.ietf.org/mailman/listinfo/radext
= --_ba2e4557-7e6c-4fd0-b565-849f2560d0d3_-- From radext-bounces@ietf.org Wed Nov 2 00:43:48 2011 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 9809B11E80A6; Wed, 2 Nov 2011 00:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320219828; bh=KVrqkZ3uL9egcmSfo3spYtwMGakSLkm3y13WrLcNgOs=; 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=rkEbGvaRrYNR/Mz5wE5QtrTelPArojxzLdcI71Ed0ES7dqW0gb9Vvl/BJUJhsbOPD Fa+GJq7QUQH/LBpi57kJccqoPV2UBpImcmTIXE3fWvULSJ7iidA0AnpIJJRLzqDzRo DsHKgTjDU2FyRtEFdhJPhe5PbrirItN05cLHXChg= 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 B8C7511E80A6 for ; Wed, 2 Nov 2011 00:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.385 X-Spam-Level: X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 uEOzvKlCxqwv for ; Wed, 2 Nov 2011 00:43:46 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id C424211E80A3 for ; Wed, 2 Nov 2011 00:43:46 -0700 (PDT) Message-ID: <4EB0F497.1000104@deployingradius.com> Date: Wed, 02 Nov 2011 08:43:19 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: "dromasca@avaya.com" , radext@ietf.org Subject: Re: [radext] RFC 4282 and RADIUS implementations (was abfab and SAML) 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 Bernard Aboba wrote: > This document includes a requirement for encoding of the NAI as per RFC > 4282. > > Today, RADIUS implementations do not convert U-labels within the > domain-portion of the NAI to A-labels, because the User-Name attribute > is 8-bit clean and designed to handle UTF-8, as described within RFC > 2865, Section 5.1. I agree. I pointed the document authors to my 4282bis, and they pointed out it wasn't a published spec, or even a WG item. > As a result, RFC 4282 doesn't really apply to RADIUS, and mentioning > that with respect to User-Name encoding is potentially confusing (and > could create an interoperability problem that doesn't exist today). This is the most important point for me. Is it time to move ahead with 4282bis? There have been few comments on the existing doc. All it does is codify current practice. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Wed Nov 2 00:43:47 2011 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 B8C7511E80A6 for ; Wed, 2 Nov 2011 00:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.385 X-Spam-Level: X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 uEOzvKlCxqwv for ; Wed, 2 Nov 2011 00:43:46 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id C424211E80A3 for ; Wed, 2 Nov 2011 00:43:46 -0700 (PDT) Message-ID: <4EB0F497.1000104@deployingradius.com> Date: Wed, 02 Nov 2011 08:43:19 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dromasca@avaya.com" , radext@ietf.org Subject: Re: [radext] RFC 4282 and RADIUS implementations (was abfab and SAML) 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, 02 Nov 2011 07:43:47 -0000 Bernard Aboba wrote: > This document includes a requirement for encoding of the NAI as per RFC > 4282. > > Today, RADIUS implementations do not convert U-labels within the > domain-portion of the NAI to A-labels, because the User-Name attribute > is 8-bit clean and designed to handle UTF-8, as described within RFC > 2865, Section 5.1. I agree. I pointed the document authors to my 4282bis, and they pointed out it wasn't a published spec, or even a WG item. > As a result, RFC 4282 doesn't really apply to RADIUS, and mentioning > that with respect to User-Name encoding is potentially confusing (and > could create an interoperability problem that doesn't exist today). This is the most important point for me. Is it time to move ahead with 4282bis? There have been few comments on the existing doc. All it does is codify current practice. Alan DeKok. From bernard_aboba@hotmail.com Wed Nov 2 08:22:26 2011 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 D4AB221F8F36 for ; Wed, 2 Nov 2011 08:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.178, 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 KthXwLpYpaDM for ; Wed, 2 Nov 2011 08:22:26 -0700 (PDT) Received: from blu0-omc2-s35.blu0.hotmail.com (blu0-omc2-s35.blu0.hotmail.com [65.55.111.110]) by ietfa.amsl.com (Postfix) with ESMTP id 134B821F8F56 for ; Wed, 2 Nov 2011 08:22:25 -0700 (PDT) Received: from BLU152-W37 ([65.55.111.73]) by blu0-omc2-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 08:22:25 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_c0e7e51b-9dbb-4977-aff3-86b7d36080cb_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Alan DeKok Date: Wed, 2 Nov 2011 08:22:25 -0700 Importance: Normal In-Reply-To: <4EB0F497.1000104@deployingradius.com> References: , <4EB0F497.1000104@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 02 Nov 2011 15:22:25.0520 (UTC) FILETIME=[39B2A700:01CC9973] Cc: "dromasca@avaya.com" , radext@ietf.org Subject: Re: [radext] RFC 4282 and RADIUS implementations (was abfab and SAML) 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, 02 Nov 2011 15:22:26 -0000 --_c0e7e51b-9dbb-4977-aff3-86b7d36080cb_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > This document includes a requirement for encoding of the NAI as per RFC > > 4282. > >=20 > > Today=2C RADIUS implementations do not convert U-labels within the > > domain-portion of the NAI to A-labels=2C because the User-Name attribut= e > > is 8-bit clean and designed to handle UTF-8=2C as described within RFC > > 2865=2C Section 5.1. >=20 > I agree. I pointed the document authors to my 4282bis=2C and they > pointed out it wasn't a published spec=2C or even a WG item. > > > As a result=2C RFC 4282 doesn't really apply to RADIUS=2C and mentionin= g > > that with respect to User-Name encoding is potentially confusing (and > > could create an interoperability problem that doesn't exist today). >=20 > This is the most important point for me. >=20 > Is it time to move ahead with 4282bis? There have been few comments > on the existing doc. All it does is codify current practice. > > [BA] Given that the spec would create an incompatible variant of RADIUS=2C I'd say that the situation is pretty serious=2C and that a document clarify= ing the encoding of the NAI within RADIUS is critical.=20 Beyond that though=2C it strikes me that we may also need a "RADIUS Change Process" document. =20 = --_c0e7e51b-9dbb-4977-aff3-86b7d36080cb_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B >=3B This document includes a requirement for encoding of the NAI = as per RFC
>=3B >=3B 4282.
>=3B >=3B
>=3B >=3B T= oday=2C RADIUS implementations do not convert U-labels within the
>=3B= >=3B domain-portion of the NAI to A-labels=2C because the User-Name attr= ibute
>=3B >=3B is 8-bit clean and designed to handle UTF-8=2C as de= scribed within RFC
>=3B >=3B 2865=2C Section 5.1.
>=3B
>= =3B I agree. I pointed the document authors to my 4282bis=2C and they>=3B pointed out it wasn't a published spec=2C or even a WG item.
>= =3B
>=3B >=3B As a result=2C RFC 4282 doesn't really apply to RADIUS= =2C and mentioning
>=3B >=3B that with respect to User-Name encoding= is potentially confusing (and
>=3B >=3B could create an interoperab= ility problem that doesn't exist today).
>=3B
>=3B This is the= most important point for me.
>=3B
>=3B Is it time to move ahe= ad with 4282bis? There have been few comments
>=3B on the existing do= c. All it does is codify current practice.
>=3B
>=3B
[BA] Giv= en that the spec would create an incompatible variant of RADIUS=2C
I'd s= ay that the situation is pretty serious=2C and that a document clarifyingthe encoding of the NAI within RADIUS is critical.

Beyond that th= ough=2C it strikes me that we may also need a "RADIUS Change
Process" do= cument. =3B



= --_c0e7e51b-9dbb-4977-aff3-86b7d36080cb_-- From radext-bounces@ietf.org Wed Nov 2 08:22:30 2011 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 ED59821F8FF8; Wed, 2 Nov 2011 08:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320247349; bh=KZONL344fxlOSrrtaRrKlJbsbSjFfPhgBDEU40K6xpo=; h=Message-ID:From:To:Date:In-Reply-To:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=wkCWy68EHItx9Sl3MXKyuUVgffQ/7OFQI3xPx1g4KNhO2mcnHECfoY7FWBt/HYU6L GqVMDAGNzvtGy41kU4YC5C/sbgsl0tgKMjWiXgQr8HMHAVQsNLP7y194g9ox4YNH8L 0JhYuiUGAUfa9lrSYffArxghjOEsBlEY1ptbeaVc= 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 D4AB221F8F36 for ; Wed, 2 Nov 2011 08:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.178, 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 KthXwLpYpaDM for ; Wed, 2 Nov 2011 08:22:26 -0700 (PDT) Received: from blu0-omc2-s35.blu0.hotmail.com (blu0-omc2-s35.blu0.hotmail.com [65.55.111.110]) by ietfa.amsl.com (Postfix) with ESMTP id 134B821F8F56 for ; Wed, 2 Nov 2011 08:22:25 -0700 (PDT) Received: from BLU152-W37 ([65.55.111.73]) by blu0-omc2-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 08:22:25 -0700 Message-ID: X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Alan DeKok Date: Wed, 2 Nov 2011 08:22:25 -0700 Importance: Normal In-Reply-To: <4EB0F497.1000104@deployingradius.com> References: , <4EB0F497.1000104@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 02 Nov 2011 15:22:25.0520 (UTC) FILETIME=[39B2A700:01CC9973] Cc: "dromasca@avaya.com" , radext@ietf.org Subject: Re: [radext] RFC 4282 and RADIUS implementations (was abfab and SAML) 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="===============5754838346173895590==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============5754838346173895590== Content-Type: multipart/alternative; boundary="_c0e7e51b-9dbb-4977-aff3-86b7d36080cb_" --_c0e7e51b-9dbb-4977-aff3-86b7d36080cb_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > This document includes a requirement for encoding of the NAI as per RFC > > 4282. > >=20 > > Today=2C RADIUS implementations do not convert U-labels within the > > domain-portion of the NAI to A-labels=2C because the User-Name attribut= e > > is 8-bit clean and designed to handle UTF-8=2C as described within RFC > > 2865=2C Section 5.1. >=20 > I agree. I pointed the document authors to my 4282bis=2C and they > pointed out it wasn't a published spec=2C or even a WG item. > > > As a result=2C RFC 4282 doesn't really apply to RADIUS=2C and mentionin= g > > that with respect to User-Name encoding is potentially confusing (and > > could create an interoperability problem that doesn't exist today). >=20 > This is the most important point for me. >=20 > Is it time to move ahead with 4282bis? There have been few comments > on the existing doc. All it does is codify current practice. > > [BA] Given that the spec would create an incompatible variant of RADIUS=2C I'd say that the situation is pretty serious=2C and that a document clarify= ing the encoding of the NAI within RADIUS is critical.=20 Beyond that though=2C it strikes me that we may also need a "RADIUS Change Process" document. =20 = --_c0e7e51b-9dbb-4977-aff3-86b7d36080cb_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B >=3B This document includes a requirement for encoding of the NAI = as per RFC
>=3B >=3B 4282.
>=3B >=3B
>=3B >=3B T= oday=2C RADIUS implementations do not convert U-labels within the
>=3B= >=3B domain-portion of the NAI to A-labels=2C because the User-Name attr= ibute
>=3B >=3B is 8-bit clean and designed to handle UTF-8=2C as de= scribed within RFC
>=3B >=3B 2865=2C Section 5.1.
>=3B
>= =3B I agree. I pointed the document authors to my 4282bis=2C and they>=3B pointed out it wasn't a published spec=2C or even a WG item.
>= =3B
>=3B >=3B As a result=2C RFC 4282 doesn't really apply to RADIUS= =2C and mentioning
>=3B >=3B that with respect to User-Name encoding= is potentially confusing (and
>=3B >=3B could create an interoperab= ility problem that doesn't exist today).
>=3B
>=3B This is the= most important point for me.
>=3B
>=3B Is it time to move ahe= ad with 4282bis? There have been few comments
>=3B on the existing do= c. All it does is codify current practice.
>=3B
>=3B
[BA] Giv= en that the spec would create an incompatible variant of RADIUS=2C
I'd s= ay that the situation is pretty serious=2C and that a document clarifyingthe encoding of the NAI within RADIUS is critical.

Beyond that th= ough=2C it strikes me that we may also need a "RADIUS Change
Process" do= cument. =3B



= --_c0e7e51b-9dbb-4977-aff3-86b7d36080cb_-- --===============5754838346173895590== 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 --===============5754838346173895590==-- From radext-bounces@ietf.org Wed Nov 2 16:34:45 2011 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 3119311E8091; Wed, 2 Nov 2011 16:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320276885; bh=ncOzykfu6cnIRzRMlrS5a0WiUI3egKQJDCmiUIWMUA0=; h=From:To:Date:Message-ID:References:In-Reply-To:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=SvRm52KkQUPStmwwUkZKfVxP1ZuN9h8+0lVFDt86iQYOY7E2DY13XyrD49Xp2ZvpB QqKQn6gDAC26/VI6MiroX55jPQ4LuA3GNfCokzl6xBeLqWAuCAbLexmJTxiadwGUnF gX4K5/C0WLMU0SYWuihXP/XQUtPpF3JfU5lnW1qY= 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 6F58811E8091 for ; Wed, 2 Nov 2011 16:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 2GYt4deNWa-i for ; Wed, 2 Nov 2011 16:34:42 -0700 (PDT) Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5A26B11E8073 for ; Wed, 2 Nov 2011 16:34:42 -0700 (PDT) Received: from G9W0369G.americas.hpqcorp.net (g9w0369g.houston.hp.com [16.216.193.232]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTPS id 95E79803E; Wed, 2 Nov 2011 23:34:41 +0000 (UTC) Received: from G6W0173.americas.hpqcorp.net (16.230.33.182) by G9W0369G.americas.hpqcorp.net (16.216.193.232) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 2 Nov 2011 23:32:41 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G6W0173.americas.hpqcorp.net ([16.230.33.182]) with mapi; Wed, 2 Nov 2011 23:32:40 +0000 From: "Sanchez, Mauricio (HP Networking)" To: Bernard Aboba , Alan DeKok Date: Wed, 2 Nov 2011 23:32:38 +0000 Thread-Topic: [radext] RFC 4282 and RADIUS implementations (was abfab and SAML) Thread-Index: AcyZc0ttsxcdnKCqTIu8giKN5ztV5gARCc0w Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD0AD3BFB@GVW0671EXC.americas.hpqcorp.net> References: , <4EB0F497.1000104@deployingradius.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "dromasca@avaya.com" , "radext@ietf.org" Subject: Re: [radext] RFC 4282 and RADIUS implementations (was abfab and SAML) 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="===============0955022397727150592==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============0955022397727150592== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0AD3BFBGVW0671EXCame_" --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0AD3BFBGVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We should discuss this at upcoming meeting. Alan: I see that you posted a new rev of the NAI doc. Are you amendable to= presenting on your doc and framing in the context of the conversation belo= w? -MS From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of= Bernard Aboba Sent: Wednesday, November 02, 2011 8:22 AM To: Alan DeKok Cc: dromasca@avaya.com; radext@ietf.org Subject: Re: [radext] RFC 4282 and RADIUS implementations (was abfab and SA= ML) > > This document includes a requirement for encoding of the NAI as per RFC > > 4282. > > > > Today, RADIUS implementations do not convert U-labels within the > > domain-portion of the NAI to A-labels, because the User-Name attribute > > is 8-bit clean and designed to handle UTF-8, as described within RFC > > 2865, Section 5.1. > > I agree. I pointed the document authors to my 4282bis, and they > pointed out it wasn't a published spec, or even a WG item. > > > As a result, RFC 4282 doesn't really apply to RADIUS, and mentioning > > that with respect to User-Name encoding is potentially confusing (and > > could create an interoperability problem that doesn't exist today). > > This is the most important point for me. > > Is it time to move ahead with 4282bis? There have been few comments > on the existing doc. All it does is codify current practice. > > [BA] Given that the spec would create an incompatible variant of RADIUS, I'd say that the situation is pretty serious, and that a document clarifyin= g the encoding of the NAI within RADIUS is critical. Beyond that though, it strikes me that we may also need a "RADIUS Change Process" document. --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0AD3BFBGVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We should= discuss this at upcoming meeting. 

 

Ala= n: I see that you posted a new rev of the NAI doc.  Are you amendable = to presenting on your doc and framing in the context of the conversation be= low? 

 

-MS

 

From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On= Behalf Of Bernard Aboba
Sent: Wednesday, November 02, 2011 8= :22 AM
To: Alan DeKok
Cc: dromasca@avaya.com; radext@ie= tf.org
Subject: Re: [radext] RFC 4282 and RADIUS implementations = (was abfab and SAML)

=  

> > This document includes a r= equirement for encoding of the NAI as per RFC

> > 4282.
> >
&= gt; > Today, RADIUS implementations do not convert U-labels within the> > domain-portion of the NAI to A-labels, because the User-Name at= tribute
> > is 8-bit clean and designed to handle UTF-8, as descri= bed within RFC
> > 2865, Section 5.1.
>
> I agree. I = pointed the document authors to my 4282bis, and they
> pointed out it= wasn't a published spec, or even a WG item.
>
> > As a resu= lt, RFC 4282 doesn't really apply to RADIUS, and mentioning
> > th= at with respect to User-Name encoding is potentially confusing (and
>= > could create an interoperability problem that doesn't exist today).>
> This is the most important point for me.
>
> I= s it time to move ahead with 4282bis? There have been few comments
> = on the existing doc. All it does is codify current practice.
>
>= ;
[BA] Given that the spec would create an incompatible variant of RADIU= S,
I'd say that the situation is pretty serious, and that a document cla= rifying
the encoding of the NAI within RADIUS is critical.

Beyon= d that though, it strikes me that we may also need a "RADIUS ChangeProcess" document. 


= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0AD3BFBGVW0671EXCame_-- --===============0955022397727150592== 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 --===============0955022397727150592==-- From mauricio.sanchez@hp.com Wed Nov 2 16:34:43 2011 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 6F58811E8091 for ; Wed, 2 Nov 2011 16:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 2GYt4deNWa-i for ; Wed, 2 Nov 2011 16:34:42 -0700 (PDT) Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5A26B11E8073 for ; Wed, 2 Nov 2011 16:34:42 -0700 (PDT) Received: from G9W0369G.americas.hpqcorp.net (g9w0369g.houston.hp.com [16.216.193.232]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTPS id 95E79803E; Wed, 2 Nov 2011 23:34:41 +0000 (UTC) Received: from G6W0173.americas.hpqcorp.net (16.230.33.182) by G9W0369G.americas.hpqcorp.net (16.216.193.232) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 2 Nov 2011 23:32:41 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G6W0173.americas.hpqcorp.net ([16.230.33.182]) with mapi; Wed, 2 Nov 2011 23:32:40 +0000 From: "Sanchez, Mauricio (HP Networking)" To: Bernard Aboba , Alan DeKok Date: Wed, 2 Nov 2011 23:32:38 +0000 Thread-Topic: [radext] RFC 4282 and RADIUS implementations (was abfab and SAML) Thread-Index: AcyZc0ttsxcdnKCqTIu8giKN5ztV5gARCc0w Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD0AD3BFB@GVW0671EXC.americas.hpqcorp.net> References: , <4EB0F497.1000104@deployingradius.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0AD3BFBGVW0671EXCame_" MIME-Version: 1.0 Cc: "dromasca@avaya.com" , "radext@ietf.org" Subject: Re: [radext] RFC 4282 and RADIUS implementations (was abfab and SAML) 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, 02 Nov 2011 23:34:43 -0000 --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0AD3BFBGVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We should discuss this at upcoming meeting. Alan: I see that you posted a new rev of the NAI doc. Are you amendable to= presenting on your doc and framing in the context of the conversation belo= w? -MS From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of= Bernard Aboba Sent: Wednesday, November 02, 2011 8:22 AM To: Alan DeKok Cc: dromasca@avaya.com; radext@ietf.org Subject: Re: [radext] RFC 4282 and RADIUS implementations (was abfab and SA= ML) > > This document includes a requirement for encoding of the NAI as per RFC > > 4282. > > > > Today, RADIUS implementations do not convert U-labels within the > > domain-portion of the NAI to A-labels, because the User-Name attribute > > is 8-bit clean and designed to handle UTF-8, as described within RFC > > 2865, Section 5.1. > > I agree. I pointed the document authors to my 4282bis, and they > pointed out it wasn't a published spec, or even a WG item. > > > As a result, RFC 4282 doesn't really apply to RADIUS, and mentioning > > that with respect to User-Name encoding is potentially confusing (and > > could create an interoperability problem that doesn't exist today). > > This is the most important point for me. > > Is it time to move ahead with 4282bis? There have been few comments > on the existing doc. All it does is codify current practice. > > [BA] Given that the spec would create an incompatible variant of RADIUS, I'd say that the situation is pretty serious, and that a document clarifyin= g the encoding of the NAI within RADIUS is critical. Beyond that though, it strikes me that we may also need a "RADIUS Change Process" document. --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0AD3BFBGVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We should= discuss this at upcoming meeting. 

 

Ala= n: I see that you posted a new rev of the NAI doc.  Are you amendable = to presenting on your doc and framing in the context of the conversation be= low? 

 

-MS

 

From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On= Behalf Of Bernard Aboba
Sent: Wednesday, November 02, 2011 8= :22 AM
To: Alan DeKok
Cc: dromasca@avaya.com; radext@ie= tf.org
Subject: Re: [radext] RFC 4282 and RADIUS implementations = (was abfab and SAML)

=  

> > This document includes a r= equirement for encoding of the NAI as per RFC

> > 4282.
> >
&= gt; > Today, RADIUS implementations do not convert U-labels within the> > domain-portion of the NAI to A-labels, because the User-Name at= tribute
> > is 8-bit clean and designed to handle UTF-8, as descri= bed within RFC
> > 2865, Section 5.1.
>
> I agree. I = pointed the document authors to my 4282bis, and they
> pointed out it= wasn't a published spec, or even a WG item.
>
> > As a resu= lt, RFC 4282 doesn't really apply to RADIUS, and mentioning
> > th= at with respect to User-Name encoding is potentially confusing (and
>= > could create an interoperability problem that doesn't exist today).>
> This is the most important point for me.
>
> I= s it time to move ahead with 4282bis? There have been few comments
> = on the existing doc. All it does is codify current practice.
>
>= ;
[BA] Given that the spec would create an incompatible variant of RADIU= S,
I'd say that the situation is pretty serious, and that a document cla= rifying
the encoding of the NAI within RADIUS is critical.

Beyon= d that though, it strikes me that we may also need a "RADIUS ChangeProcess" document. 


= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0AD3BFBGVW0671EXCame_-- From aland@deployingradius.com Thu Nov 3 00:03:01 2011 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 306631F0C81 for ; Thu, 3 Nov 2011 00:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.406 X-Spam-Level: X-Spam-Status: No, score=-102.406 tagged_above=-999 required=5 tests=[AWL=0.193, 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 4KdI+1ADJdBn for ; Thu, 3 Nov 2011 00:03:00 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 9650A1F0C79 for ; Thu, 3 Nov 2011 00:03:00 -0700 (PDT) Message-ID: <4EB23C87.4000901@deployingradius.com> Date: Thu, 03 Nov 2011 08:02:31 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Sanchez, Mauricio (HP Networking)" References: , <4EB0F497.1000104@deployingradius.com> <9BC2F7926B33FE4AB10D69891D58FC1C5CD0AD3BFB@GVW0671EXC.americas.hpqcorp.net> In-Reply-To: <9BC2F7926B33FE4AB10D69891D58FC1C5CD0AD3BFB@GVW0671EXC.americas.hpqcorp.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , "dromasca@avaya.com" , "radext@ietf.org" Subject: Re: [radext] RFC 4282 and RADIUS implementations (was abfab and SAML) 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, 03 Nov 2011 07:03:01 -0000 Sanchez, Mauricio (HP Networking) wrote: > Alan: I see that you posted a new rev of the NAI doc. Are you amendable > to presenting on your doc and framing in the context of the conversation > below? Yes. Alan DeKok. From radext-bounces@ietf.org Thu Nov 3 00:03:02 2011 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 E14E01F0C81; Thu, 3 Nov 2011 00:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320303782; bh=AZUg2dP+pKXwBy97tWY0sHaYVFEm0EanBFDb+Q6Kmto=; 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=qPImJ+blrcs2XnaV5Gk7vQILWb0MIXuCeFA4etEzdaUmA5pwJGeArOGANXZxnN8M9 GtiPvOTbQ2H8tfJ0d2i3hILXbtAwU99B+U0P3Mz0ErDVtJl9UzFLZKhtPmItvm7fJ3 cQtNgPBCXJEfi+KxBq2m5/Qo7bsjQL47m+rCMZBs= 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 306631F0C81 for ; Thu, 3 Nov 2011 00:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.406 X-Spam-Level: X-Spam-Status: No, score=-102.406 tagged_above=-999 required=5 tests=[AWL=0.193, 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 4KdI+1ADJdBn for ; Thu, 3 Nov 2011 00:03:00 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 9650A1F0C79 for ; Thu, 3 Nov 2011 00:03:00 -0700 (PDT) Message-ID: <4EB23C87.4000901@deployingradius.com> Date: Thu, 03 Nov 2011 08:02:31 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Sanchez, Mauricio (HP Networking)" References: , <4EB0F497.1000104@deployingradius.com> <9BC2F7926B33FE4AB10D69891D58FC1C5CD0AD3BFB@GVW0671EXC.americas.hpqcorp.net> In-Reply-To: <9BC2F7926B33FE4AB10D69891D58FC1C5CD0AD3BFB@GVW0671EXC.americas.hpqcorp.net> X-Enigmail-Version: 0.96.0 Cc: Bernard Aboba , "dromasca@avaya.com" , "radext@ietf.org" Subject: Re: [radext] RFC 4282 and RADIUS implementations (was abfab and SAML) 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 Sanchez, Mauricio (HP Networking) wrote: > Alan: I see that you posted a new rev of the NAI doc. Are you amendable > to presenting on your doc and framing in the context of the conversation > below? Yes. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Thu Nov 3 03:23:25 2011 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 5082B11E80AC; Thu, 3 Nov 2011 03:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320315805; bh=608SeLnpAni5ksiKZtH8gbqJYw3/Y30p4irGqinlmnY=; 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=EQCRxAJ55f/CG04jutiLKqlYFNd4LpvR03cWFbgM2SiNKqgyTrR7Fv3wrnr35nxRv 2ulSawN7QK9xw7dojd+t4M1xUX11kuFBTuMwbx5tS6xWAuItzqS8kHExjOJ9QPiLHA xRryhj33l8D51/KJjVJNOMYqNlP1OEyFtixaDjnk= 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 8CB8A11E8088 for ; Thu, 3 Nov 2011 03:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fMVFTCfuB+y for ; Thu, 3 Nov 2011 03:23:24 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8B511E80AC for ; Thu, 3 Nov 2011 03:23:23 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id E1B0E107C2 for ; Thu, 3 Nov 2011 11:23:21 +0100 (CET) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id D6155107B5 for ; Thu, 3 Nov 2011 11:23:21 +0100 (CET) Message-ID: <4EB26BA3.2000308@restena.lu> Date: Thu, 03 Nov 2011 11:23:31 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: radext@ietf.org References: <4EAFBC28.40902@deployingradius.com> In-Reply-To: <4EAFBC28.40902@deployingradius.com> X-Enigmail-Version: 1.3.2 X-Virus-Scanned: ClamAV Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-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="===============1304133839346822461==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1304133839346822461== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCECFD79C7A364DA9FE13CFB1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCECFD79C7A364DA9FE13CFB1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Looking at the names of the new attributes: > > Acct-Input-IPv4-Octets > Acct-Output-IPv4-Octets > Acct-Input-IPv4-Packets > Acct-Output-IPv4-Packets > Acct-Input-IPv6-Octets > Acct-Output-IPv6-Octets > Acct-Input-IPv6-Packets > Acct-Output-IPv6-Packets > > They're of the form: > > Acct- Input/Output - IPv4/IPv6 - Packets/Octets > > This looks like a good case for grouping by type, which means TLVs. > If you use the new format, TLVs would be preferred to using a "flat" > name space, and allocating 8 attributes from that space. That's exactly what my draft-winter-radext-fancyaccounting uses. The grouping comes very natural here; compared to that, introducing numerous attributes in flat space looks like a waste of attribute resources. > > One option would be to define two attributes: "Acct-Input-Stats" and > Acct-Output-Stats". They could be > 252 octets long, and contain TLVs.= > They could share the same set of sub-TLVs. > > The sub-TLVs could be: > > Acct-IPv4-Stats for IPv4 data > Acct-IPv6-Stats for IPv6 data > > Those sub-TLVs in turn could contain: > > Acct-Packet-Stats > Acct-Octet-Stats > > The Acct-Input-IPv4-Octets attribute you define would then map to: > > Acct-Input-Stats ( Acct-IP4-Stats ( Acct-Packet-Stats (value))) > > This uses more space in the packet, but is more general. Other > specifications could add TCP stats, UDP stats, etc. > > You mention draft-winter-radext-fancyaccounting-00. I haven't > compared the two documents in detail, but I'd like to know what overlap= > (if any) exists between them. Having the WG converge on one proposal > would be a good thing. AFAICT, fancyaccounting's capabilities are a superset of this document's. It defines a generic TLV container for traffic classes. Two such classes could be "IPv4" and "IPv6", but arbitrary other traffic classes are possible. E.g. if accounting should be done for different DSCP classes (separate billing levels), it would be easy to add that to fancyaccounting without allocating new attributes *again*. With the ext-traffic-stats document, every new traffic class would require as much as 4 new attributes. It is also not easily possible to combine criteria; e.g. if you want to have per-DSCP stats per-IP version, this cannot be expressed. Hard-wiring attribute names for one specific class of traffic does not sound prudent to me. Greetings, Stefan Winter > > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigCECFD79C7A364DA9FE13CFB1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6ya6cACgkQ+jm90f8eFWa+AQCfdG0qaINR8IR16Uj2mbMz7Kfv zEAAnjtbk+K3z2PNj82MXYKsideki7BV =NdZl -----END PGP SIGNATURE----- --------------enigCECFD79C7A364DA9FE13CFB1-- --===============1304133839346822461== 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 --===============1304133839346822461==-- From stefan.winter@restena.lu Thu Nov 3 03:23:24 2011 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 8CB8A11E8088 for ; Thu, 3 Nov 2011 03:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fMVFTCfuB+y for ; Thu, 3 Nov 2011 03:23:24 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8B511E80AC for ; Thu, 3 Nov 2011 03:23:23 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id E1B0E107C2 for ; Thu, 3 Nov 2011 11:23:21 +0100 (CET) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id D6155107B5 for ; Thu, 3 Nov 2011 11:23:21 +0100 (CET) Message-ID: <4EB26BA3.2000308@restena.lu> Date: Thu, 03 Nov 2011 11:23:31 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: radext@ietf.org References: <4EAFBC28.40902@deployingradius.com> In-Reply-To: <4EAFBC28.40902@deployingradius.com> X-Enigmail-Version: 1.3.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCECFD79C7A364DA9FE13CFB1" X-Virus-Scanned: ClamAV Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-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: Thu, 03 Nov 2011 10:23:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCECFD79C7A364DA9FE13CFB1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Looking at the names of the new attributes: > > Acct-Input-IPv4-Octets > Acct-Output-IPv4-Octets > Acct-Input-IPv4-Packets > Acct-Output-IPv4-Packets > Acct-Input-IPv6-Octets > Acct-Output-IPv6-Octets > Acct-Input-IPv6-Packets > Acct-Output-IPv6-Packets > > They're of the form: > > Acct- Input/Output - IPv4/IPv6 - Packets/Octets > > This looks like a good case for grouping by type, which means TLVs. > If you use the new format, TLVs would be preferred to using a "flat" > name space, and allocating 8 attributes from that space. That's exactly what my draft-winter-radext-fancyaccounting uses. The grouping comes very natural here; compared to that, introducing numerous attributes in flat space looks like a waste of attribute resources. > > One option would be to define two attributes: "Acct-Input-Stats" and > Acct-Output-Stats". They could be > 252 octets long, and contain TLVs.= > They could share the same set of sub-TLVs. > > The sub-TLVs could be: > > Acct-IPv4-Stats for IPv4 data > Acct-IPv6-Stats for IPv6 data > > Those sub-TLVs in turn could contain: > > Acct-Packet-Stats > Acct-Octet-Stats > > The Acct-Input-IPv4-Octets attribute you define would then map to: > > Acct-Input-Stats ( Acct-IP4-Stats ( Acct-Packet-Stats (value))) > > This uses more space in the packet, but is more general. Other > specifications could add TCP stats, UDP stats, etc. > > You mention draft-winter-radext-fancyaccounting-00. I haven't > compared the two documents in detail, but I'd like to know what overlap= > (if any) exists between them. Having the WG converge on one proposal > would be a good thing. AFAICT, fancyaccounting's capabilities are a superset of this document's. It defines a generic TLV container for traffic classes. Two such classes could be "IPv4" and "IPv6", but arbitrary other traffic classes are possible. E.g. if accounting should be done for different DSCP classes (separate billing levels), it would be easy to add that to fancyaccounting without allocating new attributes *again*. With the ext-traffic-stats document, every new traffic class would require as much as 4 new attributes. It is also not easily possible to combine criteria; e.g. if you want to have per-DSCP stats per-IP version, this cannot be expressed. Hard-wiring attribute names for one specific class of traffic does not sound prudent to me. Greetings, Stefan Winter > > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigCECFD79C7A364DA9FE13CFB1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6ya6cACgkQ+jm90f8eFWa+AQCfdG0qaINR8IR16Uj2mbMz7Kfv zEAAnjtbk+K3z2PNj82MXYKsideki7BV =NdZl -----END PGP SIGNATURE----- --------------enigCECFD79C7A364DA9FE13CFB1-- From radext-bounces@ietf.org Fri Nov 4 02:44:15 2011 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 2EF6E21F8C3E; Fri, 4 Nov 2011 02:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320399855; bh=0b/9Sa3aDePr1MdBW3Out5vz3TVTtQJLfmvluzPLZh4=; 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=AKbl9cBSerIg374bGIhH1lSZ9gRCP7CPZJeghhMFlwiBb49YqAGjuXwiQIy+R3paT B6WirRDh7/QUPNYt6WnAdFsm2cL3nZ7P+wtysIm6SA8LZJ/XsjApXALxA/6io0ZKML cyC8ifxVyUf1R8aHV+Tv7sgOA90cYAF9UuCxu3Hs= 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 1F17121F8BE5; Fri, 4 Nov 2011 02:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 dYAzPgfs2AWm; Fri, 4 Nov 2011 02:44:13 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 8568C21F8C15; Fri, 4 Nov 2011 02:44:10 -0700 (PDT) Message-ID: <4EB3B3CD.1020009@deployingradius.com> Date: Fri, 04 Nov 2011 10:43:41 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: , <4EB0F497.1000104@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: "dromasca@avaya.com" , "abfab@ietf.org" , radext@ietf.org Subject: Re: [radext] RFC 4282 and RADIUS implementations (was abfab and SAML) 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 Bernard Aboba wrote: > [BA] Given that the spec would create an incompatible variant of RADIUS, > I'd say that the situation is pretty serious, and that a document clarifying > the encoding of the NAI within RADIUS is critical. OK. Can we get support for this position on the various mailing lists? I suspect the abfab people want to work within the existing RADIUS framework. The main difficulty is that the only NAI specification is 4282. If abfab has a normative dependency on an NAI spec, then publishing 4282bis quickly is a good idea. The draft describes existing practices, and has no new recommendations in it. So it *should* be non-controversial. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Fri Nov 4 02:44:14 2011 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 1F17121F8BE5; Fri, 4 Nov 2011 02:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 dYAzPgfs2AWm; Fri, 4 Nov 2011 02:44:13 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 8568C21F8C15; Fri, 4 Nov 2011 02:44:10 -0700 (PDT) Message-ID: <4EB3B3CD.1020009@deployingradius.com> Date: Fri, 04 Nov 2011 10:43:41 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: , <4EB0F497.1000104@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dromasca@avaya.com" , "abfab@ietf.org" , radext@ietf.org Subject: Re: [radext] RFC 4282 and RADIUS implementations (was abfab and SAML) 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, 04 Nov 2011 09:44:14 -0000 Bernard Aboba wrote: > [BA] Given that the spec would create an incompatible variant of RADIUS, > I'd say that the situation is pretty serious, and that a document clarifying > the encoding of the NAI within RADIUS is critical. OK. Can we get support for this position on the various mailing lists? I suspect the abfab people want to work within the existing RADIUS framework. The main difficulty is that the only NAI specification is 4282. If abfab has a normative dependency on an NAI spec, then publishing 4282bis quickly is a good idea. The draft describes existing practices, and has no new recommendations in it. So it *should* be non-controversial. Alan DeKok. From aland@deployingradius.com Fri Nov 4 06:40:17 2011 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 72D9C21F8BEC; Fri, 4 Nov 2011 06:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 P1yssSJk9MgE; Fri, 4 Nov 2011 06:40:17 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id CCE7C21F8BC5; Fri, 4 Nov 2011 06:40:16 -0700 (PDT) Message-ID: <4EB3EB21.6090800@deployingradius.com> Date: Fri, 04 Nov 2011 14:39:45 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <4EB0F497.1000104@deployingradius.com> <4EB3B3CD.1020009@deployingradius.com> 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, "abfab@ietf.org" Subject: Re: [radext] [abfab] RFC 4282 and RADIUS implementations 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, 04 Nov 2011 13:40:17 -0000 Sam Hartman wrote: > 4282 is currently a normative dependency of draft-ietf-abfab-gss-eap. That's a problem. As Bernard said, 4282 mandates behavior which *no one* implements. Anyone implementing 4282 will be incompatible with all known RADIUS systems. I think the goal of abfab is to be interoperable with existing RADIUS roaming systems. > I'd definitely want to understand the internationalization story before > supporting a new NAI spec. Short story: AAA systems shouldn't mangle the NAI. 4282 demands NAI mangling, which is bad. > I suspect others will feel similarly. So, even if we all end up > agreeing with you in the end, I'd expect it to be a careful > process--definitely far beyond what I hope it takes to get > draft-ietf-abfab-gss-eap approved. Then we have a problem. The draft conflicts with real-world practice. > Now, at least for ABFAB implementations, I don't think it's a big > deal. I think we can leave all the processing up to the final AAA > server. That's pretty much what is said by 4282bis. > I think i18n is a topic we really need to discuss for ABFAB in IETF 82. And interoperability with RADIUS. Alan DeKok. From radext-bounces@ietf.org Fri Nov 4 06:40:19 2011 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 B487821F8C34; Fri, 4 Nov 2011 06:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320414019; bh=zEbYbSsqbMnRXMij4nIdwSyEL4g6t9fy267wvNooz1k=; 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=Sa8FgaQS+dlmfiV6ZlLWiXXAi/XpNmnO4eOodLz8QiuDMhq12FPXxfyLjb+otzosO pAl+EayvR/U1oddvt3SpmQLHyCvrZ77ZG5a8yH32xRDWiZffJzZVQvSa29c8vky6ky Hugjbh/tpNWGGN4Ms9UdBW6Anqszq4D8Z4Yic3wk= 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 72D9C21F8BEC; Fri, 4 Nov 2011 06:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 P1yssSJk9MgE; Fri, 4 Nov 2011 06:40:17 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id CCE7C21F8BC5; Fri, 4 Nov 2011 06:40:16 -0700 (PDT) Message-ID: <4EB3EB21.6090800@deployingradius.com> Date: Fri, 04 Nov 2011 14:39:45 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <4EB0F497.1000104@deployingradius.com> <4EB3B3CD.1020009@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: Bernard Aboba , radext@ietf.org, "abfab@ietf.org" Subject: Re: [radext] [abfab] RFC 4282 and RADIUS implementations 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 Sam Hartman wrote: > 4282 is currently a normative dependency of draft-ietf-abfab-gss-eap. That's a problem. As Bernard said, 4282 mandates behavior which *no one* implements. Anyone implementing 4282 will be incompatible with all known RADIUS systems. I think the goal of abfab is to be interoperable with existing RADIUS roaming systems. > I'd definitely want to understand the internationalization story before > supporting a new NAI spec. Short story: AAA systems shouldn't mangle the NAI. 4282 demands NAI mangling, which is bad. > I suspect others will feel similarly. So, even if we all end up > agreeing with you in the end, I'd expect it to be a careful > process--definitely far beyond what I hope it takes to get > draft-ietf-abfab-gss-eap approved. Then we have a problem. The draft conflicts with real-world practice. > Now, at least for ABFAB implementations, I don't think it's a big > deal. I think we can leave all the processing up to the final AAA > server. That's pretty much what is said by 4282bis. > I think i18n is a topic we really need to discuss for ABFAB in IETF 82. And interoperability with RADIUS. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Fri Nov 4 07:10:48 2011 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 C051E21F8C41; Fri, 4 Nov 2011 07:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320415848; bh=rHGRaShkwE7paC6rMrssHettUU8GsRRP/VSOVJnt3NE=; h=From:To:Date:Message-ID:In-Reply-To:Content-ID:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=hXH66KGPnid+pEAOVvrbD0znReXpgf3MNHuStCpAuiUYJhSIb9pe3IsGriFrAqvWA r7O2Xs2pbF0TxcvN/B15GgUw5vzaT5/w89fBOyglHan1tqNL84FK8nRs5cRKZghiTQ GQOsrYX/YNbYRTxyso1pNmW77GA+nQIY6zMDEAIY= 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 62DA421F8BF6; Fri, 4 Nov 2011 03:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 wlbwcyY7v3DW; Fri, 4 Nov 2011 03:02:48 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id B873321F8B84; Fri, 4 Nov 2011 03:02:48 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 585801A9BDFD_EB3B847B; Fri, 4 Nov 2011 10:02:47 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 392CC1A9BB12_EB3B847F; Fri, 4 Nov 2011 10:02:47 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Fri, 4 Nov 2011 10:02:46 +0000 From: Josh Howlett To: Alan DeKok , Bernard Aboba Thread-Topic: [abfab] [radext] RFC 4282 and RADIUS implementations (was abfab and SAML) Thread-Index: AQHMmtjnIo886vb7uEWZ4qYbvdPxrg== Date: Fri, 4 Nov 2011 10:02:46 +0000 Message-ID: In-Reply-To: <4EB3B3CD.1020009@deployingradius.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [194.82.140.76] Content-ID: MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 04 Nov 2011 07:10:47 -0700 Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [radext] [abfab] RFC 4282 and RADIUS implementations (was abfab and SAML) 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 > I suspect the abfab people want to work within the existing RADIUS >framework. The main difficulty is that the only NAI specification is >4282. If abfab has a normative dependency on an NAI spec, then >publishing 4282bis quickly is a good idea. I think the alternative would be to define something abfab-specific, which would be non-optimal for the reasons given. I would prefer to use 4282bis. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Fri Nov 4 07:10:49 2011 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 2822A21F8C60; Fri, 4 Nov 2011 07:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320415849; bh=x9Nkx0UGwisP1f07S0cWIIR+08+aGOz0PRS0f/2+Pac=; h=From:To:References:Date:In-Reply-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=h2ZHYX6EwNQU7oHg7WHe0sFkNwScyAAC6J+rqmOb29pDooaRlbs/ZCYrlJr7OTzAP H+oRzCeM/J1gpsXS1yGyeJlBT2GXDItq8Ut54av7TqGM0K0WPp6E0vKjnb0sbaD+TE m5R74V+3k6rTU20LLhFURVk4LgvnOtWci85+3VUA= 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 CA62E21F8B6C; Fri, 4 Nov 2011 05:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 qDUXs3lnmlN0; Fri, 4 Nov 2011 05:58:14 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 017F721F8B6B; Fri, 4 Nov 2011 05:58:13 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6B86D2009E; Fri, 4 Nov 2011 08:58:54 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 28B4F435A; Fri, 4 Nov 2011 08:57:57 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <4EB0F497.1000104@deployingradius.com> <4EB3B3CD.1020009@deployingradius.com> Date: Fri, 04 Nov 2011 08:57:57 -0400 In-Reply-To: <4EB3B3CD.1020009@deployingradius.com> (Alan DeKok's message of "Fri, 04 Nov 2011 10:43:41 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 04 Nov 2011 07:10:47 -0700 Cc: Bernard Aboba , radext@ietf.org, "abfab@ietf.org" Subject: Re: [radext] [abfab] RFC 4282 and RADIUS implementations 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" == Alan DeKok writes: Alan> Bernard Aboba wrote: >> [BA] Given that the spec would create an incompatible variant of >> RADIUS, I'd say that the situation is pretty serious, and that a >> document clarifying the encoding of the NAI within RADIUS is >> critical. Alan> OK. Can we get support for this position on the various Alan> mailing lists? Alan> I suspect the abfab people want to work within the existing Alan> RADIUS framework. The main difficulty is that the only NAI Alan> specification is 4282. If abfab has a normative dependency on Alan> an NAI spec, then publishing 4282bis quickly is a good idea. 4282 is currently a normative dependency of draft-ietf-abfab-gss-eap. Alan> The draft describes existing practices, and has no new Alan> recommendations in it. So it *should* be non-controversial. Uh. Good luck with that. I'd definitely want to understand the internationalization story before supporting a new NAI spec. I understand your concerns with 4282. I suspect others will feel similarly. So, even if we all end up agreeing with you in the end, I'd expect it to be a careful process--definitely far beyond what I hope it takes to get draft-ietf-abfab-gss-eap approved. Now, at least for ABFAB implementations, I don't think it's a big deal. I think we can leave all the processing up to the final AAA server. I think i18n is a topic we really need to discuss for ABFAB in IETF 82. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From Josh.Howlett@ja.net Fri Nov 4 03:02:49 2011 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 62DA421F8BF6; Fri, 4 Nov 2011 03:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 wlbwcyY7v3DW; Fri, 4 Nov 2011 03:02:48 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id B873321F8B84; Fri, 4 Nov 2011 03:02:48 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 585801A9BDFD_EB3B847B; Fri, 4 Nov 2011 10:02:47 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 392CC1A9BB12_EB3B847F; Fri, 4 Nov 2011 10:02:47 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Fri, 4 Nov 2011 10:02:46 +0000 From: Josh Howlett To: Alan DeKok , Bernard Aboba Thread-Topic: [abfab] [radext] RFC 4282 and RADIUS implementations (was abfab and SAML) Thread-Index: AQHMmtjnIo886vb7uEWZ4qYbvdPxrg== Date: Fri, 4 Nov 2011 10:02:46 +0000 Message-ID: In-Reply-To: <4EB3B3CD.1020009@deployingradius.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 04 Nov 2011 07:10:47 -0700 Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [radext] [abfab] RFC 4282 and RADIUS implementations (was abfab and SAML) 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, 04 Nov 2011 10:02:49 -0000 > I suspect the abfab people want to work within the existing RADIUS >framework. The main difficulty is that the only NAI specification is >4282. If abfab has a normative dependency on an NAI spec, then >publishing 4282bis quickly is a good idea. I think the alternative would be to define something abfab-specific, which would be non-optimal for the reasons given. I would prefer to use 4282bis. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Fri Nov 4 05:58:14 2011 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 CA62E21F8B6C; Fri, 4 Nov 2011 05:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 qDUXs3lnmlN0; Fri, 4 Nov 2011 05:58:14 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 017F721F8B6B; Fri, 4 Nov 2011 05:58:13 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6B86D2009E; Fri, 4 Nov 2011 08:58:54 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 28B4F435A; Fri, 4 Nov 2011 08:57:57 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <4EB0F497.1000104@deployingradius.com> <4EB3B3CD.1020009@deployingradius.com> Date: Fri, 04 Nov 2011 08:57:57 -0400 In-Reply-To: <4EB3B3CD.1020009@deployingradius.com> (Alan DeKok's message of "Fri, 04 Nov 2011 10:43:41 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 04 Nov 2011 07:10:47 -0700 Cc: Bernard Aboba , radext@ietf.org, "abfab@ietf.org" Subject: Re: [radext] [abfab] RFC 4282 and RADIUS implementations 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, 04 Nov 2011 12:58:14 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Bernard Aboba wrote: >> [BA] Given that the spec would create an incompatible variant of >> RADIUS, I'd say that the situation is pretty serious, and that a >> document clarifying the encoding of the NAI within RADIUS is >> critical. Alan> OK. Can we get support for this position on the various Alan> mailing lists? Alan> I suspect the abfab people want to work within the existing Alan> RADIUS framework. The main difficulty is that the only NAI Alan> specification is 4282. If abfab has a normative dependency on Alan> an NAI spec, then publishing 4282bis quickly is a good idea. 4282 is currently a normative dependency of draft-ietf-abfab-gss-eap. Alan> The draft describes existing practices, and has no new Alan> recommendations in it. So it *should* be non-controversial. Uh. Good luck with that. I'd definitely want to understand the internationalization story before supporting a new NAI spec. I understand your concerns with 4282. I suspect others will feel similarly. So, even if we all end up agreeing with you in the end, I'd expect it to be a careful process--definitely far beyond what I hope it takes to get draft-ietf-abfab-gss-eap approved. Now, at least for ABFAB implementations, I don't think it's a big deal. I think we can leave all the processing up to the final AAA server. I think i18n is a topic we really need to discuss for ABFAB in IETF 82. From radext-bounces@ietf.org Fri Nov 4 09:54:10 2011 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 589F021F8BDC; Fri, 4 Nov 2011 09:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320425650; bh=eRsQyQz2e2pfr1PW6/sRXpn2OQGeWscoEgAVCYAnP/g=; h=Message-ID:Date:From:MIME-Version:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=btIgjdx+Vyw9LqnSvLyEoUQIWMyd1/L33f2W9hlshdr7xZwyejCYJzEo74AwzoRhD 2ywed6+H6aBsiLgje84ayIw7X8/ZYTGy+Nr6Qzfd4SHgtxa26AgxI4q4K3pDdaMzl3 4OVFGM4e/cSn7UpTByiwOuFOjuOzHaemv28tR8vs= 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 5935B21F8BDC for ; Fri, 4 Nov 2011 09:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 IYv7wKOFA6hE for ; Fri, 4 Nov 2011 09:54:08 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id C718821F8BA2 for ; Fri, 4 Nov 2011 09:54:08 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id pA4Gs6lt005553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 4 Nov 2011 11:54:06 -0500 (CDT) Received: from hal.8950aaa.com (phil.aaa.lucent.com [135.140.160.4]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pA4Gs5QL010664 for ; Fri, 4 Nov 2011 11:54:06 -0500 Received: from [192.168.0.34] (pinon.8950aaa.com [192.168.0.34]) by hal.8950aaa.com (Postfix) with ESMTP id A91E32A5D for ; Fri, 4 Nov 2011 09:54:05 -0700 (PDT) Message-ID: <4EB418AD.3010801@alcatel-lucent.com> Date: Fri, 04 Nov 2011 09:54:05 -0700 From: Mike Bean User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: radext@ietf.org X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: [radext] Acct-Status-Type values and custom accounting messages 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: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Curious to know if there are any current drafts to allocate additional values to Acct-Status-Type. I have a use case where I would like to proxy accounting records to a Lawful Intercept server using RADIUS accounting messages. In addition to standard account records I would like to provide synthetic accounting records as part of processing access-requests. Currently I need to provide three types of synthetic accounting records: Attempting, Accepted, and Rejected. My choices are to set Acct-Status-Type to one of the IANA approved values and send VSA to express these new types or steal three values for use with Acct-Status-Type. Third option would be to request that Other be a valid IANA assigned value and perhaps add new Acct-Status-Type-Name to allow for custom types without use of VSA. Just wanted to know if there was something in the works or if someone has had a similar requirement for custom accounting records. Thanks, Mike -- Michael Bean (Mike) Alcatel-Lucent AAA Product Group 3461 Robin Ln, Ste 1 Cameron Park, CA 95682 Email: Michael.Bean@alcatel-lucent.com Phone: 1 530 672 7577 Fax: 1 530 676 3442 _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From Michael.Bean@alcatel-lucent.com Fri Nov 4 09:54:09 2011 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 5935B21F8BDC for ; Fri, 4 Nov 2011 09:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 IYv7wKOFA6hE for ; Fri, 4 Nov 2011 09:54:08 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id C718821F8BA2 for ; Fri, 4 Nov 2011 09:54:08 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id pA4Gs6lt005553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 4 Nov 2011 11:54:06 -0500 (CDT) Received: from hal.8950aaa.com (phil.aaa.lucent.com [135.140.160.4]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pA4Gs5QL010664 for ; Fri, 4 Nov 2011 11:54:06 -0500 Received: from [192.168.0.34] (pinon.8950aaa.com [192.168.0.34]) by hal.8950aaa.com (Postfix) with ESMTP id A91E32A5D for ; Fri, 4 Nov 2011 09:54:05 -0700 (PDT) Message-ID: <4EB418AD.3010801@alcatel-lucent.com> Date: Fri, 04 Nov 2011 09:54:05 -0700 From: Mike Bean User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: radext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: [radext] Acct-Status-Type values and custom accounting messages 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, 04 Nov 2011 16:54:09 -0000 Curious to know if there are any current drafts to allocate additional values to Acct-Status-Type. I have a use case where I would like to proxy accounting records to a Lawful Intercept server using RADIUS accounting messages. In addition to standard account records I would like to provide synthetic accounting records as part of processing access-requests. Currently I need to provide three types of synthetic accounting records: Attempting, Accepted, and Rejected. My choices are to set Acct-Status-Type to one of the IANA approved values and send VSA to express these new types or steal three values for use with Acct-Status-Type. Third option would be to request that Other be a valid IANA assigned value and perhaps add new Acct-Status-Type-Name to allow for custom types without use of VSA. Just wanted to know if there was something in the works or if someone has had a similar requirement for custom accounting records. Thanks, Mike -- Michael Bean (Mike) Alcatel-Lucent AAA Product Group 3461 Robin Ln, Ste 1 Cameron Park, CA 95682 Email: Michael.Bean@alcatel-lucent.com Phone: 1 530 672 7577 Fax: 1 530 676 3442 From radext-bounces@ietf.org Fri Nov 4 10:25:12 2011 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 349B811E808E; Fri, 4 Nov 2011 10:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320427512; bh=n1B7ieHInXCRUBrbo1b8sR0/p8wBG/2CqTyFstKxjuI=; h=From:To:Date:Message-ID:MIME-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=YulxY7HFJeYWvrvKf26tuMG1sUa07zZZIkA8B9eIhODD33K7DqiqYCHS1Jb1jRd7z BwBJ3uLq1cEoty3Oa/Wwcaw26uckDSXvMMk+SBP7WKXpPrluUIX6UlBn2qErdbydDt mviF7ZZWZ9vFx6mIgwG157UodV5T6dtFE+zbcmb8= 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 1375611E808E for ; Fri, 4 Nov 2011 10:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.474 X-Spam-Level: X-Spam-Status: No, score=-106.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 tymH2ZjYkwGK for ; Fri, 4 Nov 2011 10:25:09 -0700 (PDT) Received: from g6t0186.atlanta.hp.com (g6t0186.atlanta.hp.com [15.193.32.63]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5F711E808C for ; Fri, 4 Nov 2011 10:25:09 -0700 (PDT) Received: from G4W3011G.americas.hpqcorp.net (g4w3011g.houston.hp.com [16.234.25.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0186.atlanta.hp.com (Postfix) with ESMTPS id D22D52C01A; Fri, 4 Nov 2011 17:25:08 +0000 (UTC) Received: from G5W0602.americas.hpqcorp.net (16.228.9.185) by G4W3011G.americas.hpqcorp.net (16.234.25.125) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 4 Nov 2011 17:23:47 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0602.americas.hpqcorp.net ([16.228.9.185]) with mapi; Fri, 4 Nov 2011 17:23:47 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Fri, 4 Nov 2011 17:23:45 +0000 Thread-Topic: IETF 82: RADEXT meeting agenda Thread-Index: AcybFmR3taX2FQ37QgO1m5lJLWLjCA== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD0B35D30@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "jouni.korhonen@nsn.com" Subject: [radext] IETF 82: RADEXT meeting agenda 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="===============8648954276013130185==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============8648954276013130185== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0B35D30GVW0671EXCame_" --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0B35D30GVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Below is first draft of IETF 82 agenda for RADEXT. If there are any additi= onal topics the group would like to see, please contact Jouni or myself. Thanks, MS RADEXT WG IETF 82 Agenda Chairs: Jouni Korhonen Mauricio Sanchez Jabber room: radext at jabber.ietf.org (Please join) Monday, November 14, 2011 0900 - 1130 Room 101D 9:00 - 09:20 AM, Preliminaries (20 minutes) Audio/Video & Remote Presentation Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status IPv6 items (15 minutes) 9:20 - 9:35 AM RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec (15 = minutes) http://tools.ietf.org/html/draft-ietf-radext-ipv6-access Enhancement items (45 minutes) 9:35 - 9:50 AM RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh= (15 minutes) http://tools.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01.txt 9:50 - 10:05 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (15 = minutes) http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt 10:05 - 10:20 AM RADIUS Protocol Extensions, Alan DeKok (15 minutes) http://tools.ietf.org/html/draft-ietf-radext-radius-extensions 10:20 - 10:35 AM Network Access Identifier, Alan DeKok (15 minutes) http://tools.ietf.org/html/draft-dekok-radext-nai-01 Discussion and Wrap-up (35 minutes) 10:35 - 10:55 AM Discussion (20 minutes) 10:55 - 11:10 AM Next Steps: WG Chairs & ADs (15 minutes) WG Goals/Milestones status --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0B35D30GVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Below is first= draft of IETF 82 agenda for RADEXT.  If there are any additional topi= cs the group would like to see, please contact Jouni or myself.<= /p>

 =

Thanks,

MS =

 

 

 

= RADEXT WG IETF 82 Agenda

 

Chairs:

Jouni= Korhonen <jouni.korhonen at nsn.com>

Mauricio Sanchez <mauricio.sanchez at hp.com>

 

Jabber room: rade= xt at jabber.ietf.org (Please join)

 

Monday, November 14, 2011<= /p>

0900 - 1130

Roo= m 101D

 

9:00 - 09:20 AM, Preliminaries (20 minutes)

Audio/Video & Remote Presentation Debugging

=

Note Well

Note Take= rs

Jabber scribe

Agenda bash

Document Status=

 

 

IPv6 items (15 minutes)

9:20 - 9:35 AM RADIUS Attributes for IPv6 Acce= ss Networks, Wojcieh Dec (15 minutes)

ht= tp://tools.ietf.org/html/draft-ietf-radext-ipv6-access

 

 <= /p>

Enhancement items (45 minutes)

9:35 - 9:50 AM RADIUS Accounting Extensions of Traffic Stati= stics, Leaf Yeh (15 minutes)

http://tool= s.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01.txt

=

 

9:50 - 10:05= AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (15 minutes)

http://tools.ietf.org/id/draft-aboba-radext= -wlan-15.txt

 

10:05 - 10:20 AM RADIUS Protocol Extensions, Alan DeKok (15 = minutes)

http://tools.ietf.org/html/draf= t-ietf-radext-radius-extensions

&nb= sp;

10:20 - 10:35 AM Network Access Identifie= r, Alan DeKok (15 minutes)

http://tools.= ietf.org/html/draft-dekok-radext-nai-01

=  

 

Discussion and Wrap-up (35 minutes)

10:35 – 10:55 AM Discussion (20 minutes)

 

10:55 - 11:10 AM Nex= t Steps: WG Chairs & ADs (15 minutes)

WG Goals/Milestones status

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0B35D30GVW0671EXCame_-- --===============8648954276013130185== 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 --===============8648954276013130185==-- From mauricio.sanchez@hp.com Fri Nov 4 10:25:11 2011 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 1375611E808E for ; Fri, 4 Nov 2011 10:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.474 X-Spam-Level: X-Spam-Status: No, score=-106.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 tymH2ZjYkwGK for ; Fri, 4 Nov 2011 10:25:09 -0700 (PDT) Received: from g6t0186.atlanta.hp.com (g6t0186.atlanta.hp.com [15.193.32.63]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5F711E808C for ; Fri, 4 Nov 2011 10:25:09 -0700 (PDT) Received: from G4W3011G.americas.hpqcorp.net (g4w3011g.houston.hp.com [16.234.25.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0186.atlanta.hp.com (Postfix) with ESMTPS id D22D52C01A; Fri, 4 Nov 2011 17:25:08 +0000 (UTC) Received: from G5W0602.americas.hpqcorp.net (16.228.9.185) by G4W3011G.americas.hpqcorp.net (16.234.25.125) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 4 Nov 2011 17:23:47 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0602.americas.hpqcorp.net ([16.228.9.185]) with mapi; Fri, 4 Nov 2011 17:23:47 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Fri, 4 Nov 2011 17:23:45 +0000 Thread-Topic: IETF 82: RADEXT meeting agenda Thread-Index: AcybFmR3taX2FQ37QgO1m5lJLWLjCA== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD0B35D30@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0B35D30GVW0671EXCame_" MIME-Version: 1.0 Cc: "jouni.korhonen@nsn.com" Subject: [radext] IETF 82: RADEXT meeting agenda 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, 04 Nov 2011 17:25:11 -0000 --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0B35D30GVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Below is first draft of IETF 82 agenda for RADEXT. If there are any additi= onal topics the group would like to see, please contact Jouni or myself. Thanks, MS RADEXT WG IETF 82 Agenda Chairs: Jouni Korhonen Mauricio Sanchez Jabber room: radext at jabber.ietf.org (Please join) Monday, November 14, 2011 0900 - 1130 Room 101D 9:00 - 09:20 AM, Preliminaries (20 minutes) Audio/Video & Remote Presentation Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status IPv6 items (15 minutes) 9:20 - 9:35 AM RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec (15 = minutes) http://tools.ietf.org/html/draft-ietf-radext-ipv6-access Enhancement items (45 minutes) 9:35 - 9:50 AM RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh= (15 minutes) http://tools.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01.txt 9:50 - 10:05 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (15 = minutes) http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt 10:05 - 10:20 AM RADIUS Protocol Extensions, Alan DeKok (15 minutes) http://tools.ietf.org/html/draft-ietf-radext-radius-extensions 10:20 - 10:35 AM Network Access Identifier, Alan DeKok (15 minutes) http://tools.ietf.org/html/draft-dekok-radext-nai-01 Discussion and Wrap-up (35 minutes) 10:35 - 10:55 AM Discussion (20 minutes) 10:55 - 11:10 AM Next Steps: WG Chairs & ADs (15 minutes) WG Goals/Milestones status --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0B35D30GVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Below is first= draft of IETF 82 agenda for RADEXT.  If there are any additional topi= cs the group would like to see, please contact Jouni or myself.<= /p>

 =

Thanks,

MS =

 

 

 

= RADEXT WG IETF 82 Agenda

 

Chairs:

Jouni= Korhonen <jouni.korhonen at nsn.com>

Mauricio Sanchez <mauricio.sanchez at hp.com>

 

Jabber room: rade= xt at jabber.ietf.org (Please join)

 

Monday, November 14, 2011<= /p>

0900 - 1130

Roo= m 101D

 

9:00 - 09:20 AM, Preliminaries (20 minutes)

Audio/Video & Remote Presentation Debugging

=

Note Well

Note Take= rs

Jabber scribe

Agenda bash

Document Status=

 

 

IPv6 items (15 minutes)

9:20 - 9:35 AM RADIUS Attributes for IPv6 Acce= ss Networks, Wojcieh Dec (15 minutes)

ht= tp://tools.ietf.org/html/draft-ietf-radext-ipv6-access

 

 <= /p>

Enhancement items (45 minutes)

9:35 - 9:50 AM RADIUS Accounting Extensions of Traffic Stati= stics, Leaf Yeh (15 minutes)

http://tool= s.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01.txt

=

 

9:50 - 10:05= AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (15 minutes)

http://tools.ietf.org/id/draft-aboba-radext= -wlan-15.txt

 

10:05 - 10:20 AM RADIUS Protocol Extensions, Alan DeKok (15 = minutes)

http://tools.ietf.org/html/draf= t-ietf-radext-radius-extensions

&nb= sp;

10:20 - 10:35 AM Network Access Identifie= r, Alan DeKok (15 minutes)

http://tools.= ietf.org/html/draft-dekok-radext-nai-01

=  

 

Discussion and Wrap-up (35 minutes)

10:35 – 10:55 AM Discussion (20 minutes)

 

10:55 - 11:10 AM Nex= t Steps: WG Chairs & ADs (15 minutes)

WG Goals/Milestones status

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0B35D30GVW0671EXCame_-- From bernard_aboba@hotmail.com Mon Nov 7 09:53:16 2011 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 EC5041F0C38 for ; Mon, 7 Nov 2011 09:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.170, 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 vILk8d8Xi0ue for ; Mon, 7 Nov 2011 09:53:16 -0800 (PST) Received: from blu0-omc2-s18.blu0.hotmail.com (blu0-omc2-s18.blu0.hotmail.com [65.55.111.93]) by ietfa.amsl.com (Postfix) with ESMTP id EB3C021F8B37 for ; Mon, 7 Nov 2011 09:53:15 -0800 (PST) Received: from BLU152-W24 ([65.55.111.72]) by blu0-omc2-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Nov 2011 09:53:15 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_78e927be-ff97-410e-971e-e94e9bc1fa58_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Alan DeKok , Date: Mon, 7 Nov 2011 09:53:15 -0800 Importance: Normal In-Reply-To: <4EB7FB73.8010609@deployingradius.com> References: <4EB0F497.1000104@deployingradius.com> <4EB3B3CD.1020009@deployingradius.com> ,<4EB7FB73.8010609@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 07 Nov 2011 17:53:15.0742 (UTC) FILETIME=[201DAFE0:01CC9D76] Cc: josh.howlett@ja.net, "dromasca@avaya.com" , abfab-chairs@tools.ietf.org, "radext-chairs@tools.ietf.org" , radext@ietf.org Subject: Re: [radext] ABFAB does not specify any changes to RADIUS 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: Mon, 07 Nov 2011 17:53:17 -0000 --_78e927be-ff97-410e-971e-e94e9bc1fa58_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As an author of RFC 4282=2C I'd like to apologize for the mess that deeply = flawed document has created. If there is any way to avoid referencing it=2C that would be good. > Date: Mon=2C 7 Nov 2011 16:38:27 +0100 > From: aland@deployingradius.com > To: hartmans@painless-security.com > CC: bernard_aboba@hotmail.com=3B abfab-chairs@tools.ietf.org=3B radext-ch= airs@tools.ietf.org=3B dromasca@avaya.com=3B josh.howlett@ja.net > Subject: Re: ABFAB does not specify any changes to RADIUS >=20 > Sam Hartman wrote: > > Alan=2C I just read Klaas's forward of the radext list in which you cla= im > > that abfab documents specify an alternate use of the RADIUS username > > attribute. I now understand why you're so concerned about the NAI issu= e > > and ABFAB. >=20 > Thanks. >=20 > > However=2C I believe that what is really going on here is that we > > introduced a bug in the most recent version of draft-ietf-abfab-aaa-sam= l > > that was quickly pointed out on the list > > and that will be quickly corrected. >=20 > OK. My only concern is avoiding dependency on RFC 4282=2C for reasons > I'll outline below. >=20 > > section 4.2 of draft-ietf-abfab-aaa-saml does in fact describe the use > > of a NAI in the RADIUS user-name attribute. I think we've already > > agreed that section should not repeat parts of the RADIUS or RADIUS ove= r > > EAP binding. >=20 > Yes. My reading of that section is that the NAI format MUST follow > RFC 4282. I object to that=2C as 4282 requires punycoding of i18n NAIs= =2C > which *no one* does. >=20 > > We asked Josh to be a lot more detailed in draft-ietf-abfab-aaa-saml. H= e > > was. Now we need to scale back in order to avoid incorrectly stating > > what other specs like RADIUS and RADIUS over EAP already say. This is > > just a bug in a draft introduced very recently=2C not any plan to creat= e > > an alternate RADIUS. >=20 > OK. My $0.02 is that the reference to 4282 should be removed from > draft-ietf-abfab-aaa-saml. Even on other grounds=2C section 4.2 item (1) > of that document is wrong. It starts off with "The RADIUS client"=2C > followed by a description of NAIs=2C and routing packets. RADIUS clients > don't route packets. >=20 > Instead=2C (and this is more directed at Josh)=2C that text could be cu= t > to the first sentence and a half: >=20 > 1. The RADIUS client=2C acting as a SAML requester=2C transmits a SAM= L > request element within a RADIUS Access-Request message. This > message MUST include a single instance of the RADIUS User-Name > attribute. >=20 > Routing RADIUS packets based on NAI is *completely* outside of the > scope of RADIUS clients=2C and largely outside of the scope of the SAML > document. >=20 > > There is a document that discusses NAIs but is more stable: > >=20 > > Section 3.1 of wdoes talk about a name > > format. It describes how the components of this name format map to > > NAIs--in effect it describes how one could convert a NAI into a GSS-EAP > > mechanism name. >=20 > OK. >=20 > > However=2C draft-ietf-abfab-gss-eap never says that a NAI is sent in th= e > > RADIUS username attribute. In fact it doesn't refer to the RADIUS > > username attribute at all=2C because the existing RADIUS specifications > > already discuss that attribute. >=20 > The problem is that RFC 4282 doesn't really refer to RADIUS=2C either. > The only thing it says about RADIUS is: "NAIs are often transported in > the User-Name attribute ..." >=20 > RFC 4282 is an NAI specification. So referring to it in > draft-ietf-abfab-gss-eap means that implementors of the draft *must* > follow the requirements of 4282. These requirements are incompatible > with *all known* EAP and RADIUS implementations. >=20 > This isn't a RADIUS issue. The issue is that 4282 is wrong. The > 4282bis draft explains this in detail. >=20 > Alan DeKok. = --_78e927be-ff97-410e-971e-e94e9bc1fa58_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
As an author of RFC 4282=2C I'd like to apologize for the mess that deeply = flawed document has created.

If there is any way to avoid referencin= g it=2C that would be good.

>=3B Date: Mon=2C 7 Nov 2011 16:3= 8:27 +0100
>=3B From: aland@deployingradius.com
>=3B To: hartmans= @painless-security.com
>=3B CC: bernard_aboba@hotmail.com=3B abfab-cha= irs@tools.ietf.org=3B radext-chairs@tools.ietf.org=3B dromasca@avaya.com=3B= josh.howlett@ja.net
>=3B Subject: Re: ABFAB does not specify any chan= ges to RADIUS
>=3B
>=3B Sam Hartman wrote:
>=3B >=3B Alan= =2C I just read Klaas's forward of the radext list in which you claim
&g= t=3B >=3B that abfab documents specify an alternate use of the RADIUS use= rname
>=3B >=3B attribute. I now understand why you're so concerned= about the NAI issue
>=3B >=3B and ABFAB.
>=3B
>=3B Tha= nks.
>=3B
>=3B >=3B However=2C I believe that what is really g= oing on here is that we
>=3B >=3B introduced a bug in the most recen= t version of draft-ietf-abfab-aaa-saml
>=3B >=3B that was quickly po= inted out on the list
>=3B >=3B and that will be quickly corrected.<= br>>=3B
>=3B OK. My only concern is avoiding dependency on RFC 4= 282=2C for reasons
>=3B I'll outline below.
>=3B
>=3B >= =3B section 4.2 of draft-ietf-abfab-aaa-saml does in fact describe the use=
>=3B >=3B of a NAI in the RADIUS user-name attribute. I think we'v= e already
>=3B >=3B agreed that section should not repeat parts of t= he RADIUS or RADIUS over
>=3B >=3B EAP binding.
>=3B
>=3B= Yes. My reading of that section is that the NAI format MUST follow
&= gt=3B RFC 4282. I object to that=2C as 4282 requires punycoding of i18n NA= Is=2C
>=3B which *no one* does.
>=3B
>=3B >=3B We asked J= osh to be a lot more detailed in draft-ietf-abfab-aaa-saml. He
>=3B &g= t=3B was. Now we need to scale back in order to avoid incorrectly stating>=3B >=3B what other specs like RADIUS and RADIUS over EAP already sa= y. This is
>=3B >=3B just a bug in a draft introduced very recently= =2C not any plan to create
>=3B >=3B an alternate RADIUS.
>=3B =
>=3B OK. My $0.02 is that the reference to 4282 should be removed = from
>=3B draft-ietf-abfab-aaa-saml. Even on other grounds=2C section= 4.2 item (1)
>=3B of that document is wrong. It starts off with "The= RADIUS client"=2C
>=3B followed by a description of NAIs=2C and routi= ng packets. RADIUS clients
>=3B don't route packets.
>=3B
&g= t=3B Instead=2C (and this is more directed at Josh)=2C that text could be= cut
>=3B to the first sentence and a half:
>=3B
>=3B 1.= The RADIUS client=2C acting as a SAML requester=2C transmits a SAML
&g= t=3B request element within a RADIUS Access-Request message. This>=3B message MUST include a single instance of the RADIUS User-N= ame
>=3B attribute.
>=3B
>=3B Routing RADIUS packe= ts based on NAI is *completely* outside of the
>=3B scope of RADIUS cl= ients=2C and largely outside of the scope of the SAML
>=3B document.>=3B
>=3B >=3B There is a document that discusses NAIs but is m= ore stable:
>=3B >=3B
>=3B >=3B Section 3.1 of wdoes talk ab= out a name
>=3B >=3B format. It describes how the components of this= name format map to
>=3B >=3B NAIs--in effect it describes how one c= ould convert a NAI into a GSS-EAP
>=3B >=3B mechanism name.
>= =3B
>=3B OK.
>=3B
>=3B >=3B However=2C draft-ietf-abfa= b-gss-eap never says that a NAI is sent in the
>=3B >=3B RADIUS user= name attribute. In fact it doesn't refer to the RADIUS
>=3B >=3B us= ername attribute at all=2C because the existing RADIUS specifications
&g= t=3B >=3B already discuss that attribute.
>=3B
>=3B The prob= lem is that RFC 4282 doesn't really refer to RADIUS=2C either.
>=3B Th= e only thing it says about RADIUS is: "NAIs are often transported in
>= =3B the User-Name attribute ..."
>=3B
>=3B RFC 4282 is an NAI = specification. So referring to it in
>=3B draft-ietf-abfab-gss-eap me= ans that implementors of the draft *must*
>=3B follow the requirements= of 4282. These requirements are incompatible
>=3B with *all known* E= AP and RADIUS implementations.
>=3B
>=3B This isn't a RADIUS i= ssue. The issue is that 4282 is wrong. The
>=3B 4282bis draft explai= ns this in detail.
>=3B
>=3B Alan DeKok.
=
= --_78e927be-ff97-410e-971e-e94e9bc1fa58_-- From radext-bounces@ietf.org Mon Nov 7 09:53:18 2011 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 797361F0C38; Mon, 7 Nov 2011 09:53:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320688398; bh=4oyO4VFAQY7YiOWXGtvElQiBTNoxAYgBNnllAvRVkFU=; h=Message-ID:From:To:Date:In-Reply-To:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=man+ayybp/Zz4y3U8dBtt7ZS0SpgrWh2z3zfcs8mSJS17JLTygCPuzZT/iCTKcmzL g/jHT6v9eiajpgW4NzMMxs1BsU/NDWqL+u7kbfV7prXCr5dKiFlVKldoidiPXyCVGa 3m03SbxMsqcsCOrYXsd54SXAio3tV8SGz1kpqP9k= 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 EC5041F0C38 for ; Mon, 7 Nov 2011 09:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.170, 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 vILk8d8Xi0ue for ; Mon, 7 Nov 2011 09:53:16 -0800 (PST) Received: from blu0-omc2-s18.blu0.hotmail.com (blu0-omc2-s18.blu0.hotmail.com [65.55.111.93]) by ietfa.amsl.com (Postfix) with ESMTP id EB3C021F8B37 for ; Mon, 7 Nov 2011 09:53:15 -0800 (PST) Received: from BLU152-W24 ([65.55.111.72]) by blu0-omc2-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Nov 2011 09:53:15 -0800 Message-ID: X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Alan DeKok , Date: Mon, 7 Nov 2011 09:53:15 -0800 Importance: Normal In-Reply-To: <4EB7FB73.8010609@deployingradius.com> References: <4EB0F497.1000104@deployingradius.com> <4EB3B3CD.1020009@deployingradius.com> ,<4EB7FB73.8010609@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 07 Nov 2011 17:53:15.0742 (UTC) FILETIME=[201DAFE0:01CC9D76] Cc: josh.howlett@ja.net, "dromasca@avaya.com" , abfab-chairs@tools.ietf.org, "radext-chairs@tools.ietf.org" , radext@ietf.org Subject: Re: [radext] ABFAB does not specify any changes to RADIUS 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="===============5427957154828891604==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============5427957154828891604== Content-Type: multipart/alternative; boundary="_78e927be-ff97-410e-971e-e94e9bc1fa58_" --_78e927be-ff97-410e-971e-e94e9bc1fa58_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As an author of RFC 4282=2C I'd like to apologize for the mess that deeply = flawed document has created. If there is any way to avoid referencing it=2C that would be good. > Date: Mon=2C 7 Nov 2011 16:38:27 +0100 > From: aland@deployingradius.com > To: hartmans@painless-security.com > CC: bernard_aboba@hotmail.com=3B abfab-chairs@tools.ietf.org=3B radext-ch= airs@tools.ietf.org=3B dromasca@avaya.com=3B josh.howlett@ja.net > Subject: Re: ABFAB does not specify any changes to RADIUS >=20 > Sam Hartman wrote: > > Alan=2C I just read Klaas's forward of the radext list in which you cla= im > > that abfab documents specify an alternate use of the RADIUS username > > attribute. I now understand why you're so concerned about the NAI issu= e > > and ABFAB. >=20 > Thanks. >=20 > > However=2C I believe that what is really going on here is that we > > introduced a bug in the most recent version of draft-ietf-abfab-aaa-sam= l > > that was quickly pointed out on the list > > and that will be quickly corrected. >=20 > OK. My only concern is avoiding dependency on RFC 4282=2C for reasons > I'll outline below. >=20 > > section 4.2 of draft-ietf-abfab-aaa-saml does in fact describe the use > > of a NAI in the RADIUS user-name attribute. I think we've already > > agreed that section should not repeat parts of the RADIUS or RADIUS ove= r > > EAP binding. >=20 > Yes. My reading of that section is that the NAI format MUST follow > RFC 4282. I object to that=2C as 4282 requires punycoding of i18n NAIs= =2C > which *no one* does. >=20 > > We asked Josh to be a lot more detailed in draft-ietf-abfab-aaa-saml. H= e > > was. Now we need to scale back in order to avoid incorrectly stating > > what other specs like RADIUS and RADIUS over EAP already say. This is > > just a bug in a draft introduced very recently=2C not any plan to creat= e > > an alternate RADIUS. >=20 > OK. My $0.02 is that the reference to 4282 should be removed from > draft-ietf-abfab-aaa-saml. Even on other grounds=2C section 4.2 item (1) > of that document is wrong. It starts off with "The RADIUS client"=2C > followed by a description of NAIs=2C and routing packets. RADIUS clients > don't route packets. >=20 > Instead=2C (and this is more directed at Josh)=2C that text could be cu= t > to the first sentence and a half: >=20 > 1. The RADIUS client=2C acting as a SAML requester=2C transmits a SAM= L > request element within a RADIUS Access-Request message. This > message MUST include a single instance of the RADIUS User-Name > attribute. >=20 > Routing RADIUS packets based on NAI is *completely* outside of the > scope of RADIUS clients=2C and largely outside of the scope of the SAML > document. >=20 > > There is a document that discusses NAIs but is more stable: > >=20 > > Section 3.1 of wdoes talk about a name > > format. It describes how the components of this name format map to > > NAIs--in effect it describes how one could convert a NAI into a GSS-EAP > > mechanism name. >=20 > OK. >=20 > > However=2C draft-ietf-abfab-gss-eap never says that a NAI is sent in th= e > > RADIUS username attribute. In fact it doesn't refer to the RADIUS > > username attribute at all=2C because the existing RADIUS specifications > > already discuss that attribute. >=20 > The problem is that RFC 4282 doesn't really refer to RADIUS=2C either. > The only thing it says about RADIUS is: "NAIs are often transported in > the User-Name attribute ..." >=20 > RFC 4282 is an NAI specification. So referring to it in > draft-ietf-abfab-gss-eap means that implementors of the draft *must* > follow the requirements of 4282. These requirements are incompatible > with *all known* EAP and RADIUS implementations. >=20 > This isn't a RADIUS issue. The issue is that 4282 is wrong. The > 4282bis draft explains this in detail. >=20 > Alan DeKok. = --_78e927be-ff97-410e-971e-e94e9bc1fa58_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
As an author of RFC 4282=2C I'd like to apologize for the mess that deeply = flawed document has created.

If there is any way to avoid referencin= g it=2C that would be good.

>=3B Date: Mon=2C 7 Nov 2011 16:3= 8:27 +0100
>=3B From: aland@deployingradius.com
>=3B To: hartmans= @painless-security.com
>=3B CC: bernard_aboba@hotmail.com=3B abfab-cha= irs@tools.ietf.org=3B radext-chairs@tools.ietf.org=3B dromasca@avaya.com=3B= josh.howlett@ja.net
>=3B Subject: Re: ABFAB does not specify any chan= ges to RADIUS
>=3B
>=3B Sam Hartman wrote:
>=3B >=3B Alan= =2C I just read Klaas's forward of the radext list in which you claim
&g= t=3B >=3B that abfab documents specify an alternate use of the RADIUS use= rname
>=3B >=3B attribute. I now understand why you're so concerned= about the NAI issue
>=3B >=3B and ABFAB.
>=3B
>=3B Tha= nks.
>=3B
>=3B >=3B However=2C I believe that what is really g= oing on here is that we
>=3B >=3B introduced a bug in the most recen= t version of draft-ietf-abfab-aaa-saml
>=3B >=3B that was quickly po= inted out on the list
>=3B >=3B and that will be quickly corrected.<= br>>=3B
>=3B OK. My only concern is avoiding dependency on RFC 4= 282=2C for reasons
>=3B I'll outline below.
>=3B
>=3B >= =3B section 4.2 of draft-ietf-abfab-aaa-saml does in fact describe the use=
>=3B >=3B of a NAI in the RADIUS user-name attribute. I think we'v= e already
>=3B >=3B agreed that section should not repeat parts of t= he RADIUS or RADIUS over
>=3B >=3B EAP binding.
>=3B
>=3B= Yes. My reading of that section is that the NAI format MUST follow
&= gt=3B RFC 4282. I object to that=2C as 4282 requires punycoding of i18n NA= Is=2C
>=3B which *no one* does.
>=3B
>=3B >=3B We asked J= osh to be a lot more detailed in draft-ietf-abfab-aaa-saml. He
>=3B &g= t=3B was. Now we need to scale back in order to avoid incorrectly stating>=3B >=3B what other specs like RADIUS and RADIUS over EAP already sa= y. This is
>=3B >=3B just a bug in a draft introduced very recently= =2C not any plan to create
>=3B >=3B an alternate RADIUS.
>=3B =
>=3B OK. My $0.02 is that the reference to 4282 should be removed = from
>=3B draft-ietf-abfab-aaa-saml. Even on other grounds=2C section= 4.2 item (1)
>=3B of that document is wrong. It starts off with "The= RADIUS client"=2C
>=3B followed by a description of NAIs=2C and routi= ng packets. RADIUS clients
>=3B don't route packets.
>=3B
&g= t=3B Instead=2C (and this is more directed at Josh)=2C that text could be= cut
>=3B to the first sentence and a half:
>=3B
>=3B 1.= The RADIUS client=2C acting as a SAML requester=2C transmits a SAML
&g= t=3B request element within a RADIUS Access-Request message. This>=3B message MUST include a single instance of the RADIUS User-N= ame
>=3B attribute.
>=3B
>=3B Routing RADIUS packe= ts based on NAI is *completely* outside of the
>=3B scope of RADIUS cl= ients=2C and largely outside of the scope of the SAML
>=3B document.>=3B
>=3B >=3B There is a document that discusses NAIs but is m= ore stable:
>=3B >=3B
>=3B >=3B Section 3.1 of wdoes talk ab= out a name
>=3B >=3B format. It describes how the components of this= name format map to
>=3B >=3B NAIs--in effect it describes how one c= ould convert a NAI into a GSS-EAP
>=3B >=3B mechanism name.
>= =3B
>=3B OK.
>=3B
>=3B >=3B However=2C draft-ietf-abfa= b-gss-eap never says that a NAI is sent in the
>=3B >=3B RADIUS user= name attribute. In fact it doesn't refer to the RADIUS
>=3B >=3B us= ername attribute at all=2C because the existing RADIUS specifications
&g= t=3B >=3B already discuss that attribute.
>=3B
>=3B The prob= lem is that RFC 4282 doesn't really refer to RADIUS=2C either.
>=3B Th= e only thing it says about RADIUS is: "NAIs are often transported in
>= =3B the User-Name attribute ..."
>=3B
>=3B RFC 4282 is an NAI = specification. So referring to it in
>=3B draft-ietf-abfab-gss-eap me= ans that implementors of the draft *must*
>=3B follow the requirements= of 4282. These requirements are incompatible
>=3B with *all known* E= AP and RADIUS implementations.
>=3B
>=3B This isn't a RADIUS i= ssue. The issue is that 4282 is wrong. The
>=3B 4282bis draft explai= ns this in detail.
>=3B
>=3B Alan DeKok.
=
= --_78e927be-ff97-410e-971e-e94e9bc1fa58_-- --===============5427957154828891604== 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 --===============5427957154828891604==-- From hartmans@painless-security.com Mon Nov 7 11:14:33 2011 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 8EE4E21F8B66 for ; Mon, 7 Nov 2011 11:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 2XL8zgfHx3xN for ; Mon, 7 Nov 2011 11:14:33 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 27C3521F8B62 for ; Mon, 7 Nov 2011 11:14:33 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 1E5C6201CB; Mon, 7 Nov 2011 14:15:22 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C5AA2435A; Mon, 7 Nov 2011 14:14:21 -0500 (EST) From: Sam Hartman To: Bernard Aboba References: <4EB0F497.1000104@deployingradius.com> <4EB3B3CD.1020009@deployingradius.com> <4EB7FB73.8010609@deployingradius.com> Date: Mon, 07 Nov 2011 14:14:21 -0500 In-Reply-To: (Bernard Aboba's message of "Mon, 7 Nov 2011 09:53:15 -0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: josh.howlett@ja.net, radext@ietf.org, "radext-chairs@tools.ietf.org" , Alan DeKok , "dromasca@avaya.com" , abfab-chairs@tools.ietf.org Subject: Re: [radext] ABFAB does not specify any changes to RADIUS 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: Mon, 07 Nov 2011 19:14:33 -0000 The only thing we need is a string with human semantics similar to a NAI that has a realm portion after an at-sign and some portion (possibly empty) before the at-sign. I actually think 4282 is a fine reference for the basic concept behind a NAI so long as we are not talking about any of the encoding or string processing rules. --Sam From radext-bounces@ietf.org Mon Nov 7 11:14:35 2011 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 2517921F8B65; Mon, 7 Nov 2011 11:14:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320693275; bh=0jfPTeM/e7GZTnF06oHVVAX1dt2hyouU+HpT+AqTiIo=; h=From:To:References:Date:In-Reply-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=V4YuNEPEw9Vv6v3RT3BB+4ZemhQWewsGWvItguEorwkrr1qtlUsCyF28ZvyrmTphE CZQefiilhMhQxj+kQ3WIx4qrEQtL3cDsPgbq6YLOIPEAO6d7Cs30VtHNRZ00B0zNpM uFaBF/I2y2Gi2AUKZcYuEZSw3sv9Z3+w1Vn8aI5s= 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 8EE4E21F8B66 for ; Mon, 7 Nov 2011 11:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 2XL8zgfHx3xN for ; Mon, 7 Nov 2011 11:14:33 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 27C3521F8B62 for ; Mon, 7 Nov 2011 11:14:33 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 1E5C6201CB; Mon, 7 Nov 2011 14:15:22 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C5AA2435A; Mon, 7 Nov 2011 14:14:21 -0500 (EST) From: Sam Hartman To: Bernard Aboba References: <4EB0F497.1000104@deployingradius.com> <4EB3B3CD.1020009@deployingradius.com> <4EB7FB73.8010609@deployingradius.com> Date: Mon, 07 Nov 2011 14:14:21 -0500 In-Reply-To: (Bernard Aboba's message of "Mon, 7 Nov 2011 09:53:15 -0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Cc: josh.howlett@ja.net, radext@ietf.org, "radext-chairs@tools.ietf.org" , Alan DeKok , "dromasca@avaya.com" , abfab-chairs@tools.ietf.org Subject: Re: [radext] ABFAB does not specify any changes to RADIUS 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 only thing we need is a string with human semantics similar to a NAI that has a realm portion after an at-sign and some portion (possibly empty) before the at-sign. I actually think 4282 is a fine reference for the basic concept behind a NAI so long as we are not talking about any of the encoding or string processing rules. --Sam _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Mon Nov 7 11:47:52 2011 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 147CD21F8AF5; Mon, 7 Nov 2011 11:47:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320695272; bh=pcUuP3Q9G2DD1VJxhHeXmeSwO8aNrPu370mfa06OdK4=; 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=Mwz2bl62H2Ku+wp10jNM4rPqFdDEbXZ+JJXREd04l1Cb6DtuH7SmiiGN54Gd3DpmT vn5vRV9oo6mhzZciIQlcQ8P7O3gseVRWCnJl5O9bwZSSWnNp0LRtLrbQbxXeGnCw8c isjKvYbJaoNDY+t3jmHzc7z7tHDFWotfNuT8vFfM= 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 ADF9E21F8AF5 for ; Mon, 7 Nov 2011 11:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 2iJiJcfOUvTi for ; Mon, 7 Nov 2011 11:47:50 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id DF59921F8AF2 for ; Mon, 7 Nov 2011 11:47:43 -0800 (PST) Message-ID: <4EB835C9.9060404@deployingradius.com> Date: Mon, 07 Nov 2011 20:47:21 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <4EB0F497.1000104@deployingradius.com> <4EB3B3CD.1020009@deployingradius.com> <4EB7FB73.8010609@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: josh.howlett@ja.net, radext@ietf.org, "radext-chairs@tools.ietf.org" , Bernard Aboba , "dromasca@avaya.com" , abfab-chairs@tools.ietf.org Subject: Re: [radext] ABFAB does not specify any changes to RADIUS 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 Sam Hartman wrote: > The only thing we need is a string with human semantics similar to a NAI > that has a realm portion after an at-sign and some portion (possibly > empty) before the at-sign. That's largely what the new NAI document proposes. > I actually think 4282 is a fine reference > for the basic concept behind a NAI so long as we are not talking about > any of the encoding or string processing rules. They're tied together, unfortunately. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Mon Nov 7 11:47:51 2011 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 ADF9E21F8AF5 for ; Mon, 7 Nov 2011 11:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 2iJiJcfOUvTi for ; Mon, 7 Nov 2011 11:47:50 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id DF59921F8AF2 for ; Mon, 7 Nov 2011 11:47:43 -0800 (PST) Message-ID: <4EB835C9.9060404@deployingradius.com> Date: Mon, 07 Nov 2011 20:47:21 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <4EB0F497.1000104@deployingradius.com> <4EB3B3CD.1020009@deployingradius.com> <4EB7FB73.8010609@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: josh.howlett@ja.net, radext@ietf.org, "radext-chairs@tools.ietf.org" , Bernard Aboba , "dromasca@avaya.com" , abfab-chairs@tools.ietf.org Subject: Re: [radext] ABFAB does not specify any changes to RADIUS 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: Mon, 07 Nov 2011 19:47:51 -0000 Sam Hartman wrote: > The only thing we need is a string with human semantics similar to a NAI > that has a realm portion after an at-sign and some portion (possibly > empty) before the at-sign. That's largely what the new NAI document proposes. > I actually think 4282 is a fine reference > for the basic concept behind a NAI so long as we are not talking about > any of the encoding or string processing rules. They're tied together, unfortunately. Alan DeKok. From radext-bounces@ietf.org Mon Nov 7 11:59:12 2011 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 011C51F0C38; Mon, 7 Nov 2011 11:59:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320695952; bh=9ZLOpjYllpnFOqZzGvNNln+5Y2RG0HeCLluHH4KtdUA=; h=From:To:References:Date:In-Reply-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=eb+g1Hc9nine8jWf9Vf7xVW1EP0knpTM0BRtcfHdOmzHhMoTJNhIpMqhrmzZ1rO5G ySKAOL4Oddo7/3ZAxHE2As1vh/M0UKam+jNPBQ0zTqdoYUp0dQfcZu/Jday+skXGkc 3FoAX+nBSbLmyuJgLmPPp9sdOCEJT3ysHIESYLvY= 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 4F46721F8B37 for ; Mon, 7 Nov 2011 11:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 alz0NAP2cFZD for ; Mon, 7 Nov 2011 11:59:11 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E75D021F87D3 for ; Mon, 7 Nov 2011 11:59:10 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D410F2019A; Mon, 7 Nov 2011 14:59:59 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7AECE435A; Mon, 7 Nov 2011 14:58:59 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <4EB0F497.1000104@deployingradius.com> <4EB3B3CD.1020009@deployingradius.com> <4EB7FB73.8010609@deployingradius.com> <4EB835C9.9060404@deployingradius.com> Date: Mon, 07 Nov 2011 14:58:59 -0500 In-Reply-To: <4EB835C9.9060404@deployingradius.com> (Alan DeKok's message of "Mon, 07 Nov 2011 20:47:21 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Cc: josh.howlett@ja.net, radext@ietf.org, "radext-chairs@tools.ietf.org" , Bernard Aboba , "dromasca@avaya.com" , abfab-chairs@tools.ietf.org Subject: Re: [radext] ABFAB does not specify any changes to RADIUS 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" == Alan DeKok writes: Alan> Sam Hartman wrote: >> The only thing we need is a string with human semantics similar >> to a NAI that has a realm portion after an at-sign and some >> portion (possibly empty) before the at-sign. Alan> That's largely what the new NAI document proposes. >> I actually think 4282 is a fine reference for the basic concept >> behind a NAI so long as we are not talking about any of the >> encoding or string processing rules. Alan> They're tied together, unfortunately. Give me a chance to try and specify what we mean without pulling in the string encoding. If I fail, we can just wrip out calling it a NAI completely or note that it's intended to be compatible in concept with the new NAI once published and use an informative reference. --Sam _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From hartmans@painless-security.com Mon Nov 7 11:59:11 2011 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 4F46721F8B37 for ; Mon, 7 Nov 2011 11:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 alz0NAP2cFZD for ; Mon, 7 Nov 2011 11:59:11 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E75D021F87D3 for ; Mon, 7 Nov 2011 11:59:10 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D410F2019A; Mon, 7 Nov 2011 14:59:59 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7AECE435A; Mon, 7 Nov 2011 14:58:59 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <4EB0F497.1000104@deployingradius.com> <4EB3B3CD.1020009@deployingradius.com> <4EB7FB73.8010609@deployingradius.com> <4EB835C9.9060404@deployingradius.com> Date: Mon, 07 Nov 2011 14:58:59 -0500 In-Reply-To: <4EB835C9.9060404@deployingradius.com> (Alan DeKok's message of "Mon, 07 Nov 2011 20:47:21 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: josh.howlett@ja.net, radext@ietf.org, "radext-chairs@tools.ietf.org" , Bernard Aboba , "dromasca@avaya.com" , abfab-chairs@tools.ietf.org Subject: Re: [radext] ABFAB does not specify any changes to RADIUS 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: Mon, 07 Nov 2011 19:59:11 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Sam Hartman wrote: >> The only thing we need is a string with human semantics similar >> to a NAI that has a realm portion after an at-sign and some >> portion (possibly empty) before the at-sign. Alan> That's largely what the new NAI document proposes. >> I actually think 4282 is a fine reference for the basic concept >> behind a NAI so long as we are not talking about any of the >> encoding or string processing rules. Alan> They're tied together, unfortunately. Give me a chance to try and specify what we mean without pulling in the string encoding. If I fail, we can just wrip out calling it a NAI completely or note that it's intended to be compatible in concept with the new NAI once published and use an informative reference. --Sam From bernard_aboba@hotmail.com Mon Nov 7 12:50:41 2011 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 7F84E11E80D0 for ; Mon, 7 Nov 2011 12:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.060, 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 v7l2WDvVxaDN for ; Mon, 7 Nov 2011 12:50:29 -0800 (PST) Received: from blu0-omc1-s23.blu0.hotmail.com (blu0-omc1-s23.blu0.hotmail.com [65.55.116.34]) by ietfa.amsl.com (Postfix) with ESMTP id EA67011E80C4 for ; Mon, 7 Nov 2011 12:50:28 -0800 (PST) Received: from BLU152-W22 ([65.55.116.9]) by blu0-omc1-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Nov 2011 12:50:28 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_938e6c14-2567-492d-8733-feda970195af_" X-Originating-IP: [131.107.0.98] From: Bernard Aboba To: , Alan DeKok Date: Mon, 7 Nov 2011 12:50:27 -0800 Importance: Normal In-Reply-To: References: , , <4EB0F497.1000104@deployingradius.com>, , <4EB3B3CD.1020009@deployingradius.com> , <4EB7FB73.8010609@deployingradius.com>, , <4EB835C9.9060404@deployingradius.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 07 Nov 2011 20:50:28.0177 (UTC) FILETIME=[E18A8410:01CC9D8E] Cc: josh.howlett@ja.net, radext@ietf.org, abfab-chairs@tools.ietf.org, "radext-chairs@tools.ietf.org" , "dromasca@avaya.com" Subject: Re: [radext] ABFAB does not specify any changes to RADIUS 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: Mon, 07 Nov 2011 20:50:41 -0000 --_938e6c14-2567-492d-8733-feda970195af_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Alan> They're tied together=2C unfortunately. [BA] RFC 4282 tied them together. But I agree with Sam that they are logic= ally separate issues. =20 > Give me a chance to try and specify what we mean without pulling in the > string encoding. If I fail=2C we can just rip out calling it a NAI > completely or note that it's intended to be compatible in concept with > the new NAI once published and use an informative reference. [BA] Give it a shot. =20 = --_938e6c14-2567-492d-8733-feda970195af_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B Alan>=3B They're tied together=2C unfortunately.

[BA]= RFC 4282 tied them together. =3B But I agree with Sam that they are lo= gically separate issues. =3B

>=3B Give me a chance to t= ry and specify what we mean without pulling in the
>=3B string encodin= g. If I fail=2C we can just rip out calling it a NAI
>=3B completely = or note that it's intended to be compatible in concept with
>=3B the n= ew NAI once published and use an informative reference.

[BA] =3B= Give it a shot. =3B =3B
= --_938e6c14-2567-492d-8733-feda970195af_-- From radext-bounces@ietf.org Mon Nov 7 12:50:46 2011 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 77C5011E80D0; Mon, 7 Nov 2011 12:50:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320699046; bh=B6VtPb/noPmSoE7DUL8nMIQEKgDYCB9esOZGkQG7B04=; h=Message-ID:From:To:Date:In-Reply-To:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=uFcWMtMA0etgp90/N3O1v6hv0l9nY1V10E/GsKsaIz81oQS11UtpzGHBjw4MnmoAp ImjuNsH5my6SUsAaKdGFcaN27kUw9gdS4CVXmnAyAWIH57GpHZLuUcQ9y7xxmpnFl1 6avmx5e3Nx6KEQu6lXjxUlTX0Gykgfdxv/LcbQ2g= 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 7F84E11E80D0 for ; Mon, 7 Nov 2011 12:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.060, 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 v7l2WDvVxaDN for ; Mon, 7 Nov 2011 12:50:29 -0800 (PST) Received: from blu0-omc1-s23.blu0.hotmail.com (blu0-omc1-s23.blu0.hotmail.com [65.55.116.34]) by ietfa.amsl.com (Postfix) with ESMTP id EA67011E80C4 for ; Mon, 7 Nov 2011 12:50:28 -0800 (PST) Received: from BLU152-W22 ([65.55.116.9]) by blu0-omc1-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Nov 2011 12:50:28 -0800 Message-ID: X-Originating-IP: [131.107.0.98] From: Bernard Aboba To: , Alan DeKok Date: Mon, 7 Nov 2011 12:50:27 -0800 Importance: Normal In-Reply-To: References: , , <4EB0F497.1000104@deployingradius.com>, , <4EB3B3CD.1020009@deployingradius.com> , <4EB7FB73.8010609@deployingradius.com>, , <4EB835C9.9060404@deployingradius.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 07 Nov 2011 20:50:28.0177 (UTC) FILETIME=[E18A8410:01CC9D8E] Cc: josh.howlett@ja.net, radext@ietf.org, abfab-chairs@tools.ietf.org, "radext-chairs@tools.ietf.org" , "dromasca@avaya.com" Subject: Re: [radext] ABFAB does not specify any changes to RADIUS 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="===============1169632044836299338==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============1169632044836299338== Content-Type: multipart/alternative; boundary="_938e6c14-2567-492d-8733-feda970195af_" --_938e6c14-2567-492d-8733-feda970195af_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Alan> They're tied together=2C unfortunately. [BA] RFC 4282 tied them together. But I agree with Sam that they are logic= ally separate issues. =20 > Give me a chance to try and specify what we mean without pulling in the > string encoding. If I fail=2C we can just rip out calling it a NAI > completely or note that it's intended to be compatible in concept with > the new NAI once published and use an informative reference. [BA] Give it a shot. =20 = --_938e6c14-2567-492d-8733-feda970195af_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B Alan>=3B They're tied together=2C unfortunately.

[BA]= RFC 4282 tied them together. =3B But I agree with Sam that they are lo= gically separate issues. =3B

>=3B Give me a chance to t= ry and specify what we mean without pulling in the
>=3B string encodin= g. If I fail=2C we can just rip out calling it a NAI
>=3B completely = or note that it's intended to be compatible in concept with
>=3B the n= ew NAI once published and use an informative reference.

[BA] =3B= Give it a shot. =3B =3B
= --_938e6c14-2567-492d-8733-feda970195af_-- --===============1169632044836299338== 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 --===============1169632044836299338==-- From radext-bounces@ietf.org Wed Nov 9 20:16:28 2011 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 5999321F84CE; Wed, 9 Nov 2011 20:16:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320898588; bh=rAQOANVWFmBc3S9ul9EN9FpbLnzxu9lKXC4DIDwvrF8=; 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:Sender; b=ItMjzqGOBUk5PbSCAluNOagw1lP+KumpODkRq1aTR/aQD3bQcdy4k1BSxdG9Y6L9C LQijiklY6R9i28SY0z4Jemeg5WnNiqepG1JjNERowlVrvhiqCo8TfHiz9OPQmYgGsu UhrpSzzC5/71ijTBG03eTr9Pq4oFDxJtBaro/8h4= 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 6230721F84CB for ; Wed, 9 Nov 2011 20:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.027, 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 tZMhCw9hUV-c for ; Wed, 9 Nov 2011 20:16:25 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3F06821F8468 for ; Wed, 9 Nov 2011 20:16: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 <0LUF0026VFREM3@szxga04-in.huawei.com> for radext@ietf.org; Thu, 10 Nov 2011 12:14:02 +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 <0LUF006CUFRDZ0@szxga04-in.huawei.com> for radext@ietf.org; Thu, 10 Nov 2011 12:14:01 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEW48533; Thu, 10 Nov 2011 12:13:57 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 10 Nov 2011 12:13:50 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.62]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0270.001; Thu, 10 Nov 2011 12:13:45 +0800 Date: Thu, 10 Nov 2011 04:13:43 +0000 From: Leaf yeh In-reply-to: <4EAFBC28.40902@deployingradius.com> X-Originating-IP: [10.70.39.98] To: Alan DeKok Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-01.txt Thread-index: AQHMmHjxOn370Vpz9UOLR3dSV3C8GJWkH7VQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EAFBC28.40902@deployingradius.com> Cc: "radext@ietf.org" , "fine_sz@huawei.com" Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-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="===============8898689271333068906==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============8898689271333068906== Content-type: multipart/alternative; boundary="Boundary_(ID_EoiwDGbqZEoJ3ivEXk1Y+A)" Content-language: zh-CN --Boundary_(ID_EoiwDGbqZEoJ3ivEXk1Y+A) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 QWxhbiAtIFRoaXMgbG9va3MgbGlrZSBhIGdvb2QgY2FzZSBmb3IgZ3JvdXBpbmcgYnkgdHlwZSwg d2hpY2ggbWVhbnMgVExWcy4NCg0KVGhlIEFjY3QtSW5wdXQtSVB2NC1PY3RldHMgYXR0cmlidXRl IHlvdSBkZWZpbmUgd291bGQgdGhlbiBtYXAgdG86DQoNCkFjY3QtSW5wdXQtU3RhdHMgKCBBY2N0 LUlQNC1TdGF0cyAoIEFjY3QtUGFja2V0LVN0YXRzICh2YWx1ZSkpKQ0KDQoNCg0KVGhhbmtzIHRv IGRyYWZ0LWlldGYtcmFkZXh0LXJhZGl1cy1leHRlbnNpb25zLTAyLCB3ZSd2ZSBnb3QgdGhlIGFs dGVybmF0aXZlIG1ldGhvZCB0byBkZWZpbmUgdGhlIG5ldyBhdHRyaWJ1dGUuDQoNCg0KDQpCdXQg dGhlIGFyZ3VtZW50cyBjb3VsZCBiZToNCg0KDQoNCjEuICAgICAgVGhlIHR5cGUtc3BhY2Ugb2Yg dGhlIGF0dHJpYnV0ZSBoYXMgZXh0ZW5kZWQgbXVjaCBhZnRlciBhZG9wdGVkIHRoZSBFeHRlbmRl ZCB0eXBlICgyNDEtMjQ0KSwgdGhlIHVuYXNzaWduZWQgdHlwZSBzcGFjZSB0dXJuIHRvIGJlIDEw MDM9MTkxLTE0NCArIDQqKDI0MC0xKS4gV2UgY2FuIHVzZSBpdCBqdXN0IGRpcmVjdGx5IGluIGZs YXQgbW9kZS4NCg0KDQoNCjIuICAgICAgVGhlIGFib3ZlIG1hcCBvZiDigJhBY2N0LUlucHV0LVN0 YXRzICggQWNjdC1JUDQtU3RhdHMgKCBBY2N0LVBhY2tldC1TdGF0cyAodmFsdWUpKSnigJkgc291 bmQgVExWIG5lc3RpbmcsIGJ1dCBJIGd1ZXNzIFRMViBncm91cGluZyAoY29udGFpbmVyIG1vZGUp IHNvdW5kcyBiZXR0ZXIgdGhvdWdoIGl0IGlzIGEgbGl0dGxlIG1vcmUgY29tcGxleCB0aGFuIHRo ZSBmbGF0IG1vZGUgLg0KDQoNCg0KVGhhdCBtaWdodCBtZWFucw0KDQoNCg0KICAgIElucHV0LU9j dGV0cyAoMTB4IG9jdGV0cywgVExWKQ0KDQogICAgT3V0cHV0LU9jdGV0cyAoMTB4IG9jdGV0cywg VExWKQ0KDQogICAgSW5wdXQtUGFja2V0cyAoMTB4IG9jdGV0cywgVExWKQ0KDQogICAgT3V0cHV0 LVBhY2tldHMgKDEweCBvY3RldHMsIFRMVikNCg0KDQoNCmNvdWxkIGJlIHRoZSBzdWItYXR0cmli dXRlcy4NCg0KDQoNCklmIG9uZSBtb3JlIOKAmFRyYWZmaWMtVHlwZeKAmShzdWItYXR0cmlidXRl LCAzeCBvY3RldHMsIFRMVikgY291bGQgYmUgaW5jbHVkZWQgaW50byB0aGUgY29udGFpbmVyIOKA mEFjY3QtdHJhZmZpYy1zdGF0aXN0aWNz4oCZLCByZWZlcnJlZCB0byB0aGUgZHJhZnQtd2ludGVy LXJhZGV4LWZhbmN5YWNjb3VudGluZy0wMCwgdGhlbiB0aGUgY29udGFpbmVyIHdvdWxkIGdldCB0 aGUgZXh0ZW5zaWJpbGl0eSBmb3IgdmFyaW91cyBraW5kcyAoZWcuIElQdjQsIElQdjYpIG9mIHRy YWZmaWMgc3RhdGlzdGljcyBwZXIgdGhlIOKAmFRyYWZmaWMtVHlwZeKAmSwgYW5kIGV2ZW4gZm9y IHNvbWUgZGVtYW5kcyAoZWcuIERTQ1AgbWVudGlvbmVkIGluIHRoZSBhYm92ZSBkcmFmdCwgb3Ig VENQLCBVRFAgbWVudGlvbmVkIGJlbG93KSBpbiB0aGUgZnV0dXJlLg0KDQoNCg0KSW4gdGhpcyBk ZXNpZ24sIHRoZSBsZW5ndGggb2YgdGhlIGNvbnRhaW5lciB3aWxsIG5ldmVyIGV4Y2VzcyAyNTIg b2N0ZXRzLCB0aGVuIHRoZSBjb250YWluZXIg4oCYQWNjdC10cmFmZmljLXN0YXRpc3RpY3PigJkg Y291bGQgdXNlIHRoZSBmb3JtYXQgb2YgRXh0ZW5kZWQtVHlwZSAoMjQxKS4NCg0KDQoNCjMuICAg ICAgRG8gd2UgYWxyZWFkeSBoYXZlIGFueSBjb250YWluZXIgYXR0cmlidXRlIGRlZmluZWQgaW4g UkZDPyBJIGNhbuKAmXQgZmluZCB0aGlzIGtpbmQgb2YgYXR0cmlidXRlIGluIElBTkEgd2ViIHBh Z2UuIChodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3JhZGl1cy10eXBlcy9yYWRpdXMt dHlwZXMueG1sKS4gSSB3b25kZXIgdGhlIFJhZGl1cyBjb21tdW5pdHkgJiBXRyB3b3VsZCBsaWtl IHRoaXMgY29tcGxleGl0eSBvZiBpbnRlcnByZXRhdGlvbiBhZ2FpbnN0IDEtMiBtb3JlIGxldmVs cyBvZiBuZXN0aW5nIGFuZCBjb21iaW5hdGlvbi4NCg0KDQoNCjQuICAgICAgQXMgdG8gdGhlIGNv ZGUgYXNzaWdubWVudCBmb3IgdGhpcyBuZXcgdHlwZSBvZiBjb250YWluZXIgYXR0cmlidXRlIHBy b3Bvc2VkIGZvciBJQU5BIGNvbnNpZGVyYXRpb24sIGl0IG1pZ2h0IGJlDQoNCg0KDQoyNDEuMSBm b3IgdGhlIHRoZSBjb250YWluZXIg4oCYQWNjdC10cmFmZmljLXN0YXRpc3RpY3PigJkNCg0KMjQx LjEuMSBmb3IgdGhlIHN1Yi1hdHRyaWJ1dGUg4oCYVHJhZmZpYy1UeXBl4oCZDQoNCjI0MS4xLjIg Zm9yIHRoZSBzdWItYXR0cmlidXRlIOKAmElucHV0LU9jdGV0c+KAmQ0KDQoyNDEuMS4zIGZvciB0 aGUgc3ViLWF0dHJpYnV0ZSDigJhPdXRwdXQtT2N0ZXRz4oCZDQoNCjI0MS4xLjQgZm9yIHRoZSBz dWItYXR0cmlidXRlIOKAmElucHV0LVBhY2tldHPigJkNCg0KMjQxLjEuNSBmb3IgdGhlIHN1Yi1h dHRyaWJ1dGUg4oCYT3V0cHV0LVBhY2tldHPigJkNCg0KDQoNCkkgd29uZGVyIHRoZSBzcGFjZSBv ZiAyNDEuMS54IChyYXRoZXIgdGhhbiAyNDEueCkgaXMgcmVhZHkgZm9yIElBTkEgdG8gYXNzaWdu IG91dC4NCg0KDQoNCkFueSBtb3JlIGNvbW1lbnRzPw0KDQoNCg0KDQoNCkJlc3QgUmVnYXJkcywN Cg0KTGVhZg0KDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiByYWRl eHQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJhZGV4dC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQWxhbiBEZUtvaw0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMDEsIDIwMTEgNToz MCBQTQ0KVG86IExlYWYgeWVoDQpDYzogcmFkZXh0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Jh ZGV4dF0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteWVoLXJhZGV4dC1l eHQtdHJhZmZpYy1zdGF0aXN0aWNzLTAxLnR4dA0KDQoNCg0KTGVhZiB5ZWggd3JvdGU6DQoNCj4g RGVhciBHcm91cCwNCg0KPg0KDQo+IDEuIGRyYWZ0LXllaC1yYWRleHQtZXh0LXRyYWZmaWMtc3Rh dGlzdGljcy0wMSBpcyByZWFkeSBmb3IgeW91ciBjb21tZW50IG9uIHdoZXRoZXIgaXQgZGVzZXJ2 ZXMgYSBXRyBpdGVtIGF0IFJBREVYVC4NCg0KPg0KDQo+IDIuIEl0IGRlZmluZWQgOCBuZXcgYXR0 cmlidXRlcyBvZiB0cmFmZmljIHN0YXRpc3RpY3MgZm9yIHRoZSBzZXBhcmF0ZSBJUHY0ICYgSVB2 NiBzdGFjayAocXVldWUgb3IgY291bnRlciksIGFuZCBlbXBsb3llZCB0aGUgbmV3IGRhdGUgdHlw ZSBvZiBpbnRlZ2VyNjQsIGJ1dCB0aGUgZm9ybWF0IG9mIG5ldyBhdHRyaWJ1dGVzIG1pZ2h0IGJl IHN0aWxsIGEgcXVlc3Rpb24gbm93LiBJdCBoYXMgMiBvcHRpb25zIG5vdzogIGEuIHRoZSB0cmFk aXRpb25hbCBmb3JtYXQgZGVmaW5lZCBpbiBbUkZDMjg2NV07ICBiLiB0aGUgbmV3IGV4dGVuZGVk IGZvcm1hdCBkZWZpbmVkIGluIFtkcmFmdC1pZXRmLXJhZGV4dC1yYWRpdXMtZXh0ZW5zaW9ucy0w Ml0uDQoNCg0KDQogIExvb2tpbmcgYXQgdGhlIG5hbWVzIG9mIHRoZSBuZXcgYXR0cmlidXRlczoN Cg0KDQoNCiAgICAgIEFjY3QtSW5wdXQtSVB2NC1PY3RldHMNCg0KICAgICAgQWNjdC1PdXRwdXQt SVB2NC1PY3RldHMNCg0KICAgICAgQWNjdC1JbnB1dC1JUHY0LVBhY2tldHMNCg0KICAgICAgQWNj dC1PdXRwdXQtSVB2NC1QYWNrZXRzDQoNCiAgICAgIEFjY3QtSW5wdXQtSVB2Ni1PY3RldHMNCg0K ICAgICAgQWNjdC1PdXRwdXQtSVB2Ni1PY3RldHMNCg0KICAgICAgQWNjdC1JbnB1dC1JUHY2LVBh Y2tldHMNCg0KICAgICAgQWNjdC1PdXRwdXQtSVB2Ni1QYWNrZXRzDQoNCg0KDQogIFRoZXkncmUg b2YgdGhlIGZvcm06DQoNCg0KDQogICAgICAgICBBY2N0LSBJbnB1dC9PdXRwdXQgLSBJUHY0L0lQ djYgLSBQYWNrZXRzL09jdGV0cw0KDQoNCg0KICBUaGlzIGxvb2tzIGxpa2UgYSBnb29kIGNhc2Ug Zm9yIGdyb3VwaW5nIGJ5IHR5cGUsIHdoaWNoIG1lYW5zIFRMVnMuDQoNCklmIHlvdSB1c2UgdGhl IG5ldyBmb3JtYXQsIFRMVnMgd291bGQgYmUgcHJlZmVycmVkIHRvIHVzaW5nIGEgImZsYXQiDQoN Cm5hbWUgc3BhY2UsIGFuZCBhbGxvY2F0aW5nIDggYXR0cmlidXRlcyBmcm9tIHRoYXQgc3BhY2Uu DQoNCg0KDQogIE9uZSBvcHRpb24gd291bGQgYmUgdG8gZGVmaW5lIHR3byBhdHRyaWJ1dGVzOiAi QWNjdC1JbnB1dC1TdGF0cyIgYW5kDQoNCkFjY3QtT3V0cHV0LVN0YXRzIi4gIFRoZXkgY291bGQg YmUgPiAyNTIgb2N0ZXRzIGxvbmcsIGFuZCBjb250YWluIFRMVnMuDQoNClRoZXkgY291bGQgc2hh cmUgdGhlIHNhbWUgc2V0IG9mIHN1Yi1UTFZzLg0KDQoNCg0KICBUaGUgc3ViLVRMVnMgY291bGQg YmU6DQoNCg0KDQogICAgICAgICBBY2N0LUlQdjQtU3RhdHMgICAgICAgZm9yIElQdjQgZGF0YQ0K DQogICAgICAgICBBY2N0LUlQdjYtU3RhdHMgICAgICAgZm9yIElQdjYgZGF0YQ0KDQoNCg0KICBU aG9zZSBzdWItVExWcyBpbiB0dXJuIGNvdWxkIGNvbnRhaW46DQoNCg0KDQogICAgICAgICBBY2N0 LVBhY2tldC1TdGF0cw0KDQogICAgICAgICBBY2N0LU9jdGV0LVN0YXRzDQoNCg0KDQogIFRoZSBB Y2N0LUlucHV0LUlQdjQtT2N0ZXRzIGF0dHJpYnV0ZSB5b3UgZGVmaW5lIHdvdWxkIHRoZW4gbWFw IHRvOg0KDQoNCg0KICAgICAgICAgQWNjdC1JbnB1dC1TdGF0cyAoIEFjY3QtSVA0LVN0YXRzICgg QWNjdC1QYWNrZXQtU3RhdHMgKHZhbHVlKSkpDQoNCg0KDQogIFRoaXMgdXNlcyBtb3JlIHNwYWNl IGluIHRoZSBwYWNrZXQsIGJ1dCBpcyBtb3JlIGdlbmVyYWwuICBPdGhlcg0KDQpzcGVjaWZpY2F0 aW9ucyBjb3VsZCBhZGQgVENQIHN0YXRzLCBVRFAgc3RhdHMsIGV0Yy4NCg0KDQoNCllvdSBtZW50 aW9uIGRyYWZ0LXdpbnRlci1yYWRleHQtZmFuY3lhY2NvdW50aW5nLTAwLiAgSSBoYXZlbid0DQoN CmNvbXBhcmVkIHRoZSB0d28gZG9jdW1lbnRzIGluIGRldGFpbCwgYnV0IEknZCBsaWtlIHRvIGtu b3cgd2hhdCBvdmVybGFwDQoNCihpZiBhbnkpIGV4aXN0cyBiZXR3ZWVuIHRoZW0uICBIYXZpbmcg dGhlIFdHIGNvbnZlcmdlIG9uIG9uZSBwcm9wb3NhbA0KDQp3b3VsZCBiZSBhIGdvb2QgdGhpbmcu DQoNCg0KDQogIEFsYW4gRGVLb2suDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCnJhZGV4dCBtYWlsaW5nIGxpc3QNCg0KcmFkZXh0QGlldGYub3Jn DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0DQo= --Boundary_(ID_EoiwDGbqZEoJ3ivEXk1Y+A) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlm eTsNCgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNv UGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi57qv 5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpw Lk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdy YXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0aWZ5OmludGVyLWlk ZW9ncmFwaDsNCgl0ZXh0LWluZGVudDoyMS4wcHQ7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5bGUt bmFtZToi57qv5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazrnuq/mlofmnKw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlO30N CnNwYW4ud29yZA0KCXttc28tc3R5bGUtbmFtZTp3b3JkO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KLyogUGFnZSBE ZWZpbml0aW9ucyAqLw0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBs MA0KCXttc28tbGlzdC1pZDoxOTExNDI0ODY5Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczotMTU2MTg0NDA3OCA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9 DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+BrDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjEuMHB0Ow0KCXRleHQtaW5kZW50 Oi0yMS4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0 LWlkOjE5NzA3NDUzNTA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjEwOTEyMTYxNzYgLTE5NzU3Mjg5NjQgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMg Njc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDE6 bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozOC40cHQ7DQoJdGV4dC1pbmRlbnQ6LTE5LjJwdDt9 DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoyMDE2MzAyNTQ0Ow0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjUyOTUyMzM0IC0xOTc1NzI4OTY0IDY3Njk4 NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEz IDY3Njk4NzE1O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTkuMnB0Ow0K CXRleHQtaW5kZW50Oi0xOS4ycHQ7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MjExMTU4NjE2 MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE0NTMw NjI3NjIgLTE5NzU3Mjg5NjQgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2 OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN CgltYXJnaW4tbGVmdDoxOS4ycHQ7DQoJdGV4dC1pbmRlbnQ6LTE5LjJwdDt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9InRleHQt anVzdGlmeS10cmltOnB1bmN0dWF0aW9uIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QWxhbiAtIFRoaXMgbG9v a3MgbGlrZSBhIGdvb2QgY2FzZSBmb3IgZ3JvdXBpbmcgYnkgdHlwZSwgd2hpY2ggbWVhbnMgVExW cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+VGhlIEFjY3QtSW5wdXQtSVB2NC08c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5P Y3RldHM8L3NwYW4+IGF0dHJpYnV0ZSB5b3UgZGVmaW5lIHdvdWxkIHRoZW4gbWFwIHRvOg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPkFjY3QtSW5wdXQtU3RhdHMgKCBBY2N0LUlQNC1TdGF0cyAoIEFjY3QtPHNwYW4gc3R5 bGU9ImNvbG9yOnJlZCI+UGFja2V0PC9zcGFuPi1TdGF0cyAodmFsdWUpKSk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPlRoYW5rcyB0byBkcmFmdC1pZXRmLXJhZGV4dC1yYWRpdXMtZXh0ZW5zaW9u cy0wMiwgd2UndmUgZ290IHRoZSBhbHRlcm5hdGl2ZSBtZXRob2QgdG8gZGVmaW5lIHRoZSBuZXcg YXR0cmlidXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QnV0IHRoZSBhcmd1bWVudHMgY291 bGQgYmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOS4ycHQ7dGV4dC1pbmRlbnQ6LTE5LjJw dDttc28tbGlzdDpsMiBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBs YW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9 IkVOLVVTIj5UaGUgdHlwZS1zcGFjZSBvZiB0aGUgYXR0cmlidXRlIGhhcyBleHRlbmRlZCBtdWNo IGFmdGVyIGFkb3B0ZWQgdGhlIEV4dGVuZGVkIHR5cGUgKDI0MS0yNDQpLCB0aGUgdW5hc3NpZ25l ZCB0eXBlIHNwYWNlIHR1cm4gdG8gYmUgMTAwMz0xOTEtMTQ0ICYjNDM7IDQqKDI0MC0xKS4gV2Ug Y2FuIHVzZSBpdCBqdXN0IGRpcmVjdGx5IGluIGZsYXQgbW9kZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTkuMnB0O3Rl eHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTku MnB0O3RleHQtaW5kZW50Oi0xOS4ycHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzE7dGV4dC1hdXRv c3BhY2U6bm9uZSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgYWJv dmUgbWFwIG9mIOKAmEFjY3QtSW5wdXQtU3RhdHMgKCBBY2N0LUlQNC1TdGF0cyAoIEFjY3QtUGFj a2V0LVN0YXRzICh2YWx1ZSkpKeKAmSBzb3VuZCBUTFYgbmVzdGluZywgYnV0IEkgZ3Vlc3MgVExW IGdyb3VwaW5nIChjb250YWluZXIgbW9kZSkgc291bmRzIGJldHRlciB0aG91Z2ggaXQgaXMgYSBs aXR0bGUgbW9yZSBjb21wbGV4IHRoYW4gdGhlIGZsYXQNCiBtb2RlIC4gPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHls ZT0ibWFyZ2luLWxlZnQ6MTkuMnB0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIGxhbmc9IkVO LVVTIj5UaGF0IG1pZ2h0IG1lYW5zDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTkuMnB0Ij48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyBJbnB1dC1PY3RldHMgKDEweCBv Y3RldHMsIFRMVik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IE91dHB1dC1PY3RldHMgKDEw eCBvY3RldHMsIFRMVik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IElucHV0LVBhY2tldHMg KDEweCBvY3RldHMsIFRMVik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IE91dHB1dC1QYWNr ZXRzICgxMHggb2N0ZXRzLCBUTFYpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE5LjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxOS4ycHQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gbGFuZz0i RU4tVVMiPmNvdWxkIGJlIHRoZSBzdWItYXR0cmlidXRlcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOS4ycHQ7dGV4 dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOS4y cHQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gbGFuZz0iRU4tVVMiPklmIG9uZSBtb3JlIOKA mFRyYWZmaWMtVHlwZeKAmShzdWItYXR0cmlidXRlLCAzeCBvY3RldHMsIFRMVikgY291bGQgYmUg aW5jbHVkZWQgaW50byB0aGUgY29udGFpbmVyIOKAmEFjY3QtdHJhZmZpYy1zdGF0aXN0aWNz4oCZ LCByZWZlcnJlZCB0byB0aGUgZHJhZnQtd2ludGVyLXJhZGV4LWZhbmN5YWNjb3VudGluZy0wMCwN CiB0aGVuIHRoZSBjb250YWluZXIgd291bGQgZ2V0IHRoZSBleHRlbnNpYmlsaXR5IGZvciB2YXJp b3VzIGtpbmRzIChlZy4gSVB2NCwgSVB2Nikgb2YgdHJhZmZpYyBzdGF0aXN0aWNzIHBlciB0aGUg 4oCYVHJhZmZpYy1UeXBl4oCZLCBhbmQgZXZlbiBmb3Igc29tZSBkZW1hbmRzIChlZy4gRFNDUCBt ZW50aW9uZWQgaW4gdGhlIGFib3ZlIGRyYWZ0LCBvciBUQ1AsIFVEUCBtZW50aW9uZWQgYmVsb3cp IGluIHRoZSBmdXR1cmUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTkuMnB0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTkuMnB0O3RleHQtYXV0b3NwYWNlOm5v bmUiPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiB0aGlzIGRlc2lnbiwgdGhlIGxlbmd0aCBvZiB0aGUg Y29udGFpbmVyIHdpbGwgbmV2ZXIgZXhjZXNzIDI1MiBvY3RldHMsIHRoZW4gdGhlIGNvbnRhaW5l ciDigJhBY2N0LXRyYWZmaWMtc3RhdGlzdGljc+KAmSBjb3VsZCB1c2UgdGhlIGZvcm1hdCBvZiBF eHRlbmRlZC1UeXBlICgyNDEpLiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTkuMnB0O3RleHQtYXV0b3NwYWNl Om5vbmUiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTkuMnB0O3RleHQtaW5k ZW50Oi0xOS4ycHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzE7dGV4dC1hdXRvc3BhY2U6bm9uZSI+ DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIj5EbyB3ZSBhbHJlYWR5IGhhdmUg YW55IGNvbnRhaW5lciBhdHRyaWJ1dGUgZGVmaW5lZCBpbiBSRkM/IEkgY2Fu4oCZdCBmaW5kIHRo aXMga2luZCBvZiBhdHRyaWJ1dGUgaW4gSUFOQSB3ZWIgcGFnZS4gKDxhIGhyZWY9Imh0dHA6Ly93 d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvcmFkaXVzLXR5cGVzL3JhZGl1cy10eXBlcy54bWwiPjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwOi8v d3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3JhZGl1cy10eXBlcy9yYWRpdXMtdHlwZXMueG1sPC9z cGFuPjwvYT4pLg0KIEkgd29uZGVyIHRoZSBSYWRpdXMgY29tbXVuaXR5ICZhbXA7IFdHIHdvdWxk IGxpa2UgdGhpcyBjb21wbGV4aXR5IG9mIGludGVycHJldGF0aW9uIGFnYWluc3QgMS0yIG1vcmUg bGV2ZWxzIG9mIG5lc3RpbmcgYW5kIGNvbWJpbmF0aW9uLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE5LjJwdDt0ZXh0 LWF1dG9zcGFjZTpub25lIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE5LjJw dDt0ZXh0LWluZGVudDotMTkuMnB0O21zby1saXN0OmwyIGxldmVsMSBsZm8xO3RleHQtYXV0b3Nw YWNlOm5vbmUiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjQuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+QXMgdG8gdGhl IGNvZGUgYXNzaWdubWVudCBmb3IgdGhpcyBuZXcgdHlwZSBvZiBjb250YWluZXIgYXR0cmlidXRl IHByb3Bvc2VkIGZvciBJQU5BIGNvbnNpZGVyYXRpb24sIGl0IG1pZ2h0IGJlDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIj48c3BhbiBsYW5nPSJFTi1VUyI+MjQxLjEgZm9yIHRoZSB0aGUgY29udGFpbmVyIOKAmEFj Y3QtdHJhZmZpYy1zdGF0aXN0aWNz4oCZPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIj4yNDEuMS4xIGZvciB0aGUgc3Vi LWF0dHJpYnV0ZSDigJhUcmFmZmljLVR5cGXigJk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0idGV4dC1pbmRlbnQ6MjEuMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+MjQxLjEuMiBmb3IgdGhlIHN1Yi1hdHRyaWJ1dGUg4oCYSW5wdXQtT2N0ZXRz4oCZ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9InRl eHQtaW5kZW50OjIxLjZwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjI0MS4xLjMgZm9yIHRoZSBzdWIt YXR0cmlidXRlIOKAmE91dHB1dC1PY3RldHPigJk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0idGV4dC1pbmRlbnQ6MjEuNnB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+MjQxLjEuNCBmb3IgdGhlIHN1Yi1hdHRyaWJ1dGUg4oCYSW5wdXQtUGFja2V0c+KA mTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJ0 ZXh0LWluZGVudDoyMS42cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4yNDEuMS41IGZvciB0aGUgc3Vi LWF0dHJpYnV0ZSDigJhPdXRwdXQtUGFja2V0c+KAmTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJ0ZXh0LWluZGVudDoyMS42cHQiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0idGV4dC1pbmRlbnQ6MjEuNnB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SSB3 b25kZXIgdGhlIHNwYWNlIG9mIDI0MS4xLnggKHJhdGhlciB0aGFuIDI0MS54KSBpcyByZWFkeSBm b3IgSUFOQSB0byBhc3NpZ24gb3V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkFueSBtb3JlIGNvbW1lbnRzPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlc3QgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+TGVhZjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPGJyPg0KRnJvbTogcmFkZXh0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpyYWRleHQtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsYW4gRGVLb2s8YnI+DQpTZW50OiBUdWVzZGF5 LCBOb3ZlbWJlciAwMSwgMjAxMSA1OjMwIFBNPGJyPg0KVG86IExlYWYgeWVoPGJyPg0KQ2M6IHJh ZGV4dEBpZXRmLm9yZzxicj4NClN1YmplY3Q6IFJlOiBbcmFkZXh0XSBGVzogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC15ZWgtcmFkZXh0LWV4dC10cmFmZmljLXN0YXRpc3RpY3Mt MDEudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5MZWFmIHllaCB3cm90ZTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ Jmd0OyBEZWFyIEdyb3VwLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDEuIGRyYWZ0LXll aC1yYWRleHQtZXh0LXRyYWZmaWMtc3RhdGlzdGljcy0wMSBpcyByZWFkeSBmb3IgeW91ciBjb21t ZW50IG9uIHdoZXRoZXIgaXQgZGVzZXJ2ZXMgYSBXRyBpdGVtIGF0IFJBREVYVC4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDIuIEl0IGRlZmluZWQgOCBuZXcgYXR0cmlidXRlcyBvZiB0 cmFmZmljIHN0YXRpc3RpY3MgZm9yIHRoZSBzZXBhcmF0ZSBJUHY0ICZhbXA7IElQdjYgc3RhY2sg KHF1ZXVlIG9yIGNvdW50ZXIpLCBhbmQgZW1wbG95ZWQgdGhlIG5ldyBkYXRlIHR5cGUgb2YgaW50 ZWdlcjY0LCBidXQgdGhlIGZvcm1hdCBvZiBuZXcgYXR0cmlidXRlcyBtaWdodCBiZSBzdGlsbCBh IHF1ZXN0aW9uDQogbm93LiBJdCBoYXMgMiBvcHRpb25zIG5vdzombmJzcDsgYS4gdGhlIHRyYWRp dGlvbmFsIGZvcm1hdCBkZWZpbmVkIGluIFtSRkMyODY1XTsmbmJzcDsgYi4gdGhlIG5ldyBleHRl bmRlZCBmb3JtYXQgZGVmaW5lZCBpbiBbZHJhZnQtaWV0Zi1yYWRleHQtcmFkaXVzLWV4dGVuc2lv bnMtMDJdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7IExvb2tpbmcgYXQgdGhlIG5h bWVzIG9mIHRoZSBuZXcgYXR0cmlidXRlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBY2N0LUlucHV0LUlQdjQtT2N0ZXRzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBY2N0LU91dHB1dC1JUHY0LU9jdGV0czxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQWNjdC1JbnB1dC1JUHY0LVBh Y2tldHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFjY3QtT3V0cHV0 LUlQdjQtUGFja2V0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQWNj dC1JbnB1dC1JUHY2LU9jdGV0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgQWNjdC1PdXRwdXQtSVB2Ni1PY3RldHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEFjY3QtSW5wdXQtSVB2Ni1QYWNrZXRzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBBY2N0LU91dHB1dC1JUHY2LVBhY2tldHM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOyBUaGV5J3JlIG9mIHRoZSBmb3JtOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFj Y3QtIElucHV0L091dHB1dCAtIElQdjQvSVB2NiAtIFBhY2tldHMvT2N0ZXRzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsgVGhpcyBsb29rcyBsaWtlIGEgZ29vZCBjYXNlIGZvciBncm91 cGluZyBieSB0eXBlLCB3aGljaCBtZWFucyBUTFZzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB5b3UgdXNlIHRoZSBu ZXcgZm9ybWF0LCBUTFZzIHdvdWxkIGJlIHByZWZlcnJlZCB0byB1c2luZyBhICZxdW90O2ZsYXQm cXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+bmFtZSBzcGFjZSwgYW5kIGFsbG9jYXRpbmcgOCBhdHRyaWJ1dGVzIGZy b20gdGhhdCBzcGFjZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyBPbmUgb3B0aW9u IHdvdWxkIGJlIHRvIGRlZmluZSB0d28gYXR0cmlidXRlczogJnF1b3Q7QWNjdC1JbnB1dC1TdGF0 cyZxdW90OyBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+QWNjdC1PdXRwdXQtU3RhdHMmcXVvdDsuJm5ic3A7IFRoZXkg Y291bGQgYmUgJmd0OyAyNTIgb2N0ZXRzIGxvbmcsIGFuZCBjb250YWluIFRMVnMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PlRoZXkgY291bGQgc2hhcmUgdGhlIHNhbWUgc2V0IG9mIHN1Yi1UTFZzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7IFRoZSBzdWItVExWcyBjb3VsZCBiZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBBY2N0LUlQdjQtU3RhdHMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZm9y IElQdjQgZGF0YTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgQWNjdC1JUHY2LVN0YXRzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGZvciBJUHY2IGRhdGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyBUaG9z ZSBzdWItVExWcyBpbiB0dXJuIGNvdWxkIGNvbnRhaW46PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQWNjdC1Q YWNrZXQtU3RhdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEFjY3QtT2N0ZXQtU3RhdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOyBUaGUgQWNjdC1JbnB1dC1JUHY0LU9jdGV0cyBhdHRyaWJ1dGUgeW91IGRlZmluZSB3b3Vs ZCB0aGVuIG1hcCB0bzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBY2N0LUlucHV0LVN0YXRzICggQWNjdC1J UDQtU3RhdHMgKCBBY2N0LVBhY2tldC1TdGF0cyAodmFsdWUpKSk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOyBUaGlzIHVzZXMgbW9yZSBzcGFjZSBpbiB0aGUgcGFja2V0LCBidXQgaXMg bW9yZSBnZW5lcmFsLiZuYnNwOyBPdGhlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5zcGVjaWZpY2F0aW9ucyBjb3VsZCBh ZGQgVENQIHN0YXRzLCBVRFAgc3RhdHMsIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPllv dSBtZW50aW9uIGRyYWZ0LXdpbnRlci1yYWRleHQtZmFuY3lhY2NvdW50aW5nLTAwLiZuYnNwOyBJ IGhhdmVuJ3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+Y29tcGFyZWQgdGhlIHR3byBkb2N1bWVudHMgaW4gZGV0YWlsLCBi dXQgSSdkIGxpa2UgdG8ga25vdyB3aGF0IG92ZXJsYXA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+KGlmIGFueSkgZXhpc3Rz IGJldHdlZW4gdGhlbS4mbmJzcDsgSGF2aW5nIHRoZSBXRyBjb252ZXJnZSBvbiBvbmUgcHJvcG9z YWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+d291bGQgYmUgYSBnb29kIHRoaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7IEFsYW4gRGVLb2suPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPnJhZGV4dCBtYWlsaW5nIGxpc3Q8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+cmFkZXh0QGlldGYub3JnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcmFkZXh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --Boundary_(ID_EoiwDGbqZEoJ3ivEXk1Y+A)-- --===============8898689271333068906== 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 --===============8898689271333068906==-- From leaf.y.yeh@huawei.com Wed Nov 9 20:16:26 2011 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 6230721F84CB for ; Wed, 9 Nov 2011 20:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.027, 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 tZMhCw9hUV-c for ; Wed, 9 Nov 2011 20:16:25 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3F06821F8468 for ; Wed, 9 Nov 2011 20:16: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 <0LUF0026VFREM3@szxga04-in.huawei.com> for radext@ietf.org; Thu, 10 Nov 2011 12:14:02 +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 <0LUF006CUFRDZ0@szxga04-in.huawei.com> for radext@ietf.org; Thu, 10 Nov 2011 12:14:01 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEW48533; Thu, 10 Nov 2011 12:13:57 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 10 Nov 2011 12:13:50 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.62]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0270.001; Thu, 10 Nov 2011 12:13:45 +0800 Date: Thu, 10 Nov 2011 04:13:43 +0000 From: Leaf yeh In-reply-to: <4EAFBC28.40902@deployingradius.com> X-Originating-IP: [10.70.39.98] To: Alan DeKok Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_EoiwDGbqZEoJ3ivEXk1Y+A)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-01.txt Thread-index: AQHMmHjxOn370Vpz9UOLR3dSV3C8GJWkH7VQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EAFBC28.40902@deployingradius.com> Cc: "radext@ietf.org" , "fine_sz@huawei.com" Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-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: Thu, 10 Nov 2011 04:16:26 -0000 --Boundary_(ID_EoiwDGbqZEoJ3ivEXk1Y+A) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 QWxhbiAtIFRoaXMgbG9va3MgbGlrZSBhIGdvb2QgY2FzZSBmb3IgZ3JvdXBpbmcgYnkgdHlwZSwg d2hpY2ggbWVhbnMgVExWcy4NCg0KVGhlIEFjY3QtSW5wdXQtSVB2NC1PY3RldHMgYXR0cmlidXRl IHlvdSBkZWZpbmUgd291bGQgdGhlbiBtYXAgdG86DQoNCkFjY3QtSW5wdXQtU3RhdHMgKCBBY2N0 LUlQNC1TdGF0cyAoIEFjY3QtUGFja2V0LVN0YXRzICh2YWx1ZSkpKQ0KDQoNCg0KVGhhbmtzIHRv IGRyYWZ0LWlldGYtcmFkZXh0LXJhZGl1cy1leHRlbnNpb25zLTAyLCB3ZSd2ZSBnb3QgdGhlIGFs dGVybmF0aXZlIG1ldGhvZCB0byBkZWZpbmUgdGhlIG5ldyBhdHRyaWJ1dGUuDQoNCg0KDQpCdXQg dGhlIGFyZ3VtZW50cyBjb3VsZCBiZToNCg0KDQoNCjEuICAgICAgVGhlIHR5cGUtc3BhY2Ugb2Yg dGhlIGF0dHJpYnV0ZSBoYXMgZXh0ZW5kZWQgbXVjaCBhZnRlciBhZG9wdGVkIHRoZSBFeHRlbmRl ZCB0eXBlICgyNDEtMjQ0KSwgdGhlIHVuYXNzaWduZWQgdHlwZSBzcGFjZSB0dXJuIHRvIGJlIDEw MDM9MTkxLTE0NCArIDQqKDI0MC0xKS4gV2UgY2FuIHVzZSBpdCBqdXN0IGRpcmVjdGx5IGluIGZs YXQgbW9kZS4NCg0KDQoNCjIuICAgICAgVGhlIGFib3ZlIG1hcCBvZiDigJhBY2N0LUlucHV0LVN0 YXRzICggQWNjdC1JUDQtU3RhdHMgKCBBY2N0LVBhY2tldC1TdGF0cyAodmFsdWUpKSnigJkgc291 bmQgVExWIG5lc3RpbmcsIGJ1dCBJIGd1ZXNzIFRMViBncm91cGluZyAoY29udGFpbmVyIG1vZGUp IHNvdW5kcyBiZXR0ZXIgdGhvdWdoIGl0IGlzIGEgbGl0dGxlIG1vcmUgY29tcGxleCB0aGFuIHRo ZSBmbGF0IG1vZGUgLg0KDQoNCg0KVGhhdCBtaWdodCBtZWFucw0KDQoNCg0KICAgIElucHV0LU9j dGV0cyAoMTB4IG9jdGV0cywgVExWKQ0KDQogICAgT3V0cHV0LU9jdGV0cyAoMTB4IG9jdGV0cywg VExWKQ0KDQogICAgSW5wdXQtUGFja2V0cyAoMTB4IG9jdGV0cywgVExWKQ0KDQogICAgT3V0cHV0 LVBhY2tldHMgKDEweCBvY3RldHMsIFRMVikNCg0KDQoNCmNvdWxkIGJlIHRoZSBzdWItYXR0cmli dXRlcy4NCg0KDQoNCklmIG9uZSBtb3JlIOKAmFRyYWZmaWMtVHlwZeKAmShzdWItYXR0cmlidXRl LCAzeCBvY3RldHMsIFRMVikgY291bGQgYmUgaW5jbHVkZWQgaW50byB0aGUgY29udGFpbmVyIOKA mEFjY3QtdHJhZmZpYy1zdGF0aXN0aWNz4oCZLCByZWZlcnJlZCB0byB0aGUgZHJhZnQtd2ludGVy LXJhZGV4LWZhbmN5YWNjb3VudGluZy0wMCwgdGhlbiB0aGUgY29udGFpbmVyIHdvdWxkIGdldCB0 aGUgZXh0ZW5zaWJpbGl0eSBmb3IgdmFyaW91cyBraW5kcyAoZWcuIElQdjQsIElQdjYpIG9mIHRy YWZmaWMgc3RhdGlzdGljcyBwZXIgdGhlIOKAmFRyYWZmaWMtVHlwZeKAmSwgYW5kIGV2ZW4gZm9y IHNvbWUgZGVtYW5kcyAoZWcuIERTQ1AgbWVudGlvbmVkIGluIHRoZSBhYm92ZSBkcmFmdCwgb3Ig VENQLCBVRFAgbWVudGlvbmVkIGJlbG93KSBpbiB0aGUgZnV0dXJlLg0KDQoNCg0KSW4gdGhpcyBk ZXNpZ24sIHRoZSBsZW5ndGggb2YgdGhlIGNvbnRhaW5lciB3aWxsIG5ldmVyIGV4Y2VzcyAyNTIg b2N0ZXRzLCB0aGVuIHRoZSBjb250YWluZXIg4oCYQWNjdC10cmFmZmljLXN0YXRpc3RpY3PigJkg Y291bGQgdXNlIHRoZSBmb3JtYXQgb2YgRXh0ZW5kZWQtVHlwZSAoMjQxKS4NCg0KDQoNCjMuICAg ICAgRG8gd2UgYWxyZWFkeSBoYXZlIGFueSBjb250YWluZXIgYXR0cmlidXRlIGRlZmluZWQgaW4g UkZDPyBJIGNhbuKAmXQgZmluZCB0aGlzIGtpbmQgb2YgYXR0cmlidXRlIGluIElBTkEgd2ViIHBh Z2UuIChodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3JhZGl1cy10eXBlcy9yYWRpdXMt dHlwZXMueG1sKS4gSSB3b25kZXIgdGhlIFJhZGl1cyBjb21tdW5pdHkgJiBXRyB3b3VsZCBsaWtl IHRoaXMgY29tcGxleGl0eSBvZiBpbnRlcnByZXRhdGlvbiBhZ2FpbnN0IDEtMiBtb3JlIGxldmVs cyBvZiBuZXN0aW5nIGFuZCBjb21iaW5hdGlvbi4NCg0KDQoNCjQuICAgICAgQXMgdG8gdGhlIGNv ZGUgYXNzaWdubWVudCBmb3IgdGhpcyBuZXcgdHlwZSBvZiBjb250YWluZXIgYXR0cmlidXRlIHBy b3Bvc2VkIGZvciBJQU5BIGNvbnNpZGVyYXRpb24sIGl0IG1pZ2h0IGJlDQoNCg0KDQoyNDEuMSBm b3IgdGhlIHRoZSBjb250YWluZXIg4oCYQWNjdC10cmFmZmljLXN0YXRpc3RpY3PigJkNCg0KMjQx LjEuMSBmb3IgdGhlIHN1Yi1hdHRyaWJ1dGUg4oCYVHJhZmZpYy1UeXBl4oCZDQoNCjI0MS4xLjIg Zm9yIHRoZSBzdWItYXR0cmlidXRlIOKAmElucHV0LU9jdGV0c+KAmQ0KDQoyNDEuMS4zIGZvciB0 aGUgc3ViLWF0dHJpYnV0ZSDigJhPdXRwdXQtT2N0ZXRz4oCZDQoNCjI0MS4xLjQgZm9yIHRoZSBz dWItYXR0cmlidXRlIOKAmElucHV0LVBhY2tldHPigJkNCg0KMjQxLjEuNSBmb3IgdGhlIHN1Yi1h dHRyaWJ1dGUg4oCYT3V0cHV0LVBhY2tldHPigJkNCg0KDQoNCkkgd29uZGVyIHRoZSBzcGFjZSBv ZiAyNDEuMS54IChyYXRoZXIgdGhhbiAyNDEueCkgaXMgcmVhZHkgZm9yIElBTkEgdG8gYXNzaWdu IG91dC4NCg0KDQoNCkFueSBtb3JlIGNvbW1lbnRzPw0KDQoNCg0KDQoNCkJlc3QgUmVnYXJkcywN Cg0KTGVhZg0KDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiByYWRl eHQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJhZGV4dC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQWxhbiBEZUtvaw0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMDEsIDIwMTEgNToz MCBQTQ0KVG86IExlYWYgeWVoDQpDYzogcmFkZXh0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Jh ZGV4dF0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteWVoLXJhZGV4dC1l eHQtdHJhZmZpYy1zdGF0aXN0aWNzLTAxLnR4dA0KDQoNCg0KTGVhZiB5ZWggd3JvdGU6DQoNCj4g RGVhciBHcm91cCwNCg0KPg0KDQo+IDEuIGRyYWZ0LXllaC1yYWRleHQtZXh0LXRyYWZmaWMtc3Rh dGlzdGljcy0wMSBpcyByZWFkeSBmb3IgeW91ciBjb21tZW50IG9uIHdoZXRoZXIgaXQgZGVzZXJ2 ZXMgYSBXRyBpdGVtIGF0IFJBREVYVC4NCg0KPg0KDQo+IDIuIEl0IGRlZmluZWQgOCBuZXcgYXR0 cmlidXRlcyBvZiB0cmFmZmljIHN0YXRpc3RpY3MgZm9yIHRoZSBzZXBhcmF0ZSBJUHY0ICYgSVB2 NiBzdGFjayAocXVldWUgb3IgY291bnRlciksIGFuZCBlbXBsb3llZCB0aGUgbmV3IGRhdGUgdHlw ZSBvZiBpbnRlZ2VyNjQsIGJ1dCB0aGUgZm9ybWF0IG9mIG5ldyBhdHRyaWJ1dGVzIG1pZ2h0IGJl IHN0aWxsIGEgcXVlc3Rpb24gbm93LiBJdCBoYXMgMiBvcHRpb25zIG5vdzogIGEuIHRoZSB0cmFk aXRpb25hbCBmb3JtYXQgZGVmaW5lZCBpbiBbUkZDMjg2NV07ICBiLiB0aGUgbmV3IGV4dGVuZGVk IGZvcm1hdCBkZWZpbmVkIGluIFtkcmFmdC1pZXRmLXJhZGV4dC1yYWRpdXMtZXh0ZW5zaW9ucy0w Ml0uDQoNCg0KDQogIExvb2tpbmcgYXQgdGhlIG5hbWVzIG9mIHRoZSBuZXcgYXR0cmlidXRlczoN Cg0KDQoNCiAgICAgIEFjY3QtSW5wdXQtSVB2NC1PY3RldHMNCg0KICAgICAgQWNjdC1PdXRwdXQt SVB2NC1PY3RldHMNCg0KICAgICAgQWNjdC1JbnB1dC1JUHY0LVBhY2tldHMNCg0KICAgICAgQWNj dC1PdXRwdXQtSVB2NC1QYWNrZXRzDQoNCiAgICAgIEFjY3QtSW5wdXQtSVB2Ni1PY3RldHMNCg0K ICAgICAgQWNjdC1PdXRwdXQtSVB2Ni1PY3RldHMNCg0KICAgICAgQWNjdC1JbnB1dC1JUHY2LVBh Y2tldHMNCg0KICAgICAgQWNjdC1PdXRwdXQtSVB2Ni1QYWNrZXRzDQoNCg0KDQogIFRoZXkncmUg b2YgdGhlIGZvcm06DQoNCg0KDQogICAgICAgICBBY2N0LSBJbnB1dC9PdXRwdXQgLSBJUHY0L0lQ djYgLSBQYWNrZXRzL09jdGV0cw0KDQoNCg0KICBUaGlzIGxvb2tzIGxpa2UgYSBnb29kIGNhc2Ug Zm9yIGdyb3VwaW5nIGJ5IHR5cGUsIHdoaWNoIG1lYW5zIFRMVnMuDQoNCklmIHlvdSB1c2UgdGhl IG5ldyBmb3JtYXQsIFRMVnMgd291bGQgYmUgcHJlZmVycmVkIHRvIHVzaW5nIGEgImZsYXQiDQoN Cm5hbWUgc3BhY2UsIGFuZCBhbGxvY2F0aW5nIDggYXR0cmlidXRlcyBmcm9tIHRoYXQgc3BhY2Uu DQoNCg0KDQogIE9uZSBvcHRpb24gd291bGQgYmUgdG8gZGVmaW5lIHR3byBhdHRyaWJ1dGVzOiAi QWNjdC1JbnB1dC1TdGF0cyIgYW5kDQoNCkFjY3QtT3V0cHV0LVN0YXRzIi4gIFRoZXkgY291bGQg YmUgPiAyNTIgb2N0ZXRzIGxvbmcsIGFuZCBjb250YWluIFRMVnMuDQoNClRoZXkgY291bGQgc2hh cmUgdGhlIHNhbWUgc2V0IG9mIHN1Yi1UTFZzLg0KDQoNCg0KICBUaGUgc3ViLVRMVnMgY291bGQg YmU6DQoNCg0KDQogICAgICAgICBBY2N0LUlQdjQtU3RhdHMgICAgICAgZm9yIElQdjQgZGF0YQ0K DQogICAgICAgICBBY2N0LUlQdjYtU3RhdHMgICAgICAgZm9yIElQdjYgZGF0YQ0KDQoNCg0KICBU aG9zZSBzdWItVExWcyBpbiB0dXJuIGNvdWxkIGNvbnRhaW46DQoNCg0KDQogICAgICAgICBBY2N0 LVBhY2tldC1TdGF0cw0KDQogICAgICAgICBBY2N0LU9jdGV0LVN0YXRzDQoNCg0KDQogIFRoZSBB Y2N0LUlucHV0LUlQdjQtT2N0ZXRzIGF0dHJpYnV0ZSB5b3UgZGVmaW5lIHdvdWxkIHRoZW4gbWFw IHRvOg0KDQoNCg0KICAgICAgICAgQWNjdC1JbnB1dC1TdGF0cyAoIEFjY3QtSVA0LVN0YXRzICgg QWNjdC1QYWNrZXQtU3RhdHMgKHZhbHVlKSkpDQoNCg0KDQogIFRoaXMgdXNlcyBtb3JlIHNwYWNl IGluIHRoZSBwYWNrZXQsIGJ1dCBpcyBtb3JlIGdlbmVyYWwuICBPdGhlcg0KDQpzcGVjaWZpY2F0 aW9ucyBjb3VsZCBhZGQgVENQIHN0YXRzLCBVRFAgc3RhdHMsIGV0Yy4NCg0KDQoNCllvdSBtZW50 aW9uIGRyYWZ0LXdpbnRlci1yYWRleHQtZmFuY3lhY2NvdW50aW5nLTAwLiAgSSBoYXZlbid0DQoN CmNvbXBhcmVkIHRoZSB0d28gZG9jdW1lbnRzIGluIGRldGFpbCwgYnV0IEknZCBsaWtlIHRvIGtu b3cgd2hhdCBvdmVybGFwDQoNCihpZiBhbnkpIGV4aXN0cyBiZXR3ZWVuIHRoZW0uICBIYXZpbmcg dGhlIFdHIGNvbnZlcmdlIG9uIG9uZSBwcm9wb3NhbA0KDQp3b3VsZCBiZSBhIGdvb2QgdGhpbmcu DQoNCg0KDQogIEFsYW4gRGVLb2suDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCnJhZGV4dCBtYWlsaW5nIGxpc3QNCg0KcmFkZXh0QGlldGYub3Jn DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0DQo= --Boundary_(ID_EoiwDGbqZEoJ3ivEXk1Y+A) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlm eTsNCgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNv UGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi57qv 5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpw Lk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdy YXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0aWZ5OmludGVyLWlk ZW9ncmFwaDsNCgl0ZXh0LWluZGVudDoyMS4wcHQ7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5bGUt bmFtZToi57qv5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazrnuq/mlofmnKw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlO30N CnNwYW4ud29yZA0KCXttc28tc3R5bGUtbmFtZTp3b3JkO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KLyogUGFnZSBE ZWZpbml0aW9ucyAqLw0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBs MA0KCXttc28tbGlzdC1pZDoxOTExNDI0ODY5Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczotMTU2MTg0NDA3OCA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9 DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+BrDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjEuMHB0Ow0KCXRleHQtaW5kZW50 Oi0yMS4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0 LWlkOjE5NzA3NDUzNTA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjEwOTEyMTYxNzYgLTE5NzU3Mjg5NjQgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMg Njc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDE6 bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozOC40cHQ7DQoJdGV4dC1pbmRlbnQ6LTE5LjJwdDt9 DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoyMDE2MzAyNTQ0Ow0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjUyOTUyMzM0IC0xOTc1NzI4OTY0IDY3Njk4 NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEz IDY3Njk4NzE1O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTkuMnB0Ow0K CXRleHQtaW5kZW50Oi0xOS4ycHQ7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MjExMTU4NjE2 MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE0NTMw NjI3NjIgLTE5NzU3Mjg5NjQgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2 OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN CgltYXJnaW4tbGVmdDoxOS4ycHQ7DQoJdGV4dC1pbmRlbnQ6LTE5LjJwdDt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9InRleHQt anVzdGlmeS10cmltOnB1bmN0dWF0aW9uIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QWxhbiAtIFRoaXMgbG9v a3MgbGlrZSBhIGdvb2QgY2FzZSBmb3IgZ3JvdXBpbmcgYnkgdHlwZSwgd2hpY2ggbWVhbnMgVExW cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+VGhlIEFjY3QtSW5wdXQtSVB2NC08c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5P Y3RldHM8L3NwYW4+IGF0dHJpYnV0ZSB5b3UgZGVmaW5lIHdvdWxkIHRoZW4gbWFwIHRvOg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPkFjY3QtSW5wdXQtU3RhdHMgKCBBY2N0LUlQNC1TdGF0cyAoIEFjY3QtPHNwYW4gc3R5 bGU9ImNvbG9yOnJlZCI+UGFja2V0PC9zcGFuPi1TdGF0cyAodmFsdWUpKSk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPlRoYW5rcyB0byBkcmFmdC1pZXRmLXJhZGV4dC1yYWRpdXMtZXh0ZW5zaW9u cy0wMiwgd2UndmUgZ290IHRoZSBhbHRlcm5hdGl2ZSBtZXRob2QgdG8gZGVmaW5lIHRoZSBuZXcg YXR0cmlidXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QnV0IHRoZSBhcmd1bWVudHMgY291 bGQgYmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOS4ycHQ7dGV4dC1pbmRlbnQ6LTE5LjJw dDttc28tbGlzdDpsMiBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBs YW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9 IkVOLVVTIj5UaGUgdHlwZS1zcGFjZSBvZiB0aGUgYXR0cmlidXRlIGhhcyBleHRlbmRlZCBtdWNo IGFmdGVyIGFkb3B0ZWQgdGhlIEV4dGVuZGVkIHR5cGUgKDI0MS0yNDQpLCB0aGUgdW5hc3NpZ25l ZCB0eXBlIHNwYWNlIHR1cm4gdG8gYmUgMTAwMz0xOTEtMTQ0ICYjNDM7IDQqKDI0MC0xKS4gV2Ug Y2FuIHVzZSBpdCBqdXN0IGRpcmVjdGx5IGluIGZsYXQgbW9kZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTkuMnB0O3Rl eHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTku MnB0O3RleHQtaW5kZW50Oi0xOS4ycHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzE7dGV4dC1hdXRv c3BhY2U6bm9uZSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgYWJv dmUgbWFwIG9mIOKAmEFjY3QtSW5wdXQtU3RhdHMgKCBBY2N0LUlQNC1TdGF0cyAoIEFjY3QtUGFj a2V0LVN0YXRzICh2YWx1ZSkpKeKAmSBzb3VuZCBUTFYgbmVzdGluZywgYnV0IEkgZ3Vlc3MgVExW IGdyb3VwaW5nIChjb250YWluZXIgbW9kZSkgc291bmRzIGJldHRlciB0aG91Z2ggaXQgaXMgYSBs aXR0bGUgbW9yZSBjb21wbGV4IHRoYW4gdGhlIGZsYXQNCiBtb2RlIC4gPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHls ZT0ibWFyZ2luLWxlZnQ6MTkuMnB0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIGxhbmc9IkVO LVVTIj5UaGF0IG1pZ2h0IG1lYW5zDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTkuMnB0Ij48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyBJbnB1dC1PY3RldHMgKDEweCBv Y3RldHMsIFRMVik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IE91dHB1dC1PY3RldHMgKDEw eCBvY3RldHMsIFRMVik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IElucHV0LVBhY2tldHMg KDEweCBvY3RldHMsIFRMVik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IE91dHB1dC1QYWNr ZXRzICgxMHggb2N0ZXRzLCBUTFYpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE5LjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxOS4ycHQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gbGFuZz0i RU4tVVMiPmNvdWxkIGJlIHRoZSBzdWItYXR0cmlidXRlcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOS4ycHQ7dGV4 dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOS4y cHQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gbGFuZz0iRU4tVVMiPklmIG9uZSBtb3JlIOKA mFRyYWZmaWMtVHlwZeKAmShzdWItYXR0cmlidXRlLCAzeCBvY3RldHMsIFRMVikgY291bGQgYmUg aW5jbHVkZWQgaW50byB0aGUgY29udGFpbmVyIOKAmEFjY3QtdHJhZmZpYy1zdGF0aXN0aWNz4oCZ LCByZWZlcnJlZCB0byB0aGUgZHJhZnQtd2ludGVyLXJhZGV4LWZhbmN5YWNjb3VudGluZy0wMCwN CiB0aGVuIHRoZSBjb250YWluZXIgd291bGQgZ2V0IHRoZSBleHRlbnNpYmlsaXR5IGZvciB2YXJp b3VzIGtpbmRzIChlZy4gSVB2NCwgSVB2Nikgb2YgdHJhZmZpYyBzdGF0aXN0aWNzIHBlciB0aGUg 4oCYVHJhZmZpYy1UeXBl4oCZLCBhbmQgZXZlbiBmb3Igc29tZSBkZW1hbmRzIChlZy4gRFNDUCBt ZW50aW9uZWQgaW4gdGhlIGFib3ZlIGRyYWZ0LCBvciBUQ1AsIFVEUCBtZW50aW9uZWQgYmVsb3cp IGluIHRoZSBmdXR1cmUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTkuMnB0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTkuMnB0O3RleHQtYXV0b3NwYWNlOm5v bmUiPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiB0aGlzIGRlc2lnbiwgdGhlIGxlbmd0aCBvZiB0aGUg Y29udGFpbmVyIHdpbGwgbmV2ZXIgZXhjZXNzIDI1MiBvY3RldHMsIHRoZW4gdGhlIGNvbnRhaW5l ciDigJhBY2N0LXRyYWZmaWMtc3RhdGlzdGljc+KAmSBjb3VsZCB1c2UgdGhlIGZvcm1hdCBvZiBF eHRlbmRlZC1UeXBlICgyNDEpLiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTkuMnB0O3RleHQtYXV0b3NwYWNl Om5vbmUiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTkuMnB0O3RleHQtaW5k ZW50Oi0xOS4ycHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzE7dGV4dC1hdXRvc3BhY2U6bm9uZSI+ DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIj5EbyB3ZSBhbHJlYWR5IGhhdmUg YW55IGNvbnRhaW5lciBhdHRyaWJ1dGUgZGVmaW5lZCBpbiBSRkM/IEkgY2Fu4oCZdCBmaW5kIHRo aXMga2luZCBvZiBhdHRyaWJ1dGUgaW4gSUFOQSB3ZWIgcGFnZS4gKDxhIGhyZWY9Imh0dHA6Ly93 d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvcmFkaXVzLXR5cGVzL3JhZGl1cy10eXBlcy54bWwiPjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwOi8v d3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3JhZGl1cy10eXBlcy9yYWRpdXMtdHlwZXMueG1sPC9z cGFuPjwvYT4pLg0KIEkgd29uZGVyIHRoZSBSYWRpdXMgY29tbXVuaXR5ICZhbXA7IFdHIHdvdWxk IGxpa2UgdGhpcyBjb21wbGV4aXR5IG9mIGludGVycHJldGF0aW9uIGFnYWluc3QgMS0yIG1vcmUg bGV2ZWxzIG9mIG5lc3RpbmcgYW5kIGNvbWJpbmF0aW9uLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE5LjJwdDt0ZXh0 LWF1dG9zcGFjZTpub25lIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE5LjJw dDt0ZXh0LWluZGVudDotMTkuMnB0O21zby1saXN0OmwyIGxldmVsMSBsZm8xO3RleHQtYXV0b3Nw YWNlOm5vbmUiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjQuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+QXMgdG8gdGhl IGNvZGUgYXNzaWdubWVudCBmb3IgdGhpcyBuZXcgdHlwZSBvZiBjb250YWluZXIgYXR0cmlidXRl IHByb3Bvc2VkIGZvciBJQU5BIGNvbnNpZGVyYXRpb24sIGl0IG1pZ2h0IGJlDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIj48c3BhbiBsYW5nPSJFTi1VUyI+MjQxLjEgZm9yIHRoZSB0aGUgY29udGFpbmVyIOKAmEFj Y3QtdHJhZmZpYy1zdGF0aXN0aWNz4oCZPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIj4yNDEuMS4xIGZvciB0aGUgc3Vi LWF0dHJpYnV0ZSDigJhUcmFmZmljLVR5cGXigJk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0idGV4dC1pbmRlbnQ6MjEuMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+MjQxLjEuMiBmb3IgdGhlIHN1Yi1hdHRyaWJ1dGUg4oCYSW5wdXQtT2N0ZXRz4oCZ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9InRl eHQtaW5kZW50OjIxLjZwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjI0MS4xLjMgZm9yIHRoZSBzdWIt YXR0cmlidXRlIOKAmE91dHB1dC1PY3RldHPigJk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0idGV4dC1pbmRlbnQ6MjEuNnB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+MjQxLjEuNCBmb3IgdGhlIHN1Yi1hdHRyaWJ1dGUg4oCYSW5wdXQtUGFja2V0c+KA mTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJ0 ZXh0LWluZGVudDoyMS42cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4yNDEuMS41IGZvciB0aGUgc3Vi LWF0dHJpYnV0ZSDigJhPdXRwdXQtUGFja2V0c+KAmTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJ0ZXh0LWluZGVudDoyMS42cHQiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0idGV4dC1pbmRlbnQ6MjEuNnB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SSB3 b25kZXIgdGhlIHNwYWNlIG9mIDI0MS4xLnggKHJhdGhlciB0aGFuIDI0MS54KSBpcyByZWFkeSBm b3IgSUFOQSB0byBhc3NpZ24gb3V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkFueSBtb3JlIGNvbW1lbnRzPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlc3QgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+TGVhZjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPGJyPg0KRnJvbTogcmFkZXh0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpyYWRleHQtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsYW4gRGVLb2s8YnI+DQpTZW50OiBUdWVzZGF5 LCBOb3ZlbWJlciAwMSwgMjAxMSA1OjMwIFBNPGJyPg0KVG86IExlYWYgeWVoPGJyPg0KQ2M6IHJh ZGV4dEBpZXRmLm9yZzxicj4NClN1YmplY3Q6IFJlOiBbcmFkZXh0XSBGVzogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC15ZWgtcmFkZXh0LWV4dC10cmFmZmljLXN0YXRpc3RpY3Mt MDEudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5MZWFmIHllaCB3cm90ZTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ Jmd0OyBEZWFyIEdyb3VwLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDEuIGRyYWZ0LXll aC1yYWRleHQtZXh0LXRyYWZmaWMtc3RhdGlzdGljcy0wMSBpcyByZWFkeSBmb3IgeW91ciBjb21t ZW50IG9uIHdoZXRoZXIgaXQgZGVzZXJ2ZXMgYSBXRyBpdGVtIGF0IFJBREVYVC4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDIuIEl0IGRlZmluZWQgOCBuZXcgYXR0cmlidXRlcyBvZiB0 cmFmZmljIHN0YXRpc3RpY3MgZm9yIHRoZSBzZXBhcmF0ZSBJUHY0ICZhbXA7IElQdjYgc3RhY2sg KHF1ZXVlIG9yIGNvdW50ZXIpLCBhbmQgZW1wbG95ZWQgdGhlIG5ldyBkYXRlIHR5cGUgb2YgaW50 ZWdlcjY0LCBidXQgdGhlIGZvcm1hdCBvZiBuZXcgYXR0cmlidXRlcyBtaWdodCBiZSBzdGlsbCBh IHF1ZXN0aW9uDQogbm93LiBJdCBoYXMgMiBvcHRpb25zIG5vdzombmJzcDsgYS4gdGhlIHRyYWRp dGlvbmFsIGZvcm1hdCBkZWZpbmVkIGluIFtSRkMyODY1XTsmbmJzcDsgYi4gdGhlIG5ldyBleHRl bmRlZCBmb3JtYXQgZGVmaW5lZCBpbiBbZHJhZnQtaWV0Zi1yYWRleHQtcmFkaXVzLWV4dGVuc2lv bnMtMDJdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7IExvb2tpbmcgYXQgdGhlIG5h bWVzIG9mIHRoZSBuZXcgYXR0cmlidXRlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBY2N0LUlucHV0LUlQdjQtT2N0ZXRzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBY2N0LU91dHB1dC1JUHY0LU9jdGV0czxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQWNjdC1JbnB1dC1JUHY0LVBh Y2tldHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFjY3QtT3V0cHV0 LUlQdjQtUGFja2V0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQWNj dC1JbnB1dC1JUHY2LU9jdGV0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgQWNjdC1PdXRwdXQtSVB2Ni1PY3RldHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEFjY3QtSW5wdXQtSVB2Ni1QYWNrZXRzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBBY2N0LU91dHB1dC1JUHY2LVBhY2tldHM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOyBUaGV5J3JlIG9mIHRoZSBmb3JtOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFj Y3QtIElucHV0L091dHB1dCAtIElQdjQvSVB2NiAtIFBhY2tldHMvT2N0ZXRzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsgVGhpcyBsb29rcyBsaWtlIGEgZ29vZCBjYXNlIGZvciBncm91 cGluZyBieSB0eXBlLCB3aGljaCBtZWFucyBUTFZzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB5b3UgdXNlIHRoZSBu ZXcgZm9ybWF0LCBUTFZzIHdvdWxkIGJlIHByZWZlcnJlZCB0byB1c2luZyBhICZxdW90O2ZsYXQm cXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+bmFtZSBzcGFjZSwgYW5kIGFsbG9jYXRpbmcgOCBhdHRyaWJ1dGVzIGZy b20gdGhhdCBzcGFjZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyBPbmUgb3B0aW9u IHdvdWxkIGJlIHRvIGRlZmluZSB0d28gYXR0cmlidXRlczogJnF1b3Q7QWNjdC1JbnB1dC1TdGF0 cyZxdW90OyBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+QWNjdC1PdXRwdXQtU3RhdHMmcXVvdDsuJm5ic3A7IFRoZXkg Y291bGQgYmUgJmd0OyAyNTIgb2N0ZXRzIGxvbmcsIGFuZCBjb250YWluIFRMVnMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PlRoZXkgY291bGQgc2hhcmUgdGhlIHNhbWUgc2V0IG9mIHN1Yi1UTFZzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7IFRoZSBzdWItVExWcyBjb3VsZCBiZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBBY2N0LUlQdjQtU3RhdHMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZm9y IElQdjQgZGF0YTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgQWNjdC1JUHY2LVN0YXRzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGZvciBJUHY2IGRhdGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyBUaG9z ZSBzdWItVExWcyBpbiB0dXJuIGNvdWxkIGNvbnRhaW46PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQWNjdC1Q YWNrZXQtU3RhdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEFjY3QtT2N0ZXQtU3RhdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOyBUaGUgQWNjdC1JbnB1dC1JUHY0LU9jdGV0cyBhdHRyaWJ1dGUgeW91IGRlZmluZSB3b3Vs ZCB0aGVuIG1hcCB0bzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBY2N0LUlucHV0LVN0YXRzICggQWNjdC1J UDQtU3RhdHMgKCBBY2N0LVBhY2tldC1TdGF0cyAodmFsdWUpKSk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOyBUaGlzIHVzZXMgbW9yZSBzcGFjZSBpbiB0aGUgcGFja2V0LCBidXQgaXMg bW9yZSBnZW5lcmFsLiZuYnNwOyBPdGhlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5zcGVjaWZpY2F0aW9ucyBjb3VsZCBh ZGQgVENQIHN0YXRzLCBVRFAgc3RhdHMsIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPllv dSBtZW50aW9uIGRyYWZ0LXdpbnRlci1yYWRleHQtZmFuY3lhY2NvdW50aW5nLTAwLiZuYnNwOyBJ IGhhdmVuJ3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+Y29tcGFyZWQgdGhlIHR3byBkb2N1bWVudHMgaW4gZGV0YWlsLCBi dXQgSSdkIGxpa2UgdG8ga25vdyB3aGF0IG92ZXJsYXA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+KGlmIGFueSkgZXhpc3Rz IGJldHdlZW4gdGhlbS4mbmJzcDsgSGF2aW5nIHRoZSBXRyBjb252ZXJnZSBvbiBvbmUgcHJvcG9z YWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+d291bGQgYmUgYSBnb29kIHRoaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7IEFsYW4gRGVLb2suPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPnJhZGV4dCBtYWlsaW5nIGxpc3Q8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+cmFkZXh0QGlldGYub3JnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcmFkZXh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --Boundary_(ID_EoiwDGbqZEoJ3ivEXk1Y+A)-- From aland@deployingradius.com Wed Nov 9 22:51:04 2011 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 E0ADD21F8476 for ; Wed, 9 Nov 2011 22:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 9Q72yzuNyStI for ; Wed, 9 Nov 2011 22:51:04 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id C299311E8088 for ; Wed, 9 Nov 2011 22:51:03 -0800 (PST) Message-ID: <4EBB7439.7040403@deployingradius.com> Date: Thu, 10 Nov 2011 07:50:33 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <4EAFBC28.40902@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "radext@ietf.org" , "fine_sz@huawei.com" Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-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: Thu, 10 Nov 2011 06:51:05 -0000 Leaf yeh wrote: > 1. The type-space of the attribute has extended much after adopted > the Extended type (241-244), the unassigned type space turn to be > 1003=191-144 + 4*(240-1). We can use it just directly in flat mode. Hmm... the purpose of adding TLVs is to group similar attributes, and to allow later extensions of the same group. My response showed how that could be done. Using a flat mode means that the attributes have no logical relationship, and cannot be meaningfully extended. > If one more ‘Traffic-Type’(sub-attribute, 3x octets, TLV) could be > included into the container ‘Acct-traffic-statistics’, referred to the > draft-winter-radex-fancyaccounting-00, then the container would get the > extensibility for various kinds (eg. IPv4, IPv6) of traffic statistics > per the ‘Traffic-Type’, and even for some demands (eg. DSCP mentioned in > the above draft, or TCP, UDP mentioned below) in the future. I think so. > 3. Do we already have any container attribute defined in RFC? I > can’t find this kind of attribute in IANA web page. > (http://www.iana.org/assignments/radius-types/radius-types.xml). I > wonder the Radius community & WG would like this complexity of > interpretation against 1-2 more levels of nesting and combination. Stefan's "fancy accounting" draft had positive feedback in this WG. > 4. As to the code assignment for this new type of container > attribute proposed for IANA consideration, it might be Code assignment is done by IANA. The exact values for the numbers don't matter, and aren't up for discussion. > I wonder the space of 241.1.x (rather than 241.x) is ready for IANA to > assign out. The extended attributes draft explains in great detail how IANA assigns attributes, including new TLVs. Please read it. The numbers are not ready for IANA to assign, because the draft has not been published. Alan DeKok. From radext-bounces@ietf.org Wed Nov 9 22:51:06 2011 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 E4E8C21F8485; Wed, 9 Nov 2011 22:51:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320907865; bh=cRF/GCPpXRy3psk2BtZVWXy3mL1YOLuQ+0PBDPp0zFs=; 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=p9oQ0xxdTOgvak+hFBKdMAeXx8GuAN1EvdH1QmKTsJho48EL7DxCsGSEHSHjhDTrL dmEImYP4tUiDv8JOE9QPvGmGcZsDZHDjV8JHDL/myu0kYo33z97dIfF/D9R/zSRmYX OmfbAJO0Hm5eZeoJze91BHzOdkn7mHuxrbjRSpXw= 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 E0ADD21F8476 for ; Wed, 9 Nov 2011 22:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 9Q72yzuNyStI for ; Wed, 9 Nov 2011 22:51:04 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id C299311E8088 for ; Wed, 9 Nov 2011 22:51:03 -0800 (PST) Message-ID: <4EBB7439.7040403@deployingradius.com> Date: Thu, 10 Nov 2011 07:50:33 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <4EAFBC28.40902@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" , "fine_sz@huawei.com" Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org TGVhZiB5ZWggd3JvdGU6Cj4gMS4gICAgICBUaGUgdHlwZS1zcGFjZSBvZiB0aGUgYXR0cmlidXRl IGhhcyBleHRlbmRlZCBtdWNoIGFmdGVyIGFkb3B0ZWQKPiB0aGUgRXh0ZW5kZWQgdHlwZSAoMjQx LTI0NCksIHRoZSB1bmFzc2lnbmVkIHR5cGUgc3BhY2UgdHVybiB0byBiZQo+IDEwMDM9MTkxLTE0 NCArIDQqKDI0MC0xKS4gV2UgY2FuIHVzZSBpdCBqdXN0IGRpcmVjdGx5IGluIGZsYXQgbW9kZS4K CiAgSG1tLi4uIHRoZSBwdXJwb3NlIG9mIGFkZGluZyBUTFZzIGlzIHRvIGdyb3VwIHNpbWlsYXIg YXR0cmlidXRlcywgYW5kCnRvIGFsbG93IGxhdGVyIGV4dGVuc2lvbnMgb2YgdGhlIHNhbWUgZ3Jv dXAuICBNeSByZXNwb25zZSBzaG93ZWQgaG93CnRoYXQgY291bGQgYmUgZG9uZS4gIFVzaW5nIGEg ZmxhdCBtb2RlIG1lYW5zIHRoYXQgdGhlIGF0dHJpYnV0ZXMgaGF2ZSBubwpsb2dpY2FsIHJlbGF0 aW9uc2hpcCwgYW5kIGNhbm5vdCBiZSBtZWFuaW5nZnVsbHkgZXh0ZW5kZWQuCgo+IElmIG9uZSBt b3JlIOKAmFRyYWZmaWMtVHlwZeKAmShzdWItYXR0cmlidXRlLCAzeCBvY3RldHMsIFRMVikgY291 bGQgYmUKPiBpbmNsdWRlZCBpbnRvIHRoZSBjb250YWluZXIg4oCYQWNjdC10cmFmZmljLXN0YXRp c3RpY3PigJksIHJlZmVycmVkIHRvIHRoZQo+IGRyYWZ0LXdpbnRlci1yYWRleC1mYW5jeWFjY291 bnRpbmctMDAsIHRoZW4gdGhlIGNvbnRhaW5lciB3b3VsZCBnZXQgdGhlCj4gZXh0ZW5zaWJpbGl0 eSBmb3IgdmFyaW91cyBraW5kcyAoZWcuIElQdjQsIElQdjYpIG9mIHRyYWZmaWMgc3RhdGlzdGlj cwo+IHBlciB0aGUg4oCYVHJhZmZpYy1UeXBl4oCZLCBhbmQgZXZlbiBmb3Igc29tZSBkZW1hbmRz IChlZy4gRFNDUCBtZW50aW9uZWQgaW4KPiB0aGUgYWJvdmUgZHJhZnQsIG9yIFRDUCwgVURQIG1l bnRpb25lZCBiZWxvdykgaW4gdGhlIGZ1dHVyZS4KCiAgSSB0aGluayBzby4KCj4gMy4gICAgICBE byB3ZSBhbHJlYWR5IGhhdmUgYW55IGNvbnRhaW5lciBhdHRyaWJ1dGUgZGVmaW5lZCBpbiBSRkM/ IEkKPiBjYW7igJl0IGZpbmQgdGhpcyBraW5kIG9mIGF0dHJpYnV0ZSBpbiBJQU5BIHdlYiBwYWdl Lgo+IChodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3JhZGl1cy10eXBlcy9yYWRpdXMt dHlwZXMueG1sKS4gSQo+IHdvbmRlciB0aGUgUmFkaXVzIGNvbW11bml0eSAmIFdHIHdvdWxkIGxp a2UgdGhpcyBjb21wbGV4aXR5IG9mCj4gaW50ZXJwcmV0YXRpb24gYWdhaW5zdCAxLTIgbW9yZSBs ZXZlbHMgb2YgbmVzdGluZyBhbmQgY29tYmluYXRpb24uCgogIFN0ZWZhbidzICJmYW5jeSBhY2Nv dW50aW5nIiBkcmFmdCBoYWQgcG9zaXRpdmUgZmVlZGJhY2sgaW4gdGhpcyBXRy4KCj4gNC4gICAg ICBBcyB0byB0aGUgY29kZSBhc3NpZ25tZW50IGZvciB0aGlzIG5ldyB0eXBlIG9mIGNvbnRhaW5l cgo+IGF0dHJpYnV0ZSBwcm9wb3NlZCBmb3IgSUFOQSBjb25zaWRlcmF0aW9uLCBpdCBtaWdodCBi ZQoKICBDb2RlIGFzc2lnbm1lbnQgaXMgZG9uZSBieSBJQU5BLiAgVGhlIGV4YWN0IHZhbHVlcyBm b3IgdGhlIG51bWJlcnMKZG9uJ3QgbWF0dGVyLCBhbmQgYXJlbid0IHVwIGZvciBkaXNjdXNzaW9u LgoKPiBJIHdvbmRlciB0aGUgc3BhY2Ugb2YgMjQxLjEueCAocmF0aGVyIHRoYW4gMjQxLngpIGlz IHJlYWR5IGZvciBJQU5BIHRvCj4gYXNzaWduIG91dC4KCiAgVGhlIGV4dGVuZGVkIGF0dHJpYnV0 ZXMgZHJhZnQgZXhwbGFpbnMgaW4gZ3JlYXQgZGV0YWlsIGhvdyBJQU5BCmFzc2lnbnMgYXR0cmli dXRlcywgaW5jbHVkaW5nIG5ldyBUTFZzLiAgUGxlYXNlIHJlYWQgaXQuCgogIFRoZSBudW1iZXJz IGFyZSBub3QgcmVhZHkgZm9yIElBTkEgdG8gYXNzaWduLCBiZWNhdXNlIHRoZSBkcmFmdCBoYXMK bm90IGJlZW4gcHVibGlzaGVkLgoKICBBbGFuIERlS29rLgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpyYWRleHQgbWFpbGluZyBsaXN0CnJhZGV4dEBpZXRm Lm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JhZGV4dAo= From leaf.y.yeh@huawei.com Wed Nov 9 23:23:44 2011 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 054BE11E80A4 for ; Wed, 9 Nov 2011 23:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 pDyLx0Wtw478 for ; Wed, 9 Nov 2011 23:23:42 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2A28D11E8088 for ; Wed, 9 Nov 2011 23:23:42 -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 <0LUF006LSOG8D0@szxga04-in.huawei.com> for radext@ietf.org; Thu, 10 Nov 2011 15:21:44 +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 <0LUF006E4OG2OU@szxga04-in.huawei.com> for radext@ietf.org; Thu, 10 Nov 2011 15:21:44 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEW68938; Thu, 10 Nov 2011 15:21:24 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 10 Nov 2011 15:21:19 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.62]) by szxeml405-hub.china.huawei.com ([10.82.67.60]) with mapi id 14.01.0270.001; Thu, 10 Nov 2011 15:21:16 +0800 Date: Thu, 10 Nov 2011 07:21:15 +0000 From: Leaf yeh In-reply-to: <4EBB7439.7040403@deployingradius.com> X-Originating-IP: [10.70.39.98] To: Alan DeKok 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] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-01.txt Thread-index: AQHMn3Ujy7tGf93J9UaXZF8aR/wRWJWlrVbw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EAFBC28.40902@deployingradius.com> <4EBB7439.7040403@deployingradius.com> Cc: "radext@ietf.org" , "fine_sz@huawei.com" Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-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: Thu, 10 Nov 2011 07:23:44 -0000 QWxhbiAtIFN0ZWZhbidzICJmYW5jeSBhY2NvdW50aW5nIiBkcmFmdCBoYWQgcG9zaXRpdmUgZmVl ZGJhY2sgaW4gdGhpcyBXRy4NCg0KRllJIC0gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5n cy84MS9taW51dGVzL3JhZGV4dC50eHQgDQpQbHMuIHJlYWQgdGhlIG1pbnV0ZXMgb24gdGhlIE5v LjQtUkFESVVTIGFjY291bnRpbmcgZm9yIHRyYWZmaWMgY2xhc3Nlcy4NCg0KQWxhbiAtIENvZGUg YXNzaWdubWVudCBpcyBkb25lIGJ5IElBTkEuIFRoZSBleGFjdCB2YWx1ZXMgZm9yIHRoZSBudW1i ZXJzIGRvbid0IG1hdHRlci4NCg0KUGVyIHNlY3Rpb24gOS4xIG9mIGRyYWZ0LWlldGYtcmFkZXh0 LXJhZGl1cy1leHRlbnNpb25zLTAyLCB0aGUgcHJvcG9zYWwgc2hvd24gYXMgYW4gZXhhbXBsZSBv ZiBjb2RlIGFzc2lnbm1lbnQgY291bGQgYmUgYSBwb3NzaWJsZSAob3IgY29tcGxpYW50KSBjYXNl LiBSaWdodD8NCg0KDQpCZXN0IFJlZ2FyZHMsDQpMZWFmDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IHJhZGV4dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cmFkZXh0LWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGFuIERlS29rDQpTZW50OiBUaHVyc2RheSwg Tm92ZW1iZXIgMTAsIDIwMTEgMjo1MSBQTQ0KVG86IExlYWYgeWVoDQpDYzogcmFkZXh0QGlldGYu b3JnOyBmaW5lX3N6QGh1YXdlaS5jb20NClN1YmplY3Q6IFJlOiBbcmFkZXh0XSBGVzogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC15ZWgtcmFkZXh0LWV4dC10cmFmZmljLXN0YXRp c3RpY3MtMDEudHh0DQoNCkxlYWYgeWVoIHdyb3RlOg0KPiAxLiAgICAgIFRoZSB0eXBlLXNwYWNl IG9mIHRoZSBhdHRyaWJ1dGUgaGFzIGV4dGVuZGVkIG11Y2ggYWZ0ZXIgYWRvcHRlZA0KPiB0aGUg RXh0ZW5kZWQgdHlwZSAoMjQxLTI0NCksIHRoZSB1bmFzc2lnbmVkIHR5cGUgc3BhY2UgdHVybiB0 byBiZQ0KPiAxMDAzPTE5MS0xNDQgKyA0KigyNDAtMSkuIFdlIGNhbiB1c2UgaXQganVzdCBkaXJl Y3RseSBpbiBmbGF0IG1vZGUuDQoNCiAgSG1tLi4uIHRoZSBwdXJwb3NlIG9mIGFkZGluZyBUTFZz IGlzIHRvIGdyb3VwIHNpbWlsYXIgYXR0cmlidXRlcywgYW5kDQp0byBhbGxvdyBsYXRlciBleHRl bnNpb25zIG9mIHRoZSBzYW1lIGdyb3VwLiAgTXkgcmVzcG9uc2Ugc2hvd2VkIGhvdw0KdGhhdCBj b3VsZCBiZSBkb25lLiAgVXNpbmcgYSBmbGF0IG1vZGUgbWVhbnMgdGhhdCB0aGUgYXR0cmlidXRl cyBoYXZlIG5vDQpsb2dpY2FsIHJlbGF0aW9uc2hpcCwgYW5kIGNhbm5vdCBiZSBtZWFuaW5nZnVs bHkgZXh0ZW5kZWQuDQoNCj4gSWYgb25lIG1vcmUg4oCYVHJhZmZpYy1UeXBl4oCZKHN1Yi1hdHRy aWJ1dGUsIDN4IG9jdGV0cywgVExWKSBjb3VsZCBiZQ0KPiBpbmNsdWRlZCBpbnRvIHRoZSBjb250 YWluZXIg4oCYQWNjdC10cmFmZmljLXN0YXRpc3RpY3PigJksIHJlZmVycmVkIHRvIHRoZQ0KPiBk cmFmdC13aW50ZXItcmFkZXgtZmFuY3lhY2NvdW50aW5nLTAwLCB0aGVuIHRoZSBjb250YWluZXIg d291bGQgZ2V0IHRoZQ0KPiBleHRlbnNpYmlsaXR5IGZvciB2YXJpb3VzIGtpbmRzIChlZy4gSVB2 NCwgSVB2Nikgb2YgdHJhZmZpYyBzdGF0aXN0aWNzDQo+IHBlciB0aGUg4oCYVHJhZmZpYy1UeXBl 4oCZLCBhbmQgZXZlbiBmb3Igc29tZSBkZW1hbmRzIChlZy4gRFNDUCBtZW50aW9uZWQgaW4NCj4g dGhlIGFib3ZlIGRyYWZ0LCBvciBUQ1AsIFVEUCBtZW50aW9uZWQgYmVsb3cpIGluIHRoZSBmdXR1 cmUuDQoNCiAgSSB0aGluayBzby4NCg0KPiAzLiAgICAgIERvIHdlIGFscmVhZHkgaGF2ZSBhbnkg Y29udGFpbmVyIGF0dHJpYnV0ZSBkZWZpbmVkIGluIFJGQz8gSQ0KPiBjYW7igJl0IGZpbmQgdGhp cyBraW5kIG9mIGF0dHJpYnV0ZSBpbiBJQU5BIHdlYiBwYWdlLg0KPiAoaHR0cDovL3d3dy5pYW5h Lm9yZy9hc3NpZ25tZW50cy9yYWRpdXMtdHlwZXMvcmFkaXVzLXR5cGVzLnhtbCkuIEkNCj4gd29u ZGVyIHRoZSBSYWRpdXMgY29tbXVuaXR5ICYgV0cgd291bGQgbGlrZSB0aGlzIGNvbXBsZXhpdHkg b2YNCj4gaW50ZXJwcmV0YXRpb24gYWdhaW5zdCAxLTIgbW9yZSBsZXZlbHMgb2YgbmVzdGluZyBh bmQgY29tYmluYXRpb24uDQoNCiAgU3RlZmFuJ3MgImZhbmN5IGFjY291bnRpbmciIGRyYWZ0IGhh ZCBwb3NpdGl2ZSBmZWVkYmFjayBpbiB0aGlzIFdHLg0KDQo+IDQuICAgICAgQXMgdG8gdGhlIGNv ZGUgYXNzaWdubWVudCBmb3IgdGhpcyBuZXcgdHlwZSBvZiBjb250YWluZXINCj4gYXR0cmlidXRl IHByb3Bvc2VkIGZvciBJQU5BIGNvbnNpZGVyYXRpb24sIGl0IG1pZ2h0IGJlDQoNCiAgQ29kZSBh c3NpZ25tZW50IGlzIGRvbmUgYnkgSUFOQS4gIFRoZSBleGFjdCB2YWx1ZXMgZm9yIHRoZSBudW1i ZXJzDQpkb24ndCBtYXR0ZXIsIGFuZCBhcmVuJ3QgdXAgZm9yIGRpc2N1c3Npb24uDQoNCj4gSSB3 b25kZXIgdGhlIHNwYWNlIG9mIDI0MS4xLnggKHJhdGhlciB0aGFuIDI0MS54KSBpcyByZWFkeSBm b3IgSUFOQSB0bw0KPiBhc3NpZ24gb3V0Lg0KDQogIFRoZSBleHRlbmRlZCBhdHRyaWJ1dGVzIGRy YWZ0IGV4cGxhaW5zIGluIGdyZWF0IGRldGFpbCBob3cgSUFOQQ0KYXNzaWducyBhdHRyaWJ1dGVz LCBpbmNsdWRpbmcgbmV3IFRMVnMuICBQbGVhc2UgcmVhZCBpdC4NCg0KICBUaGUgbnVtYmVycyBh cmUgbm90IHJlYWR5IGZvciBJQU5BIHRvIGFzc2lnbiwgYmVjYXVzZSB0aGUgZHJhZnQgaGFzDQpu b3QgYmVlbiBwdWJsaXNoZWQuDQoNCiAgQWxhbiBEZUtvay4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpyYWRleHQgbWFpbGluZyBsaXN0DQpyYWRleHRA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0DQo= From radext-bounces@ietf.org Wed Nov 9 23:23:46 2011 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 0A2A711E80A4; Wed, 9 Nov 2011 23:23:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320909826; bh=Hd854F0l0lynbsqnGIOZoY4M21xx0pflIQaPIIUQhW0=; 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=GxNi0a4CH1IDo16FR22Cm/87sC7qkX81plQccXlttQPOg1V5mTgg5EFmaFRozV47q DOJJfWHZIo60McKWNJeqxLeJyCU38WVSwKWYZ0M9B+uFV895ZzdEkFnWqcLlF/tHjF Rhqk7EqcU2lvBR4/LihcBDGOAvd5D/fKVUjMBz3w= 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 054BE11E80A4 for ; Wed, 9 Nov 2011 23:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 pDyLx0Wtw478 for ; Wed, 9 Nov 2011 23:23:42 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2A28D11E8088 for ; Wed, 9 Nov 2011 23:23:42 -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 <0LUF006LSOG8D0@szxga04-in.huawei.com> for radext@ietf.org; Thu, 10 Nov 2011 15:21:44 +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 <0LUF006E4OG2OU@szxga04-in.huawei.com> for radext@ietf.org; Thu, 10 Nov 2011 15:21:44 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEW68938; Thu, 10 Nov 2011 15:21:24 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 10 Nov 2011 15:21:19 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.62]) by szxeml405-hub.china.huawei.com ([10.82.67.60]) with mapi id 14.01.0270.001; Thu, 10 Nov 2011 15:21:16 +0800 Date: Thu, 10 Nov 2011 07:21:15 +0000 From: Leaf yeh In-reply-to: <4EBB7439.7040403@deployingradius.com> X-Originating-IP: [10.70.39.98] To: Alan DeKok Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-01.txt Thread-index: AQHMn3Ujy7tGf93J9UaXZF8aR/wRWJWlrVbw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EAFBC28.40902@deployingradius.com> <4EBB7439.7040403@deployingradius.com> Cc: "radext@ietf.org" , "fine_sz@huawei.com" Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org QWxhbiAtIFN0ZWZhbidzICJmYW5jeSBhY2NvdW50aW5nIiBkcmFmdCBoYWQgcG9zaXRpdmUgZmVl ZGJhY2sgaW4gdGhpcyBXRy4NCg0KRllJIC0gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5n cy84MS9taW51dGVzL3JhZGV4dC50eHQgDQpQbHMuIHJlYWQgdGhlIG1pbnV0ZXMgb24gdGhlIE5v LjQtUkFESVVTIGFjY291bnRpbmcgZm9yIHRyYWZmaWMgY2xhc3Nlcy4NCg0KQWxhbiAtIENvZGUg YXNzaWdubWVudCBpcyBkb25lIGJ5IElBTkEuIFRoZSBleGFjdCB2YWx1ZXMgZm9yIHRoZSBudW1i ZXJzIGRvbid0IG1hdHRlci4NCg0KUGVyIHNlY3Rpb24gOS4xIG9mIGRyYWZ0LWlldGYtcmFkZXh0 LXJhZGl1cy1leHRlbnNpb25zLTAyLCB0aGUgcHJvcG9zYWwgc2hvd24gYXMgYW4gZXhhbXBsZSBv ZiBjb2RlIGFzc2lnbm1lbnQgY291bGQgYmUgYSBwb3NzaWJsZSAob3IgY29tcGxpYW50KSBjYXNl LiBSaWdodD8NCg0KDQpCZXN0IFJlZ2FyZHMsDQpMZWFmDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IHJhZGV4dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cmFkZXh0LWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGFuIERlS29rDQpTZW50OiBUaHVyc2RheSwg Tm92ZW1iZXIgMTAsIDIwMTEgMjo1MSBQTQ0KVG86IExlYWYgeWVoDQpDYzogcmFkZXh0QGlldGYu b3JnOyBmaW5lX3N6QGh1YXdlaS5jb20NClN1YmplY3Q6IFJlOiBbcmFkZXh0XSBGVzogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC15ZWgtcmFkZXh0LWV4dC10cmFmZmljLXN0YXRp c3RpY3MtMDEudHh0DQoNCkxlYWYgeWVoIHdyb3RlOg0KPiAxLiAgICAgIFRoZSB0eXBlLXNwYWNl IG9mIHRoZSBhdHRyaWJ1dGUgaGFzIGV4dGVuZGVkIG11Y2ggYWZ0ZXIgYWRvcHRlZA0KPiB0aGUg RXh0ZW5kZWQgdHlwZSAoMjQxLTI0NCksIHRoZSB1bmFzc2lnbmVkIHR5cGUgc3BhY2UgdHVybiB0 byBiZQ0KPiAxMDAzPTE5MS0xNDQgKyA0KigyNDAtMSkuIFdlIGNhbiB1c2UgaXQganVzdCBkaXJl Y3RseSBpbiBmbGF0IG1vZGUuDQoNCiAgSG1tLi4uIHRoZSBwdXJwb3NlIG9mIGFkZGluZyBUTFZz IGlzIHRvIGdyb3VwIHNpbWlsYXIgYXR0cmlidXRlcywgYW5kDQp0byBhbGxvdyBsYXRlciBleHRl bnNpb25zIG9mIHRoZSBzYW1lIGdyb3VwLiAgTXkgcmVzcG9uc2Ugc2hvd2VkIGhvdw0KdGhhdCBj b3VsZCBiZSBkb25lLiAgVXNpbmcgYSBmbGF0IG1vZGUgbWVhbnMgdGhhdCB0aGUgYXR0cmlidXRl cyBoYXZlIG5vDQpsb2dpY2FsIHJlbGF0aW9uc2hpcCwgYW5kIGNhbm5vdCBiZSBtZWFuaW5nZnVs bHkgZXh0ZW5kZWQuDQoNCj4gSWYgb25lIG1vcmUg4oCYVHJhZmZpYy1UeXBl4oCZKHN1Yi1hdHRy aWJ1dGUsIDN4IG9jdGV0cywgVExWKSBjb3VsZCBiZQ0KPiBpbmNsdWRlZCBpbnRvIHRoZSBjb250 YWluZXIg4oCYQWNjdC10cmFmZmljLXN0YXRpc3RpY3PigJksIHJlZmVycmVkIHRvIHRoZQ0KPiBk cmFmdC13aW50ZXItcmFkZXgtZmFuY3lhY2NvdW50aW5nLTAwLCB0aGVuIHRoZSBjb250YWluZXIg d291bGQgZ2V0IHRoZQ0KPiBleHRlbnNpYmlsaXR5IGZvciB2YXJpb3VzIGtpbmRzIChlZy4gSVB2 NCwgSVB2Nikgb2YgdHJhZmZpYyBzdGF0aXN0aWNzDQo+IHBlciB0aGUg4oCYVHJhZmZpYy1UeXBl 4oCZLCBhbmQgZXZlbiBmb3Igc29tZSBkZW1hbmRzIChlZy4gRFNDUCBtZW50aW9uZWQgaW4NCj4g dGhlIGFib3ZlIGRyYWZ0LCBvciBUQ1AsIFVEUCBtZW50aW9uZWQgYmVsb3cpIGluIHRoZSBmdXR1 cmUuDQoNCiAgSSB0aGluayBzby4NCg0KPiAzLiAgICAgIERvIHdlIGFscmVhZHkgaGF2ZSBhbnkg Y29udGFpbmVyIGF0dHJpYnV0ZSBkZWZpbmVkIGluIFJGQz8gSQ0KPiBjYW7igJl0IGZpbmQgdGhp cyBraW5kIG9mIGF0dHJpYnV0ZSBpbiBJQU5BIHdlYiBwYWdlLg0KPiAoaHR0cDovL3d3dy5pYW5h Lm9yZy9hc3NpZ25tZW50cy9yYWRpdXMtdHlwZXMvcmFkaXVzLXR5cGVzLnhtbCkuIEkNCj4gd29u ZGVyIHRoZSBSYWRpdXMgY29tbXVuaXR5ICYgV0cgd291bGQgbGlrZSB0aGlzIGNvbXBsZXhpdHkg b2YNCj4gaW50ZXJwcmV0YXRpb24gYWdhaW5zdCAxLTIgbW9yZSBsZXZlbHMgb2YgbmVzdGluZyBh bmQgY29tYmluYXRpb24uDQoNCiAgU3RlZmFuJ3MgImZhbmN5IGFjY291bnRpbmciIGRyYWZ0IGhh ZCBwb3NpdGl2ZSBmZWVkYmFjayBpbiB0aGlzIFdHLg0KDQo+IDQuICAgICAgQXMgdG8gdGhlIGNv ZGUgYXNzaWdubWVudCBmb3IgdGhpcyBuZXcgdHlwZSBvZiBjb250YWluZXINCj4gYXR0cmlidXRl IHByb3Bvc2VkIGZvciBJQU5BIGNvbnNpZGVyYXRpb24sIGl0IG1pZ2h0IGJlDQoNCiAgQ29kZSBh c3NpZ25tZW50IGlzIGRvbmUgYnkgSUFOQS4gIFRoZSBleGFjdCB2YWx1ZXMgZm9yIHRoZSBudW1i ZXJzDQpkb24ndCBtYXR0ZXIsIGFuZCBhcmVuJ3QgdXAgZm9yIGRpc2N1c3Npb24uDQoNCj4gSSB3 b25kZXIgdGhlIHNwYWNlIG9mIDI0MS4xLnggKHJhdGhlciB0aGFuIDI0MS54KSBpcyByZWFkeSBm b3IgSUFOQSB0bw0KPiBhc3NpZ24gb3V0Lg0KDQogIFRoZSBleHRlbmRlZCBhdHRyaWJ1dGVzIGRy YWZ0IGV4cGxhaW5zIGluIGdyZWF0IGRldGFpbCBob3cgSUFOQQ0KYXNzaWducyBhdHRyaWJ1dGVz LCBpbmNsdWRpbmcgbmV3IFRMVnMuICBQbGVhc2UgcmVhZCBpdC4NCg0KICBUaGUgbnVtYmVycyBh cmUgbm90IHJlYWR5IGZvciBJQU5BIHRvIGFzc2lnbiwgYmVjYXVzZSB0aGUgZHJhZnQgaGFzDQpu b3QgYmVlbiBwdWJsaXNoZWQuDQoNCiAgQWxhbiBEZUtvay4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpyYWRleHQgbWFpbGluZyBsaXN0DQpyYWRleHRA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpyYWRleHQgbWFp bGluZyBsaXN0CnJhZGV4dEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3JhZGV4dAo= From aland@deployingradius.com Wed Nov 9 23:30:39 2011 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 EB1A51F0C41 for ; Wed, 9 Nov 2011 23:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 b0Qf7r50YX06 for ; Wed, 9 Nov 2011 23:30:38 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 07F3B1F0C3F for ; Wed, 9 Nov 2011 23:30:33 -0800 (PST) Message-ID: <4EBB7D7D.9040203@deployingradius.com> Date: Thu, 10 Nov 2011 08:30:05 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <4EAFBC28.40902@deployingradius.com> <4EBB7439.7040403@deployingradius.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" , "fine_sz@huawei.com" Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-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: Thu, 10 Nov 2011 07:30:39 -0000 Leaf yeh wrote: > Alan - Stefan's "fancy accounting" draft had positive feedback in this WG. > > FYI - http://www.ietf.org/proceedings/81/minutes/radext.txt > Pls. read the minutes on the No.4-RADIUS accounting for traffic classes. Please read the mailing list archives. Look for "fancy accounting". > Alan - Code assignment is done by IANA. The exact values for the numbers don't matter. > > Per section 9.1 of draft-ietf-radext-radius-extensions-02, the proposal shown as an example of code assignment could be a possible (or compliant) case. Right? That isn't a response to my statement. Alan DeKok. From radext-bounces@ietf.org Wed Nov 9 23:30:40 2011 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 3BC991F0C41; Wed, 9 Nov 2011 23:30:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320910240; bh=cvc4XH55whjjI/K0NOMq5EI4XXONn39+UWKqVHdHbrs=; 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=AK7xLi4WZf7IUwG48hJkiBAPFibArOdDstM1lVjqicPXTH8EjgQFeecRosQas73pm IGojdxWZsRR+UFRX4skz8+Hyuv15Br8HE7gEFGDMqXY8ndQrEFb2EkAGUQ8X+gp0El 2WxF1jexA904ZL/OqaTlrcrvWCZpAdMCzeM1uFws= 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 EB1A51F0C41 for ; Wed, 9 Nov 2011 23:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 b0Qf7r50YX06 for ; Wed, 9 Nov 2011 23:30:38 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 07F3B1F0C3F for ; Wed, 9 Nov 2011 23:30:33 -0800 (PST) Message-ID: <4EBB7D7D.9040203@deployingradius.com> Date: Thu, 10 Nov 2011 08:30:05 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <4EAFBC28.40902@deployingradius.com> <4EBB7439.7040403@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" , "fine_sz@huawei.com" Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Leaf yeh wrote: > Alan - Stefan's "fancy accounting" draft had positive feedback in this WG. > > FYI - http://www.ietf.org/proceedings/81/minutes/radext.txt > Pls. read the minutes on the No.4-RADIUS accounting for traffic classes. Please read the mailing list archives. Look for "fancy accounting". > Alan - Code assignment is done by IANA. The exact values for the numbers don't matter. > > Per section 9.1 of draft-ietf-radext-radius-extensions-02, the proposal shown as an example of code assignment could be a possible (or compliant) case. Right? That isn't a response to my statement. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From leaf.y.yeh@huawei.com Thu Nov 10 00:22:11 2011 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 A0BE721F84B3 for ; Thu, 10 Nov 2011 00:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 J7LQdTNhTDwb for ; Thu, 10 Nov 2011 00:22:11 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id ADF1721F849E for ; Thu, 10 Nov 2011 00:22:10 -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 <0LUF0061JR7GD0@szxga04-in.huawei.com> for radext@ietf.org; Thu, 10 Nov 2011 16:21:16 +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 <0LUF00DNPR7GV2@szxga04-in.huawei.com> for radext@ietf.org; Thu, 10 Nov 2011 16:21:16 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEW78370; Thu, 10 Nov 2011 16:21:15 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 10 Nov 2011 16:21:10 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.62]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0270.001; Thu, 10 Nov 2011 16:21:08 +0800 Date: Thu, 10 Nov 2011 08:21:07 +0000 From: Leaf yeh In-reply-to: <4EBB7D7D.9040203@deployingradius.com> X-Originating-IP: [10.70.39.98] To: Alan DeKok 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] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-01.txt Thread-index: AQHMn3rNAerCrwD8fEyOa0xUzHK5kpWlwhzw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EAFBC28.40902@deployingradius.com> <4EBB7439.7040403@deployingradius.com> <4EBB7D7D.9040203@deployingradius.com> Cc: "radext@ietf.org" , "fine_sz@huawei.com" Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-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: Thu, 10 Nov 2011 08:22:11 -0000 QWxhbiAtIFRoYXQgaXNuJ3QgYSByZXNwb25zZSB0byBteSBzdGF0ZW1lbnQuDQoNClJlcGVhdCB0 aGUgcXVlc3Rpb246IA0KDQpUaGUgcHJvcG9zZWQgc2hvd24gYmVsb3cgYXMgYSBwb3NzaWJsZSBl eGFtcGxlIG9mIGNvZGUgYXNzaWdubWVudCBpcyBhIGNvbXBsaWFudCBjYXNlIHBlciB0aGUgcmVj b21tZW5kYXRpb25zIGRlc2NyaWJlZCBpbiB0aGUgc2VjdGlvbiA5LjMgb2YgZHJhZnQtaWV0Zi1y YWRleHQtcmFkaXVzLWV4dGVuc2lvbnMtMDIuIA0KDQoyNDEueCBmb3IgdGhlIHRoZSBjb250YWlu ZXIg4oCYQWNjdC10cmFmZmljLXN0YXRpc3RpY3PigJkNCjI0MS54LjEgZm9yIHRoZSBzdWItYXR0 cmlidXRlIOKAmFRyYWZmaWMtVHlwZeKAmQ0KMjQxLnguMiBmb3IgdGhlIHN1Yi1hdHRyaWJ1dGUg 4oCYSW5wdXQtT2N0ZXRz4oCZDQoyNDEueC4zIGZvciB0aGUgc3ViLWF0dHJpYnV0ZSDigJhPdXRw dXQtT2N0ZXRz4oCZDQoyNDEueC40IGZvciB0aGUgc3ViLWF0dHJpYnV0ZSDigJhJbnB1dC1QYWNr ZXRz4oCZDQoyNDEueC41IGZvciB0aGUgc3ViLWF0dHJpYnV0ZSDigJhPdXRwdXQtUGFja2V0c+KA mQ0KDQpSaWdodD8NCg0KDQpCZXN0IFJlZ2FyZHMsDQpMZWFmDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IEFsYW4gRGVLb2sgW21haWx0bzphbGFuZEBkZXBsb3lpbmdyYWRp dXMuY29tXSANClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxMCwgMjAxMSAzOjMwIFBNDQpUbzog TGVhZiB5ZWgNCkNjOiByYWRleHRAaWV0Zi5vcmc7IGZpbmVfc3pAaHVhd2VpLmNvbQ0KU3ViamVj dDogUmU6IFtyYWRleHRdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXll aC1yYWRleHQtZXh0LXRyYWZmaWMtc3RhdGlzdGljcy0wMS50eHQNCg0KTGVhZiB5ZWggd3JvdGU6 DQo+IEFsYW4gLSBTdGVmYW4ncyAiZmFuY3kgYWNjb3VudGluZyIgZHJhZnQgaGFkIHBvc2l0aXZl IGZlZWRiYWNrIGluIHRoaXMgV0cuDQo+IA0KPiBGWUkgLSBodHRwOi8vd3d3LmlldGYub3JnL3By b2NlZWRpbmdzLzgxL21pbnV0ZXMvcmFkZXh0LnR4dCANCj4gUGxzLiByZWFkIHRoZSBtaW51dGVz IG9uIHRoZSBOby40LVJBRElVUyBhY2NvdW50aW5nIGZvciB0cmFmZmljIGNsYXNzZXMuDQoNCiAg UGxlYXNlIHJlYWQgdGhlIG1haWxpbmcgbGlzdCBhcmNoaXZlcy4gIExvb2sgZm9yICJmYW5jeSBh Y2NvdW50aW5nIi4NCg0KPiBBbGFuIC0gQ29kZSBhc3NpZ25tZW50IGlzIGRvbmUgYnkgSUFOQS4g VGhlIGV4YWN0IHZhbHVlcyBmb3IgdGhlIG51bWJlcnMgZG9uJ3QgbWF0dGVyLg0KPiANCj4gUGVy IHNlY3Rpb24gOS4xIG9mIGRyYWZ0LWlldGYtcmFkZXh0LXJhZGl1cy1leHRlbnNpb25zLTAyLCB0 aGUgcHJvcG9zYWwgc2hvd24gYXMgYW4gZXhhbXBsZSBvZiBjb2RlIGFzc2lnbm1lbnQgY291bGQg YmUgYSBwb3NzaWJsZSAob3IgY29tcGxpYW50KSBjYXNlLiBSaWdodD8NCg0KICBUaGF0IGlzbid0 IGEgcmVzcG9uc2UgdG8gbXkgc3RhdGVtZW50Lg0KDQogIEFsYW4gRGVLb2suDQo= From radext-bounces@ietf.org Thu Nov 10 00:22:13 2011 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 D4F7421F84B3; Thu, 10 Nov 2011 00:22:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320913333; bh=1VGweiBmQkTjoY38K/Cl4w47SdR9y8t2HdKJpVsLIso=; 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=kwjNRF+y25ZcxBuzY+fo+mdleC6SaqwwXkV0A94NqQcOtD0vR2v9fUMPtYRLf8WKE xQ8JpQq4sATk/WDn0Rzne5QKym0wZut/qHvWT2zwlM7roSn5B8ixDjeFGfGyEdoB0B TYXt+Bp7iqcwAaQ8PpHlQG/XLyeI0yulSs86Pr5U= 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 A0BE721F84B3 for ; Thu, 10 Nov 2011 00:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 J7LQdTNhTDwb for ; Thu, 10 Nov 2011 00:22:11 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id ADF1721F849E for ; Thu, 10 Nov 2011 00:22:10 -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 <0LUF0061JR7GD0@szxga04-in.huawei.com> for radext@ietf.org; Thu, 10 Nov 2011 16:21:16 +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 <0LUF00DNPR7GV2@szxga04-in.huawei.com> for radext@ietf.org; Thu, 10 Nov 2011 16:21:16 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEW78370; Thu, 10 Nov 2011 16:21:15 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 10 Nov 2011 16:21:10 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.62]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0270.001; Thu, 10 Nov 2011 16:21:08 +0800 Date: Thu, 10 Nov 2011 08:21:07 +0000 From: Leaf yeh In-reply-to: <4EBB7D7D.9040203@deployingradius.com> X-Originating-IP: [10.70.39.98] To: Alan DeKok Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-01.txt Thread-index: AQHMn3rNAerCrwD8fEyOa0xUzHK5kpWlwhzw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EAFBC28.40902@deployingradius.com> <4EBB7439.7040403@deployingradius.com> <4EBB7D7D.9040203@deployingradius.com> Cc: "radext@ietf.org" , "fine_sz@huawei.com" Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org QWxhbiAtIFRoYXQgaXNuJ3QgYSByZXNwb25zZSB0byBteSBzdGF0ZW1lbnQuDQoNClJlcGVhdCB0 aGUgcXVlc3Rpb246IA0KDQpUaGUgcHJvcG9zZWQgc2hvd24gYmVsb3cgYXMgYSBwb3NzaWJsZSBl eGFtcGxlIG9mIGNvZGUgYXNzaWdubWVudCBpcyBhIGNvbXBsaWFudCBjYXNlIHBlciB0aGUgcmVj b21tZW5kYXRpb25zIGRlc2NyaWJlZCBpbiB0aGUgc2VjdGlvbiA5LjMgb2YgZHJhZnQtaWV0Zi1y YWRleHQtcmFkaXVzLWV4dGVuc2lvbnMtMDIuIA0KDQoyNDEueCBmb3IgdGhlIHRoZSBjb250YWlu ZXIg4oCYQWNjdC10cmFmZmljLXN0YXRpc3RpY3PigJkNCjI0MS54LjEgZm9yIHRoZSBzdWItYXR0 cmlidXRlIOKAmFRyYWZmaWMtVHlwZeKAmQ0KMjQxLnguMiBmb3IgdGhlIHN1Yi1hdHRyaWJ1dGUg 4oCYSW5wdXQtT2N0ZXRz4oCZDQoyNDEueC4zIGZvciB0aGUgc3ViLWF0dHJpYnV0ZSDigJhPdXRw dXQtT2N0ZXRz4oCZDQoyNDEueC40IGZvciB0aGUgc3ViLWF0dHJpYnV0ZSDigJhJbnB1dC1QYWNr ZXRz4oCZDQoyNDEueC41IGZvciB0aGUgc3ViLWF0dHJpYnV0ZSDigJhPdXRwdXQtUGFja2V0c+KA mQ0KDQpSaWdodD8NCg0KDQpCZXN0IFJlZ2FyZHMsDQpMZWFmDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IEFsYW4gRGVLb2sgW21haWx0bzphbGFuZEBkZXBsb3lpbmdyYWRp dXMuY29tXSANClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxMCwgMjAxMSAzOjMwIFBNDQpUbzog TGVhZiB5ZWgNCkNjOiByYWRleHRAaWV0Zi5vcmc7IGZpbmVfc3pAaHVhd2VpLmNvbQ0KU3ViamVj dDogUmU6IFtyYWRleHRdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXll aC1yYWRleHQtZXh0LXRyYWZmaWMtc3RhdGlzdGljcy0wMS50eHQNCg0KTGVhZiB5ZWggd3JvdGU6 DQo+IEFsYW4gLSBTdGVmYW4ncyAiZmFuY3kgYWNjb3VudGluZyIgZHJhZnQgaGFkIHBvc2l0aXZl IGZlZWRiYWNrIGluIHRoaXMgV0cuDQo+IA0KPiBGWUkgLSBodHRwOi8vd3d3LmlldGYub3JnL3By b2NlZWRpbmdzLzgxL21pbnV0ZXMvcmFkZXh0LnR4dCANCj4gUGxzLiByZWFkIHRoZSBtaW51dGVz IG9uIHRoZSBOby40LVJBRElVUyBhY2NvdW50aW5nIGZvciB0cmFmZmljIGNsYXNzZXMuDQoNCiAg UGxlYXNlIHJlYWQgdGhlIG1haWxpbmcgbGlzdCBhcmNoaXZlcy4gIExvb2sgZm9yICJmYW5jeSBh Y2NvdW50aW5nIi4NCg0KPiBBbGFuIC0gQ29kZSBhc3NpZ25tZW50IGlzIGRvbmUgYnkgSUFOQS4g VGhlIGV4YWN0IHZhbHVlcyBmb3IgdGhlIG51bWJlcnMgZG9uJ3QgbWF0dGVyLg0KPiANCj4gUGVy IHNlY3Rpb24gOS4xIG9mIGRyYWZ0LWlldGYtcmFkZXh0LXJhZGl1cy1leHRlbnNpb25zLTAyLCB0 aGUgcHJvcG9zYWwgc2hvd24gYXMgYW4gZXhhbXBsZSBvZiBjb2RlIGFzc2lnbm1lbnQgY291bGQg YmUgYSBwb3NzaWJsZSAob3IgY29tcGxpYW50KSBjYXNlLiBSaWdodD8NCg0KICBUaGF0IGlzbid0 IGEgcmVzcG9uc2UgdG8gbXkgc3RhdGVtZW50Lg0KDQogIEFsYW4gRGVLb2suDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpyYWRleHQgbWFpbGluZyBsaXN0 CnJhZGV4dEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Jh ZGV4dAo= From aland@deployingradius.com Thu Nov 10 03:51:55 2011 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 9E96C21F8AB9 for ; Thu, 10 Nov 2011 03:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 k1oqunsLkolX for ; Thu, 10 Nov 2011 03:51:54 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id B575E21F8AB8 for ; Thu, 10 Nov 2011 03:51:54 -0800 (PST) Message-ID: <4EBBBABE.7050901@deployingradius.com> Date: Thu, 10 Nov 2011 12:51:26 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <4EAFBC28.40902@deployingradius.com> <4EBB7439.7040403@deployingradius.com> <4EBB7D7D.9040203@deployingradius.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" , "fine_sz@huawei.com" Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-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: Thu, 10 Nov 2011 11:51:55 -0000 Leaf yeh wrote: > Alan - That isn't a response to my statement. > > Repeat the question: > > The proposed shown below as a possible example of code assignment is a compliant case per the recommendations described in the section 9.3 of draft-ietf-radext-radius-extensions-02. It's an example. Alan DeKok. From radext-bounces@ietf.org Thu Nov 10 03:51:57 2011 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 9038821F8AB9; Thu, 10 Nov 2011 03:51:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320925917; bh=h0qlmpRBsFZsXSsdW4QZmN9HsLKNHHv2lCj1APQqebI=; 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=GwaFONbLVk0eEjc9EYQsiCVkZCZuDoOqGceBZ78MzKd017Xt78x0r6zyV9uqKXc8j QssfPYmiUwFyonzCKEt5nqCISinL1vsyioOBWVzPdQv5y4vbeOk66IqLZPOCaenm/9 FEsMzSFdABK0P1Io8+/BujURLUajfiOuwHP4mIik= 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 9E96C21F8AB9 for ; Thu, 10 Nov 2011 03:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 k1oqunsLkolX for ; Thu, 10 Nov 2011 03:51:54 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id B575E21F8AB8 for ; Thu, 10 Nov 2011 03:51:54 -0800 (PST) Message-ID: <4EBBBABE.7050901@deployingradius.com> Date: Thu, 10 Nov 2011 12:51:26 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <4EAFBC28.40902@deployingradius.com> <4EBB7439.7040403@deployingradius.com> <4EBB7D7D.9040203@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" , "fine_sz@huawei.com" Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Leaf yeh wrote: > Alan - That isn't a response to my statement. > > Repeat the question: > > The proposed shown below as a possible example of code assignment is a compliant case per the recommendations described in the section 9.3 of draft-ietf-radext-radius-extensions-02. It's an example. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Thu Nov 10 08:42:48 2011 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 7C19521F8A69; Thu, 10 Nov 2011 08:42:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320943368; bh=IaTXh/0WbkSqNIwhVATyifb2UIrinU5ym33IYHYCXRw=; h=From:To:Date:Message-ID:MIME-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=T16LYpbg8CnJzuUy28DuhSGBLeLMCxHVVapgrTgyqIFZXbiclI2AE5HHq8FmrV/Yv anOkwkqjmxIWULgAo2/FXLLJgEuX7MAFat2dy5GrpM7DN/+nmzgQWZm/zUxvHD5ejz Fvnm5Z+zT32gMvTipH2nNO4MZekcDr6HNG59wPcg= 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 BB43D21F8A69 for ; Thu, 10 Nov 2011 08:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.492 X-Spam-Level: X-Spam-Status: No, score=-106.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 jyPFEkXu3aIk for ; Thu, 10 Nov 2011 08:42:46 -0800 (PST) Received: from g6t0187.atlanta.hp.com (g6t0187.atlanta.hp.com [15.193.32.64]) by ietfa.amsl.com (Postfix) with ESMTP id 698D321F8593 for ; Thu, 10 Nov 2011 08:42:46 -0800 (PST) Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g6t0187.atlanta.hp.com (Postfix) with ESMTPS id 61997283C0; Thu, 10 Nov 2011 16:42:45 +0000 (UTC) Received: from G6W0173.americas.hpqcorp.net (16.230.33.182) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 10 Nov 2011 16:42:04 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G6W0173.americas.hpqcorp.net ([16.230.33.182]) with mapi; Thu, 10 Nov 2011 16:41:57 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Thu, 10 Nov 2011 16:41:55 +0000 Thread-Topic: IETF 82: Call for presentations Thread-Index: Acyfx2m0CxqXfxzbTQyxvdl4n1URog== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD0C052B2@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "jouni.korhonen@nsn.com" Subject: [radext] IETF 82: Call for presentations 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="===============2495860661615559308==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============2495860661615559308== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0C052B2GVW0671EXCame_" --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0C052B2GVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you are on the meeting agenda to present, we kindly ask you to start sen= ding the presentations to the WG chairs. Our meeting is but 4 days away. = Agenda is below for reference. Thanks, MS ----------------------- RADEXT WG IETF 82 Agenda Chairs: Jouni Korhonen Mauricio Sanchez Jabber room: radext at jabber.ietf.org (Please join) Monday, November 14, 2011 0900 - 1130 Room 101D 9:00 - 09:20 AM, Preliminaries (20 minutes) Audio/Video & Remote Presentation Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status IPv6 items (15 minutes) 9:20 - 9:35 AM RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec (15 = minutes) http://tools.ietf.org/html/draft-ietf-radext-ipv6-access Enhancement items (45 minutes) 9:35 - 9:50 AM RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh= (15 minutes) http://tools.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01.txt 9:50 - 10:05 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (15 = minutes) http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt 10:05 - 10:20 AM RADIUS Protocol Extensions, Alan DeKok (15 minutes) http://tools.ietf.org/html/draft-ietf-radext-radius-extensions 10:20 - 10:35 AM Network Access Identifier, Alan DeKok (15 minutes) http://tools.ietf.org/html/draft-dekok-radext-nai-01 Discussion and Wrap-up (35 minutes) 10:35 - 10:55 AM Discussion (20 minutes) 10:55 - 11:10 AM Next Steps: WG Chairs & ADs (15 minutes) WG Goals/Milestones status --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0C052B2GVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you are on th= e meeting agenda to present, we kindly ask you to start sending the present= ations to the WG chairs.  Our meeting is but 4 days away.   =  Agenda is below for reference.

 

Thanks,

MS

 

-----------------------

RA= DEXT WG IETF 82 Agenda

 =

Chairs:

Jouni K= orhonen <jouni.korhonen at nsn.com>

Mauricio Sanchez <mauricio.sanchez at hp.com>

 

Jabber room: radext= at jabber.ietf.org (Please join)

&= nbsp;

Monday, November 14, 2011

0900 - 1130

Room = 101D

 

9:00 - 09:20 AM, Preliminaries (20 minutes)

Audio/Video & Remote Presentation Debugging

=

Note Well

Note Take= rs

Jabber scribe

Agenda bash

Document Status=

 

 

IPv6 items (15 minutes)

9:20 - 9:35 AM RADIUS Attributes for IPv6 Acce= ss Networks, Wojcieh Dec (15 minutes)

http://t= ools.ietf.org/html/draft-ietf-radext-ipv6-access

 

 

Enhancement items (45 minutes)

9:35 - 9:50 AM RADIUS Accounting Extensions of Traffic Statist= ics, Leaf Yeh (15 minutes)

http= ://tools.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01.txt

 

9= :50 - 10:05 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (15 m= inutes)

http://tools.ietf.org/id/draft-aboba-ra= dext-wlan-15.txt

 

10:05 - 10:20 AM RADIUS Protocol Extensions, Alan De= Kok (15 minutes)

http://tools.ietf.org/h= tml/draft-ietf-radext-radius-extensions

 

10:20 - 10:35 AM Network Acce= ss Identifier, Alan DeKok (15 minutes)

<= a href=3D"http://tools.ietf.org/html/draft-dekok-radext-nai-01">http://tool= s.ietf.org/html/draft-dekok-radext-nai-01

 

 

Discussion and Wrap-up (35 minutes)

10:35 – 10:55 AM Discussion (20 minutes)

<= p class=3DMsoNormal> 

10:55 - 11:10= AM Next Steps: WG Chairs & ADs (15 minutes)

WG Goals/Milestones status

 = ;

 

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0C052B2GVW0671EXCame_-- --===============2495860661615559308== 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 --===============2495860661615559308==-- From mauricio.sanchez@hp.com Thu Nov 10 08:42:47 2011 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 BB43D21F8A69 for ; Thu, 10 Nov 2011 08:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.492 X-Spam-Level: X-Spam-Status: No, score=-106.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 jyPFEkXu3aIk for ; Thu, 10 Nov 2011 08:42:46 -0800 (PST) Received: from g6t0187.atlanta.hp.com (g6t0187.atlanta.hp.com [15.193.32.64]) by ietfa.amsl.com (Postfix) with ESMTP id 698D321F8593 for ; Thu, 10 Nov 2011 08:42:46 -0800 (PST) Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g6t0187.atlanta.hp.com (Postfix) with ESMTPS id 61997283C0; Thu, 10 Nov 2011 16:42:45 +0000 (UTC) Received: from G6W0173.americas.hpqcorp.net (16.230.33.182) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 10 Nov 2011 16:42:04 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G6W0173.americas.hpqcorp.net ([16.230.33.182]) with mapi; Thu, 10 Nov 2011 16:41:57 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Thu, 10 Nov 2011 16:41:55 +0000 Thread-Topic: IETF 82: Call for presentations Thread-Index: Acyfx2m0CxqXfxzbTQyxvdl4n1URog== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD0C052B2@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0C052B2GVW0671EXCame_" MIME-Version: 1.0 Cc: "jouni.korhonen@nsn.com" Subject: [radext] IETF 82: Call for presentations 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, 10 Nov 2011 16:42:47 -0000 --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0C052B2GVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you are on the meeting agenda to present, we kindly ask you to start sen= ding the presentations to the WG chairs. Our meeting is but 4 days away. = Agenda is below for reference. Thanks, MS ----------------------- RADEXT WG IETF 82 Agenda Chairs: Jouni Korhonen Mauricio Sanchez Jabber room: radext at jabber.ietf.org (Please join) Monday, November 14, 2011 0900 - 1130 Room 101D 9:00 - 09:20 AM, Preliminaries (20 minutes) Audio/Video & Remote Presentation Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status IPv6 items (15 minutes) 9:20 - 9:35 AM RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec (15 = minutes) http://tools.ietf.org/html/draft-ietf-radext-ipv6-access Enhancement items (45 minutes) 9:35 - 9:50 AM RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh= (15 minutes) http://tools.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01.txt 9:50 - 10:05 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (15 = minutes) http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt 10:05 - 10:20 AM RADIUS Protocol Extensions, Alan DeKok (15 minutes) http://tools.ietf.org/html/draft-ietf-radext-radius-extensions 10:20 - 10:35 AM Network Access Identifier, Alan DeKok (15 minutes) http://tools.ietf.org/html/draft-dekok-radext-nai-01 Discussion and Wrap-up (35 minutes) 10:35 - 10:55 AM Discussion (20 minutes) 10:55 - 11:10 AM Next Steps: WG Chairs & ADs (15 minutes) WG Goals/Milestones status --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0C052B2GVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you are on th= e meeting agenda to present, we kindly ask you to start sending the present= ations to the WG chairs.  Our meeting is but 4 days away.   =  Agenda is below for reference.

 

Thanks,

MS

 

-----------------------

RA= DEXT WG IETF 82 Agenda

 =

Chairs:

Jouni K= orhonen <jouni.korhonen at nsn.com>

Mauricio Sanchez <mauricio.sanchez at hp.com>

 

Jabber room: radext= at jabber.ietf.org (Please join)

&= nbsp;

Monday, November 14, 2011

0900 - 1130

Room = 101D

 

9:00 - 09:20 AM, Preliminaries (20 minutes)

Audio/Video & Remote Presentation Debugging

=

Note Well

Note Take= rs

Jabber scribe

Agenda bash

Document Status=

 

 

IPv6 items (15 minutes)

9:20 - 9:35 AM RADIUS Attributes for IPv6 Acce= ss Networks, Wojcieh Dec (15 minutes)

http://t= ools.ietf.org/html/draft-ietf-radext-ipv6-access

 

 

Enhancement items (45 minutes)

9:35 - 9:50 AM RADIUS Accounting Extensions of Traffic Statist= ics, Leaf Yeh (15 minutes)

http= ://tools.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01.txt

 

9= :50 - 10:05 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (15 m= inutes)

http://tools.ietf.org/id/draft-aboba-ra= dext-wlan-15.txt

 

10:05 - 10:20 AM RADIUS Protocol Extensions, Alan De= Kok (15 minutes)

http://tools.ietf.org/h= tml/draft-ietf-radext-radius-extensions

 

10:20 - 10:35 AM Network Acce= ss Identifier, Alan DeKok (15 minutes)

<= a href=3D"http://tools.ietf.org/html/draft-dekok-radext-nai-01">http://tool= s.ietf.org/html/draft-dekok-radext-nai-01

 

 

Discussion and Wrap-up (35 minutes)

10:35 – 10:55 AM Discussion (20 minutes)

<= p class=3DMsoNormal> 

10:55 - 11:10= AM Next Steps: WG Chairs & ADs (15 minutes)

WG Goals/Milestones status

 = ;

 

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0C052B2GVW0671EXCame_-- From stefan.winter@restena.lu Fri Nov 11 13:08:21 2011 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 3BA0E21F8532 for ; Fri, 11 Nov 2011 13:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 PtoEA2WDig+z for ; Fri, 11 Nov 2011 13:08:20 -0800 (PST) Received: from legolas.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) by ietfa.amsl.com (Postfix) with ESMTP id 59A3521F84DF for ; Fri, 11 Nov 2011 13:08:17 -0800 (PST) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id CE4F5A6C62 for ; Fri, 11 Nov 2011 22:08:13 +0100 (CET) Received: from [IPv6:2001:4b88:108d::131] (unknown [IPv6:2001:4b88:108d::131]) by legolas.restena.lu (Postfix) with ESMTPSA id 84E4FAF03E for ; Fri, 11 Nov 2011 22:08:13 +0100 (CET) Message-ID: <4EBD8EBB.6020403@restena.lu> Date: Fri, 11 Nov 2011 22:08:11 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: radext@ietf.org References: <4EAFBC28.40902@deployingradius.com> <4EBB7439.7040403@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-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: Fri, 11 Nov 2011 21:08:21 -0000 Hello, > Alan - Stefan's "fancy accounting" draft had positive feedback in this WG. > > FYI - http://www.ietf.org/proceedings/81/minutes/radext.txt > Pls. read the minutes on the No.4-RADIUS accounting for traffic classes. I started the draft because *you* presented an urgent need for IPv6-specific accounting the meeting before that one. I wrote the draft, and got positive remarks on the mailing list. On the next meeting, I gauged interest for prioritisation of my workload. You were in the room, and (all of a sudden) had no interest any more. Now you've put forward your own draft to solve the exact same problem. Are you a) interested or b) not interested in solving the IPv6-Acct problem? The signals you send are contradicting. In any case, I would like to have a short presentation on the fancyaccounting draft, now that interest is apparently above 0 again. Stefan > > Alan - Code assignment is done by IANA. The exact values for the numbers don't matter. > > Per section 9.1 of draft-ietf-radext-radius-extensions-02, the proposal shown as an example of code assignment could be a possible (or compliant) case. Right? > > > Best Regards, > Leaf > > > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Alan DeKok > Sent: Thursday, November 10, 2011 2:51 PM > To: Leaf yeh > Cc: radext@ietf.org; fine_sz@huawei.com > Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-01.txt > > Leaf yeh wrote: >> 1. The type-space of the attribute has extended much after adopted >> the Extended type (241-244), the unassigned type space turn to be >> 1003=191-144 + 4*(240-1). We can use it just directly in flat mode. > Hmm... the purpose of adding TLVs is to group similar attributes, and > to allow later extensions of the same group. My response showed how > that could be done. Using a flat mode means that the attributes have no > logical relationship, and cannot be meaningfully extended. > >> If one more ‘Traffic-Type’(sub-attribute, 3x octets, TLV) could be >> included into the container ‘Acct-traffic-statistics’, referred to the >> draft-winter-radex-fancyaccounting-00, then the container would get the >> extensibility for various kinds (eg. IPv4, IPv6) of traffic statistics >> per the ‘Traffic-Type’, and even for some demands (eg. DSCP mentioned in >> the above draft, or TCP, UDP mentioned below) in the future. > I think so. > >> 3. Do we already have any container attribute defined in RFC? I >> can’t find this kind of attribute in IANA web page. >> (http://www.iana.org/assignments/radius-types/radius-types.xml). I >> wonder the Radius community& WG would like this complexity of >> interpretation against 1-2 more levels of nesting and combination. > Stefan's "fancy accounting" draft had positive feedback in this WG. > >> 4. As to the code assignment for this new type of container >> attribute proposed for IANA consideration, it might be > Code assignment is done by IANA. The exact values for the numbers > don't matter, and aren't up for discussion. > >> I wonder the space of 241.1.x (rather than 241.x) is ready for IANA to >> assign out. > The extended attributes draft explains in great detail how IANA > assigns attributes, including new TLVs. Please read it. > > The numbers are not ready for IANA to assign, because the draft has > not been published. > > 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 radext-bounces@ietf.org Fri Nov 11 13:08:22 2011 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 77E2121F8532; Fri, 11 Nov 2011 13:08:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321045702; bh=Y7gQpP+gQy6WVJnmXAI3x78qt7OZdDz5fhC5j8n0PtI=; 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=CXHj3U1yu63TGvAaXhkARyyB3bo9SF1cBDHll2TBfTYbV/hu10WRFfr+kO4XlpQCt 7gCrdnPvKam69fN7/riiHeNGpKqI5UHMBlSrzb8r46CEJ9TQbMRYXOHB3/8v6fWtWo z3R71gsEvN7//Tm4l+E6NITWniViIwnP0jYfRus0= 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 3BA0E21F8532 for ; Fri, 11 Nov 2011 13:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 PtoEA2WDig+z for ; Fri, 11 Nov 2011 13:08:20 -0800 (PST) Received: from legolas.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) by ietfa.amsl.com (Postfix) with ESMTP id 59A3521F84DF for ; Fri, 11 Nov 2011 13:08:17 -0800 (PST) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id CE4F5A6C62 for ; Fri, 11 Nov 2011 22:08:13 +0100 (CET) Received: from [IPv6:2001:4b88:108d::131] (unknown [IPv6:2001:4b88:108d::131]) by legolas.restena.lu (Postfix) with ESMTPSA id 84E4FAF03E for ; Fri, 11 Nov 2011 22:08:13 +0100 (CET) Message-ID: <4EBD8EBB.6020403@restena.lu> Date: Fri, 11 Nov 2011 22:08:11 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: radext@ietf.org References: <4EAFBC28.40902@deployingradius.com> <4EBB7439.7040403@deployingradius.com> In-Reply-To: X-Virus-Scanned: ClamAV Subject: Re: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-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-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org SGVsbG8sCgo+IEFsYW4gLSBTdGVmYW4ncyAiZmFuY3kgYWNjb3VudGluZyIgZHJhZnQgaGFkIHBv c2l0aXZlIGZlZWRiYWNrIGluIHRoaXMgV0cuCj4KPiBGWUkgLSBodHRwOi8vd3d3LmlldGYub3Jn L3Byb2NlZWRpbmdzLzgxL21pbnV0ZXMvcmFkZXh0LnR4dAo+IFBscy4gcmVhZCB0aGUgbWludXRl cyBvbiB0aGUgTm8uNC1SQURJVVMgYWNjb3VudGluZyBmb3IgdHJhZmZpYyBjbGFzc2VzLgoKSSBz dGFydGVkIHRoZSBkcmFmdCBiZWNhdXNlICp5b3UqIHByZXNlbnRlZCBhbiB1cmdlbnQgbmVlZCBm b3IgCklQdjYtc3BlY2lmaWMgYWNjb3VudGluZyB0aGUgbWVldGluZyBiZWZvcmUgdGhhdCBvbmUu CgpJIHdyb3RlIHRoZSBkcmFmdCwgYW5kIGdvdCBwb3NpdGl2ZSByZW1hcmtzIG9uIHRoZSBtYWls aW5nIGxpc3QuCgpPbiB0aGUgbmV4dCBtZWV0aW5nLCBJIGdhdWdlZCBpbnRlcmVzdCBmb3IgcHJp b3JpdGlzYXRpb24gb2YgbXkgCndvcmtsb2FkLiBZb3Ugd2VyZSBpbiB0aGUgcm9vbSwgYW5kIChh bGwgb2YgYSBzdWRkZW4pIGhhZCBubyBpbnRlcmVzdCAKYW55IG1vcmUuCgpOb3cgeW91J3ZlIHB1 dCBmb3J3YXJkIHlvdXIgb3duIGRyYWZ0IHRvIHNvbHZlIHRoZSBleGFjdCBzYW1lIHByb2JsZW0u CgpBcmUgeW91IGEpIGludGVyZXN0ZWQgb3IgYikgbm90IGludGVyZXN0ZWQgaW4gc29sdmluZyB0 aGUgSVB2Ni1BY2N0IApwcm9ibGVtPyBUaGUgc2lnbmFscyB5b3Ugc2VuZCBhcmUgY29udHJhZGlj dGluZy4KCkluIGFueSBjYXNlLCBJIHdvdWxkIGxpa2UgdG8gaGF2ZSBhIHNob3J0IHByZXNlbnRh dGlvbiBvbiB0aGUgCmZhbmN5YWNjb3VudGluZyBkcmFmdCwgbm93IHRoYXQgaW50ZXJlc3QgaXMg YXBwYXJlbnRseSBhYm92ZSAwIGFnYWluLgoKU3RlZmFuCgo+Cj4gQWxhbiAtIENvZGUgYXNzaWdu bWVudCBpcyBkb25lIGJ5IElBTkEuIFRoZSBleGFjdCB2YWx1ZXMgZm9yIHRoZSBudW1iZXJzIGRv bid0IG1hdHRlci4KPgo+IFBlciBzZWN0aW9uIDkuMSBvZiBkcmFmdC1pZXRmLXJhZGV4dC1yYWRp dXMtZXh0ZW5zaW9ucy0wMiwgdGhlIHByb3Bvc2FsIHNob3duIGFzIGFuIGV4YW1wbGUgb2YgY29k ZSBhc3NpZ25tZW50IGNvdWxkIGJlIGEgcG9zc2libGUgKG9yIGNvbXBsaWFudCkgY2FzZS4gUmln aHQ/Cj4KPgo+IEJlc3QgUmVnYXJkcywKPiBMZWFmCj4KPgo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tCj4gRnJvbTogcmFkZXh0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpyYWRleHQtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsYW4gRGVLb2sKPiBTZW50OiBUaHVyc2RheSwg Tm92ZW1iZXIgMTAsIDIwMTEgMjo1MSBQTQo+IFRvOiBMZWFmIHllaAo+IENjOiByYWRleHRAaWV0 Zi5vcmc7IGZpbmVfc3pAaHVhd2VpLmNvbQo+IFN1YmplY3Q6IFJlOiBbcmFkZXh0XSBGVzogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC15ZWgtcmFkZXh0LWV4dC10cmFmZmljLXN0 YXRpc3RpY3MtMDEudHh0Cj4KPiBMZWFmIHllaCB3cm90ZToKPj4gMS4gICAgICBUaGUgdHlwZS1z cGFjZSBvZiB0aGUgYXR0cmlidXRlIGhhcyBleHRlbmRlZCBtdWNoIGFmdGVyIGFkb3B0ZWQKPj4g dGhlIEV4dGVuZGVkIHR5cGUgKDI0MS0yNDQpLCB0aGUgdW5hc3NpZ25lZCB0eXBlIHNwYWNlIHR1 cm4gdG8gYmUKPj4gMTAwMz0xOTEtMTQ0ICsgNCooMjQwLTEpLiBXZSBjYW4gdXNlIGl0IGp1c3Qg ZGlyZWN0bHkgaW4gZmxhdCBtb2RlLgo+ICAgIEhtbS4uLiB0aGUgcHVycG9zZSBvZiBhZGRpbmcg VExWcyBpcyB0byBncm91cCBzaW1pbGFyIGF0dHJpYnV0ZXMsIGFuZAo+IHRvIGFsbG93IGxhdGVy IGV4dGVuc2lvbnMgb2YgdGhlIHNhbWUgZ3JvdXAuICBNeSByZXNwb25zZSBzaG93ZWQgaG93Cj4g dGhhdCBjb3VsZCBiZSBkb25lLiAgVXNpbmcgYSBmbGF0IG1vZGUgbWVhbnMgdGhhdCB0aGUgYXR0 cmlidXRlcyBoYXZlIG5vCj4gbG9naWNhbCByZWxhdGlvbnNoaXAsIGFuZCBjYW5ub3QgYmUgbWVh bmluZ2Z1bGx5IGV4dGVuZGVkLgo+Cj4+IElmIG9uZSBtb3JlIOKAmFRyYWZmaWMtVHlwZeKAmShz dWItYXR0cmlidXRlLCAzeCBvY3RldHMsIFRMVikgY291bGQgYmUKPj4gaW5jbHVkZWQgaW50byB0 aGUgY29udGFpbmVyIOKAmEFjY3QtdHJhZmZpYy1zdGF0aXN0aWNz4oCZLCByZWZlcnJlZCB0byB0 aGUKPj4gZHJhZnQtd2ludGVyLXJhZGV4LWZhbmN5YWNjb3VudGluZy0wMCwgdGhlbiB0aGUgY29u dGFpbmVyIHdvdWxkIGdldCB0aGUKPj4gZXh0ZW5zaWJpbGl0eSBmb3IgdmFyaW91cyBraW5kcyAo ZWcuIElQdjQsIElQdjYpIG9mIHRyYWZmaWMgc3RhdGlzdGljcwo+PiBwZXIgdGhlIOKAmFRyYWZm aWMtVHlwZeKAmSwgYW5kIGV2ZW4gZm9yIHNvbWUgZGVtYW5kcyAoZWcuIERTQ1AgbWVudGlvbmVk IGluCj4+IHRoZSBhYm92ZSBkcmFmdCwgb3IgVENQLCBVRFAgbWVudGlvbmVkIGJlbG93KSBpbiB0 aGUgZnV0dXJlLgo+ICAgIEkgdGhpbmsgc28uCj4KPj4gMy4gICAgICBEbyB3ZSBhbHJlYWR5IGhh dmUgYW55IGNvbnRhaW5lciBhdHRyaWJ1dGUgZGVmaW5lZCBpbiBSRkM/IEkKPj4gY2Fu4oCZdCBm aW5kIHRoaXMga2luZCBvZiBhdHRyaWJ1dGUgaW4gSUFOQSB3ZWIgcGFnZS4KPj4gKGh0dHA6Ly93 d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvcmFkaXVzLXR5cGVzL3JhZGl1cy10eXBlcy54bWwpLiBJ Cj4+IHdvbmRlciB0aGUgUmFkaXVzIGNvbW11bml0eSYgIFdHIHdvdWxkIGxpa2UgdGhpcyBjb21w bGV4aXR5IG9mCj4+IGludGVycHJldGF0aW9uIGFnYWluc3QgMS0yIG1vcmUgbGV2ZWxzIG9mIG5l c3RpbmcgYW5kIGNvbWJpbmF0aW9uLgo+ICAgIFN0ZWZhbidzICJmYW5jeSBhY2NvdW50aW5nIiBk cmFmdCBoYWQgcG9zaXRpdmUgZmVlZGJhY2sgaW4gdGhpcyBXRy4KPgo+PiA0LiAgICAgIEFzIHRv IHRoZSBjb2RlIGFzc2lnbm1lbnQgZm9yIHRoaXMgbmV3IHR5cGUgb2YgY29udGFpbmVyCj4+IGF0 dHJpYnV0ZSBwcm9wb3NlZCBmb3IgSUFOQSBjb25zaWRlcmF0aW9uLCBpdCBtaWdodCBiZQo+ICAg IENvZGUgYXNzaWdubWVudCBpcyBkb25lIGJ5IElBTkEuICBUaGUgZXhhY3QgdmFsdWVzIGZvciB0 aGUgbnVtYmVycwo+IGRvbid0IG1hdHRlciwgYW5kIGFyZW4ndCB1cCBmb3IgZGlzY3Vzc2lvbi4K Pgo+PiBJIHdvbmRlciB0aGUgc3BhY2Ugb2YgMjQxLjEueCAocmF0aGVyIHRoYW4gMjQxLngpIGlz IHJlYWR5IGZvciBJQU5BIHRvCj4+IGFzc2lnbiBvdXQuCj4gICAgVGhlIGV4dGVuZGVkIGF0dHJp YnV0ZXMgZHJhZnQgZXhwbGFpbnMgaW4gZ3JlYXQgZGV0YWlsIGhvdyBJQU5BCj4gYXNzaWducyBh dHRyaWJ1dGVzLCBpbmNsdWRpbmcgbmV3IFRMVnMuICBQbGVhc2UgcmVhZCBpdC4KPgo+ICAgIFRo ZSBudW1iZXJzIGFyZSBub3QgcmVhZHkgZm9yIElBTkEgdG8gYXNzaWduLCBiZWNhdXNlIHRoZSBk cmFmdCBoYXMKPiBub3QgYmVlbiBwdWJsaXNoZWQuCj4KPiAgICBBbGFuIERlS29rLgo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gcmFkZXh0IG1haWxp bmcgbGlzdAo+IHJhZGV4dEBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcmFkZXh0Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KPiByYWRleHQgbWFpbGluZyBsaXN0Cj4gcmFkZXh0QGlldGYub3JnCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yYWRleHQKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCnJhZGV4dCBtYWlsaW5nIGxpc3QKcmFkZXh0 QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0Cg== From wwwrun@rfc-editor.org Sat Nov 12 22:16:21 2011 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 EE32C11E80B4; Sat, 12 Nov 2011 22:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, 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 FrtDjbnoXMzb; Sat, 12 Nov 2011 22:16:21 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8A56911E80B0; Sat, 12 Nov 2011 22:16:21 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D86CDB1E002; Sat, 12 Nov 2011 22:11:19 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111113061119.D86CDB1E002@rfc-editor.org> Date: Sat, 12 Nov 2011 22:11:19 -0800 (PST) Cc: radext@ietf.org, rfc-editor@rfc-editor.org Subject: [radext] RFC 6421 on Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS) 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: Sun, 13 Nov 2011 06:16:22 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6421 Title: Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS) Author: D. Nelson, Ed. Status: Informational Stream: IETF Date: November 2011 Mailbox: d.b.nelson@comcast.net Pages: 12 Characters: 27028 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-radext-crypto-agility-requirements-07.txt URL: http://www.rfc-editor.org/rfc/rfc6421.txt This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the RADIUS EXTensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From radext-bounces@ietf.org Sat Nov 12 22:16:25 2011 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 9725611E80BC; Sat, 12 Nov 2011 22:16:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321164985; bh=Mefx2leY0IJI9N+9dZRJJfNK1mJ82jk4nng3+uZnswE=; 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=hggJmxM+T5zF2EV4MJWffIMad0jDSWAzIptFT6DepRmffEZL0DjQXZny4PFHNu8KT xZDdQ5r7dvyjPFuMa5BSgcp/E9hpheIVZTNSbXgjDlr/7zOhEMxjWA0EF1zIc0ZMnX 4EGXuE6fK1DZiqBo8gkoMUg6/j2fVyOXo2emO/mk= 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 EE32C11E80B4; Sat, 12 Nov 2011 22:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, 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 FrtDjbnoXMzb; Sat, 12 Nov 2011 22:16:21 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8A56911E80B0; Sat, 12 Nov 2011 22:16:21 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D86CDB1E002; Sat, 12 Nov 2011 22:11:19 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111113061119.D86CDB1E002@rfc-editor.org> Date: Sat, 12 Nov 2011 22:11:19 -0800 (PST) Cc: radext@ietf.org, rfc-editor@rfc-editor.org Subject: [radext] RFC 6421 on Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS) 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 A new Request for Comments is now available in online RFC libraries. RFC 6421 Title: Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS) Author: D. Nelson, Ed. Status: Informational Stream: IETF Date: November 2011 Mailbox: d.b.nelson@comcast.net Pages: 12 Characters: 27028 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-radext-crypto-agility-requirements-07.txt URL: http://www.rfc-editor.org/rfc/rfc6421.txt This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the RADIUS EXTensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From mauricio.sanchez@hp.com Sun Nov 13 02:00:52 2011 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 A2FD521F8B52 for ; Sun, 13 Nov 2011 02:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.505 X-Spam-Level: X-Spam-Status: No, score=-106.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 TyCuTThzMKcc for ; Sun, 13 Nov 2011 02:00:51 -0800 (PST) Received: from g6t0184.atlanta.hp.com (g6t0184.atlanta.hp.com [15.193.32.61]) by ietfa.amsl.com (Postfix) with ESMTP id 06CCD21F847A for ; Sun, 13 Nov 2011 02:00:50 -0800 (PST) Received: from G4W3011G.americas.hpqcorp.net (g4w3011g.houston.hp.com [16.234.25.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0184.atlanta.hp.com (Postfix) with ESMTPS id E5FDEC0D4 for ; Sun, 13 Nov 2011 10:00:50 +0000 (UTC) Received: from G5W0602.americas.hpqcorp.net (16.228.9.185) by G4W3011G.americas.hpqcorp.net (16.234.25.125) with Microsoft SMTP Server (TLS) id 14.1.289.1; Sun, 13 Nov 2011 10:00:18 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0602.americas.hpqcorp.net ([16.228.9.185]) with mapi; Sun, 13 Nov 2011 10:00:17 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Sun, 13 Nov 2011 10:00:15 +0000 Thread-Topic: IETF 82: Updated meeting agenda Thread-Index: Acyh6u3Y31Id+t4FRymvnL+dDJDYxg== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD0C05FF6@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0C05FF6GVW0671EXCame_" MIME-Version: 1.0 Subject: [radext] IETF 82: Updated meeting agenda 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: Sun, 13 Nov 2011 10:00:52 -0000 --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0C05FF6GVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Below is updated agenda for tomorrow. Cheers, Mauricio -------------------------------------------- RADEXT WG IETF 82 Agenda Chairs: Jouni Korhonen Mauricio Sanchez Jabber room: radext at jabber.ietf.org (Please join) Monday, November 14, 2011 0900 - 1130 Room 101D 9:00 - 09:20 AM, Preliminaries (20 minutes) Audio/Video & Remote Presentation Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status IPv6 items (15 minutes) 9:20 - 9:35 AM RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec (15 = minutes) http://tools.ietf.org/html/draft-ietf-radext-ipv6-access Enhancement items (45 minutes) 9:35 - 9:50 AM RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh= (15 minutes) http://tools.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01.txt 9:50 - 10:05 AM RADIUS accounting for traffic classes, Stefan Winter (15 mi= n) http://tools.ietf.org/html/draft-winter-radext-fancyaccounting 10:05 - 10:20 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (15= minutes) http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt 10:20 - 10:35 AM RADIUS Protocol Extensions, Alan DeKok (15 minutes) http://tools.ietf.org/html/draft-ietf-radext-radius-extensions 10:35 - 10:50 AM Network Access Identifier, Alan DeKok (15 minutes) http://tools.ietf.org/html/draft-dekok-radext-nai-01 Discussion and Wrap-up (35 minutes) 10:50 - 11:10 AM Discussion (20 minutes) 11:10 - 11:25 AM Next Steps: WG Chairs & ADs (15 minutes) WG Goals/Milestones status --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0C05FF6GVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Below is updated= agenda for tomorrow.

 <= /p>

Cheers,

Mauricio=

 

--------------------------------------------

RADEXT WG IETF 82 Agenda

&n= bsp;

Chairs:

Jouni Korhonen <jouni.korhonen at nsn.com>

Mauricio Sanchez <mauricio.sanchez at hp.com>=

 

Jabber r= oom: radext at jabber.ietf.org (Please join)

 

Monday, November 14, 2011

0900 - 1130

Room 101D

 

9:00 - 09:20 AM, Preliminaries (20 minutes)

Audio/Video & Remote Presentation Debugging<= /o:p>

Note Well

= Note Takers

Jabber scribe

=

Agenda bash

Documen= t Status

 

 

IPv6 items (15 minut= es)

9:20 - 9:35 AM RADIUS Attributes for= IPv6 Access Networks, Wojcieh Dec (15 minutes)

http://tools.ietf.org/html/draft-ietf-radext-ipv6-access=

 

&nb= sp;

Enhancement items (45 minutes)=

9:35 - 9:50 AM RADIUS Accounting Extensions of Tra= ffic Statistics, Leaf Yeh (15 minutes)

h= ttp://tools.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01.txt=

 

9:= 50 - 10:05 AM RADIUS accounting for traffic classes, Stefan Winter (15 min)=

http://tools.ietf.org/html/draft-winte= r-radext-fancyaccounting

 

10:05 - 10:20 AM RADIUS Attributes for IEEE 802 = Networks, Bernard Aboba (15 minutes)

htt= p://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt

 

10:20 - 10:35 AM RAD= IUS Protocol Extensions, Alan DeKok (15 minutes)

http://tools.ietf.org/html/draft-ietf-radext-radius-extensions

 

1= 0:35 - 10:50 AM Network Access Identifier, Alan DeKok (15 minutes)

http://tools.ietf.org/html/draft-dekok-radext-na= i-01

 

 

Discussion and Wrap-up (35= minutes)

10:50 – 11:10 AM Discuss= ion (20 minutes)

 

11:10 - 11:25 AM Next Steps: WG Chairs & ADs (15 min= utes)

WG Goals/Milestones status

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0C05FF6GVW0671EXCame_-- From radext-bounces@ietf.org Sun Nov 13 02:00:54 2011 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 C0FAF21F8B52; Sun, 13 Nov 2011 02:00:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321178454; bh=sz0A/i0uL2yumcGosRRfD/Q/SVo3XMI8yUEjA20gYHs=; h=From:To:Date:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=EnmkjDFWldVIjTb5R85cm0BHeCQQ+mwliclZSi3FBqqQXcMPxMbXTV/iSgbBrTxt9 JdJ5dfX1lwdxOWvu4Bb2Di58BwgRsn8KCbMXuXsSNka4cuTrIj+OMRSAykQJZGqVAF I2m2pZwbuuDXMZzI/TWM0HMcLehXd71e7MdjRiHE= 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 A2FD521F8B52 for ; Sun, 13 Nov 2011 02:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.505 X-Spam-Level: X-Spam-Status: No, score=-106.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 TyCuTThzMKcc for ; Sun, 13 Nov 2011 02:00:51 -0800 (PST) Received: from g6t0184.atlanta.hp.com (g6t0184.atlanta.hp.com [15.193.32.61]) by ietfa.amsl.com (Postfix) with ESMTP id 06CCD21F847A for ; Sun, 13 Nov 2011 02:00:50 -0800 (PST) Received: from G4W3011G.americas.hpqcorp.net (g4w3011g.houston.hp.com [16.234.25.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0184.atlanta.hp.com (Postfix) with ESMTPS id E5FDEC0D4 for ; Sun, 13 Nov 2011 10:00:50 +0000 (UTC) Received: from G5W0602.americas.hpqcorp.net (16.228.9.185) by G4W3011G.americas.hpqcorp.net (16.234.25.125) with Microsoft SMTP Server (TLS) id 14.1.289.1; Sun, 13 Nov 2011 10:00:18 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0602.americas.hpqcorp.net ([16.228.9.185]) with mapi; Sun, 13 Nov 2011 10:00:17 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Sun, 13 Nov 2011 10:00:15 +0000 Thread-Topic: IETF 82: Updated meeting agenda Thread-Index: Acyh6u3Y31Id+t4FRymvnL+dDJDYxg== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD0C05FF6@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [radext] IETF 82: Updated meeting agenda 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="===============4675134992530976652==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============4675134992530976652== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0C05FF6GVW0671EXCame_" --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0C05FF6GVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Below is updated agenda for tomorrow. Cheers, Mauricio -------------------------------------------- RADEXT WG IETF 82 Agenda Chairs: Jouni Korhonen Mauricio Sanchez Jabber room: radext at jabber.ietf.org (Please join) Monday, November 14, 2011 0900 - 1130 Room 101D 9:00 - 09:20 AM, Preliminaries (20 minutes) Audio/Video & Remote Presentation Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status IPv6 items (15 minutes) 9:20 - 9:35 AM RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec (15 = minutes) http://tools.ietf.org/html/draft-ietf-radext-ipv6-access Enhancement items (45 minutes) 9:35 - 9:50 AM RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh= (15 minutes) http://tools.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01.txt 9:50 - 10:05 AM RADIUS accounting for traffic classes, Stefan Winter (15 mi= n) http://tools.ietf.org/html/draft-winter-radext-fancyaccounting 10:05 - 10:20 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (15= minutes) http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt 10:20 - 10:35 AM RADIUS Protocol Extensions, Alan DeKok (15 minutes) http://tools.ietf.org/html/draft-ietf-radext-radius-extensions 10:35 - 10:50 AM Network Access Identifier, Alan DeKok (15 minutes) http://tools.ietf.org/html/draft-dekok-radext-nai-01 Discussion and Wrap-up (35 minutes) 10:50 - 11:10 AM Discussion (20 minutes) 11:10 - 11:25 AM Next Steps: WG Chairs & ADs (15 minutes) WG Goals/Milestones status --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0C05FF6GVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Below is updated= agenda for tomorrow.

 <= /p>

Cheers,

Mauricio=

 

--------------------------------------------

RADEXT WG IETF 82 Agenda

&n= bsp;

Chairs:

Jouni Korhonen <jouni.korhonen at nsn.com>

Mauricio Sanchez <mauricio.sanchez at hp.com>=

 

Jabber r= oom: radext at jabber.ietf.org (Please join)

 

Monday, November 14, 2011

0900 - 1130

Room 101D

 

9:00 - 09:20 AM, Preliminaries (20 minutes)

Audio/Video & Remote Presentation Debugging<= /o:p>

Note Well

= Note Takers

Jabber scribe

=

Agenda bash

Documen= t Status

 

 

IPv6 items (15 minut= es)

9:20 - 9:35 AM RADIUS Attributes for= IPv6 Access Networks, Wojcieh Dec (15 minutes)

http://tools.ietf.org/html/draft-ietf-radext-ipv6-access=

 

&nb= sp;

Enhancement items (45 minutes)=

9:35 - 9:50 AM RADIUS Accounting Extensions of Tra= ffic Statistics, Leaf Yeh (15 minutes)

h= ttp://tools.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01.txt=

 

9:= 50 - 10:05 AM RADIUS accounting for traffic classes, Stefan Winter (15 min)=

http://tools.ietf.org/html/draft-winte= r-radext-fancyaccounting

 

10:05 - 10:20 AM RADIUS Attributes for IEEE 802 = Networks, Bernard Aboba (15 minutes)

htt= p://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt

 

10:20 - 10:35 AM RAD= IUS Protocol Extensions, Alan DeKok (15 minutes)

http://tools.ietf.org/html/draft-ietf-radext-radius-extensions

 

1= 0:35 - 10:50 AM Network Access Identifier, Alan DeKok (15 minutes)

http://tools.ietf.org/html/draft-dekok-radext-na= i-01

 

 

Discussion and Wrap-up (35= minutes)

10:50 – 11:10 AM Discuss= ion (20 minutes)

 

11:10 - 11:25 AM Next Steps: WG Chairs & ADs (15 min= utes)

WG Goals/Milestones status

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0C05FF6GVW0671EXCame_-- --===============4675134992530976652== 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 --===============4675134992530976652==-- From radext-bounces@ietf.org Sun Nov 13 17:48:00 2011 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 9CDF91F0C53; Sun, 13 Nov 2011 17:48:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321235280; bh=GHwS2gZYlQIiDqDy2OUfo8DMo/fGQTDd6JR0DjMPNAY=; 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=NZxRQPiXtzd1ef4BM6pxW6WSH8/sP1108ksBGIM/AbOY8WVY5GdEGL4a2EgkX2zkL kTXE0tukDS7scD4XnzNX9ypM2JNcxhZifbZVgmB2TSBEwBNdYH4umhJ2s6HBUXh2OS XNvfGcIbwSuZADK0q6XnsmxK20/0M5o/Yk6AfsBs= 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 86E271F0C56; Sun, 13 Nov 2011 17:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 Ms-T--qnh-mu; Sun, 13 Nov 2011 17:47:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167B11F0C52; Sun, 13 Nov 2011 17:47:59 -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.63 Message-ID: <20111114014759.14198.41761.idtracker@ietfa.amsl.com> Date: Sun, 13 Nov 2011 17:47:59 -0800 Cc: radext@ietf.org Subject: [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 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 internet-drafts@ietf.org Sun Nov 13 17:47:59 2011 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 86E271F0C56; Sun, 13 Nov 2011 17:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 Ms-T--qnh-mu; Sun, 13 Nov 2011 17:47:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167B11F0C52; Sun, 13 Nov 2011 17:47:59 -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.63 Message-ID: <20111114014759.14198.41761.idtracker@ietfa.amsl.com> Date: Sun, 13 Nov 2011 17:47:59 -0800 Cc: radext@ietf.org Subject: [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: Mon, 14 Nov 2011 01:47:59 -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 : 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 From trac+radext@trac.tools.ietf.org Sun Nov 13 17:38:01 2011 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 3F24621F8783 for ; Sun, 13 Nov 2011 17:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aD3o9PzE2ZKt for ; Sun, 13 Nov 2011 17:38:00 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5319521F8487 for ; Sun, 13 Nov 2011 17:37:59 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RPlUk-0004Aj-F1; Sun, 13 Nov 2011 20:37:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: blourdel@cisco.com, wdec@cisco.com X-Trac-Project: radext Date: Mon, 14 Nov 2011 01:37:58 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/radext/trac/ticket/107#comment:1 Message-ID: <081.b470d291cb8993cd7aa4a15038b559d3@trac.tools.ietf.org> References: <066.4896d189d81ed4299493f866d2d586f9@trac.tools.ietf.org> X-Trac-Ticket-ID: 107 In-Reply-To: <066.4896d189d81ed4299493f866d2d586f9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: blourdel@cisco.com, wdec@cisco.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Sun, 13 Nov 2011 18:40:58 -0800 Cc: radext@ietf.org Subject: Re: [radext] #107: Section 1 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 01:38:01 -0000 #107: Section 1 Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Accepted. Fixed in draft -06 -- -----------------------------+------------------------- Reporter: bernard_aboba@… | Owner: blourdel@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Sun Nov 13 17:39:21 2011 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 122D821F893C for ; Sun, 13 Nov 2011 17:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uE+7sCsQY+ae for ; Sun, 13 Nov 2011 17:39:20 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 983AA21F8783 for ; Sun, 13 Nov 2011 17:39:20 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RPlW4-0006Ze-AN; Sun, 13 Nov 2011 20:39:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: blourdel@cisco.com, wdec@cisco.com X-Trac-Project: radext Date: Mon, 14 Nov 2011 01:39:20 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/radext/trac/ticket/106#comment:1 Message-ID: <081.8cf052d8371f248517a8f97e019ff981@trac.tools.ietf.org> References: <066.d61ca499e4af7cdaa82deb4389d9ef78@trac.tools.ietf.org> X-Trac-Ticket-ID: 106 In-Reply-To: <066.d61ca499e4af7cdaa82deb4389d9ef78@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: blourdel@cisco.com, wdec@cisco.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Sun, 13 Nov 2011 18:40:58 -0800 Cc: radext@ietf.org Subject: Re: [radext] #106: Section 2.1 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 01:39:21 -0000 #106: Section 2.1 Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Accepted. Fixed in draft -06 -- -----------------------------+------------------------- Reporter: bernard_aboba@… | Owner: blourdel@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Sun Nov 13 17:40:28 2011 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 3284F21F8997 for ; Sun, 13 Nov 2011 17:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eU3St-PpVANs for ; Sun, 13 Nov 2011 17:40:27 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id C40E621F893C for ; Sun, 13 Nov 2011 17:40:27 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RPlX9-0008OD-G1; Sun, 13 Nov 2011 20:40:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: blourdel@cisco.com, wdec@cisco.com X-Trac-Project: radext Date: Mon, 14 Nov 2011 01:40:27 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/radext/trac/ticket/105#comment:1 Message-ID: <081.7a97ce4b6288fa55aa1c5bcc5a9c9d66@trac.tools.ietf.org> References: <066.1923484d92fc28741af4326bb28cfeda@trac.tools.ietf.org> X-Trac-Ticket-ID: 105 In-Reply-To: <066.1923484d92fc28741af4326bb28cfeda@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: blourdel@cisco.com, wdec@cisco.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Sun, 13 Nov 2011 18:40:58 -0800 Cc: radext@ietf.org Subject: Re: [radext] #105: Section 2.3 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 01:40:28 -0000 #105: Section 2.3 Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Accepted. Fixed in draft -06 -- -----------------------------+------------------------- Reporter: bernard_aboba@… | Owner: blourdel@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+------------------------- Ticket URL: radext From radext-bounces@ietf.org Sun Nov 13 18:41:00 2011 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 E5F7311E8189; Sun, 13 Nov 2011 18:40:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321238459; bh=SkVyfPQdRGW9L9VnlQF98hv7hOOQIrcHDd8WwlALWTA=; h=MIME-Version:From:To:Date:Message-ID:References:In-Reply-To:Cc: Subject:Reply-To:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:Content-Type:Content-Transfer-Encoding: Sender; b=Dmy0KtXSDjrvAHR8Yb0w5E2gm0f3QpmqHbBQToaLm75OzqJzNHsQnBsID+ICHpXid gdQxsdqQZY/IWvDEIVarQVkh/79Mm3KuR8Dc1zotPOwfU5sfILZrBsY5vyJuI2yxTj JAlER2iZ/ZuImXFyKGmMhQ0jxN/amieqQeyPGukc= 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 3F24621F8783 for ; Sun, 13 Nov 2011 17:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aD3o9PzE2ZKt for ; Sun, 13 Nov 2011 17:38:00 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5319521F8487 for ; Sun, 13 Nov 2011 17:37:59 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RPlUk-0004Aj-F1; Sun, 13 Nov 2011 20:37:58 -0500 MIME-Version: 1.0 From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: blourdel@cisco.com, wdec@cisco.com X-Trac-Project: radext Date: Mon, 14 Nov 2011 01:37:58 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/radext/trac/ticket/107#comment:1 Message-ID: <081.b470d291cb8993cd7aa4a15038b559d3@trac.tools.ietf.org> References: <066.4896d189d81ed4299493f866d2d586f9@trac.tools.ietf.org> X-Trac-Ticket-ID: 107 In-Reply-To: <066.4896d189d81ed4299493f866d2d586f9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: blourdel@cisco.com, wdec@cisco.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Sun, 13 Nov 2011 18:40:58 -0800 Cc: radext@ietf.org Subject: Re: [radext] #107: Section 1 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org 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 IzEwNzogU2VjdGlvbiAxCgpDaGFuZ2VzIChieSB3ZGVjQOKApik6CgogKiBzdGF0dXM6ICBuZXcg PT4gY2xvc2VkCiAqIHJlc29sdXRpb246ICAgPT4gZml4ZWQKCgpDb21tZW50OgoKIEFjY2VwdGVk LiBGaXhlZCBpbiBkcmFmdCAtMDYKCi0tIAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiBSZXBvcnRlcjogIGJlcm5hcmRfYWJvYmFA4oCmICB8 ICAgICAgIE93bmVyOiAgYmxvdXJkZWxA4oCmCiAgICAgVHlwZTogIGRlZmVjdCAgICAgICAgICAg fCAgICAgIFN0YXR1czogIGNsb3NlZAogUHJpb3JpdHk6ICBtaW5vciAgICAgICAgICAgIHwgICBN aWxlc3RvbmU6ICBtaWxlc3RvbmUxCkNvbXBvbmVudDogIGlwdjYtYWNjZXNzICAgICAgfCAgICAg VmVyc2lvbjogIDEuMAogU2V2ZXJpdHk6ICBJbiBXRyBMYXN0IENhbGwgIHwgIFJlc29sdXRpb246 ICBmaXhlZAogS2V5d29yZHM6ICAgICAgICAgICAgICAgICAgIHwKLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKVGlja2V0IFVSTDogPGh0dHBz Oi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9yYWRleHQvdHJhYy90aWNrZXQvMTA3I2NvbW1lbnQ6 MT4KcmFkZXh0IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmFkZXh0Lz4KCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCnJhZGV4dCBtYWlsaW5nIGxpc3QKcmFk ZXh0QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0 Cg== From radext-bounces@ietf.org Sun Nov 13 18:41:00 2011 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 532E111E8191; Sun, 13 Nov 2011 18:41:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321238460; bh=jg7jwN8g9lb071sJ5woY2UrV8esD2AAimM/Mb1Rz0G4=; h=MIME-Version:From:To:Date:Message-ID:References:In-Reply-To:Cc: Subject:Reply-To:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:Content-Type:Content-Transfer-Encoding: Sender; b=BxvJmP5Ji4wSbZzh8p7nXjTgYyL7AqOwl7LFNHGy6J9lu8fxHj1iGHPUR9fgqZqDf E+QoDGDTzP7Nw/7pzlrkB0SmQJ6XWC7i4pNKvSEzdLI2YCr/BuqHD8UmHaDJvwWBvv 1I4eaSS3dp20md5Uv/b4ZeIAXiW0nVcvT/9E0TFI= 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 122D821F893C for ; Sun, 13 Nov 2011 17:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uE+7sCsQY+ae for ; Sun, 13 Nov 2011 17:39:20 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 983AA21F8783 for ; Sun, 13 Nov 2011 17:39:20 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RPlW4-0006Ze-AN; Sun, 13 Nov 2011 20:39:20 -0500 MIME-Version: 1.0 From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: blourdel@cisco.com, wdec@cisco.com X-Trac-Project: radext Date: Mon, 14 Nov 2011 01:39:20 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/radext/trac/ticket/106#comment:1 Message-ID: <081.8cf052d8371f248517a8f97e019ff981@trac.tools.ietf.org> References: <066.d61ca499e4af7cdaa82deb4389d9ef78@trac.tools.ietf.org> X-Trac-Ticket-ID: 106 In-Reply-To: <066.d61ca499e4af7cdaa82deb4389d9ef78@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: blourdel@cisco.com, wdec@cisco.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Sun, 13 Nov 2011 18:40:58 -0800 Cc: radext@ietf.org Subject: Re: [radext] #106: Section 2.1 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org 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 IzEwNjogU2VjdGlvbiAyLjEKCkNoYW5nZXMgKGJ5IHdkZWNA4oCmKToKCiAqIHN0YXR1czogIG5l dyA9PiBjbG9zZWQKICogcmVzb2x1dGlvbjogICA9PiBmaXhlZAoKCkNvbW1lbnQ6CgogQWNjZXB0 ZWQuIEZpeGVkIGluICBkcmFmdCAtMDYKCi0tIAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiBSZXBvcnRlcjogIGJlcm5hcmRfYWJvYmFA4oCm ICB8ICAgICAgIE93bmVyOiAgYmxvdXJkZWxA4oCmCiAgICAgVHlwZTogIGRlZmVjdCAgICAgICAg ICAgfCAgICAgIFN0YXR1czogIGNsb3NlZAogUHJpb3JpdHk6ICBtYWpvciAgICAgICAgICAgIHwg ICBNaWxlc3RvbmU6ICBtaWxlc3RvbmUxCkNvbXBvbmVudDogIGlwdjYtYWNjZXNzICAgICAgfCAg ICAgVmVyc2lvbjogIDEuMAogU2V2ZXJpdHk6ICBJbiBXRyBMYXN0IENhbGwgIHwgIFJlc29sdXRp b246ICBmaXhlZAogS2V5d29yZHM6ICAgICAgICAgICAgICAgICAgIHwKLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKVGlja2V0IFVSTDogPGh0 dHBzOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9yYWRleHQvdHJhYy90aWNrZXQvMTA2I2NvbW1l bnQ6MT4KcmFkZXh0IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmFkZXh0Lz4KCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCnJhZGV4dCBtYWlsaW5nIGxpc3QK cmFkZXh0QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFk ZXh0Cg== From radext-bounces@ietf.org Sun Nov 13 18:41:00 2011 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 9F40E11E8195; Sun, 13 Nov 2011 18:41:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321238460; bh=O4MzwKOPQRu49POZtFt21OfIWG0yE1hvgVW5Nzs8IwA=; h=MIME-Version:From:To:Date:Message-ID:References:In-Reply-To:Cc: Subject:Reply-To:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:Content-Type:Content-Transfer-Encoding: Sender; b=ry5UfPhTQnnSGF75ykGUGfHfdZbksLiIYsa22n6PhxbtTevFkJ2XAfUrnKpHfN4Q6 oFp06Q1CcfOdTY2B3N+DuBJInZzj2hAr43gqjMrVHOeoFmsE9prXPx9zEUHv+4FtRq MJy6tHDmmfMKxLWXIxa23vXdMRRSpG2PLBccpkHw= 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 3284F21F8997 for ; Sun, 13 Nov 2011 17:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eU3St-PpVANs for ; Sun, 13 Nov 2011 17:40:27 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id C40E621F893C for ; Sun, 13 Nov 2011 17:40:27 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RPlX9-0008OD-G1; Sun, 13 Nov 2011 20:40:27 -0500 MIME-Version: 1.0 From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: blourdel@cisco.com, wdec@cisco.com X-Trac-Project: radext Date: Mon, 14 Nov 2011 01:40:27 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/radext/trac/ticket/105#comment:1 Message-ID: <081.7a97ce4b6288fa55aa1c5bcc5a9c9d66@trac.tools.ietf.org> References: <066.1923484d92fc28741af4326bb28cfeda@trac.tools.ietf.org> X-Trac-Ticket-ID: 105 In-Reply-To: <066.1923484d92fc28741af4326bb28cfeda@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: blourdel@cisco.com, wdec@cisco.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Sun, 13 Nov 2011 18:40:58 -0800 Cc: radext@ietf.org Subject: Re: [radext] #105: Section 2.3 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org 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 IzEwNTogU2VjdGlvbiAyLjMKCkNoYW5nZXMgKGJ5IHdkZWNA4oCmKToKCiAqIHN0YXR1czogIG5l dyA9PiBjbG9zZWQKICogcmVzb2x1dGlvbjogICA9PiBmaXhlZAoKCkNvbW1lbnQ6CgogQWNjZXB0 ZWQuIEZpeGVkIGluIGRyYWZ0IC0wNgoKLS0gCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KIFJlcG9ydGVyOiAgYmVybmFyZF9hYm9iYUDigKYg IHwgICAgICAgT3duZXI6ICBibG91cmRlbEDigKYKICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAg ICB8ICAgICAgU3RhdHVzOiAgY2xvc2VkCiBQcmlvcml0eTogIG1ham9yICAgICAgICAgICAgfCAg IE1pbGVzdG9uZTogIG1pbGVzdG9uZTEKQ29tcG9uZW50OiAgaXB2Ni1hY2Nlc3MgICAgICB8ICAg ICBWZXJzaW9uOiAgMS4wCiBTZXZlcml0eTogIEluIFdHIExhc3QgQ2FsbCAgfCAgUmVzb2x1dGlv bjogIGZpeGVkCiBLZXl3b3JkczogICAgICAgICAgICAgICAgICAgfAotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpUaWNrZXQgVVJMOiA8aHR0 cDovL3dpa2kudG9vbHMuaWV0Zi5vcmcvd2cvcmFkZXh0L3RyYWMvdGlja2V0LzEwNSNjb21tZW50 OjE+CnJhZGV4dCA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3JhZGV4dC8+CgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpyYWRleHQgbWFpbGluZyBsaXN0CnJh ZGV4dEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JhZGV4 dAo= From radext-bounces@ietf.org Mon Nov 14 00:47:23 2011 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 6FEDE21F8E71; Mon, 14 Nov 2011 00:47:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321260443; bh=ZBmWKQ2DQiPR0HfTh4TeJ5vWxbnzn8/xy94cotvCXPk=; h=Message-ID:Date:From:MIME-Version:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=uVYMgLnwTrKGVmRJKU+4A07BJejzHaWzBPxjWmm4+rWuuhTL/Rtnydsquh/lwoE/u 5o67MtzbkjuU9GLXklCElx2/KNUL5AwB+uZxfhvKDl0ZPXPUHpOqsTJ9z8+aNBPIWT MQOcQaae1vXVs6aTI2eg00+/vc/YjzZEN4Wr7fJc= 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 6017821F8E71 for ; Mon, 14 Nov 2011 00:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 sqkXMHlGG5yk for ; Mon, 14 Nov 2011 00:47:06 -0800 (PST) Received: from legolas.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) by ietfa.amsl.com (Postfix) with ESMTP id 5A24C21F8DB8 for ; Mon, 14 Nov 2011 00:47:06 -0800 (PST) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id 4FB799DD08 for ; Mon, 14 Nov 2011 09:47:03 +0100 (CET) Received: from [158.64.15.247] (247-15.vpn.restena.lu [158.64.15.247]) by legolas.restena.lu (Postfix) with ESMTPSA id A471D9DD15 for ; Mon, 14 Nov 2011 09:47:02 +0100 (CET) Message-ID: <4EC0D582.8060701@restena.lu> Date: Mon, 14 Nov 2011 09:46:58 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: radext@ietf.org X-Enigmail-Version: 1.3.3 X-Virus-Scanned: ClamAV Subject: [radext] Accounting for traffic classes 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 Hi, following a discussion I had with Leaf, here are some basic thoughts about the different approaches. First off, both of the approaches depend on the radius-extensions-02 draft; they use Integer64 as a data type. Second, both are backwards compatible in that a IPv4-only network does not have to use the new drafts for reporting accounting; the "good old" Acct-Input/Output-Octets/Packets from RFC2866 continue to exist and are not deprecated. The main difference is really in the encoding approach: * draft-yeh "stuffs" complex information into a single attribute (design 2 and 4 on his today's slides); an implementer would need to write a custom parser for these statistics attributes. * draft-winter uses the TLV grouping from radius-extensions to encode content in sub-attributes. An implementor needs a parser for extended attributes; such a parser is useful for *any* attribute needing TLVs. That draft is pretty much the same as what Leaf presented as "Design 3" today. If a RADIUS device has not implemented TLV attributes yet, both approaches need an amount of parser writing. Such an implementer would likely need slightly less code to implement draft-yeh; the nesting of attributes in a TLV group is *slightly* more complex. So, if all you care for is these new statistics attributes, it's less work to do it with draft-yeh. Then again, RADIUS Design Guidelines (BCP!) say that complex attribute encodings shouldn't be used if a viable alternative exists. radius-extensions provide such a viable alternative, it's the TLVs. So, if you care for re-usable code, it is more advisable to write a parser for TLVs - then, you can send traffic statistics with draft-winter *and* can handle any other attribute that uses TLVs. That way is also in line with the recommendations in the Design guidelines. Given that no other attribute in use currently uses TLVs, the difference is not big. I'm trying to "evangelize" other WGs who do RADIUS stuff though to also make use of TLVs; after reading softwire's 6rd RADIUS Attributes draft I see that their extremely complex attribute encoding is something that's crying for TLVs instead. In summary, I concur with Leaf that *right now*, the advantage is non-existent. I'm still in favour of TLVs though; their advantage will play out over time with new attributes that need to encode complex attributes. That, and that not using them violates RADIUS Design Guidelines. Greetings, Stefan Winter _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From stefan.winter@restena.lu Mon Nov 14 00:47:22 2011 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 6017821F8E71 for ; Mon, 14 Nov 2011 00:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 sqkXMHlGG5yk for ; Mon, 14 Nov 2011 00:47:06 -0800 (PST) Received: from legolas.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) by ietfa.amsl.com (Postfix) with ESMTP id 5A24C21F8DB8 for ; Mon, 14 Nov 2011 00:47:06 -0800 (PST) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id 4FB799DD08 for ; Mon, 14 Nov 2011 09:47:03 +0100 (CET) Received: from [158.64.15.247] (247-15.vpn.restena.lu [158.64.15.247]) by legolas.restena.lu (Postfix) with ESMTPSA id A471D9DD15 for ; Mon, 14 Nov 2011 09:47:02 +0100 (CET) Message-ID: <4EC0D582.8060701@restena.lu> Date: Mon, 14 Nov 2011 09:46:58 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: radext@ietf.org X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV Subject: [radext] Accounting for traffic classes 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: Mon, 14 Nov 2011 08:47:22 -0000 Hi, following a discussion I had with Leaf, here are some basic thoughts about the different approaches. First off, both of the approaches depend on the radius-extensions-02 draft; they use Integer64 as a data type. Second, both are backwards compatible in that a IPv4-only network does not have to use the new drafts for reporting accounting; the "good old" Acct-Input/Output-Octets/Packets from RFC2866 continue to exist and are not deprecated. The main difference is really in the encoding approach: * draft-yeh "stuffs" complex information into a single attribute (design 2 and 4 on his today's slides); an implementer would need to write a custom parser for these statistics attributes. * draft-winter uses the TLV grouping from radius-extensions to encode content in sub-attributes. An implementor needs a parser for extended attributes; such a parser is useful for *any* attribute needing TLVs. That draft is pretty much the same as what Leaf presented as "Design 3" today. If a RADIUS device has not implemented TLV attributes yet, both approaches need an amount of parser writing. Such an implementer would likely need slightly less code to implement draft-yeh; the nesting of attributes in a TLV group is *slightly* more complex. So, if all you care for is these new statistics attributes, it's less work to do it with draft-yeh. Then again, RADIUS Design Guidelines (BCP!) say that complex attribute encodings shouldn't be used if a viable alternative exists. radius-extensions provide such a viable alternative, it's the TLVs. So, if you care for re-usable code, it is more advisable to write a parser for TLVs - then, you can send traffic statistics with draft-winter *and* can handle any other attribute that uses TLVs. That way is also in line with the recommendations in the Design guidelines. Given that no other attribute in use currently uses TLVs, the difference is not big. I'm trying to "evangelize" other WGs who do RADIUS stuff though to also make use of TLVs; after reading softwire's 6rd RADIUS Attributes draft I see that their extremely complex attribute encoding is something that's crying for TLVs instead. In summary, I concur with Leaf that *right now*, the advantage is non-existent. I'm still in favour of TLVs though; their advantage will play out over time with new attributes that need to encode complex attributes. That, and that not using them violates RADIUS Design Guidelines. Greetings, Stefan Winter From aland@deployingradius.com Mon Nov 14 01:21:30 2011 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 9162E21F8DBC for ; Mon, 14 Nov 2011 01:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 5CDquBHbvr0f for ; Mon, 14 Nov 2011 01:21:20 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id DB6C321F8512 for ; Mon, 14 Nov 2011 01:21:18 -0800 (PST) Message-ID: <4EC0DD6F.4030405@deployingradius.com> Date: Mon, 14 Nov 2011 10:20:47 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <4EC0D582.8060701@restena.lu> In-Reply-To: <4EC0D582.8060701@restena.lu> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] Accounting for traffic classes 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: Mon, 14 Nov 2011 09:21:32 -0000 Stefan Winter wrote: > The main difference is really in the encoding approach: And extensibility. Using a complex format means it is *impossible* to add new fields to the accounting attribute. Using TLVs means that is is *easy* to add new fields. > Given that no other attribute in use currently uses TLVs, the difference > is not big. The draft points out that there are many attributes which use TLVs. WiMAX and 3GPP have used TLVs extensively. Many NAS manufacturers and all major RADIUS servers already support TLVs. > I'm trying to "evangelize" other WGs who do RADIUS stuff > though to also make use of TLVs; after reading softwire's 6rd RADIUS > Attributes draft I see that their extremely complex attribute encoding > is something that's crying for TLVs instead. I agree. > In summary, I concur with Leaf that *right now*, the advantage is > non-existent. I disagree. The advantage is what you say below. The alternative is to make this decision for *every* draft. "It's not any more complicated to have a custom format than to use the new format". So this argument will be made for *every* draft. The result will be that the new format never gets implemented. At some point, we have to decide to use the new format. We might as well do it now. I see no benefit to delay, delay, delay, delay. > I'm still in favour of TLVs though; their advantage will > play out over time with new attributes that need to encode complex > attributes. That, and that not using them violates RADIUS Design Guidelines. Alan DeKok. From radext-bounces@ietf.org Mon Nov 14 01:21:57 2011 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 2BA6E21F8DE3; Mon, 14 Nov 2011 01:21:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321262516; bh=GtquCQTt1VTbfRelHVQ21ApM5vl8yyV7f/6i0MWqymE=; 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=D812oJOU+LNzPI4xgrQz4V5GgvksteuxBbU2MYBZk2Yzwy5jXBv51kv9kYWAqIjIH aCE12l+lA270r9pikSOK3nZ2Kr1ySxp0HDahCBQiEDMD5X4ortU2e4mL4L8xljp05Y 4pbY2bKydhoLYVDLMdHIbhAhF0IAcXTz4vqeNtsY= 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 9162E21F8DBC for ; Mon, 14 Nov 2011 01:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 5CDquBHbvr0f for ; Mon, 14 Nov 2011 01:21:20 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id DB6C321F8512 for ; Mon, 14 Nov 2011 01:21:18 -0800 (PST) Message-ID: <4EC0DD6F.4030405@deployingradius.com> Date: Mon, 14 Nov 2011 10:20:47 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <4EC0D582.8060701@restena.lu> In-Reply-To: <4EC0D582.8060701@restena.lu> X-Enigmail-Version: 0.96.0 Cc: radext@ietf.org Subject: Re: [radext] Accounting for traffic classes 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 Stefan Winter wrote: > The main difference is really in the encoding approach: And extensibility. Using a complex format means it is *impossible* to add new fields to the accounting attribute. Using TLVs means that is is *easy* to add new fields. > Given that no other attribute in use currently uses TLVs, the difference > is not big. The draft points out that there are many attributes which use TLVs. WiMAX and 3GPP have used TLVs extensively. Many NAS manufacturers and all major RADIUS servers already support TLVs. > I'm trying to "evangelize" other WGs who do RADIUS stuff > though to also make use of TLVs; after reading softwire's 6rd RADIUS > Attributes draft I see that their extremely complex attribute encoding > is something that's crying for TLVs instead. I agree. > In summary, I concur with Leaf that *right now*, the advantage is > non-existent. I disagree. The advantage is what you say below. The alternative is to make this decision for *every* draft. "It's not any more complicated to have a custom format than to use the new format". So this argument will be made for *every* draft. The result will be that the new format never gets implemented. At some point, we have to decide to use the new format. We might as well do it now. I see no benefit to delay, delay, delay, delay. > I'm still in favour of TLVs though; their advantage will > play out over time with new attributes that need to encode complex > attributes. That, and that not using them violates RADIUS Design Guidelines. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Mon Nov 14 04:37:37 2011 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 B21C711E822F; Mon, 14 Nov 2011 04:37:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321274257; bh=mUIR8qsqq0jbfrCk2zLxaLleWVau9UuxYzAq+LGVhjY=; 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=Gofkft/BQ6aLVY6p/o7QtN9/WyCNh5ZU6i7GUXm5uUJKFY/pcoHUt+yWluCsHPasB mqkZhFxrJhRBn0umgHoNrcm4sYkDMV2fJqdmQRXjjXGfEzB2ZltSAbpYCWLPMAzAkm KEQ31XW71Ppyl5rijvoq5wbbbjGhIFpJjaJ6emkk= 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 EF0B311E822F for ; Mon, 14 Nov 2011 04:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feKR7ZTo4q0l for ; Mon, 14 Nov 2011 04:37:36 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0C911E814D for ; Mon, 14 Nov 2011 04:37:36 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta06.westchester.pa.mail.comcast.net with comcast id x0ZB1h0081HzFnQ560dcMM; Mon, 14 Nov 2011 12:37:36 +0000 Received: from sz0057.wc.mail.comcast.net ([76.96.58.111]) by omta14.westchester.pa.mail.comcast.net with comcast id x0dc1h00F2PzLBw3a0dc0M; Mon, 14 Nov 2011 12:37:36 +0000 Date: Mon, 14 Nov 2011 12:37:35 +0000 (UTC) From: "David B. Nelson" To: Alan DeKok Message-ID: <302514528.2606057.1321274255818.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> In-Reply-To: <4EC0DD6F.4030405@deployingradius.com> MIME-Version: 1.0 X-Originating-IP: [24.218.90.45] X-Mailer: Zimbra 6.0.13_GA_2934 (ZimbraWebClient - FF3.0 (Mac)/6.0.13_GA_2934) Cc: radext@ietf.org, Stefan Winter Subject: Re: [radext] Accounting for traffic classes 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 DeKok writes: > The alternative is to make this decision for *every* draft. "It's not > any more complicated to have a custom format than to use the new > format". So this argument will be made for *every* draft. The result > will be that the new format never gets implemented. > > At some point, we have to decide to use the new format. We might as > well do it now. I see no benefit to delay, delay, delay, delay. +1 _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From d.b.nelson@comcast.net Mon Nov 14 04:37:37 2011 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 EF0B311E822F for ; Mon, 14 Nov 2011 04:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feKR7ZTo4q0l for ; Mon, 14 Nov 2011 04:37:36 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0C911E814D for ; Mon, 14 Nov 2011 04:37:36 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta06.westchester.pa.mail.comcast.net with comcast id x0ZB1h0081HzFnQ560dcMM; Mon, 14 Nov 2011 12:37:36 +0000 Received: from sz0057.wc.mail.comcast.net ([76.96.58.111]) by omta14.westchester.pa.mail.comcast.net with comcast id x0dc1h00F2PzLBw3a0dc0M; Mon, 14 Nov 2011 12:37:36 +0000 Date: Mon, 14 Nov 2011 12:37:35 +0000 (UTC) From: "David B. Nelson" To: Alan DeKok Message-ID: <302514528.2606057.1321274255818.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> In-Reply-To: <4EC0DD6F.4030405@deployingradius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [24.218.90.45] X-Mailer: Zimbra 6.0.13_GA_2934 (ZimbraWebClient - FF3.0 (Mac)/6.0.13_GA_2934) Cc: radext@ietf.org, Stefan Winter Subject: Re: [radext] Accounting for traffic classes 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: Mon, 14 Nov 2011 12:37:37 -0000 Alan DeKok writes: > The alternative is to make this decision for *every* draft. "It's not > any more complicated to have a custom format than to use the new > format". So this argument will be made for *every* draft. The result > will be that the new format never gets implemented. > > At some point, we have to decide to use the new format. We might as > well do it now. I see no benefit to delay, delay, delay, delay. +1 From peterd@iea-software.com Mon Nov 14 09:59:52 2011 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 781F51F0CE8 for ; Mon, 14 Nov 2011 09:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 TOCuPdA2ooST for ; Mon, 14 Nov 2011 09:59:52 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id E91E71F0CCE for ; Mon, 14 Nov 2011 09:59:51 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 14 Nov 2011 06:55:48 -0800 Date: Mon, 14 Nov 2011 06:55:42 -0800 (Pacific Standard Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <4EC0DD6F.4030405@deployingradius.com> Message-ID: References: <4EC0D582.8060701@restena.lu> <4EC0DD6F.4030405@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Stefan Winter , radext@ietf.org Subject: Re: [radext] Accounting for traffic classes 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: Mon, 14 Nov 2011 17:59:52 -0000 On Mon, 14 Nov 2011, Alan DeKok wrote: > Stefan Winter wrote: >> The main difference is really in the encoding approach: > And extensibility. Using a complex format means it is *impossible* to > add new fields to the accounting attribute. Using TLVs means that is is > *easy* to add new fields. Aside from the complexity arguments what if I want to convey only Octet counter(s) or counters for one side of the session? For example in my implementation for some reason Packets are unavailable. How would this be possible? One can't just send elements of a fixed format that you have. Setting the packet count values to zero is not correct either as there are not really zero packets in those fields. The value is undefined meaning the elements should not be sent. regards, Peter From radext-bounces@ietf.org Mon Nov 14 09:59:54 2011 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 26A861F0CE8; Mon, 14 Nov 2011 09:59:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321293594; bh=a/9iYMHV5cQVOEwNaeeHtdnBgfQQVnuQfruFW1F5geY=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=oxSMKmrnHnIyhmgCQHb4ECpVlusk1BVn8GqNGDWahS36gglCwyhxL0DfClaRCJYwW kFXRWEcQlKwl9tX7VSXiOLJ1sGb1zItXYllWSOiPB0L7djuUc5NzWloMZAiy6RZ86s 1lEg+kQb7mXz8qOonq2NXpjP47LNHHGituvqNDYM= 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 781F51F0CE8 for ; Mon, 14 Nov 2011 09:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 TOCuPdA2ooST for ; Mon, 14 Nov 2011 09:59:52 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id E91E71F0CCE for ; Mon, 14 Nov 2011 09:59:51 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 14 Nov 2011 06:55:48 -0800 Date: Mon, 14 Nov 2011 06:55:42 -0800 (Pacific Standard Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <4EC0DD6F.4030405@deployingradius.com> Message-ID: References: <4EC0D582.8060701@restena.lu> <4EC0DD6F.4030405@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Cc: Stefan Winter , radext@ietf.org Subject: Re: [radext] Accounting for traffic classes 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: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On Mon, 14 Nov 2011, Alan DeKok wrote: > Stefan Winter wrote: >> The main difference is really in the encoding approach: > And extensibility. Using a complex format means it is *impossible* to > add new fields to the accounting attribute. Using TLVs means that is is > *easy* to add new fields. Aside from the complexity arguments what if I want to convey only Octet counter(s) or counters for one side of the session? For example in my implementation for some reason Packets are unavailable. How would this be possible? One can't just send elements of a fixed format that you have. Setting the packet count values to zero is not correct either as there are not really zero packets in those fields. The value is undefined meaning the elements should not be sent. regards, Peter _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From jouni.nospam@gmail.com Mon Nov 14 17:57:53 2011 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 5215B11E82BB for ; Mon, 14 Nov 2011 17:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 b2Zh3K0f-xgB for ; Mon, 14 Nov 2011 17:57:52 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD57D11E816C for ; Mon, 14 Nov 2011 17:57:52 -0800 (PST) Received: by ggnr5 with SMTP id r5so1810713ggn.31 for ; Mon, 14 Nov 2011 17:57:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=2Y7nz8MP9mQWv1VZ5WCJvR0jSg8ejLC39yi8RB6tA3g=; b=VV20JSio/WALXMJtQK5EKlMP8TVbtyq89jEpesMeKuPJ63cEpbU2pRMOF2Dfwbp7Do fPhJV+UtjgqfYwwAbUD8dxnu5f+wAl/WCiBckpWGt5wzomBLK9wOJo+c9WnlJbkLZ1X2 av0NjYnNs5dycim9RvAXYmNttxOci2pNMM8x8= Received: by 10.101.75.9 with SMTP id c9mr6809050anl.149.1321322272344; Mon, 14 Nov 2011 17:57:52 -0800 (PST) Received: from ?IPv6:2001:df8::80:226:bbff:fe18:6e9c? ([2001:df8:0:80:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id u19sm67258646ank.11.2011.11.14.17.57.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Nov 2011 17:57:51 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Tue, 15 Nov 2011 03:57:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <4EB0F497.1000104@deployingradius.com> To: Bernard Aboba , Alan DeKok X-Mailer: Apple Mail (2.1084) Cc: radext@ietf.org Subject: [radext] About RFC4282 and its fate; was Re: RFC 4282 and RADIUS implementations (was abfab and SAML) 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, 15 Nov 2011 01:57:53 -0000 I got a naive question (just as a concerned WG participant) regarding = the fate of RFC4282. NAIs are also used outside AAA protocols. One = particular domain that comes to my mind is mobility and mobile networks. = There are several systems that depend on RFC4282 (as a MUST) in non-AAA = signaling and then later may or may not relay that as-is to AAA = protocols. The good thing is that usually internationalization is not = really on the table yet in these systems but not that far either.=20 So, what would be the net effect if we start fiddling with RFC4282? Do = we then also need to revisit bunch of other RFCs and especially look = into non-IETF specifications..? - Jouni= From radext-bounces@ietf.org Mon Nov 14 17:57:55 2011 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 2F2EA11E82A9; Mon, 14 Nov 2011 17:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321322275; bh=HqxccoOuR1bwLocztfADKRtxI1aVZdvoX5cp7tLYFVM=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=aYmdEJjSZ4Y77F4DQlc+xVTjM8mGQwS07eenidlZFHbSwGmUlAKPUKrDWMoSZ28G/ N1iQTDNCTbce/qPxOdckO6eJ3znKQLC2PkCWB79f/5qaDJFbF5lqbbHwK4uk9cWL/M eF2uO2s32XKVRXjtoH7m++JkACySdW1xFmbWMqHs= 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 5215B11E82BB for ; Mon, 14 Nov 2011 17:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 b2Zh3K0f-xgB for ; Mon, 14 Nov 2011 17:57:52 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD57D11E816C for ; Mon, 14 Nov 2011 17:57:52 -0800 (PST) Received: by ggnr5 with SMTP id r5so1810713ggn.31 for ; Mon, 14 Nov 2011 17:57:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=2Y7nz8MP9mQWv1VZ5WCJvR0jSg8ejLC39yi8RB6tA3g=; b=VV20JSio/WALXMJtQK5EKlMP8TVbtyq89jEpesMeKuPJ63cEpbU2pRMOF2Dfwbp7Do fPhJV+UtjgqfYwwAbUD8dxnu5f+wAl/WCiBckpWGt5wzomBLK9wOJo+c9WnlJbkLZ1X2 av0NjYnNs5dycim9RvAXYmNttxOci2pNMM8x8= Received: by 10.101.75.9 with SMTP id c9mr6809050anl.149.1321322272344; Mon, 14 Nov 2011 17:57:52 -0800 (PST) Received: from ?IPv6:2001:df8::80:226:bbff:fe18:6e9c? ([2001:df8:0:80:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id u19sm67258646ank.11.2011.11.14.17.57.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Nov 2011 17:57:51 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) From: jouni korhonen In-Reply-To: Date: Tue, 15 Nov 2011 03:57:47 +0200 Message-Id: References: , <4EB0F497.1000104@deployingradius.com> To: Bernard Aboba , Alan DeKok X-Mailer: Apple Mail (2.1084) Cc: radext@ietf.org Subject: [radext] About RFC4282 and its fate; was Re: RFC 4282 and RADIUS implementations (was abfab and SAML) 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 I got a naive question (just as a concerned WG participant) regarding the fate of RFC4282. NAIs are also used outside AAA protocols. One particular domain that comes to my mind is mobility and mobile networks. There are several systems that depend on RFC4282 (as a MUST) in non-AAA signaling and then later may or may not relay that as-is to AAA protocols. The good thing is that usually internationalization is not really on the table yet in these systems but not that far either. So, what would be the net effect if we start fiddling with RFC4282? Do we then also need to revisit bunch of other RFCs and especially look into non-IETF specifications..? - Jouni _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Tue Nov 15 00:56:12 2011 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 47CE921F9024 for ; Tue, 15 Nov 2011 00:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 nk8V95J3viyN for ; Tue, 15 Nov 2011 00:56:11 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 696C121F9023 for ; Tue, 15 Nov 2011 00:56:11 -0800 (PST) Message-ID: <4EC2290F.10204@deployingradius.com> Date: Tue, 15 Nov 2011 09:55:43 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: jouni korhonen References: , <4EB0F497.1000104@deployingradius.com> 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 Subject: Re: [radext] About RFC4282 and its fate; was Re: RFC 4282 and RADIUS implementations (was abfab and SAML) 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, 15 Nov 2011 08:56:12 -0000 jouni korhonen wrote: > I got a naive question (just as a concerned WG participant) regarding the fate of RFC4282. NAIs are also used outside AAA protocols. One particular domain that comes to my mind is mobility and mobile networks. There are several systems that depend on RFC4282 (as a MUST) in non-AAA signaling and then later may or may not relay that as-is to AAA protocols. The good thing is that usually internationalization is not really on the table yet in these systems but not that far either. Do you have a reference to a non-AAA use of 4282? From what I've seen, the NAIs are used by those systems in the context of RADIUS and EAP. So they're really just RADIUS / EAP. > So, what would be the net effect if we start fiddling with RFC4282? Do we then also need to revisit bunch of other RFCs and especially look into non-IETF specifications..? I don't think so. The reason is that these specification depend on user@realm format. They do *not* depend on the ToAscii converted form of the i18n realm. Some documents depend on the "decorated" format of the NAI as discussed in Section 2.7 of 4282. I'm not aware that this practice is widespread. i.e. realm decorations *are* widespread. Standardized formats are *not* widespread. There are a large variety of formats used in practice. My take is that a 4282bis will have minimal impact on existing specifications and practices. This is because the specifications and practices do *not* depend on the practices of 4282 which have been removed in 4282bis. A quick pass through documents yields: 4283 - NAI is user@realm 4284 - NAI is user@realm, allows for "decoration" for source routing 5113 - allows for decorated NAI 5421 - name / password is processed as per 4282. 5433 - identifiers are NAIs 5446 - references 4282 5677 - identifier is FQDN *or* NAI 5687 - references 4282 6155 - says that the NAI allows non-UTF8 realms. Non-UTF-8 characters are escaped by \HEXHEX. They define a mapping from this format to the 4282 format. This appears to be a misunderstanding, as 4282 requires that the "realm" portion be UTF-8. From radext-bounces@ietf.org Tue Nov 15 00:56:14 2011 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 6B1CF21F9022; Tue, 15 Nov 2011 00:56:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321347374; bh=nbdIUlBg5c0jCxEmnohkgDUmcHm1RM3ZS/+6j5TnNJw=; 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=cxorrd9RWyUBMXAHeil4ypfxw6f1bGNZth5kb+PAIW9Qfm7IWQazflqhibL1PnUEV +dejFfuvzLgQxasP+ToRNrDtrsZkYIC8y16iXH3iAEBlfd59pE6X10jivAxCme5XQE 9y0VUqxcBTXwlWmuAvKLW4BfDtOMu8skGFsLFqiw= 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 47CE921F9024 for ; Tue, 15 Nov 2011 00:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 nk8V95J3viyN for ; Tue, 15 Nov 2011 00:56:11 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 696C121F9023 for ; Tue, 15 Nov 2011 00:56:11 -0800 (PST) Message-ID: <4EC2290F.10204@deployingradius.com> Date: Tue, 15 Nov 2011 09:55:43 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: jouni korhonen References: , <4EB0F497.1000104@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: Bernard Aboba , radext@ietf.org Subject: Re: [radext] About RFC4282 and its fate; was Re: RFC 4282 and RADIUS implementations (was abfab and SAML) 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 jouni korhonen wrote: > I got a naive question (just as a concerned WG participant) regarding the fate of RFC4282. NAIs are also used outside AAA protocols. One particular domain that comes to my mind is mobility and mobile networks. There are several systems that depend on RFC4282 (as a MUST) in non-AAA signaling and then later may or may not relay that as-is to AAA protocols. The good thing is that usually internationalization is not really on the table yet in these systems but not that far either. Do you have a reference to a non-AAA use of 4282? From what I've seen, the NAIs are used by those systems in the context of RADIUS and EAP. So they're really just RADIUS / EAP. > So, what would be the net effect if we start fiddling with RFC4282? Do we then also need to revisit bunch of other RFCs and especially look into non-IETF specifications..? I don't think so. The reason is that these specification depend on user@realm format. They do *not* depend on the ToAscii converted form of the i18n realm. Some documents depend on the "decorated" format of the NAI as discussed in Section 2.7 of 4282. I'm not aware that this practice is widespread. i.e. realm decorations *are* widespread. Standardized formats are *not* widespread. There are a large variety of formats used in practice. My take is that a 4282bis will have minimal impact on existing specifications and practices. This is because the specifications and practices do *not* depend on the practices of 4282 which have been removed in 4282bis. A quick pass through documents yields: 4283 - NAI is user@realm 4284 - NAI is user@realm, allows for "decoration" for source routing 5113 - allows for decorated NAI 5421 - name / password is processed as per 4282. 5433 - identifiers are NAIs 5446 - references 4282 5677 - identifier is FQDN *or* NAI 5687 - references 4282 6155 - says that the NAI allows non-UTF8 realms. Non-UTF-8 characters are escaped by \HEXHEX. They define a mapping from this format to the 4282 format. This appears to be a misunderstanding, as 4282 requires that the "realm" portion be UTF-8. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From mauricio.sanchez@hp.com Tue Nov 15 01:26:34 2011 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 1FBF411E8129 for ; Tue, 15 Nov 2011 01:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.716 X-Spam-Level: X-Spam-Status: No, score=-104.716 tagged_above=-999 required=5 tests=[AWL=-1.717, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4, 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 lmordbc7OUFV for ; Tue, 15 Nov 2011 01:26:32 -0800 (PST) Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) by ietfa.amsl.com (Postfix) with ESMTP id 55CBE11E8124 for ; Tue, 15 Nov 2011 01:26:32 -0800 (PST) Received: from G2W1953G.americas.hpqcorp.net (g2w1953g.austin.hp.com [16.238.8.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0028.austin.hp.com (Postfix) with ESMTPS id DF6D81C2B4 for ; Tue, 15 Nov 2011 09:26:31 +0000 (UTC) Received: from G5W0602.americas.hpqcorp.net (16.228.9.185) by G2W1953G.americas.hpqcorp.net (16.238.8.185) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 15 Nov 2011 09:25:55 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0602.americas.hpqcorp.net ([16.228.9.185]) with mapi; Tue, 15 Nov 2011 09:25:54 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Tue, 15 Nov 2011 09:25:50 +0000 Thread-Topic: RADEXT @ IETF82: Draft meeting notes Thread-Index: AcyjeIkEYr4tOsfYRvGxcUbszebpmQ== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE1978@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [radext] RADEXT @ IETF82: Draft meeting notes 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, 15 Nov 2011 09:26:34 -0000 Below are the draft notes for our meeting at IETF 82. Any corrections/modi= fications welcome. -MS=20 -------------------------------------------------------------- RADEXT WG Minutes IETF 82 Taipei, Taiwan Monday, November 14, 2011 Meeting started 9:02AM and ended 10:32AM. Approximately 17 individuals in = meeting Chairs: Jouni Korhonen Mauricio Sanchez AD: Dan Romascanu 1.Preliminaries=20 -Chair asked for jabber scribes (Stefan Winter) and note takers (Dorothy St= anley, Aruba Networks volunteers). -Chair reviews the agenda. No proposed changes to agenda as shown below -WG Goals/Milestones status -Chair reviewed status of documents that have been published, that are wait= ing for write-up, that are in last call, in=20 progress, under review as WG item, Interesting work outside of current char= ter. -Are there any volunteers to shepherd the TLS encryption for RADIUS? Will p= ut a call out on the list, if no volunteers,=20 one of chairs will volunteer. -Will another last call be required after the current one for RADIUS attrib= utes draft? To be determined. -RADIUS over DTLS - Allan will work on to advance. -NAI-based peer discovery - planned to align with RFC, RFC now published -IEEE 802 attributes - Bernard picking the draft up again, adopt as a WG it= em, make the draft active again. -NAI - Allan working on it, will discuss changes, and consider adopting as = a work item -2 drafts for RADIUS accounting=20 ********************************************************** 2. RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec -http://tools.ietf.org/html/draft-ietf-radext-ipv6-access=20 -See http://www.ietf.org/proceedings/82/slides/radext-1.ppt=20 -Leaf Yeh: How is the use case for DHCP addressed?=20 -Woj Dec: Attributes for name pool - DHCP. -Woj Dec:Next step is to submit next version with editorial comments, corre= ctions. -Leaf Yeh:Question on name of pool on the mailing list.=20 -Woj Dec: Interpret pool names as such. Solution is to have a different att= ribute for the pool - stateful-ipv6-address- pool-attribute. Format is the = same, but is different attributes; one for local, one for delegated. -Leaf Yeh: Suggests one pool name for all addresses - need to determine how= to use the names. Or create complex pool of all attributes. -Woj Dec:Current conclusion is not to do anything. -Woj Dec:If use existing attribute, - server has to interpret the pool name= as belonging to a specific type. -Bernard Aboba: Roaming deployments - may use a pool name, need to make sur= e you have same behavior across providers. Need to be explicit, so don't ha= ve chaos, can debug issues. -Chair: Consensus is that the current attribute and semantics are necessary= to not introduce ambiguity ************************************************************ 3. RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh=20 -http://tools.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01.txt -See http://www.ietf.org/proceedings/82/slides/radext-2.pptx=20 -Describe difference between version 6 and version 4.=20 -Summary of requirements, IDs, network scenario, attribute design (8 new at= tributes), enhanced design -Stefan Winter: Use TLV encoding as in extended attributes draft - everythi= ng on one attribute. -Leaf Yeh: Still not sure about container attribute (Stefan Winter draft ad= dresses) -Leaf Yeh: Does this deserve to be a WG item? Seem to have clear requiremen= ts from the industry. -Stefan Winter: Concern - have many drafts on this topic, they seem to die = out for lack of interest, then a variation appears.=20 -AD:Why not get together and resolve differences, and come back with a sing= le proposal. What is the benefit of coming up with yet another proposal? -Leaf Yeh:In last meeting (Quebec), didn't know how to define a new attribu= te using the extensions. Got feedback on the design.=20 -Stefan Winters: Are you saying that extended attribute is not the right wa= y?=20 -Leaf Yeh: Don't know. Can be done with traditional attribute design.Don't = disagree. Thought that we as a group came up with better ways of doing this= . Would like to follow-up with the "fancy accounting" method is not used. -Stefan Winter:Distinguish between requirements and design. -Multiple design approaches can solve the problem. -Alan DeKok:Extended attributes draft was created for a reason - use comple= x attributes with a lot of content; define container, avoid stuffing severa= l items into one attribute. Some of proposed designs still use complex enco= ding. -Stefan Winter:Do you accept design 4?=20 -Leaf Yeh:No includes too much complexity - better to use explicit format.= =20 -TLV nesting and grouping (Design 3) - what is the benefit of this design?= =20 -Benefit is that it uses the framework that the extended attribute defines.= Reusable code.=20 -Also need new sub-attributes defined here. -Need one set of new attributes and one type descriptor regardless. Use par= ser for extended attributes. -In design 4 - use one field to introduce field type. Complexity is the sam= e.=20 -Need to write a parser for this specifically. Better to use the framework. -There can be multiple instances of attributes. In that point, the two are = the same. In design 3, don't need another parser. -Alan notes that Design 3 slide is wrong - attributes can be in any order. = More flexible framework, just extract attributes, In proposal 4, have to ca= re about the order of the attributes. In Design 3, can leave out some sub-a= ttributes. -Chair: Do you support this work in RADEXT? -Is this needed for IPv4? Traffic type code can indicate the IPv4/IPv6 type= . -Should I migrate all IPv4 to this new format? BBF request uses original at= tributes for past traffic. -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. -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 ag= reement on a baseline proposal -Chair: Consensus check on adding this topic to the re-charter: Show of han= ds on who is interested and will participate in the effort? 4 - yes, 0 - ag= ainst. Will take to list, strong consensus to update the charter and make t= his a working group item. Ask authors to work towards a unified proposal. -AD:Will this be discussed at the Paris meeting?=20 -Chair:Yes, not choosing a proposal today; legitimize the work item in the = charter as a first step. ****************************************************************** 4.RADIUS Attributes for IEEE 802 Networks, Bernard Aboba=20 -http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt -http://www.ietf.org/proceedings/82/slides/radext-5.ppt=20 -Bernard: Purpose to add attributes required in 11r, and 802.1X key usage. -Call for adoption was issued Nov 13, 2007. Yesterday was the 4 year annive= rsary. -Does it need more time to ripen (like fine wines)? -Should have moved a little faster - others adopted parts. -What kind of attributes - from extended attributes? If move forward, ask t= his. -Need to look at use cases for attributes also. First step is to adopt. -EMU has finished WGLC on EAP lower layer. EMU would like input on collapsi= ng lower layers together. Differences between 802.1X-2004 and 802.1X-2010. -For the adoption of this document. If wait for it to be completely right, = might be a long while. Also 11u extensions too. -Unfortunate that document didn't advance - chair was side-tracked, but don= 't want chair's pushing their own agenda. -Chair: Is there interest to adopt this document to address milestone: 12-y= es, 0-no.=20 -Take to mailing list to confirm. Strong consensus to move forward. ******************************************************************** 5.RADIUS Protocol Extensions, Alan DeKok=20 -http://tools.ietf.org/html/draft-ietf-radext-radius-extensions -See http://www.ietf.org/proceedings/82/slides/radext-3.ppt=20 -Review of status, implementations (test vectors available - please use and= review) -Comment on IANA section - IANA is a mechanical operation. Can't use normat= ive language. Talk to Michelle and the IANA people, to see what they can re= ally do. Provide extremely clear guidance. -Believe updated text addresses that. -What is the base policy - IETF consensus or greater. Add a note that not c= hanging IETF policy. Updates RFC3575, or not?=20 -Need to state and be clear if policy is updated. -Alan to prepare next version - will come out late this week or early next = week. ********************************************************************* 6.Network Access Identifier, Alan DeKok=20 -http://tools.ietf.org/html/draft-dekok-radext-nai-01=20 -See http://www.ietf.org/proceedings/82/slides/radext-4.ppt -Review rationale for the proposal (why") DNS affects EAP and RADIUS - why? -Is there a Unicode 3.1 dependency here? On a reading of 4284, unassigned c= ode points are forbidden. -Cannot use a codepoint newer than 3.2. -DNS look-up required separate conversion. Do DNS protocol requirements to = turn string into something acceptable to DNS. -No one implements any of the requirements of RFC 4282! Rather, treat usern= ame field as an opaque blob. 4284 is blocking progress - abfab documents re= quire use of nai, but 4282 requirements cannot be used. -Sam Hartman: Dependency in abfab on 4282 - 1 is a bug, will be removed in = abfab; the second - need a "username" and "realm" item. Disagree that 4284 = is blocking abfab. But needs to be updated anyway. -Stefan Winter:Dynamic Discovery draft went through the same process. -Alan Dekok:Some operating systems don't send UTF-8 characters. More reason= to use nai-bis -2 distinct questions - 1 to get rid of what should never have been there i= n the future. 2 to deal with internationalization questions.in RADIUS. Coul= d get rid of 4282 as a first step, then address internationalization, EAP. -AD: Clarify - is the request that 4282 as historical/harmful, and 4282-bis= on RADEXT work plan? -Stop the confusion first - encoding out of scope. -Stefan Winter: Is anonymization still there? "Left part" blank. Is it stil= l in? Need to check - believe it is valuable. -Chair: hearing consensus to work on this. Poll: Killing 4282 a good thing= ? 10 - yes, 0-no. Strong consensus to put a document out, put on the mailin= g list to confirm. Discuss on the mailing list the scope of 4284 -no-longer= -applicable-versus internationalization. -Adopt Allan's document? Other approach? To discuss on mailing list. Sam t= o create text in abfab to claify purpose of 4282. ********************************************************************* 7.Next Steps: WG Chairs & ADs (15 minutes)=20 -Chair summarizes next steps re: updating the charter and what was agreed i= n the meeting. -Chair reviews current goals and milestones, updates: -Update IPv6 access to 2011 Dec -Radius over DTSL - update to 2012 March -RADIUS Cryptoagility - update to early 2012, or March 2012. -Extended attributes - update to March 2012 -IEEE 802.11 attributes - update to June 2012 -Dynamic Discovery - DIME version published, March 2012 -RADIUS accounting - Sept 2012 -4284 bis - March 2012 for near term deprecation of 4284, - will be 2 diffe= rent milestones, one for near term, one for longer term. From radext-bounces@ietf.org Tue Nov 15 01:26:35 2011 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 17F8B11E8143; Tue, 15 Nov 2011 01:26:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321349195; bh=Z3GzAP4FPQvxmdbfdXLR8n+qp4WwEiUz9NX1Gq1ST1o=; h=From:To:Date:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=kX/c9BeX02hE6FdeajELS4pZo3QUvPFOFU7E8I4dfcbbgOWSbqlDpigsbBbOqGCG1 JxfmIubUJVKu/XBGJp2J9mg/aq2/sX6fRp+DSnXx2jOGlz26HVDcEmFfUAfBZ+dDd7 5B49eGhplSqkzJXy2DMz80gTuj7eeIQ8Zw4ejH00= 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 1FBF411E8129 for ; Tue, 15 Nov 2011 01:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.716 X-Spam-Level: X-Spam-Status: No, score=-104.716 tagged_above=-999 required=5 tests=[AWL=-1.717, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4, 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 lmordbc7OUFV for ; Tue, 15 Nov 2011 01:26:32 -0800 (PST) Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) by ietfa.amsl.com (Postfix) with ESMTP id 55CBE11E8124 for ; Tue, 15 Nov 2011 01:26:32 -0800 (PST) Received: from G2W1953G.americas.hpqcorp.net (g2w1953g.austin.hp.com [16.238.8.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0028.austin.hp.com (Postfix) with ESMTPS id DF6D81C2B4 for ; Tue, 15 Nov 2011 09:26:31 +0000 (UTC) Received: from G5W0602.americas.hpqcorp.net (16.228.9.185) by G2W1953G.americas.hpqcorp.net (16.238.8.185) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 15 Nov 2011 09:25:55 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0602.americas.hpqcorp.net ([16.228.9.185]) with mapi; Tue, 15 Nov 2011 09:25:54 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Tue, 15 Nov 2011 09:25:50 +0000 Thread-Topic: RADEXT @ IETF82: Draft meeting notes Thread-Index: AcyjeIkEYr4tOsfYRvGxcUbszebpmQ== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE1978@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [radext] RADEXT @ IETF82: Draft meeting notes 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 Below are the draft notes for our meeting at IETF 82. Any corrections/modifications welcome. -MS -------------------------------------------------------------- RADEXT WG Minutes IETF 82 Taipei, Taiwan Monday, November 14, 2011 Meeting started 9:02AM and ended 10:32AM. Approximately 17 individuals in meeting Chairs: Jouni Korhonen Mauricio Sanchez AD: Dan Romascanu 1.Preliminaries -Chair asked for jabber scribes (Stefan Winter) and note takers (Dorothy Stanley, Aruba Networks volunteers). -Chair reviews the agenda. No proposed changes to agenda as shown below -WG Goals/Milestones status -Chair reviewed status of documents that have been published, that are waiting for write-up, that are in last call, in progress, under review as WG item, Interesting work outside of current charter. -Are there any volunteers to shepherd the TLS encryption for RADIUS? Will put a call out on the list, if no volunteers, one of chairs will volunteer. -Will another last call be required after the current one for RADIUS attributes draft? To be determined. -RADIUS over DTLS - Allan will work on to advance. -NAI-based peer discovery - planned to align with RFC, RFC now published -IEEE 802 attributes - Bernard picking the draft up again, adopt as a WG item, make the draft active again. -NAI - Allan working on it, will discuss changes, and consider adopting as a work item -2 drafts for RADIUS accounting ********************************************************** 2. RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec -http://tools.ietf.org/html/draft-ietf-radext-ipv6-access -See http://www.ietf.org/proceedings/82/slides/radext-1.ppt -Leaf Yeh: How is the use case for DHCP addressed? -Woj Dec: Attributes for name pool - DHCP. -Woj Dec:Next step is to submit next version with editorial comments, corrections. -Leaf Yeh:Question on name of pool on the mailing list. -Woj Dec: Interpret pool names as such. Solution is to have a different attribute for the pool - stateful-ipv6-address- pool-attribute. Format is the same, but is different attributes; one for local, one for delegated. -Leaf Yeh: Suggests one pool name for all addresses - need to determine how to use the names. Or create complex pool of all attributes. -Woj Dec:Current conclusion is not to do anything. -Woj Dec:If use existing attribute, - server has to interpret the pool name as belonging to a specific type. -Bernard Aboba: Roaming deployments - may use a pool name, need to make sure you have same behavior across providers. Need to be explicit, so don't have chaos, can debug issues. -Chair: Consensus is that the current attribute and semantics are necessary to not introduce ambiguity ************************************************************ 3. RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh -http://tools.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01.txt -See http://www.ietf.org/proceedings/82/slides/radext-2.pptx -Describe difference between version 6 and version 4. -Summary of requirements, IDs, network scenario, attribute design (8 new attributes), enhanced design -Stefan Winter: Use TLV encoding as in extended attributes draft - everything on one attribute. -Leaf Yeh: Still not sure about container attribute (Stefan Winter draft addresses) -Leaf Yeh: Does this deserve to be a WG item? Seem to have clear requirements from the industry. -Stefan Winter: Concern - have many drafts on this topic, they seem to die out for lack of interest, then a variation appears. -AD:Why not get together and resolve differences, and come back with a single proposal. What is the benefit of coming up with yet another proposal? -Leaf Yeh:In last meeting (Quebec), didn't know how to define a new attribute using the extensions. Got feedback on the design. -Stefan Winters: Are you saying that extended attribute is not the right way? -Leaf Yeh: Don't know. Can be done with traditional attribute design.Don't disagree. Thought that we as a group came up with better ways of doing this. Would like to follow-up with the "fancy accounting" method is not used. -Stefan Winter:Distinguish between requirements and design. -Multiple design approaches can solve the problem. -Alan DeKok:Extended attributes draft was created for a reason - use complex attributes with a lot of content; define container, avoid stuffing several items into one attribute. Some of proposed designs still use complex encoding. -Stefan Winter:Do you accept design 4? -Leaf Yeh:No includes too much complexity - better to use explicit format. -TLV nesting and grouping (Design 3) - what is the benefit of this design? -Benefit is that it uses the framework that the extended attribute defines. Reusable code. -Also need new sub-attributes defined here. -Need one set of new attributes and one type descriptor regardless. Use parser for extended attributes. -In design 4 - use one field to introduce field type. Complexity is the same. -Need to write a parser for this specifically. Better to use the framework. -There can be multiple instances of attributes. In that point, the two are the same. In design 3, don't need another parser. -Alan notes that Design 3 slide is wrong - attributes can be in any order. More flexible framework, just extract attributes, In proposal 4, have to care about the order of the attributes. In Design 3, can leave out some sub-attributes. -Chair: Do you support this work in RADEXT? -Is this needed for IPv4? Traffic type code can indicate the IPv4/IPv6 type. -Should I migrate all IPv4 to this new format? BBF request uses original attributes for past traffic. -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. -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: 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. -AD:Will this be discussed at the Paris meeting? -Chair:Yes, not choosing a proposal today; legitimize the work item in the charter as a first step. ****************************************************************** 4.RADIUS Attributes for IEEE 802 Networks, Bernard Aboba -http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt -http://www.ietf.org/proceedings/82/slides/radext-5.ppt -Bernard: Purpose to add attributes required in 11r, and 802.1X key usage. -Call for adoption was issued Nov 13, 2007. Yesterday was the 4 year anniversary. -Does it need more time to ripen (like fine wines)? -Should have moved a little faster - others adopted parts. -What kind of attributes - from extended attributes? If move forward, ask this. -Need to look at use cases for attributes also. First step is to adopt. -EMU has finished WGLC on EAP lower layer. EMU would like input on collapsing lower layers together. Differences between 802.1X-2004 and 802.1X-2010. -For the adoption of this document. If wait for it to be completely right, might be a long while. Also 11u extensions too. -Unfortunate that document didn't advance - chair was side-tracked, but don't want chair's pushing their own agenda. -Chair: Is there interest to adopt this document to address milestone: 12-yes, 0-no. -Take to mailing list to confirm. Strong consensus to move forward. ******************************************************************** 5.RADIUS Protocol Extensions, Alan DeKok -http://tools.ietf.org/html/draft-ietf-radext-radius-extensions -See http://www.ietf.org/proceedings/82/slides/radext-3.ppt -Review of status, implementations (test vectors available - please use and review) -Comment on IANA section - IANA is a mechanical operation. Can't use normative language. Talk to Michelle and the IANA people, to see what they can really do. Provide extremely clear guidance. -Believe updated text addresses that. -What is the base policy - IETF consensus or greater. Add a note that not changing IETF policy. Updates RFC3575, or not? -Need to state and be clear if policy is updated. -Alan to prepare next version - will come out late this week or early next week. ********************************************************************* 6.Network Access Identifier, Alan DeKok -http://tools.ietf.org/html/draft-dekok-radext-nai-01 -See http://www.ietf.org/proceedings/82/slides/radext-4.ppt -Review rationale for the proposal (why") DNS affects EAP and RADIUS - why? -Is there a Unicode 3.1 dependency here? On a reading of 4284, unassigned code points are forbidden. -Cannot use a codepoint newer than 3.2. -DNS look-up required separate conversion. Do DNS protocol requirements to turn string into something acceptable to DNS. -No one implements any of the requirements of RFC 4282! Rather, treat username field as an opaque blob. 4284 is blocking progress - abfab documents require use of nai, but 4282 requirements cannot be used. -Sam Hartman: Dependency in abfab on 4282 - 1 is a bug, will be removed in abfab; the second - need a "username" and "realm" item. Disagree that 4284 is blocking abfab. But needs to be updated anyway. -Stefan Winter:Dynamic Discovery draft went through the same process. -Alan Dekok:Some operating systems don't send UTF-8 characters. More reason to use nai-bis -2 distinct questions - 1 to get rid of what should never have been there in the future. 2 to deal with internationalization questions.in RADIUS. Could get rid of 4282 as a first step, then address internationalization, EAP. -AD: Clarify - is the request that 4282 as historical/harmful, and 4282-bis on RADEXT work plan? -Stop the confusion first - encoding out of scope. -Stefan Winter: Is anonymization still there? "Left part" blank. Is it still in? Need to check - believe it is valuable. -Chair: hearing consensus to work on this. Poll: Killing 4282 a good thing? 10 - yes, 0-no. Strong consensus to put a document out, put on the mailing list to confirm. Discuss on the mailing list the scope of 4284 -no-longer-applicable-versus internationalization. -Adopt Allan's document? Other approach? To discuss on mailing list. Sam to create text in abfab to claify purpose of 4282. ********************************************************************* 7.Next Steps: WG Chairs & ADs (15 minutes) -Chair summarizes next steps re: updating the charter and what was agreed in the meeting. -Chair reviews current goals and milestones, updates: -Update IPv6 access to 2011 Dec -Radius over DTSL - update to 2012 March -RADIUS Cryptoagility - update to early 2012, or March 2012. -Extended attributes - update to March 2012 -IEEE 802.11 attributes - update to June 2012 -Dynamic Discovery - DIME version published, March 2012 -RADIUS accounting - Sept 2012 -4284 bis - March 2012 for near term deprecation of 4284, - will be 2 different milestones, one for near term, one for longer term. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From mauricio.sanchez@hp.com Tue Nov 15 01:35:09 2011 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 92C3B11E81A6 for ; Tue, 15 Nov 2011 01:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.344 X-Spam-Level: X-Spam-Status: No, score=-106.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 u6uSL9whfRwC for ; Tue, 15 Nov 2011 01:35:09 -0800 (PST) Received: from g5t0008.atlanta.hp.com (g5t0008.atlanta.hp.com [15.192.0.45]) by ietfa.amsl.com (Postfix) with ESMTP id 07C6711E81A5 for ; Tue, 15 Nov 2011 01:35:09 -0800 (PST) Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0008.atlanta.hp.com (Postfix) with ESMTPS id 8FD5124350 for ; Tue, 15 Nov 2011 09:35:08 +0000 (UTC) Received: from G6W0173.americas.hpqcorp.net (16.230.33.182) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 15 Nov 2011 09:34:40 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G6W0173.americas.hpqcorp.net ([16.230.33.182]) with mapi; Tue, 15 Nov 2011 09:34:39 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Tue, 15 Nov 2011 09:34:37 +0000 Thread-Topic: Call for document shepherd for draft-ietf-radext-radsec Thread-Index: Acyjeb5z6vrxOjW3RiuGHnhLN6xibQ== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE1979@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [radext] Call for document shepherd for draft-ietf-radext-radsec 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, 15 Nov 2011 09:35:09 -0000 TLS encryption for RADIUS (https://datatracker.ietf.org/doc/draft-ietf-rade= xt-radsec/) has completed WGLC and we are now searching for a document shep= herd to continue driving progress forward. Anyone interested in taking on t= his important duty is requested to reach out to the chairs over the next we= ek (on or before 22nd). Otherwise, the chairs will be forced to use a game= of chance or skill to determine which chair takes on the duty. =20 -MS=20 From radext-bounces@ietf.org Tue Nov 15 01:35:11 2011 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 DEE6911E8113; Tue, 15 Nov 2011 01:35:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321349710; bh=p4NgzJOtRrTMhjePYO6c9tcmH2TD2ah2OjM4izYwaTA=; h=From:To:Date:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=WOkI52IAa4BB6u20XjDNtSC6TM8jGRjnnIuqM4PkNadOt3PMV0iG4rMbbOPAdWSUY 5uoaiXfUv574WJaL9JPPpBd3Z5SMMCH0nW98RHjaX1ZkKcW7MlxjklhRxSVs8KkXuA YEyVk3HP2jLwKQ65AE75yuAniu6KtH0McnbTQEHk= 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 92C3B11E81A6 for ; Tue, 15 Nov 2011 01:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.344 X-Spam-Level: X-Spam-Status: No, score=-106.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 u6uSL9whfRwC for ; Tue, 15 Nov 2011 01:35:09 -0800 (PST) Received: from g5t0008.atlanta.hp.com (g5t0008.atlanta.hp.com [15.192.0.45]) by ietfa.amsl.com (Postfix) with ESMTP id 07C6711E81A5 for ; Tue, 15 Nov 2011 01:35:09 -0800 (PST) Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0008.atlanta.hp.com (Postfix) with ESMTPS id 8FD5124350 for ; Tue, 15 Nov 2011 09:35:08 +0000 (UTC) Received: from G6W0173.americas.hpqcorp.net (16.230.33.182) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 15 Nov 2011 09:34:40 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G6W0173.americas.hpqcorp.net ([16.230.33.182]) with mapi; Tue, 15 Nov 2011 09:34:39 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Tue, 15 Nov 2011 09:34:37 +0000 Thread-Topic: Call for document shepherd for draft-ietf-radext-radsec Thread-Index: Acyjeb5z6vrxOjW3RiuGHnhLN6xibQ== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE1979@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [radext] Call for document shepherd for draft-ietf-radext-radsec 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 TLS encryption for RADIUS (https://datatracker.ietf.org/doc/draft-ietf-radext-radsec/) has completed WGLC and we are now searching for a document shepherd to continue driving progress forward. Anyone interested in taking on this important duty is requested to reach out to the chairs over the next week (on or before 22nd). Otherwise, the chairs will be forced to use a game of chance or skill to determine which chair takes on the duty. -MS _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Tue Nov 15 01:41:27 2011 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 2C46E11E81DC; Tue, 15 Nov 2011 01:41:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321350087; bh=xkBKd1xM21qud3WHTfzr3eXEYkFa72ZFc+6wJyiMesk=; 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=lPOoaLC3/PsY/w+/Xla/YTTfdBuY39LI035JAXjPSj0n/kHsuc/5yDGMfEhNUDfgJ cLAEKHego1x9AY70KaIkV0Ln5Jzilr4ZJ8pttg2BoIgYgPjnILa1s3eN1Z877wrHiq F1U+WvhjUBOoIWGUVOUwAPsVYZFHBEhrREAcQyzs= 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 D4D9511E81D4 for ; Tue, 15 Nov 2011 01:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_62=0.6, 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 P461b78HJGky for ; Tue, 15 Nov 2011 01:41:24 -0800 (PST) Received: from out28-ams.mf.surf.net (out28-ams.mf.surf.net [145.0.1.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7260111E81B0 for ; Tue, 15 Nov 2011 01:41:24 -0800 (PST) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id pAF9fMp5021450 for ; Tue, 15 Nov 2011 10:41:22 +0100 Received: from 128-107-239-233.cisco.com ([128.107.239.233] helo=klaas-wierengas-macbook-air-2.local) by teletubbie.het.net.je with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RQFUp-000962-Kp for radext@ietf.org; Tue, 15 Nov 2011 10:40:04 +0100 Message-ID: <4EC233BE.6090302@wierenga.net> Date: Tue, 15 Nov 2011 10:41:18 +0100 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: radext@ietf.org References: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE1978@GVW0671EXC.americas.hpqcorp.net> In-Reply-To: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE1978@GVW0671EXC.americas.hpqcorp.net> X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0uFVlFm1D - 0a8074ec8c9a - 20111115 X-Scanned-By: CanIt (www . roaringpenguin . com) on 145.0.1.28 Subject: Re: [radext] RADEXT @ IETF82: Draft meeting notes 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: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On 11/15/11 10:25 AM, Sanchez, Mauricio (HP Networking) wrote: > Below are the draft notes for our meeting at IETF 82. Any corrections/modifications welcome. no biggie, but see below > > -MS > > > -------------------------------------------------------------- > > RADEXT WG Minutes > IETF 82 > Taipei, Taiwan > Monday, November 14, 2011 > Meeting started 9:02AM and ended 10:32AM. Approximately 17 individuals in meeting > > Chairs: > Jouni Korhonen > Mauricio Sanchez > > AD: > Dan Romascanu > > > 1.Preliminaries > -Chair asked for jabber scribes (Stefan Winter) and note takers (Dorothy Stanley, Aruba Networks volunteers). > -Chair reviews the agenda. No proposed changes to agenda as shown below > -WG Goals/Milestones status > -Chair reviewed status of documents that have been published, that are waiting for write-up, that are in last call, in > > progress, under review as WG item, Interesting work outside of current charter. > -Are there any volunteers to shepherd the TLS encryption for RADIUS? Will put a call out on the list, if no volunteers, > > one of chairs will volunteer. > -Will another last call be required after the current one for RADIUS attributes draft? To be determined. > -RADIUS over DTLS - Allan will work on to advance. > -NAI-based peer discovery - planned to align with RFC, RFC now published > -IEEE 802 attributes - Bernard picking the draft up again, adopt as a WG item, make the draft active again. > -NAI - Allan working on it, will discuss changes, and consider adopting as a work item > -2 drafts for RADIUS accounting > > > ********************************************************** > > 2. RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec > -http://tools.ietf.org/html/draft-ietf-radext-ipv6-access > -See http://www.ietf.org/proceedings/82/slides/radext-1.ppt > -Leaf Yeh: How is the use case for DHCP addressed? > -Woj Dec: Attributes for name pool - DHCP. > -Woj Dec:Next step is to submit next version with editorial comments, corrections. > -Leaf Yeh:Question on name of pool on the mailing list. > -Woj Dec: Interpret pool names as such. Solution is to have a different attribute for the pool - stateful-ipv6-address- pool-attribute. Format is the same, but is different attributes; one for local, one for delegated. > -Leaf Yeh: Suggests one pool name for all addresses - need to determine how to use the names. Or create complex pool of all attributes. > -Woj Dec:Current conclusion is not to do anything. > -Woj Dec:If use existing attribute, - server has to interpret the pool name as belonging to a specific type. > -Bernard Aboba: Roaming deployments - may use a pool name, need to make sure you have same behavior across providers. Need to be explicit, so don't have chaos, can debug issues. > -Chair: Consensus is that the current attribute and semantics are necessary to not introduce ambiguity > > ************************************************************ > 3. RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh > -http://tools.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01.txt > -See http://www.ietf.org/proceedings/82/slides/radext-2.pptx > -Describe difference between version 6 and version 4. > -Summary of requirements, IDs, network scenario, attribute design (8 new attributes), enhanced design > -Stefan Winter: Use TLV encoding as in extended attributes draft - everything on one attribute. > -Leaf Yeh: Still not sure about container attribute (Stefan Winter draft addresses) > -Leaf Yeh: Does this deserve to be a WG item? Seem to have clear requirements from the industry. > -Stefan Winter: Concern - have many drafts on this topic, they seem to die out for lack of interest, then a variation appears. ^^^^^^^^ I think that was me > -AD:Why not get together and resolve differences, and come back with a single proposal. What is the benefit of coming up with yet another proposal? > -Leaf Yeh:In last meeting (Quebec), didn't know how to define a new attribute using the extensions. Got feedback on the design. > -Stefan Winters: Are you saying that extended attribute is not the right way? ^^^^^^^^ ditto > -Leaf Yeh: Don't know. Can be done with traditional attribute design.Don't disagree. Thought that we as a group came up with better ways of doing this. Would like to follow-up with the "fancy accounting" method is not used. > -Stefan Winter:Distinguish between requirements and design. > -Multiple design approaches can solve the problem. > -Alan DeKok:Extended attributes draft was created for a reason - use complex attributes with a lot of content; define container, avoid stuffing several items into one attribute. Some of proposed designs still use complex encoding. > -Stefan Winter:Do you accept design 4? > -Leaf Yeh:No includes too much complexity - better to use explicit format. > -TLV nesting and grouping (Design 3) - what is the benefit of this design? > -Benefit is that it uses the framework that the extended attribute defines. Reusable code. > -Also need new sub-attributes defined here. > -Need one set of new attributes and one type descriptor regardless. Use parser for extended attributes. > -In design 4 - use one field to introduce field type. Complexity is the same. > -Need to write a parser for this specifically. Better to use the framework. > -There can be multiple instances of attributes. In that point, the two are the same. In design 3, don't need another parser. > -Alan notes that Design 3 slide is wrong - attributes can be in any order. More flexible framework, just extract attributes, In proposal 4, have to care about the order of the attributes. In Design 3, can leave out some sub-attributes. > -Chair: Do you support this work in RADEXT? > -Is this needed for IPv4? Traffic type code can indicate the IPv4/IPv6 type. > -Should I migrate all IPv4 to this new format? BBF request uses original attributes for past traffic. > -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. > -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: 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. > -AD:Will this be discussed at the Paris meeting? > -Chair:Yes, not choosing a proposal today; legitimize the work item in the charter as a first step. > > ****************************************************************** > 4.RADIUS Attributes for IEEE 802 Networks, Bernard Aboba > -http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt > -http://www.ietf.org/proceedings/82/slides/radext-5.ppt > -Bernard: Purpose to add attributes required in 11r, and 802.1X key usage. > -Call for adoption was issued Nov 13, 2007. Yesterday was the 4 year anniversary. > -Does it need more time to ripen (like fine wines)? > -Should have moved a little faster - others adopted parts. > -What kind of attributes - from extended attributes? If move forward, ask this. > -Need to look at use cases for attributes also. First step is to adopt. > -EMU has finished WGLC on EAP lower layer. EMU would like input on collapsing lower layers together. Differences between 802.1X-2004 and 802.1X-2010. > -For the adoption of this document. If wait for it to be completely right, might be a long while. Also 11u extensions too. > -Unfortunate that document didn't advance - chair was side-tracked, but don't want chair's pushing their own agenda. > -Chair: Is there interest to adopt this document to address milestone: 12-yes, 0-no. > -Take to mailing list to confirm. Strong consensus to move forward. > > ******************************************************************** > 5.RADIUS Protocol Extensions, Alan DeKok > -http://tools.ietf.org/html/draft-ietf-radext-radius-extensions > -See http://www.ietf.org/proceedings/82/slides/radext-3.ppt > -Review of status, implementations (test vectors available - please use and review) > -Comment on IANA section - IANA is a mechanical operation. Can't use normative language. Talk to Michelle and the IANA people, to see what they can really do. Provide extremely clear guidance. > -Believe updated text addresses that. > -What is the base policy - IETF consensus or greater. Add a note that not changing IETF policy. Updates RFC3575, or not? > -Need to state and be clear if policy is updated. > -Alan to prepare next version - will come out late this week or early next week. > > ********************************************************************* > 6.Network Access Identifier, Alan DeKok > -http://tools.ietf.org/html/draft-dekok-radext-nai-01 > -See http://www.ietf.org/proceedings/82/slides/radext-4.ppt > -Review rationale for the proposal (why") DNS affects EAP and RADIUS - why? > -Is there a Unicode 3.1 dependency here? On a reading of 4284, unassigned code points are forbidden. > -Cannot use a codepoint newer than 3.2. > -DNS look-up required separate conversion. Do DNS protocol requirements to turn string into something acceptable to DNS. > -No one implements any of the requirements of RFC 4282! Rather, treat username field as an opaque blob. 4284 is blocking progress - abfab documents require use of nai, but 4282 requirements cannot be used. > -Sam Hartman: Dependency in abfab on 4282 - 1 is a bug, will be removed in abfab; the second - need a "username" and "realm" item. Disagree that 4284 is blocking abfab. But needs to be updated anyway. > -Stefan Winter:Dynamic Discovery draft went through the same process. > -Alan Dekok:Some operating systems don't send UTF-8 characters. More reason to use nai-bis > -2 distinct questions - 1 to get rid of what should never have been there in the future. 2 to deal with internationalization questions.in RADIUS. Could get rid of 4282 as a first step, then address internationalization, EAP. > -AD: Clarify - is the request that 4282 as historical/harmful, and 4282-bis on RADEXT work plan? > -Stop the confusion first - encoding out of scope. > -Stefan Winter: Is anonymization still there? "Left part" blank. Is it still in? Need to check - believe it is valuable. > -Chair: hearing consensus to work on this. Poll: Killing 4282 a good thing? 10 - yes, 0-no. Strong consensus to put a document out, put on the mailing list to confirm. Discuss on the mailing list the scope of 4284 -no-longer-applicable-versus internationalization. > -Adopt Allan's document? Other approach? To discuss on mailing list. Sam to create text in abfab to claify purpose of 4282. > > ********************************************************************* > 7.Next Steps: WG Chairs& ADs (15 minutes) > -Chair summarizes next steps re: updating the charter and what was agreed in the meeting. > -Chair reviews current goals and milestones, updates: > -Update IPv6 access to 2011 Dec > -Radius over DTSL - update to 2012 March > -RADIUS Cryptoagility - update to early 2012, or March 2012. > -Extended attributes - update to March 2012 > -IEEE 802.11 attributes - update to June 2012 > -Dynamic Discovery - DIME version published, March 2012 > -RADIUS accounting - Sept 2012 > -4284 bis - March 2012 for near term deprecation of 4284, - will be 2 different milestones, one for near term, one for longer term. > _______________________________________________ > 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 klaas@wierenga.net Tue Nov 15 01:41:25 2011 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 D4D9511E81D4 for ; Tue, 15 Nov 2011 01:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_62=0.6, 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 P461b78HJGky for ; Tue, 15 Nov 2011 01:41:24 -0800 (PST) Received: from out28-ams.mf.surf.net (out28-ams.mf.surf.net [145.0.1.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7260111E81B0 for ; Tue, 15 Nov 2011 01:41:24 -0800 (PST) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id pAF9fMp5021450 for ; Tue, 15 Nov 2011 10:41:22 +0100 Received: from 128-107-239-233.cisco.com ([128.107.239.233] helo=klaas-wierengas-macbook-air-2.local) by teletubbie.het.net.je with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RQFUp-000962-Kp for radext@ietf.org; Tue, 15 Nov 2011 10:40:04 +0100 Message-ID: <4EC233BE.6090302@wierenga.net> Date: Tue, 15 Nov 2011 10:41:18 +0100 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: radext@ietf.org References: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE1978@GVW0671EXC.americas.hpqcorp.net> In-Reply-To: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE1978@GVW0671EXC.americas.hpqcorp.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0uFVlFm1D - 0a8074ec8c9a - 20111115 X-Scanned-By: CanIt (www . roaringpenguin . com) on 145.0.1.28 Subject: Re: [radext] RADEXT @ IETF82: Draft meeting notes 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, 15 Nov 2011 09:41:26 -0000 On 11/15/11 10:25 AM, Sanchez, Mauricio (HP Networking) wrote: > Below are the draft notes for our meeting at IETF 82. Any corrections/modifications welcome. no biggie, but see below > > -MS > > > -------------------------------------------------------------- > > RADEXT WG Minutes > IETF 82 > Taipei, Taiwan > Monday, November 14, 2011 > Meeting started 9:02AM and ended 10:32AM. Approximately 17 individuals in meeting > > Chairs: > Jouni Korhonen > Mauricio Sanchez > > AD: > Dan Romascanu > > > 1.Preliminaries > -Chair asked for jabber scribes (Stefan Winter) and note takers (Dorothy Stanley, Aruba Networks volunteers). > -Chair reviews the agenda. No proposed changes to agenda as shown below > -WG Goals/Milestones status > -Chair reviewed status of documents that have been published, that are waiting for write-up, that are in last call, in > > progress, under review as WG item, Interesting work outside of current charter. > -Are there any volunteers to shepherd the TLS encryption for RADIUS? Will put a call out on the list, if no volunteers, > > one of chairs will volunteer. > -Will another last call be required after the current one for RADIUS attributes draft? To be determined. > -RADIUS over DTLS - Allan will work on to advance. > -NAI-based peer discovery - planned to align with RFC, RFC now published > -IEEE 802 attributes - Bernard picking the draft up again, adopt as a WG item, make the draft active again. > -NAI - Allan working on it, will discuss changes, and consider adopting as a work item > -2 drafts for RADIUS accounting > > > ********************************************************** > > 2. RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec > -http://tools.ietf.org/html/draft-ietf-radext-ipv6-access > -See http://www.ietf.org/proceedings/82/slides/radext-1.ppt > -Leaf Yeh: How is the use case for DHCP addressed? > -Woj Dec: Attributes for name pool - DHCP. > -Woj Dec:Next step is to submit next version with editorial comments, corrections. > -Leaf Yeh:Question on name of pool on the mailing list. > -Woj Dec: Interpret pool names as such. Solution is to have a different attribute for the pool - stateful-ipv6-address- pool-attribute. Format is the same, but is different attributes; one for local, one for delegated. > -Leaf Yeh: Suggests one pool name for all addresses - need to determine how to use the names. Or create complex pool of all attributes. > -Woj Dec:Current conclusion is not to do anything. > -Woj Dec:If use existing attribute, - server has to interpret the pool name as belonging to a specific type. > -Bernard Aboba: Roaming deployments - may use a pool name, need to make sure you have same behavior across providers. Need to be explicit, so don't have chaos, can debug issues. > -Chair: Consensus is that the current attribute and semantics are necessary to not introduce ambiguity > > ************************************************************ > 3. RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh > -http://tools.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01.txt > -See http://www.ietf.org/proceedings/82/slides/radext-2.pptx > -Describe difference between version 6 and version 4. > -Summary of requirements, IDs, network scenario, attribute design (8 new attributes), enhanced design > -Stefan Winter: Use TLV encoding as in extended attributes draft - everything on one attribute. > -Leaf Yeh: Still not sure about container attribute (Stefan Winter draft addresses) > -Leaf Yeh: Does this deserve to be a WG item? Seem to have clear requirements from the industry. > -Stefan Winter: Concern - have many drafts on this topic, they seem to die out for lack of interest, then a variation appears. ^^^^^^^^ I think that was me > -AD:Why not get together and resolve differences, and come back with a single proposal. What is the benefit of coming up with yet another proposal? > -Leaf Yeh:In last meeting (Quebec), didn't know how to define a new attribute using the extensions. Got feedback on the design. > -Stefan Winters: Are you saying that extended attribute is not the right way? ^^^^^^^^ ditto > -Leaf Yeh: Don't know. Can be done with traditional attribute design.Don't disagree. Thought that we as a group came up with better ways of doing this. Would like to follow-up with the "fancy accounting" method is not used. > -Stefan Winter:Distinguish between requirements and design. > -Multiple design approaches can solve the problem. > -Alan DeKok:Extended attributes draft was created for a reason - use complex attributes with a lot of content; define container, avoid stuffing several items into one attribute. Some of proposed designs still use complex encoding. > -Stefan Winter:Do you accept design 4? > -Leaf Yeh:No includes too much complexity - better to use explicit format. > -TLV nesting and grouping (Design 3) - what is the benefit of this design? > -Benefit is that it uses the framework that the extended attribute defines. Reusable code. > -Also need new sub-attributes defined here. > -Need one set of new attributes and one type descriptor regardless. Use parser for extended attributes. > -In design 4 - use one field to introduce field type. Complexity is the same. > -Need to write a parser for this specifically. Better to use the framework. > -There can be multiple instances of attributes. In that point, the two are the same. In design 3, don't need another parser. > -Alan notes that Design 3 slide is wrong - attributes can be in any order. More flexible framework, just extract attributes, In proposal 4, have to care about the order of the attributes. In Design 3, can leave out some sub-attributes. > -Chair: Do you support this work in RADEXT? > -Is this needed for IPv4? Traffic type code can indicate the IPv4/IPv6 type. > -Should I migrate all IPv4 to this new format? BBF request uses original attributes for past traffic. > -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. > -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: 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. > -AD:Will this be discussed at the Paris meeting? > -Chair:Yes, not choosing a proposal today; legitimize the work item in the charter as a first step. > > ****************************************************************** > 4.RADIUS Attributes for IEEE 802 Networks, Bernard Aboba > -http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt > -http://www.ietf.org/proceedings/82/slides/radext-5.ppt > -Bernard: Purpose to add attributes required in 11r, and 802.1X key usage. > -Call for adoption was issued Nov 13, 2007. Yesterday was the 4 year anniversary. > -Does it need more time to ripen (like fine wines)? > -Should have moved a little faster - others adopted parts. > -What kind of attributes - from extended attributes? If move forward, ask this. > -Need to look at use cases for attributes also. First step is to adopt. > -EMU has finished WGLC on EAP lower layer. EMU would like input on collapsing lower layers together. Differences between 802.1X-2004 and 802.1X-2010. > -For the adoption of this document. If wait for it to be completely right, might be a long while. Also 11u extensions too. > -Unfortunate that document didn't advance - chair was side-tracked, but don't want chair's pushing their own agenda. > -Chair: Is there interest to adopt this document to address milestone: 12-yes, 0-no. > -Take to mailing list to confirm. Strong consensus to move forward. > > ******************************************************************** > 5.RADIUS Protocol Extensions, Alan DeKok > -http://tools.ietf.org/html/draft-ietf-radext-radius-extensions > -See http://www.ietf.org/proceedings/82/slides/radext-3.ppt > -Review of status, implementations (test vectors available - please use and review) > -Comment on IANA section - IANA is a mechanical operation. Can't use normative language. Talk to Michelle and the IANA people, to see what they can really do. Provide extremely clear guidance. > -Believe updated text addresses that. > -What is the base policy - IETF consensus or greater. Add a note that not changing IETF policy. Updates RFC3575, or not? > -Need to state and be clear if policy is updated. > -Alan to prepare next version - will come out late this week or early next week. > > ********************************************************************* > 6.Network Access Identifier, Alan DeKok > -http://tools.ietf.org/html/draft-dekok-radext-nai-01 > -See http://www.ietf.org/proceedings/82/slides/radext-4.ppt > -Review rationale for the proposal (why") DNS affects EAP and RADIUS - why? > -Is there a Unicode 3.1 dependency here? On a reading of 4284, unassigned code points are forbidden. > -Cannot use a codepoint newer than 3.2. > -DNS look-up required separate conversion. Do DNS protocol requirements to turn string into something acceptable to DNS. > -No one implements any of the requirements of RFC 4282! Rather, treat username field as an opaque blob. 4284 is blocking progress - abfab documents require use of nai, but 4282 requirements cannot be used. > -Sam Hartman: Dependency in abfab on 4282 - 1 is a bug, will be removed in abfab; the second - need a "username" and "realm" item. Disagree that 4284 is blocking abfab. But needs to be updated anyway. > -Stefan Winter:Dynamic Discovery draft went through the same process. > -Alan Dekok:Some operating systems don't send UTF-8 characters. More reason to use nai-bis > -2 distinct questions - 1 to get rid of what should never have been there in the future. 2 to deal with internationalization questions.in RADIUS. Could get rid of 4282 as a first step, then address internationalization, EAP. > -AD: Clarify - is the request that 4282 as historical/harmful, and 4282-bis on RADEXT work plan? > -Stop the confusion first - encoding out of scope. > -Stefan Winter: Is anonymization still there? "Left part" blank. Is it still in? Need to check - believe it is valuable. > -Chair: hearing consensus to work on this. Poll: Killing 4282 a good thing? 10 - yes, 0-no. Strong consensus to put a document out, put on the mailing list to confirm. Discuss on the mailing list the scope of 4284 -no-longer-applicable-versus internationalization. > -Adopt Allan's document? Other approach? To discuss on mailing list. Sam to create text in abfab to claify purpose of 4282. > > ********************************************************************* > 7.Next Steps: WG Chairs& ADs (15 minutes) > -Chair summarizes next steps re: updating the charter and what was agreed in the meeting. > -Chair reviews current goals and milestones, updates: > -Update IPv6 access to 2011 Dec > -Radius over DTSL - update to 2012 March > -RADIUS Cryptoagility - update to early 2012, or March 2012. > -Extended attributes - update to March 2012 > -IEEE 802.11 attributes - update to June 2012 > -Dynamic Discovery - DIME version published, March 2012 > -RADIUS accounting - Sept 2012 > -4284 bis - March 2012 for near term deprecation of 4284, - will be 2 different milestones, one for near term, one for longer term. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From mauricio.sanchez@hp.com Tue Nov 15 02:22:07 2011 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 433FC11E822D for ; Tue, 15 Nov 2011 02:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.567 X-Spam-Level: X-Spam-Status: No, score=-104.567 tagged_above=-999 required=5 tests=[AWL=-1.568, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4, 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 xHvpg3hKfTAp for ; Tue, 15 Nov 2011 02:22:06 -0800 (PST) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by ietfa.amsl.com (Postfix) with ESMTP id EC18611E8221 for ; Tue, 15 Nov 2011 02:22:05 -0800 (PST) Received: from G5W2206G.americas.hpqcorp.net (g5w2206g.atlanta.hp.com [16.228.43.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id 4FDF638568; Tue, 15 Nov 2011 10:22:05 +0000 (UTC) Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G5W2206G.americas.hpqcorp.net (16.228.43.185) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 15 Nov 2011 10:21:23 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Tue, 15 Nov 2011 10:21:22 +0000 From: "Sanchez, Mauricio (HP Networking)" To: Klaas Wierenga , "radext@ietf.org" Date: Tue, 15 Nov 2011 10:21:19 +0000 Thread-Topic: [radext] RADEXT @ IETF82: Draft meeting notes Thread-Index: AcyjfQNjZ+ADeK6jRKSSRKSKjKdxWwAAx1pA Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE197E@GVW0671EXC.americas.hpqcorp.net> References: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE1978@GVW0671EXC.americas.hpqcorp.net> <4EC233BE.6090302@wierenga.net> In-Reply-To: <4EC233BE.6090302@wierenga.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [radext] RADEXT @ IETF82: Draft meeting notes 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, 15 Nov 2011 10:22:07 -0000 It was a small test to see whether people actually read the notes. You pa= ssed.=20 I've updated my master copy.=20 Thanks, MS=20 -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of= Klaas Wierenga Sent: Tuesday, November 15, 2011 5:41 PM To: radext@ietf.org Subject: Re: [radext] RADEXT @ IETF82: Draft meeting notes On 11/15/11 10:25 AM, Sanchez, Mauricio (HP Networking) wrote: > Below are the draft notes for our meeting at IETF 82. Any corrections/mo= difications welcome. no biggie, but see below > > -MS > > > -------------------------------------------------------------- > > RADEXT WG Minutes > IETF 82 > Taipei, Taiwan > Monday, November 14, 2011 > Meeting started 9:02AM and ended 10:32AM. Approximately 17=20 > individuals in meeting > > Chairs: > Jouni Korhonen Mauricio=20 > Sanchez > > AD: > Dan Romascanu > > > 1.Preliminaries > -Chair asked for jabber scribes (Stefan Winter) and note takers (Dorothy = Stanley, Aruba Networks volunteers). > -Chair reviews the agenda. No proposed changes to agenda as shown=20 > below -WG Goals/Milestones status -Chair reviewed status of documents=20 > that have been published, that are waiting for write-up, that are in=20 > last call, in > > progress, under review as WG item, Interesting work outside of current ch= arter. > -Are there any volunteers to shepherd the TLS encryption for RADIUS?=20 > Will put a call out on the list, if no volunteers, > > one of chairs will volunteer. > -Will another last call be required after the current one for RADIUS attr= ibutes draft? To be determined. > -RADIUS over DTLS - Allan will work on to advance. > -NAI-based peer discovery - planned to align with RFC, RFC now=20 > published -IEEE 802 attributes - Bernard picking the draft up again, adop= t as a WG item, make the draft active again. > -NAI - Allan working on it, will discuss changes, and consider=20 > adopting as a work item > -2 drafts for RADIUS accounting > > > ********************************************************** > > 2. RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec=20 > -http://tools.ietf.org/html/draft-ietf-radext-ipv6-access > -See http://www.ietf.org/proceedings/82/slides/radext-1.ppt > -Leaf Yeh: How is the use case for DHCP addressed? > -Woj Dec: Attributes for name pool - DHCP. > -Woj Dec:Next step is to submit next version with editorial comments, cor= rections. > -Leaf Yeh:Question on name of pool on the mailing list. > -Woj Dec: Interpret pool names as such. Solution is to have a different a= ttribute for the pool - stateful-ipv6-address- pool-attribute. Format is th= e same, but is different attributes; one for local, one for delegated. > -Leaf Yeh: Suggests one pool name for all addresses - need to determine h= ow to use the names. Or create complex pool of all attributes. > -Woj Dec:Current conclusion is not to do anything. > -Woj Dec:If use existing attribute, - server has to interpret the pool na= me as belonging to a specific type. > -Bernard Aboba: Roaming deployments - may use a pool name, need to make s= ure you have same behavior across providers. Need to be explicit, so don't = have chaos, can debug issues. > -Chair: Consensus is that the current attribute and semantics are=20 > necessary to not introduce ambiguity > > ************************************************************ > 3. RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh=20 > -http://tools.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01.t > xt -See http://www.ietf.org/proceedings/82/slides/radext-2.pptx > -Describe difference between version 6 and version 4. > -Summary of requirements, IDs, network scenario, attribute design (8=20 > new attributes), enhanced design -Stefan Winter: Use TLV encoding as in e= xtended attributes draft - everything on one attribute. > -Leaf Yeh: Still not sure about container attribute (Stefan Winter=20 > draft addresses) -Leaf Yeh: Does this deserve to be a WG item? Seem to ha= ve clear requirements from the industry. > -Stefan Winter: Concern - have many drafts on this topic, they seem to di= e out for lack of interest, then a variation appears. ^^^^^^^^ I think that was me > -AD:Why not get together and resolve differences, and come back with a si= ngle proposal. What is the benefit of coming up with yet another proposal? > -Leaf Yeh:In last meeting (Quebec), didn't know how to define a new attri= bute using the extensions. Got feedback on the design. > -Stefan Winters: Are you saying that extended attribute is not the right = way? ^^^^^^^^ ditto > -Leaf Yeh: Don't know. Can be done with traditional attribute design.Don'= t disagree. Thought that we as a group came up with better ways of doing th= is. Would like to follow-up with the "fancy accounting" method is not used. > -Stefan Winter:Distinguish between requirements and design. > -Multiple design approaches can solve the problem. > -Alan DeKok:Extended attributes draft was created for a reason - use comp= lex attributes with a lot of content; define container, avoid stuffing seve= ral items into one attribute. Some of proposed designs still use complex en= coding. > -Stefan Winter:Do you accept design 4? > -Leaf Yeh:No includes too much complexity - better to use explicit format= . > -TLV nesting and grouping (Design 3) - what is the benefit of this desig= n? > -Benefit is that it uses the framework that the extended attribute define= s. Reusable code. > -Also need new sub-attributes defined here. > -Need one set of new attributes and one type descriptor regardless. Use p= arser for extended attributes. > -In design 4 - use one field to introduce field type. Complexity is the s= ame. > -Need to write a parser for this specifically. Better to use the framewor= k. > -There can be multiple instances of attributes. In that point, the two ar= e the same. In design 3, don't need another parser. > -Alan notes that Design 3 slide is wrong - attributes can be in any order= . More flexible framework, just extract attributes, In proposal 4, have to = care about the order of the attributes. In Design 3, can leave out some sub= -attributes. > -Chair: Do you support this work in RADEXT? > -Is this needed for IPv4? Traffic type code can indicate the IPv4/IPv6 ty= pe. > -Should I migrate all IPv4 to this new format? BBF request uses original = attributes for past traffic. > -Chair: Is anyone against having an accounting document? No objection. As= k authors to work out a single proposal. Need to determine if we bring into= a new charter. > -AD: before we develop the contributions, ask authors to put together=20 > pros and cons of options, remaining points of disagreement. See if we=20 > can get agreement on a baseline proposal > -Chair: Consensus check on adding this topic to the re-charter: Show of h= ands 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. > -AD:Will this be discussed at the Paris meeting? > -Chair:Yes, not choosing a proposal today; legitimize the work item in th= e charter as a first step. > > ****************************************************************** > 4.RADIUS Attributes for IEEE 802 Networks, Bernard Aboba=20 > -http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt > -http://www.ietf.org/proceedings/82/slides/radext-5.ppt > -Bernard: Purpose to add attributes required in 11r, and 802.1X key usage= . > -Call for adoption was issued Nov 13, 2007. Yesterday was the 4 year anni= versary. > -Does it need more time to ripen (like fine wines)? > -Should have moved a little faster - others adopted parts. > -What kind of attributes - from extended attributes? If move forward, ask= this. > -Need to look at use cases for attributes also. First step is to adopt. > -EMU has finished WGLC on EAP lower layer. EMU would like input on collap= sing lower layers together. Differences between 802.1X-2004 and 802.1X-2010= . > -For the adoption of this document. If wait for it to be completely right= , might be a long while. Also 11u extensions too. > -Unfortunate that document didn't advance - chair was side-tracked, but d= on't want chair's pushing their own agenda. > -Chair: Is there interest to adopt this document to address milestone: 12= -yes, 0-no. > -Take to mailing list to confirm. Strong consensus to move forward. > > ******************************************************************** > 5.RADIUS Protocol Extensions, Alan DeKok=20 > -http://tools.ietf.org/html/draft-ietf-radext-radius-extensions > -See http://www.ietf.org/proceedings/82/slides/radext-3.ppt > -Review of status, implementations (test vectors available - please=20 > use and review) -Comment on IANA section - IANA is a mechanical operation= . Can't use normative language. Talk to Michelle and the IANA people, to se= e what they can really do. Provide extremely clear guidance. > -Believe updated text addresses that. > -What is the base policy - IETF consensus or greater. Add a note that not= changing IETF policy. Updates RFC3575, or not? > -Need to state and be clear if policy is updated. > -Alan to prepare next version - will come out late this week or early nex= t week. > > ********************************************************************* > 6.Network Access Identifier, Alan DeKok > -http://tools.ietf.org/html/draft-dekok-radext-nai-01 > -See http://www.ietf.org/proceedings/82/slides/radext-4.ppt > -Review rationale for the proposal (why") DNS affects EAP and RADIUS - wh= y? > -Is there a Unicode 3.1 dependency here? On a reading of 4284, unassigned= code points are forbidden. > -Cannot use a codepoint newer than 3.2. > -DNS look-up required separate conversion. Do DNS protocol requirements t= o turn string into something acceptable to DNS. > -No one implements any of the requirements of RFC 4282! Rather, treat use= rname field as an opaque blob. 4284 is blocking progress - abfab documents = require use of nai, but 4282 requirements cannot be used. > -Sam Hartman: Dependency in abfab on 4282 - 1 is a bug, will be removed i= n abfab; the second - need a "username" and "realm" item. Disagree that 428= 4 is blocking abfab. But needs to be updated anyway. > -Stefan Winter:Dynamic Discovery draft went through the same process. > -Alan Dekok:Some operating systems don't send UTF-8 characters. More=20 > reason to use nai-bis > -2 distinct questions - 1 to get rid of what should never have been there= in the future. 2 to deal with internationalization questions.in RADIUS. Co= uld get rid of 4282 as a first step, then address internationalization, EAP= . > -AD: Clarify - is the request that 4282 as historical/harmful, and 4282-b= is on RADEXT work plan? > -Stop the confusion first - encoding out of scope. > -Stefan Winter: Is anonymization still there? "Left part" blank. Is it st= ill in? Need to check - believe it is valuable. > -Chair: hearing consensus to work on this. Poll: Killing 4282 a good thi= ng? 10 - yes, 0-no. Strong consensus to put a document out, put on the mail= ing list to confirm. Discuss on the mailing list the scope of 4284 -no-long= er-applicable-versus internationalization. > -Adopt Allan's document? Other approach? To discuss on mailing list. Sam= to create text in abfab to claify purpose of 4282. > > ********************************************************************* > 7.Next Steps: WG Chairs& ADs (15 minutes) -Chair summarizes next=20 > steps re: updating the charter and what was agreed in the meeting. > -Chair reviews current goals and milestones, updates: > -Update IPv6 access to 2011 Dec > -Radius over DTSL - update to 2012 March -RADIUS Cryptoagility -=20 > update to early 2012, or March 2012. > -Extended attributes - update to March 2012 -IEEE 802.11 attributes -=20 > update to June 2012 -Dynamic Discovery - DIME version published, March=20 > 2012 -RADIUS accounting - Sept 2012 > -4284 bis - March 2012 for near term deprecation of 4284, - will be 2 dif= ferent milestones, one for near term, one for longer term. > _______________________________________________ > 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 Tue Nov 15 02:22:08 2011 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 429C011E822D; Tue, 15 Nov 2011 02:22:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321352528; bh=wvTsUiM6+sWY5LK2D2Vge8bCRRrmi2rR4tkHwlxV/90=; h=From:To:Date:Message-ID:References:In-Reply-To:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=tSiiqCTai2yVF/ilFZtB29L7NNhuH0gQOixdMNYhiXUpZO05od5EtZwTrhE5+QC/L kxamsMcDlwpvo0mpnCS8SLIsNvyt40CGwfxod4PTGiSshIT0LMDGexr68s5hYWiHwM lzTBskoaw6exARFolewQOk3452M8wTsv6uWgekhc= 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 433FC11E822D for ; Tue, 15 Nov 2011 02:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.567 X-Spam-Level: X-Spam-Status: No, score=-104.567 tagged_above=-999 required=5 tests=[AWL=-1.568, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4, 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 xHvpg3hKfTAp for ; Tue, 15 Nov 2011 02:22:06 -0800 (PST) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by ietfa.amsl.com (Postfix) with ESMTP id EC18611E8221 for ; Tue, 15 Nov 2011 02:22:05 -0800 (PST) Received: from G5W2206G.americas.hpqcorp.net (g5w2206g.atlanta.hp.com [16.228.43.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id 4FDF638568; Tue, 15 Nov 2011 10:22:05 +0000 (UTC) Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G5W2206G.americas.hpqcorp.net (16.228.43.185) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 15 Nov 2011 10:21:23 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Tue, 15 Nov 2011 10:21:22 +0000 From: "Sanchez, Mauricio (HP Networking)" To: Klaas Wierenga , "radext@ietf.org" Date: Tue, 15 Nov 2011 10:21:19 +0000 Thread-Topic: [radext] RADEXT @ IETF82: Draft meeting notes Thread-Index: AcyjfQNjZ+ADeK6jRKSSRKSKjKdxWwAAx1pA Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE197E@GVW0671EXC.americas.hpqcorp.net> References: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE1978@GVW0671EXC.americas.hpqcorp.net> <4EC233BE.6090302@wierenga.net> In-Reply-To: <4EC233BE.6090302@wierenga.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [radext] RADEXT @ IETF82: Draft meeting notes 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 It was a small test to see whether people actually read the notes. You passed. I've updated my master copy. Thanks, MS -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Klaas Wierenga Sent: Tuesday, November 15, 2011 5:41 PM To: radext@ietf.org Subject: Re: [radext] RADEXT @ IETF82: Draft meeting notes On 11/15/11 10:25 AM, Sanchez, Mauricio (HP Networking) wrote: > Below are the draft notes for our meeting at IETF 82. Any corrections/modifications welcome. no biggie, but see below > > -MS > > > -------------------------------------------------------------- > > RADEXT WG Minutes > IETF 82 > Taipei, Taiwan > Monday, November 14, 2011 > Meeting started 9:02AM and ended 10:32AM. Approximately 17 > individuals in meeting > > Chairs: > Jouni Korhonen Mauricio > Sanchez > > AD: > Dan Romascanu > > > 1.Preliminaries > -Chair asked for jabber scribes (Stefan Winter) and note takers (Dorothy Stanley, Aruba Networks volunteers). > -Chair reviews the agenda. No proposed changes to agenda as shown > below -WG Goals/Milestones status -Chair reviewed status of documents > that have been published, that are waiting for write-up, that are in > last call, in > > progress, under review as WG item, Interesting work outside of current charter. > -Are there any volunteers to shepherd the TLS encryption for RADIUS? > Will put a call out on the list, if no volunteers, > > one of chairs will volunteer. > -Will another last call be required after the current one for RADIUS attributes draft? To be determined. > -RADIUS over DTLS - Allan will work on to advance. > -NAI-based peer discovery - planned to align with RFC, RFC now > published -IEEE 802 attributes - Bernard picking the draft up again, adopt as a WG item, make the draft active again. > -NAI - Allan working on it, will discuss changes, and consider > adopting as a work item > -2 drafts for RADIUS accounting > > > ********************************************************** > > 2. RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec > -http://tools.ietf.org/html/draft-ietf-radext-ipv6-access > -See http://www.ietf.org/proceedings/82/slides/radext-1.ppt > -Leaf Yeh: How is the use case for DHCP addressed? > -Woj Dec: Attributes for name pool - DHCP. > -Woj Dec:Next step is to submit next version with editorial comments, corrections. > -Leaf Yeh:Question on name of pool on the mailing list. > -Woj Dec: Interpret pool names as such. Solution is to have a different attribute for the pool - stateful-ipv6-address- pool-attribute. Format is the same, but is different attributes; one for local, one for delegated. > -Leaf Yeh: Suggests one pool name for all addresses - need to determine how to use the names. Or create complex pool of all attributes. > -Woj Dec:Current conclusion is not to do anything. > -Woj Dec:If use existing attribute, - server has to interpret the pool name as belonging to a specific type. > -Bernard Aboba: Roaming deployments - may use a pool name, need to make sure you have same behavior across providers. Need to be explicit, so don't have chaos, can debug issues. > -Chair: Consensus is that the current attribute and semantics are > necessary to not introduce ambiguity > > ************************************************************ > 3. RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh > -http://tools.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01.t > xt -See http://www.ietf.org/proceedings/82/slides/radext-2.pptx > -Describe difference between version 6 and version 4. > -Summary of requirements, IDs, network scenario, attribute design (8 > new attributes), enhanced design -Stefan Winter: Use TLV encoding as in extended attributes draft - everything on one attribute. > -Leaf Yeh: Still not sure about container attribute (Stefan Winter > draft addresses) -Leaf Yeh: Does this deserve to be a WG item? Seem to have clear requirements from the industry. > -Stefan Winter: Concern - have many drafts on this topic, they seem to die out for lack of interest, then a variation appears. ^^^^^^^^ I think that was me > -AD:Why not get together and resolve differences, and come back with a single proposal. What is the benefit of coming up with yet another proposal? > -Leaf Yeh:In last meeting (Quebec), didn't know how to define a new attribute using the extensions. Got feedback on the design. > -Stefan Winters: Are you saying that extended attribute is not the right way? ^^^^^^^^ ditto > -Leaf Yeh: Don't know. Can be done with traditional attribute design.Don't disagree. Thought that we as a group came up with better ways of doing this. Would like to follow-up with the "fancy accounting" method is not used. > -Stefan Winter:Distinguish between requirements and design. > -Multiple design approaches can solve the problem. > -Alan DeKok:Extended attributes draft was created for a reason - use complex attributes with a lot of content; define container, avoid stuffing several items into one attribute. Some of proposed designs still use complex encoding. > -Stefan Winter:Do you accept design 4? > -Leaf Yeh:No includes too much complexity - better to use explicit format. > -TLV nesting and grouping (Design 3) - what is the benefit of this design? > -Benefit is that it uses the framework that the extended attribute defines. Reusable code. > -Also need new sub-attributes defined here. > -Need one set of new attributes and one type descriptor regardless. Use parser for extended attributes. > -In design 4 - use one field to introduce field type. Complexity is the same. > -Need to write a parser for this specifically. Better to use the framework. > -There can be multiple instances of attributes. In that point, the two are the same. In design 3, don't need another parser. > -Alan notes that Design 3 slide is wrong - attributes can be in any order. More flexible framework, just extract attributes, In proposal 4, have to care about the order of the attributes. In Design 3, can leave out some sub-attributes. > -Chair: Do you support this work in RADEXT? > -Is this needed for IPv4? Traffic type code can indicate the IPv4/IPv6 type. > -Should I migrate all IPv4 to this new format? BBF request uses original attributes for past traffic. > -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. > -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: 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. > -AD:Will this be discussed at the Paris meeting? > -Chair:Yes, not choosing a proposal today; legitimize the work item in the charter as a first step. > > ****************************************************************** > 4.RADIUS Attributes for IEEE 802 Networks, Bernard Aboba > -http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt > -http://www.ietf.org/proceedings/82/slides/radext-5.ppt > -Bernard: Purpose to add attributes required in 11r, and 802.1X key usage. > -Call for adoption was issued Nov 13, 2007. Yesterday was the 4 year anniversary. > -Does it need more time to ripen (like fine wines)? > -Should have moved a little faster - others adopted parts. > -What kind of attributes - from extended attributes? If move forward, ask this. > -Need to look at use cases for attributes also. First step is to adopt. > -EMU has finished WGLC on EAP lower layer. EMU would like input on collapsing lower layers together. Differences between 802.1X-2004 and 802.1X-2010. > -For the adoption of this document. If wait for it to be completely right, might be a long while. Also 11u extensions too. > -Unfortunate that document didn't advance - chair was side-tracked, but don't want chair's pushing their own agenda. > -Chair: Is there interest to adopt this document to address milestone: 12-yes, 0-no. > -Take to mailing list to confirm. Strong consensus to move forward. > > ******************************************************************** > 5.RADIUS Protocol Extensions, Alan DeKok > -http://tools.ietf.org/html/draft-ietf-radext-radius-extensions > -See http://www.ietf.org/proceedings/82/slides/radext-3.ppt > -Review of status, implementations (test vectors available - please > use and review) -Comment on IANA section - IANA is a mechanical operation. Can't use normative language. Talk to Michelle and the IANA people, to see what they can really do. Provide extremely clear guidance. > -Believe updated text addresses that. > -What is the base policy - IETF consensus or greater. Add a note that not changing IETF policy. Updates RFC3575, or not? > -Need to state and be clear if policy is updated. > -Alan to prepare next version - will come out late this week or early next week. > > ********************************************************************* > 6.Network Access Identifier, Alan DeKok > -http://tools.ietf.org/html/draft-dekok-radext-nai-01 > -See http://www.ietf.org/proceedings/82/slides/radext-4.ppt > -Review rationale for the proposal (why") DNS affects EAP and RADIUS - why? > -Is there a Unicode 3.1 dependency here? On a reading of 4284, unassigned code points are forbidden. > -Cannot use a codepoint newer than 3.2. > -DNS look-up required separate conversion. Do DNS protocol requirements to turn string into something acceptable to DNS. > -No one implements any of the requirements of RFC 4282! Rather, treat username field as an opaque blob. 4284 is blocking progress - abfab documents require use of nai, but 4282 requirements cannot be used. > -Sam Hartman: Dependency in abfab on 4282 - 1 is a bug, will be removed in abfab; the second - need a "username" and "realm" item. Disagree that 4284 is blocking abfab. But needs to be updated anyway. > -Stefan Winter:Dynamic Discovery draft went through the same process. > -Alan Dekok:Some operating systems don't send UTF-8 characters. More > reason to use nai-bis > -2 distinct questions - 1 to get rid of what should never have been there in the future. 2 to deal with internationalization questions.in RADIUS. Could get rid of 4282 as a first step, then address internationalization, EAP. > -AD: Clarify - is the request that 4282 as historical/harmful, and 4282-bis on RADEXT work plan? > -Stop the confusion first - encoding out of scope. > -Stefan Winter: Is anonymization still there? "Left part" blank. Is it still in? Need to check - believe it is valuable. > -Chair: hearing consensus to work on this. Poll: Killing 4282 a good thing? 10 - yes, 0-no. Strong consensus to put a document out, put on the mailing list to confirm. Discuss on the mailing list the scope of 4284 -no-longer-applicable-versus internationalization. > -Adopt Allan's document? Other approach? To discuss on mailing list. Sam to create text in abfab to claify purpose of 4282. > > ********************************************************************* > 7.Next Steps: WG Chairs& ADs (15 minutes) -Chair summarizes next > steps re: updating the charter and what was agreed in the meeting. > -Chair reviews current goals and milestones, updates: > -Update IPv6 access to 2011 Dec > -Radius over DTSL - update to 2012 March -RADIUS Cryptoagility - > update to early 2012, or March 2012. > -Extended attributes - update to March 2012 -IEEE 802.11 attributes - > update to June 2012 -Dynamic Discovery - DIME version published, March > 2012 -RADIUS accounting - Sept 2012 > -4284 bis - March 2012 for near term deprecation of 4284, - will be 2 different milestones, one for near term, one for longer term. > _______________________________________________ > 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 _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Tue Nov 15 02:26:58 2011 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 0224321F8F9D; Tue, 15 Nov 2011 02:26:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321352818; bh=BE3gaBdlZgbpMME4vkzuzUwMcs0l+Fdqv2v8pTdGvN4=; 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=w/YxpKHhvlL0fEobp2AYPV/10ZHksBhpRDAYnRx7UIslKqC2igGzGEWs8/pXvjEGl iB7fQKXxE1PoCvuyGbwVe+cROgaWaAkiJRcukSCXzm7CS4GKizd5lNVwHCm6qExp+L xXYgFNzNIbIAy0Oy4SvSRJ2vhKgGHAI25RtbwI3I= 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 6DE3F21F8F9D for ; Tue, 15 Nov 2011 02:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.703 X-Spam-Level: X-Spam-Status: No, score=-100.703 tagged_above=-999 required=5 tests=[AWL=-1.704, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_62=0.6, 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 uZChtm+8PFkq for ; Tue, 15 Nov 2011 02:26:56 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 9716121F8F97 for ; Tue, 15 Nov 2011 02:26:55 -0800 (PST) Message-ID: <4EC23E58.3080008@deployingradius.com> Date: Tue, 15 Nov 2011 11:26:32 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Sanchez, Mauricio (HP Networking)" References: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE1978@GVW0671EXC.americas.hpqcorp.net> <4EC233BE.6090302@wierenga.net> <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE197E@GVW0671EXC.americas.hpqcorp.net> In-Reply-To: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE197E@GVW0671EXC.americas.hpqcorp.net> X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT @ IETF82: Draft meeting notes 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 Sanchez, Mauricio (HP Networking) wrote: > It was a small test to see whether people actually read the notes. You passed. I'm referred to as "Allan". A reference to 4284 should be changed to 4282. "claify" to "clarify" Do I get a cookie? > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Klaas Wierenga > Sent: Tuesday, November 15, 2011 5:41 PM > To: radext@ietf.org > Subject: Re: [radext] RADEXT @ IETF82: Draft meeting notes > > On 11/15/11 10:25 AM, Sanchez, Mauricio (HP Networking) wrote: >> Below are the draft notes for our meeting at IETF 82. Any corrections/modifications welcome. > > no biggie, but see below > >> -MS >> >> >> -------------------------------------------------------------- >> >> RADEXT WG Minutes >> IETF 82 >> Taipei, Taiwan >> Monday, November 14, 2011 >> Meeting started 9:02AM and ended 10:32AM. Approximately 17 >> individuals in meeting >> >> Chairs: >> Jouni Korhonen Mauricio >> Sanchez >> >> AD: >> Dan Romascanu >> >> >> 1.Preliminaries >> -Chair asked for jabber scribes (Stefan Winter) and note takers (Dorothy Stanley, Aruba Networks volunteers). >> -Chair reviews the agenda. No proposed changes to agenda as shown >> below -WG Goals/Milestones status -Chair reviewed status of documents >> that have been published, that are waiting for write-up, that are in >> last call, in >> >> progress, under review as WG item, Interesting work outside of current charter. >> -Are there any volunteers to shepherd the TLS encryption for RADIUS? >> Will put a call out on the list, if no volunteers, >> >> one of chairs will volunteer. >> -Will another last call be required after the current one for RADIUS attributes draft? To be determined. >> -RADIUS over DTLS - Allan will work on to advance. >> -NAI-based peer discovery - planned to align with RFC, RFC now >> published -IEEE 802 attributes - Bernard picking the draft up again, adopt as a WG item, make the draft active again. >> -NAI - Allan working on it, will discuss changes, and consider >> adopting as a work item >> -2 drafts for RADIUS accounting >> >> >> ********************************************************** >> >> 2. RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec >> -http://tools.ietf.org/html/draft-ietf-radext-ipv6-access >> -See http://www.ietf.org/proceedings/82/slides/radext-1.ppt >> -Leaf Yeh: How is the use case for DHCP addressed? >> -Woj Dec: Attributes for name pool - DHCP. >> -Woj Dec:Next step is to submit next version with editorial comments, corrections. >> -Leaf Yeh:Question on name of pool on the mailing list. >> -Woj Dec: Interpret pool names as such. Solution is to have a different attribute for the pool - stateful-ipv6-address- pool-attribute. Format is the same, but is different attributes; one for local, one for delegated. >> -Leaf Yeh: Suggests one pool name for all addresses - need to determine how to use the names. Or create complex pool of all attributes. >> -Woj Dec:Current conclusion is not to do anything. >> -Woj Dec:If use existing attribute, - server has to interpret the pool name as belonging to a specific type. >> -Bernard Aboba: Roaming deployments - may use a pool name, need to make sure you have same behavior across providers. Need to be explicit, so don't have chaos, can debug issues. >> -Chair: Consensus is that the current attribute and semantics are >> necessary to not introduce ambiguity >> >> ************************************************************ >> 3. RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh >> -http://tools.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01.t >> xt -See http://www.ietf.org/proceedings/82/slides/radext-2.pptx >> -Describe difference between version 6 and version 4. >> -Summary of requirements, IDs, network scenario, attribute design (8 >> new attributes), enhanced design -Stefan Winter: Use TLV encoding as in extended attributes draft - everything on one attribute. >> -Leaf Yeh: Still not sure about container attribute (Stefan Winter >> draft addresses) -Leaf Yeh: Does this deserve to be a WG item? Seem to have clear requirements from the industry. >> -Stefan Winter: Concern - have many drafts on this topic, they seem to die out for lack of interest, then a variation appears. > ^^^^^^^^ I think that was me > >> -AD:Why not get together and resolve differences, and come back with a single proposal. What is the benefit of coming up with yet another proposal? >> -Leaf Yeh:In last meeting (Quebec), didn't know how to define a new attribute using the extensions. Got feedback on the design. >> -Stefan Winters: Are you saying that extended attribute is not the right way? > ^^^^^^^^ > ditto > >> -Leaf Yeh: Don't know. Can be done with traditional attribute design.Don't disagree. Thought that we as a group came up with better ways of doing this. Would like to follow-up with the "fancy accounting" method is not used. >> -Stefan Winter:Distinguish between requirements and design. >> -Multiple design approaches can solve the problem. >> -Alan DeKok:Extended attributes draft was created for a reason - use complex attributes with a lot of content; define container, avoid stuffing several items into one attribute. Some of proposed designs still use complex encoding. >> -Stefan Winter:Do you accept design 4? >> -Leaf Yeh:No includes too much complexity - better to use explicit format. >> -TLV nesting and grouping (Design 3) - what is the benefit of this design? >> -Benefit is that it uses the framework that the extended attribute defines. Reusable code. >> -Also need new sub-attributes defined here. >> -Need one set of new attributes and one type descriptor regardless. Use parser for extended attributes. >> -In design 4 - use one field to introduce field type. Complexity is the same. >> -Need to write a parser for this specifically. Better to use the framework. >> -There can be multiple instances of attributes. In that point, the two are the same. In design 3, don't need another parser. >> -Alan notes that Design 3 slide is wrong - attributes can be in any order. More flexible framework, just extract attributes, In proposal 4, have to care about the order of the attributes. In Design 3, can leave out some sub-attributes. >> -Chair: Do you support this work in RADEXT? >> -Is this needed for IPv4? Traffic type code can indicate the IPv4/IPv6 type. >> -Should I migrate all IPv4 to this new format? BBF request uses original attributes for past traffic. >> -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. >> -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: 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. >> -AD:Will this be discussed at the Paris meeting? >> -Chair:Yes, not choosing a proposal today; legitimize the work item in the charter as a first step. >> >> ****************************************************************** >> 4.RADIUS Attributes for IEEE 802 Networks, Bernard Aboba >> -http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt >> -http://www.ietf.org/proceedings/82/slides/radext-5.ppt >> -Bernard: Purpose to add attributes required in 11r, and 802.1X key usage. >> -Call for adoption was issued Nov 13, 2007. Yesterday was the 4 year anniversary. >> -Does it need more time to ripen (like fine wines)? >> -Should have moved a little faster - others adopted parts. >> -What kind of attributes - from extended attributes? If move forward, ask this. >> -Need to look at use cases for attributes also. First step is to adopt. >> -EMU has finished WGLC on EAP lower layer. EMU would like input on collapsing lower layers together. Differences between 802.1X-2004 and 802.1X-2010. >> -For the adoption of this document. If wait for it to be completely right, might be a long while. Also 11u extensions too. >> -Unfortunate that document didn't advance - chair was side-tracked, but don't want chair's pushing their own agenda. >> -Chair: Is there interest to adopt this document to address milestone: 12-yes, 0-no. >> -Take to mailing list to confirm. Strong consensus to move forward. >> >> ******************************************************************** >> 5.RADIUS Protocol Extensions, Alan DeKok >> -http://tools.ietf.org/html/draft-ietf-radext-radius-extensions >> -See http://www.ietf.org/proceedings/82/slides/radext-3.ppt >> -Review of status, implementations (test vectors available - please >> use and review) -Comment on IANA section - IANA is a mechanical operation. Can't use normative language. Talk to Michelle and the IANA people, to see what they can really do. Provide extremely clear guidance. >> -Believe updated text addresses that. >> -What is the base policy - IETF consensus or greater. Add a note that not changing IETF policy. Updates RFC3575, or not? >> -Need to state and be clear if policy is updated. >> -Alan to prepare next version - will come out late this week or early next week. >> >> ********************************************************************* >> 6.Network Access Identifier, Alan DeKok >> -http://tools.ietf.org/html/draft-dekok-radext-nai-01 >> -See http://www.ietf.org/proceedings/82/slides/radext-4.ppt >> -Review rationale for the proposal (why") DNS affects EAP and RADIUS - why? >> -Is there a Unicode 3.1 dependency here? On a reading of 4284, unassigned code points are forbidden. >> -Cannot use a codepoint newer than 3.2. >> -DNS look-up required separate conversion. Do DNS protocol requirements to turn string into something acceptable to DNS. >> -No one implements any of the requirements of RFC 4282! Rather, treat username field as an opaque blob. 4284 is blocking progress - abfab documents require use of nai, but 4282 requirements cannot be used. >> -Sam Hartman: Dependency in abfab on 4282 - 1 is a bug, will be removed in abfab; the second - need a "username" and "realm" item. Disagree that 4284 is blocking abfab. But needs to be updated anyway. >> -Stefan Winter:Dynamic Discovery draft went through the same process. >> -Alan Dekok:Some operating systems don't send UTF-8 characters. More >> reason to use nai-bis >> -2 distinct questions - 1 to get rid of what should never have been there in the future. 2 to deal with internationalization questions.in RADIUS. Could get rid of 4282 as a first step, then address internationalization, EAP. >> -AD: Clarify - is the request that 4282 as historical/harmful, and 4282-bis on RADEXT work plan? >> -Stop the confusion first - encoding out of scope. >> -Stefan Winter: Is anonymization still there? "Left part" blank. Is it still in? Need to check - believe it is valuable. >> -Chair: hearing consensus to work on this. Poll: Killing 4282 a good thing? 10 - yes, 0-no. Strong consensus to put a document out, put on the mailing list to confirm. Discuss on the mailing list the scope of 4284 -no-longer-applicable-versus internationalization. >> -Adopt Allan's document? Other approach? To discuss on mailing list. Sam to create text in abfab to claify purpose of 4282. >> >> ********************************************************************* >> 7.Next Steps: WG Chairs& ADs (15 minutes) -Chair summarizes next >> steps re: updating the charter and what was agreed in the meeting. >> -Chair reviews current goals and milestones, updates: >> -Update IPv6 access to 2011 Dec >> -Radius over DTSL - update to 2012 March -RADIUS Cryptoagility - >> update to early 2012, or March 2012. >> -Extended attributes - update to March 2012 -IEEE 802.11 attributes - >> update to June 2012 -Dynamic Discovery - DIME version published, March >> 2012 -RADIUS accounting - Sept 2012 >> -4284 bis - March 2012 for near term deprecation of 4284, - will be 2 different milestones, one for near term, one for longer term. >> _______________________________________________ >> 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 > _______________________________________________ > 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 aland@deployingradius.com Tue Nov 15 02:26:57 2011 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 6DE3F21F8F9D for ; Tue, 15 Nov 2011 02:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.703 X-Spam-Level: X-Spam-Status: No, score=-100.703 tagged_above=-999 required=5 tests=[AWL=-1.704, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_62=0.6, 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 uZChtm+8PFkq for ; Tue, 15 Nov 2011 02:26:56 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 9716121F8F97 for ; Tue, 15 Nov 2011 02:26:55 -0800 (PST) Message-ID: <4EC23E58.3080008@deployingradius.com> Date: Tue, 15 Nov 2011 11:26:32 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Sanchez, Mauricio (HP Networking)" References: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE1978@GVW0671EXC.americas.hpqcorp.net> <4EC233BE.6090302@wierenga.net> <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE197E@GVW0671EXC.americas.hpqcorp.net> In-Reply-To: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE197E@GVW0671EXC.americas.hpqcorp.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT @ IETF82: Draft meeting notes 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, 15 Nov 2011 10:26:57 -0000 Sanchez, Mauricio (HP Networking) wrote: > It was a small test to see whether people actually read the notes. You passed. I'm referred to as "Allan". A reference to 4284 should be changed to 4282. "claify" to "clarify" Do I get a cookie? > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Klaas Wierenga > Sent: Tuesday, November 15, 2011 5:41 PM > To: radext@ietf.org > Subject: Re: [radext] RADEXT @ IETF82: Draft meeting notes > > On 11/15/11 10:25 AM, Sanchez, Mauricio (HP Networking) wrote: >> Below are the draft notes for our meeting at IETF 82. Any corrections/modifications welcome. > > no biggie, but see below > >> -MS >> >> >> -------------------------------------------------------------- >> >> RADEXT WG Minutes >> IETF 82 >> Taipei, Taiwan >> Monday, November 14, 2011 >> Meeting started 9:02AM and ended 10:32AM. Approximately 17 >> individuals in meeting >> >> Chairs: >> Jouni Korhonen Mauricio >> Sanchez >> >> AD: >> Dan Romascanu >> >> >> 1.Preliminaries >> -Chair asked for jabber scribes (Stefan Winter) and note takers (Dorothy Stanley, Aruba Networks volunteers). >> -Chair reviews the agenda. No proposed changes to agenda as shown >> below -WG Goals/Milestones status -Chair reviewed status of documents >> that have been published, that are waiting for write-up, that are in >> last call, in >> >> progress, under review as WG item, Interesting work outside of current charter. >> -Are there any volunteers to shepherd the TLS encryption for RADIUS? >> Will put a call out on the list, if no volunteers, >> >> one of chairs will volunteer. >> -Will another last call be required after the current one for RADIUS attributes draft? To be determined. >> -RADIUS over DTLS - Allan will work on to advance. >> -NAI-based peer discovery - planned to align with RFC, RFC now >> published -IEEE 802 attributes - Bernard picking the draft up again, adopt as a WG item, make the draft active again. >> -NAI - Allan working on it, will discuss changes, and consider >> adopting as a work item >> -2 drafts for RADIUS accounting >> >> >> ********************************************************** >> >> 2. RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec >> -http://tools.ietf.org/html/draft-ietf-radext-ipv6-access >> -See http://www.ietf.org/proceedings/82/slides/radext-1.ppt >> -Leaf Yeh: How is the use case for DHCP addressed? >> -Woj Dec: Attributes for name pool - DHCP. >> -Woj Dec:Next step is to submit next version with editorial comments, corrections. >> -Leaf Yeh:Question on name of pool on the mailing list. >> -Woj Dec: Interpret pool names as such. Solution is to have a different attribute for the pool - stateful-ipv6-address- pool-attribute. Format is the same, but is different attributes; one for local, one for delegated. >> -Leaf Yeh: Suggests one pool name for all addresses - need to determine how to use the names. Or create complex pool of all attributes. >> -Woj Dec:Current conclusion is not to do anything. >> -Woj Dec:If use existing attribute, - server has to interpret the pool name as belonging to a specific type. >> -Bernard Aboba: Roaming deployments - may use a pool name, need to make sure you have same behavior across providers. Need to be explicit, so don't have chaos, can debug issues. >> -Chair: Consensus is that the current attribute and semantics are >> necessary to not introduce ambiguity >> >> ************************************************************ >> 3. RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh >> -http://tools.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01.t >> xt -See http://www.ietf.org/proceedings/82/slides/radext-2.pptx >> -Describe difference between version 6 and version 4. >> -Summary of requirements, IDs, network scenario, attribute design (8 >> new attributes), enhanced design -Stefan Winter: Use TLV encoding as in extended attributes draft - everything on one attribute. >> -Leaf Yeh: Still not sure about container attribute (Stefan Winter >> draft addresses) -Leaf Yeh: Does this deserve to be a WG item? Seem to have clear requirements from the industry. >> -Stefan Winter: Concern - have many drafts on this topic, they seem to die out for lack of interest, then a variation appears. > ^^^^^^^^ I think that was me > >> -AD:Why not get together and resolve differences, and come back with a single proposal. What is the benefit of coming up with yet another proposal? >> -Leaf Yeh:In last meeting (Quebec), didn't know how to define a new attribute using the extensions. Got feedback on the design. >> -Stefan Winters: Are you saying that extended attribute is not the right way? > ^^^^^^^^ > ditto > >> -Leaf Yeh: Don't know. Can be done with traditional attribute design.Don't disagree. Thought that we as a group came up with better ways of doing this. Would like to follow-up with the "fancy accounting" method is not used. >> -Stefan Winter:Distinguish between requirements and design. >> -Multiple design approaches can solve the problem. >> -Alan DeKok:Extended attributes draft was created for a reason - use complex attributes with a lot of content; define container, avoid stuffing several items into one attribute. Some of proposed designs still use complex encoding. >> -Stefan Winter:Do you accept design 4? >> -Leaf Yeh:No includes too much complexity - better to use explicit format. >> -TLV nesting and grouping (Design 3) - what is the benefit of this design? >> -Benefit is that it uses the framework that the extended attribute defines. Reusable code. >> -Also need new sub-attributes defined here. >> -Need one set of new attributes and one type descriptor regardless. Use parser for extended attributes. >> -In design 4 - use one field to introduce field type. Complexity is the same. >> -Need to write a parser for this specifically. Better to use the framework. >> -There can be multiple instances of attributes. In that point, the two are the same. In design 3, don't need another parser. >> -Alan notes that Design 3 slide is wrong - attributes can be in any order. More flexible framework, just extract attributes, In proposal 4, have to care about the order of the attributes. In Design 3, can leave out some sub-attributes. >> -Chair: Do you support this work in RADEXT? >> -Is this needed for IPv4? Traffic type code can indicate the IPv4/IPv6 type. >> -Should I migrate all IPv4 to this new format? BBF request uses original attributes for past traffic. >> -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. >> -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: 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. >> -AD:Will this be discussed at the Paris meeting? >> -Chair:Yes, not choosing a proposal today; legitimize the work item in the charter as a first step. >> >> ****************************************************************** >> 4.RADIUS Attributes for IEEE 802 Networks, Bernard Aboba >> -http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt >> -http://www.ietf.org/proceedings/82/slides/radext-5.ppt >> -Bernard: Purpose to add attributes required in 11r, and 802.1X key usage. >> -Call for adoption was issued Nov 13, 2007. Yesterday was the 4 year anniversary. >> -Does it need more time to ripen (like fine wines)? >> -Should have moved a little faster - others adopted parts. >> -What kind of attributes - from extended attributes? If move forward, ask this. >> -Need to look at use cases for attributes also. First step is to adopt. >> -EMU has finished WGLC on EAP lower layer. EMU would like input on collapsing lower layers together. Differences between 802.1X-2004 and 802.1X-2010. >> -For the adoption of this document. If wait for it to be completely right, might be a long while. Also 11u extensions too. >> -Unfortunate that document didn't advance - chair was side-tracked, but don't want chair's pushing their own agenda. >> -Chair: Is there interest to adopt this document to address milestone: 12-yes, 0-no. >> -Take to mailing list to confirm. Strong consensus to move forward. >> >> ******************************************************************** >> 5.RADIUS Protocol Extensions, Alan DeKok >> -http://tools.ietf.org/html/draft-ietf-radext-radius-extensions >> -See http://www.ietf.org/proceedings/82/slides/radext-3.ppt >> -Review of status, implementations (test vectors available - please >> use and review) -Comment on IANA section - IANA is a mechanical operation. Can't use normative language. Talk to Michelle and the IANA people, to see what they can really do. Provide extremely clear guidance. >> -Believe updated text addresses that. >> -What is the base policy - IETF consensus or greater. Add a note that not changing IETF policy. Updates RFC3575, or not? >> -Need to state and be clear if policy is updated. >> -Alan to prepare next version - will come out late this week or early next week. >> >> ********************************************************************* >> 6.Network Access Identifier, Alan DeKok >> -http://tools.ietf.org/html/draft-dekok-radext-nai-01 >> -See http://www.ietf.org/proceedings/82/slides/radext-4.ppt >> -Review rationale for the proposal (why") DNS affects EAP and RADIUS - why? >> -Is there a Unicode 3.1 dependency here? On a reading of 4284, unassigned code points are forbidden. >> -Cannot use a codepoint newer than 3.2. >> -DNS look-up required separate conversion. Do DNS protocol requirements to turn string into something acceptable to DNS. >> -No one implements any of the requirements of RFC 4282! Rather, treat username field as an opaque blob. 4284 is blocking progress - abfab documents require use of nai, but 4282 requirements cannot be used. >> -Sam Hartman: Dependency in abfab on 4282 - 1 is a bug, will be removed in abfab; the second - need a "username" and "realm" item. Disagree that 4284 is blocking abfab. But needs to be updated anyway. >> -Stefan Winter:Dynamic Discovery draft went through the same process. >> -Alan Dekok:Some operating systems don't send UTF-8 characters. More >> reason to use nai-bis >> -2 distinct questions - 1 to get rid of what should never have been there in the future. 2 to deal with internationalization questions.in RADIUS. Could get rid of 4282 as a first step, then address internationalization, EAP. >> -AD: Clarify - is the request that 4282 as historical/harmful, and 4282-bis on RADEXT work plan? >> -Stop the confusion first - encoding out of scope. >> -Stefan Winter: Is anonymization still there? "Left part" blank. Is it still in? Need to check - believe it is valuable. >> -Chair: hearing consensus to work on this. Poll: Killing 4282 a good thing? 10 - yes, 0-no. Strong consensus to put a document out, put on the mailing list to confirm. Discuss on the mailing list the scope of 4284 -no-longer-applicable-versus internationalization. >> -Adopt Allan's document? Other approach? To discuss on mailing list. Sam to create text in abfab to claify purpose of 4282. >> >> ********************************************************************* >> 7.Next Steps: WG Chairs& ADs (15 minutes) -Chair summarizes next >> steps re: updating the charter and what was agreed in the meeting. >> -Chair reviews current goals and milestones, updates: >> -Update IPv6 access to 2011 Dec >> -Radius over DTSL - update to 2012 March -RADIUS Cryptoagility - >> update to early 2012, or March 2012. >> -Extended attributes - update to March 2012 -IEEE 802.11 attributes - >> update to June 2012 -Dynamic Discovery - DIME version published, March >> 2012 -RADIUS accounting - Sept 2012 >> -4284 bis - March 2012 for near term deprecation of 4284, - will be 2 different milestones, one for near term, one for longer term. >> _______________________________________________ >> 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 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > > From mauricio.sanchez@hp.com Tue Nov 15 02:27:37 2011 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 4923011E823E for ; Tue, 15 Nov 2011 02:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.237 X-Spam-Level: X-Spam-Status: No, score=-106.237 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 0urHmt1C-lrn for ; Tue, 15 Nov 2011 02:27:36 -0800 (PST) Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6395511E8202 for ; Tue, 15 Nov 2011 02:27:36 -0800 (PST) Received: from G1W0400.americas.hpqcorp.net (g1w0400.americas.hpqcorp.net [16.236.31.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTPS id C3DE98169; Tue, 15 Nov 2011 10:27:34 +0000 (UTC) Received: from G5W0324.americas.hpqcorp.net (16.228.8.69) by G1W0400.americas.hpqcorp.net (16.236.31.10) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 15 Nov 2011 10:27:15 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0324.americas.hpqcorp.net ([16.228.8.69]) with mapi; Tue, 15 Nov 2011 10:27:15 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "David B. Nelson" , Alan DeKok Date: Tue, 15 Nov 2011 10:27:12 +0000 Thread-Topic: [radext] Accounting for traffic classes Thread-Index: AcyiyjUj3LztRZXqSKSAJNgwJLXqngAto/sQ Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE197F@GVW0671EXC.americas.hpqcorp.net> References: <4EC0DD6F.4030405@deployingradius.com> <302514528.2606057.1321274255818.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> In-Reply-To: <302514528.2606057.1321274255818.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "radext@ietf.org" , Stefan Winter Subject: Re: [radext] Accounting for traffic classes 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, 15 Nov 2011 10:27:37 -0000 +1 If I'm going to have to write a new parser, rather just write one that can = be re-used. =20 Alan, When did you say you'd have a new version of the extensions draft completed= ? -MS -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of= David B. Nelson Sent: Monday, November 14, 2011 8:38 PM To: Alan DeKok Cc: radext@ietf.org; Stefan Winter Subject: Re: [radext] Accounting for traffic classes Alan DeKok writes: > The alternative is to make this decision for *every* draft. "It's not=20 > any more complicated to have a custom format than to use the new=20 > format". So this argument will be made for *every* draft. The result=20 > will be that the new format never gets implemented. >=20 > At some point, we have to decide to use the new format. We might as=20 > well do it now. I see no benefit to delay, delay, delay, delay. +1 _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Tue Nov 15 02:27:38 2011 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 585A811E823F; Tue, 15 Nov 2011 02:27:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321352858; bh=u5nNVg4RpfkujNDGAkuHTBhm1Pd2v75nmGG0WHPFFkg=; h=From:To:Date:Message-ID:References: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=exKeBo5N+DSFr9LT2ZtKG4A9AOkHLmcILbGPDoRx9cGENDz0n6LFf/m6SMApQp85F PtHkg9hIUPtcn62PgkX6qaY6bGkxTwjQM0s63Q3upPD5hp5Xd1zTAf2NZFi/DNBNtI 0G9GFXePmxC3HSl/32LCZQwQG1qv4jRT7XBotq0A= 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 4923011E823E for ; Tue, 15 Nov 2011 02:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.237 X-Spam-Level: X-Spam-Status: No, score=-106.237 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 0urHmt1C-lrn for ; Tue, 15 Nov 2011 02:27:36 -0800 (PST) Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6395511E8202 for ; Tue, 15 Nov 2011 02:27:36 -0800 (PST) Received: from G1W0400.americas.hpqcorp.net (g1w0400.americas.hpqcorp.net [16.236.31.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTPS id C3DE98169; Tue, 15 Nov 2011 10:27:34 +0000 (UTC) Received: from G5W0324.americas.hpqcorp.net (16.228.8.69) by G1W0400.americas.hpqcorp.net (16.236.31.10) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 15 Nov 2011 10:27:15 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0324.americas.hpqcorp.net ([16.228.8.69]) with mapi; Tue, 15 Nov 2011 10:27:15 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "David B. Nelson" , Alan DeKok Date: Tue, 15 Nov 2011 10:27:12 +0000 Thread-Topic: [radext] Accounting for traffic classes Thread-Index: AcyiyjUj3LztRZXqSKSAJNgwJLXqngAto/sQ Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE197F@GVW0671EXC.americas.hpqcorp.net> References: <4EC0DD6F.4030405@deployingradius.com> <302514528.2606057.1321274255818.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> In-Reply-To: <302514528.2606057.1321274255818.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "radext@ietf.org" , Stefan Winter Subject: Re: [radext] Accounting for traffic classes 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 +1 If I'm going to have to write a new parser, rather just write one that can be re-used. Alan, When did you say you'd have a new version of the extensions draft completed? -MS -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of David B. Nelson Sent: Monday, November 14, 2011 8:38 PM To: Alan DeKok Cc: radext@ietf.org; Stefan Winter Subject: Re: [radext] Accounting for traffic classes Alan DeKok writes: > The alternative is to make this decision for *every* draft. "It's not > any more complicated to have a custom format than to use the new > format". So this argument will be made for *every* draft. The result > will be that the new format never gets implemented. > > At some point, we have to decide to use the new format. We might as > well do it now. I see no benefit to delay, delay, delay, delay. +1 _______________________________________________ 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 mauricio.sanchez@hp.com Tue Nov 15 02:30:23 2011 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 E98E411E823F for ; Tue, 15 Nov 2011 02:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.465 X-Spam-Level: X-Spam-Status: No, score=-104.465 tagged_above=-999 required=5 tests=[AWL=-1.466, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4, 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 vKzG2mwnFfBc for ; Tue, 15 Nov 2011 02:30:22 -0800 (PST) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDFD11E823E for ; Tue, 15 Nov 2011 02:30:22 -0800 (PST) Received: from G5W2206G.americas.hpqcorp.net (g5w2206g.atlanta.hp.com [16.228.43.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0027.austin.hp.com (Postfix) with ESMTPS id 19F72382CB; Tue, 15 Nov 2011 10:30:22 +0000 (UTC) Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G5W2206G.americas.hpqcorp.net (16.228.43.185) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 15 Nov 2011 10:29:39 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Tue, 15 Nov 2011 10:29:38 +0000 From: "Sanchez, Mauricio (HP Networking)" To: Alan DeKok Date: Tue, 15 Nov 2011 10:29:35 +0000 Thread-Topic: [radext] RADEXT @ IETF82: Draft meeting notes Thread-Index: AcyjgRYT39lzr54VTVGcneS2CGJglAAAEA5Q Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE1980@GVW0671EXC.americas.hpqcorp.net> References: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE1978@GVW0671EXC.americas.hpqcorp.net> <4EC233BE.6090302@wierenga.net> <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE197E@GVW0671EXC.americas.hpqcorp.net> <4EC23E58.3080008@deployingradius.com> In-Reply-To: <4EC23E58.3080008@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT @ IETF82: Draft meeting notes 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, 15 Nov 2011 10:30:24 -0000 You get a gold star. Master copy updated. Thanks, MS -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com]=20 Sent: Tuesday, November 15, 2011 6:27 PM To: Sanchez, Mauricio (HP Networking) Cc: radext@ietf.org Subject: Re: [radext] RADEXT @ IETF82: Draft meeting notes Sanchez, Mauricio (HP Networking) wrote: > It was a small test to see whether people actually read the notes. You = passed.=20 I'm referred to as "Allan". A reference to 4284 should be changed to 428= 2. "claify" to "clarify" Do I get a cookie? > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On=20 > Behalf Of Klaas Wierenga > Sent: Tuesday, November 15, 2011 5:41 PM > To: radext@ietf.org > Subject: Re: [radext] RADEXT @ IETF82: Draft meeting notes >=20 > On 11/15/11 10:25 AM, Sanchez, Mauricio (HP Networking) wrote: >> Below are the draft notes for our meeting at IETF 82. Any corrections/m= odifications welcome. >=20 > no biggie, but see below >=20 >> -MS >> >> >> -------------------------------------------------------------- >> >> RADEXT WG Minutes >> IETF 82 >> Taipei, Taiwan >> Monday, November 14, 2011 >> Meeting started 9:02AM and ended 10:32AM. Approximately 17=20 >> individuals in meeting >> >> Chairs: >> Jouni Korhonen Mauricio=20 >> Sanchez >> >> AD: >> Dan Romascanu >> >> >> 1.Preliminaries >> -Chair asked for jabber scribes (Stefan Winter) and note takers (Dorothy= Stanley, Aruba Networks volunteers). >> -Chair reviews the agenda. No proposed changes to agenda as shown=20 >> below -WG Goals/Milestones status -Chair reviewed status of documents=20 >> that have been published, that are waiting for write-up, that are in=20 >> last call, in >> >> progress, under review as WG item, Interesting work outside of current c= harter. >> -Are there any volunteers to shepherd the TLS encryption for RADIUS?=20 >> Will put a call out on the list, if no volunteers, >> >> one of chairs will volunteer. >> -Will another last call be required after the current one for RADIUS att= ributes draft? To be determined. >> -RADIUS over DTLS - Allan will work on to advance. >> -NAI-based peer discovery - planned to align with RFC, RFC now=20 >> published -IEEE 802 attributes - Bernard picking the draft up again, ado= pt as a WG item, make the draft active again. >> -NAI - Allan working on it, will discuss changes, and consider=20 >> adopting as a work item >> -2 drafts for RADIUS accounting >> >> >> ********************************************************** >> >> 2. RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec=20 >> -http://tools.ietf.org/html/draft-ietf-radext-ipv6-access >> -See http://www.ietf.org/proceedings/82/slides/radext-1.ppt >> -Leaf Yeh: How is the use case for DHCP addressed? >> -Woj Dec: Attributes for name pool - DHCP. >> -Woj Dec:Next step is to submit next version with editorial comments, co= rrections. >> -Leaf Yeh:Question on name of pool on the mailing list. >> -Woj Dec: Interpret pool names as such. Solution is to have a different = attribute for the pool - stateful-ipv6-address- pool-attribute. Format is t= he same, but is different attributes; one for local, one for delegated. >> -Leaf Yeh: Suggests one pool name for all addresses - need to determine = how to use the names. Or create complex pool of all attributes. >> -Woj Dec:Current conclusion is not to do anything. >> -Woj Dec:If use existing attribute, - server has to interpret the pool n= ame as belonging to a specific type. >> -Bernard Aboba: Roaming deployments - may use a pool name, need to make = sure you have same behavior across providers. Need to be explicit, so don't= have chaos, can debug issues. >> -Chair: Consensus is that the current attribute and semantics are=20 >> necessary to not introduce ambiguity >> >> ************************************************************ >> 3. RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh=20 >> -http://tools.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01. >> t xt -See http://www.ietf.org/proceedings/82/slides/radext-2.pptx >> -Describe difference between version 6 and version 4. >> -Summary of requirements, IDs, network scenario, attribute design (8=20 >> new attributes), enhanced design -Stefan Winter: Use TLV encoding as in = extended attributes draft - everything on one attribute. >> -Leaf Yeh: Still not sure about container attribute (Stefan Winter=20 >> draft addresses) -Leaf Yeh: Does this deserve to be a WG item? Seem to h= ave clear requirements from the industry. >> -Stefan Winter: Concern - have many drafts on this topic, they seem to d= ie out for lack of interest, then a variation appears. > ^^^^^^^^ I think that was me >=20 >> -AD:Why not get together and resolve differences, and come back with a s= ingle proposal. What is the benefit of coming up with yet another proposal? >> -Leaf Yeh:In last meeting (Quebec), didn't know how to define a new attr= ibute using the extensions. Got feedback on the design. >> -Stefan Winters: Are you saying that extended attribute is not the right= way? > ^^^^^^^^ > ditto >=20 >> -Leaf Yeh: Don't know. Can be done with traditional attribute design.Don= 't disagree. Thought that we as a group came up with better ways of doing t= his. Would like to follow-up with the "fancy accounting" method is not used= . >> -Stefan Winter:Distinguish between requirements and design. >> -Multiple design approaches can solve the problem. >> -Alan DeKok:Extended attributes draft was created for a reason - use com= plex attributes with a lot of content; define container, avoid stuffing sev= eral items into one attribute. Some of proposed designs still use complex e= ncoding. >> -Stefan Winter:Do you accept design 4? >> -Leaf Yeh:No includes too much complexity - better to use explicit forma= t. >> -TLV nesting and grouping (Design 3) - what is the benefit of this desi= gn? >> -Benefit is that it uses the framework that the extended attribute defin= es. Reusable code. >> -Also need new sub-attributes defined here. >> -Need one set of new attributes and one type descriptor regardless. Use = parser for extended attributes. >> -In design 4 - use one field to introduce field type. Complexity is the = same. >> -Need to write a parser for this specifically. Better to use the framewo= rk. >> -There can be multiple instances of attributes. In that point, the two a= re the same. In design 3, don't need another parser. >> -Alan notes that Design 3 slide is wrong - attributes can be in any orde= r. More flexible framework, just extract attributes, In proposal 4, have to= care about the order of the attributes. In Design 3, can leave out some su= b-attributes. >> -Chair: Do you support this work in RADEXT? >> -Is this needed for IPv4? Traffic type code can indicate the IPv4/IPv6 t= ype. >> -Should I migrate all IPv4 to this new format? BBF request uses original= attributes for past traffic. >> -Chair: Is anyone against having an accounting document? No objection. A= sk authors to work out a single proposal. Need to determine if we bring int= o a new charter. >> -AD: before we develop the contributions, ask authors to put together=20 >> pros and cons of options, remaining points of disagreement. See if we=20 >> can get agreement on a baseline proposal >> -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 mak= e this a working group item. Ask authors to work towards a unified proposal= . >> -AD:Will this be discussed at the Paris meeting? >> -Chair:Yes, not choosing a proposal today; legitimize the work item in t= he charter as a first step. >> >> ****************************************************************** >> 4.RADIUS Attributes for IEEE 802 Networks, Bernard Aboba=20 >> -http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt >> -http://www.ietf.org/proceedings/82/slides/radext-5.ppt >> -Bernard: Purpose to add attributes required in 11r, and 802.1X key usag= e. >> -Call for adoption was issued Nov 13, 2007. Yesterday was the 4 year ann= iversary. >> -Does it need more time to ripen (like fine wines)? >> -Should have moved a little faster - others adopted parts. >> -What kind of attributes - from extended attributes? If move forward, as= k this. >> -Need to look at use cases for attributes also. First step is to adopt. >> -EMU has finished WGLC on EAP lower layer. EMU would like input on colla= psing lower layers together. Differences between 802.1X-2004 and 802.1X-201= 0. >> -For the adoption of this document. If wait for it to be completely righ= t, might be a long while. Also 11u extensions too. >> -Unfortunate that document didn't advance - chair was side-tracked, but = don't want chair's pushing their own agenda. >> -Chair: Is there interest to adopt this document to address milestone: 1= 2-yes, 0-no. >> -Take to mailing list to confirm. Strong consensus to move forward. >> >> ******************************************************************** >> 5.RADIUS Protocol Extensions, Alan DeKok=20 >> -http://tools.ietf.org/html/draft-ietf-radext-radius-extensions >> -See http://www.ietf.org/proceedings/82/slides/radext-3.ppt >> -Review of status, implementations (test vectors available - please=20 >> use and review) -Comment on IANA section - IANA is a mechanical operatio= n. Can't use normative language. Talk to Michelle and the IANA people, to s= ee what they can really do. Provide extremely clear guidance. >> -Believe updated text addresses that. >> -What is the base policy - IETF consensus or greater. Add a note that no= t changing IETF policy. Updates RFC3575, or not? >> -Need to state and be clear if policy is updated. >> -Alan to prepare next version - will come out late this week or early ne= xt week. >> >> ********************************************************************* >> 6.Network Access Identifier, Alan DeKok >> -http://tools.ietf.org/html/draft-dekok-radext-nai-01 >> -See http://www.ietf.org/proceedings/82/slides/radext-4.ppt >> -Review rationale for the proposal (why") DNS affects EAP and RADIUS - w= hy? >> -Is there a Unicode 3.1 dependency here? On a reading of 4284, unassigne= d code points are forbidden. >> -Cannot use a codepoint newer than 3.2. >> -DNS look-up required separate conversion. Do DNS protocol requirements = to turn string into something acceptable to DNS. >> -No one implements any of the requirements of RFC 4282! Rather, treat us= ername field as an opaque blob. 4284 is blocking progress - abfab documents= require use of nai, but 4282 requirements cannot be used. >> -Sam Hartman: Dependency in abfab on 4282 - 1 is a bug, will be removed = in abfab; the second - need a "username" and "realm" item. Disagree that 42= 84 is blocking abfab. But needs to be updated anyway. >> -Stefan Winter:Dynamic Discovery draft went through the same process. >> -Alan Dekok:Some operating systems don't send UTF-8 characters. More=20 >> reason to use nai-bis >> -2 distinct questions - 1 to get rid of what should never have been ther= e in the future. 2 to deal with internationalization questions.in RADIUS. C= ould get rid of 4282 as a first step, then address internationalization, EA= P. >> -AD: Clarify - is the request that 4282 as historical/harmful, and 4282-= bis on RADEXT work plan? >> -Stop the confusion first - encoding out of scope. >> -Stefan Winter: Is anonymization still there? "Left part" blank. Is it s= till in? Need to check - believe it is valuable. >> -Chair: hearing consensus to work on this. Poll: Killing 4282 a good th= ing? 10 - yes, 0-no. Strong consensus to put a document out, put on the mai= ling list to confirm. Discuss on the mailing list the scope of 4284 -no-lon= ger-applicable-versus internationalization. >> -Adopt Allan's document? Other approach? To discuss on mailing list. Sa= m to create text in abfab to claify purpose of 4282. >> >> ********************************************************************* >> 7.Next Steps: WG Chairs& ADs (15 minutes) -Chair summarizes next=20 >> steps re: updating the charter and what was agreed in the meeting. >> -Chair reviews current goals and milestones, updates: >> -Update IPv6 access to 2011 Dec >> -Radius over DTSL - update to 2012 March -RADIUS Cryptoagility -=20 >> update to early 2012, or March 2012. >> -Extended attributes - update to March 2012 -IEEE 802.11 attributes -=20 >> update to June 2012 -Dynamic Discovery - DIME version published,=20 >> March >> 2012 -RADIUS accounting - Sept 2012 >> -4284 bis - March 2012 for near term deprecation of 4284, - will be 2 di= fferent milestones, one for near term, one for longer term. >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >=20 > _______________________________________________ > 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 >=20 >=20 From radext-bounces@ietf.org Tue Nov 15 02:30:25 2011 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 72ED811E823F; Tue, 15 Nov 2011 02:30:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321353025; bh=B/CrIQ60lXVS5YHn8sdkpDdIHHKZ2sYVfQLeRdRwvAE=; h=From:To:Date:Message-ID:References: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=ygj5e7JQ2Juqr7Zwcbr2BXrNnJq/bi4bXdUtYlMl6t1SoCrNOqeITWRBoOXtuWWIl ajJ0GLxwxo24GJ3n7gpxZM1PWa32vX2/dQKOPRKspEwUzuCWXghf3uHdGZO5L0uyuN 7d1Kd738ADmT8BFm/tXXSpp+R9KQyc6mV19Ig0Io= 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 E98E411E823F for ; Tue, 15 Nov 2011 02:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.465 X-Spam-Level: X-Spam-Status: No, score=-104.465 tagged_above=-999 required=5 tests=[AWL=-1.466, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4, 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 vKzG2mwnFfBc for ; Tue, 15 Nov 2011 02:30:22 -0800 (PST) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDFD11E823E for ; Tue, 15 Nov 2011 02:30:22 -0800 (PST) Received: from G5W2206G.americas.hpqcorp.net (g5w2206g.atlanta.hp.com [16.228.43.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0027.austin.hp.com (Postfix) with ESMTPS id 19F72382CB; Tue, 15 Nov 2011 10:30:22 +0000 (UTC) Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G5W2206G.americas.hpqcorp.net (16.228.43.185) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 15 Nov 2011 10:29:39 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Tue, 15 Nov 2011 10:29:38 +0000 From: "Sanchez, Mauricio (HP Networking)" To: Alan DeKok Date: Tue, 15 Nov 2011 10:29:35 +0000 Thread-Topic: [radext] RADEXT @ IETF82: Draft meeting notes Thread-Index: AcyjgRYT39lzr54VTVGcneS2CGJglAAAEA5Q Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE1980@GVW0671EXC.americas.hpqcorp.net> References: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE1978@GVW0671EXC.americas.hpqcorp.net> <4EC233BE.6090302@wierenga.net> <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE197E@GVW0671EXC.americas.hpqcorp.net> <4EC23E58.3080008@deployingradius.com> In-Reply-To: <4EC23E58.3080008@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT @ IETF82: Draft meeting notes 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 You get a gold star. Master copy updated. Thanks, MS -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Tuesday, November 15, 2011 6:27 PM To: Sanchez, Mauricio (HP Networking) Cc: radext@ietf.org Subject: Re: [radext] RADEXT @ IETF82: Draft meeting notes Sanchez, Mauricio (HP Networking) wrote: > It was a small test to see whether people actually read the notes. You passed. I'm referred to as "Allan". A reference to 4284 should be changed to 4282. "claify" to "clarify" Do I get a cookie? > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On > Behalf Of Klaas Wierenga > Sent: Tuesday, November 15, 2011 5:41 PM > To: radext@ietf.org > Subject: Re: [radext] RADEXT @ IETF82: Draft meeting notes > > On 11/15/11 10:25 AM, Sanchez, Mauricio (HP Networking) wrote: >> Below are the draft notes for our meeting at IETF 82. Any corrections/modifications welcome. > > no biggie, but see below > >> -MS >> >> >> -------------------------------------------------------------- >> >> RADEXT WG Minutes >> IETF 82 >> Taipei, Taiwan >> Monday, November 14, 2011 >> Meeting started 9:02AM and ended 10:32AM. Approximately 17 >> individuals in meeting >> >> Chairs: >> Jouni Korhonen Mauricio >> Sanchez >> >> AD: >> Dan Romascanu >> >> >> 1.Preliminaries >> -Chair asked for jabber scribes (Stefan Winter) and note takers (Dorothy Stanley, Aruba Networks volunteers). >> -Chair reviews the agenda. No proposed changes to agenda as shown >> below -WG Goals/Milestones status -Chair reviewed status of documents >> that have been published, that are waiting for write-up, that are in >> last call, in >> >> progress, under review as WG item, Interesting work outside of current charter. >> -Are there any volunteers to shepherd the TLS encryption for RADIUS? >> Will put a call out on the list, if no volunteers, >> >> one of chairs will volunteer. >> -Will another last call be required after the current one for RADIUS attributes draft? To be determined. >> -RADIUS over DTLS - Allan will work on to advance. >> -NAI-based peer discovery - planned to align with RFC, RFC now >> published -IEEE 802 attributes - Bernard picking the draft up again, adopt as a WG item, make the draft active again. >> -NAI - Allan working on it, will discuss changes, and consider >> adopting as a work item >> -2 drafts for RADIUS accounting >> >> >> ********************************************************** >> >> 2. RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec >> -http://tools.ietf.org/html/draft-ietf-radext-ipv6-access >> -See http://www.ietf.org/proceedings/82/slides/radext-1.ppt >> -Leaf Yeh: How is the use case for DHCP addressed? >> -Woj Dec: Attributes for name pool - DHCP. >> -Woj Dec:Next step is to submit next version with editorial comments, corrections. >> -Leaf Yeh:Question on name of pool on the mailing list. >> -Woj Dec: Interpret pool names as such. Solution is to have a different attribute for the pool - stateful-ipv6-address- pool-attribute. Format is the same, but is different attributes; one for local, one for delegated. >> -Leaf Yeh: Suggests one pool name for all addresses - need to determine how to use the names. Or create complex pool of all attributes. >> -Woj Dec:Current conclusion is not to do anything. >> -Woj Dec:If use existing attribute, - server has to interpret the pool name as belonging to a specific type. >> -Bernard Aboba: Roaming deployments - may use a pool name, need to make sure you have same behavior across providers. Need to be explicit, so don't have chaos, can debug issues. >> -Chair: Consensus is that the current attribute and semantics are >> necessary to not introduce ambiguity >> >> ************************************************************ >> 3. RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh >> -http://tools.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01. >> t xt -See http://www.ietf.org/proceedings/82/slides/radext-2.pptx >> -Describe difference between version 6 and version 4. >> -Summary of requirements, IDs, network scenario, attribute design (8 >> new attributes), enhanced design -Stefan Winter: Use TLV encoding as in extended attributes draft - everything on one attribute. >> -Leaf Yeh: Still not sure about container attribute (Stefan Winter >> draft addresses) -Leaf Yeh: Does this deserve to be a WG item? Seem to have clear requirements from the industry. >> -Stefan Winter: Concern - have many drafts on this topic, they seem to die out for lack of interest, then a variation appears. > ^^^^^^^^ I think that was me > >> -AD:Why not get together and resolve differences, and come back with a single proposal. What is the benefit of coming up with yet another proposal? >> -Leaf Yeh:In last meeting (Quebec), didn't know how to define a new attribute using the extensions. Got feedback on the design. >> -Stefan Winters: Are you saying that extended attribute is not the right way? > ^^^^^^^^ > ditto > >> -Leaf Yeh: Don't know. Can be done with traditional attribute design.Don't disagree. Thought that we as a group came up with better ways of doing this. Would like to follow-up with the "fancy accounting" method is not used. >> -Stefan Winter:Distinguish between requirements and design. >> -Multiple design approaches can solve the problem. >> -Alan DeKok:Extended attributes draft was created for a reason - use complex attributes with a lot of content; define container, avoid stuffing several items into one attribute. Some of proposed designs still use complex encoding. >> -Stefan Winter:Do you accept design 4? >> -Leaf Yeh:No includes too much complexity - better to use explicit format. >> -TLV nesting and grouping (Design 3) - what is the benefit of this design? >> -Benefit is that it uses the framework that the extended attribute defines. Reusable code. >> -Also need new sub-attributes defined here. >> -Need one set of new attributes and one type descriptor regardless. Use parser for extended attributes. >> -In design 4 - use one field to introduce field type. Complexity is the same. >> -Need to write a parser for this specifically. Better to use the framework. >> -There can be multiple instances of attributes. In that point, the two are the same. In design 3, don't need another parser. >> -Alan notes that Design 3 slide is wrong - attributes can be in any order. More flexible framework, just extract attributes, In proposal 4, have to care about the order of the attributes. In Design 3, can leave out some sub-attributes. >> -Chair: Do you support this work in RADEXT? >> -Is this needed for IPv4? Traffic type code can indicate the IPv4/IPv6 type. >> -Should I migrate all IPv4 to this new format? BBF request uses original attributes for past traffic. >> -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. >> -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: 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. >> -AD:Will this be discussed at the Paris meeting? >> -Chair:Yes, not choosing a proposal today; legitimize the work item in the charter as a first step. >> >> ****************************************************************** >> 4.RADIUS Attributes for IEEE 802 Networks, Bernard Aboba >> -http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt >> -http://www.ietf.org/proceedings/82/slides/radext-5.ppt >> -Bernard: Purpose to add attributes required in 11r, and 802.1X key usage. >> -Call for adoption was issued Nov 13, 2007. Yesterday was the 4 year anniversary. >> -Does it need more time to ripen (like fine wines)? >> -Should have moved a little faster - others adopted parts. >> -What kind of attributes - from extended attributes? If move forward, ask this. >> -Need to look at use cases for attributes also. First step is to adopt. >> -EMU has finished WGLC on EAP lower layer. EMU would like input on collapsing lower layers together. Differences between 802.1X-2004 and 802.1X-2010. >> -For the adoption of this document. If wait for it to be completely right, might be a long while. Also 11u extensions too. >> -Unfortunate that document didn't advance - chair was side-tracked, but don't want chair's pushing their own agenda. >> -Chair: Is there interest to adopt this document to address milestone: 12-yes, 0-no. >> -Take to mailing list to confirm. Strong consensus to move forward. >> >> ******************************************************************** >> 5.RADIUS Protocol Extensions, Alan DeKok >> -http://tools.ietf.org/html/draft-ietf-radext-radius-extensions >> -See http://www.ietf.org/proceedings/82/slides/radext-3.ppt >> -Review of status, implementations (test vectors available - please >> use and review) -Comment on IANA section - IANA is a mechanical operation. Can't use normative language. Talk to Michelle and the IANA people, to see what they can really do. Provide extremely clear guidance. >> -Believe updated text addresses that. >> -What is the base policy - IETF consensus or greater. Add a note that not changing IETF policy. Updates RFC3575, or not? >> -Need to state and be clear if policy is updated. >> -Alan to prepare next version - will come out late this week or early next week. >> >> ********************************************************************* >> 6.Network Access Identifier, Alan DeKok >> -http://tools.ietf.org/html/draft-dekok-radext-nai-01 >> -See http://www.ietf.org/proceedings/82/slides/radext-4.ppt >> -Review rationale for the proposal (why") DNS affects EAP and RADIUS - why? >> -Is there a Unicode 3.1 dependency here? On a reading of 4284, unassigned code points are forbidden. >> -Cannot use a codepoint newer than 3.2. >> -DNS look-up required separate conversion. Do DNS protocol requirements to turn string into something acceptable to DNS. >> -No one implements any of the requirements of RFC 4282! Rather, treat username field as an opaque blob. 4284 is blocking progress - abfab documents require use of nai, but 4282 requirements cannot be used. >> -Sam Hartman: Dependency in abfab on 4282 - 1 is a bug, will be removed in abfab; the second - need a "username" and "realm" item. Disagree that 4284 is blocking abfab. But needs to be updated anyway. >> -Stefan Winter:Dynamic Discovery draft went through the same process. >> -Alan Dekok:Some operating systems don't send UTF-8 characters. More >> reason to use nai-bis >> -2 distinct questions - 1 to get rid of what should never have been there in the future. 2 to deal with internationalization questions.in RADIUS. Could get rid of 4282 as a first step, then address internationalization, EAP. >> -AD: Clarify - is the request that 4282 as historical/harmful, and 4282-bis on RADEXT work plan? >> -Stop the confusion first - encoding out of scope. >> -Stefan Winter: Is anonymization still there? "Left part" blank. Is it still in? Need to check - believe it is valuable. >> -Chair: hearing consensus to work on this. Poll: Killing 4282 a good thing? 10 - yes, 0-no. Strong consensus to put a document out, put on the mailing list to confirm. Discuss on the mailing list the scope of 4284 -no-longer-applicable-versus internationalization. >> -Adopt Allan's document? Other approach? To discuss on mailing list. Sam to create text in abfab to claify purpose of 4282. >> >> ********************************************************************* >> 7.Next Steps: WG Chairs& ADs (15 minutes) -Chair summarizes next >> steps re: updating the charter and what was agreed in the meeting. >> -Chair reviews current goals and milestones, updates: >> -Update IPv6 access to 2011 Dec >> -Radius over DTSL - update to 2012 March -RADIUS Cryptoagility - >> update to early 2012, or March 2012. >> -Extended attributes - update to March 2012 -IEEE 802.11 attributes - >> update to June 2012 -Dynamic Discovery - DIME version published, >> March >> 2012 -RADIUS accounting - Sept 2012 >> -4284 bis - March 2012 for near term deprecation of 4284, - will be 2 different milestones, one for near term, one for longer term. >> _______________________________________________ >> 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 > _______________________________________________ > 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 Tue Nov 15 02:48:32 2011 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 D644321F8E8A; Tue, 15 Nov 2011 02:48:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321354112; bh=wzj8839LKrqLB3D/6+Y6dAHbdXFhVN6fE36ynVy2UFo=; 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=No/hpgICm6m5w7gE05ADaiHM5Xl0gdjtn1NDGHyPyFzEEc3Lj1x/2tqlX11MPMG9t 2TyEx1afMd97sAtYVQVcvRvQwUczWs0cDAKzYROaa+NHab0nR0CKyFyALrApjwCMWE IZKOYfoyCwIzTyJyZa+cH1IjG/Q0xDddMVIUaGwI= 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 69A8321F8E8D for ; Tue, 15 Nov 2011 02:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.421 X-Spam-Level: X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 MnVrf7Gf-7lU for ; Tue, 15 Nov 2011 02:48:31 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id E963E21F8E8A for ; Tue, 15 Nov 2011 02:48:30 -0800 (PST) Message-ID: <4EC24364.9000505@deployingradius.com> Date: Tue, 15 Nov 2011 11:48:04 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Sanchez, Mauricio (HP Networking)" References: <4EC0DD6F.4030405@deployingradius.com> <302514528.2606057.1321274255818.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE197F@GVW0671EXC.americas.hpqcorp.net> In-Reply-To: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE197F@GVW0671EXC.americas.hpqcorp.net> X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" , "David B. Nelson" , Stefan Winter Subject: Re: [radext] Accounting for traffic classes 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 Sanchez, Mauricio (HP Networking) wrote: > Alan, > When did you say you'd have a new version of the extensions draft completed? I just submitted it. The IANA section has been extended as per Bernard's comments. It now gives detailed instructions for every aspect of attribute allocation. It references 3575, too. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Tue Nov 15 02:48:31 2011 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 69A8321F8E8D for ; Tue, 15 Nov 2011 02:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.421 X-Spam-Level: X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 MnVrf7Gf-7lU for ; Tue, 15 Nov 2011 02:48:31 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id E963E21F8E8A for ; Tue, 15 Nov 2011 02:48:30 -0800 (PST) Message-ID: <4EC24364.9000505@deployingradius.com> Date: Tue, 15 Nov 2011 11:48:04 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Sanchez, Mauricio (HP Networking)" References: <4EC0DD6F.4030405@deployingradius.com> <302514528.2606057.1321274255818.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE197F@GVW0671EXC.americas.hpqcorp.net> In-Reply-To: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE197F@GVW0671EXC.americas.hpqcorp.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "David B. Nelson" , Stefan Winter Subject: Re: [radext] Accounting for traffic classes 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, 15 Nov 2011 10:48:31 -0000 Sanchez, Mauricio (HP Networking) wrote: > Alan, > When did you say you'd have a new version of the extensions draft completed? I just submitted it. The IANA section has been extended as per Bernard's comments. It now gives detailed instructions for every aspect of attribute allocation. It references 3575, too. Alan DeKok. From internet-drafts@ietf.org Tue Nov 15 02:48:53 2011 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 375DA21F8E94; Tue, 15 Nov 2011 02:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 Ooexsw+j+UOh; Tue, 15 Nov 2011 02:48:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE4121F8E8A; Tue, 15 Nov 2011 02:48:52 -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.63 Message-ID: <20111115104852.7367.58777.idtracker@ietfa.amsl.com> Date: Tue, 15 Nov 2011 02:48:52 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radius-extensions-03.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, 15 Nov 2011 10:48:53 -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 : Remote Authentication Dial In User Service (RADIUS) Prot= ocol Extensions Author(s) : Alan DeKok Avi Lior Filename : draft-ietf-radext-radius-extensions-03.txt Pages : 58 Date : 2011-11-15 The Remote Authentication Dial In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit attribute type space. In addition, experience shows a growing need for complex grouping, along with attributes which can carry more than 253 octets of data. This document defines changes to RADIUS which address all of the above problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-radius-extensions-03.= 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-radius-extensions-03.t= xt From radext-bounces@ietf.org Tue Nov 15 02:48:54 2011 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 43FF221F8E8A; Tue, 15 Nov 2011 02:48:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321354134; bh=TBBunpcVWMpYTNVRxJlsJW/1UaDXLqEgbcD4Q6/dK2A=; 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=TTC81F3hRI4eqh0CkI6LsjqHPUVp9FNkkXgti4pTNHU0JkL+YahHkatLjsh6z5oRx z3XA72zZMTgeXVhN/ODomHA2M1P7fMz2ouG+KSG7qqnGkpG5XIy/eZ1Gtj89DuAF3F BaEmnp80VJqIqbRGjq+cRBoeCIAZjrVG+mpgvVFU= 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 375DA21F8E94; Tue, 15 Nov 2011 02:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 Ooexsw+j+UOh; Tue, 15 Nov 2011 02:48:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE4121F8E8A; Tue, 15 Nov 2011 02:48:52 -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.63 Message-ID: <20111115104852.7367.58777.idtracker@ietfa.amsl.com> Date: Tue, 15 Nov 2011 02:48:52 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radius-extensions-03.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 : Remote Authentication Dial In User Service (RADIUS) Protocol Extensions Author(s) : Alan DeKok Avi Lior Filename : draft-ietf-radext-radius-extensions-03.txt Pages : 58 Date : 2011-11-15 The Remote Authentication Dial In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit attribute type space. In addition, experience shows a growing need for complex grouping, along with attributes which can carry more than 253 octets of data. This document defines changes to RADIUS which address all of the above problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-radius-extensions-03.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-radius-extensions-03.txt _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From jouni.nospam@gmail.com Tue Nov 15 17:39:23 2011 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 3F20711E813F for ; Tue, 15 Nov 2011 17:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 QM3VLUG4wPOS for ; Tue, 15 Nov 2011 17:39:22 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC7C11E813B for ; Tue, 15 Nov 2011 17:39:19 -0800 (PST) Received: by ggnr5 with SMTP id r5so3380432ggn.31 for ; Tue, 15 Nov 2011 17:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=kucBYpBw7NfAb2pPknT7V4XjURa3y6TbMTqlHKpaEcE=; b=hn/mcFKWgvCnASZ9kHeW8Led779pTG0RcZSxxuefqX2WGL9wQYTv2QBV1/NDYL66Xq 3A0pTB05fu9ZudEQg1BuLI/UWoI2MAmiRIkplZmSsA2dKHiSdl5ldhR4nyR+K4/FkKYG iPnintOAr18xjsaEh4lQH1Bqt3z7pZR6DPqTo= Received: by 10.101.212.38 with SMTP id o38mr6872552anq.150.1321407559161; Tue, 15 Nov 2011 17:39:19 -0800 (PST) Received: from ?IPv6:2001:df8::80:226:bbff:fe18:6e9c? ([2001:df8:0:80:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id r4sm79925093anl.5.2011.11.15.17.39.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Nov 2011 17:39:18 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4EC2290F.10204@deployingradius.com> Date: Wed, 16 Nov 2011 03:39:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8E75211B-F5D6-4E7A-95E7-B25A7804B6BA@gmail.com> References: , <4EB0F497.1000104@deployingradius.com> <4EC2290F.10204@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.1084) Cc: Bernard Aboba , radext@ietf.org Subject: Re: [radext] About RFC4282 and its fate; was Re: RFC 4282 and RADIUS implementations (was abfab and SAML) 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, 16 Nov 2011 01:39:23 -0000 Alan, Thanks for elaborating this further.. Some more stuff inline. On Nov 15, 2011, at 10:55 AM, Alan DeKok wrote: > jouni korhonen wrote: >> I got a naive question (just as a concerned WG participant) regarding = the fate of RFC4282. NAIs are also used outside AAA protocols. One = particular domain that comes to my mind is mobility and mobile networks. = There are several systems that depend on RFC4282 (as a MUST) in non-AAA = signaling and then later may or may not relay that as-is to AAA = protocols. The good thing is that usually internationalization is not = really on the table yet in these systems but not that far either.=20 >=20 > Do you have a reference to a non-AAA use of 4282? =46rom what I've > seen, the NAIs are used by those systems in the context of RADIUS and > EAP. So they're really just RADIUS / EAP. >=20 >> So, what would be the net effect if we start fiddling with RFC4282? = Do we then also need to revisit bunch of other RFCs and especially look = into non-IETF specifications..? >=20 > I don't think so. The reason is that these specification depend on > user@realm format. They do *not* depend on the ToAscii converted form > of the i18n realm. Right. But that is mostly a fortunate coincidence. >=20 > Some documents depend on the "decorated" format of the NAI as > discussed in Section 2.7 of 4282. I'm not aware that this practice is > widespread. >=20 > i.e. realm decorations *are* widespread. Standardized formats are > *not* widespread. There are a large variety of formats used in = practice. RFC5729 is referenced/mandated by 3GPP in the context of RFC4282 NAI = decoration. Though, i do not know whether it is used in real deployments = today.. > My take is that a 4282bis will have minimal impact on existing > specifications and practices. This is because the specifications and > practices do *not* depend on the practices of 4282 which have been > removed in 4282bis. >=20 > A quick pass through documents yields: >=20 > 4283 - NAI is user@realm >=20 > 4284 - NAI is user@realm, allows for "decoration" for source routing >=20 > 5113 - allows for decorated NAI >=20 > 5421 - name / password is processed as per 4282. >=20 > 5433 - identifiers are NAIs >=20 > 5446 - references 4282 >=20 > 5677 - identifier is FQDN *or* NAI >=20 > 5687 - references 4282 >=20 > 6155 - says that the NAI allows non-UTF8 realms. Non-UTF-8 characters > are escaped by \HEXHEX. They define a mapping from this format to > the 4282 format. This appears to be a misunderstanding, as 4282 > requires that the "realm" portion be UTF-8. Also RFC5149, RFC5729. Then bunch of e.g. 3GPP(2) specs but they = basically use RFC4282 in EAP/RADIUS/Diameter context.=20 - Jouni From radext-bounces@ietf.org Tue Nov 15 17:39:24 2011 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 9DA1C11E813F; Tue, 15 Nov 2011 17:39:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1321407564; bh=9QnT6SBw2XGKqtF/UxvWBjLs2HUTkThG1CleAd/kgNg=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=CFXhH5e6+Hd8nPg5Bcs0aBapNVTVSdgoJghASW8fuQNN1gn8t3DqLq+HhNqUxX//5 f5lHacpbM7GeV5k7eBj3enUIKDEI96vMerokcThnnVZY/s98Xy3vZ/OhBDlUkRNNrE uP0Uh/7jIxe0ZvctPkaTvHjrIGG4PG3Vda9YaBLo= 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 3F20711E813F for ; Tue, 15 Nov 2011 17:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 QM3VLUG4wPOS for ; Tue, 15 Nov 2011 17:39:22 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC7C11E813B for ; Tue, 15 Nov 2011 17:39:19 -0800 (PST) Received: by ggnr5 with SMTP id r5so3380432ggn.31 for ; Tue, 15 Nov 2011 17:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=kucBYpBw7NfAb2pPknT7V4XjURa3y6TbMTqlHKpaEcE=; b=hn/mcFKWgvCnASZ9kHeW8Led779pTG0RcZSxxuefqX2WGL9wQYTv2QBV1/NDYL66Xq 3A0pTB05fu9ZudEQg1BuLI/UWoI2MAmiRIkplZmSsA2dKHiSdl5ldhR4nyR+K4/FkKYG iPnintOAr18xjsaEh4lQH1Bqt3z7pZR6DPqTo= Received: by 10.101.212.38 with SMTP id o38mr6872552anq.150.1321407559161; Tue, 15 Nov 2011 17:39:19 -0800 (PST) Received: from ?IPv6:2001:df8::80:226:bbff:fe18:6e9c? ([2001:df8:0:80:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id r4sm79925093anl.5.2011.11.15.17.39.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Nov 2011 17:39:18 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) From: jouni korhonen In-Reply-To: <4EC2290F.10204@deployingradius.com> Date: Wed, 16 Nov 2011 03:39:14 +0200 Message-Id: <8E75211B-F5D6-4E7A-95E7-B25A7804B6BA@gmail.com> References: , <4EB0F497.1000104@deployingradius.com> <4EC2290F.10204@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.1084) Cc: Bernard Aboba , radext@ietf.org Subject: Re: [radext] About RFC4282 and its fate; was Re: RFC 4282 and RADIUS implementations (was abfab and SAML) 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, Thanks for elaborating this further.. Some more stuff inline. On Nov 15, 2011, at 10:55 AM, Alan DeKok wrote: > jouni korhonen wrote: >> I got a naive question (just as a concerned WG participant) regarding the fate of RFC4282. NAIs are also used outside AAA protocols. One particular domain that comes to my mind is mobility and mobile networks. There are several systems that depend on RFC4282 (as a MUST) in non-AAA signaling and then later may or may not relay that as-is to AAA protocols. The good thing is that usually internationalization is not really on the table yet in these systems but not that far either. > > Do you have a reference to a non-AAA use of 4282? From what I've > seen, the NAIs are used by those systems in the context of RADIUS and > EAP. So they're really just RADIUS / EAP. > >> So, what would be the net effect if we start fiddling with RFC4282? Do we then also need to revisit bunch of other RFCs and especially look into non-IETF specifications..? > > I don't think so. The reason is that these specification depend on > user@realm format. They do *not* depend on the ToAscii converted form > of the i18n realm. Right. But that is mostly a fortunate coincidence. > > Some documents depend on the "decorated" format of the NAI as > discussed in Section 2.7 of 4282. I'm not aware that this practice is > widespread. > > i.e. realm decorations *are* widespread. Standardized formats are > *not* widespread. There are a large variety of formats used in practice. RFC5729 is referenced/mandated by 3GPP in the context of RFC4282 NAI decoration. Though, i do not know whether it is used in real deployments today.. > My take is that a 4282bis will have minimal impact on existing > specifications and practices. This is because the specifications and > practices do *not* depend on the practices of 4282 which have been > removed in 4282bis. > > A quick pass through documents yields: > > 4283 - NAI is user@realm > > 4284 - NAI is user@realm, allows for "decoration" for source routing > > 5113 - allows for decorated NAI > > 5421 - name / password is processed as per 4282. > > 5433 - identifiers are NAIs > > 5446 - references 4282 > > 5677 - identifier is FQDN *or* NAI > > 5687 - references 4282 > > 6155 - says that the NAI allows non-UTF8 realms. Non-UTF-8 characters > are escaped by \HEXHEX. They define a mapping from this format to > the 4282 format. This appears to be a misunderstanding, as 4282 > requires that the "realm" portion be UTF-8. Also RFC5149, RFC5729. Then bunch of e.g. 3GPP(2) specs but they basically use RFC4282 in EAP/RADIUS/Diameter context. - Jouni _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext