From nobody Sun Nov 1 19:17:19 2015 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C05C11B2F86 for ; Sun, 1 Nov 2015 19:17:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151102031716.8539.87840.idtracker@ietfa.amsl.com> Date: Sun, 01 Nov 2015 19:17:16 -0800 From: IETF Secretariat Archived-At: Subject: [radext] Milestones changed for radext WG X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 03:17:16 -0000 Changed milestone "Dynamic Discovery I-D submitted as a Proposed Standard RFC", resolved as "Done". Changed milestone "RFC 4282bis submitted as a Proposed Standard RFC", resolved as "Done". Changed milestone "RADIUS packet fragmentation submitted as an Experimental RFC", resolved as "Done". URL: https://datatracker.ietf.org/wg/radext/charter/ From nobody Sun Nov 1 20:48:06 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1531B2A47 for ; Sun, 1 Nov 2015 20:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DZdRCe2Nr4N for ; Sun, 1 Nov 2015 20:48:02 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731C41B2A44 for ; Sun, 1 Nov 2015 20:48:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id A19172087F; Sun, 1 Nov 2015 23:45:47 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnClqgCWGQtL; Sun, 1 Nov 2015 23:45:47 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-50-136-30-120.hsd1.ma.comcast.net [50.136.30.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Sun, 1 Nov 2015 23:45:47 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E328980B6E; Sun, 1 Nov 2015 23:47:54 -0500 (EST) From: Sam Hartman To: Stefan Winter References: <065.dd4ffddd8d52391c04bbc2b328b97f76@trac.tools.ietf.org> <55D6CC73.9020002@restena.lu> <56320958.2000403@restena.lu> Date: Sun, 01 Nov 2015 23:47:54 -0500 In-Reply-To: <56320958.2000403@restena.lu> (Stefan Winter's message of "Thu, 29 Oct 2015 12:56:08 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: radext@ietf.org Subject: Re: [radext] #192 (bigger-packets): unclear meaning of "configured categories" of dynamically discovered servers X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 02 Nov 2015 04:48:04 -0000 >>>>> "Stefan" == Stefan Winter writes: Stefan> Okay... We both agree that this parameter needs to be Stefan> configurable. None of us really knows how "categories" Stefan> should be defined exactly (nor do we know what will be Stefan> useful classification criteria in the field). Stefan> I think this is something actual implementations - and their Stefan> customer demand - can and will sort out themselves. I agree with you so far. Stefan> The important bit is that it must be configurable in Stefan> principle IMHO; and that more than one global default is Stefan> something to consider for an implementation. So how about Stefan> this as a text proposal: I also think it's important that this SHOULD be configurable along with everything else that the implementation makes configurable for dynamic discovery. That is, I suspect that the market will help us decide what the categories are, but I think we know that for each category an implementation has, the implementation SHOULD make this parameter configurable. Stefan> OLD: Stefan> If dynamic discovery mechanisms are supported, configuration Stefan> SHOULD be provided for the maximum size of clients and Stefan> servers in each dynamic discovery category. Stefan> NEW: If dynamic discovery mechanisms are supported, the Stefan> default maximum packet sizes for sending packets SHOULD be Stefan> configurable. Implementations MAY choose to allow Stefan> configuration of different defaults in different parts of Stefan> their dynamic discovery configuration. Your text loses the should. I don't find the ambiguity problematic in the old text, so I prefer the old text. However, provided that the process gives my concerns a fair hearing, the new text is not something I'd object to. That is, I actively support the old text, but do not raise an objection if the new text is the result of a reasonable process. I do not yet understand your concern with the old text. It sounds at some level like you're concerned the old text is ambiguous, but neither of us seems to believe resolving that ambiguity is important. --sam From nobody Mon Nov 2 05:55:26 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C244F1B36BE for ; Mon, 2 Nov 2015 05:55:25 -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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KI6a4IDmiWn for ; Mon, 2 Nov 2015 05:55:24 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEC681B36A8 for ; Mon, 2 Nov 2015 05:55:23 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 52820374066; Mon, 2 Nov 2015 14:55:22 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.63]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 04906180053; Mon, 2 Nov 2015 14:55:19 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0248.002; Mon, 2 Nov 2015 14:55:18 +0100 From: To: "radext@ietf.org" Thread-Topic: Call for WG document adoption Thread-Index: AdEVc0QAOhnOF0wgRyief1wu4KzHcA== Date: Mon, 2 Nov 2015 13:55:17 +0000 Message-ID: <15510_1446472519_56376B47_15510_1781_1_6B7134B31289DC4FAF731D844122B36E01D52CB9@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.10.16.122716 Archived-At: Cc: Kathleen Moriarty , Stephen Farrell Subject: [radext] Call for WG document adoption X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 02 Nov 2015 13:55:25 -0000 Hi After a detailed check, it seems that I had an issue with my email account = during the summer break (and even after) and that some of my emails were no= t correctly distributed on the RADEXT mailing list. To repeat what was agreed at the last IETF meeting, the following drafts ar= e (more than) candidates as WG documents: - draft-dekok-radext-coa-proxy-00.txt - draft-winter-radext-populating-eapidentity-01 Both items are already part of the new charter. Support for both was already expressed on the mailing list and during the m= eeting. Therefore, if no concern is raised before November, Monday 7, I will (final= ly) confirm the adoption of these drafts as WG documents.=20 Sorry for this mess! Regards, Lionel ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Nov 2 10:43:51 2015 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C75171A897A; Mon, 2 Nov 2015 10:43:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151102184349.7301.58476.idtracker@ietfa.amsl.com> Date: Mon, 02 Nov 2015 10:43:49 -0800 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-datatypes-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 18:43:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS) Author : Alan DeKok Filename : draft-ietf-radext-datatypes-02.txt Pages : 37 Date : 2015-11-02 Abstract: RADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types, and have used them in attribute definitions. This document updates the specifications to better follow established practice. We do this by naming the data types defined in RFC 6158, which have been used since at least RFC 2865. We provide an IANA registry for the data types, and update the RADIUS Attribute Type registry to include a "Data Type" field for each attribute. Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-datatypes/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-radext-datatypes-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-datatypes-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 2 13:42:06 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491561A87BB for ; Mon, 2 Nov 2015 13:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bz9l80Lcy5ti for ; Mon, 2 Nov 2015 13:41:53 -0800 (PST) Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id BC2991A87C7 for ; Mon, 2 Nov 2015 13:41:53 -0800 (PST) Received: from SMURF.peterd.ws (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 2 Nov 2015 13:41:53 -0800 Date: Mon, 2 Nov 2015 13:41:53 -0800 (Pacific Standard Time) From: Peter Deacon To: lionel.morand@orange.com In-Reply-To: <15510_1446472519_56376B47_15510_1781_1_6B7134B31289DC4FAF731D844122B36E01D52CB9@OPEXCLILM43.corporate.adroot.infra.ftgroup> Message-ID: References: <15510_1446472519_56376B47_15510_1781_1_6B7134B31289DC4FAF731D844122B36E01D52CB9@OPEXCLILM43.corporate.adroot.infra.ftgroup> User-Agent: Alpine 2.20.1 (WNT 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "radext@ietf.org" , Kathleen Moriarty , Stephen Farrell Subject: Re: [radext] Call for WG document adoption X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 02 Nov 2015 21:41:57 -0000 On Mon, 2 Nov 2015, lionel.morand@orange.com wrote: > Hi > After a detailed check, it seems that I had an issue with my email > account during the summer break (and even after) and that some of my > emails were not correctly distributed on the RADEXT mailing list. > To repeat what was agreed at the last IETF meeting, the following drafts > are (more than) candidates as WG documents: > - draft-dekok-radext-coa-proxy-00.txt I do not support adoption of this draft at this time. As discussed earlier this draft fails to offer either constraints, specific mechanisms or enabling infrastructure by which sessions are protected from attack by operators of competing potentially unfriendly or compromised realms. This draft requires every participant in a roaming network to trust every other participant. I believe trust should only be required between the participant and operator of the roaming network. I do not believe trust requirements of this draft are likely to be deemed viable by operators nor are they technically necessary. regards, Peter From nobody Mon Nov 2 15:36:06 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0AE1A8AD3 for ; Mon, 2 Nov 2015 15:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhb9n25nuzBi for ; Mon, 2 Nov 2015 15:36:04 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id C16A71A9083 for ; Mon, 2 Nov 2015 15:36:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id E72D12240869; Tue, 3 Nov 2015 00:36:02 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkZNMIOu9tcl; Tue, 3 Nov 2015 00:36:02 +0100 (CET) Received: from [192.168.120.41] (unknown [64.229.221.116]) by power.freeradius.org (Postfix) with ESMTPSA id 2F95A2240652; Tue, 3 Nov 2015 00:36:02 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Alan DeKok In-Reply-To: Date: Mon, 2 Nov 2015 18:36:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <15510_1446472519_56376B47_15510_1781_1_6B7134B31289DC4FAF731D844122B36E01D52CB9@OPEXCLILM43.corporate.adroot.infra.ftgroup> To: Peter Deacon X-Mailer: Apple Mail (2.3094) Archived-At: Cc: "radext@ietf.org" Subject: [radext] CoA proxying X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 02 Nov 2015 23:36:05 -0000 On Nov 2, 2015, at 4:41 PM, Peter Deacon = wrote: >=20 > As discussed earlier this draft fails to offer either constraints, = specific mechanisms or enabling infrastructure by which sessions are = protected from attack by operators of competing potentially unfriendly = or compromised realms. Well.. no. The draft doesn't have to be perfect in order to be adopted as a WG = draft. It is perfectly fine to have WG members review the document, and = provide feedback, for document updates. > This draft requires every participant in a roaming network to trust = every other participant. And again, no. Even RFC 5176 has provisions for participants in the RADIUS = infrastructure who are not fully trusted. This draft builds on that = lack of trust. > I believe trust should only be required between the participant and = operator of the roaming network. That's nice. How do you implement it? > I do not believe trust requirements The draft doesn't make trust "requirements". It makes trade-offs, = and acknowledges the trade-offs. This is the reality of protocol = design. > of this draft are likely to be deemed viable by operators I disagree. > nor are they technically necessary. Which is an opinion. Unsupported by facts or argument. I believe that the WG would welcome suggestions which requires minimal = trust between parties, and has maximal validation. As yet, I have not = seen any concrete proposal which is better than the current draft. Alan DeKok. From nobody Mon Nov 2 16:58:12 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4355D1AC443 for ; Mon, 2 Nov 2015 16:58:11 -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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9QCZbvWllXX for ; Mon, 2 Nov 2015 16:58:09 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A181AC44D for ; Mon, 2 Nov 2015 16:58:08 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 42F0522C2A3; Tue, 3 Nov 2015 01:58:07 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.69]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 2359F35C045; Tue, 3 Nov 2015 01:58:07 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%19]) with mapi id 14.03.0248.002; Tue, 3 Nov 2015 01:58:06 +0100 From: To: Alan DeKok , Peter Deacon , "radext@ietf.org" Thread-Topic: [radext] CoA proxying Thread-Index: AQHRFcdCEUH4ylJV40OVHw38jyzlUJ6Jdhog Date: Tue, 3 Nov 2015 00:58:06 +0000 Message-ID: <2621_1446512287_5638069F_2621_799_1_6B7134B31289DC4FAF731D844122B36E01D53202@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <15510_1446472519_56376B47_15510_1781_1_6B7134B31289DC4FAF731D844122B36E01D52CB9@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.10.16.122716 Archived-At: Subject: Re: [radext] CoA proxying X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 03 Nov 2015 00:58:11 -0000 Hi, Letting out the technical points discussed here, Alan is right. The idea is not to endorse the draft as 'THE' WG solution for CoA proxing b= ut to agree on this document as a basis for future WG contribution, review,= discussion. It is NOT a WG last call before sending the document for IESG = review and RFC publication. The call for adoption is there to acknowledge that: - the draft addresses one of our work item - the draft is stable enough to initiate technical discussions on its conte= nt. The conclusion of these discussions can be: - OK with the draft as it is - OK with correction/clarification - NOK and another approach is required - No solution at all is required/possible I personally think that the ongoing discussion is a good example of what sh= ould a discussion on a WG document :) So Peter, can you reevaluate your position taking into account the clarific= ations above? Obviously, not being OK for adoption is a valid position. But= the reasons given in your mail just illustrate that some points might be m= issing or not correctly addressed in the draft but do not mean that you are= not OK to discuss this document as WG document. Regards, Lionel -----Message d'origine----- De=A0: radext [mailto:radext-bounces@ietf.org] De la part de Alan DeKok Envoy=E9=A0: mardi 3 novembre 2015 00:36 =C0=A0: Peter Deacon Cc=A0: radext@ietf.org Objet=A0: [radext] CoA proxying On Nov 2, 2015, at 4:41 PM, Peter Deacon wrote: >=20 > As discussed earlier this draft fails to offer either constraints, specif= ic mechanisms or enabling infrastructure by which sessions are protected fr= om attack by operators of competing potentially unfriendly or compromised r= ealms. Well.. no. The draft doesn't have to be perfect in order to be adopted as a WG draft= . It is perfectly fine to have WG members review the document, and provide= feedback, for document updates. > This draft requires every participant in a roaming network to trust every= other participant. And again, no. Even RFC 5176 has provisions for participants in the RADIUS infrastructur= e who are not fully trusted. This draft builds on that lack of trust. > I believe trust should only be required between the participant and oper= ator of the roaming network. That's nice. How do you implement it? > I do not believe trust requirements The draft doesn't make trust "requirements". It makes trade-offs, and a= cknowledges the trade-offs. This is the reality of protocol design. > of this draft are likely to be deemed viable by operators I disagree. > nor are they technically necessary. Which is an opinion. Unsupported by facts or argument. I believe that the WG would welcome suggestions which requires minimal tr= ust between parties, and has maximal validation. As yet, I have not seen a= ny concrete proposal which is better than the current draft. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Nov 2 19:36:03 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668671B2C2E for ; Mon, 2 Nov 2015 19:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwJ-Ra2VRJrc for ; Mon, 2 Nov 2015 19:36:00 -0800 (PST) Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id C40F81B2C29 for ; Mon, 2 Nov 2015 19:36:00 -0800 (PST) Received: from SMURF.peterd.ws (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 2 Nov 2015 19:36:00 -0800 Date: Mon, 2 Nov 2015 19:36:00 -0800 (Pacific Standard Time) From: Peter Deacon To: lionel.morand@orange.com In-Reply-To: <2621_1446512287_5638069F_2621_799_1_6B7134B31289DC4FAF731D844122B36E01D53202@OPEXCLILM43.corporate.adroot.infra.ftgroup> Message-ID: References: <15510_1446472519_56376B47_15510_1781_1_6B7134B31289DC4FAF731D844122B36E01D52CB9@OPEXCLILM43.corporate.adroot.infra.ftgroup> <2621_1446512287_5638069F_2621_799_1_6B7134B31289DC4FAF731D844122B36E01D53202@OPEXCLILM43.corporate.adroot.infra.ftgroup> User-Agent: Alpine 2.20.1 (WNT 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "radext@ietf.org" , Alan DeKok Subject: Re: [radext] CoA proxying X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 03 Nov 2015 03:36:02 -0000 On Tue, 3 Nov 2015, lionel.morand@orange.com wrote: > Letting out the technical points discussed here, Alan is right. > The idea is not to endorse the draft as 'THE' WG solution for CoA > proxing but to agree on this document as a basis for future WG > contribution, review, discussion. It is NOT a WG last call before > sending the document for IESG review and RFC publication. > The call for adoption is there to acknowledge that: > - the draft addresses one of our work item > - the draft is stable enough to initiate technical discussions on its > content. > The conclusion of these discussions can be: > - OK with the draft as it is > - OK with correction/clarification > - NOK and another approach is required > - No solution at all is required/possible > So Peter, can you reevaluate your position taking into account the > clarifications above? Obviously, not being OK for adoption is a valid > position. But the reasons given in your mail just illustrate that some > points might be missing or not correctly addressed in the draft but do > not mean that you are not OK to discuss this document as WG document. Hi Lionel, Yes, I can support adoption with correction this problem will be addressed and not ignored: Section 5: "This specification adds one new attribute, and defines new behavior for RADIUS proxying. As this behavior mirrors existing RADIUS proxying, we do not believe that it introduces any new security issues." I would hope we can all agree with the principal RealmA's nice users not needlessly suffer constant disconnects and extreme rate limiting at evil hands of RealmB. When describing problem in detail previously I offered a couple of ideas for approaches to address the problem. I would be happy to contribute text and or discuss them further if this draft is adopted. regards, Peter From nobody Fri Nov 6 17:18:54 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCB91AD1FE for ; Fri, 6 Nov 2015 17:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PuvEIa6llFk for ; Fri, 6 Nov 2015 17:18:51 -0800 (PST) Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311D31ACE7B for ; Fri, 6 Nov 2015 17:18:50 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Date:Subject: Thread-Topic:Thread-Index:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-tituslabs-classifications-30:x-titus-version: x-tituslabs-classificationhash-30:x-titusconfig: acceptlanguage:Content-Type:MIME-Version:Return-Path; b=jxBAL7tp9nmF9nkwPXWBXPsXiTuogFVyVSsWRM90ZQcHNc2MeI+oLRJz ahigxQSLbD/FnnT9sYXiVmk3Z7Nzow6upOUfitFy7s5hFA2NDSOyrhvmZ fAvT0xHVry01regD8jmmPi5YpvopwUP67H2Fah8LzP2y80l9eesyJyONl k=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1446859131; x=1478395131; h=from:to:cc:date:subject:message-id:mime-version: content-transfer-encoding; bh=ysdt0Chn90iArnmC07HPukXZvyelooa0ohVocqzu9dk=; b=FJCMkJr5J989JVixJxE2L3ZpOgv9k2AbPzkk+7oGap8FxCJq61iWHUoZ q4g7JWlhEAQZovKVZ0ZjO6HnESfML3rrRlypOf85LARG9WEJO8kdzezPj RCP4vZAJy+1bfv36z7C4QcgB+vIR3Xey0NoGSJMquDd53+6B+2aDBqU8n I=; X-LoopCount0: from 10.175.216.250 X-IronPort-AV: E=Sophos;i="5.20,254,1444712400"; d="scan'208,217";a="861426653" From: To: Date: Sat, 7 Nov 2015 06:48:39 +0530 Thread-Topic: New Draft for RADIUS Extended Identifier Attribute Thread-Index: AdEY+eUzc+HLPdntSpegnZ5Qps2F4g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Dell;Classification=No Restrictions;Sublabels=; x-titus-version: 3.5.29.3 x-tituslabs-classificationhash-30: 0Ywc1/TmJmZP14okFmB8GNyLGuT/MQ2tENPz7BHaBKJp81hAbdYEHiLYeN0SadyvoN7ivsclKmenP6TWaMRQ0AOCpf6L8EAhRjJrwe1uyZsfEauDcj115BiOtzP0sUPs+0YPQcDyCDrmYw/ZYGS7jY1mFvm3dX/hJXpd4pLgr86LrSbfPZ6WhizgogcbpVI8t845w99a9gRD3nZhMTty+2BdjVuNWBVum7opRRlU3OOE3fo6jXYluDEPlriPSjvq x-titusconfig: 1.4APJ acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D5A6F3355F664C40AFB65BB1277D8D45043F2AFEAAMAAX7MCDC101A_" MIME-Version: 1.0 Archived-At: Cc: Sanal_Kumar_Sivarama@Dell.com Subject: [radext] New Draft for RADIUS Extended Identifier Attribute X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 07 Nov 2015 01:18:53 -0000 --_000_D5A6F3355F664C40AFB65BB1277D8D45043F2AFEAAMAAX7MCDC101A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, We have proposed a new draft for Extended Identifier Attribute. Name: draft-aravind-radext-extended-identifier-attribute Revision: 00 Title: RADIUS Extended Identifier Attribute Document date: 2015-11-07 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-aravind-radext-e= xtended-identifier-attribute-00.txt Status: https://datatracker.ietf.org/doc/draft-aravind-radext-exten= ded-identifier-attribute/ Htmlized: https://tools.ietf.org/html/draft-aravind-radext-extended-i= dentifier-attribute-00 Abstract: This document proposes solution to alleviate the limitation of limited size (8 bits) of RADIUS Identifier field by proposing a new Extended Identifier attribute. We would love to hear your reviews and comments. Thanks, S. Aravind Prasad --_000_D5A6F3355F664C40AFB65BB1277D8D45043F2AFEAAMAAX7MCDC101A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,<= o:p>

 

We have proposed a new draft for Extended Identifier Attribute.

 

Nam= e:            &= nbsp;    draft-aravind-radext-extended-identifier-attribute<= o:p>

Revision:    &nbs= p;       00

Title:          &nbs= p;         RADIUS Extended Identifi= er Attribute

Document date: &nbs= p;            2015-1= 1-07

Group:    &n= bsp;           Individual= Submission

Pages:   &= nbsp;           &nbs= p; 6

URL:    &nbs= p;       http= s://www.ietf.org/internet-drafts/draft-aravind-radext-extended-identifier-a= ttribute-00.txt

Status: &nbs= p;       https://datatr= acker.ietf.org/doc/draft-aravind-radext-extended-identifier-attribute/<= o:p>

Htmlized:    &nbs= p;  https://tools.ietf.org/html/draft-aravind-radex= t-extended-identifier-attribute-00

 

Abstract:

   This document proposes solution to allevia= te the limitation of

   lim= ited size (8 bits) of RADIUS Identifier field by proposing a new=

   Extended Identifier attribute.

 

<= o:p> 

We would love to hear your reviews= and comments.

 

Thanks,

S. Aravind Pras= ad

 

= --_000_D5A6F3355F664C40AFB65BB1277D8D45043F2AFEAAMAAX7MCDC101A_-- From nobody Mon Nov 9 06:32:21 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5801B7D24 for ; Mon, 9 Nov 2015 06:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kMkyR82R0x3 for ; Mon, 9 Nov 2015 06:32:16 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6569B1B7D22 for ; Mon, 9 Nov 2015 06:32:16 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 9E12E43AB3 for ; Mon, 9 Nov 2015 15:32:14 +0100 (CET) To: radext@ietf.org References: <065.dd4ffddd8d52391c04bbc2b328b97f76@trac.tools.ietf.org> <55D6CC73.9020002@restena.lu> <56320958.2000403@restena.lu> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 X-Enigmail-Draft-Status: N0111 Message-ID: <5640AE6E.8020207@restena.lu> Date: Mon, 9 Nov 2015 15:32:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WN1oB9SbwRLCt70WvklmFw9CI7e2Dr9wu" Archived-At: Subject: Re: [radext] #192 (bigger-packets): unclear meaning of "configured categories" of dynamically discovered servers X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 09 Nov 2015 14:32:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WN1oB9SbwRLCt70WvklmFw9CI7e2Dr9wu Content-Type: multipart/mixed; boundary="------------010502000902000801030501" This is a multi-part message in MIME format. --------------010502000902000801030501 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > Stefan> The important bit is that it must be configurable in > Stefan> principle IMHO; and that more than one global default is > Stefan> something to consider for an implementation. So how about > Stefan> this as a text proposal: >=20 > I also think it's important that this SHOULD be configurable along > with everything else that the implementation makes configurable for > dynamic discovery. > That is, I suspect that the market will help us decide what the > categories are, but I think we know that for each category an > implementation has, the implementation SHOULD make this parameter > configurable. I'm not very excited about SHOULD vs. MAY. My thinking was that since a wrong initial configured setting can be fixed with signalling (Status-Server), it's not overly important. If the SHOULD level is considered important, I absolutely don't mind the change. > Stefan> OLD: >=20 > Stefan> If dynamic discovery mechanisms are supported, configuratio= n > Stefan> SHOULD be provided for the maximum size of clients and > Stefan> servers in each dynamic discovery category. >=20 > Stefan> NEW: If dynamic discovery mechanisms are supported, the > Stefan> default maximum packet sizes for sending packets SHOULD be > Stefan> configurable. Implementations MAY choose to allow > Stefan> configuration of different defaults in different parts of > Stefan> their dynamic discovery configuration. >=20 > Your text loses the should. I don't find the ambiguity problematic in > the old text, so I prefer the old text. However, provided that the > process gives my concerns a fair hearing, the new text is not something= > I'd object to. That is, I actively support the old text, but do not > raise an objection if the new text is the result of a reasonable > process. >=20 > I do not yet understand your concern with the old text. It sounds at > some level like you're concerned the old text is ambiguous, but neither= > of us seems to believe resolving that ambiguity is important. It's probably just a matter of perception. When I read "dynamic discovery category" I expected that to mean something, while it is not a defined term at all. If I were to read this as an implementor, my only reaction to reading that would probably be "Huh? What am I supposed to do here?". The purpose of my text suggestion was merely to step back from the undefined term, and state: be flexible in your configuration defaults if you can. Greetings, Stefan Winter >=20 > --sam >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 2, avenue de l'Universit=E9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------010502000902000801030501 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------010502000902000801030501-- --WN1oB9SbwRLCt70WvklmFw9CI7e2Dr9wu 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 iQIcBAEBCgAGBQJWQK5uAAoJEMDeajWKOdxm4coP/jz4uQaxfk1l1TQIWe4ypsaQ ogSvwQqiTZuMr+WZIrybNxPnhSIVF0iKFY6uTOdHr1r5xCKITMuXQ74UnZe3e5Vi cIZPwHKUiNNGweXeB8mw1vt0eitWDaFjs73YDz+hTllUy7WKgV4GnLeEtxMRLWFz /xvUC7HgtGjNXyTXQffhjkwcB6Y5hDCVKzcwdKXwgGc7aDmR0VcUdHAe2QkbG2Fn wuEBY327feVU68/XgNgVgOtQPBxs9kP4IhoDLkeT+4jYPIPAK6cWDbh2zuz8jDCL b2CYDTW/0tdMP++x6S9yCNioV1ZWPMXfEup/xnFcUdFHb53PmDy7WHz5KEycMqsA UchdeNXVh4ay67MydOkDh5E98dEVwSuS+eCY/VFDUkrz8zk+hNT/xFMs4CqkahPa 79GOjndXUHdRriqS1aE+VJHEpkdk1OQkUvnz0vOuanjaXWu7bRjxWvBmLQzFMuTC i5N7iWR8KHKmFoUdEpQp13lTut5xYNhfIls18oCTg6HIQ+I+wV13PasgGKjWfkvH yKf10y/MX3mszsZQ6mnX5x/qo4VWbLXMISgzhQHfa5aUucNPHGCcgyVkslUzXQ8y 1hiadZQ/LcfHXaomSNg9GFUD01dAjEGPisQDD9tKsD7DNTiwajq0HigfFr8Y8t9S Wlee/slwHIF25UBBa5Sz =49DY -----END PGP SIGNATURE----- --WN1oB9SbwRLCt70WvklmFw9CI7e2Dr9wu-- From nobody Mon Nov 9 06:37:50 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39711B7D5E for ; Mon, 9 Nov 2015 06:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A_JEb48NHXhG for ; Mon, 9 Nov 2015 06:37:46 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5321B7D59 for ; Mon, 9 Nov 2015 06:37:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 1C3DB20891; Mon, 9 Nov 2015 09:35:13 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZtJUQcqVl1b; Mon, 9 Nov 2015 09:35:12 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 9 Nov 2015 09:35:12 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F3228831B8; Mon, 9 Nov 2015 09:37:44 -0500 (EST) From: Sam Hartman To: Stefan Winter References: <065.dd4ffddd8d52391c04bbc2b328b97f76@trac.tools.ietf.org> <55D6CC73.9020002@restena.lu> <56320958.2000403@restena.lu> <5640AE6E.8020207@restena.lu> Date: Mon, 09 Nov 2015 09:37:44 -0500 In-Reply-To: <5640AE6E.8020207@restena.lu> (Stefan Winter's message of "Mon, 9 Nov 2015 15:32:14 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: radext@ietf.org Subject: Re: [radext] #192 (bigger-packets): unclear meaning of "configured categories" of dynamically discovered servers X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 09 Nov 2015 14:37:50 -0000 OK, I get it and would definitely be happy with your text using SHOULD instead of MAY, and agree that's more clear. Thanks for working with me to understand your concern. was the sense of the room last Tuesday compatible with me going forward, making that change and resubmitting? (Plus the nit you called out and #196, and possibly one or two other things I'll go check outstanding issues) From nobody Mon Nov 9 06:46:17 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530481B7D8E for ; Mon, 9 Nov 2015 06:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrfToP2yRuZB for ; Mon, 9 Nov 2015 06:46:14 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E191B7D80 for ; Mon, 9 Nov 2015 06:46:13 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 47FBA40CA5 for ; Mon, 9 Nov 2015 15:46:12 +0100 (CET) To: radext@ietf.org References: <065.dd4ffddd8d52391c04bbc2b328b97f76@trac.tools.ietf.org> <55D6CC73.9020002@restena.lu> <56320958.2000403@restena.lu> <5640AE6E.8020207@restena.lu> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 X-Enigmail-Draft-Status: N1111 Message-ID: <5640B1B4.50801@restena.lu> Date: Mon, 9 Nov 2015 15:46:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HJSBMCLSK20mihKg3bITu0XCkg1MO7tVx" Archived-At: Subject: Re: [radext] #192 (bigger-packets): unclear meaning of "configured categories" of dynamically discovered servers X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 09 Nov 2015 14:46:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HJSBMCLSK20mihKg3bITu0XCkg1MO7tVx Content-Type: multipart/mixed; boundary="------------090400040104000703000506" This is a multi-part message in MIME format. --------------090400040104000703000506 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > OK, I get it and would definitely be happy with your text using SHOULD > instead of MAY, and agree that's more clear. > Thanks for working with me to understand your concern. >=20 > was the sense of the room last Tuesday compatible with me going forward= , > making that change and resubmitting? > (Plus the nit you called out and #196, and possibly one or two other > things I'll go check outstanding issues) #196 (2-octet integer for Response-Length) as brought up - the Design Guidelines states that the draft SHOULD use an unsigned 32 Bit integer instead. The text change here, the Response-Length one, aong with the nits sorts out pretty much all outstanding issues. And I am not obsessed with #191 - IETF-wide review can flag this if it is seen as important by non-me persons. So, with the items above fixed in a new rev, we should be good to go! Greetings, Stefan --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 2, avenue de l'Universit=E9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------090400040104000703000506 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------090400040104000703000506-- --HJSBMCLSK20mihKg3bITu0XCkg1MO7tVx 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 iQIcBAEBCgAGBQJWQLG0AAoJEMDeajWKOdxmQ+MP/3XO9gIa8RXuf5LxLlKtpqOD GSO8UMQBN185shnhgcxZN0NdWmTnACe15ZMiNKQwvGNdrelkpYZ5hcKB562TyvA+ w9DMu74+Izp4OFE3UA8nFYkfdCWiwMobVYMsg0ANChvd+vFRVDpzBJL32X8kEMK0 d+Ssaz8vClPyerORmI2zHihIqURSqdRQYRz/I3OxMzeXx/TYEI3BqB1IT4GgkIeI 6vz+0jyLRhHt4aKCoklcpmn1gFkQkxIE9jtEVvqvqtA5+cXwK0xr0FC2dsJ1c0Pt wm6o26/EHZKn0AUlkXsTWLbvaCF2ERmXh4IkD5TDfGCAwhR92saU3Icyom359IUn rW3nQbpnBVyDJGRwZiPuAygQN4d4OlP4rYmUxQgTl8PnmCODnltTk25ROtSHWBe1 2jG36RXF/i4PTMPlLE+LCN4R2PbAxx7Vaks+CCHWVRBWoVjAkDgmw/bDgQ0xN+cw eNwwnHyVTuj3mwC5hred2d6XmxJVDwY+MlIcLPaqQ+DF+bB0tFWMEoM2W1EKklER wLftHWChMAUAO9v6oZUgS2NeMsHcXMkT5ZpaCY/G89rpkSpWw+/+xYXwfklJCFSp yrVX4CPImC2PR5J2Zs7K1vmBk6Yj5WwMJegPlYmZaHlzYG1spV87tU/dJ/38v4Q7 E9AXMcHhVBBnSkgMVNJH =wKYQ -----END PGP SIGNATURE----- --HJSBMCLSK20mihKg3bITu0XCkg1MO7tVx-- From nobody Tue Nov 10 22:01:07 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233711AD33F for ; Tue, 10 Nov 2015 22:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oy8O6wxL5LgZ for ; Tue, 10 Nov 2015 22:01:02 -0800 (PST) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE06D1AD272 for ; Tue, 10 Nov 2015 22:01:01 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 7C8DDC06B3; Wed, 11 Nov 2015 07:01:00 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 603D21A005F; Wed, 11 Nov 2015 07:01:00 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0248.002; Wed, 11 Nov 2015 07:01:00 +0100 From: To: "radext@ietf.org" Thread-Topic: Notes from radext 94 Thread-Index: AQHRHA/nHYvFWnZCXkqmVA/zAYRl6J6WVAmA Date: Wed, 11 Nov 2015 06:00:59 +0000 Message-ID: <22756_1447221660_5642D99C_22756_16129_1_6B7134B31289DC4FAF731D844122B36E01D65E25@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <56427E3D.1020102@nostrum.com> In-Reply-To: <56427E3D.1020102@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/mixed; boundary="_002_6B7134B31289DC4FAF731D844122B36E01D65E25OPEXCLILM43corp_" MIME-Version: 1.0 Archived-At: Cc: "A. Jean Mahoney" Subject: Re: [radext] Notes from radext 94 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 11 Nov 2015 06:01:05 -0000 --_002_6B7134B31289DC4FAF731D844122B36E01D65E25OPEXCLILM43corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIHRvIEplYW4gZm9yIGhlciBoZWxwZnVsIG1pbnV0ZXMuDQoNCkxpb25lbA0KDQotLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IEEuIEplYW4gTWFob25leSBbbWFpbHRvOm1h aG9uZXlAbm9zdHJ1bS5jb21dIA0KRW52b3nDqcKgOiBtZXJjcmVkaSAxMSBub3ZlbWJyZSAyMDE1 IDAwOjMxDQrDgMKgOiBNT1JBTkQgTGlvbmVsIElNVC9PTE4NCk9iamV0wqA6IE5vdGVzIGZyb20g cmFkZXh0IDk0DQoNCkhpIExpb25lbCwNCg0KTXkgbm90ZXMgYXJlIGF0dGFjaGVkOg0KDQpUaGFu a3MhDQoNCkplYW4NCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZp bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBv dSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2Ug cGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKRnJhbmNlIFRlbGVjb20gLSBP cmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFs dGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kKClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0 cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3JpemF0aW9uLgpJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBzaGFsbCBub3QgYmUgbGlhYmxl IGlmIHRoaXMgbWVzc2FnZSB3YXMgbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFu ayB5b3UuCgo= --_002_6B7134B31289DC4FAF731D844122B36E01D65E25OPEXCLILM43corp_ Content-Type: text/plain; name="IETF94-radext-minutes.txt" Content-Description: IETF94-radext-minutes.txt Content-Disposition: attachment; filename="IETF94-radext-minutes.txt"; size=11142; creation-date="Wed, 11 Nov 2015 05:58:37 GMT"; modification-date="Wed, 11 Nov 2015 05:58:38 GMT" Content-Transfer-Encoding: base64 cmFkZXh0IDk0DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CjE0OjAwIC0gMTQ6MDUsIFByZWxpbWluYXJpZXMgKDUgbWludXRlcykNClByZXNlbnRlcjogTGlv bmVsIE1vcmFuZA0KUHJlc2VudGF0aW9uOiBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5n cy85NC9zbGlkZXMvc2xpZGVzLTk0LXJhZGV4dC0wLnBkZg0KDQpOb3RlIFRha2VyczogQW8gS29i YXlhc2hpLCBKZWFuIE1haG9uZXkNCkphYmJlciBzY3JpYmU6IEplYW4gTWFob25leQ0KDQpzbGlk ZSAxOiBUaXRsZQ0KDQpzbGlkZSAyOiBOb3RlIFdlbGwNCg0Kc2xpZGUgMzogQWdlbmRhIDEvMiAN Cg0KTGlvbmVsIC0gU2FtIGlzIG5vdCBhdmFpbGFibGUgdG8gcHJlc2VudCB0aGUgYmlnZ2VyLXBh Y2tldHMgZHJhZnQuIA0KDQpzbGlkZSA0OiBBZ2VuZGEgMi8yDQoNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KMTQ6MDUgLSAxNDoxMCwgV0cgRG9jdW1lbnQg U3RhdHVzICg1IG1pbnV0ZXMpDQpQcmVzZW50ZXI6IExpb25lbCBNb3JhbmQNClByZXNlbnRhdGlv bjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTQvc2xpZGVzL3NsaWRlcy05NC1y YWRleHQtMC5wZGYNCiAgICAgICAgICANCiogZHJhZnQtaWV0Zi1yYWRleHQtZHluYW1pYy1kaXNj b3ZlcnkgICAgICAgICAgIC0tPiBSRkMgNzU4NQ0KKiBkcmFmdC1pZXRmLXJhZGV4dC1iaWdnZXIt cGFja2V0cy0wNCAgICAgICAgICAgLS0+IFdhaXRpbmcgZm9yIFdyaXRlLVVwIChFeHBlcmltZW50 YWwpDQoqIGRyYWZ0LWlldGYtcmFkZXh0LWRhdGF0eXBlcy0wMSAgICAgICAgICAgICAgICAtLT4g SW4gV0cgLS0+IFdHTEM/DQoqIGRyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4dC0w NiAgICAgICAtLT4gV2FpdGluZyBmb3IgV3JpdGUtVXAgKFN0YW5kYXJkKQ0KDQpzbGlkZSA1OiBX RyBTdGF0dXMgVXBkYXRlICgxLzIpDQoNCkxpb25lbCAtIGJ1bmRsaW5nIGF1dGhvcnMgZGlkbid0 IHJlcXVlc3QgbXRnIHRpbWUuIENhbiBiZSBkaXNjdXNzZWQgb24gTUwuIA0KDQpzbGlkZSA2OiBX RyBTdGF0dXMgVXBkYXRlICgyLzIpIA0KDQpMaW9uZWwgLSBiaWdnZXItcGFja2V0cyAtIFdHIGNv bnNlbnN1cywgd2FpdGluZyBmb3IgU3RlcGhhbidzIHdyaXRldXAuIEFsbW9zdCByZWFkeSBmb3Ig SUVTRyBzdWJtaXNzaW9uLiANCg0KcG9ydC1yYWRpdXMtZXh0IC0gZmluaXNoIHVwIHdyaXRldXAg YWZ0ZXIgdGhpcyBtZWV0aW5nLiANCg0KTmVlZCBtb3JlIHJldmlld3Mgb24gZGF0YXR5cGVzLg0K DQpwcm94eSBkb2MgLSBsYXN0IG1lZXRpbmcsIGl0IHdhcyBkZWNpZGVkIHRoYXQgaXQgd291bGQg YmVjb21lIGFuIHJhZGV4dCBkb2N1bWVudCwgYnV0IG5ldmVyIHNlbnQgdG8gdGhlIHdnIE1MLiBU aGVyZSdzIGEgZGlzY3Vzc2lvbiB3aXRoIHBldGVyIGRlYWNvbiwNCg0KZWFwaWRlbnRpdHkgLSBu ZWVkIHRvIGNvbmZpcm0gb24gbWFpbGluZy4gDQoNCkplYW4gTWFob25leSBmb3IgQWxhbiBkZUtv ayBpbiB0aGUgSmFiYmVyIFJvb20gLSB0aGUgQ09BIGRvY3VtZW50IGhhcyBleHBpcmVkLCB3b3Jr aW5nIG9uIGFuIHVwZGF0ZSB0aGF0IHNob3VsZCBiZSBvdXQgdGhpcyB3ZWVrLiAgDQoNCnNsaWRl IDc6ICBXRyBTdGF0dXMgVXBkYXRlICgyLzIpDQoNCnNsaWRlIDg6IEVycmF0YSBvbiBSRkMgMjg2 Ng0KDQpMaW9uZWwgLSBvbiBnb2luZyBkaXNjdXNzaW9uIHdpdGggU3RlZmFuLiBEb24ndCBrbm93 IGlmIGl0J3MgdmVyaWZpZWQgb3IgdG8gYmUgcmVjb25zaWRlcmVkIGJhc2VkIG9uIGRpc2N1c3Np b24uIA0KDQpKZWFuIGZvciBTdGVmYW4gV2ludGVyIC0gVmVyaWZpZWQgaXMgb2sgd2l0aCBtZS4g DQoNCnNsaWRlIDk6IE1pbGVzdG9uZXMNCg0Kc2xpZGUgMTA6IFdHIERyYWZ0cyBEaXNjdXNzaW9u DQoNCnNsaWRlIDExOiBJbmRpdmlkdWFsIERyYWZ0cyBEaXNjdXNzaW9uDQoNCiAgICAgICAgICAN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCjE0OjEwIC0gMTQ6 MjAgUkFESVVTIERhdGEgVHlwZXMNClByZXNlbnRlcjogQWxhbiBEZUtvaw0KUHJlc2VudGF0aW9u OiBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85NC9zbGlkZXMvc2xpZGVzLTk0LXJh ZGV4dC0xLnBkZg0KRHJhZnQ6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtcmFkZXh0LWRhdGF0eXBlcy8NCg0Kc2xpZGUgMTogVGl0bGUNCg0Kc2xpZGUgMjogRGF0 YSBUeXBlcw0KDQpzbGlkZSAzOiBEaXNjdXNzaW9uPw0KDQpBbGFuIC0gVGhlcmUgYXJlIDIwMCBk YXRhIHR5cGVzIHRoYXQgbmVlZCB0byBiZSB2ZXJpZmllZC4gTmVlZCB0byB2YWxpZGF0ZSB0aGUg ZGF0YSB0eXBlIGlzIHRoZSBjb3JyZWN0IG9uIGluIHRoZSBvcmlnaW5hbCBSRkMgc2luY2Ugc29t ZSBvZiB0aGUgUkZDcyBhcmUgc2lsZW50IG9yIGFtYmlndW91cyBvbiB0aGVtLiANCg0KTGlvbmVs IC0gdGhlIHJldmlldyBjYW4gYmUgZG9uZSBpbiBhIFdHTEMuIFdlIGNhbiBzcGxpdCB0aGUgZGF0 YSB0eXBlcyAtIDIwIHRvIG9uZSwgMjAgdG8gdGhlIG90aGVyLiANCg0KQUNUSU9OOiBEYXRhIHR5 cGUgdmFsaWRhdGlvbiB0byBiZSBzcGxpdCBhbW9uZyByZXZpZXdlcnMsIGVhY2ggdGFraW5nIG9u IDIwIG9yIHNvLiANCiAgICAgICAgICANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCjE0OjIwIC0gMTQ6MzAgQmlnZ2VyIFBhY2tldHMsIFNhbS9TdGVmYW4gKDEw IG1pbnV0ZXMpDQpkcmFmdDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1yYWRleHQtYmlnZ2VyLXBhY2tldHMvDQpQcmVzZW50ZXI6IE4vQQ0KUHJlc2VudGF0aW9u OiBOL0ENCg0KTGlvbmVsIC0gU2FtIGNhbid0IG1ha2UgaXQuIA0KDQpKZWFuIGZvciBTdGVmYW4g aW4gdGhlIEphYmJlciByb29tIC0gVGhlIG1haW4gaXNzdWUgcmlnaHQgbm93IChyYWlzZWQgYnkg QWxhbikgaXMgdGhlIHVzZSBvZiAyLW9jdGV0IGludGVnZXIgdnMuIHVuc2lnbmVkIDMyLWJpdCBp bnRlZ2VyIGFzIHBlciBkYXRhLXR5cGVzIGZvciB0aGUgbWF4IGZyYWdtZW50IGxlbmd0aC4gRXZl biB0aG91Z2ggZGF0YXR5cGVzIGlzIG5vdCBhbiBSRkMgeWV0LCB0aGVyZSBzZWVtcyB0byBiZSBi cm9hZCBjb25zZW5zdXMgdG8gcmUtdXNlIGV4aXN0aW5nIHR5cGVzLCBzbyBhIGNoYW5nZSB0b3dh cmRzIHVuc2lnbmVkIDMyLWJpdCBpbnRlZ2VyIGlzIHByb2JhYmx5IHRoZSByaWdodCB0aGluZz8N Cg0KQWxhbiAtIHllcy4gUkZDIDY5MjkgZm9yYmlkcyB0aGUgdXNlIG9mIG5ldyBub24tc3RhbmRh cmQgaW50ZWdlciB0eXBlcy4gVGhlcmUncyBubyBwdXJwb3NlIGZvciBpdCB0byBiZSAxNiBiaXRz LiBUaGF0IGNhbiBiZSBhIHJlc3RyaWN0aW9uIC0gaWYgeW91IHNlZSBzb21ldGhpbmcgb3ZlciAx NiBiaXRzLCBpZ25vcmUgYW5kIHRyZWF0IGl0IGFzIG5vbi1leGlzdGVudC4gSSBoYXZlbid0IHNl ZW4gZmVlZGJhY2sgZnJvbSBTYW0uIA0KDQpMaW9uZWwgLSB3ZSBjYW4gcmVhY2ggYW4gYWdyZWVt ZW50IG9uIHRoZSBNTC4gU3RlZmFuIHdpbGwgZGVjaWRlIHdoZW4gdGhlIGRyYWZ0IHdpbGwgYmUg c2VudCB0byBBRCByZXZpZXcuDQoNCkFDVElPTjogUmVhY2ggYWdyZWVtZW50IG9uIHRoZSBtYWls aW5nIGxpc3Qgb24gdXNpbmcgcmVhbCBpbnRlZ2VyIGZvciBtYXggZnJhZ21lbnQgbGVuZ3RoLiAN CiAgICAgICAgICANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CjE0OjMwIC0gMTQ6NTAgUkZDMzU4MC9SRkMyODY2IElzc3VlcyBhbmQgcHJvcG9zZWQgZml4ZXMN ClByZXNlbnRlcjogQWxhbiBEZUtvaw0KUHJlc2VudGF0aW9uOiBodHRwczovL3d3dy5pZXRmLm9y Zy9wcm9jZWVkaW5ncy85NC9zbGlkZXMvc2xpZGVzLTk0LXJhZGV4dC0yLnBkZg0KDQoNCnNsaWRl IDE6IFRpdGxlDQoNCnNsaWRlIDI6IE9wZW4gSXNzdWVzDQoNCkFsYW4gLSBJIGFkZGVkIDQ1Njkg b24gTVMtQ0hBUC1NUFBFLUtleXMsIEJlbm9pdCByZWplY3RlZCBpdCBmb3IgbWFueSByZWFzb25z LiANCg0Kc2xpZGUgMzogTVMtQ0hBUC1NUFBFLUtleXMNCg0Kc2xpZGUgNDogTVMtQ0hBUC1NUFBF LUtleXMgDQoNCkFsYW4gLSBEbyB3ZSB3YW50IHRvIGFkZHJlc3MgdGhpcyBhcyBhbiBlcnJhdGEg c28gdGhhdCB0aGUgcmVhZGVycyBrbm93IGhvdyB0byBpbXBsZW1lbnQgcHJvcGVybHkgb3IgZGVj aWRlIHRoYXQgbW9zdCBwZW9wbGUgaGF2ZSBmaWd1cmVkIG91dCB3aGF0IHRvIGRvPw0KDQpKaW0g U2NoYWFkIC0gSXQncyBteSB1bmRlcnN0YW5kaW5nIHRoYXQgTVMtQ0hBUCBpcyBub3QgY29uc2lk ZXJlZCBzZWN1cmUuDQoNCkFsYW4gLSBkbyB3ZSB3ZSB3YW50IHRvIGV4cGxhaW4gaG93IHRvIGlt cGxlbWVudCBvciBkbyB3ZSB3YW50IHBlb3BsZSB0byBydW4gaGVhZCBsb25nIGludG8gYSB3YWxs IGFuZCBmYWxsIGRvd24gdHdpdGNoaW5nPw0KDQpKaW0gLSBUaGF0IGxhdHRlciBtaWdodCBiZSB0 aGUgYmVzdCBhbnN3ZXIgaW4gdGhpcyBjYXNlLiANCg0Kc2xpZGUgNTogQWNjdC1TZXNzaW9uLUlE DQoNCkplYW4gZm9yIFN0ZWZhbiAtIGlzIE1TLUNIQVAtTVBQRS1LZXlzIGFsd2F5cyAyNCBvY3Rl dHM/DQoNCkFsYW4gLSBjYW4gYmUgOCBvY3RldHMgb2YgMCBmb2xsb3dlZCBieSBzb21lIHN0dWZm LCBtYWtpbmcgaXQgcHJvYmxlbWF0aWMuIA0KDQpzbGlkZSA2OiBBY2N0LVNlc3Npb24tSUQNCg0K c2xpZGUgNzogQSBQcm9wb3NhbA0KDQpzbGlkZSA4OiBEaXNjdXNzaW9uDQoNCkxpbnVzIE5vcmRi ZXJnIC0gYSBxdWVzdGlvbiAtIGlzIGl0IGNvcnJlY3QuLi4uDQoNCkFsYW4gLSBObywgaXQncyBp bXBsaWVkIHRvIGJlIGEgdG9rZW4gYXNzb2NpYXRlZCB3aXRoIHVzZXIgc2Vzc2lvbi4gSXQncyB2 YWxpZCB0byBzZW5kIHRoZSBzYW1lIEFjY3QtU2Vzc2lvbi1JZCBmb3IgZXZlcnkgdXNlciBzZXNz aW9uLiBUaGUgaW50ZW50IGlzIHRvIHJlcXVpcmUgdGhlIE5BUyB0byBjcmVhdGUgZ29vZCB2YWx1 ZXMgdG8gdW5pcXVlbHkgaWRlbnRpZnkgdGhlIHVzZXIgc2Vzc2lvbi4gDQoNCkxpbnVzIC0gYXJl IHdlIGFkZGluZyBzb21ldGhpbmcgdG8gbWFrZSBpdCB1bmlxdWU/DQoNCkFsYW4gLSBJIHdvdWxk IGNvbnNpZGVyIG9ic2VydmVycyBvZiBuZXR3b3JrIHRyYWZmaWMgYXMgZGlmZmVyZW50IGZyb20g Y29uc3VtZXJzIG9mIG5ldHdvcmsgdHJhZmZpYy4gSWYgeW91IGFyZSBjb25jZXJuZWQgYWJvdXQg b2JzZXJ2ZXJzIC0gdXNlIFRMUywgSVBTZWMuIFRoZSBSQURJVVMgc2VjdXJpdHkgaXMgYmFkIGVu b3VnaCB0aGVyZSdzIG5vIGV4Y3VzZSBmb3Igc2VuZGluZyBSQURJVVMgcGFja2V0cyBpbiB0aGUg Y2xlYXIuDQoNCkxpbnVzIC0gSSBhZ3JlZSBhYm91dCBwcm90ZWN0aW5nIHRoZSBjb250ZW50cy4g QnV0IGlmIHdlIGFkZCBhIHdheSB0byB0cmFjayBhIHVzZXIgYWNyb3NzIG5ldHdvcmtzIHRoYXQg d2Fzbid0IHRoZXJlIGJlZm9yZSwgZGVwbG95bWVudHMgd291bGQgaGF2ZSB0byBjaGFuZ2UgdG8g YW5vdGhlciBwcm90b2NvbC4NCg0KQWxhbiAtIEkgZG9uJ3QgdGhpbmsgd2UncmUgY3JlYXRpbmcg YW55dGhpbmcgbmV3LiBJdCdzIGp1c3QgYSBiYWQgaWRlYSBmb3Igc2Vzc2lvbiBpZGVudGlmaWVy cyB0byBiZSB0aGUgc2FtZSBmb3IgbXVsdGlwbGUgc2Vzc2lvbnMuIA0KDQpMaW9uZWwgLSAuLi4N Cg0KQWxhbiAtIHRoZSBrZXkgaXMgdGhhdCB0aGUgc2Vzc2lvbiBpZGVudGlmaWVyIGhhcyBubyBt ZWFuaW5nLiBZb3UgY2FuIHNlbmQgRW5nbGlzaCB3b3JkcyBpZiB5b3Ugd2FudC4gSWYgdGhleSB2 YWd1ZWx5IGlkZW50aWZ5IGEgc2Vzc2lvbiB0aGF0J3Mgb2suIFRoZXkgc2hvdWxkIG1vcmUgc3Ry b25nbHkgaWRlbnRpZnkgYSBzZXNzaW9uLiBXaGVuIGEgTkFTIGNyZWF0ZXMgb25lLCBpdCBzaG91 bGQgdXNlIGEgYmV0dGVyIG1ldGhvZC4gTm90aGluZyBlbHNlIHNob3VsZCBjaGFuZ2UuIA0KDQpz bGlkZSA5OiBRdWVzdGlvbg0KDQpMaW9uZWwgLSBvbiBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGlz c3VlcywgYW55IE5BUyBub3QgY29tcGx5aW5nIHdpbGwgbm90IGJlIGNvbXBsaWFudCB3aXRoIHRo ZSBSRkMuIFRoZSBzZXNzaW9uIG5lZWRzIHRvIGJlIGdsb2JhbGx5IHVuaXF1ZS4gMzU4MCAtIHdo ZW4geW91IHVzZSB0aGlzLCB5b3UgbWF5IGhhdmUgYWRkaXRpb25hbCByZXF1aXJlbWVudCBhbmQg eW91IGNhbiBhZGQgdGhpcy4gSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIHVwZGF0ZSB0aGUgUkZD LiBUaGVyZSdzIG5vIHJlY29tbWVuZGF0aW9uIG9uIGhvdyB0byBoYXZlIGEgZ2xvYmFsbHkgdW5p cXVlIHNlc3Npb24gaWQuIE1heWJlIHdlIGNhbiBwcm92aWRlIGEgcmVjb21tZW5kYXRpb24uDQoN CkFsYW4gLSBzb3VuZCBmaW5lLiANCg0KTGlvbmVsIC0gbWF5YmUgaGF2ZSBhIGRyYWZ0LCBhbmQg bm90IHVwZGF0ZSBSRkMgMjg2Ni4gSSdsbCBkb3VibGUgY2hlY2sgMzU4MC4gSWYgeW91IGhhdmUg ZnVydGhlciBjb25zdHJhaW50cyBvbiB0aGUgQVZQLi4uICANCg0KQWxhbiAtIHNvdW5kcyBvay4g DQoNCnNsaWRlIDEwOiBBY2N0LVN0YXR1cy1UeXBlDQoNCnNsaWRlIDExOiBBY2N0LVN0YXR1cy1U eXBlIA0KDQpMaW9uZWwgLSBUaGUgRGVzaWduYXRlZCBleHBlcnQgaXMgQmVybmFyZCwgd2hvIGlz IHdhaXRpbmcgb24gdGhlIG91dHB1dCBvZiB0aGlzIGRpc2N1c3Npb24uIEkgdW5kZXJzdGFuZCB0 aGUgY2xhcmlmaWNhdGlvbiwgYnV0IHRoZXJlJ3Mgbm8gbm90aW9uIG9mIHN1YnN5c3RlbSBpbiBS RkMyODY2LiBNYXliZSBwdXQgdGhlIGluZm8gc29tZXdoZXJlIGVsc2U/IEl0J3MganVzdCByZWx5 aW5nIG9uIGhvdyB0aGUgTkFTIGlzIGltcGxlbWVudGVkLiANCg0KQWxhbiAtIEFuIGlzc3VlIHRo YXQgaGFzbid0IGJlZW4gYWRkcmVzc2VkIGlzIHRoZSBwcml2YWN5IG9mIHRoZSB2aXNpdGVkIG5l dHdvcmssIHRoZSBJUCBhZGRyZXNzIG9mIHRoZSBOQVMgaXMgb3V0IHRoZXJlLiBIb3cgZG8geW91 IHNpZ25hbCB1cHN0cmVhbSB0aGF0IHBhcnQgb2YgbmV0d29yayB3ZW50IGRvd24vdXAuIFlvdSBk b24ndCB3YW50IHRvIHNlbmQgMTAwMHMgb2YgbWVzc2FnZXMuIFlvdSB3YW50IHRvIHNheSBzb21l IGdyb3VwIG9mIHVzZXJzIHdhcyBkaXNjb25uZWN0ZWQuIElmIHRoZSBOQVMgaXMgYSB2aXNpdGVk IG5ldHdvcmsgb3IgYSB3aXJlbGVzcyBhY2Nlc3MgcG9pbnQuIFlvdSBuZWVkIHRvIHNpZ25hbCB0 aGF0IGEgbGFyZ2Ugc3Vic2V0IG9mIHVzZXJzIGhhcyBiZWVuIGtpY2tlZCBvZmZsaW5lIHdpdGhv dXQga2lja2luZyBhbGwgb2YgdGhlbSBvZmYuIFdoYXQgZG8gd2UgbWVhbiBieSBzdWJzeXN0ZW0s IGl0J3Mgbm90IGRlZmluZWQuICANCg0KTGlvbmVsIC0gbmVlZCB0byBkaXNjdXNzIHRoZSBpbXBh Y3RzIGludHJvZHVjaW5nIHRoZSBjb25jZXB0IG9mIHRoZSBzdWJzeXN0ZW0uIFlvdSBjYW4gZXZl biBkZXNjcmliZSBpdCBhcyBncm91cCBvZiB1c2VyIEEsIGdyb3VwIG9mIHVzZXIgQi4gDQoNCkFD VElPTjogRGlzY3VzcyB0aGUgaW1wYWN0cyBvZiBpbnRyb2R1Y2luZyB0aGUgY29uY2VwdCBvZiBh IHN1YnN5c3RlbSBvbiB0aGUgbWFpbGluZyBsaXN0LiANCg0KQWxhbiAtIGxvb2tpbmcgYXQgdGhl IGN1cnJlbnQgdXNlIG9mIHRoZSBhY2N0LXN0YXR1cy10eXBlLiBUaGV5J3JlIHVzaW5nIGl0IHRo aXMgd2F5LiBJZiB3ZSBkZWZpbmUgYW4gYWNjdC1zdGF0dXMtdHlwZSwgdGhleSB3b24ndCBiZSB1 c2luZyBpdCBpbmNvcnJlY3RseSBhbnkgbW9yZS4gSW50ZW50IGlzIHRoYXQgLSBJQU5BIHNheSB0 aGVzZSB2YWx1ZXMgYXJlIHRvIGJlIGRlZmluZWQgYnkgYW4gZXhwZXJ0LCBzbyB3ZSBjYW4gZG8g dGhpcy4gVXNlIHRoaXMgcmF0aGVyIHRoYW4gYWNjb3VudGluZy1vZmYgYWNjb3VudGluZy1vbi4g DQoNCkxpb25lbCAtIElmIHdlIGFncmVlIG9uIHRoZSB2YWx1ZSBvZiBzdWJzeXN0ZW0tb2ZmLCBz dWJzeXN0ZW0tb24sIG5lZWQgdG8gZG9jdW1lbnQgdG8gY2xhcmlmeSBob3cgdG8gdXNlIHRoZSBp bmZvcm1hdGlvbiBhbmQgdGhlIGJlaGF2aW9yIG9mIHRoZSBzZXJ2ZXIgcmVjZWl2aW5nIHRoZSBp bmZvLiBUYWxrIG9uIHRoZSBNTC4gV2hhdCBleGlzdGluZyBpc3N1ZXMgd2lsbCBiZSBmaXhlZCB3 aXRoIHRoaXMuIA0KDQpBbGFuIC0gSSBwb3N0ZWQgYSB3cml0ZXVwIHRvIHRoZSBNTCBhbmQgb24g RnJlZVJBRElVUyB3ZWIgcGFnZS4gV2UgZG9uJ3QgbmVlZCBJRVRGIGNvbnNlbnN1cywgYnV0IGl0 IG5lZWRzIHRvIGJlIGRvY3VtZW50ZWQgYnkgc29tZW9uZSBzb21ld2hlcmUuIEl0IGNvdmVycyBo b3cgcGVvcGxlIGFyZSB1c2luZyBpdCByaWdodCBub3cuIElzc3VpbmcgYW4gUkZDIGlzIG5vdCB0 aGUgcmlnaHQgdGhpbmcgdG8gZG8sIHVubGVzcyB3ZSBjb3ZlciAxNS0yMCBjaGFuZ2VzIGluIHRo ZSBkb2MuIA0KDQpMaW9uZWwgLSBXZSBjYW4gZGlzY3VzcyBmdXJ0aGVyLiBEZWZpbmluZyBuZXcg dmFsdWVzIHdpdGhvdXQga25vd2luZyBob3cgdG8gdXNlIHRoZW0sIG5vdCBzbyB1c2VmdWwuIEkn bSBub3Qgc2F5aW5nIGEgbmV3IFJGQy4gV2FudCB0byBtYWtlIHN1cmUgdGhhdCBkZWZpbmluZyBu ZXcgdmFsdWUgc29sdmVzIHRoZSBwcm9ibGVtLiBXaGF0J3MgdGhlIHRyaWdnZXIgdG8gaW1wbGVt ZW50IHRoaXMgbmV3IHZhbHVlPyANCg0KQWxhbiAtIGl0J3MgY2xlYXIgdGhhdCB0aGUgdmVuZG9y cyBhcmVuJ3QgdXNpbmcgYWNjb3VudGluZy1vbiwgYWNjb3VudGluZy1vZmYgY29ycmVjdGx5LiBU aGV5IGRvbid0IHNob3cgdXAgYXQgSUVURi4gVGhleSBqdXN0IGRvIHNvbWV0aGluZyB0aGF0IHNl ZW1zIHRvIHdvcmsuIEkndmUgdGFsa2VkIHRvIGRpZmZlcmVudCB2ZW5kb3JzIGFuZCBwZW9wbGUg dXNpbmcgZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucywgSSd2ZSBkb2N1bWVudGVkIG9uIHRoZSB3 ZWJwYWdlIGhvdyBwZW9wbGUgYXJlIHVzaW5nIGl0LiANCg0KTGlvbmVsIC0gaGF2ZSBkaXNjdXNz aW9uIG9uIHRoZSBNTC4gTmVlZCBmZWVkYmFjayBmcm9tIEJlcm5hcmQgYW5kIG90aGVycy4gSSB1 bmRlcnN0YW5kIHdoYXQgeW91IGFyZSBzYXlpbmcuIEknbGwgdHJ5IHRvIGNsYXJpZnkgbXkgcG9p bnQgb24gdGhlIGxpc3QuIA0KDQpBQ1RJT046IERpc2N1c3Mgb24gdGhlIE1MIGNsYXJpZnlpbmcg aG93IHRvIHVzZSBzdWJzeXN0ZW0tb2ZmL3N1YnN5c3RlbS1vbiBhbmQgc2VydmVyIGJlaGF2aW9y IHVwb24gcmVjZWl2aW5nIHRoZSBpbmZvcm1hdGlvbi4gSWRlbnRpZnkgdGhlIGV4aXN0aW5nIGlz c3VlcyB0aGF0IHdpbGwgYmUgZml4ZWQgd2l0aCBzdWJzeXN0ZW0tb2ZmL3N1YnN5c3RlbS1vbi4g DQoNCnNsaWRlIDEyOiBDb25jbHVzaW9ucw0KDQpzbGlkZSAxMzogQ29uY2x1c2lvbnMgKDIpDQoN CkFsYW4gLSBCZXJuYXJkJ3MgZmVlZGJhY2sgLSBhbnkgY2hhbmdlcyB0byAzNTgwIHJlcXVpcmUg ZmVlZGJhY2sgZnJvbSBJRUVFLiBTZWN0aW9uIDUuNCBzYXlzIHdoZW4gdXNlZCB3aXRoIElFRUUg ODAyLjF4IGF1dGhlbnRpY2F0b3JzLCB0aGUgQWNjb3VudC1TZXNzaW9uLUlEIFNIT1VMRCBiZSB1 bmlxdWUuIEkgcHJlZmVyIHRoYXQgaXQgc2F5IE1VU1QsIG5vdCBqdXN0IGZvciAzNTgwIGFuZCBJ RUVFIG5ldHdvcmtzIGJ1dCBhbGwgbmV0d29ya3MgYW5kIHRleHQgb24gaG93IHRvIGNyZWF0ZSBh IEFjY291bnQtU2Vzc2lvbi1JRC4gSSBkb24ndCB0aGluayBBY2NvdW50LVN0YXR1cy1UeXBlIHJl cXVpcmVzIElFRUUgZmVlZGJhY2suDQoNCkxpb25lbCAtIG5lZWQgZmVlZGJhY2sgZnJvbSBJRUVF IHRvIHVwZGF0ZSB0aGUgZG9jdW1lbnQuDQoNCkRvcm90aHkgU3RhbmxleSwgSFAgLSB3aGF0IGZl ZWRiYWNrIGRvIHlvdSBuZWVkPw0KDQpBbGFuIC0gV2FudCB0byBwYXNzIHN1Z2dlc3RlZCB0ZXh0 IHRocm91Z2ggSUVFRSB0byBzZWUgaWYgaXQgd2lsbCBicmVhayBhbnl0aGluZywgb3IgaXQncyBm aW5lLiBEb2Vzbid0IG5lZWQgb2ZmaWNpYWwgZG9jdW1lbnRzLCBqdXN0IHRoYXQgSUVFRSBoYXMg cmV2aWV3ZWQgYW5kIGlzIG9rIHdpdGggdGhlbS4gIA0KDQpEb3JvdGh5IC0gbGV0IG1lIGtub3cg d2hlbiB0aGUgdXBkYXRlcyBhcmUgYXZhaWxhYmxlLiANCg0KQWxhbiAtIHVwZGF0ZXMgYXJlIG5v dCBhdmFpbGFibGUgeWV0LiANCg0KTGlvbmVsIC0gVGhlIGNvbnRlbnRzIG9mIHRoaXMgUkZDIGNv bWVzIGZyb20gSUVFRSwgY2hhbmdlcyBuZWVkIHRvIGJlIGVuZG9yc2VkIGJ5IElFRUUuIEl0J3Mg dGhlIGZpcnN0IGNsaWVudCBvZiB0aGUgc3BlYy4NCg0KRG9yb3RoeSAtIDM1ODAgaXMgZ2VuZXJh bCwgbm90IGp1c3QgSUVFRS4NCg0KTGlvbmVsIC0gaXQncyBpbmZvcm1hdGlvbmFsIFJGQyBhbmQg Y292ZXJzIGhvdyB0byB1c2UgaW4gSUVFRSBuZXR3b3JrLiANCg0KRG9yb3RoeSAtIEknbSBoYXBw eSB0byB0YWtlIGFuIHVwZGF0ZWQgZG9jIHRvIC4xMSBhbmQgZ2V0IGZlZWRiYWNrLiBDb250YWN0 IG1lIHdoZW4gdGhlIGRvY3VtZW50IGlzIHJlYWR5LiANCg0KTGlvbmVsIC0gd2UnbGwgZGlzY3Vz cyBvbiBNTC4gSSBkb24ndCBrbm93IHdoYXQgdGhlIGRvY3VtZW50IHdpbGwgYmUuIENvdWxkIGJl IGFuIFJGQyB1cGRhdGUgb3IgYSBkcmFmdC4gDQoNCkFDVElPTjogUHJvcG9zZSBBY2NvdW50LVNl c3Npb24tSUQgdGV4dCBvbiB0aGUgbWFpbGluZyBsaXN0LiBEb3JvdGh5IFN0YW5sZXkgdG8gc29s aWNpdCBJRUVFIGZlZWRiYWNrLiANCg0Kc2xpZGUgMTQ6IERpc2N1c3Npb24/DQoNCkxpb25lbCAt IG5lZWQgbW9yZSByZXZpZXdzLiANCiAgICAgICAgICANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCjEzOjU1IC0gMTQ6MDAgTmV4dCBTdGVwczogV0cgQ2hhaXJz ICYgQURzICg1IG1pbnV0ZXMpDQpQcmVzZW50ZXI6IExpb25lbCBNb3JhbmQNClByZXNlbnRhdGlv bjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTQvc2xpZGVzL3NsaWRlcy05NC1y YWRleHQtMC5wZGYNCg0KDQpzbGlkZSAxMjogTmV4dCBTdGVwDQoNCkxpb25lbCAtIE5lZWQgbW9y ZSByZXZpZXdlcnMgZm9yIFdHIGRvY3MuIA0K --_002_6B7134B31289DC4FAF731D844122B36E01D65E25OPEXCLILM43corp_-- From nobody Thu Nov 12 10:04:41 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EDD1B2BD7 for ; Thu, 12 Nov 2015 10:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnuim8JiW4MK for ; Thu, 12 Nov 2015 10:04:34 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68D811B2BD3 for ; Thu, 12 Nov 2015 10:04:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9415; q=dns/txt; s=iport; t=1447351474; x=1448561074; h=from:to:cc:subject:date:message-id:mime-version; bh=p00oguXg0JfurvuJ6PDWDLjbyK8D0eiDsFRfRGfLnIY=; b=ZH0TJka9ONfR5NWnFp4A1/0vkPxQctwUv952T3DB+CmFPPzY+Dl78mys N4K/1HwkYzHe+XiNj7Lh7OjU7fqS+bsQcPWAmSJJWnAg80+NKaWsfkUgt C5iLZ86ymKN8MLSQl7OFbPsL13mcmshXWLfDVECmvegZE0FxylbAFEz10 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQA/1ERW/4QNJK1egm5NU28GvB+CG?= =?us-ascii?q?gENgWUjhW2BQDgUAQEBAQEBAYEKhDQBAgQtTBIBCBEDAQIoORQJCgQBDQUbiBM?= =?us-ascii?q?NxAQBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZUhH6ENDQTDYQxBY0bhUyDYQGFH?= =?us-ascii?q?IgKgVuWeINxAR8BAUKEBHIBg3JDgQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,282,1444694400"; d="scan'208,217";a="207129752" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Nov 2015 18:04:33 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tACI4XfC031242 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Nov 2015 18:04:33 GMT Received: from xch-rcd-002.cisco.com (173.37.102.12) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 12 Nov 2015 12:04:33 -0600 Received: from xch-rcd-002.cisco.com ([173.37.102.12]) by XCH-RCD-002.cisco.com ([173.37.102.12]) with mapi id 15.00.1104.000; Thu, 12 Nov 2015 12:04:32 -0600 From: "Satyanarayana Danda (sdanda)" To: "Aravind_Sridharan@Dell.com" , "radext@ietf.org" Thread-Topic: [radext] New Draft for RADIUS Extended Identifier Attribute Thread-Index: AQHRHXSVww+01Sb8CkC3dbre/zmVxQ== Date: Thu, 12 Nov 2015 18:04:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.35.209] Content-Type: multipart/alternative; boundary="_000_D26AD16956F7Dsdandaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Sanal_Kumar_Sivarama@Dell.com" Subject: Re: [radext] New Draft for RADIUS Extended Identifier Attribute X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 12 Nov 2015 18:04:36 -0000 --_000_D26AD16956F7Dsdandaciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Most of the efficient implementations would have Identifier as one of the k= eys for Request/Response match lookup. With this new AVP 1. have you thought about any performance considerations? 2. In the TLV buffer, do you suggest the position of the new AVP? if so = are we breaking any existing recommendation of the TLV positions? Thanks Satya From: "Aravind_Sridharan@Dell.com" > Date: Saturday, 7 November 2015 6:48 am To: "radext@ietf.org" > Cc: "Sanal_Kumar_Sivarama@Dell.com" <= Sanal_Kumar_Sivarama@Dell.com> Subject: [radext] New Draft for RADIUS Extended Identifier Attribute Hi All, We have proposed a new draft for Extended Identifier Attribute. Name: draft-aravind-radext-extended-identifier-attribute Revision: 00 Title: RADIUS Extended Identifier Attribute Document date: 2015-11-07 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-aravind-radext-e= xtended-identifier-attribute-00.txt Status: https://datatracker.ietf.org/doc/draft-aravind-radext-exten= ded-identifier-attribute/ Htmlized: https://tools.ietf.org/html/draft-aravind-radext-extended-i= dentifier-attribute-00 Abstract: This document proposes solution to alleviate the limitation of limited size (8 bits) of RADIUS Identifier field by proposing a new Extended Identifier attribute. We would love to hear your reviews and comments. Thanks, S. Aravind Prasad --_000_D26AD16956F7Dsdandaciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <246E03361460604196A0C38FB64932FA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Most of the efficient implementations would have Identifier as one of = the keys for Request/Response match lookup.

With this new AVP

  1. have you thought about any performance considerations?
  2. In the T= LV buffer, do you suggest the position of the new AVP? if so are we breakin= g any existing recommendation of the TLV positions?
Thanks
Satya

From: "Aravind_Sridharan@Dell.com" <Aravind_Sridharan@Dell.com>
Date: Saturday, 7 November 2015 6:4= 8 am
To: "radext@ietf.org" <= radext@ietf.org>
Cc: "Sanal_Kumar_Sivarama@Dell.com" <Sanal_Kumar_Sivarama@Dell.com= >
Subject: [radext] New Draft for RAD= IUS Extended Identifier Attribute

Hi All,

 

We have proposed a new draft for Extended Identifier= Attribute.

 

Name:       &n= bsp;         draft-aravind-radext-e= xtended-identifier-attribute

Revision:      &nbs= p;     00

Title:       &= nbsp;            RAD= IUS Extended Identifier Attribute

Document date:      = ;        2015-11-07

Group:       &= nbsp;        Individual Submission<= /o:p>

Pages:       &= nbsp;         6

URL:       &nb= sp;    https://www.ietf.org/internet-drafts/draft-aravind-radext-extended-identifi= er-attribute-00.txt

Status:       =   https://datatracker.ietf.org/doc/draft-aravind-radext-extended-identifier-a= ttribute/

Htmlized:       https://tools.ietf.org/html/draft-aravind-radext-extended-identifier-attrib= ute-00

 

Abstract:

   This document proposes solution to a= lleviate the limitation of

   limited size (8 bits) of RADIUS Iden= tifier field by proposing a new

   Extended Identifier attribute.<= /o:p>

 

 

We would love to hear your reviews and comments.

 

Thanks,

S. Aravind Prasad

 

 --_000_D26AD16956F7Dsdandaciscocom_-- From nobody Thu Nov 12 12:13:18 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16EC31B347B for ; Thu, 12 Nov 2015 12:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQ0hTnr4UCqr for ; Thu, 12 Nov 2015 12:13:15 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0821B3476 for ; Thu, 12 Nov 2015 12:13:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 611AD2240901; Thu, 12 Nov 2015 21:12:44 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgEMSSqetHl2; Thu, 12 Nov 2015 21:12:44 +0100 (CET) Received: from [192.168.120.41] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by power.freeradius.org (Postfix) with ESMTPSA id 9B56022408F5; Thu, 12 Nov 2015 21:12:43 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Alan DeKok In-Reply-To: Date: Thu, 12 Nov 2015 15:12:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9A9ADD39-3F54-4FE3-8A43-4F47C7BC6B11@deployingradius.com> References: To: "Satyanarayana Danda (sdanda)" X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "Aravind_Sridharan@Dell.com" , "radext@ietf.org" , "Sanal_Kumar_Sivarama@Dell.com" Subject: Re: [radext] New Draft for RADIUS Extended Identifier Attribute X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 12 Nov 2015 20:13:17 -0000 It's easy to say "extend the identifier space." It's hard to work = through all of the use-cases, so that we're *sure* it works. Right now, the draft proposes an idea. That's nice. The idea has = been discussed off and on for a long time. I suggest that the draft propose a *solution*. Explain how the = extended identifier will work in practice. Where it works, where it = doesn't work, and how to tell the two situations apart. Alan DeKok. From nobody Mon Nov 16 21:53:41 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082531B2A25 for ; Mon, 16 Nov 2015 21:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhcXmwr1dM4A for ; Mon, 16 Nov 2015 21:53:37 -0800 (PST) Received: from ausxipps310.us.dell.com (AUSXIPPS310.us.dell.com [143.166.148.211]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D907F1B2A26 for ; Mon, 16 Nov 2015 21:53:36 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Date:Subject: Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator: x-tituslabs-classifications-30:x-titus-version: x-tituslabs-classificationhash-30:x-titusconfig: acceptlanguage:Content-Type:MIME-Version:Return-Path; b=B7VDaK0Dr1vNKHUOyH9zsRN18t0Wz9xqXhccV9l2h9Msib9pWhXSoles TPR+ckid9if6+R9jM2Y+nc847xU5QicE3FwpMyiF6RoQWb8zNYZ02PCyc IJjqNreMcWrIvfyC9yKAahdSDXG3bqCemXWHdGn4ivYVBmBYnycTeb6+x g=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1447739616; x=1479275616; h=from:to:cc:date:subject:message-id:references: in-reply-to:mime-version:content-transfer-encoding; bh=AuXTCvDIv681X21TNG4YyQFO2EC5Ad2Vo+lzkRoctTQ=; b=HAy/t27hKvrIC70UU3g9VkqcKhVZ0cif3pyMAhRkAjX8trplS/otLwjW 7TqZd4R85Fq0f/L8qrrHwH2f3IrWofqpq16SFzjhbmcFmlZNjzrBDXkTG dWOpfc29ky3JD2AF6b3GsEUwFPmwqtq4l1ol/8jn2ucfNza9nS00AGBtL o=; X-LoopCount0: from 10.175.216.249 X-IronPort-AV: E=Sophos;i="5.20,306,1444712400"; d="scan'208,217";a="252483036" From: To: , , Date: Tue, 17 Nov 2015 11:23:29 +0530 Thread-Topic: [radext] New Draft for RADIUS Extended Identifier Attribute Thread-Index: AdEdhoHU1SIJn9mWRsyt8CVV3CvEXQDdMzZg Message-ID: References: <9A9ADD39-3F54-4FE3-8A43-4F47C7BC6B11@deployingradius.com> In-Reply-To: <9A9ADD39-3F54-4FE3-8A43-4F47C7BC6B11@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Dell;Classification=No Restrictions;Sublabels=; x-titus-version: 3.5.29.3 x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Iq9nBwmvpQc0FJRNE2DD9Puq7ugTBx3sYS+jr4MbKpqvzZAcGtj5rxjyspKB4nMNTbTRKTOOctah0SF/YaMMoCzbJmKfhabUEyK6WqvYOZ4ZsxPbV9Q9TuM3YlEoF2OHPcphJZxlKzo868TIGXOM8L21dPRbV8Pb5NJdtID2M6OrXUPILOQk+rMlQiukQ/yn5vf4jpuUtSckcx8chkMeTsQwDLt7t2q1uy5EKDixw/YhDYF/XmLZASD8zoQj+BwIsw== x-titusconfig: 1.4APJ acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D5A6F3355F664C40AFB65BB1277D8D45043FFE693EMAAX7MCDC101A_" MIME-Version: 1.0 Archived-At: Cc: radext@ietf.org, Sanal_Kumar_Sivarama@Dell.com Subject: Re: [radext] New Draft for RADIUS Extended Identifier Attribute X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 17 Nov 2015 05:53:40 -0000 --_000_D5A6F3355F664C40AFB65BB1277D8D45043FFE693EMAAX7MCDC101A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter/Satyanarayana/Alan, Thanks a lot for your review comments and sorry for the delay in response. Hi Peter, >> Have you thought about how compatibility would work with proxy servers? >> RADIUS Client --> RADIUS Proxy A --> RADIUS Server >> For example what happens in the scenario where Client and RADIUS Server = support Extended identifier however Proxy A does not? >> RADIUS Client sends an Access-Request containing Extended-Identifier to = Proxy A. >> Proxy A does not understand Extended-Identifier and forwards the entire = Access-Request including Extended-Identifier to RADIUS Server. >> RADIUS Server gets request and incorrectly processes Extended-Identifier= as if it was generated by Proxy A even though it was generated by RADIUS C= lient and is completely invalid in the scope of >> communication between Proxy A and RADIUS Server. Here is the flow as per the proposal. 1. RADIUS Client --> RADIUS Proxy A --> RADIUS Server 2. RADIUS Client sends an Access-Request containing both ID (in the m= essage) and External-Identifier attribute to Proxy A. 3. Proxy A doesn't understand External-Identifier attribute and forwa= rds the Access-Request to RADIUS Server. 4. RADIUS server gets the request and responds back with same ID (in = the message) and External-Identifier attribute. Please note that both the I= Ds are in the response. a. If RADIUS server doesn't understand External-Identifier attribute,= then only the ID of message header will be in the response. 5. Proxy A gets the response and send to Client. 6. In case client needs to send subsequent Access-Request message, th= at also will have both ID and External-Identifier attribute with different = values. The proposal introduces External-Identifier attribute along with ID. If the= Radius server has the External-Identifier attribute support, then we will = get the benefit of extended ID length. Otherwise, will work like today. We realize that there is a possibility of misinterpreting some of the terms= that we used in the draft. We will correct in the subsequent version. Hi Satyanarayana/Alan, Thanks for your views and comments. We will comeback with results and solut= ions in sometime soon. Thanks, S. Aravind Prasad -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Friday, November 13, 2015 1:43 AM To: Satyanarayana Danda (sdanda) Cc: Sridharan, Aravind; radext@ietf.org; Sivarama, Sanal Kumar Subject: Re: [radext] New Draft for RADIUS Extended Identifier Attribute It's easy to say "extend the identifier space." It's hard to work through a= ll of the use-cases, so that we're *sure* it works. Right now, the draft proposes an idea. That's nice. The idea has been discu= ssed off and on for a long time. I suggest that the draft propose a *solution*. Explain how the extended ide= ntifier will work in practice. Where it works, where it doesn't work, and h= ow to tell the two situations apart. Alan DeKok. --_000_D5A6F3355F664C40AFB65BB1277D8D45043FFE693EMAAX7MCDC101A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peter= /Satyanarayana/Alan,

 

Thanks a lot for your review comments and sorry for = the delay in response.

 

Hi Peter,

 

>> Have you thought about how = compatibility would work with proxy servers?
>> RADIUS Client --&g= t; RADIUS Proxy A --> RADIUS Server
>> For example what happens= in the scenario where Client and RADIUS Server support Extended identifier= however Proxy A does not?
>> RADIUS Client sends an Access-Reques= t containing Extended-Identifier to Proxy A.
>> Proxy A does not u= nderstand Extended-Identifier and forwards the entire Access-Request includ= ing Extended-Identifier to RADIUS Server.
>> RADIUS Server gets re= quest and incorrectly processes Extended-Identifier as if it was generated = by Proxy A even though it was generated by RADIUS Client and is completely = invalid in the scope of

>> commun= ication between Proxy A and RADIUS Server.

 

Here is the flow as per the pr= oposal.

 

1.       RADIUS Client à R= ADIUS Proxy A à RADIUS = Server

2.    = ;   RADIUS Client sends an Access-Request= containing both ID (in the message) and External-Identifier attribute to P= roxy A.

3.   &nb= sp;   Proxy A doesn’t understand Ex= ternal-Identifier attribute and forwards the Access-Request to RADIUS Serve= r.

4.    &nb= sp;  RADIUS server gets the request and respon= ds back with same ID (in the message) and External-Identifier attribute. Pl= ease note that both the IDs are in the response.

