From stefan.winter@restena.lu Tue Dec 20 00:22:57 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF2121F851F for ; Tue, 20 Dec 2011 00:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHGNrKnqCGFH for ; Tue, 20 Dec 2011 00:22:57 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 0B73F21F851A for ; Tue, 20 Dec 2011 00:22:54 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 5C616109FA for ; Tue, 20 Dec 2011 09:22:51 +0100 (CET) Received: from [IPv6:2001:a18:1:8:198e:f526:b969:d03c] (unknown [IPv6:2001:a18:1:8:198e:f526:b969:d03c]) by smtprelay.restena.lu (Postfix) with ESMTPS id 4B0FA106CB for ; Tue, 20 Dec 2011 09:22:51 +0100 (CET) Message-ID: <4EF04640.9060200@restena.lu> Date: Tue, 20 Dec 2011 09:24:32 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: radext@ietf.org References: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE1979@GVW0671EXC.americas.hpqcorp.net> In-Reply-To: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE1979@GVW0671EXC.americas.hpqcorp.net> X-Enigmail-Version: 1.3.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig550D864867C56F7EAB1FE1FF" X-Virus-Scanned: ClamAV Subject: Re: [radext] Call for document shepherd for draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 08:22:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig550D864867C56F7EAB1FE1FF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 15.11.2011 10:34, Sanchez, Mauricio (HP Networking) wrote: > Anyone interested in taking on this important duty is requested to reac= h out to the chairs over the next week (on or before 22nd). That was 22nd of November, so reading this one month later, I guess nobody spoke up. > Otherwise, the chairs will be forced to use a game of chance or skill t= o determine which chair takes on the duty. Have the dice already fallen? Greetings, Stefan --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig550D864867C56F7EAB1FE1FF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7wRkYACgkQ+jm90f8eFWaRcACfcf3jW5xCQQSC8+jQTrqldXaQ EToAn3FE5AKISIYN6qNMa/JksaRrSHZv =MJCq -----END PGP SIGNATURE----- --------------enig550D864867C56F7EAB1FE1FF-- From radext-bounces@ietf.org Tue Dec 20 00:22:59 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A1121F851A; Tue, 20 Dec 2011 00:22:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1324369379; bh=tRxVVl3tDN+fUugNV7fCMCSEJDoPJKkq7rziMMcbjIA=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=a5VfFARI5z2vqVRS3GV+7DQ8+RqJZ9Oem/cMd2ZBPhfzeulpBgtX0ixzggTZuwpaf w1DyUzI3i1K1JJzYF/L8rX+fWBdodCxxa2/eKsMb1GCoIYSVixmNFZ1I4KDwFKLIS1 x8cRso81WWHneq7M9XenOC3DEjcaNeJPqIi6LBmY= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF2121F851F for ; Tue, 20 Dec 2011 00:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHGNrKnqCGFH for ; Tue, 20 Dec 2011 00:22:57 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 0B73F21F851A for ; Tue, 20 Dec 2011 00:22:54 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 5C616109FA for ; Tue, 20 Dec 2011 09:22:51 +0100 (CET) Received: from [IPv6:2001:a18:1:8:198e:f526:b969:d03c] (unknown [IPv6:2001:a18:1:8:198e:f526:b969:d03c]) by smtprelay.restena.lu (Postfix) with ESMTPS id 4B0FA106CB for ; Tue, 20 Dec 2011 09:22:51 +0100 (CET) Message-ID: <4EF04640.9060200@restena.lu> Date: Tue, 20 Dec 2011 09:24:32 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: radext@ietf.org References: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE1979@GVW0671EXC.americas.hpqcorp.net> In-Reply-To: <9BC2F7926B33FE4AB10D69891D58FC1C5CD1AE1979@GVW0671EXC.americas.hpqcorp.net> X-Enigmail-Version: 1.3.4 X-Virus-Scanned: ClamAV Subject: Re: [radext] Call for document shepherd for draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6341764629829804115==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============6341764629829804115== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig550D864867C56F7EAB1FE1FF" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig550D864867C56F7EAB1FE1FF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 15.11.2011 10:34, Sanchez, Mauricio (HP Networking) wrote: > Anyone interested in taking on this important duty is requested to reac= h out to the chairs over the next week (on or before 22nd). That was 22nd of November, so reading this one month later, I guess nobody spoke up. > Otherwise, the chairs will be forced to use a game of chance or skill t= o determine which chair takes on the duty. Have the dice already fallen? Greetings, Stefan --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig550D864867C56F7EAB1FE1FF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7wRkYACgkQ+jm90f8eFWaRcACfcf3jW5xCQQSC8+jQTrqldXaQ EToAn3FE5AKISIYN6qNMa/JksaRrSHZv =MJCq -----END PGP SIGNATURE----- --------------enig550D864867C56F7EAB1FE1FF-- --===============6341764629829804115== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============6341764629829804115==-- From radext-bounces@ietf.org Wed Dec 21 05:16:25 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1596521F8B16; Wed, 21 Dec 2011 05:16:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1324473385; bh=MnlwWgRsZb1UQnoVoRkCkLoQNmPIvXJJiFjb8y3s/uc=; 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=cIrIjkGmtK9GG+su4XXXBd69tQa72XP8GXMlOb+UV7fQecllf9HCkc2b7/Zom9jN9 S1IdgiyTUrDYtCsRBb+EIz4Zm2acsJ1pMKRg5SezltVg3a5q6wpol0ZZvwYak3/WRl fCfV0pgRAz6d7MPk9DtQQmxwrTB4tVU/rgx+JN+s= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2909921F8B16 for ; Wed, 21 Dec 2011 05:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.11 X-Spam-Level: X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 kVdzi-p3UrOY for ; Wed, 21 Dec 2011 05:16:23 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id A12ED21F8B14 for ; Wed, 21 Dec 2011 05:16:23 -0800 (PST) Message-ID: <4EF1DC0A.1070004@deployingradius.com> Date: Wed, 21 Dec 2011 08:15:54 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: 'radext mailing list' X-Enigmail-Version: 0.96.0 Subject: [radext] Status of extensions document? 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 haven't seen any comments on the latest draft. There were some typos from Leaf, and IANA comments from Bernard. Have they been addressed to the WGs satisfaction? Having the document move forward would be a wonderful xmas present. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Wed Dec 21 05:16:24 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2909921F8B16 for ; Wed, 21 Dec 2011 05:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.11 X-Spam-Level: X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 kVdzi-p3UrOY for ; Wed, 21 Dec 2011 05:16:23 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id A12ED21F8B14 for ; Wed, 21 Dec 2011 05:16:23 -0800 (PST) Message-ID: <4EF1DC0A.1070004@deployingradius.com> Date: Wed, 21 Dec 2011 08:15:54 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: 'radext mailing list' X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [radext] Status of extensions document? 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, 21 Dec 2011 13:16:24 -0000 I haven't seen any comments on the latest draft. There were some typos from Leaf, and IANA comments from Bernard. Have they been addressed to the WGs satisfaction? Having the document move forward would be a wonderful xmas present. Alan DeKok. From leaf.y.yeh@huawei.com Fri Dec 23 01:40:50 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8092B21F8B32 for ; Fri, 23 Dec 2011 01:40:50 -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 GyhazVKZXBV1 for ; Fri, 23 Dec 2011 01:40:50 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id E9EC621F8B16 for ; Fri, 23 Dec 2011 01:40:49 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWN00DQRHJUDK@szxga05-in.huawei.com> for radext@ietf.org; Fri, 23 Dec 2011 17:40:42 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWN00GFLHJU4B@szxga05-in.huawei.com> for radext@ietf.org; Fri, 23 Dec 2011 17:40:42 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFZ59996; Fri, 23 Dec 2011 17:40:39 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Dec 2011 17:40:32 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.223]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Fri, 23 Dec 2011 17:40:34 +0800 Date: Fri, 23 Dec 2011 09:39:40 +0000 From: Leaf yeh In-reply-to: <4EF1DC0A.1070004@deployingradius.com> X-Originating-IP: [10.70.39.113] To: Alan DeKok , 'radext mailing list' Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [radext] Status of extensions document? Thread-index: AQHMv+LGizesQYvWFUusQXiD6agRkJXpICig X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EF1DC0A.1070004@deployingradius.com> Subject: Re: [radext] Status of extensions document? 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 Dec 2011 09:40:50 -0000 Has the WG concluded on the concern against 'IANA is requested to move the "Unassigned" values in the range 144-191 from "Unassigned" to "Deprecated'. in section 9.1 of draft-ietf-radext-radius-extensions-03? Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Alan DeKok Sent: Wednesday, December 21, 2011 9:16 PM To: 'radext mailing list' Subject: [radext] Status of extensions document? I haven't seen any comments on the latest draft. There were some typos from Leaf, and IANA comments from Bernard. Have they been addressed to the WGs satisfaction? Having the document move forward would be a wonderful xmas present. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Fri Dec 23 01:40:52 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7CB21F8B32; Fri, 23 Dec 2011 01:40:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1324633252; bh=2a9sN9O0GzqRnxXL9wvrIjh4D5CgLY6Y7drll+Gq1EU=; h=Date:From:In-reply-to:To:Message-id:MIME-version:References: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=N5pRdt6eGE5pSTyJHP4N0X1Y+HbkYg+csHdWdV5eDOCeRns3GMNG5HheQTyoCGZSr vnmdj/eqzBxYdP++rPKZKiWx35S/vJgybhPpMU6M4xHtbR4K42GpaVVANS8sGsKP23 v0cyNWCevivldYYW1cyhBUQe0rHvVC/N+xWaVOVs= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8092B21F8B32 for ; Fri, 23 Dec 2011 01:40:50 -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 GyhazVKZXBV1 for ; Fri, 23 Dec 2011 01:40:50 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id E9EC621F8B16 for ; Fri, 23 Dec 2011 01:40:49 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWN00DQRHJUDK@szxga05-in.huawei.com> for radext@ietf.org; Fri, 23 Dec 2011 17:40:42 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWN00GFLHJU4B@szxga05-in.huawei.com> for radext@ietf.org; Fri, 23 Dec 2011 17:40:42 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFZ59996; Fri, 23 Dec 2011 17:40:39 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Dec 2011 17:40:32 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.223]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Fri, 23 Dec 2011 17:40:34 +0800 Date: Fri, 23 Dec 2011 09:39:40 +0000 From: Leaf yeh In-reply-to: <4EF1DC0A.1070004@deployingradius.com> X-Originating-IP: [10.70.39.113] To: Alan DeKok , 'radext mailing list' Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [radext] Status of extensions document? Thread-index: AQHMv+LGizesQYvWFUusQXiD6agRkJXpICig X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EF1DC0A.1070004@deployingradius.com> Subject: Re: [radext] Status of extensions document? 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 Has the WG concluded on the concern against 'IANA is requested to move the "Unassigned" values in the range 144-191 from "Unassigned" to "Deprecated'. in section 9.1 of draft-ietf-radext-radius-extensions-03? Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Alan DeKok Sent: Wednesday, December 21, 2011 9:16 PM To: 'radext mailing list' Subject: [radext] Status of extensions document? I haven't seen any comments on the latest draft. There were some typos from Leaf, and IANA comments from Bernard. Have they been addressed to the WGs satisfaction? Having the document move forward would be a wonderful xmas present. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From leaf.y.yeh@huawei.com Fri Dec 23 20:07:57 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D416311E8081 for ; Fri, 23 Dec 2011 20:07:57 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wP0wz6aDyi98 for ; Fri, 23 Dec 2011 20:07:54 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4B43611E807F for ; Fri, 23 Dec 2011 20:07:54 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWO00EJGWSTPY@szxga04-in.huawei.com> for radext@ietf.org; Sat, 24 Dec 2011 12:07:41 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWO000WXWSTH8@szxga04-in.huawei.com> for radext@ietf.org; Sat, 24 Dec 2011 12:07:41 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFZ77420; Sat, 24 Dec 2011 12:07:40 +0800 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 24 Dec 2011 12:07:30 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.223]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Sat, 24 Dec 2011 12:07:36 +0800 Date: Sat, 24 Dec 2011 04:06:38 +0000 From: Leaf yeh X-Originating-IP: [10.70.39.113] To: Alan DeKok , 'radext mailing list' Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_albwARPSculKKXo/wbFl1A)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [radext] Status of extensions document? Thread-index: AQHMv+LGizesQYvWFUusQXiD6agRkJXpICiggAEz1ZA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EF1DC0A.1070004@deployingradius.com> Subject: Re: [radext] Status of extensions document? 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, 24 Dec 2011 04:07:57 -0000 --Boundary_(ID_albwARPSculKKXo/wbFl1A) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT FYI - In fact, the type code of the Radius attribute, 144, seems to have been assigned. (http://www.iana.org/assignments/radius-types/radius-types.xml) -----Original Message----- From: Leaf yeh Sent: Friday, December 23, 2011 5:41 PM To: 'Alan DeKok'; 'radext mailing list' Subject: RE: [radext] Status of extensions document? Has the WG concluded on the concern against 'IANA is requested to move the "Unassigned" values in the range 144-191 from "Unassigned" to "Deprecated'. in section 9.1 of draft-ietf-radext-radius-extensions-03? Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Alan DeKok Sent: Wednesday, December 21, 2011 9:16 PM To: 'radext mailing list' Subject: [radext] Status of extensions document? I haven't seen any comments on the latest draft. There were some typos from Leaf, and IANA comments from Bernard. Have they been addressed to the WGs satisfaction? Having the document move forward would be a wonderful xmas present. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --Boundary_(ID_albwARPSculKKXo/wbFl1A) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0 IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0x OjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L 5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCgl0 ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5U ZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi57qv5paH5pys IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkNo YXINCgl7bXNvLXN0eWxlLW5hbWU6Iue6r+aWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms657qv5paH5pysOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7fQ0KLyogUGFnZSBEZWZpbml0aW9ucyAqLw0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9InRleHQt anVzdGlmeS10cmltOnB1bmN0dWF0aW9uIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+RllJIC0gSW4gZmFjdCwg dGhlIHR5cGUgY29kZSBvZiB0aGUgUmFkaXVzIGF0dHJpYnV0ZSwgMTQ0LCBzZWVtcyB0byBoYXZl IGJlZW4gYXNzaWduZWQuICg8YSBocmVmPSJodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRz L3JhZGl1cy10eXBlcy9yYWRpdXMtdHlwZXMueG1sIj5odHRwOi8vd3d3LmlhbmEub3JnL2Fzc2ln bm1lbnRzL3JhZGl1cy10eXBlcy9yYWRpdXMtdHlwZXMueG1sPC9hPik8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBMZWFmIHllaCA8YnI+DQpTZW50OiBGcmlkYXksIERlY2Vt YmVyIDIzLCAyMDExIDU6NDEgUE08YnI+DQpUbzogJ0FsYW4gRGVLb2snOyAncmFkZXh0IG1haWxp bmcgbGlzdCc8YnI+DQpTdWJqZWN0OiBSRTogW3JhZGV4dF0gU3RhdHVzIG9mIGV4dGVuc2lvbnMg ZG9jdW1lbnQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5IYXMgdGhlIFdHIGNvbmNsdWRlZCBv biB0aGUgY29uY2VybiBhZ2FpbnN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4nSUFOQSBpcyBy ZXF1ZXN0ZWQgdG8gbW92ZSB0aGUgJnF1b3Q7VW5hc3NpZ25lZCZxdW90OyB2YWx1ZXMgaW4gdGhl IHJhbmdlDQo8c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4xNDQ8L3NwYW4+LTE5MSBmcm9tICZxdW90 O1VuYXNzaWduZWQmcXVvdDsgdG8gJnF1b3Q7RGVwcmVjYXRlZCcuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj5pbiBzZWN0aW9uIDkuMSBvZiBkcmFmdC1pZXRmLXJhZGV4dC1yYWRpdXMtZXh0ZW5z aW9ucy0wMz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5CZXN0IFJl Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPkxlYWY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOiByYWRleHQtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJhZGV4dC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQWxhbiBEZUtvazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5TZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDIxLCAyMDEx IDk6MTYgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+VG86ICdyYWRleHQgbWFpbGluZyBsaXN0JzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5TdWJq ZWN0OiBbcmFkZXh0XSBTdGF0dXMgb2YgZXh0ZW5zaW9ucyBkb2N1bWVudD88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOyBJIGhhdmVuJ3Qgc2VlbiBhbnkgY29tbWVudHMgb24gdGhlIGxh dGVzdCBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyBUaGVyZSB3ZXJlIHNv bWUgdHlwb3MgZnJvbSBMZWFmLCBhbmQgSUFOQSBjb21tZW50cyBmcm9tIEJlcm5hcmQuJm5ic3A7 IEhhdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+dGhleSBiZWVuIGFkZHJlc3NlZCB0byB0aGUgV0dzIHNhdGlzZmFjdGlv bj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyBIYXZpbmcgdGhlIGRvY3VtZW50IG1v dmUgZm9yd2FyZCB3b3VsZCBiZSBhIHdvbmRlcmZ1bCB4bWFzIHByZXNlbnQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsgQWxhbiBEZUtvay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PnJhZGV4dCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+cmFkZXh0QGlldGYub3JnPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --Boundary_(ID_albwARPSculKKXo/wbFl1A)-- From radext-bounces@ietf.org Fri Dec 23 20:07:58 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B005911E8081; Fri, 23 Dec 2011 20:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1324699678; bh=NmZzr9oDDysLWNwxvtvCF4lgWDj44WEdkzPsuur5n2I=; h=Date:From:To:Message-id:MIME-version:References:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=bp6Teuw3EnsTSIpFLi8tnCyWeq+H83D6L9N7SpK6l2hHrbxAOYzVibTcx0mf+HZaq K+U8XPZ0+ThqeeIZHZpFoKTbu4U5OuWjJlxL94YzbsXsm2blmLgpjQu/ACvx8FX21f TH/U9bEA3ffstzr42v4rDbE5P6AgUVjITSgSJWMk= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D416311E8081 for ; Fri, 23 Dec 2011 20:07:57 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wP0wz6aDyi98 for ; Fri, 23 Dec 2011 20:07:54 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4B43611E807F for ; Fri, 23 Dec 2011 20:07:54 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWO00EJGWSTPY@szxga04-in.huawei.com> for radext@ietf.org; Sat, 24 Dec 2011 12:07:41 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWO000WXWSTH8@szxga04-in.huawei.com> for radext@ietf.org; Sat, 24 Dec 2011 12:07:41 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFZ77420; Sat, 24 Dec 2011 12:07:40 +0800 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 24 Dec 2011 12:07:30 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.223]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Sat, 24 Dec 2011 12:07:36 +0800 Date: Sat, 24 Dec 2011 04:06:38 +0000 From: Leaf yeh X-Originating-IP: [10.70.39.113] To: Alan DeKok , 'radext mailing list' Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [radext] Status of extensions document? Thread-index: AQHMv+LGizesQYvWFUusQXiD6agRkJXpICiggAEz1ZA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EF1DC0A.1070004@deployingradius.com> Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7726250028966176988==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============7726250028966176988== Content-type: multipart/alternative; boundary="Boundary_(ID_albwARPSculKKXo/wbFl1A)" Content-language: zh-CN --Boundary_(ID_albwARPSculKKXo/wbFl1A) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT FYI - In fact, the type code of the Radius attribute, 144, seems to have been assigned. (http://www.iana.org/assignments/radius-types/radius-types.xml) -----Original Message----- From: Leaf yeh Sent: Friday, December 23, 2011 5:41 PM To: 'Alan DeKok'; 'radext mailing list' Subject: RE: [radext] Status of extensions document? Has the WG concluded on the concern against 'IANA is requested to move the "Unassigned" values in the range 144-191 from "Unassigned" to "Deprecated'. in section 9.1 of draft-ietf-radext-radius-extensions-03? Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Alan DeKok Sent: Wednesday, December 21, 2011 9:16 PM To: 'radext mailing list' Subject: [radext] Status of extensions document? I haven't seen any comments on the latest draft. There were some typos from Leaf, and IANA comments from Bernard. Have they been addressed to the WGs satisfaction? Having the document move forward would be a wonderful xmas present. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --Boundary_(ID_albwARPSculKKXo/wbFl1A) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0 IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0x OjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L 5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCgl0 ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5U ZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi57qv5paH5pys IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkNo YXINCgl7bXNvLXN0eWxlLW5hbWU6Iue6r+aWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms657qv5paH5pysOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7fQ0KLyogUGFnZSBEZWZpbml0aW9ucyAqLw0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9InRleHQt anVzdGlmeS10cmltOnB1bmN0dWF0aW9uIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+RllJIC0gSW4gZmFjdCwg dGhlIHR5cGUgY29kZSBvZiB0aGUgUmFkaXVzIGF0dHJpYnV0ZSwgMTQ0LCBzZWVtcyB0byBoYXZl IGJlZW4gYXNzaWduZWQuICg8YSBocmVmPSJodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRz L3JhZGl1cy10eXBlcy9yYWRpdXMtdHlwZXMueG1sIj5odHRwOi8vd3d3LmlhbmEub3JnL2Fzc2ln bm1lbnRzL3JhZGl1cy10eXBlcy9yYWRpdXMtdHlwZXMueG1sPC9hPik8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBMZWFmIHllaCA8YnI+DQpTZW50OiBGcmlkYXksIERlY2Vt YmVyIDIzLCAyMDExIDU6NDEgUE08YnI+DQpUbzogJ0FsYW4gRGVLb2snOyAncmFkZXh0IG1haWxp bmcgbGlzdCc8YnI+DQpTdWJqZWN0OiBSRTogW3JhZGV4dF0gU3RhdHVzIG9mIGV4dGVuc2lvbnMg ZG9jdW1lbnQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5IYXMgdGhlIFdHIGNvbmNsdWRlZCBv biB0aGUgY29uY2VybiBhZ2FpbnN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4nSUFOQSBpcyBy ZXF1ZXN0ZWQgdG8gbW92ZSB0aGUgJnF1b3Q7VW5hc3NpZ25lZCZxdW90OyB2YWx1ZXMgaW4gdGhl IHJhbmdlDQo8c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4xNDQ8L3NwYW4+LTE5MSBmcm9tICZxdW90 O1VuYXNzaWduZWQmcXVvdDsgdG8gJnF1b3Q7RGVwcmVjYXRlZCcuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj5pbiBzZWN0aW9uIDkuMSBvZiBkcmFmdC1pZXRmLXJhZGV4dC1yYWRpdXMtZXh0ZW5z aW9ucy0wMz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5CZXN0IFJl Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPkxlYWY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOiByYWRleHQtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJhZGV4dC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQWxhbiBEZUtvazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5TZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDIxLCAyMDEx IDk6MTYgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+VG86ICdyYWRleHQgbWFpbGluZyBsaXN0JzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5TdWJq ZWN0OiBbcmFkZXh0XSBTdGF0dXMgb2YgZXh0ZW5zaW9ucyBkb2N1bWVudD88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOyBJIGhhdmVuJ3Qgc2VlbiBhbnkgY29tbWVudHMgb24gdGhlIGxh dGVzdCBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyBUaGVyZSB3ZXJlIHNv bWUgdHlwb3MgZnJvbSBMZWFmLCBhbmQgSUFOQSBjb21tZW50cyBmcm9tIEJlcm5hcmQuJm5ic3A7 IEhhdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+dGhleSBiZWVuIGFkZHJlc3NlZCB0byB0aGUgV0dzIHNhdGlzZmFjdGlv bj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyBIYXZpbmcgdGhlIGRvY3VtZW50IG1v dmUgZm9yd2FyZCB3b3VsZCBiZSBhIHdvbmRlcmZ1bCB4bWFzIHByZXNlbnQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsgQWxhbiBEZUtvay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PnJhZGV4dCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+cmFkZXh0QGlldGYub3JnPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --Boundary_(ID_albwARPSculKKXo/wbFl1A)-- --===============7726250028966176988== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============7726250028966176988==-- From aland@deployingradius.com Sat Dec 24 06:05:31 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCAD21F84A1 for ; Sat, 24 Dec 2011 06:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3gAwDx-0OX2 for ; Sat, 24 Dec 2011 06:05:31 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 2C65F21F84A0 for ; Sat, 24 Dec 2011 06:05:31 -0800 (PST) Received: from thor.lan (76-10-182-150.dsl.teksavvy.com [76.10.182.150]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 09BC61234008; Sat, 24 Dec 2011 15:05:07 +0100 (CET) Message-ID: <4EF5DC11.5050606@deployingradius.com> Date: Sat, 24 Dec 2011 09:05:05 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <4EF1DC0A.1070004@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'radext mailing list' Subject: Re: [radext] Status of extensions document? 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, 24 Dec 2011 14:05:31 -0000 Leaf yeh wrote: > FYI - In fact, the type code of the Radius attribute, 144, seems to have > been assigned. > (http://www.iana.org/assignments/radius-types/radius-types.xml) Which is why the text says to move the *UNASSIGNED* values. Since 144 is not *UNASSIGNED*, there is no problem. Alan DeKok. From radext-bounces@ietf.org Sat Dec 24 06:05:33 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA9D21F84A1; Sat, 24 Dec 2011 06:05:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1324735533; bh=iV0djsghRGZpLxtkaYrGcrqfcNtzsdYJFhOQ7lDY6jE=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=W/C3uV3qGTF/i4BsQhITPaiWERKiZEeztjiAJwMsCg5ZNVyLlPSgPMJA4Hptm4tkG WaqiGVFBbQde1OQcBkadGdYKg8UbsBxKSv6P3y6k7junvv9faWn7B9zt1LRCrW4bQl pWMJvOSag64BkeD+thsl87qVo7aJzJq+3gA8sLPA= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCAD21F84A1 for ; Sat, 24 Dec 2011 06:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3gAwDx-0OX2 for ; Sat, 24 Dec 2011 06:05:31 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 2C65F21F84A0 for ; Sat, 24 Dec 2011 06:05:31 -0800 (PST) Received: from thor.lan (76-10-182-150.dsl.teksavvy.com [76.10.182.150]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 09BC61234008; Sat, 24 Dec 2011 15:05:07 +0100 (CET) Message-ID: <4EF5DC11.5050606@deployingradius.com> Date: Sat, 24 Dec 2011 09:05:05 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <4EF1DC0A.1070004@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: 'radext mailing list' Subject: Re: [radext] Status of extensions document? 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: > FYI - In fact, the type code of the Radius attribute, 144, seems to have > been assigned. > (http://www.iana.org/assignments/radius-types/radius-types.xml) Which is why the text says to move the *UNASSIGNED* values. Since 144 is not *UNASSIGNED*, there is no problem. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Sat Dec 24 07:58:29 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56ADA21F844B for ; Sat, 24 Dec 2011 07:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqfEMJ6YLS2w for ; Sat, 24 Dec 2011 07:58:28 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id C9EC121F8446 for ; Sat, 24 Dec 2011 07:58:28 -0800 (PST) Received: from thor.lan (76-10-182-150.dsl.teksavvy.com [76.10.182.150]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 8B1D01234008; Sat, 24 Dec 2011 16:58:00 +0100 (CET) Message-ID: <4EF5F686.6080202@deployingradius.com> Date: Sat, 24 Dec 2011 10:57:58 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Dave Nelson References: <4EF1DC0A.1070004@deployingradius.com> <4EF5DC11.5050606@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext mailing list , Leaf yeh Subject: Re: [radext] Status of extensions document? 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, 24 Dec 2011 15:58:29 -0000 Dave Nelson wrote: > What's the purpose of this? To preclude any additional "classic" RADIUS > attributes from being defined? Not to preclude, but to deprecate them. The goal is to use the new attributes where possible. > I thought the consensus was to prvide > guidance on when to use "classic" attributes and when to use "extended" > attributes. The document does that. > Theare a any number of applications asn uses cases that I > can Imagine whnere a sinple "classic" RADIUS attribute works just fine, > so long as the number space lasts. Why force the issue? If we don't suggest that documents use the new format, they won't. Deprecating the old space gives incentive to use the new space. Again, the document doesn't *prevent* use of the old space. It just suggests that there are few reasons for using it. Alan DeKok. From radext-bounces@ietf.org Sat Dec 24 07:58:30 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32E221F844B; Sat, 24 Dec 2011 07:58:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1324742310; bh=ELCKxQV6ykVoCaT/i7ppgl4zwaLn47mlvyxujPuinVQ=; 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=KtXwuxQ5EzjKfDRscpK5GBsKQR1DyoSK5eyuHN7EdD/PPM2gxlaAxE5IPubkfP832 5kEYvQppYOZLkXtlBVBVui9H5/T2E0BAS2VYb+iY7Set6fMgr2MI9IrUlONPiCNtSf kVY64Db5F5g3kfCikFTOpyu+ouY02as7vAN61lDI= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56ADA21F844B for ; Sat, 24 Dec 2011 07:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqfEMJ6YLS2w for ; Sat, 24 Dec 2011 07:58:28 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id C9EC121F8446 for ; Sat, 24 Dec 2011 07:58:28 -0800 (PST) Received: from thor.lan (76-10-182-150.dsl.teksavvy.com [76.10.182.150]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 8B1D01234008; Sat, 24 Dec 2011 16:58:00 +0100 (CET) Message-ID: <4EF5F686.6080202@deployingradius.com> Date: Sat, 24 Dec 2011 10:57:58 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Dave Nelson References: <4EF1DC0A.1070004@deployingradius.com> <4EF5DC11.5050606@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: radext mailing list , Leaf yeh Subject: Re: [radext] Status of extensions document? 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 Dave Nelson wrote: > What's the purpose of this? To preclude any additional "classic" RADIUS > attributes from being defined? Not to preclude, but to deprecate them. The goal is to use the new attributes where possible. > I thought the consensus was to prvide > guidance on when to use "classic" attributes and when to use "extended" > attributes. The document does that. > Theare a any number of applications asn uses cases that I > can Imagine whnere a sinple "classic" RADIUS attribute works just fine, > so long as the number space lasts. Why force the issue? If we don't suggest that documents use the new format, they won't. Deprecating the old space gives incentive to use the new space. Again, the document doesn't *prevent* use of the old space. It just suggests that there are few reasons for using it. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From bernard_aboba@hotmail.com Sun Dec 25 08:31:19 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8E221F8477 for ; Sun, 25 Dec 2011 08:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.694 X-Spam-Level: X-Spam-Status: No, score=-100.694 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 G5VN1jg3EeuI for ; Sun, 25 Dec 2011 08:31:19 -0800 (PST) Received: from snt0-omc3-s27.snt0.hotmail.com (snt0-omc3-s27.snt0.hotmail.com [65.55.90.166]) by ietfa.amsl.com (Postfix) with ESMTP id 1027921F8472 for ; Sun, 25 Dec 2011 08:31:19 -0800 (PST) Received: from SNT0-EAS383 ([65.55.90.136]) by snt0-omc3-s27.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Dec 2011 08:31:18 -0800 X-Originating-IP: [24.17.217.162] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: <4EF1DC0A.1070004@deployingradius.com> <4EF5DC11.5050606@deployingradius.com> <4EF5F686.6080202@deployingradius.com> Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Content-Type: text/plain; charset="us-ascii" In-Reply-To: <4EF5F686.6080202@deployingradius.com> Date: Sun, 25 Dec 2011 08:31:56 -0800 To: Alan DeKok MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 25 Dec 2011 16:31:18.0659 (UTC) FILETIME=[A1225D30:01CCC322] Cc: radext mailing list , Dave Nelson , Leaf yeh Subject: Re: [radext] Status of extensions document? 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 Dec 2011 16:31:19 -0000 On Dec 24, 2011, at 7:58, "Alan DeKok" wrote: > Dave Nelson wrote: >> What's the purpose of this? To preclude any additional "classic" RADIUS >> attributes from being defined? >=20 > Not to preclude, but to deprecate them. The goal is to use the new > attributes where possible. Deprecation of a registry is not defined in RFC 5226, so it's not clear how I= ANA can carry that out in practice. >=20 >> I thought the consensus was to prvide >> guidance on when to use "classic" attributes and when to use "extended" >> attributes. >=20 > The document does that. >=20 >> Theare a any number of applications asn uses cases that I >> can Imagine whnere a sinple "classic" RADIUS attribute works just fine, >> so long as the number space lasts. Why force the issue? >=20 > If we don't suggest that documents use the new format, they won't. > Deprecating the old space gives incentive to use the new space. >=20 > Again, the document doesn't *prevent* use of the old space. It just > suggests that there are few reasons for using it. Since this draft doesn't update RFC 3575, it can be argued that no changes a= re made to legacy allocations. However, the request for deprecation will cr= eate confusion.=20 >=20 > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Sun Dec 25 08:31:21 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC4721F8477; Sun, 25 Dec 2011 08:31:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1324830681; bh=iA/D6S7UvLQXtv7+KuHrSb2s1ZbeSLebkZyn3n2kNDM=; h=Message-ID:References:From:In-Reply-To:Date:To:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=xLVKP4fVRJyqvEHQUwxm1zKTZCNc8eUBCrSf1bDIcUF7fCLdQpc4petjIrPWvA7Qa xIGtHqp/B/71beD1oS8sYhqsj+6BwHUhusS9pvJhhuEIoOpTeawLXbPhyzH0WtLY18 HoCQO8/nFZFSy06A7DXv5xwqYmBlzjZmdniJu5MU= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8E221F8477 for ; Sun, 25 Dec 2011 08:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.694 X-Spam-Level: X-Spam-Status: No, score=-100.694 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 G5VN1jg3EeuI for ; Sun, 25 Dec 2011 08:31:19 -0800 (PST) Received: from snt0-omc3-s27.snt0.hotmail.com (snt0-omc3-s27.snt0.hotmail.com [65.55.90.166]) by ietfa.amsl.com (Postfix) with ESMTP id 1027921F8472 for ; Sun, 25 Dec 2011 08:31:19 -0800 (PST) Received: from SNT0-EAS383 ([65.55.90.136]) by snt0-omc3-s27.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Dec 2011 08:31:18 -0800 X-Originating-IP: [24.17.217.162] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: <4EF1DC0A.1070004@deployingradius.com> <4EF5DC11.5050606@deployingradius.com> <4EF5F686.6080202@deployingradius.com> From: Bernard Aboba In-Reply-To: <4EF5F686.6080202@deployingradius.com> Date: Sun, 25 Dec 2011 08:31:56 -0800 To: Alan DeKok MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 25 Dec 2011 16:31:18.0659 (UTC) FILETIME=[A1225D30:01CCC322] Cc: radext mailing list , Dave Nelson , Leaf yeh Subject: Re: [radext] Status of extensions document? 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 Dec 24, 2011, at 7:58, "Alan DeKok" wrote: > Dave Nelson wrote: >> What's the purpose of this? To preclude any additional "classic" RADIUS >> attributes from being defined? > > Not to preclude, but to deprecate them. The goal is to use the new > attributes where possible. Deprecation of a registry is not defined in RFC 5226, so it's not clear how IANA can carry that out in practice. > >> I thought the consensus was to prvide >> guidance on when to use "classic" attributes and when to use "extended" >> attributes. > > The document does that. > >> Theare a any number of applications asn uses cases that I >> can Imagine whnere a sinple "classic" RADIUS attribute works just fine, >> so long as the number space lasts. Why force the issue? > > If we don't suggest that documents use the new format, they won't. > Deprecating the old space gives incentive to use the new space. > > Again, the document doesn't *prevent* use of the old space. It just > suggests that there are few reasons for using it. Since this draft doesn't update RFC 3575, it can be argued that no changes are made to legacy allocations. However, the request for deprecation will create confusion. > > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Mon Dec 26 06:27:15 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271D321F8BA2; Mon, 26 Dec 2011 06:27:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1324909635; bh=/16+hhuRRq0canwYg7gQOlCGFWLZNlnjUW5V0as5QAE=; 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=JIGAyMHyZViUchXL+0bhd90VErby92Ua50VD6qZlf554ZBbCDdX5ciEd6MtuOcTHv U6VdpaLx2VmI/Kiokr911LJuvl6d+VSAwBrYbs3mpGieOvacJs8bxHfaWdy6cHDs28 tBCz4+6xoirrAZS3XyErhzzkTOndG68f6nWwKWDs= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08EE21F8BA2 for ; Mon, 26 Dec 2011 06:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=0.745, 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 WfTMtojUAwrE for ; Mon, 26 Dec 2011 06:27:14 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 45B5321F8B9E for ; Mon, 26 Dec 2011 06:27:14 -0800 (PST) Message-ID: <4EF88423.7050305@deployingradius.com> Date: Mon, 26 Dec 2011 09:26:43 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <4EF1DC0A.1070004@deployingradius.com> <4EF5DC11.5050606@deployingradius.com> <4EF5F686.6080202@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: radext mailing list , Dave Nelson , Leaf yeh Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Bernard Aboba wrote: > Deprecation of a registry is not defined in RFC 5226, so it's not clear how IANA can carry that out in practice. Then the entries should be marked "reserved". > Since this draft doesn't update RFC 3575, it can be argued that no changes are made to legacy allocations. However, the request for deprecation will create confusion. The latest version of the draft (1 month ago) does update 3575. It also updates the IANA section to address your other concerns. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Mon Dec 26 06:27:14 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08EE21F8BA2 for ; Mon, 26 Dec 2011 06:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=0.745, 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 WfTMtojUAwrE for ; Mon, 26 Dec 2011 06:27:14 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 45B5321F8B9E for ; Mon, 26 Dec 2011 06:27:14 -0800 (PST) Message-ID: <4EF88423.7050305@deployingradius.com> Date: Mon, 26 Dec 2011 09:26:43 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <4EF1DC0A.1070004@deployingradius.com> <4EF5DC11.5050606@deployingradius.com> <4EF5F686.6080202@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext mailing list , Dave Nelson , Leaf yeh Subject: Re: [radext] Status of extensions document? 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, 26 Dec 2011 14:27:14 -0000 Bernard Aboba wrote: > Deprecation of a registry is not defined in RFC 5226, so it's not clear how IANA can carry that out in practice. Then the entries should be marked "reserved". > Since this draft doesn't update RFC 3575, it can be argued that no changes are made to legacy allocations. However, the request for deprecation will create confusion. The latest version of the draft (1 month ago) does update 3575. It also updates the IANA section to address your other concerns. Alan DeKok. From bernard_aboba@hotmail.com Mon Dec 26 10:21:41 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A74D21F8C32 for ; Mon, 26 Dec 2011 10:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.716 X-Spam-Level: X-Spam-Status: No, score=-100.716 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_20=-0.74, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9WtPsPTXzlB for ; Mon, 26 Dec 2011 10:21:41 -0800 (PST) Received: from blu0-omc2-s29.blu0.hotmail.com (blu0-omc2-s29.blu0.hotmail.com [65.55.111.104]) by ietfa.amsl.com (Postfix) with ESMTP id DBB9D21F8C2D for ; Mon, 26 Dec 2011 10:21:40 -0800 (PST) Received: from BLU152-W42 ([65.55.111.73]) by blu0-omc2-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Dec 2011 10:21:37 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_50cd0f75-94ea-4f8b-ada6-a7fc947fce05_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Alan DeKok Date: Mon, 26 Dec 2011 10:21:36 -0800 Importance: Normal In-Reply-To: <4EF88423.7050305@deployingradius.com> References: <4EF1DC0A.1070004@deployingradius.com>, , <4EF5DC11.5050606@deployingradius.com>, , <4EF5F686.6080202@deployingradius.com>, , <4EF88423.7050305@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 26 Dec 2011 18:21:37.0197 (UTC) FILETIME=[3480DDD0:01CCC3FB] Cc: radext@ietf.org, dnelson@elbrys.com, leaf.y.yeh@huawei.com Subject: Re: [radext] Status of extensions document? 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, 26 Dec 2011 18:21:41 -0000 --_50cd0f75-94ea-4f8b-ada6-a7fc947fce05_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Updating RFC 3575 and marking non-allocated entries as "reserved" would be = well understood by IANA. This would cause them to refuse to allocate any a= ttributes from the "reserved" space=2C effectively closing the RADIUS "stan= dards" space to further use=2C effective immediately.=20 > > Deprecation of a registry is not defined in RFC 5226=2C so it's not cle= ar how IANA can carry that out in practice. >=20 > Then the entries should be marked "reserved". >=20 > > Since this draft doesn't update RFC 3575=2C it can be argued that no ch= anges are made to legacy allocations. However=2C the request for deprecati= on will create confusion.=20 >=20 > The latest version of the draft (1 month ago) does update 3575. It > also updates the IANA section to address your other concerns. = --_50cd0f75-94ea-4f8b-ada6-a7fc947fce05_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Updating RFC 3575 and marking non-allocated entries as "reserved" would be = well understood by IANA. =3B This would cause them to refuse to allocat= e any attributes from the "reserved" space=2C effectively closing the RADIU= S "standards" space to further use=2C effective immediately.

<= div id=3D"SkyDrivePlaceholder">
>=3B >=3B Deprecation of a registr= y is not defined in RFC 5226=2C so it's not clear how IANA can carry that o= ut in practice.
>=3B
>=3B Then the entries should be marked "r= eserved".
>=3B
>=3B >=3B Since this draft doesn't update RFC 3= 575=2C it can be argued that no changes are made to legacy allocations. Ho= wever=2C the request for deprecation will create confusion.
>=3B
= >=3B The latest version of the draft (1 month ago) does update 3575. I= t
>=3B also updates the IANA section to address your other concerns.
= --_50cd0f75-94ea-4f8b-ada6-a7fc947fce05_-- From radext-bounces@ietf.org Mon Dec 26 10:21:43 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1661221F8C32; Mon, 26 Dec 2011 10:21:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1324923703; bh=TyOt3nyQhNi0123EpbsGTDFtxfqHuKIgeAbQYo0JbQQ=; h=Message-ID:From:To:Date:In-Reply-To:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=V+E1VPOQbJewkDx0CZgzL9VRcESdsYNbOV4uc1vgUXeB4Mup4LcWs9h4vyP5Eesyi HHVcCIFnDi671rdPWw4sd3laMGNxHGYM4RxmcpgYUalI0JQtDWU+CaMgsWyuXUXccT gqjb3wZ5Rlw/FPteSYVPMqlWpYSjd8K21LBaBHoA= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A74D21F8C32 for ; Mon, 26 Dec 2011 10:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.716 X-Spam-Level: X-Spam-Status: No, score=-100.716 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_20=-0.74, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9WtPsPTXzlB for ; Mon, 26 Dec 2011 10:21:41 -0800 (PST) Received: from blu0-omc2-s29.blu0.hotmail.com (blu0-omc2-s29.blu0.hotmail.com [65.55.111.104]) by ietfa.amsl.com (Postfix) with ESMTP id DBB9D21F8C2D for ; Mon, 26 Dec 2011 10:21:40 -0800 (PST) Received: from BLU152-W42 ([65.55.111.73]) by blu0-omc2-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Dec 2011 10:21:37 -0800 Message-ID: X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Alan DeKok Date: Mon, 26 Dec 2011 10:21:36 -0800 Importance: Normal In-Reply-To: <4EF88423.7050305@deployingradius.com> References: <4EF1DC0A.1070004@deployingradius.com>, , <4EF5DC11.5050606@deployingradius.com>, , <4EF5F686.6080202@deployingradius.com>, , <4EF88423.7050305@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 26 Dec 2011 18:21:37.0197 (UTC) FILETIME=[3480DDD0:01CCC3FB] Cc: radext@ietf.org, dnelson@elbrys.com, leaf.y.yeh@huawei.com Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3800892431139029055==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============3800892431139029055== Content-Type: multipart/alternative; boundary="_50cd0f75-94ea-4f8b-ada6-a7fc947fce05_" --_50cd0f75-94ea-4f8b-ada6-a7fc947fce05_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Updating RFC 3575 and marking non-allocated entries as "reserved" would be = well understood by IANA. This would cause them to refuse to allocate any a= ttributes from the "reserved" space=2C effectively closing the RADIUS "stan= dards" space to further use=2C effective immediately.=20 > > Deprecation of a registry is not defined in RFC 5226=2C so it's not cle= ar how IANA can carry that out in practice. >=20 > Then the entries should be marked "reserved". >=20 > > Since this draft doesn't update RFC 3575=2C it can be argued that no ch= anges are made to legacy allocations. However=2C the request for deprecati= on will create confusion.=20 >=20 > The latest version of the draft (1 month ago) does update 3575. It > also updates the IANA section to address your other concerns. = --_50cd0f75-94ea-4f8b-ada6-a7fc947fce05_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Updating RFC 3575 and marking non-allocated entries as "reserved" would be = well understood by IANA. =3B This would cause them to refuse to allocat= e any attributes from the "reserved" space=2C effectively closing the RADIU= S "standards" space to further use=2C effective immediately.

<= div id=3D"SkyDrivePlaceholder">
>=3B >=3B Deprecation of a registr= y is not defined in RFC 5226=2C so it's not clear how IANA can carry that o= ut in practice.
>=3B
>=3B Then the entries should be marked "r= eserved".
>=3B
>=3B >=3B Since this draft doesn't update RFC 3= 575=2C it can be argued that no changes are made to legacy allocations. Ho= wever=2C the request for deprecation will create confusion.
>=3B
= >=3B The latest version of the draft (1 month ago) does update 3575. I= t
>=3B also updates the IANA section to address your other concerns.
= --_50cd0f75-94ea-4f8b-ada6-a7fc947fce05_-- --===============3800892431139029055== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============3800892431139029055==-- From aland@deployingradius.com Mon Dec 26 10:39:41 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB49A21F8C32 for ; Mon, 26 Dec 2011 10:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.227 X-Spam-Level: X-Spam-Status: No, score=-102.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 F4xst8bN87GF for ; Mon, 26 Dec 2011 10:39:41 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 6610621F8BB7 for ; Mon, 26 Dec 2011 10:39:41 -0800 (PST) Message-ID: <4EF8BF4D.6090401@deployingradius.com> Date: Mon, 26 Dec 2011 13:39:09 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <4EF1DC0A.1070004@deployingradius.com>, , <4EF5DC11.5050606@deployingradius.com>, , <4EF5F686.6080202@deployingradius.com>, , <4EF88423.7050305@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, dnelson@elbrys.com, leaf.y.yeh@huawei.com Subject: Re: [radext] Status of extensions document? 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, 26 Dec 2011 18:39:42 -0000 Bernard Aboba wrote: > Updating RFC 3575 and marking non-allocated entries as "reserved" would > be well understood by IANA. This would cause them to refuse to allocate > any attributes from the "reserved" space, effectively closing the RADIUS > "standards" space to further use, effective immediately. Honestly, I might be OK with that. As an alternative, how do we update the registry to (a) create the new extended space, and (b) suggest that people should *use* it? I'm open to suggestions. Much of the discussion on this list has been to shoot down new ideas. So I understand why people are hesitant to propose anything positive. There's currently a strong push to use the standard space for everything, even new standards which would be better served by using the extended format. The excuse is "the extended format isn't published", or "it isn't implemented" It's a circular argument (as has been pointed out repeatedly). Yet it's appealing, because it lets people ignore the problem for another few years. It lets people delay updating their implementations. After all, 400-500 lines of code for the extended format is just too complicated to add to an implementation. I propose that we simply discard the extensions document. Instead, we should just keep allocating from the standard space. Then, when all attributes have been allocated, we should panic. Or... maybe there's a more intelligent alternative. Alan DeKok. From radext-bounces@ietf.org Mon Dec 26 10:39:43 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B9D21F8C32; Mon, 26 Dec 2011 10:39:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1324924783; bh=ShEfBUSp2WP3NuTqm1MlvKEGhzf+Lflzp8QVzsse75g=; 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=h7FR+y1Km8g/TESuQ2mmBA+2kQyol2sTQXvCLqN3PGcbj7Ag3NhHqPBkTcLS8wAT3 z85ohaq0L1xM57vSV1vo7dYNSdKAho20OPjV3JWmyr/JeETHVZOTlHU9iGL13Mtfy/ vbPIg3DSgP4GU+BQOtslFKICoaqfwce8y1BCGbW4= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB49A21F8C32 for ; Mon, 26 Dec 2011 10:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.227 X-Spam-Level: X-Spam-Status: No, score=-102.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 F4xst8bN87GF for ; Mon, 26 Dec 2011 10:39:41 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 6610621F8BB7 for ; Mon, 26 Dec 2011 10:39:41 -0800 (PST) Message-ID: <4EF8BF4D.6090401@deployingradius.com> Date: Mon, 26 Dec 2011 13:39:09 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <4EF1DC0A.1070004@deployingradius.com>, , <4EF5DC11.5050606@deployingradius.com>, , <4EF5F686.6080202@deployingradius.com>, , <4EF88423.7050305@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: radext@ietf.org, dnelson@elbrys.com, leaf.y.yeh@huawei.com Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Bernard Aboba wrote: > Updating RFC 3575 and marking non-allocated entries as "reserved" would > be well understood by IANA. This would cause them to refuse to allocate > any attributes from the "reserved" space, effectively closing the RADIUS > "standards" space to further use, effective immediately. Honestly, I might be OK with that. As an alternative, how do we update the registry to (a) create the new extended space, and (b) suggest that people should *use* it? I'm open to suggestions. Much of the discussion on this list has been to shoot down new ideas. So I understand why people are hesitant to propose anything positive. There's currently a strong push to use the standard space for everything, even new standards which would be better served by using the extended format. The excuse is "the extended format isn't published", or "it isn't implemented" It's a circular argument (as has been pointed out repeatedly). Yet it's appealing, because it lets people ignore the problem for another few years. It lets people delay updating their implementations. After all, 400-500 lines of code for the extended format is just too complicated to add to an implementation. I propose that we simply discard the extensions document. Instead, we should just keep allocating from the standard space. Then, when all attributes have been allocated, we should panic. Or... maybe there's a more intelligent alternative. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From dnelson@elbrys.com Sat Dec 24 06:40:50 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEC221F84C3 for ; Sat, 24 Dec 2011 06:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGK4Uun1TASA for ; Sat, 24 Dec 2011 06:40:50 -0800 (PST) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with SMTP id D331E21F84BD for ; Sat, 24 Dec 2011 06:40:49 -0800 (PST) Received: from mail-vx0-f179.google.com ([209.85.220.179]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTvXkcFSEa3As18Y8DcG+jKm+onh7aO/e@postini.com; Sat, 24 Dec 2011 06:40:49 PST Received: by mail-vx0-f179.google.com with SMTP id f13so6993637vcb.38 for ; Sat, 24 Dec 2011 06:40:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.141.144 with SMTP id m16mr12283506vcu.54.1324737648256; Sat, 24 Dec 2011 06:40:48 -0800 (PST) Received: by 10.52.188.167 with HTTP; Sat, 24 Dec 2011 06:40:48 -0800 (PST) In-Reply-To: <4EF5DC11.5050606@deployingradius.com> References: <4EF1DC0A.1070004@deployingradius.com> <4EF5DC11.5050606@deployingradius.com> Date: Sat, 24 Dec 2011 09:40:48 -0500 Message-ID: From: Dave Nelson To: Alan DeKok Content-Type: multipart/alternative; boundary=f46d043be048f1e56d04b4d7843e X-Mailman-Approved-At: Tue, 27 Dec 2011 02:37:10 -0800 Cc: radext mailing list , Leaf yeh Subject: Re: [radext] Status of extensions document? 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, 24 Dec 2011 14:40:50 -0000 --f46d043be048f1e56d04b4d7843e Content-Type: text/plain; charset=ISO-8859-1 On Sat, Dec 24, 2011 at 9:05 AM, Alan DeKok wrote: > > Which is why the text says to move the *UNASSIGNED* values. > > What's the purpose of this? To preclude any additional "classic" RADIUS attributes from being defined? I thought the consensus was to prvide guidance on when to use "classic" attributes and when to use "extended" attributes. Theare a any number of applications asn uses cases that I can Imagine whnere a sinple "classic" RADIUS attribute works just fine, so long as the number space lasts. Why force the issue? Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 --f46d043be048f1e56d04b4d7843e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Dec 24, 2011 at 9:05 AM, Alan DeKok <aland@deployingradius.com> wrote:

=A0Which is why the text says to move the *UNASSIGNED* values.
=A0
What's the purpose of this?=A0 To preclude an= y additional "classic" RADIUS attributes from being defined?=A0 I= thought the consensus was to prvide guidance on when to use "classic&= quot; attributes and when to use "extended" attributes.=A0 Theare= a any number of applications asn uses cases that I can Imagine whnere a si= nple "classic" RADIUS attribute works just fine, so long as the n= umber space lasts.=A0 Why force the issue?

Regards,

Dave

David B. Nelson
Sr. Software ArchitectElbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636
--f46d043be048f1e56d04b4d7843e-- From radext-bounces@ietf.org Tue Dec 27 02:37:12 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCCD21F858D; Tue, 27 Dec 2011 02:37:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1324982232; bh=MDE3bbx4DMPWVYnAs4Isoak5qoNbY39hEVElmSHui+M=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=Skit22PIM5457WYmw/QkJBBwzMoCevnHW+aHDXk3sL9amK2O37mCDghW0BVXK2DXR 1OHMD8YrATlnICUtCHvRQoJwjA+hw2CwknOfvQTTknDBRGraFBP6vkejmnfNFN2L5j IEPFDNCjTpiVDsbJLxILQ+HBB547C+q1Lu+yEWVM= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEC221F84C3 for ; Sat, 24 Dec 2011 06:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGK4Uun1TASA for ; Sat, 24 Dec 2011 06:40:50 -0800 (PST) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with SMTP id D331E21F84BD for ; Sat, 24 Dec 2011 06:40:49 -0800 (PST) Received: from mail-vx0-f179.google.com ([209.85.220.179]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTvXkcFSEa3As18Y8DcG+jKm+onh7aO/e@postini.com; Sat, 24 Dec 2011 06:40:49 PST Received: by mail-vx0-f179.google.com with SMTP id f13so6993637vcb.38 for ; Sat, 24 Dec 2011 06:40:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.141.144 with SMTP id m16mr12283506vcu.54.1324737648256; Sat, 24 Dec 2011 06:40:48 -0800 (PST) Received: by 10.52.188.167 with HTTP; Sat, 24 Dec 2011 06:40:48 -0800 (PST) In-Reply-To: <4EF5DC11.5050606@deployingradius.com> References: <4EF1DC0A.1070004@deployingradius.com> <4EF5DC11.5050606@deployingradius.com> Date: Sat, 24 Dec 2011 09:40:48 -0500 Message-ID: From: Dave Nelson To: Alan DeKok X-Mailman-Approved-At: Tue, 27 Dec 2011 02:37:10 -0800 Cc: radext mailing list , Leaf yeh Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1127593978747590001==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============1127593978747590001== Content-Type: multipart/alternative; boundary=f46d043be048f1e56d04b4d7843e --f46d043be048f1e56d04b4d7843e Content-Type: text/plain; charset=ISO-8859-1 On Sat, Dec 24, 2011 at 9:05 AM, Alan DeKok wrote: > > Which is why the text says to move the *UNASSIGNED* values. > > What's the purpose of this? To preclude any additional "classic" RADIUS attributes from being defined? I thought the consensus was to prvide guidance on when to use "classic" attributes and when to use "extended" attributes. Theare a any number of applications asn uses cases that I can Imagine whnere a sinple "classic" RADIUS attribute works just fine, so long as the number space lasts. Why force the issue? Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 --f46d043be048f1e56d04b4d7843e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Dec 24, 2011 at 9:05 AM, Alan DeKok <aland@deployingradius.com> wrote:

=A0Which is why the text says to move the *UNASSIGNED* values.
=A0
What's the purpose of this?=A0 To preclude an= y additional "classic" RADIUS attributes from being defined?=A0 I= thought the consensus was to prvide guidance on when to use "classic&= quot; attributes and when to use "extended" attributes.=A0 Theare= a any number of applications asn uses cases that I can Imagine whnere a si= nple "classic" RADIUS attribute works just fine, so long as the n= umber space lasts.=A0 Why force the issue?

Regards,

Dave

David B. Nelson
Sr. Software ArchitectElbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636
--f46d043be048f1e56d04b4d7843e-- --===============1127593978747590001== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============1127593978747590001==-- From bernard_aboba@hotmail.com Wed Dec 28 23:37:22 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923A721F845E for ; Wed, 28 Dec 2011 23:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.998 X-Spam-Level: X-Spam-Status: No, score=-99.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5ZONNprooua for ; Wed, 28 Dec 2011 23:37:22 -0800 (PST) Received: from blu0-omc2-s14.blu0.hotmail.com (blu0-omc2-s14.blu0.hotmail.com [65.55.111.89]) by ietfa.amsl.com (Postfix) with ESMTP id C327B21F845F for ; Wed, 28 Dec 2011 23:37:21 -0800 (PST) Received: from BLU152-W46 ([65.55.111.71]) by blu0-omc2-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Dec 2011 23:37:21 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_a3583334-4237-484b-b005-cfaa5a63f798_" X-Originating-IP: [75.139.208.190] From: Bernard Aboba To: Alan DeKok Date: Wed, 28 Dec 2011 23:37:21 -0800 Importance: Normal In-Reply-To: <4EF8BF4D.6090401@deployingradius.com> References: <4EF1DC0A.1070004@deployingradius.com>, , <4EF5DC11.5050606@deployingradius.com>, , <4EF5F686.6080202@deployingradius.com>, , <4EF88423.7050305@deployingradius.com> , <4EF8BF4D.6090401@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 29 Dec 2011 07:37:21.0834 (UTC) FILETIME=[B359D0A0:01CCC5FC] Cc: radext@ietf.org, dnelson@elbrys.com, leaf.y.yeh@huawei.com Subject: Re: [radext] Status of extensions document? 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 Dec 2011 07:37:22 -0000 --_a3583334-4237-484b-b005-cfaa5a63f798_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > As an alternative=2C how do we update the registry to (a) create the ne= w > extended space=2C and (b) suggest that people should *use* it? [BA] I'd suggest that the document create the new extended space=2C and: 1. Enable attribute requests to be allocated from the new space upon reques= t=3B 2. Require that "large" (e.g. >10) attribute requests be allocated onl= y from the new space (to prevent attribute hoarding)=3B 3. Prescribe that a= ttributes automatically be allocated from the new space once the "standards= " space is exhausted=3B=20 > There's currently a strong push to use the standard space for > everything=2C even new standards which would be better served by using th= e > extended format. The excuse is "the extended format isn't published"=2C > or "it isn't implemented" [BA] Both of those objections can be overcome by publishing the document an= d implementing the format.=20 > It's a circular argument (as has been pointed out repeatedly). Yet > it's appealing=2C because it lets people ignore the problem for another > few years.=20 [BA] It might take a few years to get the extensions widely implemented so= that's not so bad by itself.=20 However=2C I would be upset if a few "large" requests were to exhaust the s= tandards space before that point. =20 > It lets people delay updating their implementations. After > all=2C 400-500 lines of code for the extended format is just too > complicated to add to an implementation. [BA] It's not just implementing=2C there is also deployment to consider. E= ven if all RADIUS servers implementedextensions today=2C it could still tak= e 3-4 years to get the new servers widely deployed. =20 > I propose that we simply discard the extensions document.=20 [BA] No need to go that far. It's a useful document=2C it should be publis= hed.=20 > Instead=2C we should just keep allocating from the standard space. Then= =2C when all > attributes have been allocated=2C we should panic. [BA] The two are not mutually exclusive. We can publish the extension docu= ment=2C then keep allocating from the standards space=2C and in a few years= =2C panic.=20 Based on recent experience with IPv6=2C this is a time-honored technique. = = --_a3583334-4237-484b-b005-cfaa5a63f798_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B As an alternative=2C how do we update the registry to (a) cre= ate the new
>=3B extended space=2C and (b) suggest that people should = *use* it?

[BA]  =3BI'd suggest that the docume= nt create the new extended space=2C =3B
and:

1. Enable attribute requests to be allocated from the new space up= on request=3B =3B
2. Require that "large" (e.g. >=3B10) att= ribute requests be allocated only from the new space (to prevent attribute = hoarding)=3B =3B
3. Prescribe that attributes automatically b= e allocated from the new space once the "standards" space is exhausted=3B&n= bsp=3B

>=3B There's currently a strong push to use the st= andard space for
>=3B everything=2C even new standards which would be = better served by using the
>=3B extended format. The excuse is "the e= xtended format isn't published"=2C
>=3B or "it isn't implemented"
<= br>
[BA] Both of those objections can be overcome by publishing t= he document and implementing the format. =3B

&= gt=3B It's a circular argument (as has been pointed out repeatedly). Yet=
>=3B it's appealing=2C because it lets people ignore the problem for = another
>=3B few years. =3B

[BA]  =3B= It might take a few years to get the extensions widely implemented so that'= s not so bad by itself. =3B

However=2C I would= be upset if a few "large" requests were to exhaust the standards space bef= ore that point.  =3B

>=3B It lets people del= ay updating their implementations. After
>=3B all=2C 400-500 lines of= code for the extended format is just too
>=3B complicated to add to a= n implementation.

[BA] It's not just implementing= =2C there is also deployment to consider.  =3BEven if all RADIUS server= s implemented
extensions today=2C it could still take 3-4 years t= o get the new servers widely deployed.  =3B


>=3B = I propose that we simply discard the extensions document. =3B

[BA] No need to go that far.  =3BIt's a useful document= =2C it should be published. =3B

>=3B Instead= =2C we =3Bshould just keep allocating from the standard space. Then=2C= when all
>=3B attributes have been allocated=2C we should panic.

[BA] The two are not mutually exclusive.  =3BWe ca= n publish the extension document=2C then keep allocating from the standards= space=2C and in a few years=2C panic. =3B

Bas= ed on recent experience with IPv6=2C this is a time-honored technique. &nbs= p=3B
= --_a3583334-4237-484b-b005-cfaa5a63f798_-- From radext-bounces@ietf.org Wed Dec 28 23:37:24 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E01E21F845F; Wed, 28 Dec 2011 23:37:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325144244; bh=GZu6cqGxibWVWtdJBJ80s5o8MhwQBaZ68iqvIQ1uDAY=; h=Message-ID:From:To:Date:In-Reply-To:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=AgXCa5NjpQ828qN8GCqiONdN6XlaLylPbvj3HcqhoiCD1Zl937cshLF1/w+I5/VA9 uaQLe1y98fQodNL/YPQyyouuEFpoNOgC5afAAWlfRUwWg2FxWqbvq3u9QxD2ruIn2V nE6Q4x6Got6KMkVsVwQg7DmUMZU4CKseVOFalAHw= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923A721F845E for ; Wed, 28 Dec 2011 23:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.998 X-Spam-Level: X-Spam-Status: No, score=-99.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5ZONNprooua for ; Wed, 28 Dec 2011 23:37:22 -0800 (PST) Received: from blu0-omc2-s14.blu0.hotmail.com (blu0-omc2-s14.blu0.hotmail.com [65.55.111.89]) by ietfa.amsl.com (Postfix) with ESMTP id C327B21F845F for ; Wed, 28 Dec 2011 23:37:21 -0800 (PST) Received: from BLU152-W46 ([65.55.111.71]) by blu0-omc2-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Dec 2011 23:37:21 -0800 Message-ID: X-Originating-IP: [75.139.208.190] From: Bernard Aboba To: Alan DeKok Date: Wed, 28 Dec 2011 23:37:21 -0800 Importance: Normal In-Reply-To: <4EF8BF4D.6090401@deployingradius.com> References: <4EF1DC0A.1070004@deployingradius.com>, , <4EF5DC11.5050606@deployingradius.com>, , <4EF5F686.6080202@deployingradius.com>, , <4EF88423.7050305@deployingradius.com> , <4EF8BF4D.6090401@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 29 Dec 2011 07:37:21.0834 (UTC) FILETIME=[B359D0A0:01CCC5FC] Cc: radext@ietf.org, dnelson@elbrys.com, leaf.y.yeh@huawei.com Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1377407741941911658==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============1377407741941911658== Content-Type: multipart/alternative; boundary="_a3583334-4237-484b-b005-cfaa5a63f798_" --_a3583334-4237-484b-b005-cfaa5a63f798_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > As an alternative=2C how do we update the registry to (a) create the ne= w > extended space=2C and (b) suggest that people should *use* it? [BA] I'd suggest that the document create the new extended space=2C and: 1. Enable attribute requests to be allocated from the new space upon reques= t=3B 2. Require that "large" (e.g. >10) attribute requests be allocated onl= y from the new space (to prevent attribute hoarding)=3B 3. Prescribe that a= ttributes automatically be allocated from the new space once the "standards= " space is exhausted=3B=20 > There's currently a strong push to use the standard space for > everything=2C even new standards which would be better served by using th= e > extended format. The excuse is "the extended format isn't published"=2C > or "it isn't implemented" [BA] Both of those objections can be overcome by publishing the document an= d implementing the format.=20 > It's a circular argument (as has been pointed out repeatedly). Yet > it's appealing=2C because it lets people ignore the problem for another > few years.=20 [BA] It might take a few years to get the extensions widely implemented so= that's not so bad by itself.=20 However=2C I would be upset if a few "large" requests were to exhaust the s= tandards space before that point. =20 > It lets people delay updating their implementations. After > all=2C 400-500 lines of code for the extended format is just too > complicated to add to an implementation. [BA] It's not just implementing=2C there is also deployment to consider. E= ven if all RADIUS servers implementedextensions today=2C it could still tak= e 3-4 years to get the new servers widely deployed. =20 > I propose that we simply discard the extensions document.=20 [BA] No need to go that far. It's a useful document=2C it should be publis= hed.=20 > Instead=2C we should just keep allocating from the standard space. Then= =2C when all > attributes have been allocated=2C we should panic. [BA] The two are not mutually exclusive. We can publish the extension docu= ment=2C then keep allocating from the standards space=2C and in a few years= =2C panic.=20 Based on recent experience with IPv6=2C this is a time-honored technique. = = --_a3583334-4237-484b-b005-cfaa5a63f798_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B As an alternative=2C how do we update the registry to (a) cre= ate the new
>=3B extended space=2C and (b) suggest that people should = *use* it?

[BA]  =3BI'd suggest that the docume= nt create the new extended space=2C =3B
and:

1. Enable attribute requests to be allocated from the new space up= on request=3B =3B
2. Require that "large" (e.g. >=3B10) att= ribute requests be allocated only from the new space (to prevent attribute = hoarding)=3B =3B
3. Prescribe that attributes automatically b= e allocated from the new space once the "standards" space is exhausted=3B&n= bsp=3B

>=3B There's currently a strong push to use the st= andard space for
>=3B everything=2C even new standards which would be = better served by using the
>=3B extended format. The excuse is "the e= xtended format isn't published"=2C
>=3B or "it isn't implemented"
<= br>
[BA] Both of those objections can be overcome by publishing t= he document and implementing the format. =3B

&= gt=3B It's a circular argument (as has been pointed out repeatedly). Yet=
>=3B it's appealing=2C because it lets people ignore the problem for = another
>=3B few years. =3B

[BA]  =3B= It might take a few years to get the extensions widely implemented so that'= s not so bad by itself. =3B

However=2C I would= be upset if a few "large" requests were to exhaust the standards space bef= ore that point.  =3B

>=3B It lets people del= ay updating their implementations. After
>=3B all=2C 400-500 lines of= code for the extended format is just too
>=3B complicated to add to a= n implementation.

[BA] It's not just implementing= =2C there is also deployment to consider.  =3BEven if all RADIUS server= s implemented
extensions today=2C it could still take 3-4 years t= o get the new servers widely deployed.  =3B


>=3B = I propose that we simply discard the extensions document. =3B

[BA] No need to go that far.  =3BIt's a useful document= =2C it should be published. =3B

>=3B Instead= =2C we =3Bshould just keep allocating from the standard space. Then=2C= when all
>=3B attributes have been allocated=2C we should panic.

[BA] The two are not mutually exclusive.  =3BWe ca= n publish the extension document=2C then keep allocating from the standards= space=2C and in a few years=2C panic. =3B

Bas= ed on recent experience with IPv6=2C this is a time-honored technique. &nbs= p=3B
= --_a3583334-4237-484b-b005-cfaa5a63f798_-- --===============1377407741941911658== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============1377407741941911658==-- From leaf.y.yeh@huawei.com Thu Dec 29 03:33:52 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D328D21F84AC for ; Thu, 29 Dec 2011 03:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+4tJTo7Wx+x for ; Thu, 29 Dec 2011 03:33:52 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDEB21F84A0 for ; Thu, 29 Dec 2011 03:33:51 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWY001NQQKKHW@szxga03-in.huawei.com> for radext@ietf.org; Thu, 29 Dec 2011 19:29:08 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWY00323QKK0H@szxga03-in.huawei.com> for radext@ietf.org; Thu, 29 Dec 2011 19:29:08 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGA02537; Thu, 29 Dec 2011 19:29:06 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Dec 2011 19:29:00 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.223]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0323.003; Thu, 29 Dec 2011 19:29:03 +0800 Date: Thu, 29 Dec 2011 11:28:36 +0000 From: Leaf yeh In-reply-to: X-Originating-IP: [10.70.39.113] To: Alan DeKok , Bernard Aboba Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Q05egTgEq6fAIizrcu7Xtw)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [radext] Status of extensions document? Thread-index: AQHMv+LGizesQYvWFUusQXiD6agRkJXpICiggAEz1ZCAADAzgIAACfsAgAAVjwCAAZvSAIABb1mAgABBoACAAATogIAD/haAgACXA+A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EF1DC0A.1070004@deployingradius.com> <4EF5DC11.5050606@deployingradius.com> <4EF5F686.6080202@deployingradius.com> <4EF88423.7050305@deployingradius.com> <4EF8BF4D.6090401@deployingradius.com> Cc: "radext@ietf.org" , "dnelson@elbrys.com" Subject: Re: [radext] Status of extensions document? 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 Dec 2011 11:33:53 -0000 --Boundary_(ID_Q05egTgEq6fAIizrcu7Xtw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT [BA] No need to go that far. It's a useful document, it should be published. I also support to publish draft-ietf-radext-radius-extensions. At least I need data type of Integer64 for the definition of IPv4 or IPv6 traffic statistics in my individual draft. Another comment for the further discussion: Do we really need around 1k (4*240) in the new type space got from 241.* to 244.* for the Extended-Type? I guess the design of 241.* (or plus 242.*) might be enough to meet the current requirement or situation. From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Thursday, December 29, 2011 3:37 PM To: Alan DeKok Cc: radext@ietf.org; dnelson@elbrys.com; Leaf yeh Subject: RE: [radext] Status of extensions document? > As an alternative, how do we update the registry to (a) create the new > extended space, and (b) suggest that people should *use* it? [BA] I'd suggest that the document create the new extended space, and: 1. Enable attribute requests to be allocated from the new space upon request; 2. Require that "large" (e.g. >10) attribute requests be allocated only from the new space (to prevent attribute hoarding); 3. Prescribe that attributes automatically be allocated from the new space once the "standards" space is exhausted; > There's currently a strong push to use the standard space for > everything, even new standards which would be better served by using the > extended format. The excuse is "the extended format isn't published", > or "it isn't implemented" [BA] Both of those objections can be overcome by publishing the document and implementing the format. > It's a circular argument (as has been pointed out repeatedly). Yet > it's appealing, because it lets people ignore the problem for another > few years. [BA] It might take a few years to get the extensions widely implemented so that's not so bad by itself. However, I would be upset if a few "large" requests were to exhaust the standards space before that point. > It lets people delay updating their implementations. After > all, 400-500 lines of code for the extended format is just too > complicated to add to an implementation. [BA] It's not just implementing, there is also deployment to consider. Even if all RADIUS servers implemented extensions today, it could still take 3-4 years to get the new servers widely deployed. > I propose that we simply discard the extensions document. [BA] No need to go that far. It's a useful document, it should be published. > Instead, we should just keep allocating from the standard space. Then, when all > attributes have been allocated, we should panic. [BA] The two are not mutually exclusive. We can publish the extension document, then keep allocating from the standards space, and in a few years, panic. Based on recent experience with IPv6, this is a time-honored technique. --Boundary_(ID_Q05egTgEq6fAIizrcu7Xtw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4w cHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+W0JBXSBObyBuZWVkIHRvIGdvIHRoYXQg ZmFyLiAmbmJzcDtJdCdzIGEgdXNlZnVsIGRvY3VtZW50LCBpdCBzaG91bGQgYmUgcHVibGlzaGVk LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFsc28gc3VwcG9y dCB0byBwdWJsaXNoIGRyYWZ0LWlldGYtcmFkZXh0LXJhZGl1cy1leHRlbnNpb25zLg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BdCBsZWFzdCBJIG5lZWQgZGF0 YSB0eXBlIG9mIEludGVnZXI2NCBmb3IgdGhlIGRlZmluaXRpb24gb2YgSVB2NCBvciBJUHY2IHRy YWZmaWMgc3RhdGlzdGljcyBpbiBteSBpbmRpdmlkdWFsIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5Bbm90aGVyIGNvbW1lbnQgZm9yIHRoZSBmdXJ0aGVyIGRpc2N1 c3Npb246DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RG8gd2UgcmVhbGx5 IG5lZWQgYXJvdW5kIDFrICg0KjI0MCkgaW4gdGhlIG5ldyB0eXBlIHNwYWNlIGdvdCBmcm9tIDI0 MS4qIHRvIDI0NC4qIGZvciB0aGUgRXh0ZW5kZWQtVHlwZT8NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBndWVzcyB0aGUgZGVzaWduIG9mIDI0MS4qIChvciBw bHVzIDI0Mi4qKSBtaWdodCBiZSBlbm91Z2ggdG8gbWVldCB0aGUgY3VycmVudCByZXF1aXJlbWVu dCBvciBzaXR1YXRpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gQmVybmFyZCBBYm9iYSBbbWFpbHRvOmJlcm5hcmRfYWJvYmFAaG90bWFpbC5jb21dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIERlY2VtYmVyIDI5LCAyMDExIDM6MzcgUE08YnI+ DQo8Yj5Ubzo8L2I+IEFsYW4gRGVLb2s8YnI+DQo8Yj5DYzo8L2I+IHJhZGV4dEBpZXRmLm9yZzsg ZG5lbHNvbkBlbGJyeXMuY29tOyBMZWFmIHllaDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3Jh ZGV4dF0gU3RhdHVzIG9mIGV4dGVuc2lvbnMgZG9jdW1lbnQ/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyBB cyBhbiBhbHRlcm5hdGl2ZSwgaG93IGRvIHdlIHVwZGF0ZSB0aGUgcmVnaXN0cnkgdG8gKGEpIGNy ZWF0ZSB0aGUgbmV3PGJyPg0KJmd0OyBleHRlbmRlZCBzcGFjZSwgYW5kIChiKSBzdWdnZXN0IHRo YXQgcGVvcGxlIHNob3VsZCAqdXNlKiBpdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+W0JBXSAmbmJzcDtJJ2Qgc3VnZ2VzdCB0aGF0IHRoZSBkb2N1bWVudCBjcmVhdGUgdGhl IG5ldyBleHRlbmRlZCBzcGFjZSwmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPmFuZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+MS4g RW5hYmxlIGF0dHJpYnV0ZSByZXF1ZXN0cyB0byBiZSBhbGxvY2F0ZWQgZnJvbSB0aGUgbmV3IHNw YWNlIHVwb24gcmVxdWVzdDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjIuIFJlcXVpcmUgdGhhdCAmcXVvdDtsYXJnZSZxdW90OyAoZS5nLiAmZ3Q7MTAp IGF0dHJpYnV0ZSByZXF1ZXN0cyBiZSBhbGxvY2F0ZWQgb25seSBmcm9tIHRoZSBuZXcgc3BhY2Ug KHRvIHByZXZlbnQgYXR0cmlidXRlIGhvYXJkaW5nKTsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjMuIFByZXNjcmliZSB0aGF0IGF0dHJpYnV0ZXMgYXV0 b21hdGljYWxseSBiZSBhbGxvY2F0ZWQgZnJvbSB0aGUgbmV3IHNwYWNlIG9uY2UgdGhlICZxdW90 O3N0YW5kYXJkcyZxdW90OyBzcGFjZSBpcyBleGhhdXN0ZWQ7Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pjxicj4NCiZndDsgVGhlcmUncyBjdXJyZW50bHkgYSBzdHJvbmcgcHVzaCB0byB1c2UgdGhlIHN0 YW5kYXJkIHNwYWNlIGZvcjxicj4NCiZndDsgZXZlcnl0aGluZywgZXZlbiBuZXcgc3RhbmRhcmRz IHdoaWNoIHdvdWxkIGJlIGJldHRlciBzZXJ2ZWQgYnkgdXNpbmcgdGhlPGJyPg0KJmd0OyBleHRl bmRlZCBmb3JtYXQuIFRoZSBleGN1c2UgaXMgJnF1b3Q7dGhlIGV4dGVuZGVkIGZvcm1hdCBpc24n dCBwdWJsaXNoZWQmcXVvdDssPGJyPg0KJmd0OyBvciAmcXVvdDtpdCBpc24ndCBpbXBsZW1lbnRl ZCZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+W0JBXSBC b3RoIG9mIHRob3NlIG9iamVjdGlvbnMgY2FuIGJlIG92ZXJjb21lIGJ5IHB1Ymxpc2hpbmcgdGhl IGRvY3VtZW50IGFuZCBpbXBsZW1lbnRpbmcgdGhlIGZvcm1hdC4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyBJdCdzIGEgY2lyY3VsYXIgYXJndW1lbnQgKGFz IGhhcyBiZWVuIHBvaW50ZWQgb3V0IHJlcGVhdGVkbHkpLiBZZXQ8YnI+DQomZ3Q7IGl0J3MgYXBw ZWFsaW5nLCBiZWNhdXNlIGl0IGxldHMgcGVvcGxlIGlnbm9yZSB0aGUgcHJvYmxlbSBmb3IgYW5v dGhlcjxicj4NCiZndDsgZmV3IHllYXJzLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5bQkFdICZuYnNwO0l0IG1pZ2h0IHRha2UgYSBmZXcgeWVhcnMgdG8gZ2V0IHRo ZSBleHRlbnNpb25zIHdpZGVseSBpbXBsZW1lbnRlZCBzbyB0aGF0J3Mgbm90IHNvIGJhZCBieSBp dHNlbGYuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhvd2V2ZXIs IEkgd291bGQgYmUgdXBzZXQgaWYgYSBmZXcgJnF1b3Q7bGFyZ2UmcXVvdDsgcmVxdWVzdHMgd2Vy ZSB0byBleGhhdXN0IHRoZSBzdGFuZGFyZHMgc3BhY2UgYmVmb3JlIHRoYXQgcG9pbnQuICZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7IEl0IGxldHMgcGVvcGxl IGRlbGF5IHVwZGF0aW5nIHRoZWlyIGltcGxlbWVudGF0aW9ucy4gQWZ0ZXI8YnI+DQomZ3Q7IGFs bCwgNDAwLTUwMCBsaW5lcyBvZiBjb2RlIGZvciB0aGUgZXh0ZW5kZWQgZm9ybWF0IGlzIGp1c3Qg dG9vPGJyPg0KJmd0OyBjb21wbGljYXRlZCB0byBhZGQgdG8gYW4gaW1wbGVtZW50YXRpb24uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPltCQV0gSXQncyBub3QganVzdCBpbXBs ZW1lbnRpbmcsIHRoZXJlIGlzIGFsc28gZGVwbG95bWVudCB0byBjb25zaWRlci4gJm5ic3A7RXZl biBpZiBhbGwgUkFESVVTIHNlcnZlcnMgaW1wbGVtZW50ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPmV4dGVuc2lvbnMgdG9kYXksIGl0IGNvdWxkIHN0aWxsIHRh a2UgMy00IHllYXJzIHRvIGdldCB0aGUgbmV3IHNlcnZlcnMgd2lkZWx5IGRlcGxveWVkLiAmbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxicj4N CiZndDsgSSBwcm9wb3NlIHRoYXQgd2Ugc2ltcGx5IGRpc2NhcmQgdGhlIGV4dGVuc2lvbnMgZG9j dW1lbnQuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPltCQV0gTm8g bmVlZCB0byBnbyB0aGF0IGZhci4gJm5ic3A7SXQncyBhIHVzZWZ1bCBkb2N1bWVudCwgaXQgc2hv dWxkIGJlIHB1Ymxpc2hlZC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jmd0OyBJbnN0ZWFkLCB3ZSZuYnNwO3Nob3VsZCBqdXN0IGtlZXAgYWxsb2NhdGluZyBmcm9t IHRoZSBzdGFuZGFyZCBzcGFjZS4gVGhlbiwgd2hlbiBhbGw8YnI+DQomZ3Q7IGF0dHJpYnV0ZXMg aGF2ZSBiZWVuIGFsbG9jYXRlZCwgd2Ugc2hvdWxkIHBhbmljLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5bQkFdIFRoZSB0d28gYXJlIG5vdCBtdXR1YWxseSBleGNsdXNpdmUu ICZuYnNwO1dlIGNhbiBwdWJsaXNoIHRoZSBleHRlbnNpb24gZG9jdW1lbnQsIHRoZW4ga2VlcCBh bGxvY2F0aW5nIGZyb20gdGhlIHN0YW5kYXJkcyBzcGFjZSwgYW5kIGluIGEgZmV3IHllYXJzLCBw YW5pYy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QmFzZWQgb24g cmVjZW50IGV4cGVyaWVuY2Ugd2l0aCBJUHY2LCB0aGlzIGlzIGEgdGltZS1ob25vcmVkIHRlY2hu aXF1ZS4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --Boundary_(ID_Q05egTgEq6fAIizrcu7Xtw)-- From radext-bounces@ietf.org Thu Dec 29 03:33:55 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C7A21F84B2; Thu, 29 Dec 2011 03:33:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325158434; bh=R+iSmnNGdpjTNpUryLZI3AFRJi3e97keQDYcL2ntuhI=; h=Date:From:In-reply-to:To:Message-id:MIME-version:References:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=N/BeQVxg0P4hcQ9OXrc4h2/3UqXK7k21NCG4IHTeWLQgpHD5IgnTOFshQqWwXygkI YiIcp9ggkDxg0JOjpspYUcUEl6jSVSh6jh+/Wacd4o7LGEri7iKOl/leI5Cz7xEVyk pGTsiEPkBkYEdncHZt+XzLr3iZgt4a7z8Gth0mJs= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D328D21F84AC for ; Thu, 29 Dec 2011 03:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+4tJTo7Wx+x for ; Thu, 29 Dec 2011 03:33:52 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDEB21F84A0 for ; Thu, 29 Dec 2011 03:33:51 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWY001NQQKKHW@szxga03-in.huawei.com> for radext@ietf.org; Thu, 29 Dec 2011 19:29:08 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWY00323QKK0H@szxga03-in.huawei.com> for radext@ietf.org; Thu, 29 Dec 2011 19:29:08 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGA02537; Thu, 29 Dec 2011 19:29:06 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Dec 2011 19:29:00 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.223]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0323.003; Thu, 29 Dec 2011 19:29:03 +0800 Date: Thu, 29 Dec 2011 11:28:36 +0000 From: Leaf yeh In-reply-to: X-Originating-IP: [10.70.39.113] To: Alan DeKok , Bernard Aboba Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [radext] Status of extensions document? Thread-index: AQHMv+LGizesQYvWFUusQXiD6agRkJXpICiggAEz1ZCAADAzgIAACfsAgAAVjwCAAZvSAIABb1mAgABBoACAAATogIAD/haAgACXA+A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EF1DC0A.1070004@deployingradius.com> <4EF5DC11.5050606@deployingradius.com> <4EF5F686.6080202@deployingradius.com> <4EF88423.7050305@deployingradius.com> <4EF8BF4D.6090401@deployingradius.com> Cc: "radext@ietf.org" , "dnelson@elbrys.com" Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6361475518266057237==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============6361475518266057237== Content-type: multipart/alternative; boundary="Boundary_(ID_Q05egTgEq6fAIizrcu7Xtw)" Content-language: zh-CN --Boundary_(ID_Q05egTgEq6fAIizrcu7Xtw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT [BA] No need to go that far. It's a useful document, it should be published. I also support to publish draft-ietf-radext-radius-extensions. At least I need data type of Integer64 for the definition of IPv4 or IPv6 traffic statistics in my individual draft. Another comment for the further discussion: Do we really need around 1k (4*240) in the new type space got from 241.* to 244.* for the Extended-Type? I guess the design of 241.* (or plus 242.*) might be enough to meet the current requirement or situation. From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Thursday, December 29, 2011 3:37 PM To: Alan DeKok Cc: radext@ietf.org; dnelson@elbrys.com; Leaf yeh Subject: RE: [radext] Status of extensions document? > As an alternative, how do we update the registry to (a) create the new > extended space, and (b) suggest that people should *use* it? [BA] I'd suggest that the document create the new extended space, and: 1. Enable attribute requests to be allocated from the new space upon request; 2. Require that "large" (e.g. >10) attribute requests be allocated only from the new space (to prevent attribute hoarding); 3. Prescribe that attributes automatically be allocated from the new space once the "standards" space is exhausted; > There's currently a strong push to use the standard space for > everything, even new standards which would be better served by using the > extended format. The excuse is "the extended format isn't published", > or "it isn't implemented" [BA] Both of those objections can be overcome by publishing the document and implementing the format. > It's a circular argument (as has been pointed out repeatedly). Yet > it's appealing, because it lets people ignore the problem for another > few years. [BA] It might take a few years to get the extensions widely implemented so that's not so bad by itself. However, I would be upset if a few "large" requests were to exhaust the standards space before that point. > It lets people delay updating their implementations. After > all, 400-500 lines of code for the extended format is just too > complicated to add to an implementation. [BA] It's not just implementing, there is also deployment to consider. Even if all RADIUS servers implemented extensions today, it could still take 3-4 years to get the new servers widely deployed. > I propose that we simply discard the extensions document. [BA] No need to go that far. It's a useful document, it should be published. > Instead, we should just keep allocating from the standard space. Then, when all > attributes have been allocated, we should panic. [BA] The two are not mutually exclusive. We can publish the extension document, then keep allocating from the standards space, and in a few years, panic. Based on recent experience with IPv6, this is a time-honored technique. --Boundary_(ID_Q05egTgEq6fAIizrcu7Xtw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4w cHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+W0JBXSBObyBuZWVkIHRvIGdvIHRoYXQg ZmFyLiAmbmJzcDtJdCdzIGEgdXNlZnVsIGRvY3VtZW50LCBpdCBzaG91bGQgYmUgcHVibGlzaGVk LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFsc28gc3VwcG9y dCB0byBwdWJsaXNoIGRyYWZ0LWlldGYtcmFkZXh0LXJhZGl1cy1leHRlbnNpb25zLg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BdCBsZWFzdCBJIG5lZWQgZGF0 YSB0eXBlIG9mIEludGVnZXI2NCBmb3IgdGhlIGRlZmluaXRpb24gb2YgSVB2NCBvciBJUHY2IHRy YWZmaWMgc3RhdGlzdGljcyBpbiBteSBpbmRpdmlkdWFsIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5Bbm90aGVyIGNvbW1lbnQgZm9yIHRoZSBmdXJ0aGVyIGRpc2N1 c3Npb246DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RG8gd2UgcmVhbGx5 IG5lZWQgYXJvdW5kIDFrICg0KjI0MCkgaW4gdGhlIG5ldyB0eXBlIHNwYWNlIGdvdCBmcm9tIDI0 MS4qIHRvIDI0NC4qIGZvciB0aGUgRXh0ZW5kZWQtVHlwZT8NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBndWVzcyB0aGUgZGVzaWduIG9mIDI0MS4qIChvciBw bHVzIDI0Mi4qKSBtaWdodCBiZSBlbm91Z2ggdG8gbWVldCB0aGUgY3VycmVudCByZXF1aXJlbWVu dCBvciBzaXR1YXRpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gQmVybmFyZCBBYm9iYSBbbWFpbHRvOmJlcm5hcmRfYWJvYmFAaG90bWFpbC5jb21dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIERlY2VtYmVyIDI5LCAyMDExIDM6MzcgUE08YnI+ DQo8Yj5Ubzo8L2I+IEFsYW4gRGVLb2s8YnI+DQo8Yj5DYzo8L2I+IHJhZGV4dEBpZXRmLm9yZzsg ZG5lbHNvbkBlbGJyeXMuY29tOyBMZWFmIHllaDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3Jh ZGV4dF0gU3RhdHVzIG9mIGV4dGVuc2lvbnMgZG9jdW1lbnQ/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyBB cyBhbiBhbHRlcm5hdGl2ZSwgaG93IGRvIHdlIHVwZGF0ZSB0aGUgcmVnaXN0cnkgdG8gKGEpIGNy ZWF0ZSB0aGUgbmV3PGJyPg0KJmd0OyBleHRlbmRlZCBzcGFjZSwgYW5kIChiKSBzdWdnZXN0IHRo YXQgcGVvcGxlIHNob3VsZCAqdXNlKiBpdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+W0JBXSAmbmJzcDtJJ2Qgc3VnZ2VzdCB0aGF0IHRoZSBkb2N1bWVudCBjcmVhdGUgdGhl IG5ldyBleHRlbmRlZCBzcGFjZSwmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPmFuZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+MS4g RW5hYmxlIGF0dHJpYnV0ZSByZXF1ZXN0cyB0byBiZSBhbGxvY2F0ZWQgZnJvbSB0aGUgbmV3IHNw YWNlIHVwb24gcmVxdWVzdDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjIuIFJlcXVpcmUgdGhhdCAmcXVvdDtsYXJnZSZxdW90OyAoZS5nLiAmZ3Q7MTAp IGF0dHJpYnV0ZSByZXF1ZXN0cyBiZSBhbGxvY2F0ZWQgb25seSBmcm9tIHRoZSBuZXcgc3BhY2Ug KHRvIHByZXZlbnQgYXR0cmlidXRlIGhvYXJkaW5nKTsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjMuIFByZXNjcmliZSB0aGF0IGF0dHJpYnV0ZXMgYXV0 b21hdGljYWxseSBiZSBhbGxvY2F0ZWQgZnJvbSB0aGUgbmV3IHNwYWNlIG9uY2UgdGhlICZxdW90 O3N0YW5kYXJkcyZxdW90OyBzcGFjZSBpcyBleGhhdXN0ZWQ7Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pjxicj4NCiZndDsgVGhlcmUncyBjdXJyZW50bHkgYSBzdHJvbmcgcHVzaCB0byB1c2UgdGhlIHN0 YW5kYXJkIHNwYWNlIGZvcjxicj4NCiZndDsgZXZlcnl0aGluZywgZXZlbiBuZXcgc3RhbmRhcmRz IHdoaWNoIHdvdWxkIGJlIGJldHRlciBzZXJ2ZWQgYnkgdXNpbmcgdGhlPGJyPg0KJmd0OyBleHRl bmRlZCBmb3JtYXQuIFRoZSBleGN1c2UgaXMgJnF1b3Q7dGhlIGV4dGVuZGVkIGZvcm1hdCBpc24n dCBwdWJsaXNoZWQmcXVvdDssPGJyPg0KJmd0OyBvciAmcXVvdDtpdCBpc24ndCBpbXBsZW1lbnRl ZCZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+W0JBXSBC b3RoIG9mIHRob3NlIG9iamVjdGlvbnMgY2FuIGJlIG92ZXJjb21lIGJ5IHB1Ymxpc2hpbmcgdGhl IGRvY3VtZW50IGFuZCBpbXBsZW1lbnRpbmcgdGhlIGZvcm1hdC4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyBJdCdzIGEgY2lyY3VsYXIgYXJndW1lbnQgKGFz IGhhcyBiZWVuIHBvaW50ZWQgb3V0IHJlcGVhdGVkbHkpLiBZZXQ8YnI+DQomZ3Q7IGl0J3MgYXBw ZWFsaW5nLCBiZWNhdXNlIGl0IGxldHMgcGVvcGxlIGlnbm9yZSB0aGUgcHJvYmxlbSBmb3IgYW5v dGhlcjxicj4NCiZndDsgZmV3IHllYXJzLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5bQkFdICZuYnNwO0l0IG1pZ2h0IHRha2UgYSBmZXcgeWVhcnMgdG8gZ2V0IHRo ZSBleHRlbnNpb25zIHdpZGVseSBpbXBsZW1lbnRlZCBzbyB0aGF0J3Mgbm90IHNvIGJhZCBieSBp dHNlbGYuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhvd2V2ZXIs IEkgd291bGQgYmUgdXBzZXQgaWYgYSBmZXcgJnF1b3Q7bGFyZ2UmcXVvdDsgcmVxdWVzdHMgd2Vy ZSB0byBleGhhdXN0IHRoZSBzdGFuZGFyZHMgc3BhY2UgYmVmb3JlIHRoYXQgcG9pbnQuICZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7IEl0IGxldHMgcGVvcGxl IGRlbGF5IHVwZGF0aW5nIHRoZWlyIGltcGxlbWVudGF0aW9ucy4gQWZ0ZXI8YnI+DQomZ3Q7IGFs bCwgNDAwLTUwMCBsaW5lcyBvZiBjb2RlIGZvciB0aGUgZXh0ZW5kZWQgZm9ybWF0IGlzIGp1c3Qg dG9vPGJyPg0KJmd0OyBjb21wbGljYXRlZCB0byBhZGQgdG8gYW4gaW1wbGVtZW50YXRpb24uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPltCQV0gSXQncyBub3QganVzdCBpbXBs ZW1lbnRpbmcsIHRoZXJlIGlzIGFsc28gZGVwbG95bWVudCB0byBjb25zaWRlci4gJm5ic3A7RXZl biBpZiBhbGwgUkFESVVTIHNlcnZlcnMgaW1wbGVtZW50ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPmV4dGVuc2lvbnMgdG9kYXksIGl0IGNvdWxkIHN0aWxsIHRh a2UgMy00IHllYXJzIHRvIGdldCB0aGUgbmV3IHNlcnZlcnMgd2lkZWx5IGRlcGxveWVkLiAmbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxicj4N CiZndDsgSSBwcm9wb3NlIHRoYXQgd2Ugc2ltcGx5IGRpc2NhcmQgdGhlIGV4dGVuc2lvbnMgZG9j dW1lbnQuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPltCQV0gTm8g bmVlZCB0byBnbyB0aGF0IGZhci4gJm5ic3A7SXQncyBhIHVzZWZ1bCBkb2N1bWVudCwgaXQgc2hv dWxkIGJlIHB1Ymxpc2hlZC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jmd0OyBJbnN0ZWFkLCB3ZSZuYnNwO3Nob3VsZCBqdXN0IGtlZXAgYWxsb2NhdGluZyBmcm9t IHRoZSBzdGFuZGFyZCBzcGFjZS4gVGhlbiwgd2hlbiBhbGw8YnI+DQomZ3Q7IGF0dHJpYnV0ZXMg aGF2ZSBiZWVuIGFsbG9jYXRlZCwgd2Ugc2hvdWxkIHBhbmljLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5bQkFdIFRoZSB0d28gYXJlIG5vdCBtdXR1YWxseSBleGNsdXNpdmUu ICZuYnNwO1dlIGNhbiBwdWJsaXNoIHRoZSBleHRlbnNpb24gZG9jdW1lbnQsIHRoZW4ga2VlcCBh bGxvY2F0aW5nIGZyb20gdGhlIHN0YW5kYXJkcyBzcGFjZSwgYW5kIGluIGEgZmV3IHllYXJzLCBw YW5pYy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QmFzZWQgb24g cmVjZW50IGV4cGVyaWVuY2Ugd2l0aCBJUHY2LCB0aGlzIGlzIGEgdGltZS1ob25vcmVkIHRlY2hu aXF1ZS4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --Boundary_(ID_Q05egTgEq6fAIizrcu7Xtw)-- --===============6361475518266057237== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============6361475518266057237==-- From aland@deployingradius.com Thu Dec 29 09:00:55 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B3921F8B04 for ; Thu, 29 Dec 2011 09:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.144 X-Spam-Level: X-Spam-Status: No, score=-101.144 tagged_above=-999 required=5 tests=[AWL=-0.959, BAYES_40=-0.185, 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 DyYKTk-iTNmV for ; Thu, 29 Dec 2011 09:00:55 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id F1F2021F8B03 for ; Thu, 29 Dec 2011 09:00:54 -0800 (PST) Message-ID: <4EFC9CA7.5020204@deployingradius.com> Date: Thu, 29 Dec 2011 12:00:23 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <4EF1DC0A.1070004@deployingradius.com> <4EF5DC11.5050606@deployingradius.com> <4EF5F686.6080202@deployingradius.com> <4EF88423.7050305@deployingradius.com> <4EF8BF4D.6090401@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , "radext@ietf.org" , "dnelson@elbrys.com" Subject: Re: [radext] Status of extensions document? 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 Dec 2011 17:00:55 -0000 Leaf yeh wrote: > Do we really need around 1k (4*240) in the new type space got from 241.* > to 244.* for the Extended-Type? Not really. The only reason to allocate many is to remove the perception that the type space was precious. With 1K attributes available, specifications can freely allocate attributes for all needs. Alan DeKok. From radext-bounces@ietf.org Thu Dec 29 09:00:57 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F3021F8B04; Thu, 29 Dec 2011 09:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325178056; bh=w4F7YzQ7zarMXAzYAN3ge/KY7vcXkZToWtcXI3A/3Jk=; 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=UKEIRJbXJj4iSVDMlflsAP/SlQMALQJW/IiLhb5mVYq1M1Aepm6aYwLXXt8lc8TlD vBO4nMDxjfVzZCsLGVDIYMj2RK2Pf+xE/roSzbr6C0FkBFYvP4D0Cf4W+Sq3gvDejV 4vhHeKVSJf8UoKWOnn6ksAanl0wAk99FrsJI/GTo= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B3921F8B04 for ; Thu, 29 Dec 2011 09:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.144 X-Spam-Level: X-Spam-Status: No, score=-101.144 tagged_above=-999 required=5 tests=[AWL=-0.959, BAYES_40=-0.185, 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 DyYKTk-iTNmV for ; Thu, 29 Dec 2011 09:00:55 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id F1F2021F8B03 for ; Thu, 29 Dec 2011 09:00:54 -0800 (PST) Message-ID: <4EFC9CA7.5020204@deployingradius.com> Date: Thu, 29 Dec 2011 12:00:23 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <4EF1DC0A.1070004@deployingradius.com> <4EF5DC11.5050606@deployingradius.com> <4EF5F686.6080202@deployingradius.com> <4EF88423.7050305@deployingradius.com> <4EF8BF4D.6090401@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: Bernard Aboba , "radext@ietf.org" , "dnelson@elbrys.com" Subject: Re: [radext] Status of extensions document? 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: > Do we really need around 1k (4*240) in the new type space got from 241.* > to 244.* for the Extended-Type? Not really. The only reason to allocate many is to remove the perception that the type space was precious. With 1K attributes available, specifications can freely allocate attributes for all needs. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Thu Dec 29 09:09:49 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744F921F8AFD for ; Thu, 29 Dec 2011 09:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.111 X-Spam-Level: X-Spam-Status: No, score=-102.111 tagged_above=-999 required=5 tests=[AWL=0.488, 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 6PsdeKXNRdTg for ; Thu, 29 Dec 2011 09:09:48 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 15DDA21F8B09 for ; Thu, 29 Dec 2011 09:09:48 -0800 (PST) Message-ID: <4EFC9EBA.1050407@deployingradius.com> Date: Thu, 29 Dec 2011 12:09:14 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <4EF1DC0A.1070004@deployingradius.com>, , <4EF5DC11.5050606@deployingradius.com>, , <4EF5F686.6080202@deployingradius.com>, , <4EF88423.7050305@deployingradius.com> , <4EF8BF4D.6090401@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, dnelson@elbrys.com, leaf.y.yeh@huawei.com Subject: Re: [radext] Status of extensions document? 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 Dec 2011 17:09:49 -0000 Bernard Aboba wrote: > [BA] I'd suggest that the document create the new extended space, > and: > > 1. Enable attribute requests to be allocated from the new space upon > request; > 2. Require that "large" (e.g. >10) attribute requests be allocated only > from the new space (to prevent attribute hoarding); > 3. Prescribe that attributes automatically be allocated from the new > space once the "standards" space is exhausted; I've updated the document as above. There is a new text in Section 6 (guidelines for spec authors), and Section 9 (IANA considerations) to address this. The document also updates RFC6158 (it didn't before), and contains text updating the guidelines in specific sections of RFC 6158. > [BA] It's not just implementing, there is also deployment to consider. > Even if all RADIUS servers implemented > extensions today, it could still take 3-4 years to get the new servers > widely deployed. Yes. > [BA] The two are not mutually exclusive. We can publish the extension > document, then keep allocating from the standards space, and in a few > years, panic. > > Based on recent experience with IPv6, this is a time-honored technique. :) The draft submission tool appears to be down. I've put a new version of the document at: http://git.freeradius.org/ietf/draft-ietf-radext-radius-extensions-04.txt I'll try submitting it again next week. Alan DeKok. From radext-bounces@ietf.org Thu Dec 29 09:09:50 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41C721F8B09; Thu, 29 Dec 2011 09:09:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325178590; bh=SNHOCaK0CEAxhM0KN4IPZrnj7Quelk2sTf4R8GxpdX0=; 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=LJR+2C7qAtObXt2ZyjaOkZvrt4yhDqn9Z8zfjD7+/Rgzrs02NUT8Q+0EhIQC16fjc Lyr9wpC4J+SYYf8CQ2SmS15BENXB7l82TfG7CnFgeDp1Yv8S9XIIE/8jI7E32zfyiE JgNn9p5uMkF2feguUHM2uvMEOBwcOmblE+hYz8zM= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744F921F8AFD for ; Thu, 29 Dec 2011 09:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.111 X-Spam-Level: X-Spam-Status: No, score=-102.111 tagged_above=-999 required=5 tests=[AWL=0.488, 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 6PsdeKXNRdTg for ; Thu, 29 Dec 2011 09:09:48 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 15DDA21F8B09 for ; Thu, 29 Dec 2011 09:09:48 -0800 (PST) Message-ID: <4EFC9EBA.1050407@deployingradius.com> Date: Thu, 29 Dec 2011 12:09:14 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <4EF1DC0A.1070004@deployingradius.com>, , <4EF5DC11.5050606@deployingradius.com>, , <4EF5F686.6080202@deployingradius.com>, , <4EF88423.7050305@deployingradius.com> , <4EF8BF4D.6090401@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: radext@ietf.org, dnelson@elbrys.com, leaf.y.yeh@huawei.com Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Bernard Aboba wrote: > [BA] I'd suggest that the document create the new extended space, > and: > > 1. Enable attribute requests to be allocated from the new space upon > request; > 2. Require that "large" (e.g. >10) attribute requests be allocated only > from the new space (to prevent attribute hoarding); > 3. Prescribe that attributes automatically be allocated from the new > space once the "standards" space is exhausted; I've updated the document as above. There is a new text in Section 6 (guidelines for spec authors), and Section 9 (IANA considerations) to address this. The document also updates RFC6158 (it didn't before), and contains text updating the guidelines in specific sections of RFC 6158. > [BA] It's not just implementing, there is also deployment to consider. > Even if all RADIUS servers implemented > extensions today, it could still take 3-4 years to get the new servers > widely deployed. Yes. > [BA] The two are not mutually exclusive. We can publish the extension > document, then keep allocating from the standards space, and in a few > years, panic. > > Based on recent experience with IPv6, this is a time-honored technique. :) The draft submission tool appears to be down. I've put a new version of the document at: http://git.freeradius.org/ietf/draft-ietf-radext-radius-extensions-04.txt I'll try submitting it again next week. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From d.b.nelson@comcast.net Thu Dec 29 09:44:48 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A4821F8B2B for ; Thu, 29 Dec 2011 09:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FVdaOijhy1h for ; Thu, 29 Dec 2011 09:44:48 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 2F67B21F8AF3 for ; Thu, 29 Dec 2011 09:44:48 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by QMTA11.westchester.pa.mail.comcast.net with comcast id F3sZ1i0051ZXKqc5B5kolv; Thu, 29 Dec 2011 17:44:48 +0000 Received: from sz0057.wc.mail.comcast.net ([76.96.58.111]) by omta21.westchester.pa.mail.comcast.net with comcast id F5ko1i00a2PzLBw3h5ko7b; Thu, 29 Dec 2011 17:44:48 +0000 Date: Thu, 29 Dec 2011 17:44:48 +0000 (UTC) From: "David B. Nelson" To: Bernard Aboba Message-ID: <1321358726.124964.1325180688430.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [24.218.90.45] X-Mailer: Zimbra 6.0.13_GA_2934 (ZimbraWebClient - FF3.0 (Mac)/6.0.13_GA_2934) Cc: radext@ietf.org, dnelson@elbrys.com, leaf y yeh , Alan DeKok Subject: Re: [radext] Status of extensions document? 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 Dec 2011 17:44:48 -0000 Bernard writes... > [BA] I'd suggest that the document create the new extended space, > and: > > > 1. Enable attribute requests to be allocated from the new space > upon request; > 2. Require that "large" (e.g. >10) attribute requests be > allocated only from the new space (to prevent attribute hoarding); > 3. Prescribe that attributes automatically be allocated from the > new space once the "standards" space is exhausted; I think that's a more workable approach. > > There's currently a strong push to use the standard space for > > everything, even new standards which would be better served by using > > the extended format. The excuse is "the extended format isn't > > published", or "it isn't implemented" > > > [BA] Both of those objections can be overcome by publishing the > document and implementing the format. Indeed. This has to be a make-before-break kind of transition, and until there is sufficient industry experience with the extended attribute format and sufficient deployment of infrastructure using it, effectively obsoleting the classic attribute format for new uses is premature. > > I propose that we simply discard the extensions document. > > > [BA] No need to go that far. It's a useful document, it should be > published. It should be published, and via the design guidelines process developers should be encouraged to use the extended attribute format when the classic attribute format would be a force-fit. Do we have a practical way to tie allocation in either space to the outcome of a design guidelines review? -- Dave From radext-bounces@ietf.org Thu Dec 29 09:44:50 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CCA21F8B2B; Thu, 29 Dec 2011 09:44:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325180690; bh=v4NUFebj3jkHnxl3FcZ3A7uZdv9hhTjrriAZckU49I4=; 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=krEhKs+NihmXYqU5succMcDvPkvFPBNOC3Whn2XxzrYt75cyqOPdJTJF8d0Q60cn1 MKFQoAN87WzI6VW7eQGRszDeKzmtLCyhfBqBTdtNHq4lRTysCrStCpjwbYRbZDGCNh 0F7Y76oHHN5HQP+yNKhlAQVfkuBZNeCDF4bAGP2s= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A4821F8B2B for ; Thu, 29 Dec 2011 09:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FVdaOijhy1h for ; Thu, 29 Dec 2011 09:44:48 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 2F67B21F8AF3 for ; Thu, 29 Dec 2011 09:44:48 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by QMTA11.westchester.pa.mail.comcast.net with comcast id F3sZ1i0051ZXKqc5B5kolv; Thu, 29 Dec 2011 17:44:48 +0000 Received: from sz0057.wc.mail.comcast.net ([76.96.58.111]) by omta21.westchester.pa.mail.comcast.net with comcast id F5ko1i00a2PzLBw3h5ko7b; Thu, 29 Dec 2011 17:44:48 +0000 Date: Thu, 29 Dec 2011 17:44:48 +0000 (UTC) From: "David B. Nelson" To: Bernard Aboba Message-ID: <1321358726.124964.1325180688430.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> In-Reply-To: MIME-Version: 1.0 X-Originating-IP: [24.218.90.45] X-Mailer: Zimbra 6.0.13_GA_2934 (ZimbraWebClient - FF3.0 (Mac)/6.0.13_GA_2934) Cc: radext@ietf.org, dnelson@elbrys.com, leaf y yeh , Alan DeKok Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Bernard writes... > [BA] I'd suggest that the document create the new extended space, > and: > > > 1. Enable attribute requests to be allocated from the new space > upon request; > 2. Require that "large" (e.g. >10) attribute requests be > allocated only from the new space (to prevent attribute hoarding); > 3. Prescribe that attributes automatically be allocated from the > new space once the "standards" space is exhausted; I think that's a more workable approach. > > There's currently a strong push to use the standard space for > > everything, even new standards which would be better served by using > > the extended format. The excuse is "the extended format isn't > > published", or "it isn't implemented" > > > [BA] Both of those objections can be overcome by publishing the > document and implementing the format. Indeed. This has to be a make-before-break kind of transition, and until there is sufficient industry experience with the extended attribute format and sufficient deployment of infrastructure using it, effectively obsoleting the classic attribute format for new uses is premature. > > I propose that we simply discard the extensions document. > > > [BA] No need to go that far. It's a useful document, it should be > published. It should be published, and via the design guidelines process developers should be encouraged to use the extended attribute format when the classic attribute format would be a force-fit. Do we have a practical way to tie allocation in either space to the outcome of a design guidelines review? -- Dave _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Thu Dec 29 09:48:53 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAB521F8B0D; Thu, 29 Dec 2011 09:48:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325180933; bh=GigUGm8FUfylNgpxaQzwxNjuB8ToIV/jeqJSFbrc9eU=; 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=LQbZWH4N9KuF/GRtiMcOTH41pz3EJV/AC1U1PV4b1SEe7tQ2E0E7xIMCs9LSnRwX/ h5eOw5NyAtOMHOUSZiqcHPqOMvlKxLEd5iofmm/CrgrRwBup76iPrqoaEtQtAm43ES ER5A7mGtYLQ9NN1Z5faqOn+xLsrA21R1e6816zo4= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB38521F8B0D for ; Thu, 29 Dec 2011 09:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyQEGiJdZKxh for ; Thu, 29 Dec 2011 09:48:52 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id EBB6021F8B0B for ; Thu, 29 Dec 2011 09:48:51 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta09.westchester.pa.mail.comcast.net with comcast id F1951i00327AodY595oswl; Thu, 29 Dec 2011 17:48:52 +0000 Received: from sz0057.wc.mail.comcast.net ([76.96.58.111]) by omta19.westchester.pa.mail.comcast.net with comcast id F5os1i00Q2PzLBw3f5osfr; Thu, 29 Dec 2011 17:48:52 +0000 Date: Thu, 29 Dec 2011 17:48:51 +0000 (UTC) From: "David B. Nelson" To: Alan DeKok Message-ID: <430631100.125088.1325180931976.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> In-Reply-To: <4EFC9EBA.1050407@deployingradius.com> MIME-Version: 1.0 X-Originating-IP: [24.218.90.45] X-Mailer: Zimbra 6.0.13_GA_2934 (ZimbraWebClient - FF3.0 (Mac)/6.0.13_GA_2934) Cc: Bernard Aboba , radext@ietf.org, dnelson@elbrys.com, leaf y yeh Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Alan DeKok writes... > I've updated the document as above. There is a new text in Section 6 > (guidelines for spec authors), and Section 9 (IANA considerations) to > address this. You weren't going to wait for just a bit more discussion and consensus-building on the list? ;-) Process aside, I think this is the correct approach. > The document also updates RFC6158 (it didn't before), and contains > text updating the guidelines in specific sections of RFC 6158. Yeah. I'll take a look at that, along the lines of the question I asked in my previous post: Can allocation policy be effectively tied to guidelines review? -- Dave _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From d.b.nelson@comcast.net Thu Dec 29 09:48:52 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB38521F8B0D for ; Thu, 29 Dec 2011 09:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyQEGiJdZKxh for ; Thu, 29 Dec 2011 09:48:52 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id EBB6021F8B0B for ; Thu, 29 Dec 2011 09:48:51 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta09.westchester.pa.mail.comcast.net with comcast id F1951i00327AodY595oswl; Thu, 29 Dec 2011 17:48:52 +0000 Received: from sz0057.wc.mail.comcast.net ([76.96.58.111]) by omta19.westchester.pa.mail.comcast.net with comcast id F5os1i00Q2PzLBw3f5osfr; Thu, 29 Dec 2011 17:48:52 +0000 Date: Thu, 29 Dec 2011 17:48:51 +0000 (UTC) From: "David B. Nelson" To: Alan DeKok Message-ID: <430631100.125088.1325180931976.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> In-Reply-To: <4EFC9EBA.1050407@deployingradius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [24.218.90.45] X-Mailer: Zimbra 6.0.13_GA_2934 (ZimbraWebClient - FF3.0 (Mac)/6.0.13_GA_2934) Cc: Bernard Aboba , radext@ietf.org, dnelson@elbrys.com, leaf y yeh Subject: Re: [radext] Status of extensions document? 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 Dec 2011 17:48:52 -0000 Alan DeKok writes... > I've updated the document as above. There is a new text in Section 6 > (guidelines for spec authors), and Section 9 (IANA considerations) to > address this. You weren't going to wait for just a bit more discussion and consensus-building on the list? ;-) Process aside, I think this is the correct approach. > The document also updates RFC6158 (it didn't before), and contains > text updating the guidelines in specific sections of RFC 6158. Yeah. I'll take a look at that, along the lines of the question I asked in my previous post: Can allocation policy be effectively tied to guidelines review? -- Dave From aland@deployingradius.com Thu Dec 29 10:13:33 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC9C21F8B18 for ; Thu, 29 Dec 2011 10:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.209 X-Spam-Level: X-Spam-Status: No, score=-102.209 tagged_above=-999 required=5 tests=[AWL=0.390, 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 Z9uIErbtWSgE for ; Thu, 29 Dec 2011 10:13:32 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 846A521F8B01 for ; Thu, 29 Dec 2011 10:13:32 -0800 (PST) Message-ID: <4EFCADAE.9090602@deployingradius.com> Date: Thu, 29 Dec 2011 13:13:02 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "David B. Nelson" References: <1321358726.124964.1325180688430.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> In-Reply-To: <1321358726.124964.1325180688430.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , radext@ietf.org, dnelson@elbrys.com, leaf y yeh Subject: Re: [radext] Status of extensions document? 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 Dec 2011 18:13:33 -0000 David B. Nelson wrote: > It should be published, and via the design guidelines process developers should be encouraged to use the extended attribute format when the classic attribute format would be a force-fit. Do we have a practical way to tie allocation in either space to the outcome of a design guidelines review? The document updates RFC 6158, and adds new guidelines. Alan DeKok. From radext-bounces@ietf.org Thu Dec 29 10:13:34 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA66B21F8B01; Thu, 29 Dec 2011 10:13:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325182414; bh=kYAVONCFE277fN0dNv8U9/9FwdgGpdp5j4GwfW/SsoI=; 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=dFxuaH+wWYKN32oHKE4UapPLw8i/xWzFY1UBlge7p9QHWJj7dGKwkJO0mB4feVAFM JvvGBrx5zlbVXY5DYPLQjopJpX5kcjzwSRrZ3FMsEv5y4vMxSefibMcdYMtB372n5s 1hZbjmK25u0LHu23X7vfSpbB/8BCZPleKkFjobS4= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC9C21F8B18 for ; Thu, 29 Dec 2011 10:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.209 X-Spam-Level: X-Spam-Status: No, score=-102.209 tagged_above=-999 required=5 tests=[AWL=0.390, 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 Z9uIErbtWSgE for ; Thu, 29 Dec 2011 10:13:32 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 846A521F8B01 for ; Thu, 29 Dec 2011 10:13:32 -0800 (PST) Message-ID: <4EFCADAE.9090602@deployingradius.com> Date: Thu, 29 Dec 2011 13:13:02 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "David B. Nelson" References: <1321358726.124964.1325180688430.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> In-Reply-To: <1321358726.124964.1325180688430.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> X-Enigmail-Version: 0.96.0 Cc: Bernard Aboba , radext@ietf.org, dnelson@elbrys.com, leaf y yeh Subject: Re: [radext] Status of extensions document? 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 David B. Nelson wrote: > It should be published, and via the design guidelines process developers should be encouraged to use the extended attribute format when the classic attribute format would be a force-fit. Do we have a practical way to tie allocation in either space to the outcome of a design guidelines review? The document updates RFC 6158, and adds new guidelines. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Thu Dec 29 10:17:51 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EE221F8B4B for ; Thu, 29 Dec 2011 10:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 Cf-qVk8dJ4TS for ; Thu, 29 Dec 2011 10:17:50 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 85E3C21F8B3D for ; Thu, 29 Dec 2011 10:17:50 -0800 (PST) Message-ID: <4EFCAEAE.9000206@deployingradius.com> Date: Thu, 29 Dec 2011 13:17:18 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "David B. Nelson" References: <430631100.125088.1325180931976.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> In-Reply-To: <430631100.125088.1325180931976.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , radext@ietf.org, dnelson@elbrys.com, leaf y yeh Subject: Re: [radext] Status of extensions document? 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 Dec 2011 18:17:51 -0000 David B. Nelson wrote: > You weren't going to wait for just a bit more discussion and consensus-building on the list? ;-) The consensus is clear: allow allocations from the standard space. > Process aside, I think this is the correct approach. > >> The document also updates RFC6158 (it didn't before), and contains >> text updating the guidelines in specific sections of RFC 6158. > > Yeah. I'll take a look at that, along the lines of the question I asked in my previous post: Can allocation policy be effectively tied to guidelines review? Yes. The document does that. When the submission tool starts working again, I'll submit the draft. A "diff" view between -03 and -04 is instructive. There are a number of new sections dealing with guidelines, and more clarity WRT the IANA Considerations. The new text came about because I reviewed the document with an eye to concerns raised on this list. I realized that it didn't update RC 6158, even though it had a simple "guidelines" section. Then, it needed explicit changes to the guidelines of 6158, to make it clear that the new formats are now allowed. Then based on Bernard's suggestion, the IANA considerations section was re-worked to give very detailed description of what to do. The Guidelines section was also re-worked to have normative text reflecting the IANA allocation strategies. Over all, I think the document is more precise in what it's trying to do. Alan DeKok. From radext-bounces@ietf.org Thu Dec 29 10:17:53 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD5821F8B4B; Thu, 29 Dec 2011 10:17:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325182673; bh=+nWdA2itZKATi4BA/IaXpSWt+IzfBra2ODXV3P8dojA=; 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=jMnyG5LeUN+5oPBQiZdHQhTjmI7vHMXujN3FlMYYZ+pqU/I5rvKuPNRoyg3AIC814 u/ZG6xvecJcbgYySJgbDcTz71r/gPCFe9HParJ/Y44eU7KS962dKC7v8cjfZnh/Tjj QVaHF24kE7jJOao/kr6fvagV2X3jIwhO1KU4Tipo= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EE221F8B4B for ; Thu, 29 Dec 2011 10:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 Cf-qVk8dJ4TS for ; Thu, 29 Dec 2011 10:17:50 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 85E3C21F8B3D for ; Thu, 29 Dec 2011 10:17:50 -0800 (PST) Message-ID: <4EFCAEAE.9000206@deployingradius.com> Date: Thu, 29 Dec 2011 13:17:18 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "David B. Nelson" References: <430631100.125088.1325180931976.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> In-Reply-To: <430631100.125088.1325180931976.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> X-Enigmail-Version: 0.96.0 Cc: Bernard Aboba , radext@ietf.org, dnelson@elbrys.com, leaf y yeh Subject: Re: [radext] Status of extensions document? 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 David B. Nelson wrote: > You weren't going to wait for just a bit more discussion and consensus-building on the list? ;-) The consensus is clear: allow allocations from the standard space. > Process aside, I think this is the correct approach. > >> The document also updates RFC6158 (it didn't before), and contains >> text updating the guidelines in specific sections of RFC 6158. > > Yeah. I'll take a look at that, along the lines of the question I asked in my previous post: Can allocation policy be effectively tied to guidelines review? Yes. The document does that. When the submission tool starts working again, I'll submit the draft. A "diff" view between -03 and -04 is instructive. There are a number of new sections dealing with guidelines, and more clarity WRT the IANA Considerations. The new text came about because I reviewed the document with an eye to concerns raised on this list. I realized that it didn't update RC 6158, even though it had a simple "guidelines" section. Then, it needed explicit changes to the guidelines of 6158, to make it clear that the new formats are now allowed. Then based on Bernard's suggestion, the IANA considerations section was re-worked to give very detailed description of what to do. The Guidelines section was also re-worked to have normative text reflecting the IANA allocation strategies. Over all, I think the document is more precise in what it's trying to do. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From bernard_aboba@hotmail.com Sat Dec 31 11:35:44 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE5B21F84A1 for ; Sat, 31 Dec 2011 11:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.6 X-Spam-Level: X-Spam-Status: No, score=-100.6 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 cfi8nkN8BGgT for ; Sat, 31 Dec 2011 11:35:42 -0800 (PST) Received: from snt0-omc4-s34.snt0.hotmail.com (snt0-omc4-s34.snt0.hotmail.com [65.55.90.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9155721F84A2 for ; Sat, 31 Dec 2011 11:35:42 -0800 (PST) Received: from SNT0-EAS190 ([65.55.90.200]) by snt0-omc4-s34.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 31 Dec 2011 11:35:42 -0800 X-Originating-IP: [75.139.208.190] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: <430631100.125088.1325180931976.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> <4EFCAEAE.9000206@deployingradius.com> Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Content-Type: text/plain; charset="us-ascii" In-Reply-To: <4EFCAEAE.9000206@deployingradius.com> Date: Sat, 31 Dec 2011 11:36:31 -0800 To: Alan DeKok MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 31 Dec 2011 19:35:42.0182 (UTC) FILETIME=[61FC8060:01CCC7F3] Cc: "radext@ietf.org" , "David B. Nelson" Subject: Re: [radext] Status of extensions document? 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 Dec 2011 19:35:44 -0000 A question: shouldn't the document be Standards Track? On Dec 29, 2011, at 10:17, "Alan DeKok" wrote: > David B. Nelson wrote: >> You weren't going to wait for just a bit more discussion and consensus-bu= ilding on the list? ;-) >=20 > The consensus is clear: allow allocations from the standard space. >=20 >> Process aside, I think this is the correct approach. >>=20 >>> The document also updates RFC6158 (it didn't before), and contains >>> text updating the guidelines in specific sections of RFC 6158. >>=20 >> Yeah. I'll take a look at that, along the lines of the question I asked i= n my previous post: Can allocation policy be effectively tied to guidelines r= eview? >=20 > Yes. The document does that. >=20 > When the submission tool starts working again, I'll submit the draft. > A "diff" view between -03 and -04 is instructive. There are a number > of new sections dealing with guidelines, and more clarity WRT the IANA > Considerations. >=20 > The new text came about because I reviewed the document with an eye to > concerns raised on this list. I realized that it didn't update RC 6158, > even though it had a simple "guidelines" section. Then, it needed > explicit changes to the guidelines of 6158, to make it clear that the > new formats are now allowed. >=20 > Then based on Bernard's suggestion, the IANA considerations section > was re-worked to give very detailed description of what to do. The > Guidelines section was also re-worked to have normative text reflecting > the IANA allocation strategies. >=20 > Over all, I think the document is more precise in what it's trying to do.= >=20 > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Sat Dec 31 11:35:46 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3029521F84A2; Sat, 31 Dec 2011 11:35:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325360146; bh=NUj/ogbRgV1ygj9b6a0O6rnDBan7OoyIXNMf3//ayR0=; h=Message-ID:References:From:In-Reply-To:Date:To:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=R1qhwmG9FjnUWJHQswTUk2kTC2Gj5xSSwI5ifPMuM2PP4BM4FwLcNpf1gjFeRKX3x KNTIsViE/1Fl/uByV8oxfAZNjTkoLz3S76Kmx5b8CRgvaF5l/L/fxdklwh4wOsOuyq GF+zqGt5VLnlAsdz1OW8lvbhx9xDMRavxk8Wi/PM= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE5B21F84A1 for ; Sat, 31 Dec 2011 11:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.6 X-Spam-Level: X-Spam-Status: No, score=-100.6 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 cfi8nkN8BGgT for ; Sat, 31 Dec 2011 11:35:42 -0800 (PST) Received: from snt0-omc4-s34.snt0.hotmail.com (snt0-omc4-s34.snt0.hotmail.com [65.55.90.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9155721F84A2 for ; Sat, 31 Dec 2011 11:35:42 -0800 (PST) Received: from SNT0-EAS190 ([65.55.90.200]) by snt0-omc4-s34.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 31 Dec 2011 11:35:42 -0800 X-Originating-IP: [75.139.208.190] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: <430631100.125088.1325180931976.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> <4EFCAEAE.9000206@deployingradius.com> From: Bernard Aboba In-Reply-To: <4EFCAEAE.9000206@deployingradius.com> Date: Sat, 31 Dec 2011 11:36:31 -0800 To: Alan DeKok MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 31 Dec 2011 19:35:42.0182 (UTC) FILETIME=[61FC8060:01CCC7F3] Cc: "radext@ietf.org" , "David B. Nelson" Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org A question: shouldn't the document be Standards Track? On Dec 29, 2011, at 10:17, "Alan DeKok" wrote: > David B. Nelson wrote: >> You weren't going to wait for just a bit more discussion and consensus-building on the list? ;-) > > The consensus is clear: allow allocations from the standard space. > >> Process aside, I think this is the correct approach. >> >>> The document also updates RFC6158 (it didn't before), and contains >>> text updating the guidelines in specific sections of RFC 6158. >> >> Yeah. I'll take a look at that, along the lines of the question I asked in my previous post: Can allocation policy be effectively tied to guidelines review? > > Yes. The document does that. > > When the submission tool starts working again, I'll submit the draft. > A "diff" view between -03 and -04 is instructive. There are a number > of new sections dealing with guidelines, and more clarity WRT the IANA > Considerations. > > The new text came about because I reviewed the document with an eye to > concerns raised on this list. I realized that it didn't update RC 6158, > even though it had a simple "guidelines" section. Then, it needed > explicit changes to the guidelines of 6158, to make it clear that the > new formats are now allowed. > > Then based on Bernard's suggestion, the IANA considerations section > was re-worked to give very detailed description of what to do. The > Guidelines section was also re-worked to have normative text reflecting > the IANA allocation strategies. > > Over all, I think the document is more precise in what it's trying to do. > > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Sat Dec 31 13:26:01 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A7821F84BA for ; Sat, 31 Dec 2011 13:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYwmJHZWjZF0 for ; Sat, 31 Dec 2011 13:26:00 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 9481A21F84AC for ; Sat, 31 Dec 2011 13:26:00 -0800 (PST) Received: from thor.lan (206-248-191-1.dsl.teksavvy.com [206.248.191.1]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 9BFF712344FC; Sat, 31 Dec 2011 22:25:30 +0100 (CET) Message-ID: <4EFF7DC7.8010302@deployingradius.com> Date: Sat, 31 Dec 2011 16:25:27 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <430631100.125088.1325180931976.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> <4EFCAEAE.9000206@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "David B. Nelson" Subject: Re: [radext] Status of extensions document? 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 Dec 2011 21:26:01 -0000 Bernard Aboba wrote: > A question: shouldn't the document be Standards Track? Hmm... yes, I think. Alan DeKok. From radext-bounces@ietf.org Sat Dec 31 13:26:01 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68EBE21F84BA; Sat, 31 Dec 2011 13:26:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325366761; bh=r3RgwQ59nkTUmEF5XZ2xvcfxJGzMviF5er8dUNskIhk=; 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=dd8PGv4689bugjYgd+l6ODPWALavKFL0Cc4sN1vYJwi6/dfX8KrAH+6cALfnfkcxz EEtKpLj+xdGUVlvNyOnInbuQVzMjBJernbs7yVTeWYWPmr7Q5ymPWFU6+izmdnrE5d 2fVErXA1rWuk345viiMFigx+fvXAVaRva7JCJtCE= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A7821F84BA for ; Sat, 31 Dec 2011 13:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYwmJHZWjZF0 for ; Sat, 31 Dec 2011 13:26:00 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 9481A21F84AC for ; Sat, 31 Dec 2011 13:26:00 -0800 (PST) Received: from thor.lan (206-248-191-1.dsl.teksavvy.com [206.248.191.1]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 9BFF712344FC; Sat, 31 Dec 2011 22:25:30 +0100 (CET) Message-ID: <4EFF7DC7.8010302@deployingradius.com> Date: Sat, 31 Dec 2011 16:25:27 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <430631100.125088.1325180931976.JavaMail.root@sz0057a.westchester.pa.mail.comcast.net> <4EFCAEAE.9000206@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" , "David B. Nelson" Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Bernard Aboba wrote: > A question: shouldn't the document be Standards Track? Hmm... yes, I think. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext