From nobody Wed Jan 6 01:21:14 2016 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 A90B01ACDD8; Wed, 6 Jan 2016 01:21:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160106092111.26332.77836.idtracker@ietfa.amsl.com> Date: Wed, 06 Jan 2016 01:21:11 -0800 Archived-At: Cc: radext@ietf.org, Kathleen.Moriarty.ietf@gmail.com, radext-chairs@ietf.org, stefan.winter@restena.lu Subject: [radext] radext - New Meeting Session Request for IETF 95 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: Wed, 06 Jan 2016 09:21:11 -0000 A new meeting session request has just been submitted by Stefan Winter, a Chair of the radext working group. --------------------------------------------------------- Working Group Name: RADIUS EXTensions Area Name: Operations and Management Area Session Requester: Stefan Winter Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: First Priority: mif dime 6man v6ops dmm abfab oauth saag Second Priority: spring sfc rtcweb 6lo netext ace httpauth mile ipsecme Special Requests: --------------------------------------------------------- From nobody Mon Jan 11 07:50:37 2016 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 B54661A1B5C; Mon, 11 Jan 2016 07:50:35 -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.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160111155035.28140.74572.idtracker@ietfa.amsl.com> Date: Mon, 11 Jan 2016 07:50:35 -0800 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-coa-proxy-00.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, 11 Jan 2016 15:50:35 -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 : Dynamic Authorization Proxying in Remote Authorization Dial-In User Service Protocol (RADIUS) Authors : Alan DeKok Jouni Korhonen Filename : draft-ietf-radext-coa-proxy-00.txt Pages : 15 Date : 2016-01-11 Abstract: RFC 5176 defines Change of Authorization (CoA) and Disconnect Message (DM) behavior for RADIUS. Section 3.1 of that document suggests that proxying these messages is possible, but gives no guidance as to how that is done. This specification corrects that omission. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-coa-proxy/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-radext-coa-proxy-00 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 Jan 11 11:54:02 2016 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 C1AD91A90A6 for ; Mon, 11 Jan 2016 11:54:00 -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 NuOzDxadhl7Q for ; Mon, 11 Jan 2016 11:53:58 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1211A90A2 for ; Mon, 11 Jan 2016 11:53:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id E1169179C for ; Mon, 11 Jan 2016 19:53:57 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnz3yuQEEHLw for ; Mon, 11 Jan 2016 19:53:57 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 862437A8 for ; Mon, 11 Jan 2016 19:53:57 +0000 (UTC) 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: <20160111155035.28140.74572.idtracker@ietfa.amsl.com> Date: Mon, 11 Jan 2016 14:53:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <105833FD-4E43-42C4-9964-20FD966E85AA@deployingradius.com> References: <20160111155035.28140.74572.idtracker@ietfa.amsl.com> To: radext@ietf.org X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: Re: [radext] I-D Action: draft-ietf-radext-coa-proxy-00.txt 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, 11 Jan 2016 19:54:00 -0000 Please review and comment. To do list: - update Jouni's contact (sorry) - discuss / clarify Peter's comments > On Jan 11, 2016, at 10:50 AM, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : Dynamic Authorization Proxying in Remote = Authorization Dial-In User Service Protocol (RADIUS) > Authors : Alan DeKok > Jouni Korhonen > Filename : draft-ietf-radext-coa-proxy-00.txt > Pages : 15 > Date : 2016-01-11 >=20 > Abstract: > RFC 5176 defines Change of Authorization (CoA) and Disconnect = Message > (DM) behavior for RADIUS. Section 3.1 of that document suggests = that > proxying these messages is possible, but gives no guidance as to how > that is done. This specification corrects that omission. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-radext-coa-proxy/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-radext-coa-proxy-00 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Fri Jan 15 07:15:11 2016 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 D9B6A1B2ECE for ; Fri, 15 Jan 2016 07:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, 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 7gr2_b_VNwy2 for ; Fri, 15 Jan 2016 07:15:08 -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 38C8D1B2D29 for ; Fri, 15 Jan 2016 07:15:08 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 95DC543AA0 for ; Fri, 15 Jan 2016 16:15:06 +0100 (CET) To: "radext@ietf.org" 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: <56990CFA.9010309@restena.lu> Date: Fri, 15 Jan 2016 16:15:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0MbKTiTNERfuPuVU5sBRvbHgI25W4tfIH" Archived-At: Subject: [radext] Start of WGLC for draft-ietf-radext-datatypes-02 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: Fri, 15 Jan 2016 15:15:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0MbKTiTNERfuPuVU5sBRvbHgI25W4tfIH Content-Type: multipart/mixed; boundary="------------050901010008000507070901" This is a multi-part message in MIME format. --------------050901010008000507070901 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, this draft has been out for a while now, and did not receive further comments. The document has also previously received significant scrutiny when it was an individual submission. Also, other drafts depend on this o= ne. The author has requested a Working Group Last Call, and I believe the document is ready for that. This email officially starts the WGLC which lasts two weeks from now. The document is at https://www.ietf.org/id/draft-ietf-radext-datatypes-02.txt . Please send your comments and issues with the draft to the mailing list until 2016-01-29 2400 UTC. In addition, following the strategy for promoting compliance with the IPR disclosure rules (RFC6702), the chairs would like to check whether there are claims of Intellectual Property Rights (IPR) on the document that need to be disclosed. Therefore, the following questions are addressed to the WG and Especially Authors and Contributors of the draft:= Are you personally aware of any IPR that applies to draft-ietf-radext-datatypes-02 ? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) If you are a document author or listed contributor on this document, please reply to this email message regardless of whether or not you are personally aware of any relevant IPR. We might not be able to advance this document to the next stage until we have received a reply from each author and listed contributor. If you are on the RADEXT WG email list but are not an author or listed contributor for this document, you are reminded of your opportunity for a voluntary IPR disclosure under BCP 79. Please do not reply unless you want to make such a voluntary disclosure. Online tools for filing IPR disclosures can be found at . Regards, Lionel & Stefan --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 2, avenue de l'Universit=C3=A9 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 --------------050901010008000507070901 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----- --------------050901010008000507070901-- --0MbKTiTNERfuPuVU5sBRvbHgI25W4tfIH 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 iQIcBAEBCgAGBQJWmQz7AAoJEMDeajWKOdxmar4QAM6PLl8nX+pbEroQ/BOu2v6U evym7MUDWaeZAFI+sq3x3+rny70hFWgV4YizRK3ru/3IhxZWjVVk3VETAAxQHyRH 7a741cRgvd9XfDLM2aqlxloY5RDfGEOevhvYG+9ETX2a3IPfh0UtTcnwqGQMRkUX TWht/R9YSAeUxvxbxmiypGx10VM1++a9YyD8CTKO4bT6F7FNmSUPAqOFaRb1+5fu XxKBdqJLZHPw98eAYEZoj/80PN8g5Mmcm34T/czxtjTeA1vP1vhN2aSVwwTaU0N8 z/74aWCr1w+bmBSMCVI7VZ8E3Snwnud3jr9G71UWJj4b870gNCG9QrgTTIroi4yA ZMTowRrcmXRf27XfpYK10SvoDevAhCxAgbP6ur9ZcnY0pxHmTwMnLgfAqnzftwUB KGER4lJ0OPn8pAl2JZDFpqbYuG3sVBI2taJ/JqmQ8ahyrBLK2mZn/7pUc1mfZmsC vPn3rqINV53LT4UaymBe6PeEAGyrCA5/8DMeS4kABux0L+8At5cXF3YuVbM9CQQH X9LdBsQZ1Vycp7Ecxsv7do7f9bFGwEGzn14Ni5tal51o/8PHYfQBB/DtokaPBwyf DWpCBqblowHyTXGY2uwxOoFInijvPv7tqyuOoJjR9fF8hKt1tOtAWVzEXFStUB8W snJLNwywoxuOS0THl8T2 =PImP -----END PGP SIGNATURE----- --0MbKTiTNERfuPuVU5sBRvbHgI25W4tfIH-- From nobody Fri Jan 15 07:48:27 2016 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 498B81B2F5A for ; Fri, 15 Jan 2016 07:48:26 -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 GscXU_qmsC9b for ; Fri, 15 Jan 2016 07:48:24 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id A591C1B2F59 for ; Fri, 15 Jan 2016 07:48:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id E403D13D6; Fri, 15 Jan 2016 15:48:23 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJMtIsx0YDGI; Fri, 15 Jan 2016 15:48:23 +0000 (UTC) Received: from [192.168.20.69] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 75CBA36B; Fri, 15 Jan 2016 15:48:23 +0000 (UTC) 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: <56990CFA.9010309@restena.lu> Date: Fri, 15 Jan 2016 10:48:20 -0500 Content-Transfer-Encoding: 7bit Message-Id: <095CDEAA-7A91-42FF-8A23-A431F36DFAF5@deployingradius.com> References: <56990CFA.9010309@restena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Start of WGLC for draft-ietf-radext-datatypes-02 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: Fri, 15 Jan 2016 15:48:26 -0000 On Jan 15, 2016, at 10:15 AM, Stefan Winter wrote: > Are you personally aware of any IPR that applies to > draft-ietf-radext-datatypes-02 ? If so, has this IPR been disclosed in > compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 > for more details.) I am not aware of any IPR on this document. Alan DeKok. From nobody Sun Jan 17 18:55:24 2016 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 949F61ACD97 for ; Sun, 17 Jan 2016 18:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, 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 jO8J_eK2mkNU for ; Sun, 17 Jan 2016 18:55:16 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0733.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:733]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862631ACD96 for ; Sun, 17 Jan 2016 18:55:16 -0800 (PST) Received: from BLUPR05MB516.namprd05.prod.outlook.com (10.141.29.153) by BLUPR05MB515.namprd05.prod.outlook.com (10.141.29.146) with Microsoft SMTP Server (TLS) id 15.1.365.19; Mon, 18 Jan 2016 02:54:55 +0000 Received: from BLUPR05MB516.namprd05.prod.outlook.com ([169.254.4.128]) by BLUPR05MB516.namprd05.prod.outlook.com ([169.254.4.128]) with mapi id 15.01.0365.024; Mon, 18 Jan 2016 02:54:55 +0000 From: Sunil Gandhewar To: "radext@ietf.org" Thread-Topic: Reporting the Authorization Result back to the RADIUS Thread-Index: AdFRmStSf7GVE5zxSZ2tjzu6pMzL/w== Date: Mon, 18 Jan 2016 02:54:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sgandhewar@juniper.net; x-originating-ip: [116.197.184.14] x-microsoft-exchange-diagnostics: 1; BLUPR05MB515; 5:G9IBFittBRZheGaHXeHSr7w4Gedkw/RhORZ/1auNhGziaQJtrrd+7BCLkNnxLuTUIA40WLA6S0IX284JRRpKFtbk695XwQkrudekMzt9+GSMLDmUIEJ38L7HgI6J8zw8J/hPocel8w/ygVAkUbGjCw==; 24:AWz1xVo+wpCBeEaQmyzAUP0Z1tN7Bzwa5FP8iI5u3yoABtq0s19y2EEhgHRZhhcGMjL7dnXmejm5gYAot5MvGRLfL1p9EYXpKE6SBnQQRb0= x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42139001); SRVR:BLUPR05MB515; x-ms-office365-filtering-correlation-id: c0faad82-7ad2-4a6f-d47b-08d31fb2bef6 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001); SRVR:BLUPR05MB515; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB515; x-forefront-prvs: 08252193F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(107886002)(450100001)(81156007)(101416001)(106356001)(110136002)(33656002)(5003600100002)(4326007)(5008740100001)(5001960100002)(3846002)(6116002)(5004730100002)(2906002)(19580405001)(97736004)(19580395003)(76576001)(15975445007)(189998001)(5002640100001)(1730700002)(86362001)(4001430100002)(10400500002)(50986999)(87936001)(2501003)(2900100001)(102836003)(229853001)(11100500001)(54356999)(122556002)(92566002)(586003)(1096002)(105586002)(2351001)(74316001)(99286002)(66066001)(40100003)(1220700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB515; H:BLUPR05MB516.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BLUPR05MB5160613175D20A4A5269C04C2C00BLUPR05MB516namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2016 02:54:55.4115 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB515 Archived-At: Cc: Sunil Gandhewar Subject: [radext] Reporting the Authorization Result back to the RADIUS 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, 18 Jan 2016 02:55:22 -0000 --_000_BLUPR05MB5160613175D20A4A5269C04C2C00BLUPR05MB516namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, When a subscriber logs in after getting authenticated, it sends list of ser= vices at login time via Access-Accept. Due to some reason, if one of the se= rvices is failed to be applied, NAS cannot apply any of these services and = RADIUS has no way to know the Result of the authorization. This Result is n= eeded in many cases especially for extending RADIUS services outside. Currently one either relies on Accounting START message. It gets complicate= d when either Accounting server is at remote location or when accounting is= not enabled. Some send services to be provisioned via CoA instead of at login time throu= gh Access-Accept. That way it knows the Result via CoA-ACK/NAK. The problem becomes more prominent with RFC 7499 where RADIUS packet needs = to be fragments and as per RFC 7499 it asks to piggyback on pull mechanism = via login time. I am wondering if it makes sense to write a new draft in RADEXT for adding = new attribute to report result of the authorization. RADIUS can include thi= s attribute in Access-Accept which indicate NAS that it needs to send the r= esult to the RADIUS. On applying services result can be sent to the RADIUS = by Access-Request and then RADIUS can respond back with Access-Accept once = it receives the result. So these 2 additional packets if RADIUS needs such = a result. If you think it makes sense to write draft, me being relatively new in IETF= , would you be interesting in co-authoring with me? Otherwise can you point= me to someoneone experienced who would co-author and help me to proceed? Regards, Sunil Gandhewar Juniper Networks, Inc. sgandhewar@juniper.net --_000_BLUPR05MB5160613175D20A4A5269C04C2C00BLUPR05MB516namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi All,
When a subscriber logs in after getting authenticated, it sends list o= f services at login time via Access-Accept. Due to some reason, if one of t= he services is failed to be applied, NAS cannot apply any of these services= and RADIUS has no way to know the Result of the authorization. This Result is needed in many cases especially= for extending RADIUS services outside.
 
Currently one either relies on Accounting START message. It gets compl= icated when either Accounting server is at remote location or when accounti= ng is not enabled.
 
Some send services to be provisioned via CoA instead of at login time = through Access-Accept. That way it knows the Result via CoA-ACK/NAK.
 
The problem becomes more prominent with RFC 7499 where RADIUS packet n= eeds to be fragments and as per RFC 7499 it asks to piggyback on pull mecha= nism via login time.
 
I am wondering if it makes sense to write a new draft in RADEXT for ad= ding new attribute to report result of the authorization. RADIUS can includ= e this attribute in Access-Accept which indicate NAS that it needs to send = the result to the RADIUS. On applying services result can be sent to the RADIUS by Access-Request and then RADIUS= can respond back with Access-Accept once it receives the result. So these = 2 additional packets if RADIUS needs such a result.
 
If you think it makes sense to write draft, me being relatively new in= IETF, would you be interesting in co-authoring with me? Otherwise can you = point me to someoneone experienced who would co-author and help me to proce= ed?
 
Regards,
Sunil Gandhewar
Juniper Networks, Inc.
 
 
 --_000_BLUPR05MB5160613175D20A4A5269C04C2C00BLUPR05MB516namprd_-- From nobody Mon Jan 18 18:03:23 2016 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 E87491A872D for ; Mon, 18 Jan 2016 18:03:21 -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 YwUtUFy-ptvb for ; Mon, 18 Jan 2016 18:03:19 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id C49151A872B for ; Mon, 18 Jan 2016 18:03:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id B90DB19F0; Tue, 19 Jan 2016 02:03:18 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mcez79keWkss; Tue, 19 Jan 2016 02:03:18 +0000 (UTC) Received: from [192.168.120.41] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by mail.networkradius.com (Postfix) with ESMTPSA id 19832CC6; Tue, 19 Jan 2016 02:03:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Mon, 18 Jan 2016 21:03:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sunil Gandhewar X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Reporting the Authorization Result back to the RADIUS 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, 19 Jan 2016 02:03:22 -0000 On Jan 17, 2016, at 9:54 PM, Sunil Gandhewar = wrote: >=20 > Hi All, > When a subscriber logs in after getting authenticated, it sends list = of services at login time via Access-Accept. Such as? There's only one Service-Type allowed. Maybe you mean = something like "set of authorization attributes". > Due to some reason, if one of the services is failed to be applied, = NAS cannot apply any of these services and RADIUS has no way to know the = Result of the authorization. This Result is needed in many cases = especially for extending RADIUS services outside. RFC 2865 Section 5.6 say: ... A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Service-Types as though an Access-Reject had been received instead. It doesn't have similar text for (e.g.) Framed-IP-Address, or for most = of the other authorization attributes. > Currently one either relies on Accounting START message. It gets = complicated when either Accounting server is at remote location or when = accounting is not enabled. Yes. If accounting isn't enabled, you have no idea whether or not the = session started. There is no way around that problem. If accounting is enabled, the authorization attributes *might* be = echoed back in the Accounting-Request packet. But there's no = requirement for the NAS to do so. > Some send services to be provisioned via CoA instead of at login time = through Access-Accept. That way it knows the Result via CoA-ACK/NAK. You mean "authorization" again here, not "services". Please use = vocabulary which is consistent with the RADIUS RFCs. > The problem becomes more prominent with RFC 7499 where RADIUS packet = needs to be fragments and as per RFC 7499 it asks to piggyback on pull = mechanism via login time. I'm not sure how it's more complicated. The only issue I see is that = the fragmented data can't be sent in an Accounting-Request. > I am wondering if it makes sense to write a new draft in RADEXT for = adding new attribute to report result of the authorization. RADIUS can = include this attribute in Access-Accept which indicate NAS that it needs = to send the result to the RADIUS. The only extensible way to ACK authorization attributes is to send = them verbatim from a NAS to a server. That would require some new = packet code, or packet exchanges. > On applying services result can be sent to the RADIUS by = Access-Request and then RADIUS can respond back with Access-Accept once = it receives the result. So these 2 additional packets if RADIUS needs = such a result. It might work. But there are attributes which can go into = Access-Accept, but aren't supposed to be in Access-Request. So any = simple echoing process is not going to work. I would suggest instead just echoing back the authorization attributes = in the Accounting-Request packet. Most NASes already do this, so it = would involve minimal changes to existing specifications and practices. = It would be worth discussing why a NAS should (or should not) do this, = and what should go into the Accounting-Request, and why. The larger question, of course, is *why* is this change necessary? = What problem does it solve? Please describe it. Alan DeKok. From nobody Tue Jan 19 04:41:41 2016 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 76D5D1B2DAE for ; Tue, 19 Jan 2016 04:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 cQqJzgOy56Zw for ; Tue, 19 Jan 2016 04:41:32 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0132.outbound.protection.outlook.com [207.46.100.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9341B2DA6 for ; Tue, 19 Jan 2016 04:41:32 -0800 (PST) Received: from BLUPR05MB516.namprd05.prod.outlook.com (10.141.29.153) by BLUPR05MB515.namprd05.prod.outlook.com (10.141.29.146) with Microsoft SMTP Server (TLS) id 15.1.365.19; Tue, 19 Jan 2016 12:41:30 +0000 Received: from BLUPR05MB516.namprd05.prod.outlook.com ([169.254.4.128]) by BLUPR05MB516.namprd05.prod.outlook.com ([169.254.4.128]) with mapi id 15.01.0365.024; Tue, 19 Jan 2016 12:41:30 +0000 From: Sunil Gandhewar To: Alan DeKok Thread-Topic: [radext] Reporting the Authorization Result back to the RADIUS Thread-Index: AdFRmStSf7GVE5zxSZ2tjzu6pMzL/wAxGP4AAA6TKlA= Date: Tue, 19 Jan 2016 12:41:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sgandhewar@juniper.net; x-originating-ip: [116.197.184.14] x-microsoft-exchange-diagnostics: 1; BLUPR05MB515; 5:jd1jjRT0ReK+7DhnpKm5yeiMnIUTg9R6MMY3v4lEJj8Wgily0F5diGsHonCLQxbZ87VM19DKv3z1E4zwQwxdb6SGgItcCyg/Ghujm5j02TEdokQGs4+ayXEneoLCQwZX9he3dl/T0ZPeK82BtzngjQ==; 24:xXk9FeS1Y1jgqyCnq1Q8StNmQKHz+tTPtwoWg7PH7EaCjrPPXX/AmhbbbTYudNgQ99MW4ZIzfBAZlmyYbUM9tbcvPLHFaN+U3QcARAN/gFM= x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42139001); SRVR:BLUPR05MB515; x-ms-office365-filtering-correlation-id: 7e174003-29fc-49c9-dd2c-08d320cddb14 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001); SRVR:BLUPR05MB515; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB515; x-forefront-prvs: 0826B2F01B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(199003)(189002)(53754006)(16064003)(377454003)(24454002)(33656002)(54356999)(102836003)(586003)(86362001)(122556002)(2900100001)(10400500002)(76176999)(4001430100002)(92566002)(11100500001)(50986999)(40100003)(1096002)(1220700001)(87936001)(66066001)(99286002)(105586002)(74316001)(6116002)(3846002)(4326007)(101416001)(81156007)(5008740100001)(2950100001)(5001960100002)(5003600100002)(107886002)(5002640100001)(76576001)(189998001)(97736004)(19580405001)(5004730100002)(110136002)(19580395003)(2906002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB515; H:BLUPR05MB516.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2016 12:41:30.1746 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB515 Archived-At: Cc: "radext@ietf.org" , Sunil Gandhewar Subject: Re: [radext] Reporting the Authorization Result back to the RADIUS 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, 19 Jan 2016 12:41:39 -0000 Thanks Alan for responding. Please see my answers inline with [SMG] Regards, Sunil M Gandhewar Juniper Networks, Inc. sgandhewar@juniper.net -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com]=20 Sent: Tuesday, January 19, 2016 7:33 AM To: Sunil Gandhewar Cc: radext@ietf.org Subject: Re: [radext] Reporting the Authorization Result back to the RADIUS On Jan 17, 2016, at 9:54 PM, Sunil Gandhewar wrote= : >=20 > Hi All, > When a subscriber logs in after getting authenticated, it sends list of s= ervices at login time via Access-Accept. Such as? There's only one Service-Type allowed. Maybe you mean somethin= g like "set of authorization attributes". [SMG] Yes, that's right. These include filter-names, policies with paramete= rs in case of dynamic subscribers. > Due to some reason, if one of the services is failed to be applied, NAS c= annot apply any of these services and RADIUS has no way to know the Result = of the authorization. This Result is needed in many cases especially for ex= tending RADIUS services outside. RFC 2865 Section 5.6 say: ... A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Service-Types as though an Access-Reject had been received instead. It doesn't have similar text for (e.g.) Framed-IP-Address, or for most of= the other authorization attributes. [SMG] Again what I meant here is authorization data e.g. could not apply a = policy or filter for some reason e.g. it was not pre-configured so does not= exist. Or even for that mater there is no way to indicate whether the sess= ion started or not. > Currently one either relies on Accounting START message. It gets complica= ted when either Accounting server is at remote location or when accounting = is not enabled. Yes. If accounting isn't enabled, you have no idea whether or not the se= ssion started. There is no way around that problem. If accounting is enabled, the authorization attributes *might* be echoed = back in the Accounting-Request packet. But there's no requirement for the = NAS to do so. > Some send services to be provisioned via CoA instead of at login time thr= ough Access-Accept. That way it knows the Result via CoA-ACK/NAK. You mean "authorization" again here, not "services". Please use vocabula= ry which is consistent with the RADIUS RFCs. [SMG] Yes, sorry about that. > The problem becomes more prominent with RFC 7499 where RADIUS packet need= s to be fragments and as per RFC 7499 it asks to piggyback on pull mechanis= m via login time. I'm not sure how it's more complicated. The only issue I see is that the= fragmented data can't be sent in an Accounting-Request. [SMG] Complicated because now the large amount of authorization data cannot= be sent in CoA-Request, it has to be sent in Access-Request, but there is = no way to report back the status of that. > I am wondering if it makes sense to write a new draft in RADEXT for addin= g new attribute to report result of the authorization. RADIUS can include t= his attribute in Access-Accept which indicate NAS that it needs to send the= result to the RADIUS. The only extensible way to ACK authorization attributes is to send them v= erbatim from a NAS to a server. That would require some new packet code, o= r packet exchanges. [SMG] New packets will work. Instead of new packet types how about, if RADI= US can add a new attribute e.g. Result with value as Result-Required. Then = NAS can send addition Access-Request with Result and Radius can respond Acc= ess-Accept with Result as Result-Received. Something of this sort, this wil= l be executed only if RADIUS requires the Result of authorization or to kno= w if the session started. > On applying services result can be sent to the RADIUS by Access-Request a= nd then RADIUS can respond back with Access-Accept once it receives the res= ult. So these 2 additional packets if RADIUS needs such a result. It might work. But there are attributes which can go into Access-Accept,= but aren't supposed to be in Access-Request. So any simple echoing proces= s is not going to work. I would suggest instead just echoing back the authorization attributes in= the Accounting-Request packet. Most NASes already do this, so it would in= volve minimal changes to existing specifications and practices. It would b= e worth discussing why a NAS should (or should not) do this, and what shoul= d go into the Accounting-Request, and why. The larger question, of course, is *why* is this change necessary? What = problem does it solve? Please describe it.[SMG]=20 [SMG] This is needed for the cases where RADIUS need to know if session sta= rt or failed and it's reason. That could be for multiple purposes e.g. to t= ake corrective action, fix the error or it could be for extending session s= ervice outside the radius to service-gateway. These service gateways may wa= nt to provide additional subscriber services based on the authorization dat= a. Alan DeKok. From nobody Tue Jan 19 06:06:59 2016 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 980011B2F21 for ; Tue, 19 Jan 2016 06:06:58 -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 xZorB7rz-zoV for ; Tue, 19 Jan 2016 06:06:56 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id B20051B2F1E for ; Tue, 19 Jan 2016 06:06:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id EEF8E13C4; Tue, 19 Jan 2016 14:06:55 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luDfwddyAhuH; Tue, 19 Jan 2016 14:06:55 +0000 (UTC) Received: from [192.168.120.41] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by mail.networkradius.com (Postfix) with ESMTPSA id 74162CC6; Tue, 19 Jan 2016 14:06:55 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Tue, 19 Jan 2016 09:06:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sunil Gandhewar X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Reporting the Authorization Result back to the RADIUS 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, 19 Jan 2016 14:06:58 -0000 On Jan 19, 2016, at 7:41 AM, Sunil Gandhewar = wrote: > [SMG] This is needed for the cases where RADIUS need to know if = session start or failed and it's reason. That's a much simpler problem statement. Right now, a server can send = an Access-Accept, and have no way of knowing whether or not the session = started. Some NASes will send an Accounting-Request packet with a session time = of zero. But there's no standardization here. I agree that would be = useful. Being able to signal *why* the session was failed by the NAS is a = separate item. As we're talking about RADIUS... the simplest possible = approach would be best. Alan DeKok. From nobody Tue Jan 19 08:23:06 2016 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 ABB331B31D8 for ; Tue, 19 Jan 2016 08:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 tfShFtbzhcVw for ; Tue, 19 Jan 2016 08:22:58 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0144.outbound.protection.outlook.com [207.46.100.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3041B31B0 for ; Tue, 19 Jan 2016 08:22:58 -0800 (PST) Received: from BLUPR05MB516.namprd05.prod.outlook.com (10.141.29.153) by BLUPR05MB513.namprd05.prod.outlook.com (10.141.29.140) with Microsoft SMTP Server (TLS) id 15.1.365.19; Tue, 19 Jan 2016 16:22:55 +0000 Received: from BLUPR05MB516.namprd05.prod.outlook.com ([169.254.4.128]) by BLUPR05MB516.namprd05.prod.outlook.com ([169.254.4.128]) with mapi id 15.01.0365.024; Tue, 19 Jan 2016 16:22:54 +0000 From: Sunil Gandhewar To: Alan DeKok Thread-Topic: [radext] Reporting the Authorization Result back to the RADIUS Thread-Index: AdFRmStSf7GVE5zxSZ2tjzu6pMzL/wAxGP4AAA6TKlAACrJ5gAAAjHYQ Date: Tue, 19 Jan 2016 16:22:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sgandhewar@juniper.net; x-originating-ip: [116.197.184.14] x-microsoft-exchange-diagnostics: 1; BLUPR05MB513; 5:vupPlgz0yX1izHsBb5gkw7/sjyLrh4J+xdiTLF67gVXbIVKtNpQQ4lCNDaGzd+9IFIG4G7X4vltpYAWMMSuM1Wx3jk5d4Gvx+daa1j6ZXeumsqK+DIP22yUBuHX7yAFwyZUu43OR1Tan9ezbRqsz8w==; 24:XMcrLJL8Yda2jSou+1ONdvPd9SAVxtDgnkm4a7xdWM4iMAFDawO/32R27qeAKt6uPJQHGN6aBZGLrmnKkJoRb9rDWGkYc/JGaS684AStgnI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB513; x-ms-office365-filtering-correlation-id: 2160ba45-a195-498c-edc7-08d320ecc91b x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:BLUPR05MB513; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB513; x-forefront-prvs: 0826B2F01B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(24454002)(377454003)(199003)(13464003)(87936001)(66066001)(3846002)(4326007)(97736004)(1220700001)(586003)(106356001)(76576001)(105586002)(19580405001)(19580395003)(1096002)(81156007)(110136002)(5008740100001)(10400500002)(6116002)(4001430100002)(74316001)(107886002)(5004730100002)(76176999)(101416001)(93886004)(122556002)(54356999)(50986999)(33656002)(102836003)(2900100001)(2906002)(99286002)(40100003)(2950100001)(86362001)(5001960100002)(189998001)(5002640100001)(92566002)(5003600100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB513; H:BLUPR05MB516.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2016 16:22:54.6857 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB513 Archived-At: Cc: "radext@ietf.org" , Sunil Gandhewar Subject: Re: [radext] Reporting the Authorization Result back to the RADIUS 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, 19 Jan 2016 16:23:04 -0000 Hi Alan, I am glad that you agree to have a standardization of the solution. With NAS sending the status time of zero, these 2 packet exchanges will alw= ays be there. It won't be based on only if RADIUS needs it. Also there will= not be a way for additional information for reason or what failed. Regards, Sunil M Gandhewar Juniper Networks, Inc. sgandhewar@juniper.net -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com]=20 Sent: Tuesday, January 19, 2016 7:37 PM To: Sunil Gandhewar Cc: radext@ietf.org Subject: Re: [radext] Reporting the Authorization Result back to the RADIUS On Jan 19, 2016, at 7:41 AM, Sunil Gandhewar wrote= : > [SMG] This is needed for the cases where RADIUS need to know if session s= tart or failed and it's reason. That's a much simpler problem statement. Right now, a server can send an= Access-Accept, and have no way of knowing whether or not the session start= ed. Some NASes will send an Accounting-Request packet with a session time of = zero. But there's no standardization here. I agree that would be useful. Being able to signal *why* the session was failed by the NAS is a separa= te item. As we're talking about RADIUS... the simplest possible approach w= ould be best. Alan DeKok. From nobody Tue Jan 19 11:08:30 2016 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 AED671B3491 for ; Tue, 19 Jan 2016 11:08:28 -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 ABYUkONU8ism for ; Tue, 19 Jan 2016 11:08:27 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id E41571B348D for ; Tue, 19 Jan 2016 11:08:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 24861D43; Tue, 19 Jan 2016 19:08:26 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRvGET3pX5tO; Tue, 19 Jan 2016 19:08:26 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id AF8FD984; Tue, 19 Jan 2016 19:08:25 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Tue, 19 Jan 2016 14:08:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <48BC614E-927F-4DF3-95E3-CFE3BFFE8D15@deployingradius.com> References: To: Sunil Gandhewar X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Reporting the Authorization Result back to the RADIUS 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, 19 Jan 2016 19:08:28 -0000 On Jan 19, 2016, at 11:22 AM, Sunil Gandhewar = wrote: > With NAS sending the status time of zero, these 2 packet exchanges = will always be there. It won't be based on only if RADIUS needs it. Also = there will not be a way for additional information for reason or what = failed. All these issues need to be discussed before anything is standardized. The two important procedural items are: - is it needed by many people? - are people willing to work on it? Alan DeKok. From nobody Tue Jan 19 16:41:55 2016 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 178621B387E for ; Tue, 19 Jan 2016 16:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 pyOoaKwdITL0 for ; Tue, 19 Jan 2016 16:41:52 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0144.outbound.protection.outlook.com [207.46.100.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3592E1B387A for ; Tue, 19 Jan 2016 16:41:51 -0800 (PST) Received: from BLUPR05MB516.namprd05.prod.outlook.com (10.141.29.153) by BLUPR05MB515.namprd05.prod.outlook.com (10.141.29.146) with Microsoft SMTP Server (TLS) id 15.1.365.19; Wed, 20 Jan 2016 00:41:48 +0000 Received: from BLUPR05MB516.namprd05.prod.outlook.com ([169.254.4.128]) by BLUPR05MB516.namprd05.prod.outlook.com ([169.254.4.128]) with mapi id 15.01.0365.024; Wed, 20 Jan 2016 00:41:48 +0000 From: Sunil Gandhewar To: Alan DeKok Thread-Topic: [radext] Reporting the Authorization Result back to the RADIUS Thread-Index: AdFRmStSf7GVE5zxSZ2tjzu6pMzL/wAxGP4AAA6TKlAACrJ5gAAAjHYQAAn7TwAAC5OLIA== Date: Wed, 20 Jan 2016 00:41:48 +0000 Message-ID: References: <48BC614E-927F-4DF3-95E3-CFE3BFFE8D15@deployingradius.com> In-Reply-To: <48BC614E-927F-4DF3-95E3-CFE3BFFE8D15@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sgandhewar@juniper.net; x-originating-ip: [116.197.184.12] x-microsoft-exchange-diagnostics: 1; BLUPR05MB515; 5:k4DH78R6+CQGBp7K9FgTvk2qiEFRukQ7aNvGlbbvbYHD6AhHPs2qRBBt3r42WDca5Jb3cBEpD5LZYUaCSC9ShWmtDv9GZfy75ISv4yezVrZiHfFy5fmeRMN+5kvo+PVAw8xftzcnrOgZoj2EFqgPfQ==; 24:R4/nkcvssjRSG0PTETDYiezHDqM5Q/9kFOvfvB9JHFS8Fox6pTC4+ZbEy7pvoFh4zYEGXewgZWUziYGCcWWfriIut6oKiT/hH2LwwbwpqjA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB515; x-ms-office365-filtering-correlation-id: aa04cdb0-a04c-4ed1-d91a-08d321327ae4 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR05MB515; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB515; x-forefront-prvs: 0827D7ACB9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(189002)(13464003)(24454002)(5003600100002)(5004730100002)(10400500002)(66066001)(50986999)(76176999)(54356999)(110136002)(107886002)(5001960100002)(4326007)(74316001)(92566002)(2906002)(2950100001)(2900100001)(189998001)(76576001)(19580395003)(33656002)(5002640100001)(6116002)(102836003)(19580405001)(3846002)(86362001)(4001430100002)(87936001)(1096002)(1220700001)(105586002)(101416001)(106356001)(97736004)(40100003)(122556002)(93886004)(5008740100001)(11100500001)(586003)(81156007)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB515; H:BLUPR05MB516.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2016 00:41:48.2179 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB515 Archived-At: Cc: "radext@ietf.org" , Sunil Gandhewar Subject: Re: [radext] Reporting the Authorization Result back to the RADIUS 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, 20 Jan 2016 00:41:54 -0000 That's right we shall discuss the issues before any standardization. What needs to be done for: > The two important procedural items are: > - is it needed by many people? > - are people willing to work on it? Regards, Sunil M Gandhewar Juniper Networks, Inc. sgandhewar@juniper.net -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com]=20 Sent: Wednesday, January 20, 2016 12:38 AM To: Sunil Gandhewar Cc: radext@ietf.org Subject: Re: [radext] Reporting the Authorization Result back to the RADIUS On Jan 19, 2016, at 11:22 AM, Sunil Gandhewar wrot= e: > With NAS sending the status time of zero, these 2 packet exchanges will a= lways be there. It won't be based on only if RADIUS needs it. Also there wi= ll not be a way for additional information for reason or what failed. All these issues need to be discussed before anything is standardized. The two important procedural items are: - is it needed by many people? - are people willing to work on it? Alan DeKok. From nobody Wed Jan 20 08:09:56 2016 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 7CC121A904C for ; Wed, 20 Jan 2016 08:09:55 -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 3YfclifpFeya for ; Wed, 20 Jan 2016 08:09:51 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 054BC1A907F for ; Wed, 20 Jan 2016 08:09:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 2C0C3771; Wed, 20 Jan 2016 16:09:50 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QXNvymHLs8R; Wed, 20 Jan 2016 16:09:50 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id A7234683; Wed, 20 Jan 2016 16:09:49 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Wed, 20 Jan 2016 11:09:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4A78F424-27E0-49B3-846B-D6FC35963E8E@deployingradius.com> References: <48BC614E-927F-4DF3-95E3-CFE3BFFE8D15@deployingradius.com> To: Sunil Gandhewar X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Reporting the Authorization Result back to the RADIUS 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, 20 Jan 2016 16:09:55 -0000 You need to convince people here that it's important. How you do that = is up to you. On Jan 19, 2016, at 7:41 PM, Sunil Gandhewar = wrote: >=20 > That's right we shall discuss the issues before any standardization. >=20 > What needs to be done for: >> The two important procedural items are: >> - is it needed by many people? >> - are people willing to work on it?