a.       <= /span>If RADIUS server doesn’t understand External-I= dentifier attribute, then only the ID of message header will be in the resp= onse.

5.    =    Proxy A gets the response and send to = Client.

6.   &nb= sp;   In case client needs to send subseq= uent Access-Request message, that also will have both ID and External-Ident= ifier attribute with different values.

<= o:p> 

The proposal introduces External-I= dentifier attribute along with ID. If the Radius server has the External-Id= entifier attribute support, then we will get the benefit of extended ID len= gth. Otherwise, will work like today.

We= realize that there is a possibility of misinterpreting some of the terms t= hat we used in the draft. We will correct in the subsequent version.

 

Hi S= atyanarayana/Alan,

 

Thanks for your views and comments. We will comeback = with results and solutions in sometime soon.

 

 

 

Thanks,=

S. Aravind Prasad

-----Original M= essage-----
From: Alan DeKok [mailto:aland@deployingradius.com]
Sent= : Friday, November 13, 2015 1:43 AM
To: Satyanarayana Danda (sdanda)
= Cc: Sridharan, Aravind; radext@ietf.org; Sivarama, Sanal Kumar
Subject: = Re: [radext] New Draft for RADIUS Extended Identifier Attribute

It's= easy to say "extend the identifier space." It's hard to work thr= ough all of the use-cases, so that we're *sure* it works.

Right now,= the draft proposes an idea. That's nice. The idea has been discussed off a= nd on for a long time.

I suggest that the draft propose a *solution*= . Explain how the extended identifier will work in practice. Where it works= , where it doesn't work, and how to tell the two situations apart.

A= lan DeKok.

= --_000_D5A6F3355F664C40AFB65BB1277D8D45043FFE693EMAAX7MCDC101A_--