From aland@deployingradius.com Sat Mar 3 23:10:34 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155B721F85A3; Sat, 3 Mar 2012 23:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 pYWHoNrabFah; Sat, 3 Mar 2012 23:10:33 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 372BA21F8516; Sat, 3 Mar 2012 23:10:33 -0800 (PST) Message-ID: <4F53154C.9060604@deployingradius.com> Date: Sun, 04 Mar 2012 08:10:04 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jim Schaad References: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> <4F4E03E3.8070006@um.es> <010601ccf987$409e0220$c1da0660$@augustcellars.com> In-Reply-To: <010601ccf987$409e0220$c1da0660$@augustcellars.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, abfab@ietf.org, 'Alejandro Perez Mendez' Subject: Re: [radext] [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 07:10:34 -0000 Jim Schaad wrote: > I have some comments on the draft. However first let me say that I know next to nothing about RADIX having only briefly read it a couple of times and having not yet worked with it to any extent. Reviews are always welcome. > 1. I think a discussion is in order about the issues of packing a radius message full in the presence of proxy intermediaries which might need room for adding and removing routing materials. I don't know how many proxies are keep local state as oppose to just filling up the message with Proxy-State items and thus need space on the way back. Also a discussion of removal and re-insertion of the T flag might be needed if the proxy fully assembles the message and then relays it in pieces. The simplest way to address that is to artificially lower the RADIUS maximum packet size, as seen by the client. > 2. The Overview in section 2 does not discuss the fact that a new set of state items might also added to the message. This changes the limit of how many bytes can be placed into the fragmented packets. Yes. > 3. nit - in para #3 of overview you use the word truncated and truncation. I think a better word set might be partitioned and partitioning. Also ensure that fragmentation is used strictly for the process in radius-extensions. I have not found any cases yet were it is not but will try and remember to look. > > 4. I am not sure if positioning of the more-data-pending packet is significant. The introduction says it comes last but nothing to that effect is said in section 3. > > 5. Section 6 implies that the order of items in a set of fragmented packets might need to be changed based on the ability of items to be in the packet. For example if the Access-Accept packet had been = Data1[M], Data2[M]...Data 10, User-Name, Service-Type[X], Framed-IP-Address the order would need to be changed in the original partitioning. This should be mentioned someplace other than just in the "examples" section. It implies that a general use piece of code to do this will need to have the table built in, and potentially extended as new items are added, rather than just being coded correctly in the specific packet type code. Attribute ordering is explicitly *not* required in RADIUS. > 6. What if any indications does a server have that the client will be able to deal with the partitioned message other than it will either fail or get confused depending on what set of attributes are in the first packet and what it needs and feels it can ignore. That's an open area for discussion. RADIUS doesn't have capability negotiation, so it's hard to do. Alan DeKok. From radext-bounces@ietf.org Sat Mar 3 23:10:36 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268AC21F85B5; Sat, 3 Mar 2012 23:10:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330845036; bh=UA2/PrIwig+Ic7p0Y1MfU7f2tVT8Is9nMlCSEZxquM4=; 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=kmA4ENhr9kqlzgE1dRqShv1qKFVqfukKxI8xvxJeAxPguggIREB3FeZn8+XL1SNL6 9pIL1EwR7Ez8KzpsJdWy/0t1KF8mbSrXqj88ZEKRtW9nqRt7t8Uiz9OeWQhbmbSS6s IV/cRHOJWNuskBN7yW04sDuezg531Y0TEET+BgpM= 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 155B721F85A3; Sat, 3 Mar 2012 23:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 pYWHoNrabFah; Sat, 3 Mar 2012 23:10:33 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 372BA21F8516; Sat, 3 Mar 2012 23:10:33 -0800 (PST) Message-ID: <4F53154C.9060604@deployingradius.com> Date: Sun, 04 Mar 2012 08:10:04 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jim Schaad References: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> <4F4E03E3.8070006@um.es> <010601ccf987$409e0220$c1da0660$@augustcellars.com> In-Reply-To: <010601ccf987$409e0220$c1da0660$@augustcellars.com> X-Enigmail-Version: 0.96.0 Cc: radext@ietf.org, abfab@ietf.org, 'Alejandro Perez Mendez' Subject: Re: [radext] [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Jim Schaad wrote: > I have some comments on the draft. However first let me say that I know next to nothing about RADIX having only briefly read it a couple of times and having not yet worked with it to any extent. Reviews are always welcome. > 1. I think a discussion is in order about the issues of packing a radius message full in the presence of proxy intermediaries which might need room for adding and removing routing materials. I don't know how many proxies are keep local state as oppose to just filling up the message with Proxy-State items and thus need space on the way back. Also a discussion of removal and re-insertion of the T flag might be needed if the proxy fully assembles the message and then relays it in pieces. The simplest way to address that is to artificially lower the RADIUS maximum packet size, as seen by the client. > 2. The Overview in section 2 does not discuss the fact that a new set of state items might also added to the message. This changes the limit of how many bytes can be placed into the fragmented packets. Yes. > 3. nit - in para #3 of overview you use the word truncated and truncation. I think a better word set might be partitioned and partitioning. Also ensure that fragmentation is used strictly for the process in radius-extensions. I have not found any cases yet were it is not but will try and remember to look. > > 4. I am not sure if positioning of the more-data-pending packet is significant. The introduction says it comes last but nothing to that effect is said in section 3. > > 5. Section 6 implies that the order of items in a set of fragmented packets might need to be changed based on the ability of items to be in the packet. For example if the Access-Accept packet had been = Data1[M], Data2[M]...Data 10, User-Name, Service-Type[X], Framed-IP-Address the order would need to be changed in the original partitioning. This should be mentioned someplace other than just in the "examples" section. It implies that a general use piece of code to do this will need to have the table built in, and potentially extended as new items are added, rather than just being coded correctly in the specific packet type code. Attribute ordering is explicitly *not* required in RADIUS. > 6. What if any indications does a server have that the client will be able to deal with the partitioned message other than it will either fail or get confused depending on what set of attributes are in the first packet and what it needs and feels it can ignore. That's an open area for discussion. RADIUS doesn't have capability negotiation, so it's hard to do. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From alex@um.es Mon Mar 5 00:02:38 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9C121F8542; Mon, 5 Mar 2012 00:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.057 X-Spam-Level: X-Spam-Status: No, score=-5.057 tagged_above=-999 required=5 tests=[AWL=-1.458, 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 y-1Dh4vhrU1r; Mon, 5 Mar 2012 00:02:36 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 6F90521F8559; Mon, 5 Mar 2012 00:02:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 16D9C5D4E4; Mon, 5 Mar 2012 09:02:35 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hu9MhqGaPLs9; Mon, 5 Mar 2012 09:02:34 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon13.um.es (Postfix) with ESMTPSA id 8D3A95D497; Mon, 5 Mar 2012 09:02:32 +0100 (CET) Message-ID: <4F547319.5040001@um.es> Date: Mon, 05 Mar 2012 09:02:33 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Alan DeKok References: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> <4F4E03E3.8070006@um.es> <010601ccf987$409e0220$c1da0660$@augustcellars.com> <4F53154C.9060604@deployingradius.com> In-Reply-To: <4F53154C.9060604@deployingradius.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: radext@ietf.org, Jim Schaad , abfab@ietf.org Subject: Re: [radext] [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 08:02:38 -0000 El 04/03/12 08:10, Alan DeKok escribió: > Jim Schaad wrote: >> I have some comments on the draft. However first let me say that I know next to nothing about RADIX having only briefly read it a couple of times and having not yet worked with it to any extent. > Reviews are always welcome. > >> 1. I think a discussion is in order about the issues of packing a radius message full in the presence of proxy intermediaries which might need room for adding and removing routing materials. I don't know how many proxies are keep local state as oppose to just filling up the message with Proxy-State items and thus need space on the way back. Also a discussion of removal and re-insertion of the T flag might be needed if the proxy fully assembles the message and then relays it in pieces. > The simplest way to address that is to artificially lower the RADIUS > maximum packet size, as seen by the client. Additionally, regarding the T flag removal/re-insertion comment, proxies are not allowed to perform RADIUS fragmentation on forwarded packets. It is a process performed end-to-end the RADIUS client and server. > >> 2. The Overview in section 2 does not discuss the fact that a new set of state items might also added to the message. This changes the limit of how many bytes can be placed into the fragmented packets. > Yes. > >> 3. nit - in para #3 of overview you use the word truncated and truncation. I think a better word set might be partitioned and partitioning. Also ensure that fragmentation is used strictly for the process in radius-extensions. I have not found any cases yet were it is not but will try and remember to look. >> >> 4. I am not sure if positioning of the more-data-pending packet is significant. The introduction says it comes last but nothing to that effect is said in section 3. >> >> 5. Section 6 implies that the order of items in a set of fragmented packets might need to be changed based on the ability of items to be in the packet. For example if the Access-Accept packet had been = Data1[M], Data2[M]...Data 10, User-Name, Service-Type[X], Framed-IP-Address the order would need to be changed in the original partitioning. This should be mentioned someplace other than just in the "examples" section. It implies that a general use piece of code to do this will need to have the table built in, and potentially extended as new items are added, rather than just being coded correctly in the specific packet type code. > Attribute ordering is explicitly *not* required in RADIUS. > >> 6. What if any indications does a server have that the client will be able to deal with the partitioned message other than it will either fail or get confused depending on what set of attributes are in the first packet and what it needs and feels it can ignore. > That's an open area for discussion. RADIUS doesn't have capability > negotiation, so it's hard to do. > > Alan DeKok. From radext-bounces@ietf.org Mon Mar 5 00:02:40 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629AB21F8559; Mon, 5 Mar 2012 00:02:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1330934560; bh=zuVfxWIA50ETETZC5STfhfzZZfRMKYOha1jgJjI9aEo=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=oBEGjNqu23eBd45Xio86Sse1lR8duukIt+Aiy3kxL8faEHy5DVeQTEotWMqHLf7Rg JkSFEw0vsJC71eFka6RArH0JgItULCLmVlHMA0kcCZMWGoFet7JqieX49Y77IdYAJY OAJxC3npzr31S8gZB6xIf9PX8xPxoZlyVS7L0be4= 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 5A9C121F8542; Mon, 5 Mar 2012 00:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.057 X-Spam-Level: X-Spam-Status: No, score=-5.057 tagged_above=-999 required=5 tests=[AWL=-1.458, 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 y-1Dh4vhrU1r; Mon, 5 Mar 2012 00:02:36 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 6F90521F8559; Mon, 5 Mar 2012 00:02:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 16D9C5D4E4; Mon, 5 Mar 2012 09:02:35 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hu9MhqGaPLs9; Mon, 5 Mar 2012 09:02:34 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon13.um.es (Postfix) with ESMTPSA id 8D3A95D497; Mon, 5 Mar 2012 09:02:32 +0100 (CET) Message-ID: <4F547319.5040001@um.es> Date: Mon, 05 Mar 2012 09:02:33 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Alan DeKok References: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> <4F4E03E3.8070006@um.es> <010601ccf987$409e0220$c1da0660$@augustcellars.com> <4F53154C.9060604@deployingradius.com> In-Reply-To: <4F53154C.9060604@deployingradius.com> Cc: radext@ietf.org, Jim Schaad , abfab@ietf.org Subject: Re: [radext] [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org CgpFbCAwNC8wMy8xMiAwODoxMCwgQWxhbiBEZUtvayBlc2NyaWJpw7M6Cj4gSmltIFNjaGFhZCB3 cm90ZToKPj4gSSBoYXZlIHNvbWUgY29tbWVudHMgb24gdGhlIGRyYWZ0LiAgSG93ZXZlciBmaXJz dCBsZXQgbWUgc2F5IHRoYXQgSSBrbm93IG5leHQgdG8gbm90aGluZyBhYm91dCBSQURJWCBoYXZp bmcgb25seSBicmllZmx5IHJlYWQgaXQgYSBjb3VwbGUgb2YgdGltZXMgYW5kIGhhdmluZyBub3Qg eWV0IHdvcmtlZCB3aXRoIGl0IHRvIGFueSBleHRlbnQuCj4gICAgUmV2aWV3cyBhcmUgYWx3YXlz IHdlbGNvbWUuCj4KPj4gMS4gIEkgdGhpbmsgYSBkaXNjdXNzaW9uIGlzIGluIG9yZGVyIGFib3V0 IHRoZSBpc3N1ZXMgb2YgcGFja2luZyBhIHJhZGl1cyBtZXNzYWdlIGZ1bGwgaW4gdGhlIHByZXNl bmNlIG9mIHByb3h5IGludGVybWVkaWFyaWVzIHdoaWNoIG1pZ2h0IG5lZWQgcm9vbSBmb3IgYWRk aW5nIGFuZCByZW1vdmluZyByb3V0aW5nIG1hdGVyaWFscy4gIEkgZG9uJ3Qga25vdyBob3cgbWFu eSBwcm94aWVzIGFyZSBrZWVwIGxvY2FsIHN0YXRlIGFzIG9wcG9zZSB0byBqdXN0IGZpbGxpbmcg dXAgdGhlIG1lc3NhZ2Ugd2l0aCBQcm94eS1TdGF0ZSBpdGVtcyBhbmQgdGh1cyBuZWVkIHNwYWNl IG9uIHRoZSB3YXkgYmFjay4gIEFsc28gYSBkaXNjdXNzaW9uIG9mIHJlbW92YWwgYW5kIHJlLWlu c2VydGlvbiBvZiB0aGUgVCBmbGFnIG1pZ2h0IGJlIG5lZWRlZCBpZiB0aGUgcHJveHkgZnVsbHkg YXNzZW1ibGVzIHRoZSBtZXNzYWdlIGFuZCB0aGVuIHJlbGF5cyBpdCBpbiBwaWVjZXMuCj4gICAg VGhlIHNpbXBsZXN0IHdheSB0byBhZGRyZXNzIHRoYXQgaXMgdG8gYXJ0aWZpY2lhbGx5IGxvd2Vy IHRoZSBSQURJVVMKPiBtYXhpbXVtIHBhY2tldCBzaXplLCBhcyBzZWVuIGJ5IHRoZSBjbGllbnQu CgpBZGRpdGlvbmFsbHksIHJlZ2FyZGluZyB0aGUgVCBmbGFnIHJlbW92YWwvcmUtaW5zZXJ0aW9u IGNvbW1lbnQsIHByb3hpZXMgCmFyZSBub3QgYWxsb3dlZCB0byBwZXJmb3JtIFJBRElVUyBmcmFn bWVudGF0aW9uIG9uIGZvcndhcmRlZCBwYWNrZXRzLiBJdCAKaXMgYSBwcm9jZXNzIHBlcmZvcm1l ZCBlbmQtdG8tZW5kIHRoZSBSQURJVVMgY2xpZW50IGFuZCBzZXJ2ZXIuCgo+Cj4+IDIuICAgVGhl IE92ZXJ2aWV3IGluIHNlY3Rpb24gMiBkb2VzIG5vdCBkaXNjdXNzIHRoZSBmYWN0IHRoYXQgYSBu ZXcgc2V0IG9mIHN0YXRlIGl0ZW1zIG1pZ2h0IGFsc28gYWRkZWQgdG8gdGhlIG1lc3NhZ2UuICBU aGlzIGNoYW5nZXMgdGhlIGxpbWl0IG9mIGhvdyBtYW55IGJ5dGVzIGNhbiBiZSBwbGFjZWQgaW50 byB0aGUgZnJhZ21lbnRlZCBwYWNrZXRzLgo+ICAgIFllcy4KPgo+PiAzLiBuaXQgLSBpbiBwYXJh ICMzIG9mIG92ZXJ2aWV3IHlvdSB1c2UgdGhlIHdvcmQgdHJ1bmNhdGVkIGFuZCB0cnVuY2F0aW9u LiAgSSB0aGluayBhIGJldHRlciB3b3JkIHNldCBtaWdodCBiZSBwYXJ0aXRpb25lZCBhbmQgcGFy dGl0aW9uaW5nLiAgQWxzbyBlbnN1cmUgdGhhdCBmcmFnbWVudGF0aW9uIGlzIHVzZWQgc3RyaWN0 bHkgZm9yIHRoZSBwcm9jZXNzIGluIHJhZGl1cy1leHRlbnNpb25zLiAgSSBoYXZlIG5vdCBmb3Vu ZCBhbnkgY2FzZXMgeWV0IHdlcmUgaXQgaXMgbm90IGJ1dCB3aWxsIHRyeSBhbmQgcmVtZW1iZXIg dG8gbG9vay4KPj4KPj4gNC4gIEkgYW0gbm90IHN1cmUgaWYgcG9zaXRpb25pbmcgb2YgdGhlIG1v cmUtZGF0YS1wZW5kaW5nIHBhY2tldCBpcyBzaWduaWZpY2FudC4gIFRoZSBpbnRyb2R1Y3Rpb24g c2F5cyBpdCBjb21lcyBsYXN0IGJ1dCBub3RoaW5nIHRvIHRoYXQgZWZmZWN0IGlzIHNhaWQgaW4g c2VjdGlvbiAzLgo+Pgo+PiA1LiAgIFNlY3Rpb24gNiBpbXBsaWVzIHRoYXQgdGhlIG9yZGVyIG9m IGl0ZW1zIGluIGEgc2V0IG9mIGZyYWdtZW50ZWQgcGFja2V0cyBtaWdodCBuZWVkIHRvIGJlIGNo YW5nZWQgYmFzZWQgb24gdGhlIGFiaWxpdHkgb2YgaXRlbXMgdG8gYmUgaW4gdGhlIHBhY2tldC4g IEZvciBleGFtcGxlIGlmIHRoZSBBY2Nlc3MtQWNjZXB0IHBhY2tldCBoYWQgYmVlbiA9IERhdGEx W01dLCBEYXRhMltNXS4uLkRhdGEgMTAsIFVzZXItTmFtZSwgU2VydmljZS1UeXBlW1hdLCBGcmFt ZWQtSVAtQWRkcmVzcyB0aGUgb3JkZXIgd291bGQgbmVlZCB0byBiZSBjaGFuZ2VkIGluIHRoZSBv cmlnaW5hbCBwYXJ0aXRpb25pbmcuICBUaGlzIHNob3VsZCBiZSBtZW50aW9uZWQgc29tZXBsYWNl IG90aGVyIHRoYW4ganVzdCBpbiB0aGUgImV4YW1wbGVzIiBzZWN0aW9uLiAgSXQgaW1wbGllcyB0 aGF0IGEgZ2VuZXJhbCB1c2UgcGllY2Ugb2YgY29kZSB0byBkbyB0aGlzIHdpbGwgbmVlZCB0byBo YXZlIHRoZSB0YWJsZSBidWlsdCBpbiwgYW5kIHBvdGVudGlhbGx5IGV4dGVuZGVkIGFzIG5ldyBp dGVtcyBhcmUgYWRkZWQsIHJhdGhlciB0aGFuIGp1c3QgYmVpbmcgY29kZWQgY29ycmVjdGx5IGlu IHRoZSBzcGVjaWZpYyBwYWNrZXQgdHlwZSBjb2RlLgo+ICAgIEF0dHJpYnV0ZSBvcmRlcmluZyBp cyBleHBsaWNpdGx5ICpub3QqIHJlcXVpcmVkIGluIFJBRElVUy4KPgo+PiA2LiAgV2hhdCBpZiBh bnkgaW5kaWNhdGlvbnMgZG9lcyBhIHNlcnZlciBoYXZlIHRoYXQgdGhlIGNsaWVudCB3aWxsIGJl IGFibGUgdG8gZGVhbCB3aXRoIHRoZSBwYXJ0aXRpb25lZCBtZXNzYWdlIG90aGVyIHRoYW4gaXQg d2lsbCBlaXRoZXIgZmFpbCBvciBnZXQgY29uZnVzZWQgZGVwZW5kaW5nIG9uIHdoYXQgc2V0IG9m IGF0dHJpYnV0ZXMgYXJlIGluIHRoZSBmaXJzdCBwYWNrZXQgYW5kIHdoYXQgaXQgbmVlZHMgYW5k IGZlZWxzIGl0IGNhbiBpZ25vcmUuCj4gICAgVGhhdCdzIGFuIG9wZW4gYXJlYSBmb3IgZGlzY3Vz c2lvbi4gIFJBRElVUyBkb2Vzbid0IGhhdmUgY2FwYWJpbGl0eQo+IG5lZ290aWF0aW9uLCBzbyBp dCdzIGhhcmQgdG8gZG8uCj4KPiAgICBBbGFuIERlS29rLgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpyYWRleHQgbWFpbGluZyBsaXN0CnJhZGV4dEBpZXRm Lm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JhZGV4dAo= From leaf.y.yeh@huawei.com Mon Mar 5 23:29:28 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0D521F8682 for ; Mon, 5 Mar 2012 23:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.653 X-Spam-Level: X-Spam-Status: No, score=-6.653 tagged_above=-999 required=5 tests=[AWL=-0.054, 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 hpFDfDiqAj2a for ; Mon, 5 Mar 2012 23:29:28 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0132C21F8678 for ; Mon, 5 Mar 2012 23:29:28 -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 <0M0G007FWCIM57@szxga04-in.huawei.com> for radext@ietf.org; Tue, 06 Mar 2012 15:23:10 +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 <0M0G00JP4CI75B@szxga04-in.huawei.com> for radext@ietf.org; Tue, 06 Mar 2012 15:23:10 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHP70136; Tue, 06 Mar 2012 15:23:09 +0800 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 06 Mar 2012 15:22:27 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.199]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Tue, 06 Mar 2012 15:23:06 +0800 Date: Tue, 06 Mar 2012 07:23:06 +0000 From: Leaf yeh X-Originating-IP: [10.70.39.113] To: "radext@ietf.org" , "mauricio.sanchez@hp.com" , "jouni.korhonen@nsn.com" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: New Version Notification for draft-yeh-radext-ext-traffic-statistics-02.txt Thread-index: AQHM+rLwpkAAkCzz30asqFU4pUK8k5ZbcIcQgAFqv/A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-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, 06 Mar 2012 07:29:28 -0000 Dear WG, " RADIUS Accounting Extensions for Traffic Statistics " has been updated to be (-02). Questions and comments are more than welcome. There might still have some discussion in the technical part. If chairs agree, I'd like to apply a time slot (15mins) in the RADEXT session of IETF83 for the presentation of this update. Hope you all agree that this item could join the re-charter of RADEXT in Paris. Best Regards, Leaf -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, March 05, 2012 5:32 PM To: Leaf yeh Subject: New Version Notification for draft-yeh-radext-ext-traffic-statistics-02.txt A new version of I-D, draft-yeh-radext-ext-traffic-statistics-02.txt has been successfully submitted by Leaf Y. Yeh and posted to the IETF repository. Filename: draft-yeh-radext-ext-traffic-statistics Revision: 02 Title: RADIUS Accounting Extensions for Traffic Statistics Creation date: 2012-03-05 WG ID: Individual Submission Number of pages: 12 Abstract: This document specifies the RADIUS extensions of attributes for the traffic statistics with different type, which can be used to support the differentiated accounting policies and traffic recording on the AAA server. The IETF Secretariat From radext-bounces@ietf.org Mon Mar 5 23:29:29 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5763421F8682; Mon, 5 Mar 2012 23:29:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331018969; bh=B5g3oWO6sONrt68DKOImnu9SlGPpxeyWtAKkEJmjQfY=; h=Date:From:To:Message-id:MIME-version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=agiTBUk5ALgbwZADYjc+MH1eyT8Fw2K6ja4JiqifE/21k/MvQa3z28wnkxhN5eyFA kDKggwvYE4SB5yLNrSVtWi6dOyRypoLcRyLioKJCma2Vn0hVdaV7GKLx62Eggq03Dy sjt6imClvQ94zYKCOm4tdtayxAuyRLBF7tt5DQsk= 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 9F0D521F8682 for ; Mon, 5 Mar 2012 23:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.653 X-Spam-Level: X-Spam-Status: No, score=-6.653 tagged_above=-999 required=5 tests=[AWL=-0.054, 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 hpFDfDiqAj2a for ; Mon, 5 Mar 2012 23:29:28 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0132C21F8678 for ; Mon, 5 Mar 2012 23:29:28 -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 <0M0G007FWCIM57@szxga04-in.huawei.com> for radext@ietf.org; Tue, 06 Mar 2012 15:23:10 +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 <0M0G00JP4CI75B@szxga04-in.huawei.com> for radext@ietf.org; Tue, 06 Mar 2012 15:23:10 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHP70136; Tue, 06 Mar 2012 15:23:09 +0800 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 06 Mar 2012 15:22:27 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.199]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Tue, 06 Mar 2012 15:23:06 +0800 Date: Tue, 06 Mar 2012 07:23:06 +0000 From: Leaf yeh X-Originating-IP: [10.70.39.113] To: "radext@ietf.org" , "mauricio.sanchez@hp.com" , "jouni.korhonen@nsn.com" Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: New Version Notification for draft-yeh-radext-ext-traffic-statistics-02.txt Thread-index: AQHM+rLwpkAAkCzz30asqFU4pUK8k5ZbcIcQgAFqv/A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-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 Dear WG, " RADIUS Accounting Extensions for Traffic Statistics " has been updated to be (-02). Questions and comments are more than welcome. There might still have some discussion in the technical part. If chairs agree, I'd like to apply a time slot (15mins) in the RADEXT session of IETF83 for the presentation of this update. Hope you all agree that this item could join the re-charter of RADEXT in Paris. Best Regards, Leaf -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, March 05, 2012 5:32 PM To: Leaf yeh Subject: New Version Notification for draft-yeh-radext-ext-traffic-statistics-02.txt A new version of I-D, draft-yeh-radext-ext-traffic-statistics-02.txt has been successfully submitted by Leaf Y. Yeh and posted to the IETF repository. Filename: draft-yeh-radext-ext-traffic-statistics Revision: 02 Title: RADIUS Accounting Extensions for Traffic Statistics Creation date: 2012-03-05 WG ID: Individual Submission Number of pages: 12 Abstract: This document specifies the RADIUS extensions of attributes for the traffic statistics with different type, which can be used to support the differentiated accounting policies and traffic recording on the AAA server. The IETF Secretariat _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From ietf@augustcellars.com Sat Mar 3 13:48:24 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9AC21F876D; Sat, 3 Mar 2012 13:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, 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 kEwVzByg6Rff; Sat, 3 Mar 2012 13:48:24 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1658921F876C; Sat, 3 Mar 2012 13:48:23 -0800 (PST) Received: from Tobias (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id D625738F38; Sat, 3 Mar 2012 13:47:53 -0800 (PST) From: "Jim Schaad" To: "'Alejandro Perez Mendez'" , , References: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> <4F4E03E3.8070006@um.es> In-Reply-To: <4F4E03E3.8070006@um.es> Date: Sat, 3 Mar 2012 13:47:06 -0800 Message-ID: <010601ccf987$409e0220$c1da0660$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFt1L0qLKvc32/xJBUkpNNaNsw/wgHbB2m1lwhje2A= Content-Language: en-us X-Mailman-Approved-At: Wed, 07 Mar 2012 04:19:29 -0800 Subject: Re: [radext] [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 21:48:24 -0000 I have some comments on the draft. However first let me say that I know = next to nothing about RADIX having only briefly read it a couple of = times and having not yet worked with it to any extent. 1. I think a discussion is in order about the issues of packing a = radius message full in the presence of proxy intermediaries which might = need room for adding and removing routing materials. I don't know how = many proxies are keep local state as oppose to just filling up the = message with Proxy-State items and thus need space on the way back. = Also a discussion of removal and re-insertion of the T flag might be = needed if the proxy fully assembles the message and then relays it in = pieces. 2. The Overview in section 2 does not discuss the fact that a new set = of state items might also added to the message. This changes the limit = of how many bytes can be placed into the fragmented packets. 3. nit - in para #3 of overview you use the word truncated and = truncation. I think a better word set might be partitioned and = partitioning. Also ensure that fragmentation is used strictly for the = process in radius-extensions. I have not found any cases yet were it is = not but will try and remember to look. 4. I am not sure if positioning of the more-data-pending packet is = significant. The introduction says it comes last but nothing to that = effect is said in section 3. =20 5. Section 6 implies that the order of items in a set of fragmented = packets might need to be changed based on the ability of items to be in = the packet. For example if the Access-Accept packet had been =3D = Data1[M], Data2[M]...Data 10, User-Name, Service-Type[X], = Framed-IP-Address the order would need to be changed in the original = partitioning. This should be mentioned someplace other than just in the = "examples" section. It implies that a general use piece of code to do = this will need to have the table built in, and potentially extended as = new items are added, rather than just being coded correctly in the = specific packet type code. 6. What if any indications does a server have that the client will be = able to deal with the partitioned message other than it will either fail = or get confused depending on what set of attributes are in the first = packet and what it needs and feels it can ignore. From radext-bounces@ietf.org Wed Mar 7 04:19:30 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A27C21F87AA; Wed, 7 Mar 2012 04:19:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331122770; bh=CUQwHpdb/lLISdh715TN+9JUz1Dq3KjtiCzjLE5TXF4=; h=From:To:References:In-Reply-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=JU8cA/6nrAIWsgHhul4zZsGskhGJ5kDWQMbianQ1Ih2voI35c7Xny3LcNgatbzV9p AmatTvo6HX1sgqFapYS/Y0ltoNeXi0SnEl5g1Kn9B9oueYPhuNjtBm1A9m82tGne2a UswSxoFaTzHmzk54k/DJuM/QI//ujPz03LtCCrhQ= 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 8F9AC21F876D; Sat, 3 Mar 2012 13:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, 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 kEwVzByg6Rff; Sat, 3 Mar 2012 13:48:24 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1658921F876C; Sat, 3 Mar 2012 13:48:23 -0800 (PST) Received: from Tobias (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id D625738F38; Sat, 3 Mar 2012 13:47:53 -0800 (PST) From: "Jim Schaad" To: "'Alejandro Perez Mendez'" , , References: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> <4F4E03E3.8070006@um.es> In-Reply-To: <4F4E03E3.8070006@um.es> Date: Sat, 3 Mar 2012 13:47:06 -0800 Message-ID: <010601ccf987$409e0220$c1da0660$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFt1L0qLKvc32/xJBUkpNNaNsw/wgHbB2m1lwhje2A= Content-Language: en-us X-Mailman-Approved-At: Wed, 07 Mar 2012 04:19:29 -0800 Subject: Re: [radext] [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org I have some comments on the draft. However first let me say that I know next to nothing about RADIX having only briefly read it a couple of times and having not yet worked with it to any extent. 1. I think a discussion is in order about the issues of packing a radius message full in the presence of proxy intermediaries which might need room for adding and removing routing materials. I don't know how many proxies are keep local state as oppose to just filling up the message with Proxy-State items and thus need space on the way back. Also a discussion of removal and re-insertion of the T flag might be needed if the proxy fully assembles the message and then relays it in pieces. 2. The Overview in section 2 does not discuss the fact that a new set of state items might also added to the message. This changes the limit of how many bytes can be placed into the fragmented packets. 3. nit - in para #3 of overview you use the word truncated and truncation. I think a better word set might be partitioned and partitioning. Also ensure that fragmentation is used strictly for the process in radius-extensions. I have not found any cases yet were it is not but will try and remember to look. 4. I am not sure if positioning of the more-data-pending packet is significant. The introduction says it comes last but nothing to that effect is said in section 3. 5. Section 6 implies that the order of items in a set of fragmented packets might need to be changed based on the ability of items to be in the packet. For example if the Access-Accept packet had been = Data1[M], Data2[M]...Data 10, User-Name, Service-Type[X], Framed-IP-Address the order would need to be changed in the original partitioning. This should be mentioned someplace other than just in the "examples" section. It implies that a general use piece of code to do this will need to have the table built in, and potentially extended as new items are added, rather than just being coded correctly in the specific packet type code. 6. What if any indications does a server have that the client will be able to deal with the partitioned message other than it will either fail or get confused depending on what set of attributes are in the first packet and what it needs and feels it can ignore. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Thu Mar 8 09:17:52 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A427521F8593; Thu, 8 Mar 2012 09:17:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331227072; bh=/OXb14Bs1DWaK89u61BXtJDxBTAohpqMe/PciX7Ap5s=; 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=TvOTq7XwZADDZS8v9OPp+FWgyxme6TS7Zz3nAAm6TC4iOP2Xpxr41Qz5fuprxBbXw IrzbcproJsdez6Qnxy4AtppUYYQoRjY/hHx0NpHz20p7ym3rgMdgHSmKDbF0kF2nJj fL7Q3sZ6CyZStyrGXv+9Foq7KblqdjkekDICYhTs= 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 DC5B321F8474 for ; Thu, 8 Mar 2012 09:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.369 X-Spam-Level: X-Spam-Status: No, score=-110.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65trqC9X+s51 for ; Thu, 8 Mar 2012 09:17:49 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 38BE621F8593 for ; Thu, 8 Mar 2012 09:17:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=3428; q=dns/txt; s=iport; t=1331227069; x=1332436669; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=Z1YU0H+yOF1DnMC2Aw+W/3HzIlmPiNbEhEvD43bCADY=; b=IZ6GAS7j8PpcmUXMLKGRgT8z11SylCLUmlIiH6+ECWIgQ8R0jgDEGqe2 j4jChIoL4+SO+2GbBFcm5wUlneDMddIbKt57Zr2xCbNqbHCWcu5duSFfV c5a1KY9BN7eKhll4oMO0orAh2BL6Yv7Udk2uJp3zWcyNF+pXhpBZDTHFi s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMGADrpWE+Q/khL/2dsb2JhbABDo1ORUYEHggoBAQEEAQEBDwEpATELDAYBCBEDAQEBAScuHwkIAgQBDQUih2gLm0IBnxuJOIc2BIgfjSaLIoR2gmQ X-IronPort-AV: E=Sophos;i="4.73,553,1325462400"; d="scan'208";a="68020015" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 08 Mar 2012 17:17:47 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q28HHmGd018756; Thu, 8 Mar 2012 17:17:48 GMT Received: from xmb-ams-112.cisco.com ([144.254.74.87]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 18:17:47 +0100 Received: from 10.61.81.197 ([10.61.81.197]) by XMB-AMS-112.cisco.com ([144.254.74.87]) with Microsoft Exchange Server HTTP-DAV ; Thu, 8 Mar 2012 17:17:47 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 08 Mar 2012 18:17:43 +0100 From: Wojciech Dec To: "Sanchez, Mauricio (HP Networking)" , Jouni Message-ID: Thread-Topic: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt Thread-Index: AQHMom90WDU7kboiIkWUJSus5ElNy5Y+VmzA//+S3oCAAAUXAIACDmRggAyRBA+AFMwWfQ== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 08 Mar 2012 17:17:47.0749 (UTC) FILETIME=[62213950:01CCFD4F] Cc: Bernard Aboba , radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Hello Chairs, all, Would appreciate WG feedback on how to handle the comment(s). On the one hand, the current format of the attribute represents the result of consented previous WG feedback, on the other it is not in line with more recent recommendations in RFC6158. Thanks, Woj. > = > ------ Forwarded Message > From: Leaf yeh > Date: Thu, 16 Feb 2012 12:05:44 +0000 > To: Wojciech Dec , Bernard Aboba > Cc: "radext@ietf.org" , "fine_sz@huawei.com" > , Stefan Winter > Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt > = > Wojciech - the Route-IPv6-Information attribute changed from its > previous "non complex" to the current form between draft 04 and 05, based= on > WG review/feedback: > http://trac.tools.ietf.org/wg/radext/trac/ticket/71 > = > = > As per the requirement in the section 2.1 of RFC6158, > = > Since there are no "hard and fast" > rules for where complexity is best located, each situation has to be > decided on a case-by-case basis...Where a complex data type is selected, = an > explanation SHOULD be offered as to why this was necessary. > = > would you clarify the reason for the adoption of the 'complex data type' = in > the definition of attribute, Route-IPv6-Information? > = > I can=B9t find the answer in the following links: > http://trac.tools.ietf.org/wg/radext/trac/ticket/71 & > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ipv6-access-05 . > = > The definition of the attribute without multi-fields sounds 'ok' with me > personally, but RFC6158 (& its section A.2.1) seems not recommended it. > = > Is my understanding right here? > = > = > Best Regards, > Leaf > = > = > -----Original Message----- > From: Wojciech Dec [mailto:wdec@cisco.com] > Sent: Wednesday, February 15, 2012 8:24 PM > To: Alan DeKok; Leaf yeh > Cc: radext@ietf.org; Stefan Winter; fine_sz@huawei.com > Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt > = > Just as an FYI, the Route-IPv6-Information attribute changed from its > previous "non complex" to the current form between draft 04 and 05, based= on > WG review/feedback: > http://trac.tools.ietf.org/wg/radext/trac/ticket/71 > = > -Wojciech. > = > = > = > On 15/02/2012 13:05, "Alan DeKok" wrote: > = >> Leaf yeh wrote: >>> After reading and employed the RFC6158, Radius Design Guidelines, could= it >>> be >>> concluded the attribute of Route-IPv6-Information defined in the >>> draft-ietf-radext-ipv6-access-06 shown as follows: >> .. >>> is creating a new 'Complex Data Type', which has multi-fields, and is n= ot >>> recommended? = >> = >> That is what the document says. >> = >>> Will it get the same 'acceptable' as that of Frame-IPv6-Prefix (97) and >>> Delegated-IPv6-Prefix(123), which is mentioned in Section B.7 of RFC615= 8? >> = >> No. >> = >> I could explain here, but there's no need. Read RFC 6158. It >> thoroughly details the rationale behind the design guidelines. >> = >> Alan DeKok. > = > _______________________________________________ radext mailing > list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext > = > ------ End of Forwarded Message _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From wdec@cisco.com Thu Mar 8 09:17:50 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5B321F8474 for ; Thu, 8 Mar 2012 09:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.369 X-Spam-Level: X-Spam-Status: No, score=-110.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65trqC9X+s51 for ; Thu, 8 Mar 2012 09:17:49 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 38BE621F8593 for ; Thu, 8 Mar 2012 09:17:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=3428; q=dns/txt; s=iport; t=1331227069; x=1332436669; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=Z1YU0H+yOF1DnMC2Aw+W/3HzIlmPiNbEhEvD43bCADY=; b=IZ6GAS7j8PpcmUXMLKGRgT8z11SylCLUmlIiH6+ECWIgQ8R0jgDEGqe2 j4jChIoL4+SO+2GbBFcm5wUlneDMddIbKt57Zr2xCbNqbHCWcu5duSFfV c5a1KY9BN7eKhll4oMO0orAh2BL6Yv7Udk2uJp3zWcyNF+pXhpBZDTHFi s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMGADrpWE+Q/khL/2dsb2JhbABDo1ORUYEHggoBAQEEAQEBDwEpATELDAYBCBEDAQEBAScuHwkIAgQBDQUih2gLm0IBnxuJOIc2BIgfjSaLIoR2gmQ X-IronPort-AV: E=Sophos;i="4.73,553,1325462400"; d="scan'208";a="68020015" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 08 Mar 2012 17:17:47 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q28HHmGd018756; Thu, 8 Mar 2012 17:17:48 GMT Received: from xmb-ams-112.cisco.com ([144.254.74.87]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 18:17:47 +0100 Received: from 10.61.81.197 ([10.61.81.197]) by XMB-AMS-112.cisco.com ([144.254.74.87]) with Microsoft Exchange Server HTTP-DAV ; Thu, 8 Mar 2012 17:17:47 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 08 Mar 2012 18:17:43 +0100 From: Wojciech Dec To: "Sanchez, Mauricio (HP Networking)" , Jouni Message-ID: Thread-Topic: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt Thread-Index: AQHMom90WDU7kboiIkWUJSus5ElNy5Y+VmzA//+S3oCAAAUXAIACDmRggAyRBA+AFMwWfQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 08 Mar 2012 17:17:47.0749 (UTC) FILETIME=[62213950:01CCFD4F] Cc: Bernard Aboba , radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:17:51 -0000 Hello Chairs, all, Would appreciate WG feedback on how to handle the comment(s). On the one hand, the current format of the attribute represents the result of consented previous WG feedback, on the other it is not in line with more recent recommendations in RFC6158. Thanks, Woj. >=20 > ------ Forwarded Message > From: Leaf yeh > Date: Thu, 16 Feb 2012 12:05:44 +0000 > To: Wojciech Dec , Bernard Aboba > Cc: "radext@ietf.org" , "fine_sz@huawei.com" > , Stefan Winter > Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt >=20 > Wojciech - the Route-IPv6-Information attribute changed from its > previous "non complex" to the current form between draft 04 and 05, based= on > WG review/feedback: > http://trac.tools.ietf.org/wg/radext/trac/ticket/71 >=20 >=20 > As per the requirement in the section 2.1 of RFC6158, >=20 > Since there are no "hard and fast" > rules for where complexity is best located, each situation has to be > decided on a case-by-case basis...Where a complex data type is selected, = an > explanation SHOULD be offered as to why this was necessary. >=20 > would you clarify the reason for the adoption of the 'complex data type' = in > the definition of attribute, Route-IPv6-Information? >=20 > I can=B9t find the answer in the following links: > http://trac.tools.ietf.org/wg/radext/trac/ticket/71 & > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ipv6-access-05 . >=20 > The definition of the attribute without multi-fields sounds 'ok' with me > personally, but RFC6158 (& its section A.2.1) seems not recommended it. >=20 > Is my understanding right here? >=20 >=20 > Best Regards, > Leaf >=20 >=20 > -----Original Message----- > From: Wojciech Dec [mailto:wdec@cisco.com] > Sent: Wednesday, February 15, 2012 8:24 PM > To: Alan DeKok; Leaf yeh > Cc: radext@ietf.org; Stefan Winter; fine_sz@huawei.com > Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt >=20 > Just as an FYI, the Route-IPv6-Information attribute changed from its > previous "non complex" to the current form between draft 04 and 05, based= on > WG review/feedback: > http://trac.tools.ietf.org/wg/radext/trac/ticket/71 >=20 > -Wojciech. >=20 >=20 >=20 > On 15/02/2012 13:05, "Alan DeKok" wrote: >=20 >> Leaf yeh wrote: >>> After reading and employed the RFC6158, Radius Design Guidelines, could= it >>> be >>> concluded the attribute of Route-IPv6-Information defined in the >>> draft-ietf-radext-ipv6-access-06 shown as follows: >> .. >>> is creating a new 'Complex Data Type', which has multi-fields, and is n= ot >>> recommended?=20 >>=20 >> That is what the document says. >>=20 >>> Will it get the same 'acceptable' as that of Frame-IPv6-Prefix (97) and >>> Delegated-IPv6-Prefix(123), which is mentioned in Section B.7 of RFC615= 8? >>=20 >> No. >>=20 >> I could explain here, but there's no need. Read RFC 6158. It >> thoroughly details the rationale behind the design guidelines. >>=20 >> Alan DeKok. >=20 > _______________________________________________ radext mailing > list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext >=20 > ------ End of Forwarded Message From aland@deployingradius.com Fri Mar 9 00:15:55 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E4321F85A1; Fri, 9 Mar 2012 00:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.392 X-Spam-Level: X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 K6c1aj4c4mhh; Fri, 9 Mar 2012 00:15:54 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEF521F860B; Fri, 9 Mar 2012 00:15:54 -0800 (PST) Message-ID: <4F59BC22.5070800@deployingradius.com> Date: Fri, 09 Mar 2012 09:15:30 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jim Schaad References: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> <4F4E03E3.8070006@um.es> <010601ccf987$409e0220$c1da0660$@augustcellars.com> <4F53154C.9060604@deployingradius.com> <002701ccfdb0$a6b67ab0$f4237010$@augustcellars.com> In-Reply-To: <002701ccfdb0$a6b67ab0$f4237010$@augustcellars.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, abfab@ietf.org, 'Alejandro Perez Mendez' Subject: Re: [radext] [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 08:15:55 -0000 Jim Schaad wrote: > Would this also be a way to deal with restrictions on the size seen by the > server? I.e. you also need to make the server deal with smaller packets as > well. Yes. Servers already do this for EAP authentication. If they see a Framed-MTU, they ensure that the EAP packet will fit into that MTU. This gives a secondary result that the size of the RADIUS packet is limited. Alan DeKok. From radext-bounces@ietf.org Fri Mar 9 00:15:55 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBE221F860B; Fri, 9 Mar 2012 00:15:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331280955; bh=cL7C9qxA9lQaJ+R7zgn0P+YaC6s3BBYbbt+HjoVaW44=; 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=u3nlN4hA4UW+Tv7qEkRrfPa65Nvhtwmm1u3tuGkOIkAjkgElP4Ut+AgKSiJKptcF7 sgZ7aezZcg4NPaG+49FcIDiYDFMcCzjzUS1UQOwW8i82yZVMFWMCJEWkEMl4ftqiuq hmCrDdYPeY2Xt4KDkukNgazWP3VFqeZVK7XobqD4= 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 31E4321F85A1; Fri, 9 Mar 2012 00:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.392 X-Spam-Level: X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 K6c1aj4c4mhh; Fri, 9 Mar 2012 00:15:54 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEF521F860B; Fri, 9 Mar 2012 00:15:54 -0800 (PST) Message-ID: <4F59BC22.5070800@deployingradius.com> Date: Fri, 09 Mar 2012 09:15:30 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jim Schaad References: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> <4F4E03E3.8070006@um.es> <010601ccf987$409e0220$c1da0660$@augustcellars.com> <4F53154C.9060604@deployingradius.com> <002701ccfdb0$a6b67ab0$f4237010$@augustcellars.com> In-Reply-To: <002701ccfdb0$a6b67ab0$f4237010$@augustcellars.com> X-Enigmail-Version: 0.96.0 Cc: radext@ietf.org, abfab@ietf.org, 'Alejandro Perez Mendez' Subject: Re: [radext] [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Jim Schaad wrote: > Would this also be a way to deal with restrictions on the size seen by the > server? I.e. you also need to make the server deal with smaller packets as > well. Yes. Servers already do this for EAP authentication. If they see a Framed-MTU, they ensure that the EAP packet will fit into that MTU. This gives a secondary result that the size of the RADIUS packet is limited. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Fri Mar 9 03:56:13 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D64A21F85F1; Fri, 9 Mar 2012 03:56:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331294173; bh=DZSpQa698WkzLjsvSTMNF5vSfHmaLfTt/mWyAdVE5Aw=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=WHH/i2oz9A3t+JYJSndmZ4Q3ttJDuo4CZk6T50q22WotgWrnIVCnE92OdGDL5fNbw LeorXlpHroqtqS1C3yLSva4Tpg9aKuvk55L9sOjsu0KpJUPQzaBtkkkalU8qNgGJhu sQv5WJyIpEyGUZnYCx2UBi8Clxg9P+jFLh7taVU8= 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 9123B21F85F1; Fri, 9 Mar 2012 03:56:11 -0800 (PST) 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 SsgGk9MmKXwC; Fri, 9 Mar 2012 03:56:10 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 879F821F85E6; Fri, 9 Mar 2012 03:56:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 217D5535FE; Fri, 9 Mar 2012 12:56:09 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GcOWQNCxJLyW; Fri, 9 Mar 2012 12:56:08 +0100 (CET) Received: from [192.168.1.131] (238.226.14.37.dynamic.jazztel.es [37.14.226.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPSA id 6B184535E7; Fri, 9 Mar 2012 12:56:03 +0100 (CET) Message-ID: <4F59EFD1.8030400@um.es> Date: Fri, 09 Mar 2012 12:56:01 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jim Schaad References: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> <4F4E03E3.8070006@um.es> <010601ccf987$409e0220$c1da0660$@augustcellars.com> <4F53154C.9060604@deployingradius.com> <4F547319.5040001@um.es> <002801ccfdb0$dc0d6ac0$94284040$@augustcellars.com> In-Reply-To: <002801ccfdb0$dc0d6ac0$94284040$@augustcellars.com> Cc: radext@ietf.org, abfab@ietf.org, 'Alan DeKok' Subject: Re: [radext] [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org CgpFbCAwOS8wMy8xMiAwNTo1NSwgSmltIFNjaGFhZCBlc2NyaWJpw7M6Cj4KPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0KPj4gRnJvbTogQWxlamFuZHJvIFBlcmV6IE1lbmRleiBbbWFpbHRv OmFsZXhAdW0uZXNdCj4+IFNlbnQ6IE1vbmRheSwgTWFyY2ggMDUsIDIwMTIgMTI6MDMgQU0KPj4g VG86IEFsYW4gRGVLb2sKPj4gQ2M6IEppbSBTY2hhYWQ7IHJhZGV4dEBpZXRmLm9yZzsgYWJmYWJA aWV0Zi5vcmcKPj4gU3ViamVjdDogUmU6IFthYmZhYl0gRllJOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LXBlcmV6LXJhZGV4dC0KPj4gcmFkaXVzLWZyYWdtZW50YXRpb24tMDEu dHh0Cj4+Cj4+Cj4+Cj4+IEVsIDA0LzAzLzEyIDA4OjEwLCBBbGFuIERlS29rIGVzY3JpYmnDszoK Pj4+IEppbSBTY2hhYWQgd3JvdGU6Cj4+Pj4gSSBoYXZlIHNvbWUgY29tbWVudHMgb24gdGhlIGRy YWZ0LiAgSG93ZXZlciBmaXJzdCBsZXQgbWUgc2F5IHRoYXQgSSBrbm93Cj4+IG5leHQgdG8gbm90 aGluZyBhYm91dCBSQURJWCBoYXZpbmcgb25seSBicmllZmx5IHJlYWQgaXQgYSBjb3VwbGUgb2Yg dGltZXMgYW5kCj4+IGhhdmluZyBub3QgeWV0IHdvcmtlZCB3aXRoIGl0IHRvIGFueSBleHRlbnQu Cj4+PiAgICAgUmV2aWV3cyBhcmUgYWx3YXlzIHdlbGNvbWUuCj4+Pgo+Pj4+IDEuICBJIHRoaW5r IGEgZGlzY3Vzc2lvbiBpcyBpbiBvcmRlciBhYm91dCB0aGUgaXNzdWVzIG9mIHBhY2tpbmcgYSBy YWRpdXMKPj4gbWVzc2FnZSBmdWxsIGluIHRoZSBwcmVzZW5jZSBvZiBwcm94eSBpbnRlcm1lZGlh cmllcyB3aGljaCBtaWdodCBuZWVkIHJvb20KPj4gZm9yIGFkZGluZyBhbmQgcmVtb3Zpbmcgcm91 dGluZyBtYXRlcmlhbHMuICBJIGRvbid0IGtub3cgaG93IG1hbnkgcHJveGllcwo+PiBhcmUga2Vl cCBsb2NhbCBzdGF0ZSBhcyBvcHBvc2UgdG8ganVzdCBmaWxsaW5nIHVwIHRoZSBtZXNzYWdlIHdp dGggUHJveHktU3RhdGUKPj4gaXRlbXMgYW5kIHRodXMgbmVlZCBzcGFjZSBvbiB0aGUgd2F5IGJh Y2suICBBbHNvIGEgZGlzY3Vzc2lvbiBvZiByZW1vdmFsCj4+IGFuZCByZS1pbnNlcnRpb24gb2Yg dGhlIFQgZmxhZyBtaWdodCBiZSBuZWVkZWQgaWYgdGhlIHByb3h5IGZ1bGx5IGFzc2VtYmxlcwo+ PiB0aGUgbWVzc2FnZSBhbmQgdGhlbiByZWxheXMgaXQgaW4gcGllY2VzLgo+Pj4gICAgIFRoZSBz aW1wbGVzdCB3YXkgdG8gYWRkcmVzcyB0aGF0IGlzIHRvIGFydGlmaWNpYWxseSBsb3dlciB0aGUK Pj4+IFJBRElVUyBtYXhpbXVtIHBhY2tldCBzaXplLCBhcyBzZWVuIGJ5IHRoZSBjbGllbnQuCj4+ IEFkZGl0aW9uYWxseSwgcmVnYXJkaW5nIHRoZSBUIGZsYWcgcmVtb3ZhbC9yZS1pbnNlcnRpb24g Y29tbWVudCwgcHJveGllcyBhcmUKPj4gbm90IGFsbG93ZWQgdG8gcGVyZm9ybSBSQURJVVMgZnJh Z21lbnRhdGlvbiBvbiBmb3J3YXJkZWQgcGFja2V0cy4gSXQgaXMgYQo+PiBwcm9jZXNzIHBlcmZv cm1lZCBlbmQtdG8tZW5kIHRoZSBSQURJVVMgY2xpZW50IGFuZCBzZXJ2ZXIuCj4+Cj4gV2hhdCBo YXBwZW5zIGZvciBwcm94aWVzIHRoYXQsIGZvciBzb21lIHJlYXNvbiAtIHdhbnQgdG8gcmUtd3Jp dGUgdGhlIGNvbnRlbnRzIG9mIHBhY2tldHMuICBGb3IgQUJGQUIgSSBhbSBzcGVjaWZpY2FsbHkg dGhpbmtpbmcgb2YgY2hhbmdpbmcgb3IgbWFwcGluZyBhdHRyaWJ1dGVzIGluIFNBTUwgYXNzZXJ0 aW9ucy4KCkkgZG9uJ3QgdGhpbmsgYSBSQURJVVMgcHJveHkgc2hvdWxkIGNoYW5nZSBhbnl0aGlu ZyBhdCBhIFNBTUwgbGV2ZWwsIGJ1dCAKSSBtYXkgYmUgd3JvbmcuIFNwZWNpYWxseSwgaWYgdGhl IGFzc2VydGlvbiBpcyBzaW5nZWQgYnkgdGhlIElkUCwgdGhhdCAKd291bGQgYmUgaW1wb3NzaWJs ZSBhdCBpdCB3b3VsZCBpbnZhbGlkYXRlIHRoZSBzaWduYXR1cmUuCgpBbnl3YXksIG90aGVyIGFs dGVybmF0aXZlcyB0byBkZWxpdmVyIGxhcmdlIGF1dGhvcml6YXRpb24gZGF0YSwgbGlrZSAKcHJv dmlkaW5nIGEgVVJMIHdoZXJlIHRoZSBSUCBjYW4gZG93bmxvYWQgdGhlIGFzc2VydGlvbiBsYXRl ciwgaGF2ZSAKZXhhY3RseSB0aGUgc2FtZSBpc3N1ZTogcHJveGllcyBjYW5ub3QgbW9kaWZ5IHRo ZSBjb250ZW50cyBvZiB0aGUgYXNzZXJ0aW9uLgoKUmVnYXJkcywKQWxlamFuZHJvCgo+Cj4+Pj4g Mi4gICBUaGUgT3ZlcnZpZXcgaW4gc2VjdGlvbiAyIGRvZXMgbm90IGRpc2N1c3MgdGhlIGZhY3Qg dGhhdCBhIG5ldyBzZXQgb2YKPj4gc3RhdGUgaXRlbXMgbWlnaHQgYWxzbyBhZGRlZCB0byB0aGUg bWVzc2FnZS4gIFRoaXMgY2hhbmdlcyB0aGUgbGltaXQgb2YgaG93Cj4+IG1hbnkgYnl0ZXMgY2Fu IGJlIHBsYWNlZCBpbnRvIHRoZSBmcmFnbWVudGVkIHBhY2tldHMuCj4+PiAgICAgWWVzLgo+Pj4K Pj4+PiAzLiBuaXQgLSBpbiBwYXJhICMzIG9mIG92ZXJ2aWV3IHlvdSB1c2UgdGhlIHdvcmQgdHJ1 bmNhdGVkIGFuZCB0cnVuY2F0aW9uLgo+PiBJIHRoaW5rIGEgYmV0dGVyIHdvcmQgc2V0IG1pZ2h0 IGJlIHBhcnRpdGlvbmVkIGFuZCBwYXJ0aXRpb25pbmcuICBBbHNvIGVuc3VyZQo+PiB0aGF0IGZy YWdtZW50YXRpb24gaXMgdXNlZCBzdHJpY3RseSBmb3IgdGhlIHByb2Nlc3MgaW4gcmFkaXVzLWV4 dGVuc2lvbnMuICBJCj4+IGhhdmUgbm90IGZvdW5kIGFueSBjYXNlcyB5ZXQgd2VyZSBpdCBpcyBu b3QgYnV0IHdpbGwgdHJ5IGFuZCByZW1lbWJlciB0bwo+PiBsb29rLgo+Pj4+IDQuICBJIGFtIG5v dCBzdXJlIGlmIHBvc2l0aW9uaW5nIG9mIHRoZSBtb3JlLWRhdGEtcGVuZGluZyBwYWNrZXQgaXMK Pj4gc2lnbmlmaWNhbnQuICBUaGUgaW50cm9kdWN0aW9uIHNheXMgaXQgY29tZXMgbGFzdCBidXQg bm90aGluZyB0byB0aGF0IGVmZmVjdCBpcwo+PiBzYWlkIGluIHNlY3Rpb24gMy4KPj4+PiA1LiAg IFNlY3Rpb24gNiBpbXBsaWVzIHRoYXQgdGhlIG9yZGVyIG9mIGl0ZW1zIGluIGEgc2V0IG9mIGZy YWdtZW50ZWQgcGFja2V0cwo+PiBtaWdodCBuZWVkIHRvIGJlIGNoYW5nZWQgYmFzZWQgb24gdGhl IGFiaWxpdHkgb2YgaXRlbXMgdG8gYmUgaW4gdGhlIHBhY2tldC4KPj4gRm9yIGV4YW1wbGUgaWYg dGhlIEFjY2Vzcy1BY2NlcHQgcGFja2V0IGhhZCBiZWVuID0gRGF0YTFbTV0sCj4+IERhdGEyW01d Li4uRGF0YSAxMCwgVXNlci1OYW1lLCBTZXJ2aWNlLVR5cGVbWF0sIEZyYW1lZC1JUC1BZGRyZXNz IHRoZQo+PiBvcmRlciB3b3VsZCBuZWVkIHRvIGJlIGNoYW5nZWQgaW4gdGhlIG9yaWdpbmFsIHBh cnRpdGlvbmluZy4gIFRoaXMgc2hvdWxkIGJlCj4+IG1lbnRpb25lZCBzb21lcGxhY2Ugb3RoZXIg dGhhbiBqdXN0IGluIHRoZSAiZXhhbXBsZXMiIHNlY3Rpb24uICBJdCBpbXBsaWVzCj4+IHRoYXQg YSBnZW5lcmFsIHVzZSBwaWVjZSBvZiBjb2RlIHRvIGRvIHRoaXMgd2lsbCBuZWVkIHRvIGhhdmUg dGhlIHRhYmxlIGJ1aWx0IGluLAo+PiBhbmQgcG90ZW50aWFsbHkgZXh0ZW5kZWQgYXMgbmV3IGl0 ZW1zIGFyZSBhZGRlZCwgcmF0aGVyIHRoYW4ganVzdCBiZWluZwo+PiBjb2RlZCBjb3JyZWN0bHkg aW4gdGhlIHNwZWNpZmljIHBhY2tldCB0eXBlIGNvZGUuCj4+PiAgICAgQXR0cmlidXRlIG9yZGVy aW5nIGlzIGV4cGxpY2l0bHkgKm5vdCogcmVxdWlyZWQgaW4gUkFESVVTLgo+Pj4KPj4+PiA2LiAg V2hhdCBpZiBhbnkgaW5kaWNhdGlvbnMgZG9lcyBhIHNlcnZlciBoYXZlIHRoYXQgdGhlIGNsaWVu dCB3aWxsIGJlIGFibGUgdG8KPj4gZGVhbCB3aXRoIHRoZSBwYXJ0aXRpb25lZCBtZXNzYWdlIG90 aGVyIHRoYW4gaXQgd2lsbCBlaXRoZXIgZmFpbCBvciBnZXQgY29uZnVzZWQKPj4gZGVwZW5kaW5n IG9uIHdoYXQgc2V0IG9mIGF0dHJpYnV0ZXMgYXJlIGluIHRoZSBmaXJzdCBwYWNrZXQgYW5kIHdo YXQgaXQgbmVlZHMKPj4gYW5kIGZlZWxzIGl0IGNhbiBpZ25vcmUuCj4+PiAgICAgVGhhdCdzIGFu IG9wZW4gYXJlYSBmb3IgZGlzY3Vzc2lvbi4gIFJBRElVUyBkb2Vzbid0IGhhdmUgY2FwYWJpbGl0 eQo+Pj4gbmVnb3RpYXRpb24sIHNvIGl0J3MgaGFyZCB0byBkby4KPj4+Cj4+PiAgICAgQWxhbiBE ZUtvay4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcmFk ZXh0IG1haWxpbmcgbGlzdApyYWRleHRAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9yYWRleHQK From alex@um.es Fri Mar 9 03:56:11 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9123B21F85F1; Fri, 9 Mar 2012 03:56:11 -0800 (PST) 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 SsgGk9MmKXwC; Fri, 9 Mar 2012 03:56:10 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 879F821F85E6; Fri, 9 Mar 2012 03:56:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 217D5535FE; Fri, 9 Mar 2012 12:56:09 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GcOWQNCxJLyW; Fri, 9 Mar 2012 12:56:08 +0100 (CET) Received: from [192.168.1.131] (238.226.14.37.dynamic.jazztel.es [37.14.226.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPSA id 6B184535E7; Fri, 9 Mar 2012 12:56:03 +0100 (CET) Message-ID: <4F59EFD1.8030400@um.es> Date: Fri, 09 Mar 2012 12:56:01 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jim Schaad References: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> <4F4E03E3.8070006@um.es> <010601ccf987$409e0220$c1da0660$@augustcellars.com> <4F53154C.9060604@deployingradius.com> <4F547319.5040001@um.es> <002801ccfdb0$dc0d6ac0$94284040$@augustcellars.com> In-Reply-To: <002801ccfdb0$dc0d6ac0$94284040$@augustcellars.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: radext@ietf.org, abfab@ietf.org, 'Alan DeKok' Subject: Re: [radext] [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 11:56:11 -0000 El 09/03/12 05:55, Jim Schaad escribió: > >> -----Original Message----- >> From: Alejandro Perez Mendez [mailto:alex@um.es] >> Sent: Monday, March 05, 2012 12:03 AM >> To: Alan DeKok >> Cc: Jim Schaad; radext@ietf.org; abfab@ietf.org >> Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext- >> radius-fragmentation-01.txt >> >> >> >> El 04/03/12 08:10, Alan DeKok escribió: >>> Jim Schaad wrote: >>>> I have some comments on the draft. However first let me say that I know >> next to nothing about RADIX having only briefly read it a couple of times and >> having not yet worked with it to any extent. >>> Reviews are always welcome. >>> >>>> 1. I think a discussion is in order about the issues of packing a radius >> message full in the presence of proxy intermediaries which might need room >> for adding and removing routing materials. I don't know how many proxies >> are keep local state as oppose to just filling up the message with Proxy-State >> items and thus need space on the way back. Also a discussion of removal >> and re-insertion of the T flag might be needed if the proxy fully assembles >> the message and then relays it in pieces. >>> The simplest way to address that is to artificially lower the >>> RADIUS maximum packet size, as seen by the client. >> Additionally, regarding the T flag removal/re-insertion comment, proxies are >> not allowed to perform RADIUS fragmentation on forwarded packets. It is a >> process performed end-to-end the RADIUS client and server. >> > What happens for proxies that, for some reason - want to re-write the contents of packets. For ABFAB I am specifically thinking of changing or mapping attributes in SAML assertions. I don't think a RADIUS proxy should change anything at a SAML level, but I may be wrong. Specially, if the assertion is singed by the IdP, that would be impossible at it would invalidate the signature. Anyway, other alternatives to deliver large authorization data, like providing a URL where the RP can download the assertion later, have exactly the same issue: proxies cannot modify the contents of the assertion. Regards, Alejandro > >>>> 2. The Overview in section 2 does not discuss the fact that a new set of >> state items might also added to the message. This changes the limit of how >> many bytes can be placed into the fragmented packets. >>> Yes. >>> >>>> 3. nit - in para #3 of overview you use the word truncated and truncation. >> I think a better word set might be partitioned and partitioning. Also ensure >> that fragmentation is used strictly for the process in radius-extensions. I >> have not found any cases yet were it is not but will try and remember to >> look. >>>> 4. I am not sure if positioning of the more-data-pending packet is >> significant. The introduction says it comes last but nothing to that effect is >> said in section 3. >>>> 5. Section 6 implies that the order of items in a set of fragmented packets >> might need to be changed based on the ability of items to be in the packet. >> For example if the Access-Accept packet had been = Data1[M], >> Data2[M]...Data 10, User-Name, Service-Type[X], Framed-IP-Address the >> order would need to be changed in the original partitioning. This should be >> mentioned someplace other than just in the "examples" section. It implies >> that a general use piece of code to do this will need to have the table built in, >> and potentially extended as new items are added, rather than just being >> coded correctly in the specific packet type code. >>> Attribute ordering is explicitly *not* required in RADIUS. >>> >>>> 6. What if any indications does a server have that the client will be able to >> deal with the partitioned message other than it will either fail or get confused >> depending on what set of attributes are in the first packet and what it needs >> and feels it can ignore. >>> That's an open area for discussion. RADIUS doesn't have capability >>> negotiation, so it's hard to do. >>> >>> Alan DeKok. From iesg-secretary@ietf.org Mon Mar 12 14:43:03 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20B811E816B; Mon, 12 Mar 2012 14:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 zt8M-fL3VcsK; Mon, 12 Mar 2012 14:43:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CFB11E8170; Mon, 12 Mar 2012 14:43:00 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312214300.26285.89256.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 14:43:00 -0700 Cc: radext mailing list , radext chair , RFC Editor Subject: [radext] Document Action: 'Transport Layer Security (TLS) encryption for RADIUS' to Experimental RFC (draft-ietf-radext-radsec-12.txt) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:43:04 -0000 The IESG has approved the following document: - 'Transport Layer Security (TLS) encryption for RADIUS' (draft-ietf-radext-radsec-12.txt) as an Experimental RFC This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are Dan Romascanu and Ronald Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-radext-radsec/ Technical Summary This document specifies security on the transport layer (TLS) for the RADIUS protocol when transmitted over TCP. This enables dynamic trust relationships between RADIUS servers Working Group Summary The consensus in the WG was solid and there were no specific issues during the WG process that would need specific noting. Document Quality The document quality is good and there are several known implementations from different vendors, and more implementations are expected. Furthermore, there is at least one operational world-wide roaming environment with multiple involved parties already using the protocol specified by this document. Personnel Jouni Korhonen is the Document Shepherd. Dan Romascanu is the Responsible Area Director. From radext-bounces@ietf.org Mon Mar 12 14:43:09 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A07B11E8176; Mon, 12 Mar 2012 14:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331588589; bh=8KX0pDePYdEJfafHrhMev1GOJM/btyAAhKbvvWVoYQQ=; 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=vOur1J3AboeV/i1/uPgikAJwHaiGdttlvC7fqh7IIBtOTMZa70eR7IgmAI9jYn7Qb IEskW1vuqioR5T2V4/ZkLAQ7T9VlkEqJTbeBafhkeSSw5DRtVgaY391LNd5zfO/5eI DHSG4sow0UbYPeWgyBy753tklHGOI/gX5AYA68O0= 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 E20B811E816B; Mon, 12 Mar 2012 14:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 zt8M-fL3VcsK; Mon, 12 Mar 2012 14:43:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CFB11E8170; Mon, 12 Mar 2012 14:43:00 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312214300.26285.89256.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 14:43:00 -0700 Cc: radext mailing list , radext chair , RFC Editor Subject: [radext] Document Action: 'Transport Layer Security (TLS) encryption for RADIUS' to Experimental RFC (draft-ietf-radext-radsec-12.txt) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org The IESG has approved the following document: - 'Transport Layer Security (TLS) encryption for RADIUS' (draft-ietf-radext-radsec-12.txt) as an Experimental RFC This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are Dan Romascanu and Ronald Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-radext-radsec/ Technical Summary This document specifies security on the transport layer (TLS) for the RADIUS protocol when transmitted over TCP. This enables dynamic trust relationships between RADIUS servers Working Group Summary The consensus in the WG was solid and there were no specific issues during the WG process that would need specific noting. Document Quality The document quality is good and there are several known implementations from different vendors, and more implementations are expected. Furthermore, there is at least one operational world-wide roaming environment with multiple involved parties already using the protocol specified by this document. Personnel Jouni Korhonen is the Document Shepherd. Dan Romascanu is the Responsible Area Director. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Tue Mar 13 10:10:58 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADDB521E8021; Tue, 13 Mar 2012 10:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331658658; bh=qg/cqSkAC42VyFAlJ8wLoGlarcjNtmx5XVXV/einO/U=; h=From:To:Date: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=tZh6WqtE8bdpI5O+aCS2EThGGEb0lhT1mQZyFV6DY9wm2nIjTbIvG6VIPSEj6BcMR EaPz+rtEXa8pZtaZOQR3zV5G8jVidUUhZvFmGssF/fruW+TRI7xJ8ZgciUMEMIdrAT wNHKwsrbl1YjrivvUrby0kOpYcMrwwOSdcw2BPrY= 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 0F1D121E8034 for ; Tue, 13 Mar 2012 10:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.722 X-Spam-Level: X-Spam-Status: No, score=-107.722 tagged_above=-999 required=5 tests=[AWL=-2.877, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 l8LgOxL7b2xT for ; Tue, 13 Mar 2012 10:10:57 -0700 (PDT) Received: from g6t0185.atlanta.hp.com (g6t0185.atlanta.hp.com [15.193.32.62]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1B521E8021 for ; Tue, 13 Mar 2012 10:10:57 -0700 (PDT) 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 g6t0185.atlanta.hp.com (Postfix) with ESMTPS id 64C9B24143; Tue, 13 Mar 2012 17:10:56 +0000 (UTC) Received: from G6W0173.americas.hpqcorp.net (16.230.33.182) by G1W0400.americas.hpqcorp.net (16.236.31.10) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 13 Mar 2012 17:09:51 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G6W0173.americas.hpqcorp.net ([16.230.33.182]) with mapi; Tue, 13 Mar 2012 17:09:51 +0000 From: "Sanchez, Mauricio (HP Networking)" To: Wojciech Dec , "jouni.nospam@gmail.com" Date: Tue, 13 Mar 2012 17:09:05 +0000 Thread-Topic: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt Thread-Index: Ac0BPBpHnetohAALRPa9LFwNG1pvFg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US MIME-Version: 1.0 Cc: Bernard Aboba , "radext@ietf.org" Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org DQpSQURFWFQsIGxpa2UgYW55IGdvb2QgSUVURiBXRywgaGFzIGEgY29sb3JmdWwgaGlzdG9yeSBh bmQgc29tZXRpbWVzIGEgYml0DQpzY2hpem9waHJlbmljLCBhcyB0aGlzIHBhcnRpY3VsYXIgY2Fz ZSBjYW4gYXR0ZXN0IHRvLiAgSSB0aGluayB3ZSBjYW4gYWxsDQphZ3JlZSB0aGF0IHRoZSBpcHY2 IGF0dHJpYnV0ZWQgbm90ZWQgYmVsb3cgaXMgb2YgYSBjb21wbGV4IHR5cGUgYW5kIGluDQpjb25m bGljdCB3aXRoIFJGQzYxNTggbWFuZGF0ZSB0byBub3QgY29udGludWUgdG8gcHJvbXVsZ2F0ZSBz dWNoIGNvbXBsZXgNCnR5cGVzLiBIb3dldmVyLCBSRkM2MTU4IGFsc28gaW5jbHVkZXMgYSBzaWdu aWZpY2FudCBhbW91bnQgb2YgbGVld2F5LiAgSQ0KdGhpbmsgd2UgaGF2ZSB0d28gb3B0aW9ucyBi ZWZvcmUgdXM6DQoNCigxKSBQZXIgUkZDNjE1OCdzIG1hbmRhdGUgaW5jbHVkZSBhIHNtYWxsIHN0 YXRlbWVudCBqdXN0aWZ5aW5nIHRoZSBjb21wbGV4DQphdHRyaWJ1dGUgYXMgaXQgc3RhbmRzIG5v dy4gIFN0YXRlbWVudCB3b3VsZCBiZSBzaW1pbGFyIGluIHNwaXJpdCB0byB3aGF0DQphcHBlbmRp eCBCIGluIFJGQzYxNTggZG9lcyBmb3Igb3RoZXIgY29tcGxleCBhdHRyaWJ1dGVzDQoNCigyKSBS ZWNhc3QgdGhlIGRlc2lnbiBvZiBhdHRyaWJ1dGUgaW50byBhIG5ldyBmb3JtIHRoYXQgcmVkdWNl cyBpdHMNCmNvbXBsZXhpdHkgKGkuZS4gTG9vayB0byBmb2xsb3cgUkZDNjE1OCBtb3JlIGNsb3Nl bHkpLg0KDQpJZiB3ZSBhZ3JlZSB0aGVzZSBhcmUgdGhlIHR3byBvcHRpb25zIGJlZm9yZSB1cywg d2UgY2FuIGRvIGNvbnNlbnN1cyBjaGVjaw0Kb24gd2hpY2ggYXBwcm9hY2ggdGhlIFdHIHdvdWxk IGxpa2UgdG8gdGFrZS4NCg0KLU1TIA0KDQoNCg0KDQoNCk9uIDMvOC8xMiAxMToxNyBBTSwgIldv amNpZWNoIERlYyIgPHdkZWNAY2lzY28uY29tPiB3cm90ZToNCg0KPkhlbGxvIENoYWlycywgYWxs LA0KPg0KPldvdWxkIGFwcHJlY2lhdGUgV0cgZmVlZGJhY2sgb24gaG93IHRvIGhhbmRsZSB0aGUg Y29tbWVudChzKS4gT24NCj50aGUgb25lIGhhbmQsIHRoZSBjdXJyZW50IGZvcm1hdCBvZiB0aGUg YXR0cmlidXRlIHJlcHJlc2VudHMgdGhlIHJlc3VsdCBvZg0KPmNvbnNlbnRlZCBwcmV2aW91cyBX RyBmZWVkYmFjaywgb24gdGhlIG90aGVyIGl0IGlzIG5vdCBpbiBsaW5lIHdpdGggbW9yZQ0KPnJl Y2VudCByZWNvbW1lbmRhdGlvbnMgaW4gUkZDNjE1OC4NCj4NCj5UaGFua3MsDQo+V29qLg0KPg0K Pj4gDQo+PiAtLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UNCj4+IEZyb206IExlYWYgeWVoIDxsZWFm LnkueWVoQGh1YXdlaS5jb20+DQo+PiBEYXRlOiBUaHUsIDE2IEZlYiAyMDEyIDEyOjA1OjQ0ICsw MDAwDQo+PiBUbzogV29qY2llY2ggRGVjIDx3ZGVjQGNpc2NvLmNvbT4sIEJlcm5hcmQgQWJvYmEN Cj4+PGJlcm5hcmRfYWJvYmFAaG90bWFpbC5jb20+DQo+PiBDYzogInJhZGV4dEBpZXRmLm9yZyIg PHJhZGV4dEBpZXRmLm9yZz4sICJmaW5lX3N6QGh1YXdlaS5jb20iDQo+PiA8ZmluZV9zekBodWF3 ZWkuY29tPiwgU3RlZmFuIFdpbnRlciA8c3RlZmFuLndpbnRlckByZXN0ZW5hLmx1Pg0KPj4gU3Vi amVjdDogUmU6IFtyYWRleHRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNj ZXNzLTA2LnR4dA0KPj4gDQo+PiBXb2pjaWVjaCAtIHRoZSBSb3V0ZS1JUHY2LUluZm9ybWF0aW9u IGF0dHJpYnV0ZSBjaGFuZ2VkIGZyb20gaXRzDQo+PiBwcmV2aW91cyAibm9uIGNvbXBsZXgiIHRv IHRoZSBjdXJyZW50IGZvcm0gYmV0d2VlbiBkcmFmdCAwNCBhbmQgMDUsDQo+PmJhc2VkIG9uDQo+ PiBXRyByZXZpZXcvZmVlZGJhY2s6DQo+PiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9y YWRleHQvdHJhYy90aWNrZXQvNzENCj4+IA0KPj4gDQo+PiBBcyBwZXIgdGhlIHJlcXVpcmVtZW50 IGluIHRoZSBzZWN0aW9uIDIuMSBvZiBSRkM2MTU4LA0KPj4gDQo+PiA8cXVvdGU+U2luY2UgdGhl cmUgYXJlIG5vICJoYXJkIGFuZCBmYXN0Ig0KPj4gcnVsZXMgZm9yIHdoZXJlIGNvbXBsZXhpdHkg aXMgYmVzdCBsb2NhdGVkLCBlYWNoIHNpdHVhdGlvbiBoYXMgdG8gYmUNCj4+IGRlY2lkZWQgb24g YSBjYXNlLWJ5LWNhc2UgYmFzaXMuLi5XaGVyZSBhIGNvbXBsZXggZGF0YSB0eXBlIGlzDQo+PnNl bGVjdGVkLCBhbg0KPj4gZXhwbGFuYXRpb24gU0hPVUxEIGJlIG9mZmVyZWQgYXMgdG8gd2h5IHRo aXMgd2FzIG5lY2Vzc2FyeS48L3F1b3RlPg0KPj4gDQo+PiB3b3VsZCB5b3UgY2xhcmlmeSB0aGUg cmVhc29uIGZvciB0aGUgYWRvcHRpb24gb2YgdGhlICdjb21wbGV4IGRhdGENCj4+dHlwZScgaW4N Cj4+IHRoZSBkZWZpbml0aW9uIG9mIGF0dHJpYnV0ZSwgUm91dGUtSVB2Ni1JbmZvcm1hdGlvbj8N Cj4+IA0KPj4gSSBjYW6p9nQgZmluZCB0aGUgYW5zd2VyIGluIHRoZSBmb2xsb3dpbmcgbGlua3M6 DQo+PiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9yYWRleHQvdHJhYy90aWNrZXQvNzEg Jg0KPj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJhZGV4 dC1pcHY2LWFjY2Vzcy0wNSAuDQo+PiANCj4+IFRoZSBkZWZpbml0aW9uIG9mIHRoZSBhdHRyaWJ1 dGUgd2l0aG91dCBtdWx0aS1maWVsZHMgc291bmRzICdvaycgd2l0aCBtZQ0KPj4gcGVyc29uYWxs eSwgYnV0IFJGQzYxNTggKCYgaXRzIHNlY3Rpb24gQS4yLjEpIHNlZW1zIG5vdCByZWNvbW1lbmRl ZCBpdC4NCj4+IA0KPj4gSXMgbXkgdW5kZXJzdGFuZGluZyByaWdodCBoZXJlPw0KPj4gDQo+PiAN Cj4+IEJlc3QgUmVnYXJkcywNCj4+IExlYWYNCj4+IA0KPj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4gRnJvbTogV29qY2llY2ggRGVjIFttYWlsdG86d2RlY0BjaXNjby5jb21d DQo+PiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE1LCAyMDEyIDg6MjQgUE0NCj4+IFRvOiBB bGFuIERlS29rOyBMZWFmIHllaA0KPj4gQ2M6IHJhZGV4dEBpZXRmLm9yZzsgU3RlZmFuIFdpbnRl cjsgZmluZV9zekBodWF3ZWkuY29tDQo+PiBTdWJqZWN0OiBSZTogW3JhZGV4dF0gSS1EIEFjdGlv bjogZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3MtMDYudHh0DQo+PiANCj4+IEp1c3QgYXMg YW4gRllJLCB0aGUgUm91dGUtSVB2Ni1JbmZvcm1hdGlvbiBhdHRyaWJ1dGUgY2hhbmdlZCBmcm9t IGl0cw0KPj4gcHJldmlvdXMgIm5vbiBjb21wbGV4IiB0byB0aGUgY3VycmVudCBmb3JtIGJldHdl ZW4gZHJhZnQgMDQgYW5kIDA1LA0KPj5iYXNlZCBvbg0KPj4gV0cgcmV2aWV3L2ZlZWRiYWNrOg0K Pj4gaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvcmFkZXh0L3RyYWMvdGlja2V0LzcxDQo+ PiANCj4+IC1Xb2pjaWVjaC4NCj4+IA0KPj4gDQo+PiANCj4+IE9uIDE1LzAyLzIwMTIgMTM6MDUs ICJBbGFuIERlS29rIiA8YWxhbmRAZGVwbG95aW5ncmFkaXVzLmNvbT4gd3JvdGU6DQo+PiANCj4+ PiBMZWFmIHllaCB3cm90ZToNCj4+Pj4gQWZ0ZXIgcmVhZGluZyBhbmQgZW1wbG95ZWQgdGhlIFJG QzYxNTgsIFJhZGl1cyBEZXNpZ24gR3VpZGVsaW5lcywNCj4+Pj5jb3VsZCBpdA0KPj4+PiBiZQ0K Pj4+PiBjb25jbHVkZWQgdGhlIGF0dHJpYnV0ZSBvZiBSb3V0ZS1JUHY2LUluZm9ybWF0aW9uIGRl ZmluZWQgaW4gdGhlDQo+Pj4+IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzLTA2IHNob3du IGFzIGZvbGxvd3M6DQo+Pj4gLi4NCj4+Pj4gaXMgY3JlYXRpbmcgYSBuZXcgJ0NvbXBsZXggRGF0 YSBUeXBlJywgd2hpY2ggaGFzIG11bHRpLWZpZWxkcywgYW5kIGlzDQo+Pj4+bm90DQo+Pj4+IHJl Y29tbWVuZGVkPyANCj4+PiANCj4+PiAgIFRoYXQgaXMgd2hhdCB0aGUgZG9jdW1lbnQgc2F5cy4N Cj4+PiANCj4+Pj4gV2lsbCBpdCBnZXQgdGhlIHNhbWUgJ2FjY2VwdGFibGUnIGFzIHRoYXQgb2Yg RnJhbWUtSVB2Ni1QcmVmaXggKDk3KQ0KPj4+PmFuZA0KPj4+PiBEZWxlZ2F0ZWQtSVB2Ni1QcmVm aXgoMTIzKSwgd2hpY2ggaXMgbWVudGlvbmVkIGluIFNlY3Rpb24gQi43IG9mDQo+Pj4+UkZDNjE1 OD8NCj4+PiANCj4+PiAgIE5vLg0KPj4+IA0KPj4+ICAgSSBjb3VsZCBleHBsYWluIGhlcmUsIGJ1 dCB0aGVyZSdzIG5vIG5lZWQuICBSZWFkIFJGQyA2MTU4LiAgSXQNCj4+PiB0aG9yb3VnaGx5IGRl dGFpbHMgdGhlIHJhdGlvbmFsZSBiZWhpbmQgdGhlIGRlc2lnbiBndWlkZWxpbmVzLg0KPj4+IA0K Pj4+ICAgQWxhbiBEZUtvay4NCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj5yYWRleHQgbWFpbGluZw0KPj4gbGlzdA0KPnJhZGV4dEBpZXRm Lm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0DQo+DQo+ PiANCj4+IC0tLS0tLSBFbmQgb2YgRm9yd2FyZGVkIE1lc3NhZ2UNCj4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcmFkZXh0IG1haWxpbmcgbGlzdApy YWRleHRAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yYWRl eHQK From mauricio.sanchez@hp.com Tue Mar 13 10:10:58 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1D121E8034 for ; Tue, 13 Mar 2012 10:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.722 X-Spam-Level: X-Spam-Status: No, score=-107.722 tagged_above=-999 required=5 tests=[AWL=-2.877, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 l8LgOxL7b2xT for ; Tue, 13 Mar 2012 10:10:57 -0700 (PDT) Received: from g6t0185.atlanta.hp.com (g6t0185.atlanta.hp.com [15.193.32.62]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1B521E8021 for ; Tue, 13 Mar 2012 10:10:57 -0700 (PDT) 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 g6t0185.atlanta.hp.com (Postfix) with ESMTPS id 64C9B24143; Tue, 13 Mar 2012 17:10:56 +0000 (UTC) Received: from G6W0173.americas.hpqcorp.net (16.230.33.182) by G1W0400.americas.hpqcorp.net (16.236.31.10) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 13 Mar 2012 17:09:51 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G6W0173.americas.hpqcorp.net ([16.230.33.182]) with mapi; Tue, 13 Mar 2012 17:09:51 +0000 From: "Sanchez, Mauricio (HP Networking)" To: Wojciech Dec , "jouni.nospam@gmail.com" Date: Tue, 13 Mar 2012 17:09:05 +0000 Thread-Topic: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt Thread-Index: Ac0BPBpHnetohAALRPa9LFwNG1pvFg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Bernard Aboba , "radext@ietf.org" Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 17:10:58 -0000 DQpSQURFWFQsIGxpa2UgYW55IGdvb2QgSUVURiBXRywgaGFzIGEgY29sb3JmdWwgaGlzdG9yeSBh bmQgc29tZXRpbWVzIGEgYml0DQpzY2hpem9waHJlbmljLCBhcyB0aGlzIHBhcnRpY3VsYXIgY2Fz ZSBjYW4gYXR0ZXN0IHRvLiAgSSB0aGluayB3ZSBjYW4gYWxsDQphZ3JlZSB0aGF0IHRoZSBpcHY2 IGF0dHJpYnV0ZWQgbm90ZWQgYmVsb3cgaXMgb2YgYSBjb21wbGV4IHR5cGUgYW5kIGluDQpjb25m bGljdCB3aXRoIFJGQzYxNTggbWFuZGF0ZSB0byBub3QgY29udGludWUgdG8gcHJvbXVsZ2F0ZSBz dWNoIGNvbXBsZXgNCnR5cGVzLiBIb3dldmVyLCBSRkM2MTU4IGFsc28gaW5jbHVkZXMgYSBzaWdu aWZpY2FudCBhbW91bnQgb2YgbGVld2F5LiAgSQ0KdGhpbmsgd2UgaGF2ZSB0d28gb3B0aW9ucyBi ZWZvcmUgdXM6DQoNCigxKSBQZXIgUkZDNjE1OCdzIG1hbmRhdGUgaW5jbHVkZSBhIHNtYWxsIHN0 YXRlbWVudCBqdXN0aWZ5aW5nIHRoZSBjb21wbGV4DQphdHRyaWJ1dGUgYXMgaXQgc3RhbmRzIG5v dy4gIFN0YXRlbWVudCB3b3VsZCBiZSBzaW1pbGFyIGluIHNwaXJpdCB0byB3aGF0DQphcHBlbmRp eCBCIGluIFJGQzYxNTggZG9lcyBmb3Igb3RoZXIgY29tcGxleCBhdHRyaWJ1dGVzDQoNCigyKSBS ZWNhc3QgdGhlIGRlc2lnbiBvZiBhdHRyaWJ1dGUgaW50byBhIG5ldyBmb3JtIHRoYXQgcmVkdWNl cyBpdHMNCmNvbXBsZXhpdHkgKGkuZS4gTG9vayB0byBmb2xsb3cgUkZDNjE1OCBtb3JlIGNsb3Nl bHkpLg0KDQpJZiB3ZSBhZ3JlZSB0aGVzZSBhcmUgdGhlIHR3byBvcHRpb25zIGJlZm9yZSB1cywg d2UgY2FuIGRvIGNvbnNlbnN1cyBjaGVjaw0Kb24gd2hpY2ggYXBwcm9hY2ggdGhlIFdHIHdvdWxk IGxpa2UgdG8gdGFrZS4NCg0KLU1TIA0KDQoNCg0KDQoNCk9uIDMvOC8xMiAxMToxNyBBTSwgIldv amNpZWNoIERlYyIgPHdkZWNAY2lzY28uY29tPiB3cm90ZToNCg0KPkhlbGxvIENoYWlycywgYWxs LA0KPg0KPldvdWxkIGFwcHJlY2lhdGUgV0cgZmVlZGJhY2sgb24gaG93IHRvIGhhbmRsZSB0aGUg Y29tbWVudChzKS4gT24NCj50aGUgb25lIGhhbmQsIHRoZSBjdXJyZW50IGZvcm1hdCBvZiB0aGUg YXR0cmlidXRlIHJlcHJlc2VudHMgdGhlIHJlc3VsdCBvZg0KPmNvbnNlbnRlZCBwcmV2aW91cyBX RyBmZWVkYmFjaywgb24gdGhlIG90aGVyIGl0IGlzIG5vdCBpbiBsaW5lIHdpdGggbW9yZQ0KPnJl Y2VudCByZWNvbW1lbmRhdGlvbnMgaW4gUkZDNjE1OC4NCj4NCj5UaGFua3MsDQo+V29qLg0KPg0K Pj4gDQo+PiAtLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UNCj4+IEZyb206IExlYWYgeWVoIDxsZWFm LnkueWVoQGh1YXdlaS5jb20+DQo+PiBEYXRlOiBUaHUsIDE2IEZlYiAyMDEyIDEyOjA1OjQ0ICsw MDAwDQo+PiBUbzogV29qY2llY2ggRGVjIDx3ZGVjQGNpc2NvLmNvbT4sIEJlcm5hcmQgQWJvYmEN Cj4+PGJlcm5hcmRfYWJvYmFAaG90bWFpbC5jb20+DQo+PiBDYzogInJhZGV4dEBpZXRmLm9yZyIg PHJhZGV4dEBpZXRmLm9yZz4sICJmaW5lX3N6QGh1YXdlaS5jb20iDQo+PiA8ZmluZV9zekBodWF3 ZWkuY29tPiwgU3RlZmFuIFdpbnRlciA8c3RlZmFuLndpbnRlckByZXN0ZW5hLmx1Pg0KPj4gU3Vi amVjdDogUmU6IFtyYWRleHRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNj ZXNzLTA2LnR4dA0KPj4gDQo+PiBXb2pjaWVjaCAtIHRoZSBSb3V0ZS1JUHY2LUluZm9ybWF0aW9u IGF0dHJpYnV0ZSBjaGFuZ2VkIGZyb20gaXRzDQo+PiBwcmV2aW91cyAibm9uIGNvbXBsZXgiIHRv IHRoZSBjdXJyZW50IGZvcm0gYmV0d2VlbiBkcmFmdCAwNCBhbmQgMDUsDQo+PmJhc2VkIG9uDQo+ PiBXRyByZXZpZXcvZmVlZGJhY2s6DQo+PiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9y YWRleHQvdHJhYy90aWNrZXQvNzENCj4+IA0KPj4gDQo+PiBBcyBwZXIgdGhlIHJlcXVpcmVtZW50 IGluIHRoZSBzZWN0aW9uIDIuMSBvZiBSRkM2MTU4LA0KPj4gDQo+PiA8cXVvdGU+U2luY2UgdGhl cmUgYXJlIG5vICJoYXJkIGFuZCBmYXN0Ig0KPj4gcnVsZXMgZm9yIHdoZXJlIGNvbXBsZXhpdHkg aXMgYmVzdCBsb2NhdGVkLCBlYWNoIHNpdHVhdGlvbiBoYXMgdG8gYmUNCj4+IGRlY2lkZWQgb24g YSBjYXNlLWJ5LWNhc2UgYmFzaXMuLi5XaGVyZSBhIGNvbXBsZXggZGF0YSB0eXBlIGlzDQo+PnNl bGVjdGVkLCBhbg0KPj4gZXhwbGFuYXRpb24gU0hPVUxEIGJlIG9mZmVyZWQgYXMgdG8gd2h5IHRo aXMgd2FzIG5lY2Vzc2FyeS48L3F1b3RlPg0KPj4gDQo+PiB3b3VsZCB5b3UgY2xhcmlmeSB0aGUg cmVhc29uIGZvciB0aGUgYWRvcHRpb24gb2YgdGhlICdjb21wbGV4IGRhdGENCj4+dHlwZScgaW4N Cj4+IHRoZSBkZWZpbml0aW9uIG9mIGF0dHJpYnV0ZSwgUm91dGUtSVB2Ni1JbmZvcm1hdGlvbj8N Cj4+IA0KPj4gSSBjYW6p9nQgZmluZCB0aGUgYW5zd2VyIGluIHRoZSBmb2xsb3dpbmcgbGlua3M6 DQo+PiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9yYWRleHQvdHJhYy90aWNrZXQvNzEg Jg0KPj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJhZGV4 dC1pcHY2LWFjY2Vzcy0wNSAuDQo+PiANCj4+IFRoZSBkZWZpbml0aW9uIG9mIHRoZSBhdHRyaWJ1 dGUgd2l0aG91dCBtdWx0aS1maWVsZHMgc291bmRzICdvaycgd2l0aCBtZQ0KPj4gcGVyc29uYWxs eSwgYnV0IFJGQzYxNTggKCYgaXRzIHNlY3Rpb24gQS4yLjEpIHNlZW1zIG5vdCByZWNvbW1lbmRl ZCBpdC4NCj4+IA0KPj4gSXMgbXkgdW5kZXJzdGFuZGluZyByaWdodCBoZXJlPw0KPj4gDQo+PiAN Cj4+IEJlc3QgUmVnYXJkcywNCj4+IExlYWYNCj4+IA0KPj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4gRnJvbTogV29qY2llY2ggRGVjIFttYWlsdG86d2RlY0BjaXNjby5jb21d DQo+PiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE1LCAyMDEyIDg6MjQgUE0NCj4+IFRvOiBB bGFuIERlS29rOyBMZWFmIHllaA0KPj4gQ2M6IHJhZGV4dEBpZXRmLm9yZzsgU3RlZmFuIFdpbnRl cjsgZmluZV9zekBodWF3ZWkuY29tDQo+PiBTdWJqZWN0OiBSZTogW3JhZGV4dF0gSS1EIEFjdGlv bjogZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3MtMDYudHh0DQo+PiANCj4+IEp1c3QgYXMg YW4gRllJLCB0aGUgUm91dGUtSVB2Ni1JbmZvcm1hdGlvbiBhdHRyaWJ1dGUgY2hhbmdlZCBmcm9t IGl0cw0KPj4gcHJldmlvdXMgIm5vbiBjb21wbGV4IiB0byB0aGUgY3VycmVudCBmb3JtIGJldHdl ZW4gZHJhZnQgMDQgYW5kIDA1LA0KPj5iYXNlZCBvbg0KPj4gV0cgcmV2aWV3L2ZlZWRiYWNrOg0K Pj4gaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvcmFkZXh0L3RyYWMvdGlja2V0LzcxDQo+ PiANCj4+IC1Xb2pjaWVjaC4NCj4+IA0KPj4gDQo+PiANCj4+IE9uIDE1LzAyLzIwMTIgMTM6MDUs ICJBbGFuIERlS29rIiA8YWxhbmRAZGVwbG95aW5ncmFkaXVzLmNvbT4gd3JvdGU6DQo+PiANCj4+ PiBMZWFmIHllaCB3cm90ZToNCj4+Pj4gQWZ0ZXIgcmVhZGluZyBhbmQgZW1wbG95ZWQgdGhlIFJG QzYxNTgsIFJhZGl1cyBEZXNpZ24gR3VpZGVsaW5lcywNCj4+Pj5jb3VsZCBpdA0KPj4+PiBiZQ0K Pj4+PiBjb25jbHVkZWQgdGhlIGF0dHJpYnV0ZSBvZiBSb3V0ZS1JUHY2LUluZm9ybWF0aW9uIGRl ZmluZWQgaW4gdGhlDQo+Pj4+IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzLTA2IHNob3du IGFzIGZvbGxvd3M6DQo+Pj4gLi4NCj4+Pj4gaXMgY3JlYXRpbmcgYSBuZXcgJ0NvbXBsZXggRGF0 YSBUeXBlJywgd2hpY2ggaGFzIG11bHRpLWZpZWxkcywgYW5kIGlzDQo+Pj4+bm90DQo+Pj4+IHJl Y29tbWVuZGVkPyANCj4+PiANCj4+PiAgIFRoYXQgaXMgd2hhdCB0aGUgZG9jdW1lbnQgc2F5cy4N Cj4+PiANCj4+Pj4gV2lsbCBpdCBnZXQgdGhlIHNhbWUgJ2FjY2VwdGFibGUnIGFzIHRoYXQgb2Yg RnJhbWUtSVB2Ni1QcmVmaXggKDk3KQ0KPj4+PmFuZA0KPj4+PiBEZWxlZ2F0ZWQtSVB2Ni1QcmVm aXgoMTIzKSwgd2hpY2ggaXMgbWVudGlvbmVkIGluIFNlY3Rpb24gQi43IG9mDQo+Pj4+UkZDNjE1 OD8NCj4+PiANCj4+PiAgIE5vLg0KPj4+IA0KPj4+ICAgSSBjb3VsZCBleHBsYWluIGhlcmUsIGJ1 dCB0aGVyZSdzIG5vIG5lZWQuICBSZWFkIFJGQyA2MTU4LiAgSXQNCj4+PiB0aG9yb3VnaGx5IGRl dGFpbHMgdGhlIHJhdGlvbmFsZSBiZWhpbmQgdGhlIGRlc2lnbiBndWlkZWxpbmVzLg0KPj4+IA0K Pj4+ICAgQWxhbiBEZUtvay4NCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj5yYWRleHQgbWFpbGluZw0KPj4gbGlzdA0KPnJhZGV4dEBpZXRm Lm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0DQo+DQo+ PiANCj4+IC0tLS0tLSBFbmQgb2YgRm9yd2FyZGVkIE1lc3NhZ2UNCj4NCg0K From mauricio.sanchez@hp.com Wed Mar 14 00:56:49 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E10421F8697 for ; Wed, 14 Mar 2012 00:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.12 X-Spam-Level: X-Spam-Status: No, score=-110.12 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 540CQq7-d9Cb for ; Wed, 14 Mar 2012 00:56:48 -0700 (PDT) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCBF21F868A for ; Wed, 14 Mar 2012 00:56:48 -0700 (PDT) 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 g4t0017.houston.hp.com (Postfix) with ESMTPS id CD1EF385A6; Wed, 14 Mar 2012 07:56:47 +0000 (UTC) Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G2W1953G.americas.hpqcorp.net (16.238.8.185) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 14 Mar 2012 07:55:33 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Wed, 14 Mar 2012 07:55:33 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Wed, 14 Mar 2012 07:55:24 +0000 Thread-Topic: IETF 83: Draft agenda Thread-Index: Ac0Bt9UHNGxJAWT6TKqf866+MSFTSQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jouni.nospam@gmail.com" Subject: [radext] IETF 83: Draft 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: Wed, 14 Mar 2012 07:56:49 -0000 At IETF 83 RADEXT has a two-hour time slot allocated. Below is the draft a= genda. Please respond with any suggested changes or comments. Regards, MS --------------- RADEXT WG IETF 83 Agenda Chairs: Jouni Korhonen Mauricio Sanchez Jabber room: radext at jabber.ietf.org (Please join) Friday, March 30, 2012 0900-1100 Room 212/213 9:00 - 09:15 AM, Preliminaries (15 minutes) Audio/Video & Remote Presentation Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status Draft discussion (60 minutes) 9:15 - 9:30 AM RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec (15 = minutes) http://tools.ietf.org/html/draft-ietf-radext-ipv6-access 9:30 - 9:45 AM RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh= (15 minutes) http://tools.ietf.org/html/draft-yeh-radext-ext-traffic-statistics 9:45 - 10:00 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (15 = minutes) http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt 10:00 - 10:15 AM RADIUS Protocol Extensions, Alan DeKok (15 minutes) http://tools.ietf.org/html/draft-ietf-radext-radius-extensions Rechartering and Wrap-up (45 minutes) 10:15 - 10:45 AM Rechartering/ New Milestones (30 minutes) 10:45 - 11:00 AM Next Steps: WG Chairs & ADs (15 minutes) WG Goals/Milestones status, next steps From radext-bounces@ietf.org Wed Mar 14 00:56:51 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CCE21F8697; Wed, 14 Mar 2012 00:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331711811; bh=7q0iUBiV37VpY0k7Ov+1vkJA03ET8lhr5Av44SEUIXM=; h=From:To:Date: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=NtDMepgDk0g+POzH8s+26XIHZOyEkcrVQcUEs152ffqqeLyGW1o7F242y56JSRNqX 51vLIavKmbvsuVEwj9Iypai1xiubx9SOnMC6po2DlTBY8ORGXRsAlNS7g69lEMSgzi DgKZJvOif+QtN5vzSGmgPE9RtRDqiPmi8iuPm7AE= 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 2E10421F8697 for ; Wed, 14 Mar 2012 00:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.12 X-Spam-Level: X-Spam-Status: No, score=-110.12 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 540CQq7-d9Cb for ; Wed, 14 Mar 2012 00:56:48 -0700 (PDT) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCBF21F868A for ; Wed, 14 Mar 2012 00:56:48 -0700 (PDT) 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 g4t0017.houston.hp.com (Postfix) with ESMTPS id CD1EF385A6; Wed, 14 Mar 2012 07:56:47 +0000 (UTC) Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G2W1953G.americas.hpqcorp.net (16.238.8.185) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 14 Mar 2012 07:55:33 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Wed, 14 Mar 2012 07:55:33 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Wed, 14 Mar 2012 07:55:24 +0000 Thread-Topic: IETF 83: Draft agenda Thread-Index: Ac0Bt9UHNGxJAWT6TKqf866+MSFTSQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US MIME-Version: 1.0 Cc: "jouni.nospam@gmail.com" Subject: [radext] IETF 83: Draft 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org At IETF 83 RADEXT has a two-hour time slot allocated. Below is the draft agenda. Please respond with any suggested changes or comments. Regards, MS --------------- RADEXT WG IETF 83 Agenda Chairs: Jouni Korhonen Mauricio Sanchez Jabber room: radext at jabber.ietf.org (Please join) Friday, March 30, 2012 0900-1100 Room 212/213 9:00 - 09:15 AM, Preliminaries (15 minutes) Audio/Video & Remote Presentation Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status Draft discussion (60 minutes) 9:15 - 9:30 AM RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec (15 minutes) http://tools.ietf.org/html/draft-ietf-radext-ipv6-access 9:30 - 9:45 AM RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh (15 minutes) http://tools.ietf.org/html/draft-yeh-radext-ext-traffic-statistics 9:45 - 10:00 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (15 minutes) http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt 10:00 - 10:15 AM RADIUS Protocol Extensions, Alan DeKok (15 minutes) http://tools.ietf.org/html/draft-ietf-radext-radius-extensions Rechartering and Wrap-up (45 minutes) 10:15 - 10:45 AM Rechartering/ New Milestones (30 minutes) 10:45 - 11:00 AM Next Steps: WG Chairs & ADs (15 minutes) WG Goals/Milestones status, next steps _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From wdec@cisco.com Wed Mar 14 02:59:15 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1480021F85C0 for ; Wed, 14 Mar 2012 02:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.368 X-Spam-Level: X-Spam-Status: No, score=-110.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFbn2RWUuNoK for ; Wed, 14 Mar 2012 02:59:14 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 86EEA21F8688 for ; Wed, 14 Mar 2012 02:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=5258; q=dns/txt; s=iport; t=1331719153; x=1332928753; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=zmwVLHq5yXd6Ofs7lgT/0TzhNQJay+BGA1pWDhjRD9U=; b=cHqTGMvwfkEwR+ujvkm8aqqPYBxvZsHrM4oaTsw4RtkEgKLldJeWujnH tT4swXoClkAnYXUbVgHoFGE/V+kKyrkXe0xvbYGs9MnWw4EZipeyNDsHS BrUpWXkGGiDz2b28D2Co5twaIedrU84uaCYhHi6enPbJK5a6jj/N4+ton U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8GACFrYE+Q/khN/2dsb2JhbABDpEmRT4EHggkBAQEEAQEBDwEdPgsMBAIBCBEDAQEBAQoGFwEGASAGHwkIAQEEARIIGodoC50RAZ8diUSGUWMEiCSYYIR4gmc X-IronPort-AV: E=Sophos;i="4.73,583,1325462400"; d="scan'208";a="68440157" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 14 Mar 2012 09:59:09 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2E9x96H001690; Wed, 14 Mar 2012 09:59:09 GMT Received: from xmb-ams-112.cisco.com ([144.254.74.87]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Mar 2012 10:59:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Mar 2012 10:58:34 +0100 Message-ID: <671F3F6039F35F48B458F3E382BC8D610121D648@XMB-AMS-112.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt Thread-Index: Ac0BPBpHnetohAALRPa9LFwNG1pvFgAjKKbQ References: From: "Wojciech Dec (wdec)" To: "Sanchez, Mauricio (HP Networking)" , X-OriginalArrivalTime: 14 Mar 2012 09:59:09.0972 (UTC) FILETIME=[19FDA540:01CD01C9] Cc: Bernard Aboba , radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 09:59:15 -0000 Personally, I'm ok either way, but perhaps in the wider interest of = closing off on the draft sooner rather than later I'd vote for (1). What = about the rest of the WG? Regards, Woj. > -----Original Message----- > From: Sanchez, Mauricio (HP Networking) > [mailto:mauricio.sanchez@hp.com] > Sent: 13 March 2012 18:09 > To: Wojciech Dec (wdec); jouni.nospam@gmail.com > Cc: Bernard Aboba; radext@ietf.org > Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt >=20 >=20 > RADEXT, like any good IETF WG, has a colorful history and sometimes a > bit > schizophrenic, as this particular case can attest to. I think we can > all > agree that the ipv6 attributed noted below is of a complex type and in > conflict with RFC6158 mandate to not continue to promulgate such > complex > types. However, RFC6158 also includes a significant amount of leeway. > I > think we have two options before us: >=20 > (1) Per RFC6158's mandate include a small statement justifying the > complex > attribute as it stands now. Statement would be similar in spirit to > what > appendix B in RFC6158 does for other complex attributes >=20 > (2) Recast the design of attribute into a new form that reduces its > complexity (i.e. Look to follow RFC6158 more closely). >=20 > If we agree these are the two options before us, we can do consensus > check > on which approach the WG would like to take. >=20 > -MS >=20 >=20 >=20 >=20 >=20 > On 3/8/12 11:17 AM, "Wojciech Dec" wrote: >=20 > >Hello Chairs, all, > > > >Would appreciate WG feedback on how to handle the comment(s). On > >the one hand, the current format of the attribute represents the > result of > >consented previous WG feedback, on the other it is not in line with > more > >recent recommendations in RFC6158. > > > >Thanks, > >Woj. > > > >> > >> ------ Forwarded Message > >> From: Leaf yeh > >> Date: Thu, 16 Feb 2012 12:05:44 +0000 > >> To: Wojciech Dec , Bernard Aboba > >> > >> Cc: "radext@ietf.org" , "fine_sz@huawei.com" > >> , Stefan Winter > >> Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access- > 06.txt > >> > >> Wojciech - the Route-IPv6-Information attribute changed from its > >> previous "non complex" to the current form between draft 04 and 05, > >>based on > >> WG review/feedback: > >> http://trac.tools.ietf.org/wg/radext/trac/ticket/71 > >> > >> > >> As per the requirement in the section 2.1 of RFC6158, > >> > >> Since there are no "hard and fast" > >> rules for where complexity is best located, each situation has to = be > >> decided on a case-by-case basis...Where a complex data type is > >>selected, an > >> explanation SHOULD be offered as to why this was necessary. > >> > >> would you clarify the reason for the adoption of the 'complex data > >>type' in > >> the definition of attribute, Route-IPv6-Information? > >> > >> I can=B9t find the answer in the following links: > >> http://trac.tools.ietf.org/wg/radext/trac/ticket/71 & > >> = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ipv6-access-05 > . > >> > >> The definition of the attribute without multi-fields sounds 'ok' > with me > >> personally, but RFC6158 (& its section A.2.1) seems not recommended > it. > >> > >> Is my understanding right here? > >> > >> > >> Best Regards, > >> Leaf > >> > >> > >> -----Original Message----- > >> From: Wojciech Dec [mailto:wdec@cisco.com] > >> Sent: Wednesday, February 15, 2012 8:24 PM > >> To: Alan DeKok; Leaf yeh > >> Cc: radext@ietf.org; Stefan Winter; fine_sz@huawei.com > >> Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access- > 06.txt > >> > >> Just as an FYI, the Route-IPv6-Information attribute changed from > its > >> previous "non complex" to the current form between draft 04 and 05, > >>based on > >> WG review/feedback: > >> http://trac.tools.ietf.org/wg/radext/trac/ticket/71 > >> > >> -Wojciech. > >> > >> > >> > >> On 15/02/2012 13:05, "Alan DeKok" = wrote: > >> > >>> Leaf yeh wrote: > >>>> After reading and employed the RFC6158, Radius Design Guidelines, > >>>>could it > >>>> be > >>>> concluded the attribute of Route-IPv6-Information defined in the > >>>> draft-ietf-radext-ipv6-access-06 shown as follows: > >>> .. > >>>> is creating a new 'Complex Data Type', which has multi-fields, = and > is > >>>>not > >>>> recommended? > >>> > >>> That is what the document says. > >>> > >>>> Will it get the same 'acceptable' as that of Frame-IPv6-Prefix > (97) > >>>>and > >>>> Delegated-IPv6-Prefix(123), which is mentioned in Section B.7 of > >>>>RFC6158? > >>> > >>> No. > >>> > >>> I could explain here, but there's no need. Read RFC 6158. It > >>> thoroughly details the rationale behind the design guidelines. > >>> > >>> Alan DeKok. > >> > >> _______________________________________________ > >radext mailing > >> list > >radext@ietf.org > >https://www.ietf.org/mailman/listinfo/radext > > > >> > >> ------ End of Forwarded Message > > From radext-bounces@ietf.org Wed Mar 14 02:59:17 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674F721F8688; Wed, 14 Mar 2012 02:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331719157; bh=u+9sdeRgJXMjiTojOTjL6YeMVs0s2s9tG7UoRGQc8S8=; h=MIME-Version:Date:Message-ID:In-Reply-To:References:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=UEiCbJWYLefJQGR2okwwbwsJ7ElIf3AmcB9VIufkqTLGjHSCJKm/R9yB2l0BSGrbF CkPD/DXYnw/4haFiTqE7vh/0v5AQtjTIU3xpQRUg5ytXnXIU4oNQZmU30zIe1Vvt/Q 7EfRi4CZt8dr0L3kQBM6lu/KwreGUrFoleLW8SWM= 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 1480021F85C0 for ; Wed, 14 Mar 2012 02:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.368 X-Spam-Level: X-Spam-Status: No, score=-110.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFbn2RWUuNoK for ; Wed, 14 Mar 2012 02:59:14 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 86EEA21F8688 for ; Wed, 14 Mar 2012 02:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=5258; q=dns/txt; s=iport; t=1331719153; x=1332928753; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=zmwVLHq5yXd6Ofs7lgT/0TzhNQJay+BGA1pWDhjRD9U=; b=cHqTGMvwfkEwR+ujvkm8aqqPYBxvZsHrM4oaTsw4RtkEgKLldJeWujnH tT4swXoClkAnYXUbVgHoFGE/V+kKyrkXe0xvbYGs9MnWw4EZipeyNDsHS BrUpWXkGGiDz2b28D2Co5twaIedrU84uaCYhHi6enPbJK5a6jj/N4+ton U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8GACFrYE+Q/khN/2dsb2JhbABDpEmRT4EHggkBAQEEAQEBDwEdPgsMBAIBCBEDAQEBAQoGFwEGASAGHwkIAQEEARIIGodoC50RAZ8diUSGUWMEiCSYYIR4gmc X-IronPort-AV: E=Sophos;i="4.73,583,1325462400"; d="scan'208";a="68440157" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 14 Mar 2012 09:59:09 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2E9x96H001690; Wed, 14 Mar 2012 09:59:09 GMT Received: from xmb-ams-112.cisco.com ([144.254.74.87]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Mar 2012 10:59:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Mar 2012 10:58:34 +0100 Message-ID: <671F3F6039F35F48B458F3E382BC8D610121D648@XMB-AMS-112.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt Thread-Index: Ac0BPBpHnetohAALRPa9LFwNG1pvFgAjKKbQ References: From: "Wojciech Dec (wdec)" To: "Sanchez, Mauricio (HP Networking)" , X-OriginalArrivalTime: 14 Mar 2012 09:59:09.0972 (UTC) FILETIME=[19FDA540:01CD01C9] Cc: Bernard Aboba , radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Personally, I'm ok either way, but perhaps in the wider interest of closing= off on the draft sooner rather than later I'd vote for (1). What about the= rest of the WG? Regards, Woj. > -----Original Message----- > From: Sanchez, Mauricio (HP Networking) > [mailto:mauricio.sanchez@hp.com] > Sent: 13 March 2012 18:09 > To: Wojciech Dec (wdec); jouni.nospam@gmail.com > Cc: Bernard Aboba; radext@ietf.org > Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt > = > = > RADEXT, like any good IETF WG, has a colorful history and sometimes a > bit > schizophrenic, as this particular case can attest to. I think we can > all > agree that the ipv6 attributed noted below is of a complex type and in > conflict with RFC6158 mandate to not continue to promulgate such > complex > types. However, RFC6158 also includes a significant amount of leeway. > I > think we have two options before us: > = > (1) Per RFC6158's mandate include a small statement justifying the > complex > attribute as it stands now. Statement would be similar in spirit to > what > appendix B in RFC6158 does for other complex attributes > = > (2) Recast the design of attribute into a new form that reduces its > complexity (i.e. Look to follow RFC6158 more closely). > = > If we agree these are the two options before us, we can do consensus > check > on which approach the WG would like to take. > = > -MS > = > = > = > = > = > On 3/8/12 11:17 AM, "Wojciech Dec" wrote: > = > >Hello Chairs, all, > > > >Would appreciate WG feedback on how to handle the comment(s). On > >the one hand, the current format of the attribute represents the > result of > >consented previous WG feedback, on the other it is not in line with > more > >recent recommendations in RFC6158. > > > >Thanks, > >Woj. > > > >> > >> ------ Forwarded Message > >> From: Leaf yeh > >> Date: Thu, 16 Feb 2012 12:05:44 +0000 > >> To: Wojciech Dec , Bernard Aboba > >> > >> Cc: "radext@ietf.org" , "fine_sz@huawei.com" > >> , Stefan Winter > >> Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access- > 06.txt > >> > >> Wojciech - the Route-IPv6-Information attribute changed from its > >> previous "non complex" to the current form between draft 04 and 05, > >>based on > >> WG review/feedback: > >> http://trac.tools.ietf.org/wg/radext/trac/ticket/71 > >> > >> > >> As per the requirement in the section 2.1 of RFC6158, > >> > >> Since there are no "hard and fast" > >> rules for where complexity is best located, each situation has to be > >> decided on a case-by-case basis...Where a complex data type is > >>selected, an > >> explanation SHOULD be offered as to why this was necessary. > >> > >> would you clarify the reason for the adoption of the 'complex data > >>type' in > >> the definition of attribute, Route-IPv6-Information? > >> > >> I can=B9t find the answer in the following links: > >> http://trac.tools.ietf.org/wg/radext/trac/ticket/71 & > >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ipv6-access-05 > . > >> > >> The definition of the attribute without multi-fields sounds 'ok' > with me > >> personally, but RFC6158 (& its section A.2.1) seems not recommended > it. > >> > >> Is my understanding right here? > >> > >> > >> Best Regards, > >> Leaf > >> > >> > >> -----Original Message----- > >> From: Wojciech Dec [mailto:wdec@cisco.com] > >> Sent: Wednesday, February 15, 2012 8:24 PM > >> To: Alan DeKok; Leaf yeh > >> Cc: radext@ietf.org; Stefan Winter; fine_sz@huawei.com > >> Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access- > 06.txt > >> > >> Just as an FYI, the Route-IPv6-Information attribute changed from > its > >> previous "non complex" to the current form between draft 04 and 05, > >>based on > >> WG review/feedback: > >> http://trac.tools.ietf.org/wg/radext/trac/ticket/71 > >> > >> -Wojciech. > >> > >> > >> > >> On 15/02/2012 13:05, "Alan DeKok" wrote: > >> > >>> Leaf yeh wrote: > >>>> After reading and employed the RFC6158, Radius Design Guidelines, > >>>>could it > >>>> be > >>>> concluded the attribute of Route-IPv6-Information defined in the > >>>> draft-ietf-radext-ipv6-access-06 shown as follows: > >>> .. > >>>> is creating a new 'Complex Data Type', which has multi-fields, and > is > >>>>not > >>>> recommended? > >>> > >>> That is what the document says. > >>> > >>>> Will it get the same 'acceptable' as that of Frame-IPv6-Prefix > (97) > >>>>and > >>>> Delegated-IPv6-Prefix(123), which is mentioned in Section B.7 of > >>>>RFC6158? > >>> > >>> No. > >>> > >>> I could explain here, but there's no need. Read RFC 6158. It > >>> thoroughly details the rationale behind the design guidelines. > >>> > >>> Alan DeKok. > >> > >> _______________________________________________ > >radext mailing > >> list > >radext@ietf.org > >https://www.ietf.org/mailman/listinfo/radext > > > >> > >> ------ End of Forwarded Message > > _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From alex@um.es Wed Mar 14 08:22:09 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F1F21E805F for ; Wed, 14 Mar 2012 08:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, 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 1IruQSPpWE-q for ; Wed, 14 Mar 2012 08:22:08 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 5D55A21E8054 for ; Wed, 14 Mar 2012 08:22:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id BD1BE4BD11 for ; Wed, 14 Mar 2012 16:22:06 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ouWG0KH1WXdk for ; Wed, 14 Mar 2012 16:22:06 +0100 (CET) Received: from [192.168.1.131] (64.227.14.37.dynamic.jazztel.es [37.14.227.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPSA id 0F7B04BD1B for ; Wed, 14 Mar 2012 16:22:05 +0100 (CET) Message-ID: <4F60B79C.5090903@um.es> Date: Wed, 14 Mar 2012 16:22:04 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: radext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [radext] IETF 83: Draft 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: Wed, 14 Mar 2012 15:22:09 -0000 If there is enough time, I would like to request a slot (about 15 minutes) to talk about draft-perez-radext-radius-fragmentation-01 (http://www.ietf.org/id/draft-perez-radext-radius-fragmentation-01.txt). Regards, Alejandro > > At IETF 83 RADEXT has a two-hour time slot allocated. Below is the draft agenda. Please respond with any suggested changes or comments. > > Regards, > MS > > --------------- > > RADEXT WG IETF 83 Agenda > > Chairs: > Jouni Korhonen > Mauricio Sanchez > > Jabber room: radext at jabber.ietf.org (Please join) > > Friday, March 30, 2012 > 0900-1100 > Room 212/213 > > 9:00 - 09:15 AM, Preliminaries (15 minutes) > Audio/Video& Remote Presentation Debugging > Note Well > Note Takers > Jabber scribe > Agenda bash > Document Status > > Draft discussion (60 minutes) > 9:15 - 9:30 AM RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec (15 minutes) > http://tools.ietf.org/html/draft-ietf-radext-ipv6-access > > 9:30 - 9:45 AM RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh (15 minutes) > http://tools.ietf.org/html/draft-yeh-radext-ext-traffic-statistics > > 9:45 - 10:00 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (15 minutes) > http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt > > 10:00 - 10:15 AM RADIUS Protocol Extensions, Alan DeKok (15 minutes) > http://tools.ietf.org/html/draft-ietf-radext-radius-extensions > > Rechartering and Wrap-up (45 minutes) > 10:15 - 10:45 AM Rechartering/ New Milestones (30 minutes) > > 10:45 - 11:00 AM Next Steps: WG Chairs& ADs (15 minutes) > WG Goals/Milestones status, next steps > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Wed Mar 14 08:22:11 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDBD21E805F; Wed, 14 Mar 2012 08:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331738531; bh=8yNtMTqozmiryZgYyeIfgi09YEnFRK7dnhEo1uC0ls0=; 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=xHaU85ww10x47qAEIA3Dhiz2sZQgA6u1GoaB+fFjcVAP1OaSdxSuyj5S0f+QCiSev qFbfK4MyeOjKVItAN1WcxuTsuIQiicdlvMuf+eECM1mS+H6IM7R7wrmKl5tIPKi7AT epcQMIo5/6ba0e12UU1qwlxkFTh9N9T/gbZbPqGo= 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 79F1F21E805F for ; Wed, 14 Mar 2012 08:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, 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 1IruQSPpWE-q for ; Wed, 14 Mar 2012 08:22:08 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 5D55A21E8054 for ; Wed, 14 Mar 2012 08:22:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id BD1BE4BD11 for ; Wed, 14 Mar 2012 16:22:06 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ouWG0KH1WXdk for ; Wed, 14 Mar 2012 16:22:06 +0100 (CET) Received: from [192.168.1.131] (64.227.14.37.dynamic.jazztel.es [37.14.227.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPSA id 0F7B04BD1B for ; Wed, 14 Mar 2012 16:22:05 +0100 (CET) Message-ID: <4F60B79C.5090903@um.es> Date: Wed, 14 Mar 2012 16:22:04 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: radext@ietf.org References: In-Reply-To: Subject: Re: [radext] IETF 83: Draft 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org If there is enough time, I would like to request a slot (about 15 minutes) to talk about draft-perez-radext-radius-fragmentation-01 (http://www.ietf.org/id/draft-perez-radext-radius-fragmentation-01.txt). Regards, Alejandro > > At IETF 83 RADEXT has a two-hour time slot allocated. Below is the draft agenda. Please respond with any suggested changes or comments. > > Regards, > MS > > --------------- > > RADEXT WG IETF 83 Agenda > > Chairs: > Jouni Korhonen > Mauricio Sanchez > > Jabber room: radext at jabber.ietf.org (Please join) > > Friday, March 30, 2012 > 0900-1100 > Room 212/213 > > 9:00 - 09:15 AM, Preliminaries (15 minutes) > Audio/Video& Remote Presentation Debugging > Note Well > Note Takers > Jabber scribe > Agenda bash > Document Status > > Draft discussion (60 minutes) > 9:15 - 9:30 AM RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec (15 minutes) > http://tools.ietf.org/html/draft-ietf-radext-ipv6-access > > 9:30 - 9:45 AM RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh (15 minutes) > http://tools.ietf.org/html/draft-yeh-radext-ext-traffic-statistics > > 9:45 - 10:00 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (15 minutes) > http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt > > 10:00 - 10:15 AM RADIUS Protocol Extensions, Alan DeKok (15 minutes) > http://tools.ietf.org/html/draft-ietf-radext-radius-extensions > > Rechartering and Wrap-up (45 minutes) > 10:15 - 10:45 AM Rechartering/ New Milestones (30 minutes) > > 10:45 - 11:00 AM Next Steps: WG Chairs& ADs (15 minutes) > WG Goals/Milestones status, next steps > _______________________________________________ > 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 peterd@iea-software.com Wed Mar 14 10:26:14 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445EF21F85D3 for ; Wed, 14 Mar 2012 10:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 zEi7Bzb1PqN4 for ; Wed, 14 Mar 2012 10:26:13 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id B2D9821F85CD for ; Wed, 14 Mar 2012 10:26:13 -0700 (PDT) Received: from littlesmurf.internal.iea-software.com (unverified [10.0.0.39]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Wed, 14 Mar 2012 10:26:12 -0700 Date: Wed, 14 Mar 2012 10:26:14 -0700 (Pacific Daylight Time) From: Peter Deacon To: "Wojciech Dec (wdec)" In-Reply-To: <671F3F6039F35F48B458F3E382BC8D610121D648@XMB-AMS-112.cisco.com> Message-ID: References: <671F3F6039F35F48B458F3E382BC8D610121D648@XMB-AMS-112.cisco.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: Bernard Aboba , radext@ietf.org, jouni.nospam@gmail.com, "Sanchez, Mauricio \(HP Networking\)" Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 17:26:14 -0000 On Wed, 14 Mar 2012, Wojciech Dec (wdec) wrote: > Personally, I'm ok either way, but perhaps in the wider interest of > closing off on the draft sooner rather than later I'd vote for (1). What > about the rest of the WG? What is the purpose of signaling lifetime and preference via RADIUS? Could the NAS better handle these parameters intelligently and or with local configuration? If necessary it seems the NAS would have the capability to issue zero lifetime advertisements to invalidate current routes in order to effect routing changes as a result of session reauthorization. Currently I prefer -04 version as I'm not seeing the value justify cost of another custom packet format for one attribute. regards, Peter From radext-bounces@ietf.org Wed Mar 14 10:26:15 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1650921F85D3; Wed, 14 Mar 2012 10:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331745975; bh=i2bGaW2sOSttey0zPib0SiUcEhRDfYE2ClJ0Mzf4iM0=; 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=U9Gj8x6bgdnOHWi9DjnZIsg69zcBIvVAPJ6kdteI0A7eoYIrAmf8GMTD/M86XIMAW nsg2qNLC3shrlHskqZOFyT0CKqCZSV1jsD47BPFjhl9BA/1gWy3eUAycGPBnPSiwuE E54xqAECgvF32ueTvph03rriz7dayxf/0Dc4soDc= 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 445EF21F85D3 for ; Wed, 14 Mar 2012 10:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 zEi7Bzb1PqN4 for ; Wed, 14 Mar 2012 10:26:13 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id B2D9821F85CD for ; Wed, 14 Mar 2012 10:26:13 -0700 (PDT) Received: from littlesmurf.internal.iea-software.com (unverified [10.0.0.39]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Wed, 14 Mar 2012 10:26:12 -0700 Date: Wed, 14 Mar 2012 10:26:14 -0700 (Pacific Daylight Time) From: Peter Deacon To: "Wojciech Dec (wdec)" In-Reply-To: <671F3F6039F35F48B458F3E382BC8D610121D648@XMB-AMS-112.cisco.com> Message-ID: References: <671F3F6039F35F48B458F3E382BC8D610121D648@XMB-AMS-112.cisco.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Cc: Bernard Aboba , radext@ietf.org, jouni.nospam@gmail.com, "Sanchez, Mauricio \(HP Networking\)" Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On Wed, 14 Mar 2012, Wojciech Dec (wdec) wrote: > Personally, I'm ok either way, but perhaps in the wider interest of > closing off on the draft sooner rather than later I'd vote for (1). What > about the rest of the WG? What is the purpose of signaling lifetime and preference via RADIUS? Could the NAS better handle these parameters intelligently and or with local configuration? If necessary it seems the NAS would have the capability to issue zero lifetime advertisements to invalidate current routes in order to effect routing changes as a result of session reauthorization. Currently I prefer -04 version as I'm not seeing the value justify cost of another custom packet format for one attribute. regards, Peter _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Wed Mar 14 10:36:52 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722AD21E8034; Wed, 14 Mar 2012 10:36:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331746612; bh=5paxrKsDWMeTJC7/5wzWiL20BBUq1XiIl8dhlXZSCWI=; 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=Bu5yyDcs37OHw62t5dUp37Wq20pDrVeSuiadK3QH4bxlv8wLkZUT+951yZAg1dj0M lZnVyRCO5DDCwRSmMHQh7QX9hbsUt+5NvcHIohAeOi8yvOxszzTkFtu0aXdNVssF7P 5ZylBHJPuFtM9SAKaI8IEzyPsyTXqPhUSjXU+/As= 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 02E4421E8048 for ; Wed, 14 Mar 2012 10:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.387 X-Spam-Level: X-Spam-Status: No, score=-110.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+TMxXH3L+jf for ; Wed, 14 Mar 2012 10:36:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id AEB1621E8034 for ; Wed, 14 Mar 2012 10:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=1313; q=dns/txt; s=iport; t=1331746609; x=1332956209; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=LpxSEEJ81uB2WuiMZMPZgsLdw7l0Wd+s4GND3wzCSYE=; b=jFRdYgcLQf9wsU8BxpbyEOjF0jyG3TyMptSwmOgGXMHuN7M/oBTmGn+R 1MXqV+xvQNEkgz4ZzkHl10ZtgrEfO1eqreZnMil7hU2ZzsznA9LJ8OW8C B8pjr45dZWZGz6vp2Rksumvk4HWYyn8MGMBWSNynK0WQnuPfo3vvBFfMY k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJvWYE+Q/khM/2dsb2JhbABDti2BB4IJAQEBAwESAScCATwFDQEIGIEFAQEEDgUih2MFm36fLJB+BJVWjkCBaIJn X-IronPort-AV: E=Sophos;i="4.73,584,1325462400"; d="scan'208";a="132322833" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 14 Mar 2012 17:36:46 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2EHakBM005804; Wed, 14 Mar 2012 17:36:46 GMT Received: from xmb-ams-112.cisco.com ([144.254.74.87]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Mar 2012 18:36:46 +0100 Received: from 10.55.90.154 ([10.55.90.154]) by XMB-AMS-112.cisco.com ([144.254.74.87]) with Microsoft Exchange Server HTTP-DAV ; Wed, 14 Mar 2012 17:36:46 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 14 Mar 2012 18:36:39 +0100 From: Wojciech Dec To: Peter Deacon Message-ID: Thread-Topic: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt Thread-Index: Ac0CCQLiGGB2Iv833UmhK5TDtZRg/w== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 14 Mar 2012 17:36:46.0995 (UTC) FILETIME=[07A6DE30:01CD0209] Cc: Bernard Aboba , radext@ietf.org, jouni.nospam@gmail.com, "Sanchez, Mauricio \(HP Networking\)" Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On 14/03/2012 18:26, "Peter Deacon" wrote: > On Wed, 14 Mar 2012, Wojciech Dec (wdec) wrote: > >> Personally, I'm ok either way, but perhaps in the wider interest of >> closing off on the draft sooner rather than later I'd vote for (1). What >> about the rest of the WG? > > What is the purpose of signaling lifetime and preference via RADIUS? > Could the NAS better handle these parameters intelligently and or with > local configuration? That was the original idea... Countered with the argument that the fuller parameters should also be exposed, since they all relate to info sent in a RA. Looking at it from another angle, that of a dhcp-pd, we see that while the prefix has its own attribute it does not expose any/all dhcp timers, values etc in radius. Ie the equivalent of the -04 version. > > If necessary it seems the NAS would have the capability to issue zero > lifetime advertisements to invalidate current routes in order to effect > routing changes as a result of session reauthorization. > > Currently I prefer -04 version as I'm not seeing the value justify cost of > another custom packet format for one attribute. Given that the fix to go back to -04 is also trivial, I'd be happy with that. -Woj. > > regards, > Peter _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From wdec@cisco.com Wed Mar 14 10:36:51 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E4421E8048 for ; Wed, 14 Mar 2012 10:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.387 X-Spam-Level: X-Spam-Status: No, score=-110.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+TMxXH3L+jf for ; Wed, 14 Mar 2012 10:36:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id AEB1621E8034 for ; Wed, 14 Mar 2012 10:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=1313; q=dns/txt; s=iport; t=1331746609; x=1332956209; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=LpxSEEJ81uB2WuiMZMPZgsLdw7l0Wd+s4GND3wzCSYE=; b=jFRdYgcLQf9wsU8BxpbyEOjF0jyG3TyMptSwmOgGXMHuN7M/oBTmGn+R 1MXqV+xvQNEkgz4ZzkHl10ZtgrEfO1eqreZnMil7hU2ZzsznA9LJ8OW8C B8pjr45dZWZGz6vp2Rksumvk4HWYyn8MGMBWSNynK0WQnuPfo3vvBFfMY k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJvWYE+Q/khM/2dsb2JhbABDti2BB4IJAQEBAwESAScCATwFDQEIGIEFAQEEDgUih2MFm36fLJB+BJVWjkCBaIJn X-IronPort-AV: E=Sophos;i="4.73,584,1325462400"; d="scan'208";a="132322833" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 14 Mar 2012 17:36:46 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2EHakBM005804; Wed, 14 Mar 2012 17:36:46 GMT Received: from xmb-ams-112.cisco.com ([144.254.74.87]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Mar 2012 18:36:46 +0100 Received: from 10.55.90.154 ([10.55.90.154]) by XMB-AMS-112.cisco.com ([144.254.74.87]) with Microsoft Exchange Server HTTP-DAV ; Wed, 14 Mar 2012 17:36:46 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 14 Mar 2012 18:36:39 +0100 From: Wojciech Dec To: Peter Deacon Message-ID: Thread-Topic: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt Thread-Index: Ac0CCQLiGGB2Iv833UmhK5TDtZRg/w== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Mar 2012 17:36:46.0995 (UTC) FILETIME=[07A6DE30:01CD0209] Cc: Bernard Aboba , radext@ietf.org, jouni.nospam@gmail.com, "Sanchez, Mauricio \(HP Networking\)" Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 17:36:51 -0000 On 14/03/2012 18:26, "Peter Deacon" wrote: > On Wed, 14 Mar 2012, Wojciech Dec (wdec) wrote: > >> Personally, I'm ok either way, but perhaps in the wider interest of >> closing off on the draft sooner rather than later I'd vote for (1). What >> about the rest of the WG? > > What is the purpose of signaling lifetime and preference via RADIUS? > Could the NAS better handle these parameters intelligently and or with > local configuration? That was the original idea... Countered with the argument that the fuller parameters should also be exposed, since they all relate to info sent in a RA. Looking at it from another angle, that of a dhcp-pd, we see that while the prefix has its own attribute it does not expose any/all dhcp timers, values etc in radius. Ie the equivalent of the -04 version. > > If necessary it seems the NAS would have the capability to issue zero > lifetime advertisements to invalidate current routes in order to effect > routing changes as a result of session reauthorization. > > Currently I prefer -04 version as I'm not seeing the value justify cost of > another custom packet format for one attribute. Given that the fix to go back to -04 is also trivial, I'd be happy with that. -Woj. > > regards, > Peter From jouni.nospam@gmail.com Wed Mar 14 15:19:29 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8321721F8748 for ; Wed, 14 Mar 2012 15:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 oooz76JkeoWj for ; Wed, 14 Mar 2012 15:19:29 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCAE21F8740 for ; Wed, 14 Mar 2012 15:19:28 -0700 (PDT) Received: by lbol12 with SMTP id l12so1276356lbo.31 for ; Wed, 14 Mar 2012 15:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=nJTwzB4naVXcWh5LTZq5w3RvwLXg4GrH3FdGQ8wfRIE=; b=lgC0PwOfRNE5PD/WlBqsERWqZMV72S4HElG6cmnWlYQgcqzoaZdYAN3x+pXvQvEj6s Extim/Tuw8GnDJ1Zt5Rb+dn59CdNMRY0kfKBTAjVDYx+fgM5AMJW7ybUEOO5VpFKsfcB l/RlJhMUBFuPa6Jz1rQ9d5YjLsVQS01SC/fdJRw+QeTArwt9MeR2dVANrj3HEYf7I5Ep 9zmlJiGetvs4w69hm3ZACZTQRfoGfyqAVIDXapadWaTK+XokWzqg2AU4AbO+0OX0Opqm bbKueSfDWNVwZXmTySlE1kJ0jCIsp4wtR+KXWnUE4fcL3GsSgcSEUq+iNpPaCVNvRHMn BjEw== Received: by 10.112.88.2 with SMTP id bc2mr1567668lbb.85.1331763567595; Wed, 14 Mar 2012 15:19:27 -0700 (PDT) Received: from a88-114-7-204.elisa-laajakaista.fi (a88-114-7-204.elisa-laajakaista.fi. [88.114.7.204]) by mx.google.com with ESMTPS id jg7sm6075786lbb.0.2012.03.14.15.19.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Mar 2012 15:19:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 15 Mar 2012 00:19:24 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Bernard Aboba , radext@ietf.org, "Sanchez, Mauricio \(HP Networking\)" , Peter Deacon Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 22:19:29 -0000 On Mar 14, 2012, at 7:36 PM, Wojciech Dec wrote: > > On 14/03/2012 18:26, "Peter Deacon" wrote: > >> On Wed, 14 Mar 2012, Wojciech Dec (wdec) wrote: >> >>> Personally, I'm ok either way, but perhaps in the wider interest of >>> closing off on the draft sooner rather than later I'd vote for (1). What >>> about the rest of the WG? >> >> What is the purpose of signaling lifetime and preference via RADIUS? >> Could the NAS better handle these parameters intelligently and or with >> local configuration? > > That was the original idea... Countered with the argument that the fuller > parameters should also be exposed, since they all relate to info sent in a > RA. > Looking at it from another angle, that of a dhcp-pd, we see that while the > prefix has its own attribute it does not expose any/all dhcp timers, values > etc in radius. Ie the equivalent of the -04 version. RFC3162 Framed-IPv6-Prefix content that gets put into PIO does not either have anything else but the prefix and its length. >> >> If necessary it seems the NAS would have the capability to issue zero >> lifetime advertisements to invalidate current routes in order to effect >> routing changes as a result of session reauthorization. >> >> Currently I prefer -04 version as I'm not seeing the value justify cost of >> another custom packet format for one attribute. > > Given that the fix to go back to -04 is also trivial, I'd be happy with > that. I would be happy to go back to -04 with this specific attribute as well. - Jouni > > -Woj. >> >> regards, >> Peter > From radext-bounces@ietf.org Wed Mar 14 15:19:30 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72F521F8740; Wed, 14 Mar 2012 15:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331763570; bh=1YU2WJSC/5Unt892/obpz6lmCBdrtqdX1T1XGPEndP0=; 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=lYcq7nYyTJiCwwwq9YGPpX3eD5BHPPt3mcuC3EN7Ww43eVXdsr4pRJI1D3iHNLiDK 8lS3AlNDR/j5BIn7LG7/6GxK+pqupzPcnunkFpo/UkTdQLzTKz/jYWvW1/zPlAr9O8 NVkRI9LPrZNdBbsLg5zgL6WNOMTHvdBQTWtduhb4= 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 8321721F8748 for ; Wed, 14 Mar 2012 15:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 oooz76JkeoWj for ; Wed, 14 Mar 2012 15:19:29 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCAE21F8740 for ; Wed, 14 Mar 2012 15:19:28 -0700 (PDT) Received: by lbol12 with SMTP id l12so1276356lbo.31 for ; Wed, 14 Mar 2012 15:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=nJTwzB4naVXcWh5LTZq5w3RvwLXg4GrH3FdGQ8wfRIE=; b=lgC0PwOfRNE5PD/WlBqsERWqZMV72S4HElG6cmnWlYQgcqzoaZdYAN3x+pXvQvEj6s Extim/Tuw8GnDJ1Zt5Rb+dn59CdNMRY0kfKBTAjVDYx+fgM5AMJW7ybUEOO5VpFKsfcB l/RlJhMUBFuPa6Jz1rQ9d5YjLsVQS01SC/fdJRw+QeTArwt9MeR2dVANrj3HEYf7I5Ep 9zmlJiGetvs4w69hm3ZACZTQRfoGfyqAVIDXapadWaTK+XokWzqg2AU4AbO+0OX0Opqm bbKueSfDWNVwZXmTySlE1kJ0jCIsp4wtR+KXWnUE4fcL3GsSgcSEUq+iNpPaCVNvRHMn BjEw== Received: by 10.112.88.2 with SMTP id bc2mr1567668lbb.85.1331763567595; Wed, 14 Mar 2012 15:19:27 -0700 (PDT) Received: from a88-114-7-204.elisa-laajakaista.fi (a88-114-7-204.elisa-laajakaista.fi. [88.114.7.204]) by mx.google.com with ESMTPS id jg7sm6075786lbb.0.2012.03.14.15.19.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Mar 2012 15:19:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: jouni korhonen In-Reply-To: Date: Thu, 15 Mar 2012 00:19:24 +0200 Message-Id: References: To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Bernard Aboba , radext@ietf.org, "Sanchez, Mauricio \(HP Networking\)" , Peter Deacon Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On Mar 14, 2012, at 7:36 PM, Wojciech Dec wrote: > > On 14/03/2012 18:26, "Peter Deacon" wrote: > >> On Wed, 14 Mar 2012, Wojciech Dec (wdec) wrote: >> >>> Personally, I'm ok either way, but perhaps in the wider interest of >>> closing off on the draft sooner rather than later I'd vote for (1). What >>> about the rest of the WG? >> >> What is the purpose of signaling lifetime and preference via RADIUS? >> Could the NAS better handle these parameters intelligently and or with >> local configuration? > > That was the original idea... Countered with the argument that the fuller > parameters should also be exposed, since they all relate to info sent in a > RA. > Looking at it from another angle, that of a dhcp-pd, we see that while the > prefix has its own attribute it does not expose any/all dhcp timers, values > etc in radius. Ie the equivalent of the -04 version. RFC3162 Framed-IPv6-Prefix content that gets put into PIO does not either have anything else but the prefix and its length. >> >> If necessary it seems the NAS would have the capability to issue zero >> lifetime advertisements to invalidate current routes in order to effect >> routing changes as a result of session reauthorization. >> >> Currently I prefer -04 version as I'm not seeing the value justify cost of >> another custom packet format for one attribute. > > Given that the fix to go back to -04 is also trivial, I'd be happy with > that. I would be happy to go back to -04 with this specific attribute as well. - Jouni > > -Woj. >> >> regards, >> Peter > _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From leaf.y.yeh@huawei.com Thu Mar 15 19:46:59 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E250321E800F for ; Thu, 15 Mar 2012 19:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.645 X-Spam-Level: X-Spam-Status: No, score=-6.645 tagged_above=-999 required=5 tests=[AWL=-0.046, 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 4uUY6m+T4br3 for ; Thu, 15 Mar 2012 19:46:59 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id BB76021E800E for ; Thu, 15 Mar 2012 19:46:58 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0Y003J1IE6YW@szxga05-in.huawei.com> for radext@ietf.org; Fri, 16 Mar 2012 10:46:54 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0Y009SCIE6MT@szxga05-in.huawei.com> for radext@ietf.org; Fri, 16 Mar 2012 10:46:54 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHX11510; Fri, 16 Mar 2012 10:46:53 +0800 Received: from SZXEML438-HUB.china.huawei.com (10.72.61.73) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Mar 2012 10:46:10 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.217]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Fri, 16 Mar 2012 10:46:48 +0800 Date: Fri, 16 Mar 2012 02:46:47 +0000 From: Leaf yeh In-reply-to: X-Originating-IP: [10.70.39.113] To: jouni korhonen , Wojciech Dec Message-id: Content-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt Thread-index: AQHMom90WDU7kboiIkWUJSus5ElNy5Y+VmzA//+S3oCAAAUXAIACDmRggAyRBA+AFMwWfYAHUyOAgAEaCwCAAH0UAIAAAumAgABPAACAAZbXuQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: Bernard Aboba , "radext@ietf.org" , Peter Deacon , "Sanchez, Mauricio \(HP Networking\)" Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 02:47:00 -0000 If the format of 'Route-IPv6-Information' is designed as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | Prefix-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Prefix (variable) . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ which is quoted from http://tools.ietf.org/id/draft-ietf-radext-ipv6-access-04.txt, it sounds we only care to the corresponding route sent to the user hosts through RA. Then I begin to doubt the necessity of the network scenario, where the RG or host are expected to be multi-homed to both NASes, which shows as: +-----+ (Radius) | AAA | ...........>| | . +--+--+ v ^ +---+---+ . | NAS | .(Radius) | | . +---+---+ v +------+ | +---+---+ +------+ | AN | | | NAS | | RG/ +-------| +-----------+----------+ | | host | | | | | +------+ (DSL) +------+ (Ethernet) +-------+ Figure 1 I guess Figure 1 could be simplified as: +-----+ | AAA | | | +--+--+ ^ . .(Radius) . v +------+ +---+---+ +------+ | AN | | NAS | | RG/ +-------| +-----------+----------+ | | host | | | | | +------+ (DSL) +------+ (Ethernet) +-------+ Otherwise, we might need some text for the reasons or description why we keep the information of 'Route Preference' (or even 'Router Lifetime') to meet the requirement from RFC4191. Right? I am interested in the value of multi-home connecting to the NASes in the network architecture originally shown in Figure 1, I guess the 'Route Preference' for the default router of the user host might be useful in this case. Best Regards, Leaf ________________________________________ From: radext-bounces@ietf.org [radext-bounces@ietf.org] on behalf of jouni korhonen [jouni.nospam@gmail.com] Sent: Thursday, March 15, 2012 6:19 To: Wojciech Dec Cc: Bernard Aboba; radext@ietf.org; Sanchez, Mauricio (HP Networking); Peter Deacon Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt On Mar 14, 2012, at 7:36 PM, Wojciech Dec wrote: > > On 14/03/2012 18:26, "Peter Deacon" wrote: > >> On Wed, 14 Mar 2012, Wojciech Dec (wdec) wrote: >> >>> Personally, I'm ok either way, but perhaps in the wider interest of >>> closing off on the draft sooner rather than later I'd vote for (1). What >>> about the rest of the WG? >> >> What is the purpose of signaling lifetime and preference via RADIUS? >> Could the NAS better handle these parameters intelligently and or with >> local configuration? > > That was the original idea... Countered with the argument that the fuller > parameters should also be exposed, since they all relate to info sent in a > RA. > Looking at it from another angle, that of a dhcp-pd, we see that while the > prefix has its own attribute it does not expose any/all dhcp timers, values > etc in radius. Ie the equivalent of the -04 version. RFC3162 Framed-IPv6-Prefix content that gets put into PIO does not either have anything else but the prefix and its length. >> >> If necessary it seems the NAS would have the capability to issue zero >> lifetime advertisements to invalidate current routes in order to effect >> routing changes as a result of session reauthorization. >> >> Currently I prefer -04 version as I'm not seeing the value justify cost of >> another custom packet format for one attribute. > > Given that the fix to go back to -04 is also trivial, I'd be happy with > that. I would be happy to go back to -04 with this specific attribute as well. - Jouni > > -Woj. >> >> regards, >> Peter > _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Thu Mar 15 19:47:01 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E80321E800F; Thu, 15 Mar 2012 19:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331866021; bh=8U7UYK1HYhsbtGJs4E52XHuuOjZ78PYdIyLUdRZhlk0=; h=Date:From:In-reply-to:To:Message-id:Content-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=hYqSJ1RW9ICIFAAYP2Dr8HgiAb2iLgcqTGGSYtINe9rbHxLVBUlX5UYNlnOEOTQGL Mrhwk9HuVmbF+86bmQf7C+NNQ/Vd30/5XbXbJYN8t1zVvvYEC40yOvUBxlJy73EYUm IpnxSdcWS9ivRdV2luGK+CvyZCTcn4Euc2uEdeCs= 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 E250321E800F for ; Thu, 15 Mar 2012 19:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.645 X-Spam-Level: X-Spam-Status: No, score=-6.645 tagged_above=-999 required=5 tests=[AWL=-0.046, 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 4uUY6m+T4br3 for ; Thu, 15 Mar 2012 19:46:59 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id BB76021E800E for ; Thu, 15 Mar 2012 19:46:58 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0Y003J1IE6YW@szxga05-in.huawei.com> for radext@ietf.org; Fri, 16 Mar 2012 10:46:54 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0Y009SCIE6MT@szxga05-in.huawei.com> for radext@ietf.org; Fri, 16 Mar 2012 10:46:54 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHX11510; Fri, 16 Mar 2012 10:46:53 +0800 Received: from SZXEML438-HUB.china.huawei.com (10.72.61.73) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Mar 2012 10:46:10 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.217]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Fri, 16 Mar 2012 10:46:48 +0800 Date: Fri, 16 Mar 2012 02:46:47 +0000 From: Leaf yeh In-reply-to: X-Originating-IP: [10.70.39.113] To: jouni korhonen , Wojciech Dec Message-id: Content-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt Thread-index: AQHMom90WDU7kboiIkWUJSus5ElNy5Y+VmzA//+S3oCAAAUXAIACDmRggAyRBA+AFMwWfYAHUyOAgAEaCwCAAH0UAIAAAumAgABPAACAAZbXuQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: Bernard Aboba , "radext@ietf.org" , Peter Deacon , "Sanchez, Mauricio \(HP Networking\)" Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org If the format of 'Route-IPv6-Information' is designed as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | Prefix-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Prefix (variable) . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ which is quoted from http://tools.ietf.org/id/draft-ietf-radext-ipv6-access-04.txt, it sounds we only care to the corresponding route sent to the user hosts through RA. Then I begin to doubt the necessity of the network scenario, where the RG or host are expected to be multi-homed to both NASes, which shows as: +-----+ (Radius) | AAA | ...........>| | . +--+--+ v ^ +---+---+ . | NAS | .(Radius) | | . +---+---+ v +------+ | +---+---+ +------+ | AN | | | NAS | | RG/ +-------| +-----------+----------+ | | host | | | | | +------+ (DSL) +------+ (Ethernet) +-------+ Figure 1 I guess Figure 1 could be simplified as: +-----+ | AAA | | | +--+--+ ^ . .(Radius) . v +------+ +---+---+ +------+ | AN | | NAS | | RG/ +-------| +-----------+----------+ | | host | | | | | +------+ (DSL) +------+ (Ethernet) +-------+ Otherwise, we might need some text for the reasons or description why we keep the information of 'Route Preference' (or even 'Router Lifetime') to meet the requirement from RFC4191. Right? I am interested in the value of multi-home connecting to the NASes in the network architecture originally shown in Figure 1, I guess the 'Route Preference' for the default router of the user host might be useful in this case. Best Regards, Leaf ________________________________________ From: radext-bounces@ietf.org [radext-bounces@ietf.org] on behalf of jouni korhonen [jouni.nospam@gmail.com] Sent: Thursday, March 15, 2012 6:19 To: Wojciech Dec Cc: Bernard Aboba; radext@ietf.org; Sanchez, Mauricio (HP Networking); Peter Deacon Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt On Mar 14, 2012, at 7:36 PM, Wojciech Dec wrote: > > On 14/03/2012 18:26, "Peter Deacon" wrote: > >> On Wed, 14 Mar 2012, Wojciech Dec (wdec) wrote: >> >>> Personally, I'm ok either way, but perhaps in the wider interest of >>> closing off on the draft sooner rather than later I'd vote for (1). What >>> about the rest of the WG? >> >> What is the purpose of signaling lifetime and preference via RADIUS? >> Could the NAS better handle these parameters intelligently and or with >> local configuration? > > That was the original idea... Countered with the argument that the fuller > parameters should also be exposed, since they all relate to info sent in a > RA. > Looking at it from another angle, that of a dhcp-pd, we see that while the > prefix has its own attribute it does not expose any/all dhcp timers, values > etc in radius. Ie the equivalent of the -04 version. RFC3162 Framed-IPv6-Prefix content that gets put into PIO does not either have anything else but the prefix and its length. >> >> If necessary it seems the NAS would have the capability to issue zero >> lifetime advertisements to invalidate current routes in order to effect >> routing changes as a result of session reauthorization. >> >> Currently I prefer -04 version as I'm not seeing the value justify cost of >> another custom packet format for one attribute. > > Given that the fix to go back to -04 is also trivial, I'd be happy with > that. I would be happy to go back to -04 with this specific attribute as well. - Jouni > > -Woj. >> >> regards, >> Peter > _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From leaf.y.yeh@huawei.com Thu Mar 15 23:05:51 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131F421F8724 for ; Thu, 15 Mar 2012 23:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.644 X-Spam-Level: X-Spam-Status: No, score=-6.644 tagged_above=-999 required=5 tests=[AWL=-0.045, 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 DYDq4qYUE6t8 for ; Thu, 15 Mar 2012 23:05:50 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3719321F871C for ; Thu, 15 Mar 2012 23:05:50 -0700 (PDT) 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 <0M0Y00M5DRLB7D@szxga04-in.huawei.com> for radext@ietf.org; Fri, 16 Mar 2012 14:05:35 +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 <0M0Y00KJURKWGJ@szxga04-in.huawei.com> for radext@ietf.org; Fri, 16 Mar 2012 14:05:35 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHX27783; Fri, 16 Mar 2012 14:05:34 +0800 Received: from SZXEML430-HUB.china.huawei.com (10.72.61.38) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Mar 2012 14:05:26 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.217]) by szxeml430-hub.china.huawei.com ([10.72.61.38]) with mapi id 14.01.0323.003; Fri, 16 Mar 2012 14:05:32 +0800 Date: Fri, 16 Mar 2012 06:05:32 +0000 From: Leaf yeh X-Originating-IP: [10.70.39.113] To: "radext@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt-sent again Thread-index: AQHMom90WDU7kboiIkWUJSus5ElNy5Y+VmzA//+S3oCAAAUXAIACDmRggAyRBA+AFMwWfYAHUyOAgAEjo4CAAZKLYIABzR9A X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt-sent again 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, 16 Mar 2012 06:05:51 -0000 IMHO, the following are only for the technical discussion: Section 2.1 of RFC6158 only defined 9 data types, which are 1. 32-bits unsigned integer 2. Enumerated (32-bit unsigned integer) 3. IPv4 address (32-bit/4-octet) 4. Time (32-bit unsigned integer in second) 5. IPv6 address (128-bit/16-octet) 6. Interface-ID (64-bit/8-octet) 7. IPv6 prefix (variable length per the field of 'prefix-length' defined in RFC3162) 8. String (<= 253-octet) 9. UTF-8 Text (<= 253-octet) Section 6.1 of draft-ietf-radext-radius-extensions-04 recommended to add 3 new basic data types, which are 10. EVS (Extended Vendor Specific) 11. TLV (Type-Length-Value) 12. Interger64 (64-bits) Section 6.3 of draft-ietf-radext-radius-extensions-04 provided the guidelines for Complex Data Type, which sounds as follows: Does the attribute: * define a complex type which can be represented via TLVs? If so, this data type MUST be represented via TLVs. But section 6.4 of draft-ietf-radext-radius-extensions-04 provided the guidelines for the new types, which are as follows: The data type "tlv" SHOULD NOT be used for standard RADIUS attributes. While its use is NOT RECOMMENDED by [RFC6158], this specification updates [RFC6158] to permit the "tlv" data type in attributes using the Extended-Type format. There might be 2 alternatives for the attribute re-design of 'Route-IPv6-Information' if we want to comply with RFC6158 and draft-ietf-radext-radius-extensions. Design-a. I suggest TLV can be used in any RADIUS attribute including those in the unassigned standard space after the publication of draft-ietf-radext-radius-extensions (Remote Authentication Dial In User Service (RADIUS) Protocol Extensions). Design-b. It needs 3 new attributes in the traditional flat mode to carry the information in the fields of Route Information Option defined in RFC4191. They might be: 1 for the IPv6 Prefix (variable length); 1 for the Route Lifetime (32-bit) and 1 for Route Preference (32-bit). Design-b might be the simplest way now if we remind there is RFC6158 and forget there is draft-ietf-radext-radius-extensions. Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Sanchez, Mauricio (HP Networking) Sent: Wednesday, March 14, 2012 1:09 AM To: Wojciech Dec; jouni.nospam@gmail.com Cc: Bernard Aboba; radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt RADEXT, like any good IETF WG, has a colorful history and sometimes a bit schizophrenic, as this particular case can attest to. I think we can all agree that the ipv6 attributed noted below is of a complex type and in conflict with RFC6158 mandate to not continue to promulgate such complex types. However, RFC6158 also includes a significant amount of leeway. I think we have two options before us: (1) Per RFC6158's mandate include a small statement justifying the complex attribute as it stands now. Statement would be similar in spirit to what appendix B in RFC6158 does for other complex attributes (2) Recast the design of attribute into a new form that reduces its complexity (i.e. Look to follow RFC6158 more closely). If we agree these are the two options before us, we can do consensus check on which approach the WG would like to take. -MS From radext-bounces@ietf.org Thu Mar 15 23:05:53 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2368321F871E; Thu, 15 Mar 2012 23:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331877953; bh=XSsojG8LAVhonRz8+8QlOU7e0wi4rSS+pF1ysWPRZkA=; h=Date:From:To:Message-id:MIME-version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=yIP08VIqP/XOyYkxgV9SuSacdPz24fY3vTVmZ9mntvNSFe3IPegd/giGdMee/hRTN H54WQGggxVCHYm9992KsYYKiNatzydNpdDCEkykAHfAoEApMggWQmQN3H1j72jfc4+ IMJaQM2bQ2L9CClf4omXbaydGL8t083J1IXFCcKE= 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 131F421F8724 for ; Thu, 15 Mar 2012 23:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.644 X-Spam-Level: X-Spam-Status: No, score=-6.644 tagged_above=-999 required=5 tests=[AWL=-0.045, 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 DYDq4qYUE6t8 for ; Thu, 15 Mar 2012 23:05:50 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3719321F871C for ; Thu, 15 Mar 2012 23:05:50 -0700 (PDT) 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 <0M0Y00M5DRLB7D@szxga04-in.huawei.com> for radext@ietf.org; Fri, 16 Mar 2012 14:05:35 +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 <0M0Y00KJURKWGJ@szxga04-in.huawei.com> for radext@ietf.org; Fri, 16 Mar 2012 14:05:35 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHX27783; Fri, 16 Mar 2012 14:05:34 +0800 Received: from SZXEML430-HUB.china.huawei.com (10.72.61.38) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Mar 2012 14:05:26 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.217]) by szxeml430-hub.china.huawei.com ([10.72.61.38]) with mapi id 14.01.0323.003; Fri, 16 Mar 2012 14:05:32 +0800 Date: Fri, 16 Mar 2012 06:05:32 +0000 From: Leaf yeh X-Originating-IP: [10.70.39.113] To: "radext@ietf.org" Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt-sent again Thread-index: AQHMom90WDU7kboiIkWUJSus5ElNy5Y+VmzA//+S3oCAAAUXAIACDmRggAyRBA+AFMwWfYAHUyOAgAEjo4CAAZKLYIABzR9A X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt-sent again 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 IMHO, the following are only for the technical discussion: Section 2.1 of RFC6158 only defined 9 data types, which are 1. 32-bits unsigned integer 2. Enumerated (32-bit unsigned integer) 3. IPv4 address (32-bit/4-octet) 4. Time (32-bit unsigned integer in second) 5. IPv6 address (128-bit/16-octet) 6. Interface-ID (64-bit/8-octet) 7. IPv6 prefix (variable length per the field of 'prefix-length' defined in RFC3162) 8. String (<= 253-octet) 9. UTF-8 Text (<= 253-octet) Section 6.1 of draft-ietf-radext-radius-extensions-04 recommended to add 3 new basic data types, which are 10. EVS (Extended Vendor Specific) 11. TLV (Type-Length-Value) 12. Interger64 (64-bits) Section 6.3 of draft-ietf-radext-radius-extensions-04 provided the guidelines for Complex Data Type, which sounds as follows: Does the attribute: * define a complex type which can be represented via TLVs? If so, this data type MUST be represented via TLVs. But section 6.4 of draft-ietf-radext-radius-extensions-04 provided the guidelines for the new types, which are as follows: The data type "tlv" SHOULD NOT be used for standard RADIUS attributes. While its use is NOT RECOMMENDED by [RFC6158], this specification updates [RFC6158] to permit the "tlv" data type in attributes using the Extended-Type format. There might be 2 alternatives for the attribute re-design of 'Route-IPv6-Information' if we want to comply with RFC6158 and draft-ietf-radext-radius-extensions. Design-a. I suggest TLV can be used in any RADIUS attribute including those in the unassigned standard space after the publication of draft-ietf-radext-radius-extensions (Remote Authentication Dial In User Service (RADIUS) Protocol Extensions). Design-b. It needs 3 new attributes in the traditional flat mode to carry the information in the fields of Route Information Option defined in RFC4191. They might be: 1 for the IPv6 Prefix (variable length); 1 for the Route Lifetime (32-bit) and 1 for Route Preference (32-bit). Design-b might be the simplest way now if we remind there is RFC6158 and forget there is draft-ietf-radext-radius-extensions. Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Sanchez, Mauricio (HP Networking) Sent: Wednesday, March 14, 2012 1:09 AM To: Wojciech Dec; jouni.nospam@gmail.com Cc: Bernard Aboba; radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt RADEXT, like any good IETF WG, has a colorful history and sometimes a bit schizophrenic, as this particular case can attest to. I think we can all agree that the ipv6 attributed noted below is of a complex type and in conflict with RFC6158 mandate to not continue to promulgate such complex types. However, RFC6158 also includes a significant amount of leeway. I think we have two options before us: (1) Per RFC6158's mandate include a small statement justifying the complex attribute as it stands now. Statement would be similar in spirit to what appendix B in RFC6158 does for other complex attributes (2) Recast the design of attribute into a new form that reduces its complexity (i.e. Look to follow RFC6158 more closely). If we agree these are the two options before us, we can do consensus check on which approach the WG would like to take. -MS _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Fri Mar 16 01:51:47 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA31321F8711; Fri, 16 Mar 2012 01:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331887907; bh=UPLWS8kz2UlOSalgpBEihIPrW+ETU/DjebejqdWsT7o=; h=Date:From:To:Message-id:MIME-version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=R/zaxKQ5nwyNOrpC2S4hgY2lsxhC47kVHRCy4sFC8WvCRhruEoRrR7Z2O355dQ72X ULletHCfWH/2x3SwTF16TPCMWpCx1FI7Ibt7EGhf2GJcClHBCq7yOVrRuUugNN8Hr1 N6f12gyCNfNoCeVfIKiFczjbiMK+9jFps3etWBJU= 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 3573521F8711 for ; Fri, 16 Mar 2012 01:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.642 X-Spam-Level: X-Spam-Status: No, score=-6.642 tagged_above=-999 required=5 tests=[AWL=-0.043, 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 dwB1CLH7X9h4 for ; Fri, 16 Mar 2012 01:51:46 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 293EC21F86FA for ; Fri, 16 Mar 2012 01:51:46 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0Y00DUOZA7BO@szxga05-in.huawei.com> for radext@ietf.org; Fri, 16 Mar 2012 16:51:43 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0Y00LWTZ92NM@szxga05-in.huawei.com> for radext@ietf.org; Fri, 16 Mar 2012 16:51:43 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHX48614; Fri, 16 Mar 2012 16:51:42 +0800 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Mar 2012 16:51:34 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.217]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Fri, 16 Mar 2012 16:51:40 +0800 Date: Fri, 16 Mar 2012 08:51:39 +0000 From: Leaf yeh X-Originating-IP: [10.70.39.113] To: "radext@ietf.org" , Alan DeKok Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: Discussion on VSA defined in draft-ietf-radext-radius-extensions Thread-index: Ac0DUgB0wEwjBzMbTeuiVlHHZ7CFFQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [radext] Discussion on VSA defined in draft-ietf-radext-radius-extensions 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 draft-ietf-radext-radius-extensions defined 6 new attributes, including 24x.26, to solve the issue on the type space exhaustion of VSA. Does it mean Huawei (IANA-PEN=2011) or any enterprise who has the exclusive vendor-id, will inherit these new type space defined in 24x.26 naturally? On the other hand, I am thinking an alternative option for the enterprise who feel the pressure on the type space exhaustion of VSA, why do they not apply for a new exclusive vender-ID to get the extensive 255 new types? The Vendor-ID in the traditional VSA (26) has the length of 4-octect (=2^32). I can't see the exhaustion of Vendor-ID in the future. Just for the examples, Cisco already got 4 PENs, 4857/ 5771/ 5842 /26484; while China Telecom-Guangzhou Research and Development Center already got 2 PENs, 20236/20942. (http://www.iana.org/assignments/enterprise-numbers) If I am wrong (or it is a old question discussed before), pls. feel free to shoot on it. Best Regards, Leaf _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From leaf.y.yeh@huawei.com Fri Mar 16 01:51:47 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3573521F8711 for ; Fri, 16 Mar 2012 01:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.642 X-Spam-Level: X-Spam-Status: No, score=-6.642 tagged_above=-999 required=5 tests=[AWL=-0.043, 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 dwB1CLH7X9h4 for ; Fri, 16 Mar 2012 01:51:46 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 293EC21F86FA for ; Fri, 16 Mar 2012 01:51:46 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0Y00DUOZA7BO@szxga05-in.huawei.com> for radext@ietf.org; Fri, 16 Mar 2012 16:51:43 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0Y00LWTZ92NM@szxga05-in.huawei.com> for radext@ietf.org; Fri, 16 Mar 2012 16:51:43 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHX48614; Fri, 16 Mar 2012 16:51:42 +0800 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Mar 2012 16:51:34 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.217]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Fri, 16 Mar 2012 16:51:40 +0800 Date: Fri, 16 Mar 2012 08:51:39 +0000 From: Leaf yeh X-Originating-IP: [10.70.39.113] To: "radext@ietf.org" , Alan DeKok Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Discussion on VSA defined in draft-ietf-radext-radius-extensions Thread-index: Ac0DUgB0wEwjBzMbTeuiVlHHZ7CFFQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [radext] Discussion on VSA defined in draft-ietf-radext-radius-extensions 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, 16 Mar 2012 08:51:47 -0000 draft-ietf-radext-radius-extensions defined 6 new attributes, including 24x.26, to solve the issue on the type space exhaustion of VSA. Does it mean Huawei (IANA-PEN=2011) or any enterprise who has the exclusive vendor-id, will inherit these new type space defined in 24x.26 naturally? On the other hand, I am thinking an alternative option for the enterprise who feel the pressure on the type space exhaustion of VSA, why do they not apply for a new exclusive vender-ID to get the extensive 255 new types? The Vendor-ID in the traditional VSA (26) has the length of 4-octect (=2^32). I can't see the exhaustion of Vendor-ID in the future. Just for the examples, Cisco already got 4 PENs, 4857/ 5771/ 5842 /26484; while China Telecom-Guangzhou Research and Development Center already got 2 PENs, 20236/20942. (http://www.iana.org/assignments/enterprise-numbers) If I am wrong (or it is a old question discussed before), pls. feel free to shoot on it. Best Regards, Leaf From aland@deployingradius.com Fri Mar 16 05:24:23 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861D121F85FD for ; Fri, 16 Mar 2012 05:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJuE-eZA-T5S for ; Fri, 16 Mar 2012 05:24:23 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id D5BCD21F8600 for ; Fri, 16 Mar 2012 05:24:22 -0700 (PDT) Received: from thor.lan (69-196-167-168.dsl.teksavvy.com [69.196.167.168]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 187B312344CE; Fri, 16 Mar 2012 13:23:54 +0100 (CET) Message-ID: <4F6330D9.2020609@deployingradius.com> Date: Fri, 16 Mar 2012 08:23:53 -0400 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] Discussion on VSA defined in draft-ietf-radext-radius-extensions 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, 16 Mar 2012 12:24:23 -0000 Leaf yeh wrote: > draft-ietf-radext-radius-extensions defined 6 new attributes, including 24x.26, to solve the issue on the type space exhaustion of VSA. Does it mean Huawei (IANA-PEN=2011) or any enterprise who has the exclusive vendor-id, will inherit these new type space defined in 24x.26 naturally? Yes. That's what the draft says. > On the other hand, I am thinking an alternative option for the enterprise who feel the pressure on the type space exhaustion of VSA, why do they not apply for a new exclusive vender-ID to get the extensive 255 new types? The Vendor-ID in the traditional VSA (26) has the length of 4-octect (=2^32). I can't see the exhaustion of Vendor-ID in the future. See the list archives. A vendor has tried to do that. IANA refused to give them another PEN. > Just for the examples, Cisco already got 4 PENs, 4857/ 5771/ 5842 /26484; while China Telecom-Guangzhou Research and Development Center already got 2 PENs, 20236/20942. (http://www.iana.org/assignments/enterprise-numbers) Those numbers were likely obtained by buying other companies. > If I am wrong (or it is a old question discussed before), pls. feel free to shoot on it. It's been discussed. Alan DeKok. From radext-bounces@ietf.org Fri Mar 16 05:24:25 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D5321F8600; Fri, 16 Mar 2012 05:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331900665; bh=REbf7Bh6bIO1qoeXT32FOgOKhMuDHzp5m/xhzr88sD8=; 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=qFBtshRoQFpbcb91k4pJD1R7GOuI5eBU//hb+5iXzLvmUlh6HU6tq6fwtKrJKSoyr V0O1JN64TVylR/dtR2LGGnM7ut/sOrZJOgXbcsclGrDaVlgOjTyabNDQl+8WYhXcWD yqUIAzSmMxrkywrid92RHgU+pDT5WtXlt/NWodU4= 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 861D121F85FD for ; Fri, 16 Mar 2012 05:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJuE-eZA-T5S for ; Fri, 16 Mar 2012 05:24:23 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id D5BCD21F8600 for ; Fri, 16 Mar 2012 05:24:22 -0700 (PDT) Received: from thor.lan (69-196-167-168.dsl.teksavvy.com [69.196.167.168]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 187B312344CE; Fri, 16 Mar 2012 13:23:54 +0100 (CET) Message-ID: <4F6330D9.2020609@deployingradius.com> Date: Fri, 16 Mar 2012 08:23:53 -0400 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] Discussion on VSA defined in draft-ietf-radext-radius-extensions 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: > draft-ietf-radext-radius-extensions defined 6 new attributes, including 24x.26, to solve the issue on the type space exhaustion of VSA. Does it mean Huawei (IANA-PEN=2011) or any enterprise who has the exclusive vendor-id, will inherit these new type space defined in 24x.26 naturally? Yes. That's what the draft says. > On the other hand, I am thinking an alternative option for the enterprise who feel the pressure on the type space exhaustion of VSA, why do they not apply for a new exclusive vender-ID to get the extensive 255 new types? The Vendor-ID in the traditional VSA (26) has the length of 4-octect (=2^32). I can't see the exhaustion of Vendor-ID in the future. See the list archives. A vendor has tried to do that. IANA refused to give them another PEN. > Just for the examples, Cisco already got 4 PENs, 4857/ 5771/ 5842 /26484; while China Telecom-Guangzhou Research and Development Center already got 2 PENs, 20236/20942. (http://www.iana.org/assignments/enterprise-numbers) Those numbers were likely obtained by buying other companies. > If I am wrong (or it is a old question discussed before), pls. feel free to shoot on it. It's been discussed. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From mauricio.sanchez@hp.com Mon Mar 19 08:44:35 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A362521F8770 for ; Mon, 19 Mar 2012 08:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.188 X-Spam-Level: X-Spam-Status: No, score=-108.188 tagged_above=-999 required=5 tests=[AWL=-1.589, 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 QEdbVCdBIcaC for ; Mon, 19 Mar 2012 08:44:32 -0700 (PDT) Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9784F21F8731 for ; Mon, 19 Mar 2012 08:44:32 -0700 (PDT) Received: from G6W1798G.americas.hpqcorp.net (g6w1798g.atlanta.hp.com [16.230.17.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0028.austin.hp.com (Postfix) with ESMTPS id B54BF1C3E2; Mon, 19 Mar 2012 15:44:31 +0000 (UTC) Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G6W1798G.americas.hpqcorp.net (16.230.17.175) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 19 Mar 2012 15:44:03 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Mon, 19 Mar 2012 15:43:57 +0000 From: "Sanchez, Mauricio (HP Networking)" To: Alejandro Perez Mendez , "radext@ietf.org" Date: Mon, 19 Mar 2012 15:43:59 +0000 Thread-Topic: [radext] IETF 83: Draft agenda Thread-Index: Ac0F5xjxAIL/sKbNTaazvh6r1LWXNA== Message-ID: In-Reply-To: <4F60B79C.5090903@um.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [radext] IETF 83: Draft 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: Mon, 19 Mar 2012 15:44:35 -0000 Ok. 2nd version of agenda posted to meeting materials: http://www.ietf.org/proceedings/83/agenda/agenda-83-radext.txt -MS=20 On 3/14/12 8:22 AM, "Alejandro Perez Mendez" wrote: >If there is enough time, I would like to request a slot (about 15 >minutes) to talk about draft-perez-radext-radius-fragmentation-01 >(http://www.ietf.org/id/draft-perez-radext-radius-fragmentation-01.txt). > >Regards, >Alejandro > >> >> At IETF 83 RADEXT has a two-hour time slot allocated. Below is the >>draft agenda. Please respond with any suggested changes or comments. >> >> Regards, >> MS >> >> --------------- >> >> RADEXT WG IETF 83 Agenda >> >> Chairs: >> Jouni Korhonen >> Mauricio Sanchez >> >> Jabber room: radext at jabber.ietf.org (Please join) >> >> Friday, March 30, 2012 >> 0900-1100 >> Room 212/213 >> >> 9:00 - 09:15 AM, Preliminaries (15 minutes) >> Audio/Video& Remote Presentation Debugging >> Note Well >> Note Takers >> Jabber scribe >> Agenda bash >> Document Status >> >> Draft discussion (60 minutes) >> 9:15 - 9:30 AM RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec >>(15 minutes) >> http://tools.ietf.org/html/draft-ietf-radext-ipv6-access >> >> 9:30 - 9:45 AM RADIUS Accounting Extensions of Traffic Statistics, Leaf >>Yeh (15 minutes) >> http://tools.ietf.org/html/draft-yeh-radext-ext-traffic-statistics >> >> 9:45 - 10:00 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba >>(15 minutes) >> http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt >> >> 10:00 - 10:15 AM RADIUS Protocol Extensions, Alan DeKok (15 minutes) >> http://tools.ietf.org/html/draft-ietf-radext-radius-extensions >> >> Rechartering and Wrap-up (45 minutes) >> 10:15 - 10:45 AM Rechartering/ New Milestones (30 minutes) >> >> 10:45 - 11:00 AM Next Steps: WG Chairs& ADs (15 minutes) >> WG Goals/Milestones status, next steps >> _______________________________________________ >> 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 Mon Mar 19 08:44:36 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF4121F8770; Mon, 19 Mar 2012 08:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332171876; bh=ncAf3R0DrxxwUUOIV7A0Om+lyvo+qL4teFeMoi0HETA=; h=From:To:Date:Message-ID: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=XZp7a/OFCRs9cdkNhM1MlvpGbNX0tZHgL31TgSTd6vPvYaH6gFyHr0ehfBGzNefE5 /L7jp12RgTVMWX4VIshtWSb1xfR/EAUa05nFKYeCyFR8Z+7oQL79u4sCO0+jlm7hvj 8w8GHY3/flS0Bps94gKtasDmsDGrUQNNOLtdhI9U= 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 A362521F8770 for ; Mon, 19 Mar 2012 08:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.188 X-Spam-Level: X-Spam-Status: No, score=-108.188 tagged_above=-999 required=5 tests=[AWL=-1.589, 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 QEdbVCdBIcaC for ; Mon, 19 Mar 2012 08:44:32 -0700 (PDT) Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9784F21F8731 for ; Mon, 19 Mar 2012 08:44:32 -0700 (PDT) Received: from G6W1798G.americas.hpqcorp.net (g6w1798g.atlanta.hp.com [16.230.17.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0028.austin.hp.com (Postfix) with ESMTPS id B54BF1C3E2; Mon, 19 Mar 2012 15:44:31 +0000 (UTC) Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G6W1798G.americas.hpqcorp.net (16.230.17.175) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 19 Mar 2012 15:44:03 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Mon, 19 Mar 2012 15:43:57 +0000 From: "Sanchez, Mauricio (HP Networking)" To: Alejandro Perez Mendez , "radext@ietf.org" Date: Mon, 19 Mar 2012 15:43:59 +0000 Thread-Topic: [radext] IETF 83: Draft agenda Thread-Index: Ac0F5xjxAIL/sKbNTaazvh6r1LWXNA== Message-ID: In-Reply-To: <4F60B79C.5090903@um.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [radext] IETF 83: Draft 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Ok. 2nd version of agenda posted to meeting materials: http://www.ietf.org/proceedings/83/agenda/agenda-83-radext.txt -MS On 3/14/12 8:22 AM, "Alejandro Perez Mendez" wrote: >If there is enough time, I would like to request a slot (about 15 >minutes) to talk about draft-perez-radext-radius-fragmentation-01 >(http://www.ietf.org/id/draft-perez-radext-radius-fragmentation-01.txt). > >Regards, >Alejandro > >> >> At IETF 83 RADEXT has a two-hour time slot allocated. Below is the >>draft agenda. Please respond with any suggested changes or comments. >> >> Regards, >> MS >> >> --------------- >> >> RADEXT WG IETF 83 Agenda >> >> Chairs: >> Jouni Korhonen >> Mauricio Sanchez >> >> Jabber room: radext at jabber.ietf.org (Please join) >> >> Friday, March 30, 2012 >> 0900-1100 >> Room 212/213 >> >> 9:00 - 09:15 AM, Preliminaries (15 minutes) >> Audio/Video& Remote Presentation Debugging >> Note Well >> Note Takers >> Jabber scribe >> Agenda bash >> Document Status >> >> Draft discussion (60 minutes) >> 9:15 - 9:30 AM RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec >>(15 minutes) >> http://tools.ietf.org/html/draft-ietf-radext-ipv6-access >> >> 9:30 - 9:45 AM RADIUS Accounting Extensions of Traffic Statistics, Leaf >>Yeh (15 minutes) >> http://tools.ietf.org/html/draft-yeh-radext-ext-traffic-statistics >> >> 9:45 - 10:00 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba >>(15 minutes) >> http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt >> >> 10:00 - 10:15 AM RADIUS Protocol Extensions, Alan DeKok (15 minutes) >> http://tools.ietf.org/html/draft-ietf-radext-radius-extensions >> >> Rechartering and Wrap-up (45 minutes) >> 10:15 - 10:45 AM Rechartering/ New Milestones (30 minutes) >> >> 10:45 - 11:00 AM Next Steps: WG Chairs& ADs (15 minutes) >> WG Goals/Milestones status, next steps >> _______________________________________________ >> 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 leaf.y.yeh@huawei.com Fri Mar 23 04:30:43 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEC121F84D7 for ; Fri, 23 Mar 2012 04:30:43 -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 Zvv48AVHhxXT for ; Fri, 23 Mar 2012 04:30:42 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8BB21F84D6 for ; Fri, 23 Mar 2012 04:30:42 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEI07873; Fri, 23 Mar 2012 07:30:42 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Mar 2012 04:29:00 -0700 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Mar 2012 04:29:07 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.251]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 23 Mar 2012 19:29:01 +0800 From: Leaf yeh To: Alan DeKok Thread-Topic: Flags in draft-ietf-radext-radius-extensions-04 Thread-Index: Ac0Gi17ixx+O1hrXRdOGEaDZGsyPPQCVkrKw Date: Fri, 23 Mar 2012 11:29:00 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.39.113] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "radext@ietf.org" Subject: Re: [radext] Flags in draft-ietf-radext-radius-extensions-04 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, 23 Mar 2012 11:30:43 -0000 U2VjdGlvbiAyLjIsIGRyYWZ0LWlldGYtcmFkZXh0LXJhZGl1cy1leHRlbnNpb25zLTA0DQoNCjxx dW90ZT5GbGFncw0KDQpUaGlzIGZpZWxkIGlzIDcgYml0cyBsb25nLCBhbmQgaXMgcmVzZXJ2ZWQg Zm9yIGZ1dHVyZSB1c2UuDQpJbXBsZW1lbnRhdGlvbnMgTVVTVCBzZXQgaXQgdG8gemVybyAoMCkg d2hlbiBlbmNvZGluZyBhbiBhdHRyaWJ1dGUNCmZvciBzZW5kaW5nIGluIGEgcGFja2V0LiBUaGUg Y29udGVudHMgU0hPVUxEIGJlIGlnbm9yZWQgb24NCnJlY2VwdGlvbi4NCkZ1dHVyZSBzcGVjaWZp Y2F0aW9ucyBtYXkgZGVmaW5lIGFkZGl0aW9uYWwgbWVhbmluZyBmb3IgdGhpcw0KZmllbGQuIElt cGxlbWVudGF0aW9ucyB0aGVyZWZvcmUgTVVTVCBOT1QgdHJlYXQgdGhpcyBmaWVsZCBhcw0KaW52 YWxpZCBpZiBpdCBpcyBub24temVyby48L3F1b3RlPg0KDQpUaGVyZSBpcyBubyByZWFsIGZsYWdz IGluIHRoaXMgZmllbGQuIEl0IGlzIHJlc2VydmVkIGZvciBmdXR1cmUgdXNlLiANCldvdWxkIHlv dSBtaW5kIHRvIGNoYW5nZSB0aGUgbmFtZSBvZiB0aGlzIGZpZWxkIHRvIGJlICdSZXNlcnZlZCc/ DQoNCg0KQmVzdCBSZWdhcmRzLA0KTGVhZg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9t OiBMZWFmIHllaCANClRvOiAnQWxhbiBEZUtvaycNClN1YmplY3Q6IE1vcmUgdHlwb3MgaW4gZHJh ZnQtaWV0Zi1yYWRleHQtcmFkaXVzLWV4dGVuc2lvbnMtMDQNCg0KRmluZGluZyBpbiB0aGUgY2Fz dWFsIHJlYWRpbmfvvJoNCg0KU2VjdGlvbiAyLjQgb2YgZHJhZnQtaWV0Zi1yYWRleHQtcmFkaXVz LWV4dGVuc2lvbnMtMDQNCg0KMS4gPHF1b3RlPlRoZSAiZXZzIiBkYXRhIHR5cGUgaXMgYW4gZW5j YXBzdWxhdGlvbiBsYXllcg0Kd2hpY2ggd2hpY2ggcGVybWl0cyB0aGUgIlZhbHVlIiBmaWVsZCBv ZiBhbiBBdHRyaWJ1dGUgdG8gY29udGFpbiBhDQpWZW5kb3ItSWQsIGZvbGxvd2VkIGJ5IGEgVmVu ZG9yLVR5cGUsIGFuZCB0aGVuIHZlbmRvci1kZWZpbmVkIGRhdGEuPC9xdW90ZSA+DQoNClRoZXJl IGlzIDEgbW9yZSDigJh3aGljaOKAmSBpbiB0aGUgYWJvdmUgc2VudGVuY2UuDQoNCjIuIDxxdW90 ZT5UaGUgbGVuZ3RoIG9mIHRoZSAiU3RyaW5nIg0KZmllbGQgaXMgaW1wbGljaXQsIGFuZCBpcyBk ZXRlcm1pbmVkIGJ5IHRha2luZyB0aGUgIkxlbmd0aCIgb2YgdGhlDQplbmNhcHN1bGF0aW5nIFJB RElVUyBBdHRyaWJ1dGUsIGFuZCBzdWJ0cmFjdGluZyB0aGUgbGVuZ3RoIG9mIHRoZQ0KYXR0cmli dXRlIGhlYWRlciBpbmNsdWRpbmcgdGhlIDQgb2N0ZXRzIG9mIFZlbmRvci1JZC4gPC9xdW90ZSA+ DQoNClN1cHBvc2VkIHRoZSBhYm92ZSBzZW50ZW5jZSBzaG91bGQgYmUg4oCY4oCmc3VidHJhY3Rp bmcgdGhlIGxlbmd0aCBvZiB0aGUgYXR0cmlidXRlIGhlYWRlciBhbmQgdGhlIEVWUyBoZWFkZXIg aW5jbHVkaW5nIHRoZSA0IG9jdGV0cyBvZiBWZW5kb3ItSWQgYW5kIDEgb2N0ZXQgb2YgVmVuZG9y LXR5cGUu4oCZDQoNCjMuIDxxdW90ZT5Gb3INCiJFeHRlbmRlZCBUeXBlIiBhdHRyaWJ1dGVzLCB0 aGUgbGVuZ3RoIG9mIHRoZSBTdHJpbmcgZmllbGQgaXMgc2V2ZW4NCig3KSBsZXNzIHRoYW4gdGhl IHZhbHVlIG9mIHRoZSBMZW5ndGggZmllbGQuIEZvciAiRXh0ZW5kZWQgVHlwZSB3aXRoDQpGbGFn cyIgYXR0cmlidXRlcywgdGhlIGxlbmd0aCBvZiB0aGUgU3RyaW5nIGZpZWxkIGlzIGVpZ2h0ICg4 KSBsZXNzDQp0aGFuIHRoZSB2YWx1ZSBvZiB0aGUgTGVuZ3RoIGZpZWxkLiA8L3F1b3RlID4NCg0K U3VwcG9zZWQgdGhlIGFib3ZlIHNlbnRlbmNlIHNob3VsZCBiZSDigJhGb3IgIkV4dGVuZGVkIFR5 cGUiIGF0dHJpYnV0ZXMsIOKApi5laWdodCAoOD0zKzUpLi4uRm9yICJFeHRlbmRlZCBUeXBlIHdp dGggRmxhZ3MiIGF0dHJpYnV0ZXMs4oCmbmluZSAoOT00KzUp4oCm4oCZLg0KDQoNCkJlc3QgUmVn YXJkcywNCkxlYWYNCg== From radext-bounces@ietf.org Fri Mar 23 04:30:44 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8EA21F8503; Fri, 23 Mar 2012 04:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332502244; bh=W9DQ35bmg8PyQfLnpqvIWs8ZJ9ZOjCtfUXg9LhxQoFQ=; h=From:To:Date: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=ej325dwzF8WuTboDEJJ820IwGSKx+LI7klF+zuGt0AzhMIQ7vdVA4UVmUBiDSYXmm z2uq6TlYGMIZrnEGOrXGxuRZC9Jho5eV9bipdkSIdR/CC4zsz27yfvT6gD+0abCxfc A1SigbC30Troe1vKVgfeD8d3cTzDTXQOQYLzeTrw= 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 1DEC121F84D7 for ; Fri, 23 Mar 2012 04:30:43 -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 Zvv48AVHhxXT for ; Fri, 23 Mar 2012 04:30:42 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8BB21F84D6 for ; Fri, 23 Mar 2012 04:30:42 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEI07873; Fri, 23 Mar 2012 07:30:42 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Mar 2012 04:29:00 -0700 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Mar 2012 04:29:07 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.251]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 23 Mar 2012 19:29:01 +0800 From: Leaf yeh To: Alan DeKok Thread-Topic: Flags in draft-ietf-radext-radius-extensions-04 Thread-Index: Ac0Gi17ixx+O1hrXRdOGEaDZGsyPPQCVkrKw Date: Fri, 23 Mar 2012 11:29:00 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.39.113] MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "radext@ietf.org" Subject: Re: [radext] Flags in draft-ietf-radext-radius-extensions-04 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 U2VjdGlvbiAyLjIsIGRyYWZ0LWlldGYtcmFkZXh0LXJhZGl1cy1leHRlbnNpb25zLTA0DQoNCjxx dW90ZT5GbGFncw0KDQpUaGlzIGZpZWxkIGlzIDcgYml0cyBsb25nLCBhbmQgaXMgcmVzZXJ2ZWQg Zm9yIGZ1dHVyZSB1c2UuDQpJbXBsZW1lbnRhdGlvbnMgTVVTVCBzZXQgaXQgdG8gemVybyAoMCkg d2hlbiBlbmNvZGluZyBhbiBhdHRyaWJ1dGUNCmZvciBzZW5kaW5nIGluIGEgcGFja2V0LiBUaGUg Y29udGVudHMgU0hPVUxEIGJlIGlnbm9yZWQgb24NCnJlY2VwdGlvbi4NCkZ1dHVyZSBzcGVjaWZp Y2F0aW9ucyBtYXkgZGVmaW5lIGFkZGl0aW9uYWwgbWVhbmluZyBmb3IgdGhpcw0KZmllbGQuIElt cGxlbWVudGF0aW9ucyB0aGVyZWZvcmUgTVVTVCBOT1QgdHJlYXQgdGhpcyBmaWVsZCBhcw0KaW52 YWxpZCBpZiBpdCBpcyBub24temVyby48L3F1b3RlPg0KDQpUaGVyZSBpcyBubyByZWFsIGZsYWdz IGluIHRoaXMgZmllbGQuIEl0IGlzIHJlc2VydmVkIGZvciBmdXR1cmUgdXNlLiANCldvdWxkIHlv dSBtaW5kIHRvIGNoYW5nZSB0aGUgbmFtZSBvZiB0aGlzIGZpZWxkIHRvIGJlICdSZXNlcnZlZCc/ DQoNCg0KQmVzdCBSZWdhcmRzLA0KTGVhZg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9t OiBMZWFmIHllaCANClRvOiAnQWxhbiBEZUtvaycNClN1YmplY3Q6IE1vcmUgdHlwb3MgaW4gZHJh ZnQtaWV0Zi1yYWRleHQtcmFkaXVzLWV4dGVuc2lvbnMtMDQNCg0KRmluZGluZyBpbiB0aGUgY2Fz dWFsIHJlYWRpbmfvvJoNCg0KU2VjdGlvbiAyLjQgb2YgZHJhZnQtaWV0Zi1yYWRleHQtcmFkaXVz LWV4dGVuc2lvbnMtMDQNCg0KMS4gPHF1b3RlPlRoZSAiZXZzIiBkYXRhIHR5cGUgaXMgYW4gZW5j YXBzdWxhdGlvbiBsYXllcg0Kd2hpY2ggd2hpY2ggcGVybWl0cyB0aGUgIlZhbHVlIiBmaWVsZCBv ZiBhbiBBdHRyaWJ1dGUgdG8gY29udGFpbiBhDQpWZW5kb3ItSWQsIGZvbGxvd2VkIGJ5IGEgVmVu ZG9yLVR5cGUsIGFuZCB0aGVuIHZlbmRvci1kZWZpbmVkIGRhdGEuPC9xdW90ZSA+DQoNClRoZXJl IGlzIDEgbW9yZSDigJh3aGljaOKAmSBpbiB0aGUgYWJvdmUgc2VudGVuY2UuDQoNCjIuIDxxdW90 ZT5UaGUgbGVuZ3RoIG9mIHRoZSAiU3RyaW5nIg0KZmllbGQgaXMgaW1wbGljaXQsIGFuZCBpcyBk ZXRlcm1pbmVkIGJ5IHRha2luZyB0aGUgIkxlbmd0aCIgb2YgdGhlDQplbmNhcHN1bGF0aW5nIFJB RElVUyBBdHRyaWJ1dGUsIGFuZCBzdWJ0cmFjdGluZyB0aGUgbGVuZ3RoIG9mIHRoZQ0KYXR0cmli dXRlIGhlYWRlciBpbmNsdWRpbmcgdGhlIDQgb2N0ZXRzIG9mIFZlbmRvci1JZC4gPC9xdW90ZSA+ DQoNClN1cHBvc2VkIHRoZSBhYm92ZSBzZW50ZW5jZSBzaG91bGQgYmUg4oCY4oCmc3VidHJhY3Rp bmcgdGhlIGxlbmd0aCBvZiB0aGUgYXR0cmlidXRlIGhlYWRlciBhbmQgdGhlIEVWUyBoZWFkZXIg aW5jbHVkaW5nIHRoZSA0IG9jdGV0cyBvZiBWZW5kb3ItSWQgYW5kIDEgb2N0ZXQgb2YgVmVuZG9y LXR5cGUu4oCZDQoNCjMuIDxxdW90ZT5Gb3INCiJFeHRlbmRlZCBUeXBlIiBhdHRyaWJ1dGVzLCB0 aGUgbGVuZ3RoIG9mIHRoZSBTdHJpbmcgZmllbGQgaXMgc2V2ZW4NCig3KSBsZXNzIHRoYW4gdGhl IHZhbHVlIG9mIHRoZSBMZW5ndGggZmllbGQuIEZvciAiRXh0ZW5kZWQgVHlwZSB3aXRoDQpGbGFn cyIgYXR0cmlidXRlcywgdGhlIGxlbmd0aCBvZiB0aGUgU3RyaW5nIGZpZWxkIGlzIGVpZ2h0ICg4 KSBsZXNzDQp0aGFuIHRoZSB2YWx1ZSBvZiB0aGUgTGVuZ3RoIGZpZWxkLiA8L3F1b3RlID4NCg0K U3VwcG9zZWQgdGhlIGFib3ZlIHNlbnRlbmNlIHNob3VsZCBiZSDigJhGb3IgIkV4dGVuZGVkIFR5 cGUiIGF0dHJpYnV0ZXMsIOKApi5laWdodCAoOD0zKzUpLi4uRm9yICJFeHRlbmRlZCBUeXBlIHdp dGggRmxhZ3MiIGF0dHJpYnV0ZXMs4oCmbmluZSAoOT00KzUp4oCm4oCZLg0KDQoNCkJlc3QgUmVn YXJkcywNCkxlYWYNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCnJhZGV4dCBtYWlsaW5nIGxpc3QKcmFkZXh0QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0Cg== From aland@deployingradius.com Fri Mar 23 05:07:02 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF0221F84D3 for ; Fri, 23 Mar 2012 05:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-KSZVyZ99qi for ; Fri, 23 Mar 2012 05:07:01 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6FF21F84CE for ; Fri, 23 Mar 2012 05:07:01 -0700 (PDT) Received: from thor.lan (unknown [108.175.226.14]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 75FAA1234411; Fri, 23 Mar 2012 13:06:32 +0100 (CET) Message-ID: <4F6C6749.6010908@deployingradius.com> Date: Fri, 23 Mar 2012 08:06:33 -0400 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=UTF-8 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Flags in draft-ietf-radext-radius-extensions-04 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, 23 Mar 2012 12:07:02 -0000 Leaf yeh wrote: > There is no real flags in this field. It is reserved for future use. > Would you mind to change the name of this field to be 'Reserved'? That's fine. I'll make an update before the WG meeting. Alan DeKok. From radext-bounces@ietf.org Fri Mar 23 05:07:04 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B7E21F84D3; Fri, 23 Mar 2012 05:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332504424; bh=ZH7dxBhecAszNAOoYLWMYuhNxPnEVeMAxE6s36ASp0U=; 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=u0QlF0ySfwp2+KB3e5H6fh9AcgqUfoZIhMOIulzCB1h/Ay0SJz9SwyFbu5L3XvZOf 7tPDH40ZIi0VeJX43Yh+PSNaOE/gkFKbb4o11WqdD+aSW5jipRuTHoEXiN9/SJxYUC VIYEsYIy0C8Q38tUKv0TJjC57489iaxMXWjciBMU= 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 5BF0221F84D3 for ; Fri, 23 Mar 2012 05:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-KSZVyZ99qi for ; Fri, 23 Mar 2012 05:07:01 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6FF21F84CE for ; Fri, 23 Mar 2012 05:07:01 -0700 (PDT) Received: from thor.lan (unknown [108.175.226.14]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 75FAA1234411; Fri, 23 Mar 2012 13:06:32 +0100 (CET) Message-ID: <4F6C6749.6010908@deployingradius.com> Date: Fri, 23 Mar 2012 08:06:33 -0400 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] Flags in draft-ietf-radext-radius-extensions-04 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: > There is no real flags in this field. It is reserved for future use. > Would you mind to change the name of this field to be 'Reserved'? That's fine. I'll make an update before the WG meeting. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From mauricio.sanchez@hp.com Sun Mar 25 06:12:22 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE9021F84B8 for ; Sun, 25 Mar 2012 06:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.989 X-Spam-Level: X-Spam-Status: No, score=-107.989 tagged_above=-999 required=5 tests=[AWL=-1.390, 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 cMvY4sBqOJvS for ; Sun, 25 Mar 2012 06:12:21 -0700 (PDT) Received: from g5t0006.atlanta.hp.com (g5t0006.atlanta.hp.com [15.192.0.43]) by ietfa.amsl.com (Postfix) with ESMTP id BA29C21F84C8 for ; Sun, 25 Mar 2012 06:12:21 -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 g5t0006.atlanta.hp.com (Postfix) with ESMTPS id 0557AC22B for ; Sun, 25 Mar 2012 13:12:20 +0000 (UTC) Received: from G5W0324.americas.hpqcorp.net (16.228.8.69) by G4W3011G.americas.hpqcorp.net (16.234.25.125) with Microsoft SMTP Server (TLS) id 14.1.289.1; Sun, 25 Mar 2012 13:10:02 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0324.americas.hpqcorp.net ([16.228.8.69]) with mapi; Sun, 25 Mar 2012 14:10:01 +0100 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Sun, 25 Mar 2012 14:10:01 +0100 Thread-Topic: RADEXT recharter Thread-Index: Ac0KiJZp1Yuc0eVmQz2NbKgzj34oNQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 13:12:22 -0000 This past January we discussed on the list proposed re-charter text. At th= is time, I would like to restart the discussions based on the updated versi= on that came out of January's discussions. Please review and respond with= feedback, either negative or positive. We will be discussing this topic = on Friday. Thanks, Mauricio and Jouni ------------- Description of Working Group The RADIUS Extensions Working Group will focus on extensions to the RADIUS = protocol required to expand and enrich the standard attribute space, addres= s cryptographic algorithm agility, use of new secure transports and clarify= its usage and definition. In order to enable interoperation of heterogeneous RADIUS/Diameter deployme= nts, all RADEXT WG work items MUST contain a Diameter compatibility section= , outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implemen= tations, as well as compatibility between RADIUS and Diameter, the followin= g restrictions are imposed on extensions considered by the RADEXT WG: - All documents produced MUST specify means of interoperation with legacy R= ADIUS and, if possible, be backward compatible with existing RADIUS RFCs, i= ncluding RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090= , 5176 and 6158. Transport profiles should, if possible, be compatible with= RFC 3539. - All RADIUS work MUST be compatible with equivalent facilities in Diameter= . Where possible, new attributes should be defined so that the same attribu= te can be used in both RADIUS and Diameter without translation. In other ca= ses a translation considerations section should be included in the specific= ation. Work Items The immediate goals of the RADEXT working group are to address the followin= g issues: -RADIUS attribute space extension. The standard RADIUS attribute space is c= urrently being depleted. This document will provide additional standard att= ribute space, while maintaining backward compatibility with existing attrib= utes. -IEEE 802 attributes. New attributes have been proposed to support IEEE 802= standards for wired and wireless LANs. This work item will support authent= ication, authorization and accounting attributes needed by IEEE 802 groups = including IEEE 802.1, IEEE 802.11 and IEEE 802.16. - New RADIUS transports. A reliable transport profile for RADIUS will be de= veloped, as well as specifications for Secure transports, including TCP/TLS= (RADSEC) and UDP/DTLS. - Update and clarification of Network Access Identifiers (RFC4282).This wor= k item will correct and clarify issues present with RFC4282 in two phases. = In first phase, RFC4282bis will be issued to eliminate fundamental incompa= tibilities with RADIUS around character encoding and NAI modifications by p= roxies. In second phase, a fresh review of NAI internationalization requir= ements and behavior will be undertaken with a clear goal of maintaining com= patibility with RADIUS. -RADIUS Accounting Extensions for Traffic Statistics. This work item will s= pecify RADIUS accounting attributes for differentiated accounting polices a= nd traffic recording. Goals and Milestones Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication Done SIP RADIUS authentication draft submitted as a Proposed Standard RFC Done RFC 2486bis submitted as a Proposed Standard RFC Done RFC 3576 MIBs submitted as an Informational RFC Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed Stan= dard RFC (reduced in scope) Done RADIUS Implementation Issues and Fixes draft submitted as an Informati= onal RFC Done RADIUS Filtering Attributes draft submitted as a Proposed Standard RFC= (split out from VLAN & Priority draft) Done RFC 3576bis submitted as an Informational RFC (split out from Issues &= Fixes draft) Done RADIUS Redirection Attributes draft submitted as a Proposed Standard R= FC (split out from VLAN & Priority draft) Done RADIUS Design Guidelines submitted as a Best Current Practice RFC Done RADIUS Management Authorization I-D submitted as a Proposed Standard R= FC Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed Stan= dard RFC Done Status-Server I-D submitted as a Proposed Standard RFC Done RADIUS Crypto-agility Requirements submitted as an Informational RFC Mar 2012 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RF= C Apr 2012 IPv6 Access I-D submitted as a Proposed Standard RFC Apr 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Apr 2012 Extended Attributes I-D submitted as a Proposed Standard RFC Jun 2012 RFC 4282bis submitted as a Proposed Standard RFC Jun 2012 RADIUS over DTLS I-D submitted as an Experimental RFC Jun 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC Oct 2012 RADIUS support for NAI Internationalization I-D submitted as a Pro= posed Standard RFC Dec 2012 Traffic Statistics Attribute I-D submitted as a Proposed Standard = RFC From radext-bounces@ietf.org Sun Mar 25 06:12:24 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2036C21F84C8; Sun, 25 Mar 2012 06:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332681144; bh=jAIClS3ovG+WpEGf1mp4xkozNmE/D9nW5sfICksIP8Y=; 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=vl/HMbMQufcVtxdoWQniiLyoV2ziUfHV6G7Yp608Ojoqocz+EaP+JWsDzfbknOLI6 cNoDzCMg0iskLLMF5SFbuCcHv2wE4/XvpXaS8DzYYMnWX+wbyCG+ieC7LjYwBU+uMW JiQWs7n6UwqGjYZKE1ZWQm5uVCPmweQeNQkR0LSU= 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 8BE9021F84B8 for ; Sun, 25 Mar 2012 06:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.989 X-Spam-Level: X-Spam-Status: No, score=-107.989 tagged_above=-999 required=5 tests=[AWL=-1.390, 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 cMvY4sBqOJvS for ; Sun, 25 Mar 2012 06:12:21 -0700 (PDT) Received: from g5t0006.atlanta.hp.com (g5t0006.atlanta.hp.com [15.192.0.43]) by ietfa.amsl.com (Postfix) with ESMTP id BA29C21F84C8 for ; Sun, 25 Mar 2012 06:12:21 -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 g5t0006.atlanta.hp.com (Postfix) with ESMTPS id 0557AC22B for ; Sun, 25 Mar 2012 13:12:20 +0000 (UTC) Received: from G5W0324.americas.hpqcorp.net (16.228.8.69) by G4W3011G.americas.hpqcorp.net (16.234.25.125) with Microsoft SMTP Server (TLS) id 14.1.289.1; Sun, 25 Mar 2012 13:10:02 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0324.americas.hpqcorp.net ([16.228.8.69]) with mapi; Sun, 25 Mar 2012 14:10:01 +0100 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Sun, 25 Mar 2012 14:10:01 +0100 Thread-Topic: RADEXT recharter Thread-Index: Ac0KiJZp1Yuc0eVmQz2NbKgzj34oNQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US MIME-Version: 1.0 Subject: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This past January we discussed on the list proposed re-charter text. At this time, I would like to restart the discussions based on the updated version that came out of January's discussions. Please review and respond with feedback, either negative or positive. We will be discussing this topic on Friday. Thanks, Mauricio and Jouni ------------- Description of Working Group The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to expand and enrich the standard attribute space, address cryptographic algorithm agility, use of new secure transports and clarify its usage and definition. In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All documents produced MUST specify means of interoperation with legacy RADIUS and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090, 5176 and 6158. Transport profiles should, if possible, be compatible with RFC 3539. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. Work Items The immediate goals of the RADEXT working group are to address the following issues: -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. -IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. - New RADIUS transports. A reliable transport profile for RADIUS will be developed, as well as specifications for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS. - Update and clarification of Network Access Identifiers (RFC4282).This work item will correct and clarify issues present with RFC4282 in two phases. In first phase, RFC4282bis will be issued to eliminate fundamental incompatibilities with RADIUS around character encoding and NAI modifications by proxies. In second phase, a fresh review of NAI internationalization requirements and behavior will be undertaken with a clear goal of maintaining compatibility with RADIUS. -RADIUS Accounting Extensions for Traffic Statistics. This work item will specify RADIUS accounting attributes for differentiated accounting polices and traffic recording. Goals and Milestones Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication Done SIP RADIUS authentication draft submitted as a Proposed Standard RFC Done RFC 2486bis submitted as a Proposed Standard RFC Done RFC 3576 MIBs submitted as an Informational RFC Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed Standard RFC (reduced in scope) Done RADIUS Implementation Issues and Fixes draft submitted as an Informational RFC Done RADIUS Filtering Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) Done RFC 3576bis submitted as an Informational RFC (split out from Issues & Fixes draft) Done RADIUS Redirection Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) Done RADIUS Design Guidelines submitted as a Best Current Practice RFC Done RADIUS Management Authorization I-D submitted as a Proposed Standard RFC Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed Standard RFC Done Status-Server I-D submitted as a Proposed Standard RFC Done RADIUS Crypto-agility Requirements submitted as an Informational RFC Mar 2012 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC Apr 2012 IPv6 Access I-D submitted as a Proposed Standard RFC Apr 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Apr 2012 Extended Attributes I-D submitted as a Proposed Standard RFC Jun 2012 RFC 4282bis submitted as a Proposed Standard RFC Jun 2012 RADIUS over DTLS I-D submitted as an Experimental RFC Jun 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC Oct 2012 RADIUS support for NAI Internationalization I-D submitted as a Proposed Standard RFC Dec 2012 Traffic Statistics Attribute I-D submitted as a Proposed Standard RFC _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From mauricio.sanchez@hp.com Sun Mar 25 06:14:43 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9AE521F84AA for ; Sun, 25 Mar 2012 06:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.835 X-Spam-Level: X-Spam-Status: No, score=-107.835 tagged_above=-999 required=5 tests=[AWL=-1.236, 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 DEbh1lmSfPMH for ; Sun, 25 Mar 2012 06:14:43 -0700 (PDT) Received: from g5t0006.atlanta.hp.com (g5t0006.atlanta.hp.com [15.192.0.43]) by ietfa.amsl.com (Postfix) with ESMTP id 609BD21F8462 for ; Sun, 25 Mar 2012 06:14:43 -0700 (PDT) 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 g5t0006.atlanta.hp.com (Postfix) with ESMTPS id EB254C0ED for ; Sun, 25 Mar 2012 13:14:42 +0000 (UTC) Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 25 Mar 2012 13:13:30 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Sun, 25 Mar 2012 14:13:29 +0100 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Sun, 25 Mar 2012 14:13:30 +0100 Thread-Topic: Slides for IETF 83 RADEXT WG meeting Thread-Index: Ac0KiRKbm1+y33sRRMWTgYDfD1erhA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [radext] Slides for IETF 83 RADEXT WG meeting 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, 25 Mar 2012 13:14:44 -0000 The RADEXT WG is scheduled to meet on Friday, March 30, 2012 from 0900-1100= . If you are scheduled to present, please email slides to myself and Jouni AS= AP. Thanks, MS From radext-bounces@ietf.org Sun Mar 25 06:14:46 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA00621F84AE; Sun, 25 Mar 2012 06:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332681286; bh=QCEyaXyma11DdtcSYxuKRgbwAZ2MbdbHmgc8+ikBTM4=; 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=ubwqULvKTSjgYHB+5Azwg11CcfuMT6CtisyHOMwkYCue23Q8N2wNaPJhBBjb/kTwH 4kmeG+ZtHCLxzc71Z4ZhfQvyx2+OFICxFM28nVT5wfHHh1gExiTQXWVssHgfCNlhiC qhYANMYoBCSrjm+Lho7mTL/33wA8IHWE7wT6V7pQ= 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 D9AE521F84AA for ; Sun, 25 Mar 2012 06:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.835 X-Spam-Level: X-Spam-Status: No, score=-107.835 tagged_above=-999 required=5 tests=[AWL=-1.236, 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 DEbh1lmSfPMH for ; Sun, 25 Mar 2012 06:14:43 -0700 (PDT) Received: from g5t0006.atlanta.hp.com (g5t0006.atlanta.hp.com [15.192.0.43]) by ietfa.amsl.com (Postfix) with ESMTP id 609BD21F8462 for ; Sun, 25 Mar 2012 06:14:43 -0700 (PDT) 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 g5t0006.atlanta.hp.com (Postfix) with ESMTPS id EB254C0ED for ; Sun, 25 Mar 2012 13:14:42 +0000 (UTC) Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 25 Mar 2012 13:13:30 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Sun, 25 Mar 2012 14:13:29 +0100 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Sun, 25 Mar 2012 14:13:30 +0100 Thread-Topic: Slides for IETF 83 RADEXT WG meeting Thread-Index: Ac0KiRKbm1+y33sRRMWTgYDfD1erhA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US MIME-Version: 1.0 Subject: [radext] Slides for IETF 83 RADEXT WG meeting 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 RADEXT WG is scheduled to meet on Friday, March 30, 2012 from 0900-1100. If you are scheduled to present, please email slides to myself and Jouni ASAP. Thanks, MS _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From mauricio.sanchez@hp.com Sun Mar 25 06:23:13 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DB021F84B4 for ; Sun, 25 Mar 2012 06:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.711 X-Spam-Level: X-Spam-Status: No, score=-109.711 tagged_above=-999 required=5 tests=[AWL=0.888, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Uzo5ZdCK0c8 for ; Sun, 25 Mar 2012 06:23:11 -0700 (PDT) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5A41321F8445 for ; Sun, 25 Mar 2012 06:23:11 -0700 (PDT) Received: from G6W1798G.americas.hpqcorp.net (g6w1798g.atlanta.hp.com [16.230.17.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0027.austin.hp.com (Postfix) with ESMTPS id ECBC538270 for ; Sun, 25 Mar 2012 13:23:10 +0000 (UTC) Received: from G5W0325.americas.hpqcorp.net (16.228.8.67) by G6W1798G.americas.hpqcorp.net (16.230.17.175) with Microsoft SMTP Server (TLS) id 14.1.289.1; Sun, 25 Mar 2012 13:23:09 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0325.americas.hpqcorp.net ([16.228.8.67]) with mapi; Sun, 25 Mar 2012 14:22:45 +0100 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Sun, 25 Mar 2012 14:22:45 +0100 Thread-Topic: Summary of Call for Adoption as RADEXT WG work item: draft-aboba-radext-wlan-15 Thread-Index: Ac0Kil2DdKTcBOhBQPGBo0CvqOHkjw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [radext] Summary of Call for Adoption as RADEXT WG work item: draft-aboba-radext-wlan-15 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, 25 Mar 2012 13:23:13 -0000 The Call for Adoption of draft-aboba-radext-wlan-15 concluded February 6, 2= 012: http://www.ietf.org/mail-archive/web/radext/current/msg07412.html Based on the WG response, this document is now adopted as a RADEXT WG work = item. Authors: please submit the document as draft-ietf-radext-wlan-00.txt ASAP. From radext-bounces@ietf.org Sun Mar 25 06:23:15 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92AC21F84B4; Sun, 25 Mar 2012 06:23:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332681794; bh=merc3LJIlT5ic+iw59qxYhFS2htokjWKxD7n15eRU4I=; 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=v6wzHePZ0jF8S2nN9QChitagQaggp+GbMKt8sFK/1Svc5UlrO8l6PIaVfrd5yM0tL 3rmodj6xuJJAWHac6nCLCXdahiAynj99Mb5Kx8NX/6rAUfcSsTUVtnUsAC2x5el3C3 7+yY9L9CNJbSREOUnqOWKKBMCJ3xdfvLqU5zIaKI= 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 14DB021F84B4 for ; Sun, 25 Mar 2012 06:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.711 X-Spam-Level: X-Spam-Status: No, score=-109.711 tagged_above=-999 required=5 tests=[AWL=0.888, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Uzo5ZdCK0c8 for ; Sun, 25 Mar 2012 06:23:11 -0700 (PDT) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5A41321F8445 for ; Sun, 25 Mar 2012 06:23:11 -0700 (PDT) Received: from G6W1798G.americas.hpqcorp.net (g6w1798g.atlanta.hp.com [16.230.17.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0027.austin.hp.com (Postfix) with ESMTPS id ECBC538270 for ; Sun, 25 Mar 2012 13:23:10 +0000 (UTC) Received: from G5W0325.americas.hpqcorp.net (16.228.8.67) by G6W1798G.americas.hpqcorp.net (16.230.17.175) with Microsoft SMTP Server (TLS) id 14.1.289.1; Sun, 25 Mar 2012 13:23:09 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0325.americas.hpqcorp.net ([16.228.8.67]) with mapi; Sun, 25 Mar 2012 14:22:45 +0100 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Sun, 25 Mar 2012 14:22:45 +0100 Thread-Topic: Summary of Call for Adoption as RADEXT WG work item: draft-aboba-radext-wlan-15 Thread-Index: Ac0Kil2DdKTcBOhBQPGBo0CvqOHkjw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US MIME-Version: 1.0 Subject: [radext] Summary of Call for Adoption as RADEXT WG work item: draft-aboba-radext-wlan-15 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 Call for Adoption of draft-aboba-radext-wlan-15 concluded February 6, 2012: http://www.ietf.org/mail-archive/web/radext/current/msg07412.html Based on the WG response, this document is now adopted as a RADEXT WG work item. Authors: please submit the document as draft-ietf-radext-wlan-00.txt ASAP. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Sun Mar 25 06:54:36 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40FF21F84DA for ; Sun, 25 Mar 2012 06:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjgoFLMPCDVY for ; Sun, 25 Mar 2012 06:54:36 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 53A0221F84D9 for ; Sun, 25 Mar 2012 06:54:36 -0700 (PDT) Received: from thor.lan (69-196-139-132.dsl.teksavvy.com [69.196.139.132]) by liberty.deployingradius.com (Postfix) with ESMTPSA id D31D612342FD; Sun, 25 Mar 2012 15:54:07 +0200 (CEST) Message-ID: <4F6F2380.50207@deployingradius.com> Date: Sun, 25 Mar 2012 09:54:08 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Sanchez, Mauricio (HP Networking)" 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] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 13:54:37 -0000 Sanchez, Mauricio (HP Networking) wrote: > - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. Hmm... the extensions document doesn't have a Diameter considerations section. Oops. I'll go add one. Any opinions as to how the new attributes should be represented in Diameter? Alan DeKok. From radext-bounces@ietf.org Sun Mar 25 06:54:38 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A5F21F84DA; Sun, 25 Mar 2012 06:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332683678; bh=2taP5nRrB94eEK2Es8Am7G48IbcuGc2AyD9H5VZU5NM=; 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=YOfiS/RsObcUjBuVp5yi0+GqUsWNx70AUCAXFhp8r0Y0lrsVubyaY43jAaAOvqoce dLQPGjtkGGxTswVPStU16u81niaUJFH0x999zHpZGqdjYplPS0IBTYlnsUbqN7kH7n rTBdANLHn2J484V0aymRR/c3Mq5KsMNo9mKi7xo4= 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 E40FF21F84DA for ; Sun, 25 Mar 2012 06:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjgoFLMPCDVY for ; Sun, 25 Mar 2012 06:54:36 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 53A0221F84D9 for ; Sun, 25 Mar 2012 06:54:36 -0700 (PDT) Received: from thor.lan (69-196-139-132.dsl.teksavvy.com [69.196.139.132]) by liberty.deployingradius.com (Postfix) with ESMTPSA id D31D612342FD; Sun, 25 Mar 2012 15:54:07 +0200 (CEST) Message-ID: <4F6F2380.50207@deployingradius.com> Date: Sun, 25 Mar 2012 09:54:08 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Sanchez, Mauricio (HP Networking)" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Sanchez, Mauricio (HP Networking) wrote: > - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. Hmm... the extensions document doesn't have a Diameter considerations section. Oops. I'll go add one. Any opinions as to how the new attributes should be represented in Diameter? Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From mauricio.sanchez@hp.com Thu Mar 29 02:16:38 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E466321F8A24 for ; Thu, 29 Mar 2012 02:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.792 X-Spam-Level: X-Spam-Status: No, score=-109.792 tagged_above=-999 required=5 tests=[AWL=0.807, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZysod2dRSSg for ; Thu, 29 Mar 2012 02:16:38 -0700 (PDT) Received: from g6t0187.atlanta.hp.com (g6t0187.atlanta.hp.com [15.193.32.64]) by ietfa.amsl.com (Postfix) with ESMTP id 41CC721F8A17 for ; Thu, 29 Mar 2012 02:16:34 -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 g6t0187.atlanta.hp.com (Postfix) with ESMTPS id BFCF42812C for ; Thu, 29 Mar 2012 09:16:30 +0000 (UTC) Received: from G5W0325.americas.hpqcorp.net (16.228.8.67) by G9W0369G.americas.hpqcorp.net (16.216.193.232) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 29 Mar 2012 09:15:37 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0325.americas.hpqcorp.net ([16.228.8.67]) with mapi; Thu, 29 Mar 2012 10:15:36 +0100 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Thu, 29 Mar 2012 10:15:36 +0100 Thread-Topic: Last call for slides for IETF 83 RADEXT WG meeting Thread-Index: Ac0NjIAhI4txE3hUTnC7SXl8+zKTlg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [radext] Last call for slides for IETF 83 RADEXT WG meeting 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, 29 Mar 2012 09:16:39 -0000 The RADEXT WG is scheduled to meet tomorrow, March 30, 2012 from 0900-1100. If you are scheduled to present, please email slides to myself and Jouni AS= AP. Thanks to those that have already submitted their slides. Thanks, MS From radext-bounces@ietf.org Thu Mar 29 02:16:40 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9E621F8A1C; Thu, 29 Mar 2012 02:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333012600; bh=CS6bPanPVVwymgZ+dxaV9fQxM2moayNb+aHAOaEWUiA=; h=From:To:Date:Message-ID: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=SqA129tJPOcUKWYaIEfbR8IOsNhvOOI1n1tU/2UDEf8GC6KTA687SkBdudnf0L4sN vurpsOfHshCfLePwL5sqF/7wnAkwzLhqh48HuDmyadEgzJTE4TtYUjWZ0JhS7FKkpC 9sQ0G516pzjY863awgi9H7ZCfIsE8N1mybPGk+PI= 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 E466321F8A24 for ; Thu, 29 Mar 2012 02:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.792 X-Spam-Level: X-Spam-Status: No, score=-109.792 tagged_above=-999 required=5 tests=[AWL=0.807, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZysod2dRSSg for ; Thu, 29 Mar 2012 02:16:38 -0700 (PDT) Received: from g6t0187.atlanta.hp.com (g6t0187.atlanta.hp.com [15.193.32.64]) by ietfa.amsl.com (Postfix) with ESMTP id 41CC721F8A17 for ; Thu, 29 Mar 2012 02:16:34 -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 g6t0187.atlanta.hp.com (Postfix) with ESMTPS id BFCF42812C for ; Thu, 29 Mar 2012 09:16:30 +0000 (UTC) Received: from G5W0325.americas.hpqcorp.net (16.228.8.67) by G9W0369G.americas.hpqcorp.net (16.216.193.232) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 29 Mar 2012 09:15:37 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0325.americas.hpqcorp.net ([16.228.8.67]) with mapi; Thu, 29 Mar 2012 10:15:36 +0100 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Thu, 29 Mar 2012 10:15:36 +0100 Thread-Topic: Last call for slides for IETF 83 RADEXT WG meeting Thread-Index: Ac0NjIAhI4txE3hUTnC7SXl8+zKTlg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US MIME-Version: 1.0 Subject: [radext] Last call for slides for IETF 83 RADEXT WG meeting 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 RADEXT WG is scheduled to meet tomorrow, March 30, 2012 from 0900-1100. If you are scheduled to present, please email slides to myself and Jouni ASAP. Thanks to those that have already submitted their slides. Thanks, MS _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From mauricio.sanchez@hp.com Thu Mar 29 06:12:08 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E86721F84FC for ; Thu, 29 Mar 2012 06:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.859 X-Spam-Level: X-Spam-Status: No, score=-109.859 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FP3VvneHzFK for ; Thu, 29 Mar 2012 06:12:06 -0700 (PDT) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by ietfa.amsl.com (Postfix) with ESMTP id 905DD21F8B29 for ; Thu, 29 Mar 2012 06:12:06 -0700 (PDT) Received: from G6W1798G.americas.hpqcorp.net (g6w1798g.atlanta.hp.com [16.230.17.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0027.austin.hp.com (Postfix) with ESMTPS id 0707138376; Thu, 29 Mar 2012 13:12:05 +0000 (UTC) Received: from G5W0325.americas.hpqcorp.net (16.228.8.67) by G6W1798G.americas.hpqcorp.net (16.230.17.175) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 29 Mar 2012 13:11:58 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0325.americas.hpqcorp.net ([16.228.8.67]) with mapi; Thu, 29 Mar 2012 14:11:22 +0100 From: "Sanchez, Mauricio (HP Networking)" To: Alan DeKok Date: Thu, 29 Mar 2012 14:11:22 +0100 Thread-Topic: [radext] RADEXT recharter Thread-Index: Ac0NrW/0LMUJbBj/SreeunpiJfyMJw== Message-ID: In-Reply-To: <4F6F2380.50207@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 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 recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:12:08 -0000 Can you be more specific? -MS On 3/25/12 3:54 PM, "Alan DeKok" wrote: > > Any opinions as to how the new attributes should be represented in >Diameter? > > Alan DeKok. From radext-bounces@ietf.org Thu Mar 29 06:12:11 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6083521F8739; Thu, 29 Mar 2012 06:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333026731; bh=0Gm+vjOg/CxhZ+VQE6AQAQdaCA18sPvWpkqtFW+hdoo=; h=From:To:Date: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=RNBX+3x7djDEMFCQdm0xlKXCB9B5V5uX8+LefYicDqmGTb/gN60vs4I7bTMM1QhY3 fv1HhufNVZNUibY3td0g3kV3O8wNP5t7jnM56bOmVf2f3oYZWqMNZIN/Pd+stSkMLs hahNajCqU47dxlzre36QDHNNenbsWnWGa/CoLy5A= 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 0E86721F84FC for ; Thu, 29 Mar 2012 06:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.859 X-Spam-Level: X-Spam-Status: No, score=-109.859 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FP3VvneHzFK for ; Thu, 29 Mar 2012 06:12:06 -0700 (PDT) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by ietfa.amsl.com (Postfix) with ESMTP id 905DD21F8B29 for ; Thu, 29 Mar 2012 06:12:06 -0700 (PDT) Received: from G6W1798G.americas.hpqcorp.net (g6w1798g.atlanta.hp.com [16.230.17.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0027.austin.hp.com (Postfix) with ESMTPS id 0707138376; Thu, 29 Mar 2012 13:12:05 +0000 (UTC) Received: from G5W0325.americas.hpqcorp.net (16.228.8.67) by G6W1798G.americas.hpqcorp.net (16.230.17.175) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 29 Mar 2012 13:11:58 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0325.americas.hpqcorp.net ([16.228.8.67]) with mapi; Thu, 29 Mar 2012 14:11:22 +0100 From: "Sanchez, Mauricio (HP Networking)" To: Alan DeKok Date: Thu, 29 Mar 2012 14:11:22 +0100 Thread-Topic: [radext] RADEXT recharter Thread-Index: Ac0NrW/0LMUJbBj/SreeunpiJfyMJw== Message-ID: In-Reply-To: <4F6F2380.50207@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US MIME-Version: 1.0 Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Can you be more specific? -MS On 3/25/12 3:54 PM, "Alan DeKok" wrote: > > Any opinions as to how the new attributes should be represented in >Diameter? > > Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Thu Mar 29 07:37:45 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20AB21F88BC; Thu, 29 Mar 2012 07:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333031865; bh=MeoAsYvAE7TcOjFGo5C9cmLozr16E2GjUK0Fwhox+JE=; 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=q2PCl73s0x8bx4tSw5ddRp2ygu42vAOU/J8SNfI1xfjDSnR1ZWUIqMns3aOqfmnVp /5NHrwdW6lIi47HhPe/H/24zqiuzu4oTq9I59OfyydIdSHnbcgnjnpwIuKrjoMKjks SDfErti7A9wu23D0kINXoLQcLbR8sjmPNWHFYAMg= 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 4592D21F88BC for ; Thu, 29 Mar 2012 07:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9+rUtu4TxiV for ; Thu, 29 Mar 2012 07:37:43 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id C792021F88BB for ; Thu, 29 Mar 2012 07:37:42 -0700 (PDT) Received: from dhcp-5051.meeting.ietf.org (dhcp-5051.meeting.ietf.org [130.129.80.81]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 0827D12340D7; Thu, 29 Mar 2012 16:37:13 +0200 (CEST) Message-ID: <4F747395.20602@deployingradius.com> Date: Thu, 29 Mar 2012 16:37:09 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Sanchez, Mauricio (HP Networking)" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Sanchez, Mauricio (HP Networking) wrote: > Can you be more specific? What text should go into the Diameter Considerations section? Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Thu Mar 29 07:37:44 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4592D21F88BC for ; Thu, 29 Mar 2012 07:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9+rUtu4TxiV for ; Thu, 29 Mar 2012 07:37:43 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id C792021F88BB for ; Thu, 29 Mar 2012 07:37:42 -0700 (PDT) Received: from dhcp-5051.meeting.ietf.org (dhcp-5051.meeting.ietf.org [130.129.80.81]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 0827D12340D7; Thu, 29 Mar 2012 16:37:13 +0200 (CEST) Message-ID: <4F747395.20602@deployingradius.com> Date: Thu, 29 Mar 2012 16:37:09 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Sanchez, Mauricio (HP Networking)" 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] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:37:44 -0000 Sanchez, Mauricio (HP Networking) wrote: > Can you be more specific? What text should go into the Diameter Considerations section? Alan DeKok. From aland@deployingradius.com Sat Mar 31 01:48:55 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DBC21F865E; Sat, 31 Mar 2012 01:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.4 X-Spam-Level: X-Spam-Status: No, score=-102.4 tagged_above=-999 required=5 tests=[AWL=0.199, 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 En3AP3fwopHs; Sat, 31 Mar 2012 01:48:54 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4C921F8645; Sat, 31 Mar 2012 01:48:54 -0700 (PDT) Message-ID: <4F76C4D8.9080804@deployingradius.com> Date: Sat, 31 Mar 2012 10:48:24 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "radext@ietf.org" , "abfab@ietf.org" X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [radext] Fragmentation in 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: Sat, 31 Mar 2012 08:48:55 -0000 Alejandro presented the fragmentation draft in RADEXT. There was a long discussion around it. One suggestion was to just use Diameter for transporting large amounts of authorization data. That won't work, for the simple reason that the people involved don't run Diameter, have no plans to run Diameter, and have no budget to get Diameter. The consensus was that the document presents 3 related problems and solutions: 1) using Authorize-Only with Access-Accept It's currently specified for CoA (RFC 5176, Section 3.2). In this use-case, a CoA packet contains a State and Service-Type = Authorize-Only. The NAS then sends an Access-Request, with the same State and Authorize-Only. The RADIUS server responds with new authorization data. The same method could be used by sending Service-Type = Authorize-Only in an Access-Accept. This would need standardization. 2) Sending large amounts of authorization data The limit on RADIUS packet size is 4K. These limits have been run into in real-world deployments. e.g. sending large amounts of filter rules to a NAS. It would be useful to extend method (1) above to allow for more than 4K of authorization data to be sent. The draft proposes using Authorize-Only, and a sequence of Access-Request / Access-Challenge packets. Since challenges are widely implemented in servers and clients, this is an appealing approach. The major change to RADIUS here is to update RFC 2865 Section 5.44, to allow authorization attributes inside of Access-Challenge packets. This permission should be limited to Access-Requests having Service-Type = Authorize-Only. The result is a way to send arbitrary amounts of authorization data to a NAS. The extensions to RADIUS are hopefully minor, and not contentious. 3) Proxying large packets The solution to (2) above aggravates an existing problem in RADIUS. The specs are silent on what to do when a Proxy receives a large packet (<4K), and wants to add data to make the packet >4K. The problem is made worse by UDP fragmentation. Fragmented UDP packets can be dropped by intermediate routers, making the practical limit for RADIUS packets to be much smaller. The result is that it's difficult to send large amounts of authorization data from a server to a client, through intermediate proxies. The solution to (2) above helps by fragmenting the packets. However, we still don't know how large to make those fragments. And we don't know how to allow the proxies to re-write attributes when the authorization data is fragmented across multiple packets. The goal is to allow proxies to know how large to make the fragments, and also to allow them to re-write the authorization data. The draft proposes a number of work-arounds. One would be to have a new attribute like Framed-MTU, but instead "RADIUS MTU". It would signify the maximum size for RADIUS packets. This would allow home servers to know how large to make the fragments. The difficulty there is that the proxies still see fragments, and they want to re-write all of the authorization data. So they need to see *all* of the data. Re-writing each packet on the fly is likely unworkable. The draft proposes that the proxies obtain *all* of the data before re-writing it. This involves no changes to RADIUS. It does, however, require changes to implementations. These changes are documented, so that everyone is aware of the costs and benefits of the solution. And, so that the implementations are guided to a method that works. This message is long, but I hope it clarifies issues around the fragmentation draft. Alan DeKok. From radext-bounces@ietf.org Sat Mar 31 01:48:57 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0658B21F865E; Sat, 31 Mar 2012 01:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333183737; bh=jA+zt2oUfPgqkfEiGVeqbJu/C/bFn/OtvkdeQQeTZcM=; 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=spMJOC5Gisj/7z6C5y0bp3W/eTQrkxhEH5cZQfWAxBK7/KJknjgWZ2ezRC7SDmLmE vRXNGHD7pP0oBZDxGwLunqcJnD5K37EJin3Du1jhkXAzCXg0FQqMawtoUWQSDOXCdf Ydhh8gbfOalWmTQAmJZ1YRNxoTssidkjStIAKMQ0= 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 75DBC21F865E; Sat, 31 Mar 2012 01:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.4 X-Spam-Level: X-Spam-Status: No, score=-102.4 tagged_above=-999 required=5 tests=[AWL=0.199, 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 En3AP3fwopHs; Sat, 31 Mar 2012 01:48:54 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4C921F8645; Sat, 31 Mar 2012 01:48:54 -0700 (PDT) Message-ID: <4F76C4D8.9080804@deployingradius.com> Date: Sat, 31 Mar 2012 10:48:24 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "radext@ietf.org" , "abfab@ietf.org" X-Enigmail-Version: 0.96.0 Subject: [radext] Fragmentation in 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 Alejandro presented the fragmentation draft in RADEXT. There was a long discussion around it. One suggestion was to just use Diameter for transporting large amounts of authorization data. That won't work, for the simple reason that the people involved don't run Diameter, have no plans to run Diameter, and have no budget to get Diameter. The consensus was that the document presents 3 related problems and solutions: 1) using Authorize-Only with Access-Accept It's currently specified for CoA (RFC 5176, Section 3.2). In this use-case, a CoA packet contains a State and Service-Type = Authorize-Only. The NAS then sends an Access-Request, with the same State and Authorize-Only. The RADIUS server responds with new authorization data. The same method could be used by sending Service-Type = Authorize-Only in an Access-Accept. This would need standardization. 2) Sending large amounts of authorization data The limit on RADIUS packet size is 4K. These limits have been run into in real-world deployments. e.g. sending large amounts of filter rules to a NAS. It would be useful to extend method (1) above to allow for more than 4K of authorization data to be sent. The draft proposes using Authorize-Only, and a sequence of Access-Request / Access-Challenge packets. Since challenges are widely implemented in servers and clients, this is an appealing approach. The major change to RADIUS here is to update RFC 2865 Section 5.44, to allow authorization attributes inside of Access-Challenge packets. This permission should be limited to Access-Requests having Service-Type = Authorize-Only. The result is a way to send arbitrary amounts of authorization data to a NAS. The extensions to RADIUS are hopefully minor, and not contentious. 3) Proxying large packets The solution to (2) above aggravates an existing problem in RADIUS. The specs are silent on what to do when a Proxy receives a large packet (<4K), and wants to add data to make the packet >4K. The problem is made worse by UDP fragmentation. Fragmented UDP packets can be dropped by intermediate routers, making the practical limit for RADIUS packets to be much smaller. The result is that it's difficult to send large amounts of authorization data from a server to a client, through intermediate proxies. The solution to (2) above helps by fragmenting the packets. However, we still don't know how large to make those fragments. And we don't know how to allow the proxies to re-write attributes when the authorization data is fragmented across multiple packets. The goal is to allow proxies to know how large to make the fragments, and also to allow them to re-write the authorization data. The draft proposes a number of work-arounds. One would be to have a new attribute like Framed-MTU, but instead "RADIUS MTU". It would signify the maximum size for RADIUS packets. This would allow home servers to know how large to make the fragments. The difficulty there is that the proxies still see fragments, and they want to re-write all of the authorization data. So they need to see *all* of the data. Re-writing each packet on the fly is likely unworkable. The draft proposes that the proxies obtain *all* of the data before re-writing it. This involves no changes to RADIUS. It does, however, require changes to implementations. These changes are documented, so that everyone is aware of the costs and benefits of the solution. And, so that the implementations are guided to a method that works. This message is long, but I hope it clarifies issues around the fragmentation draft. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext