From nobody Fri Oct 3 00:45:24 2014 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 181BD1ACFFB; Fri, 3 Oct 2014 00:45:23 -0700 (PDT) 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 Pv09qkfw2fm2; Fri, 3 Oct 2014 00:45:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 994011ACFE5; Fri, 3 Oct 2014 00:45:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141003074521.3609.3254.idtracker@ietfa.amsl.com> Date: Fri, 03 Oct 2014 00:45:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/Mk5MD1mnmFndZdqzISLJVYWtXwQ Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radius-fragmentation-08.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: Fri, 03 Oct 2014 07:45:23 -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 : Support of fragmentation of RADIUS packets Authors : Alejandro Perez-Mendez Rafa Marin-Lopez Fernando Pereniguez-Garcia Gabriel Lopez-Millan Diego R. Lopez Alan DeKok Filename : draft-ietf-radext-radius-fragmentation-08.txt Pages : 33 Date : 2014-10-03 Abstract: The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 octets. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with existing implementations, and are designed to be invisible to proxies, and "fail-safe" to legacy clients and servers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-08 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 Fri Oct 3 00:47:21 2014 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 9B2591ACFE3 for ; Fri, 3 Oct 2014 00:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, 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 2wP_yaCwxE6V for ; Fri, 3 Oct 2014 00:47:18 -0700 (PDT) Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id 44EEA1A00B8 for ; Fri, 3 Oct 2014 00:47:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id 7337AA6E4 for ; Fri, 3 Oct 2014 09:47:16 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon22.um.es Received: from xenon22.um.es ([127.0.0.1]) by localhost (xenon22.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8qFc-uBK9MPn for ; Fri, 3 Oct 2014 09:47:16 +0200 (CEST) Received: from [10.42.0.18] (84.124.144.62.dyn.user.ono.com [84.124.144.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon22.um.es (Postfix) with ESMTPSA id 33CB83944 for ; Fri, 3 Oct 2014 09:47:15 +0200 (CEST) Message-ID: <542E5482.1020505@um.es> Date: Fri, 03 Oct 2014 09:47:14 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: radext@ietf.org References: <20141003074521.3609.3254.idtracker@ietfa.amsl.com> In-Reply-To: <20141003074521.3609.3254.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/spF40F80Vh9d3WcAo_R_n-j_YvM Subject: Re: [radext] I-D Action: draft-ietf-radext-radius-fragmentation-08.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: Fri, 03 Oct 2014 07:47:20 -0000 We've posted a new version of the fragmentation draft, addressing the remaining issues in the trac (basically some nits). The draft is now ready for LC. Regards, Alejandro > 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 : Support of fragmentation of RADIUS packets > Authors : Alejandro Perez-Mendez > Rafa Marin-Lopez > Fernando Pereniguez-Garcia > Gabriel Lopez-Millan > Diego R. Lopez > Alan DeKok > Filename : draft-ietf-radext-radius-fragmentation-08.txt > Pages : 33 > Date : 2014-10-03 > > Abstract: > The Remote Authentication Dial-In User Service (RADIUS) protocol is > limited to a total packet size of 4096 octets. Provisions exist for > fragmenting large amounts of authentication data across multiple > packets, via Access-Challenge. No similar provisions exist for > fragmenting large amounts of authorization data. This document > specifies how existing RADIUS mechanisms can be leveraged to provide > that functionality. These mechanisms are largely compatible with > existing implementations, and are designed to be invisible to > proxies, and "fail-safe" to legacy clients and servers. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-08 > > > 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/ > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Tue Oct 7 02:05:30 2014 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 41D201A913D for ; Tue, 7 Oct 2014 02:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 tTEfAyNvwLom for ; Tue, 7 Oct 2014 02:05:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C92F1A1A76 for ; Tue, 7 Oct 2014 02:05:26 -0700 (PDT) Received: from localhost ([::1]:37867 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XbQho-00083r-1O; Tue, 07 Oct 2014 02:05:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-radius-fragmentation@tools.ietf.org, alex@um.es, stefan.winter@restena.lu X-Trac-Project: radext Date: Tue, 07 Oct 2014 09:05:15 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/178#comment:4 Message-ID: <080.6703456ea3e426a982ff5212cee70296@trac.tools.ietf.org> References: <065.3a956fa45a00049e711dbe6a5fb8d6c9@trac.tools.ietf.org> X-Trac-Ticket-ID: 178 In-Reply-To: <065.3a956fa45a00049e711dbe6a5fb8d6c9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-radius-fragmentation@tools.ietf.org, alex@um.es, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@networkradius.com, alex@um.es, diego@tid.es, gabilm@um.es, pereniguez@um.es, rafa@um.es Archived-At: http://mailarchive.ietf.org/arch/msg/radext/kYgeg2eC2jLteduT_00mqGI7bSg Cc: radext@ietf.org Subject: Re: [radext] #178 (radius-fragmentation): fragments going in both directions - allowed or not? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 09:05:28 -0000 #178: fragments going in both directions - allowed or not? Changes (by stefan.winter@restena.lu): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | radius-fragmentation@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: radius-fragmentation | Version: Severity: Waiting for Shepherd | Resolution: fixed Writeup | Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Tue Oct 7 02:05:52 2014 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 E6F581A9168 for ; Tue, 7 Oct 2014 02:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 x1DZMNpSLhmS for ; Tue, 7 Oct 2014 02:05:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE3A1A9155 for ; Tue, 7 Oct 2014 02:05:49 -0700 (PDT) Received: from localhost ([::1]:37907 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XbQiH-0008Cf-RC; Tue, 07 Oct 2014 02:05:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-radius-fragmentation@tools.ietf.org, stefan.winter@restena.lu, alex@um.es X-Trac-Project: radext Date: Tue, 07 Oct 2014 09:05:45 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/179#comment:5 Message-ID: <080.317eab685e9a6000986c33f989434e48@trac.tools.ietf.org> References: <065.e68e62499c1428e7ab8f6e73087bad4c@trac.tools.ietf.org> X-Trac-Ticket-ID: 179 In-Reply-To: <065.e68e62499c1428e7ab8f6e73087bad4c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-radius-fragmentation@tools.ietf.org, stefan.winter@restena.lu, alex@um.es, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@networkradius.com, alex@um.es, diego@tid.es, gabilm@um.es, pereniguez@um.es, rafa@um.es Archived-At: http://mailarchive.ietf.org/arch/msg/radext/8ItUPTElFvB1w8HaVkBbZt56Pv8 Cc: radext@ietf.org Subject: Re: [radext] #179 (radius-fragmentation): draft-ietf-radext-radius-fragmentation-06: IANA considerations X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 09:05:51 -0000 #179: draft-ietf-radext-radius-fragmentation-06: IANA considerations Changes (by stefan.winter@restena.lu): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | radius-fragmentation@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: radius-fragmentation | Version: Severity: Waiting for Shepherd | Resolution: fixed Writeup | Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Tue Oct 7 02:07:24 2014 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 6E9BE1A1B47 for ; Tue, 7 Oct 2014 02:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 XYoZoKi9G5hq for ; Tue, 7 Oct 2014 02:07:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8511A1A76 for ; Tue, 7 Oct 2014 02:07:21 -0700 (PDT) Received: from localhost ([::1]:37964 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XbQjg-0008Lt-La; Tue, 07 Oct 2014 02:07:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-radius-fragmentation@tools.ietf.org, alex@um.es, aland@deployingradius.com, stefan.winter@restena.lu X-Trac-Project: radext Date: Tue, 07 Oct 2014 09:07:12 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/180#comment:5 Message-ID: <080.989f21273315631e27365552c476b238@trac.tools.ietf.org> References: <065.fe6830fb6d900ff63bd95d61218553db@trac.tools.ietf.org> X-Trac-Ticket-ID: 180 In-Reply-To: <065.fe6830fb6d900ff63bd95d61218553db@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-radius-fragmentation@tools.ietf.org, alex@um.es, aland@deployingradius.com, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@networkradius.com, alex@um.es, diego@tid.es, gabilm@um.es, pereniguez@um.es, rafa@um.es Archived-At: http://mailarchive.ietf.org/arch/msg/radext/8a6JiLk_DORDfchrdqc4kEKcy3o Cc: radext@ietf.org Subject: Re: [radext] #180 (radius-fragmentation): draft-ietf-radext-radius-fragmentation-06: mop-up of small comments X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 09:07:23 -0000 #180: draft-ietf-radext-radius-fragmentation-06: mop-up of small comments Changes (by stefan.winter@restena.lu): * status: new => closed * resolution: => fixed Comment: That sentence in #1 still reads strange to me, but I'm not a native speaker myself. I'm sure the RFC editor will fix any grammar if needed, so I'm closing this ticket. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | radius-fragmentation@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: radius-fragmentation | Version: Severity: Waiting for Shepherd | Resolution: fixed Writeup | Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Tue Oct 7 02:11:26 2014 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 C4AD91A9167 for ; Tue, 7 Oct 2014 02:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 bPoChj9YBXZf for ; Tue, 7 Oct 2014 02:11:21 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80D71A1A80 for ; Tue, 7 Oct 2014 02:11:20 -0700 (PDT) Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id 6B76A411A7 for ; Tue, 7 Oct 2014 11:11:19 +0200 (CEST) Message-ID: <5433AE37.2080402@restena.lu> Date: Tue, 07 Oct 2014 11:11:19 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: radext@ietf.org References: <20141003074521.3609.3254.idtracker@ietfa.amsl.com> <542E5482.1020505@um.es> In-Reply-To: <542E5482.1020505@um.es> OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mImnAEF8HVQ7RnJ8qA3jh0eRdtJfPpX5F" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/0MqjWVTCZPQNvAfjuxvLApeiHdg Subject: Re: [radext] I-D Action: draft-ietf-radext-radius-fragmentation-08.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: Tue, 07 Oct 2014 09:11:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mImnAEF8HVQ7RnJ8qA3jh0eRdtJfPpX5F Content-Type: multipart/mixed; boundary="------------060003080309040605030605" This is a multi-part message in MIME format. --------------060003080309040605030605 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > We've posted a new version of the fragmentation draft, addressing the > remaining issues in the trac (basically some nits). >=20 > The draft is now ready for LC. It is :-) I've just completed the write-up and requested publication. Thanks for work on this draft, Stefan Winter >=20 > Regards, > Alejandro >=20 >=20 >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >> This draft is a work item of the RADIUS EXTensions Working Group of t= he IETF. >> >> Title : Support of fragmentation of RADIUS packets >> Authors : Alejandro Perez-Mendez >> Rafa Marin-Lopez >> Fernando Pereniguez-Garcia >> Gabriel Lopez-Millan >> Diego R. Lopez >> Alan DeKok >> Filename : draft-ietf-radext-radius-fragmentation-08.txt >> Pages : 33 >> Date : 2014-10-03 >> >> Abstract: >> The Remote Authentication Dial-In User Service (RADIUS) protocol is= >> limited to a total packet size of 4096 octets. Provisions exist fo= r >> fragmenting large amounts of authentication data across multiple >> packets, via Access-Challenge. No similar provisions exist for >> fragmenting large amounts of authorization data. This document >> specifies how existing RADIUS mechanisms can be leveraged to provid= e >> that functionality. These mechanisms are largely compatible with >> existing implementations, and are designed to be invisible to >> proxies, and "fail-safe" to legacy clients and servers. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentatio= n/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-08 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-radius-fragmentat= ion-08 >> >> >> Please note that it may take a couple of minutes from the time of subm= ission >> 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/ >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 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 --------------060003080309040605030605 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.0.22 (GNU/Linux) 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----- --------------060003080309040605030605-- --mImnAEF8HVQ7RnJ8qA3jh0eRdtJfPpX5F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJUM643AAoJEMDeajWKOdxmrsIQALorwMuwvuuaUHxDfxZ1nnl1 F955SC/xT7reSb5dKMWr9jODuzYN4rtA06M68khBX67D82FijZPnwiX4ldVaKv74 hpzLeedwKQSVOp1HWX9Gv4T3HJ0MCsxQfHPKPlAmfHM0PWlVRhDbIOyyLl8FDHEL n5jracqKd2rZc8fHx+ITEf6wSnaKLwit//s1GtKU770X+LLXhkdoSswhNEdKAFv+ cMmcG/OVcdRhTZKf3yxDq68tHuZPra6ztjBtvZwu3n52TY3XMo5HNPS9IonM+sQB ukltm038AtthbeNime4zQGBKq6aIfKQf46Knl1w/cv2NJrcOjbzRrfTtEDwCLB2K N2RKwElrJWSK/NhtZV4HGIT3woPomgIVKlA6pBlwKC6bfDRVrgh8+KbzI1K7Vzu5 7fgX8S0y7AFjWzXWkrWcuerF11dC699npc9o2MfSnP7A53yEcxInuCiMw5EuTfZc Aj2p+SmNNM787xOFz3TBd5hPmuTa4vM50pGoV267vjM91J1yOBy27CCSMEdznDbh YucXSP83HQdOew19vbZD8JzDh+ZX6zIrUnhAkN2OITbvCSlhizV4dy0K6QoomZkc fAamYPI1IpK0ltdMVgMV9ch6UfR6GgrwDlWeOp1tVOSy+mPSHPjLkpyihCAsvBAl /h0lFGrSEzaUBwl0TMpO =eR+Q -----END PGP SIGNATURE----- --mImnAEF8HVQ7RnJ8qA3jh0eRdtJfPpX5F-- From nobody Tue Oct 7 02:35:43 2014 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 AFAA01ACCDC for ; Tue, 7 Oct 2014 02:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.386 X-Spam-Level: X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3, RP_MATCHES_RCVD=-0.786] autolearn=no 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 59321DuLnBYU for ; Tue, 7 Oct 2014 02:35:40 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B09B31A1A7F for ; Tue, 7 Oct 2014 02:35:40 -0700 (PDT) Received: from localhost ([::1]:39449 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XbRBA-0008OU-R8; Tue, 07 Oct 2014 02:35:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-nai@tools.ietf.org, aland@deployingradius.com, stefan.winter@restena.lu X-Trac-Project: radext Date: Tue, 07 Oct 2014 09:35:36 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/176#comment:2 Message-ID: <080.009645db2a2ae3ccc551525874156bac@trac.tools.ietf.org> References: <065.18ebd81ae64d013f63a780221f34a543@trac.tools.ietf.org> X-Trac-Ticket-ID: 176 In-Reply-To: <065.18ebd81ae64d013f63a780221f34a543@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-nai@tools.ietf.org, aland@deployingradius.com, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@freeradius.org Archived-At: http://mailarchive.ietf.org/arch/msg/radext/c-oxOFTsezI62SBi0Cd3ATtqLMs Cc: radext@ietf.org Subject: Re: [radext] #176 (nai): draft-ietf-radext-nai-05: is the term *Network Access* Identifier still appropriate? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 09:35:41 -0000 #176: draft-ietf-radext-nai-05: is the term *Network Access* Identifier still appropriate? Comment (by stefan.winter@restena.lu): This issue was discussed on the list and it was unanismously agreed to keep the name - noting that the actual scope of NAIs is larger than back in the day when the term was coined. The document was revised meanwhile; only one trace of the old wording remains in 1.1 "Definition": "... is the user identity submitted by the client during network access authentication." Re-wording this to "... is the user identity submitted by the client during authentication." would remove the network context. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | nai@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: nai | Version: Severity: Waiting for Shepherd | Resolution: Writeup | Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Tue Oct 7 03:28:17 2014 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 980F11A1B81 for ; Tue, 7 Oct 2014 03:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 G8DM57iVYT_o for ; Tue, 7 Oct 2014 03:28:13 -0700 (PDT) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id 80D6A1A1B25 for ; Tue, 7 Oct 2014 03:28:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id 14C96E5DB for ; Tue, 7 Oct 2014 12:28:11 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon24.um.es Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id l+ODRGuVsEyX for ; Tue, 7 Oct 2014 12:28:11 +0200 (CEST) Received: from [10.42.0.18] (84.124.144.62.dyn.user.ono.com [84.124.144.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon24.um.es (Postfix) with ESMTPSA id 81883DE60 for ; Tue, 7 Oct 2014 12:28:09 +0200 (CEST) Message-ID: <5433C031.1040406@um.es> Date: Tue, 07 Oct 2014 12:28:01 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: radext@ietf.org References: <20141003074521.3609.3254.idtracker@ietfa.amsl.com> <542E5482.1020505@um.es> <5433AE37.2080402@restena.lu> In-Reply-To: <5433AE37.2080402@restena.lu> Content-Type: multipart/alternative; boundary="------------030900010804060700080703" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/fodaVczFG8WpTFZOR8xdA8kzR4c Subject: Re: [radext] I-D Action: draft-ietf-radext-radius-fragmentation-08.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: Tue, 07 Oct 2014 10:28:16 -0000 This is a multi-part message in MIME format. --------------030900010804060700080703 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit El 07/10/14 a las #4, Stefan Winter escribió: > Hi, > >> We've posted a new version of the fragmentation draft, addressing the >> remaining issues in the trac (basically some nits). >> >> The draft is now ready for LC. > It is :-) I've just completed the write-up and requested publication. > > Thanks for work on this draft, Thanks to you for the review and shepherding work. Regards, Alejandro > > Stefan Winter > >> Regards, >> Alejandro >> >> >>> 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 : Support of fragmentation of RADIUS packets >>> Authors : Alejandro Perez-Mendez >>> Rafa Marin-Lopez >>> Fernando Pereniguez-Garcia >>> Gabriel Lopez-Millan >>> Diego R. Lopez >>> Alan DeKok >>> Filename : draft-ietf-radext-radius-fragmentation-08.txt >>> Pages : 33 >>> Date : 2014-10-03 >>> >>> Abstract: >>> The Remote Authentication Dial-In User Service (RADIUS) protocol is >>> limited to a total packet size of 4096 octets. Provisions exist for >>> fragmenting large amounts of authentication data across multiple >>> packets, via Access-Challenge. No similar provisions exist for >>> fragmenting large amounts of authorization data. This document >>> specifies how existing RADIUS mechanisms can be leveraged to provide >>> that functionality. These mechanisms are largely compatible with >>> existing implementations, and are designed to be invisible to >>> proxies, and "fail-safe" to legacy clients and servers. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-08 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-08 >>> >>> >>> 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/ >>> >>> _______________________________________________ >>> radext mailing list >>> radext@ietf.org >>> https://www.ietf.org/mailman/listinfo/radext >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >> > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------030900010804060700080703 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
El 07/10/14 a las #4, Stefan Winter escribió:
Hi,


We've posted a new version of the fragmentation draft, addressing the
remaining issues in the trac (basically some nits).

The draft is now ready for LC.

It is :-) I've just completed the write-up and requested publication.

Thanks for work on this draft,

Thanks to you for the review and shepherding  work.

Regards,
Alejandro


Stefan Winter


Regards,
Alejandro



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           : Support of fragmentation of RADIUS packets
        Authors         : Alejandro Perez-Mendez
                          Rafa Marin-Lopez
                          Fernando Pereniguez-Garcia
                          Gabriel Lopez-Millan
                          Diego R. Lopez
                          Alan DeKok
	Filename        : draft-ietf-radext-radius-fragmentation-08.txt
	Pages           : 33
	Date            : 2014-10-03

Abstract:
   The Remote Authentication Dial-In User Service (RADIUS) protocol is
   limited to a total packet size of 4096 octets.  Provisions exist for
   fragmenting large amounts of authentication data across multiple
   packets, via Access-Challenge.  No similar provisions exist for
   fragmenting large amounts of authorization data.  This document
   specifies how existing RADIUS mechanisms can be leveraged to provide
   that functionality.  These mechanisms are largely compatible with
   existing implementations, and are designed to be invisible to
   proxies, and "fail-safe" to legacy clients and servers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-08


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/

_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext






_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

--------------030900010804060700080703-- From nobody Tue Oct 7 07:56:46 2014 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 4BE4A1ACDEC for ; Tue, 7 Oct 2014 07:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.386 X-Spam-Level: X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3, RP_MATCHES_RCVD=-0.786] autolearn=no 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 A3a95OBFIqTG for ; Tue, 7 Oct 2014 07:56:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477BA1ACDE9 for ; Tue, 7 Oct 2014 07:56:43 -0700 (PDT) Received: from localhost ([::1]:56415 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XbWBs-00028M-4g; Tue, 07 Oct 2014 07:56:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-nai@tools.ietf.org, aland@deployingradius.com, stefan.winter@restena.lu X-Trac-Project: radext Date: Tue, 07 Oct 2014 14:56:40 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/176#comment:3 Message-ID: <080.9a2e1df74be9770b33e997f44000d29c@trac.tools.ietf.org> References: <065.18ebd81ae64d013f63a780221f34a543@trac.tools.ietf.org> X-Trac-Ticket-ID: 176 In-Reply-To: <065.18ebd81ae64d013f63a780221f34a543@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-nai@tools.ietf.org, aland@deployingradius.com, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@freeradius.org Archived-At: http://mailarchive.ietf.org/arch/msg/radext/1KGUvMlaqqTTqYorgTD7yzWyRSs Cc: radext@ietf.org Subject: Re: [radext] #176 (nai): draft-ietf-radext-nai-05: is the term *Network Access* Identifier still appropriate? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 14:56:44 -0000 #176: draft-ietf-radext-nai-05: is the term *Network Access* Identifier still appropriate? Comment (by aland@deployingradius.com): I'll change it in last call. I don't think it's worth doing a new rev for this one change. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | nai@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: nai | Version: Severity: Waiting for Shepherd | Resolution: Writeup | Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Tue Oct 7 22:37:27 2014 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 E6FD31ACD50 for ; Tue, 7 Oct 2014 22:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.386 X-Spam-Level: X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3, RP_MATCHES_RCVD=-0.786] autolearn=no 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 jnsDxPuwTYqy for ; Tue, 7 Oct 2014 22:37:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23A801ACD4C for ; Tue, 7 Oct 2014 22:37:23 -0700 (PDT) Received: from localhost ([::1]:36736 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xbjw7-0005fX-9i; Tue, 07 Oct 2014 22:37:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-nai@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Wed, 08 Oct 2014 05:37:19 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/174#comment:1 Message-ID: <080.522f234016a3dad7272e3abc73c32d5d@trac.tools.ietf.org> References: <065.12d087d901705030bfcbbcad989fa5e8@trac.tools.ietf.org> X-Trac-Ticket-ID: 174 In-Reply-To: <065.12d087d901705030bfcbbcad989fa5e8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-nai@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@freeradius.org Archived-At: http://mailarchive.ietf.org/arch/msg/radext/DygWqQ4GPxWm9OXSg_n2rH7scKM Cc: radext@ietf.org Subject: Re: [radext] #174 (nai): draft-ietf-radext-nai-05: IPR boilerplate X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 05:37:24 -0000 #174: draft-ietf-radext-nai-05: IPR boilerplate Changes (by stefan.winter@restena.lu): * status: new => closed * resolution: => wontfix Comment: After checking offline with the author, there is too much pre-2008 legacy in the document to reconcile; the boilerplate thus needs to stay as it is. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | nai@tools.ietf.org Type: enhancement | Status: closed Priority: minor | Milestone: Component: nai | Version: Severity: Waiting for Shepherd | Resolution: wontfix Writeup | Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Tue Oct 7 22:58:38 2014 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 B40861ACE36 for ; Tue, 7 Oct 2014 22:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 bJ5Vesa57zdH for ; Tue, 7 Oct 2014 22:58:34 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE571A9100 for ; Tue, 7 Oct 2014 22:58:33 -0700 (PDT) Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id 71CB7411D9 for ; Wed, 8 Oct 2014 07:58:32 +0200 (CEST) Message-ID: <5434D288.10706@restena.lu> Date: Wed, 08 Oct 2014 07:58:32 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: radext@ietf.org References: <065.18ebd81ae64d013f63a780221f34a543@trac.tools.ietf.org> <080.9a2e1df74be9770b33e997f44000d29c@trac.tools.ietf.org> In-Reply-To: <080.9a2e1df74be9770b33e997f44000d29c@trac.tools.ietf.org> OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FJqML44VDmL8pfhaFNisuxvPJaPTaUKgI" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/vFxIg5olz5XLeVHkszbmodRs-18 Subject: Re: [radext] #176 (nai): draft-ietf-radext-nai-05: is the term *Network Access* Identifier still appropriate? 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, 08 Oct 2014 05:58:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FJqML44VDmL8pfhaFNisuxvPJaPTaUKgI Content-Type: multipart/mixed; boundary="------------060305030004010203060508" This is a multi-part message in MIME format. --------------060305030004010203060508 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > I'll change it in last call. I don't think it's worth doing a new rev= for > this one change. ACK, I'll keep the ticket open as a reminder. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 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 --------------060305030004010203060508 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.0.22 (GNU/Linux) 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----- --------------060305030004010203060508-- --FJqML44VDmL8pfhaFNisuxvPJaPTaUKgI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJUNNKIAAoJEMDeajWKOdxmudIQALXYUXzMA7xYivrJ4ZFpyrmu Jnul8JxsqarIkhDY0RHn89cd3WVS+ME4FlyTFiQkiMN6msRo7Hh2lITLiGEjOEfu pfPKxLYaMAmdZbcYek5myuyklTYePYx4MKWEl6nqMhKWoU9464pIs9jSU0StuX8w p6Wh4veG3EeM6hWSYNHTrc1/m1oG1aNITTq0IcZc3+kSWoLcJf5IRcY/oF0xFW09 Rrj1mDEjdab6JM4D1yDavr1+LhTvDtOMgu64WnmF7CSfQ8fTZeX78v7DkZLLZOPa eRZnIZk4cB3lINdyV7g3nH8licT/ZBcYodJXPHrbKn2A5UAyOVKOkPg5WYut4LU6 6vo9fEFsYATSb+ooHB1tKFykqJohGff5IUqdzK1QvcDrS84hgoC0mZSvVJ0BOwyv LMnfslVB/VzPx7dInN4z3PzouDzeMIrTaN4aFseeWgYzAdNXMH4HmAKx8Mun5vUl ys0aPc2h3NfA3R4kC4O7YF2Y3nefiA/YHjafMt1U/7lpyfbBPyg49gSo4QylR2PG L7w86Qn3pDWsT4xnzpc2hOandm5ghA3ylirTSlRYK+g0Bycygl9pvggBMU20mU+Z 9s5fdUPaODiGf/TnWEZrw6qFt+KdTdTuEP7bbn/t8Z1EJcT051AwQc8kd+Uv3fug IW2fU4KboSiiTU3bkw1a =vQuR -----END PGP SIGNATURE----- --FJqML44VDmL8pfhaFNisuxvPJaPTaUKgI-- From nobody Wed Oct 8 01:39:54 2014 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 35FC01A0108 for ; Wed, 8 Oct 2014 01:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.386 X-Spam-Level: X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3, RP_MATCHES_RCVD=-0.786] autolearn=no 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 rbH1VRFKPnIU for ; Wed, 8 Oct 2014 01:39:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE7D1A0105 for ; Wed, 8 Oct 2014 01:39:52 -0700 (PDT) Received: from localhost ([::1]:46239 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xbmmi-0005f6-K8; Wed, 08 Oct 2014 01:39:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-nai@tools.ietf.org, aland@deployingradius.com, stefan.winter@restena.lu X-Trac-Project: radext Date: Wed, 08 Oct 2014 08:39:48 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/176#comment:4 Message-ID: <080.1a955c63a090de473a357e378209ef11@trac.tools.ietf.org> References: <065.18ebd81ae64d013f63a780221f34a543@trac.tools.ietf.org> X-Trac-Ticket-ID: 176 In-Reply-To: <065.18ebd81ae64d013f63a780221f34a543@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-nai@tools.ietf.org, aland@deployingradius.com, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@freeradius.org Archived-At: http://mailarchive.ietf.org/arch/msg/radext/rCileR_SSHm032PD_aVhT1-HDyc Cc: radext@ietf.org Subject: Re: [radext] #176 (nai): draft-ietf-radext-nai-05: is the term *Network Access* Identifier still appropriate? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 08:39:53 -0000 #176: draft-ietf-radext-nai-05: is the term *Network Access* Identifier still appropriate? Comment (by stefan.winter@restena.lu): Another occurence is in the Abstract: "... the user identity submitted by the client prior to accessing network resources." It should probably just be "resources" to remove the specific scope of network access. This can also be done in IETF LC. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | nai@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: nai | Version: Severity: Waiting for Shepherd | Resolution: Writeup | Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Mon Oct 20 00:45:29 2014 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 401001A6FDA for ; Mon, 20 Oct 2014 00:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 S0T858Qvo8n2 for ; Mon, 20 Oct 2014 00:45:25 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A60251A0030 for ; Mon, 20 Oct 2014 00:45:24 -0700 (PDT) Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id 2888B40CA5 for ; Mon, 20 Oct 2014 09:45:23 +0200 (CEST) Message-ID: <5444BD92.6050200@restena.lu> Date: Mon, 20 Oct 2014 09:45:22 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "radext@ietf.org" OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3lH8AGqc6AjPPmuqhPE4ATIrliEFEQp1O" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/IVIlmdiHdIh_39ZOcAkOTJWjGeU Subject: [radext] Preliminary Agenda for the radext meeting at IETF91 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, 20 Oct 2014 07:45:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3lH8AGqc6AjPPmuqhPE4ATIrliEFEQp1O Content-Type: multipart/mixed; boundary="------------030603070305040303090505" This is a multi-part message in MIME format. --------------030603070305040303090505 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, as you've probably seen, the final agenda for IETF91 has been published recently. Jouni and I have asked for the usual 90 min slot, but were given a 120 min slot instead. Hooray! I'm attaching a preliminary agenst for the radext slot; I crafted it with the 90 min in mind, so it's easy to add more items or ask for more time if you think you need it. In particular, we will need to recharter to get new work on board ( specifically, for -datatypes and -coa-proxy ) and I'd like to discuss that in the meeting. I'm still working on the exact proposed text for a new charter, but "semantic changelog" of items that need work are in the attached agenda draft. Please comment on the agenda before the I-D cutoff; soon after the cut-off, I'll post the final agenda. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg 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 --------------030603070305040303090505 Content-Type: text/plain; charset=UTF-8; name="radext-agenda.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="radext-agenda.txt" UkFERVhUIFdHIElFVEYgOTEgQWdlbmRhCj09PT09PT09PT09PT09PT09PT09PT09PQpDaGFp cnM6CkpvdW5pIEtvcmhvbmVuIDxqb3VuaS5rb3Job25lbiBhdCBicm9hZGNvbS5jb20+ClN0 ZWZhbiBXaW50ZXIgPHN0ZWZhbi53aW50ZXIgYXQgcmVzdGVuYS5sdT4KCkphYmJlciByb29t OiByYWRleHQgYXQgamFiYmVyLmlldGYub3JnIChQbGVhc2Ugam9pbikKVGltZSBhbmQgRGF5 OiBUdWVzZGF5LCAxMSBOb3ZlbWJlciAyMDE0LCAxNTIwIEhTVApQbGFjZTogTGVodWEgU3Vp dGUKClByZWxpbWluYXJpZXMgKDEwIG1pbikKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpBdWRp by9WaWRlbyAmIFJlbW90ZSBQcmVzZW50YXRpb24gRGVidWdnaW5nCk5vdGUgV2VsbApOb3Rl IFRha2VycwpKYWJiZXIgc2NyaWJlCkFnZW5kYSBiYXNoCkRvY3VtZW50IFN0YXR1cwoKV29y a2luZyBncm91cCBkcmFmdCBkaXNjdXNzaW9uICgzNSBtaW51dGVzKQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAgIChhY3RpdmUpCiAgIGRyYWZ0LWll dGYtcmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4dC0wMSAgICA6IDEwIG1pbgogICBkcmFmdC1p ZXRmLXJhZGV4dC1iaWdnZXItcGFja2V0cy0wMSAgICAgICAgOiAxMCBtaW4KICAgZHJhZnQt aWV0Zi1yYWRleHQtZHluYW1pYy1kaXNjb3ZlcnktMTEgICAgIDogIDUgbWluCiAgIChwdWJs aWNhdGlvbiByZXF1ZXN0ZWQgLyBJRVRGIExDKQogICBkcmFmdC1pZXRmLXJhZGV4dC1uYWkt MDggICAgICAgICAgICAgICAgICAgOiAgNSBtaW4KICAgZHJhZnQtaWV0Zi1yYWRleHQtcmFk aXVzLWZyYWdtZW50YXRpb24tMDggIDogIDUgbWluCgpJbmRpdmlkdWFsIGRyYWZ0IGRpc2N1 c3Npb25zLCBwdC4gMSAoMTAgbWludXRlcykKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KICAgZHJhZnQtZGVrb2stcmFkZXh0LWNvYS1wcm94eSAgICAgICAg ICAgICAgIDogIDUgbWluCiAgIGRyYWZ0LWRla29rLXJhZGV4dC1kYXRhdHlwZXMgICAgICAg ICAgICAgICA6ICA1IG1pbgoKUmVjaGFydGVyIGRpc2N1c3Npb24gKHN0cmF3bWFuIHRleHQp ICgxNSBtaW51dGVzKQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KU2tl dGNoOgogIEFERCBleHRlbnNpb25zICpmb3IgbmV3IGZ1bmN0aW9uYWxpdHkqCiAgICAoc25l YWtzIGluIENvQSBwcm94eSkKICAoZGF0YXR5cGVzIGFyZ3VhYmx5IGNvdmVyZWQgYnkgImNs YXJpZnkgdXNhZ2UgYW5kIGRlZmluaXRpb24iOwogICBvdGhlcndpc2UsIHRoZXkgYXJlICJu ZXcgZnVuY3Rpb25hbGl0eSIpCiAgREVMIERpYW1ldGVyIGNvbXBhdAogIERFTCB3b3JrIGl0 ZW0gYXR0cmlidXRlIHNwYWNlIGV4dGVuc2lvbiAoZG9uZSkKICBERUwgd29yayBpdGVtIElF RUUgODAyCiAgREVMIHdvcmsgaXRlbSBOQUkKICBERUwgd29yayBpdGVtIGZyYWdtZW50YXRp b24KICBBREQgd29yayBpdGVtIHVzZSBvZiBDb0EgaW4gcm9hbWluZyBjb250ZXh0cwogIEFE RCB3b3JrIGl0ZW0gY2xhcmlmaWNhdGlvbiBvZiBleGlzdGluZyBhbmQgZGVmaW5pdGlvbiBv ZiBuZXcgZGF0YXR5cGVzCiAKSW5kaXZpZHVhbCBkcmFmdCBzdWJtaXNzaW9ucywgcHQuIDIg KDUgbWludXRlcykKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCmRyYWZ0 LXdpbnRlci1yYWRleHQtcG9wdWxhdGluZy1lYXBpZGVudGl0eSAgICA6ICA1IG1pbgoKSG91 c2VrZWVwaW5nCi0tLS0tLS0tLS0tLQpBZHZhbmNlbWVudCBvZiBSRkM2NjE0IHRvIFNURCB0 cmFjayAgICAgICAgICAgOiAgNSBtaW4KCkluZGVwZW5kZW50IFN0cmVhbSBkb2N1bWVudHMg b2YgaW50ZXJlc3QgdG8gcmFkZXh0Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tCmVkdXJvYW0gYXJjaGl0ZWN0dXJlICAgICAgICAgICAgICAg ICAgICAgICAgICA6ICA1IG1pbgoKRW1wdHkgLyBXcmFwLXVwICg1IG1pbnV0ZXMpCi0tLS0t LS0tLS0tLS0tLS0tLS0tCk5leHQgU3RlcHM6IFdHIENoYWlycyAmIEFEcw== --------------030603070305040303090505 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.0.22 (GNU/Linux) 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----- --------------030603070305040303090505-- --3lH8AGqc6AjPPmuqhPE4ATIrliEFEQp1O Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJURL2SAAoJEMDeajWKOdxmovwQAKsIYv21g8qckjLq6B0E6/Cw rde6T6d397UBqN4jcie3Du3RuM4J7/x/2h7u9zsskBDQyZiWIGCmX9XG/Ex2OCUc rPXgy/V6tbUM0bTG+kyk5csztxhj6WMU9KLjhNn7CicS2JHb/iv6wjFHn8Hgs0KC NHn/8KUo2WU90M0UtioLlpXDcFydXcUp3Zr/J9YDE1GBItX2qroeL8xhYJkW9j7+ IxrshHnO+zBcJBG8DOJO80Vg5aTN6dw6ewnS34nws/1/jDoVezzBlW9qkxakOX4f 0VTAcBb/nEmWgsuCdpETPVeFu8SPaIkZtzTkz7pHbO2TYsXFwFU8NCv+gV+RdK81 xjSz/wCB8pvWa+F9TkRhGcVzUvZxFDzGQAlWeJkRnDja3/gbEuFWcCQAjAMi6v+7 8G68GTwxFHJciA04AhZUI3rOCvE4HxukgYVOp6NRVKdGbeyCEO+go5ylYuJo5lLf kBBvZzncPiJemyjE/qq//iFVjWPY0zxcgT9abSxfafLpFT9acrBsfGRLXh51nQCn ScnoqgbK47TDHjTgOMlgbr3WtV4Z1fC//zlq4I9TauauR7QewcVr1zuVy6KYgYmq pgyQVZC8Wltj6PSpfddivnud0zGYcgrDNUI+aNJURc9d4gWtclwb+p7TRGnyDiCD yOQP+G8we+AUjBUATnuN =kwEb -----END PGP SIGNATURE----- --3lH8AGqc6AjPPmuqhPE4ATIrliEFEQp1O-- From nobody Mon Oct 20 04:05:53 2014 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 8696C1A86E2 for ; Mon, 20 Oct 2014 04:05:51 -0700 (PDT) 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 bQseHjDPZGYr for ; Mon, 20 Oct 2014 04:05:49 -0700 (PDT) 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 D022E1A86E3 for ; Mon, 20 Oct 2014 04:05:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id ED33220371; Mon, 20 Oct 2014 07:04:28 -0400 (EDT) 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 bI7eYoiToJgG; Mon, 20 Oct 2014 07:04:27 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-26-5.hsd1.ma.comcast.net [50.177.26.5]) (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, 20 Oct 2014 07:04:27 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 303AC8167D; Mon, 20 Oct 2014 07:05:43 -0400 (EDT) From: Sam Hartman To: Stefan Winter References: <5444BD92.6050200@restena.lu> Date: Mon, 20 Oct 2014 07:05:43 -0400 In-Reply-To: <5444BD92.6050200@restena.lu> (Stefan Winter's message of "Mon, 20 Oct 2014 09:45:22 +0200") 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: http://mailarchive.ietf.org/arch/msg/radext/hJdOKQyUuqC4AevzuFiJoT04mG4 Cc: "radext@ietf.org" Subject: Re: [radext] Preliminary Agenda for the radext meeting at IETF91 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, 20 Oct 2014 11:05:51 -0000 Hi. I am waiting for a last call for bigger-packets. I posted a note in July of 2014 noting that there were no open issues. I think we should keep the agenda slot, but I'd appreciate it if the chairs could move towards last call. --Sam From nobody Mon Oct 20 10:43:56 2014 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 233F41A88C2 for ; Mon, 20 Oct 2014 10:43:55 -0700 (PDT) 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 YUR08SWHMDJB for ; Mon, 20 Oct 2014 10:43:52 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4489D1A88DD for ; Mon, 20 Oct 2014 10:43:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 591C222405E2; Mon, 20 Oct 2014 19:43:21 +0200 (CEST) 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 d9MyafXQhVB6; Mon, 20 Oct 2014 19:43:21 +0200 (CEST) Received: from Thor.local (76-10-152-73.dsl.teksavvy.com [76.10.152.73]) by power.freeradius.org (Postfix) with ESMTPSA id C0D2F22405AC; Mon, 20 Oct 2014 19:43:20 +0200 (CEST) Message-ID: <544549B7.6050605@deployingradius.com> Date: Mon, 20 Oct 2014 13:43:19 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <5444BD92.6050200@restena.lu> In-Reply-To: <5444BD92.6050200@restena.lu> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/5dqBltbioZoiRz4gbDyzIZdcjpo Cc: "radext@ietf.org" Subject: Re: [radext] Preliminary Agenda for the radext meeting at IETF91 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, 20 Oct 2014 17:43:55 -0000 Stefan Winter wrote: > Jouni and I have asked for the usual 90 min slot, but were given a 120 > min slot instead. Hooray! Room for more discussion. :) > In particular, we will need to recharter to get new work on board ( > specifically, for -datatypes and -coa-proxy ) and I'd like to discuss > that in the meeting. I think the list of re-charter items is fine. We might want to add the accounting work. But the interest in that seems to have disappeared. > I'm still working on the exact proposed text for a new charter, but > "semantic changelog" of items that need work are in the attached agenda > draft. For me: - the NAI document is essentially done, barring last-minute reviews - the data types document is essentially done. Based on feedback from Sam, I'll add a "concat" type for EAP-Message. But all feedback has been positive. The document now contains explicit updates to the IANA registry - the CoA proxy document is rough. It needs cleaning up and finalizing. the main issue here is that Diameter has a "Operastor-NAS-IP-Address" (IIRC), which is the IP of the NAS. The feedback from RADEXT was that for security, we wanted to give out and opaque token to identify the NAS, instead of using an IP address. Once that's settled, I think I can finalize the document. It's been discussed for ~2 years now, with no controversy. Alan DeKok. From nobody Tue Oct 21 06:06:31 2014 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 BE9571A1B80 for ; Tue, 21 Oct 2014 06:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 5l2RYO1hh-Ed for ; Tue, 21 Oct 2014 06:06:24 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC8E31A1B75 for ; Tue, 21 Oct 2014 06:06:24 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id v10so1301467pde.22 for ; Tue, 21 Oct 2014 06:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=clka+SLAJ95lQzGHJ9lDvaWXDHSPYbcyXSOtlw+Vw9k=; b=bft9O8vPBLh6FNIAqZjJo6CejlnsQQMp/eSqEoDyUmjTwswvlDnAGrafEvlE1itbS/ 9X0jao3YmJvGnc/OaQV0Wh8Rc+9pANAlCkVt4yOEJoqLsAMOorIVJq24z/CCz1XuRh1H TzhBdS9JUSKjyC1NfyiusQCeyNjG87LAbGPnDAXjsZlW2ZsUh/+9rRPQe8PouIete5kT ReCq6g9DuprEmHpRHwZtM4c0t4wEtwsnLXkYmN4XcFc/1oROHmfhuSPFihDA2/5C6MTK wIZy0S0RRmGY9kn08Hptz3zVPvX2/QN7tZdR0Ee70BszAyhI+N99ER1Dsz+3+5s3zcMB Qm4Q== X-Received: by 10.70.130.143 with SMTP id oe15mr34193615pdb.81.1413896784046; Tue, 21 Oct 2014 06:06:24 -0700 (PDT) Received: from [10.0.35.124] ([119.97.241.190]) by mx.google.com with ESMTPSA id c6sm11965515pdm.0.2014.10.21.06.06.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 06:06:23 -0700 (PDT) Message-ID: <54465A4B.1080201@gmail.com> Date: Tue, 21 Oct 2014 16:06:19 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sam Hartman , Stefan Winter References: <5444BD92.6050200@restena.lu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/cMmEn1PZMbgUuqEe5ADmA0mg-iE Cc: "radext@ietf.org" Subject: Re: [radext] Preliminary Agenda for the radext meeting at IETF91 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, 21 Oct 2014 13:06:27 -0000 10/20/2014 2:05 PM, Sam Hartman kirjoitti: > Hi. > > I am waiting for a last call for bigger-packets. I posted a note in > July of 2014 noting that there were no open issues. Bummer.. you are right. > I think we should keep the agenda slot, but I'd appreciate it if the > chairs could move towards last call. Sure. - Jouni > > --Sam > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > From nobody Wed Oct 22 01:04:49 2014 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 0A58A1A8AF6 for ; Wed, 22 Oct 2014 01:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 82TmxHtqcr8e for ; Wed, 22 Oct 2014 01:04:43 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC22D1A883B for ; Wed, 22 Oct 2014 01:04:43 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id r10so3021541pdi.24 for ; Wed, 22 Oct 2014 01:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=ZF3PGIPy4mVQD3u3NiULe50kZPZN4J6ZMeI3+7nlnyU=; b=eHbv1t83+93qX5HHZNdQLjfR+0sgPkPhxW8dy/CymfPHuIIAoSNeopf+SLZtgAWaQo lIkBSEFiwQ6Rb0IN9RrbUBeL0Xv+4d8CSDIKdjxn0cQ3ZyaGW3HGowrfsvkiBmLuaoJI 93OqE8QoEpKHjAaQUspQ3/ujDHtjl4cT9+lzbeThCpeq1tgdrTtr7RVeZln+SLWWyeYs KMK/LUDGGewjE/ozW8TwjRZlNRmGXqVvH/HhqPn98kBYX74Pz5uQsSZXp1eZih7UL4du n6IWcD0M+CVJ/cG8ptqaz0Kq75ejJwpujpWePm06Gi0Iaza9cRXfHpgNQP2kv/z3JDT0 tluA== X-Received: by 10.68.68.164 with SMTP id x4mr40223751pbt.102.1413965077722; Wed, 22 Oct 2014 01:04:37 -0700 (PDT) Received: from [10.0.35.124] ([119.97.241.190]) by mx.google.com with ESMTPSA id o4sm13733611pdh.56.2014.10.22.01.04.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Oct 2014 01:04:37 -0700 (PDT) Message-ID: <54476510.10903@gmail.com> Date: Wed, 22 Oct 2014 11:04:32 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "radext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/q75elYtRwhIPUVlgcOf5bntfbok Cc: Sam Hartman , jouni.nospam@gmail.com, Stefan Winter Subject: [radext] WGLC for draft-ietf-radext-bigger-packets-01 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, 22 Oct 2014 08:04:45 -0000 Folks, This email starts a two week WGLC for the I-D: draft-ietf-radext-bigger-packets-01 Voice your support, comments and concerns on the list. The WGLC ends 5th November EOB (EEST). In the case of issues or other enhancement proposals, please enter them also into the issue tracker. - Jouni & Stefan From nobody Wed Oct 22 07:27:04 2014 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 A28E91ACC8B for ; Wed, 22 Oct 2014 07:27:00 -0700 (PDT) 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 nakn61u133ws for ; Wed, 22 Oct 2014 07:26:58 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5310D1AC410 for ; Wed, 22 Oct 2014 07:26:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 8D1A522403A6; Wed, 22 Oct 2014 16:26:44 +0200 (CEST) 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 IAfC3R6O5Elv; Wed, 22 Oct 2014 16:26:44 +0200 (CEST) Received: from Thor.local (69-165-156-239.dsl.teksavvy.com [69.165.156.239]) by power.freeradius.org (Postfix) with ESMTPSA id A410122400DF; Wed, 22 Oct 2014 16:26:43 +0200 (CEST) Message-ID: <5447BEA3.60805@deployingradius.com> Date: Wed, 22 Oct 2014 10:26:43 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jouni Korhonen References: <54476510.10903@gmail.com> In-Reply-To: <54476510.10903@gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/QlBk-PgzQHe4NKkLZSdpedLUzps Cc: "radext@ietf.org" , Stefan Winter , Sam Hartman Subject: Re: [radext] WGLC for draft-ietf-radext-bigger-packets-01 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, 22 Oct 2014 14:27:00 -0000 Jouni Korhonen wrote: > This email starts a two week WGLC for the I-D: > draft-ietf-radext-bigger-packets-01 > > Voice your support, comments and concerns on the list. The WGLC ends 5th > November EOB (EEST). In the case of issues or other enhancement > proposals, please enter them also into the issue tracker. It needs some clarification around the response packet code. Sorry for not doing this review earlier. I'll open some issues. Editorial nits: The maximum packet length of 4096 octets is proving insufficient for ... That could be "is proving TO BE insufficient ..." Implementation notes: FreeRADIUS supports TCP, and silently discards packets over 4K octets. This limit isn't configurable, but could be with minimal work. This applies to both server and proxy. Technical comments: * Section 5 defines the Response-Length attribute, but doesn't use the typical RADIUS specification format, with ASCII art, etc. This means it's not clear how many octets the attribute takes. I suggest stating explicitly that it's of type "integer", as defined in RFC 2865, Section 5. * I'm of two minds about the "Too-Big" packet code. It's useful, but it may be better to change this to a generic "Protocol-Error" type, and include an Error-Cause attribute, with value "Too-Big". That would allow the same packet code to be used in other situations. * the document doesn't say how the "Too-Big" packet is created or signed. The rules for signing packets are different for Access-Accept and Accounting-Request packets. Which ones are used for "Too-Big" ? * what happens when a TCP socket contains both Access-Request and Accounting-Request packets? i.e. it is possible to have Access-Request of ID 1 and Accounting-Request of ID 1 sent over a TCP socket at the same time. If the client receives a "Too-Big" attribute of ID 1, which packet is it for? Does it matter? How does a client match the Too-Big attribute to incoming packets? These rules aren't clear. It's also not clear if they can be resolved in a reasonable amount of time. Perhaps one way to solve this issue is to define a "Protocol-Error" packet, and a Protocol-Error-Ack packet. The server would send one over the TCP socket to the client, and the client would ACK it. The packet signing rules could be the same as for Accounting-Request. This change would make TCP sockets "two-way", in that servers would be sending messages to clients. But I think that's fine... Clients could then use the same packet to send protocol error messages to servers. A Protocol-Error packet could then contain an Error-Cause attribute with value "Packet-Too-Big", and a Response-Length of the allowed response length. It would then be up to the receiver of the packet to change it's behavior. This also means that the receiver of Protocol-Error can't tell *which* packet caused the problem. But that might be fine. From nobody Wed Oct 22 07:43:10 2014 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 D514D1ACD01 for ; Wed, 22 Oct 2014 07:43:07 -0700 (PDT) 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 FbZE1zSV79Op for ; Wed, 22 Oct 2014 07:43:05 -0700 (PDT) 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 779721ACD00 for ; Wed, 22 Oct 2014 07:43:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 963AF2037B; Wed, 22 Oct 2014 10:41:39 -0400 (EDT) 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 lOONNt6CuCsR; Wed, 22 Oct 2014 10:41:38 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-26-5.hsd1.ma.comcast.net [50.177.26.5]) (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; Wed, 22 Oct 2014 10:41:38 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6B24681368; Wed, 22 Oct 2014 10:43:01 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <54476510.10903@gmail.com> <5447BEA3.60805@deployingradius.com> Date: Wed, 22 Oct 2014 10:43:01 -0400 In-Reply-To: <5447BEA3.60805@deployingradius.com> (Alan DeKok's message of "Wed, 22 Oct 2014 10:26:43 -0400") 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: http://mailarchive.ietf.org/arch/msg/radext/SLEjuukr3qElUt9I2l0HNy8K9d8 Cc: "radext@ietf.org" , Jouni Korhonen , Stefan Winter Subject: Re: [radext] WGLC for draft-ietf-radext-bigger-packets-01 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, 22 Oct 2014 14:43:08 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Jouni Korhonen wrote: Alan> * Section 5 defines the Response-Length attribute, but doesn't Alan> use the typical RADIUS specification format, with ASCII art, Alan> etc. This means it's not clear how many octets the attribute Alan> takes. Alan> I suggest stating explicitly that it's of type "integer", as Alan> defined in RFC 2865, Section 5. makes sense. If you want to supply ASCII art I'd be happy to include it. If you want to pretend we live in a post-data-types world and start that world now I'd be delighted. Alan> * I'm of two minds about the "Too-Big" packet code. It's Alan> useful, but it may be better to change this to a generic Alan> "Protocol-Error" type, and include an Error-Cause attribute, Alan> with value "Too-Big". Alan> That would allow the same packet code to be used in other Alan> situations. Alan> * the document doesn't say how the "Too-Big" packet is created Alan> or signed. The rules for signing packets are different for Alan> Access-Accept and Accounting-Request packets. Which ones are Alan> used for "Too-Big" ? I can see two choices. Pick one, or pick the one that is appropriate for what you're responding to. Alan> * what happens when a TCP socket contains both Access-Request Alan> and Accounting-Request packets? Hmm, I was thinking about TCP where we have separate accounting and authentication ports. However, we don't seem to have that for radsec. Alan> i.e. it is possible to have Access-Request of ID 1 and Alan> Accounting-Request of ID 1 sent over a TCP socket at the same Alan> time. Alan> If the client receives a "Too-Big" attribute of ID 1, which Alan> packet is it for? Does it matter? I don't think it matters that much, no. If it does you can see which of the packets you sent is bigger than the response length you just got. Alan> How does a client match the Too-Big attribute to incoming Alan> packets? These rules aren't clear. It's also not clear if Alan> they can be resolved in a reasonable amount of time. Alan> Perhaps one way to solve this issue is to define a Alan> "Protocol-Error" packet, and a Protocol-Error-Ack packet. The Alan> server would send one over the TCP socket to the client, and Alan> the client would ACK it. The packet signing rules could be Alan> the same as for Accounting-Request. I'd really rather not do that; it seems rather complex and I'd really like to try and find a way to make this mechanism simple. Let's explore how important it is that clients be able to match the too-big packet and if so how difficult that ends up being. --Sam From nobody Wed Oct 22 07:55:15 2014 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 0B3891ACD31 for ; Wed, 22 Oct 2014 07:55:12 -0700 (PDT) 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 Z8HsUGLsKyRi for ; Wed, 22 Oct 2014 07:55:05 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 19E231ACD2E for ; Wed, 22 Oct 2014 07:55:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 764AE2240E39; Wed, 22 Oct 2014 16:54:34 +0200 (CEST) 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 Ai6AN2ipoywc; Wed, 22 Oct 2014 16:54:34 +0200 (CEST) Received: from Thor.local (69-165-156-239.dsl.teksavvy.com [69.165.156.239]) by power.freeradius.org (Postfix) with ESMTPSA id 9BA1D2240363; Wed, 22 Oct 2014 16:54:33 +0200 (CEST) Message-ID: <5447C529.5060609@deployingradius.com> Date: Wed, 22 Oct 2014 10:54:33 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <54476510.10903@gmail.com> <5447BEA3.60805@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/IRrOWdvwprgZH9ubwNHzwmiQ040 Cc: "radext@ietf.org" , Jouni Korhonen , Stefan Winter Subject: Re: [radext] WGLC for draft-ietf-radext-bigger-packets-01 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, 22 Oct 2014 14:55:12 -0000 Sam Hartman wrote: > If you want to pretend we live in a post-data-types world and start that > world now I'd be delighted. I'm all for that. Call it an "integer" attribute as per RFC 2865 Section 5, and we're done. > I can see two choices. > Pick one, or pick the one that is appropriate for what you're responding > to. It's hard to know which packet type is being responded to. > I don't think it matters that much, no. > If it does you can see which of the packets you sent is bigger than the > response length you just got. That might be hard work, if the client is sending 100's of 1000's of packets. The packets will be sorted by socket, IPs, ports, etc. Not by size. > I'd really rather not do that; it seems rather complex and I'd really > like to try and find a way to make this mechanism simple. I'd prefer to not overload Access-Reject or Accounting-Response. Those are for *normal* situations. i.e. they do signaling for users, not for protocol errors. That means we need a new packet code. > Let's explore how important it is that clients be able to match the > too-big packet and if so how difficult that ends up being. TBH, the simplest thing would be to include the original packet code in a new attribute. That way the peer receiving the packet knows how to find the original. It can match code, src/dst IP, src/dst port. And change the name of the packet code. A generic name is much prettier than a specific one. i.e.: Packet code == Protocol-Error Attribute-TBD = Access-Request Error-Cause = Packet-Too-Big Response-Length = 8192 The packet signing rules should be the same as for Access-Accept, I think. i.e. copy the original vector to the response vector and sign. Even if the original was Accounting-Request. I think that's simple, has minimal changes to the document, and has minimal changes to existing implementations. Alan DeKok. From nobody Wed Oct 22 08:01:47 2014 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 5FBDB1ACCF3 for ; Wed, 22 Oct 2014 08:01:43 -0700 (PDT) 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 K3BbtkUQF5Gm for ; Wed, 22 Oct 2014 08:01:27 -0700 (PDT) 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 94F7E1ACD3A for ; Wed, 22 Oct 2014 08:01:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 176D22037B; Wed, 22 Oct 2014 11:00:02 -0400 (EDT) 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 MLo45P8DzggG; Wed, 22 Oct 2014 11:00:01 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-26-5.hsd1.ma.comcast.net [50.177.26.5]) (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; Wed, 22 Oct 2014 11:00:01 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 064EA81368; Wed, 22 Oct 2014 11:01:25 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <54476510.10903@gmail.com> <5447BEA3.60805@deployingradius.com> <5447C529.5060609@deployingradius.com> Date: Wed, 22 Oct 2014 11:01:25 -0400 In-Reply-To: <5447C529.5060609@deployingradius.com> (Alan DeKok's message of "Wed, 22 Oct 2014 10:54:33 -0400") 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: http://mailarchive.ietf.org/arch/msg/radext/c2vKKR-PS8Tj59kvI8Lsp5gqt5A Cc: "radext@ietf.org" , Jouni Korhonen , Stefan Winter Subject: Re: [radext] WGLC for draft-ietf-radext-bigger-packets-01 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, 22 Oct 2014 15:01:44 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> That might be hard work, if the client is sending 100's of Alan> 1000's of packets. The packets will be sorted by socket, IPs, Alan> ports, etc. Not by size. You know the socket and port. You're trying to sort between one accounting request and one access-request with id 1. That seems relatively easy. However: Alan> I'd prefer to not overload Access-Reject or Alan> Accounting-Response. Those are for *normal* situations. Alan> i.e. they do signaling for users, not for protocol errors. Agreed. Also, they get proxied, and we don't want that here (I don't think) Alan> That means we need a new packet code. Alan> TBH, the simplest thing would be to include the original Alan> packet code in a new attribute. That way the peer receiving Alan> the packet knows how to find the original. It can match code, Alan> src/dst IP, src/dst port. Alan> And change the name of the packet code. A generic name is Alan> much prettier than a specific one. Alan> i.e.: Alan> Packet code == Protocol-Error Attribute-TBD = Access-Request Alan> Error-Cause = Packet-Too-Big Response-Length = 8192 Alan> The packet signing rules should be the same as for Alan> Access-Accept, I think. i.e. copy the original vector to the Alan> response vector and sign. Even if the original was Alan> Accounting-Request. Alan> I think that's simple, has minimal changes to the document, Alan> and has minimal changes to existing implementations. I'm happy with that solutionn. Others? From nobody Wed Oct 22 09:00:16 2014 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 5676A1ACDC7 for ; Wed, 22 Oct 2014 09:00:06 -0700 (PDT) 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 hkq1Yr30Hw2v for ; Wed, 22 Oct 2014 09:00:04 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E50A1ACDC5 for ; Wed, 22 Oct 2014 09:00:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 7F98922403A6; Wed, 22 Oct 2014 17:59:33 +0200 (CEST) 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 NnyVxnxhXCmU; Wed, 22 Oct 2014 17:59:33 +0200 (CEST) Received: from Thor.local (69-165-156-239.dsl.teksavvy.com [69.165.156.239]) by power.freeradius.org (Postfix) with ESMTPSA id B7B472240363; Wed, 22 Oct 2014 17:59:32 +0200 (CEST) Message-ID: <5447D464.9040806@deployingradius.com> Date: Wed, 22 Oct 2014 11:59:32 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <54476510.10903@gmail.com> <5447BEA3.60805@deployingradius.com> <5447C529.5060609@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/OE-sCukGhHFPj3dJHsXAwX0gxL0 Cc: "radext@ietf.org" , Jouni Korhonen , Stefan Winter Subject: Re: [radext] WGLC for draft-ietf-radext-bigger-packets-01 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, 22 Oct 2014 16:00:06 -0000 Sam Hartman wrote: > Also, they get proxied, and we don't want that here (I don't think) We don't want this packet proxied. Alan DeKok. From nobody Mon Oct 27 03:07:40 2014 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 AEAA61A9028 for ; Mon, 27 Oct 2014 03:07:35 -0700 (PDT) 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 l1AJaefMDPlQ for ; Mon, 27 Oct 2014 03:07:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BDE51A9027 for ; Mon, 27 Oct 2014 03:07:32 -0700 (PDT) Received: from localhost ([::1]:50016 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XihCz-0000E1-Al; Mon, 27 Oct 2014 03:07:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com, stefan.winter@restena.lu X-Trac-Project: radext Date: Mon, 27 Oct 2014 10:07:29 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/183#comment:1 Message-ID: <078.b9286ec1e3124d63d68da523d9aa6f0e@trac.tools.ietf.org> References: <063.9b645a0504dc6867d7aa44c8deb37d91@trac.tools.ietf.org> X-Trac-Ticket-ID: 183 In-Reply-To: <063.9b645a0504dc6867d7aa44c8deb37d91@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/radext/yCa2oaIl3F4VMTErKCv7_Kc3pfs Cc: radext@ietf.org Subject: Re: [radext] #183 (dynamic-discovery): editorials X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 10:07:36 -0000 #183: editorials Changes (by stefan.winter@restena.lu): * status: new => closed * resolution: => fixed Comment: I have fixed the draft in these respects. Things to note: * "timeout" and "time out" still both occur (only "time-out" has gone) - the former is used as a noun, whereas the latter is used as a verb as in constructions like "connections time out after a while". I believe this is correct use and have left this. * "a NAI" is also fixed for "a NAIRealm" - all now use "an" * TTL and RR expanded, but "DNS", "PKI", "TLSA" do not need to be expanded as per the RFC Style Guideline (https://www.rfc-editor.org/rfc-style- guide/abbrev.expansion.txt) so I left them as-is All other bullets in this ticket were fixed verbatim in my working copy. I consider this ticket complete. -- ------------------------------------------+-------------------------------- Reporter: jouni.nospam@gmail.com | Owner: Type: enhancement | jouni.nospam@gmail.com Priority: trivial | Status: closed Component: dynamic-discovery | Milestone: Severity: Waiting for Shepherd Writeup | Version: Keywords: | Resolution: fixed ------------------------------------------+-------------------------------- Ticket URL: radext From nobody Mon Oct 27 03:14:19 2014 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 E04DC1A8FD4 for ; Mon, 27 Oct 2014 03:14:07 -0700 (PDT) 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 k-mrOA3K4oVT for ; Mon, 27 Oct 2014 03:14:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C98C1A8ADA for ; Mon, 27 Oct 2014 03:14:06 -0700 (PDT) Received: from localhost ([::1]:50356 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XihJN-0002ly-Pm; Mon, 27 Oct 2014 03:14:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com, stefan.winter@restena.lu X-Trac-Project: radext Date: Mon, 27 Oct 2014 10:14:05 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/184#comment:1 Message-ID: <078.da78f5b3a5ed804337c70ee1e5d59314@trac.tools.ietf.org> References: <063.ea5663ecba6396573cff16cbd3d98363@trac.tools.ietf.org> X-Trac-Ticket-ID: 184 In-Reply-To: <063.ea5663ecba6396573cff16cbd3d98363@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/radext/TcyeqHrtkiWwcVJMCIcgD8ZZXKA Cc: radext@ietf.org Subject: Re: [radext] #184 (dynamic-discovery): Major additions/deviations claims X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 10:14:08 -0000 #184: Major additions/deviations claims Changes (by stefan.winter@restena.lu): * status: new => closed * resolution: => fixed Comment: This comment is quite old; it referred to the original Diameter as per RFC3588, not the revision which still carried the same version number that is RFC6733. Since RFC6733 obsoletes RFC3588, I guess this sentence is also obsolete and I have deleted it from my working copy. This closes the ticket. -- ------------------------------------+------------------------------------- Reporter: jouni.nospam@gmail.com | Owner: jouni.nospam@gmail.com Type: defect | Status: closed Priority: major | Milestone: Component: dynamic-discovery | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+------------------------------------- Ticket URL: radext From nobody Mon Oct 27 03:21:41 2014 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 39C321A9033 for ; Mon, 27 Oct 2014 03:21:39 -0700 (PDT) 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 0MNrAE3Rf8Cc for ; Mon, 27 Oct 2014 03:21:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4B271A9031 for ; Mon, 27 Oct 2014 03:21:37 -0700 (PDT) Received: from localhost ([::1]:51282 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XihQd-0006Cf-DR; Mon, 27 Oct 2014 03:21:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com, stefan.winter@restena.lu X-Trac-Project: radext Date: Mon, 27 Oct 2014 10:21:35 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/185#comment:1 Message-ID: <078.f0296c74f9bb8c0f922beecd9cc2028a@trac.tools.ietf.org> References: <063.6b383665e49d6b669056a6a2651d4292@trac.tools.ietf.org> X-Trac-Ticket-ID: 185 In-Reply-To: <063.6b383665e49d6b669056a6a2651d4292@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/radext/xnA432SZEjWfgdAULtquqNNf-zg Cc: radext@ietf.org Subject: Re: [radext] #185 (dynamic-discovery): missing references X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 10:21:39 -0000 #185: missing references Changes (by stefan.winter@restena.lu): * status: new => closed * resolution: => fixed Comment: I have added the current version of the eduroam architecture draft as an Informational reference: draft-wierenga-ietf-eduroam-04.xml. The first mention of the word "eduroam" now references this draft. It is hopefully going to be published very soon as an RFC. This closes the ticket. -- ------------------------------------+------------------------------------- Reporter: jouni.nospam@gmail.com | Owner: jouni.nospam@gmail.com Type: defect | Status: closed Priority: minor | Milestone: Component: dynamic-discovery | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+------------------------------------- Ticket URL: radext From nobody Mon Oct 27 03:34:35 2014 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 095DD1A8A81 for ; Mon, 27 Oct 2014 03:34:33 -0700 (PDT) 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 38wyzog-v7Qk for ; Mon, 27 Oct 2014 03:34:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AC371A00B9 for ; Mon, 27 Oct 2014 03:34:30 -0700 (PDT) Received: from localhost ([::1]:51844 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xihd5-0002zh-TW; Mon, 27 Oct 2014 03:34:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com, stefan.winter@restena.lu X-Trac-Project: radext Date: Mon, 27 Oct 2014 10:34:27 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/186#comment:1 Message-ID: <078.82594231d790e793afe187070416cd74@trac.tools.ietf.org> References: <063.5f284cb003bf060a7627b3180720803e@trac.tools.ietf.org> X-Trac-Ticket-ID: 186 In-Reply-To: <063.5f284cb003bf060a7627b3180720803e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/radext/4zxjy2zXCLsHMyQIdzB2Dclpo_4 Cc: radext@ietf.org Subject: Re: [radext] #186 (dynamic-discovery): Routing error X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 10:34:33 -0000 #186: Routing error Changes (by stefan.winter@restena.lu): * status: new => closed * resolution: => fixed Comment: The error detection is specific to DNS; since RADIUS does not have the equivalent of a Route-Record AVP, this is the only place to put a loop detection. It's quite correct that Diameter has its own mechanism, and can thus ignore how the loop was constructed (i.e. leave DNS lookup loops as implementation specific). I have removed the parenthesis and added "during DNS lookups" to qualify the sentence. This should close the ticket. -- ------------------------------------+------------------------------------- Reporter: jouni.nospam@gmail.com | Owner: jouni.nospam@gmail.com Type: defect | Status: closed Priority: major | Milestone: Component: dynamic-discovery | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+------------------------------------- Ticket URL: radext From nobody Mon Oct 27 03:50:46 2014 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 9A97B1A90AF for ; Mon, 27 Oct 2014 03:50:41 -0700 (PDT) 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 HHd1AGrNY0LF for ; Mon, 27 Oct 2014 03:50:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C69A1A90A1 for ; Mon, 27 Oct 2014 03:50:34 -0700 (PDT) Received: from localhost ([::1]:52847 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xihsf-0001eQ-2u; Mon, 27 Oct 2014 03:50:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com, stefan.winter@restena.lu X-Trac-Project: radext Date: Mon, 27 Oct 2014 10:50:33 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/187#comment:1 Message-ID: <078.9fc02d07c7351d64e4450160cafebd10@trac.tools.ietf.org> References: <063.ba2b4bddc24d4cb1355d2b261657b2ec@trac.tools.ietf.org> X-Trac-Ticket-ID: 187 In-Reply-To: <063.ba2b4bddc24d4cb1355d2b261657b2ec@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/radext/iYz6pToMZt84bj9YaRJlAf8Fm5A Cc: radext@ietf.org Subject: Re: [radext] #187 (dynamic-discovery): Timeouts.. X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 10:50:41 -0000 #187: Timeouts.. Comment (by stefan.winter@restena.lu): I have changed the sentence to a relative, not an absolute statement: "much more in-depth guidance on DNS regarding timeouts, failure conditions, alteration of Time-To-Live (TTL) information than the Diameter counterpart" which makes the sentence more true than before. On the second part, TTL higher than certificate lifetime, this is out of scope for this specification: this draft specifies an algorithm on extracting connection-relevant data from DNS - and only that. The lifetime of a certificate is learned only later, when this list is used to establish a RADIUS/TLS connection with a discovered endpoint. The place to put a TTL restriction would thus be RFC6614, chapter "Connection Setup". Unfortunately, that RFC is silent on this matter :-( Since RFC6614 is currently being discussed for re-issue from Experimental to Standards track, I suggest to introduce the corresponding change in that RFC's "bis". Please let me know if that works for you and close the ticket if so. -- ------------------------------------+------------------------------------- Reporter: jouni.nospam@gmail.com | Owner: jouni.nospam@gmail.com Type: defect | Status: new Priority: major | Milestone: Component: dynamic-discovery | Version: Severity: - | Resolution: Keywords: | ------------------------------------+------------------------------------- Ticket URL: radext From nobody Mon Oct 27 04:02:54 2014 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 575DF1A90A3 for ; Mon, 27 Oct 2014 04:02:52 -0700 (PDT) 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 6syXaFTX6OCM for ; Mon, 27 Oct 2014 04:02:50 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2149C1A8A57 for ; Mon, 27 Oct 2014 04:02:50 -0700 (PDT) Received: from localhost ([::1]:53407 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xii4V-0004IG-QB; Mon, 27 Oct 2014 04:02:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com, stefan.winter@restena.lu X-Trac-Project: radext Date: Mon, 27 Oct 2014 11:02:47 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/188#comment:1 Message-ID: <078.352830fa570a638c13f95a7d9d979ffb@trac.tools.ietf.org> References: <063.d47d4674d3200d8f248a9cc868cbbe46@trac.tools.ietf.org> X-Trac-Ticket-ID: 188 In-Reply-To: <063.d47d4674d3200d8f248a9cc868cbbe46@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/radext/1sonPCBLe0vT06rkdjpV_F6j8cM Cc: radext@ietf.org Subject: Re: [radext] #188 (dynamic-discovery): Application Service and Protocol Tags X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 11:02:52 -0000 #188: Application Service and Protocol Tags Changes (by stefan.winter@restena.lu): * status: new => closed * resolution: => fixed Comment: Good point; the tags are now changed. This closes the ticket. -- ------------------------------------+------------------------------------- Reporter: jouni.nospam@gmail.com | Owner: jouni.nospam@gmail.com Type: defect | Status: closed Priority: major | Milestone: Component: dynamic-discovery | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+------------------------------------- Ticket URL: radext From nobody Mon Oct 27 04:19:33 2014 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 966681A8F49 for ; Mon, 27 Oct 2014 04:19:31 -0700 (PDT) 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 rIe-RfA43TF3 for ; Mon, 27 Oct 2014 04:19:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FBFC1A6F34 for ; Mon, 27 Oct 2014 04:19:30 -0700 (PDT) Received: from localhost ([::1]:54885 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XiiKX-0004IH-DZ; Mon, 27 Oct 2014 04:19:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com, stefan.winter@restena.lu X-Trac-Project: radext Date: Mon, 27 Oct 2014 11:19:21 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/189#comment:1 Message-ID: <078.90b6aff049c1464d1263fb3a4e732b94@trac.tools.ietf.org> References: <063.4785bcc57d94228bd8e3b91295e03e3c@trac.tools.ietf.org> X-Trac-Ticket-ID: 189 In-Reply-To: <063.4785bcc57d94228bd8e3b91295e03e3c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/radext/7BhRnGosDXZP6QIhwmtEB5bWFtM Cc: radext@ietf.org Subject: Re: [radext] #189 (dynamic-discovery): SRV protocol registry X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 11:19:31 -0000 #189: SRV protocol registry Comment (by stefan.winter@restena.lu): This is about the "Proto" field for the SRV RR. I see that the original RFC2782 already uses _tcp and _udp in its examples and considers them useful, but this has never made its way into an actual registry entry at IANA as far as I can see. Other (new) protocol tags have been defined properly, e.g. https://www.iana.org/assignments/im-srv-labels/im-srv-labels.xhtml#im-srv- labels-1 In the absence of an existing IANA registry specifically for _tcp and _udp, I was trying to create one. If we can consider those two existing by legacy or via some implicit rule (which I still don't "get" after reading your comment), I can also drop the paragraph. For the sake of releasing -12 before the cutoff, I'll comment out the section and we can think plentiful about whether it should rather be in at a later point. -- ------------------------------------+------------------------------------- Reporter: jouni.nospam@gmail.com | Owner: jouni.nospam@gmail.com Type: task | Status: new Priority: minor | Milestone: Component: dynamic-discovery | Version: Severity: - | Resolution: Keywords: | ------------------------------------+------------------------------------- Ticket URL: radext From nobody Mon Oct 27 04:25:37 2014 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 9C49B1A90CD for ; Mon, 27 Oct 2014 04:25:32 -0700 (PDT) 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 GGT6F6G_JhH4 for ; Mon, 27 Oct 2014 04:25:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FC601A90C2 for ; Mon, 27 Oct 2014 04:25:30 -0700 (PDT) Received: from localhost ([::1]:55387 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XiiQS-00088G-W3; Mon, 27 Oct 2014 04:25:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com, stefan.winter@restena.lu X-Trac-Project: radext Date: Mon, 27 Oct 2014 11:25:28 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/189#comment:2 Message-ID: <078.cbc5229155b545acafc5dd06d16d0f25@trac.tools.ietf.org> References: <063.4785bcc57d94228bd8e3b91295e03e3c@trac.tools.ietf.org> X-Trac-Ticket-ID: 189 In-Reply-To: <063.4785bcc57d94228bd8e3b91295e03e3c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/radext/TYDEG2ucl6_ST-aVi1rPauuXznQ Cc: radext@ietf.org Subject: Re: [radext] #189 (dynamic-discovery): SRV protocol registry X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 11:25:32 -0000 #189: SRV protocol registry Comment (by stefan.winter@restena.lu): In fact, I didn't want to leave this out completely, so added my reasoning in an extra paragraph: "This specification makes use of the SRV Protocol identifiers "_tcp" and "_udp" which are mentioned as early as [RFC2782] but do not appear to be assigned in an actual registry. Since they are in wide- spread use in other protocols, this specification refrains from requesting a new registry "RADIUS/TLS SRV Protocol Registry" and continues to make use of these tags implicitly." -- ------------------------------------+------------------------------------- Reporter: jouni.nospam@gmail.com | Owner: jouni.nospam@gmail.com Type: task | Status: new Priority: minor | Milestone: Component: dynamic-discovery | Version: Severity: - | Resolution: Keywords: | ------------------------------------+------------------------------------- Ticket URL: radext From nobody Mon Oct 27 04:38:00 2014 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 149171A90D7; Mon, 27 Oct 2014 04:37:57 -0700 (PDT) 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 GtReAWShlz7e; Mon, 27 Oct 2014 04:37:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D62351A9069; Mon, 27 Oct 2014 04:37:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027113755.25666.20848.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 04:37:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/03RLQs5_yemYnVA1BecUnAauIWU Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-dynamic-discovery-12.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, 27 Oct 2014 11:37:57 -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 : NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Authors : Stefan Winter Mike McCauley Filename : draft-ietf-radext-dynamic-discovery-12.txt Pages : 28 Date : 2014-10-27 Abstract: This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS/TLS and RADIUS/DTLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-dynamic-discovery-12 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 Oct 27 05:12:04 2014 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 AFC721A9237 for ; Mon, 27 Oct 2014 05:11:58 -0700 (PDT) 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 e70l79FekEK4 for ; Mon, 27 Oct 2014 05:11:55 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D41C1A9173 for ; Mon, 27 Oct 2014 05:11:51 -0700 (PDT) Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id 9A264403B7 for ; Mon, 27 Oct 2014 13:11:49 +0100 (CET) Message-ID: <544E3685.6010906@restena.lu> Date: Mon, 27 Oct 2014 13:11:49 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "radext@ietf.org" References: <20141027115149.1961.53790.idtracker@ietfa.amsl.com> In-Reply-To: <20141027115149.1961.53790.idtracker@ietfa.amsl.com> OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 X-Forwarded-Message-Id: <20141027115149.1961.53790.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NmlP671J998g1f5PsdiJk3tPRt4wRRC5k" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/Fq-1HS3QIbsy5Ts0gpDhM13SSnY Subject: [radext] Fwd: New Version Notification for draft-winter-radext-populating-eapidentity-01.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, 27 Oct 2014 12:11:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NmlP671J998g1f5PsdiJk3tPRt4wRRC5k Content-Type: multipart/mixed; boundary="------------010509070508020406020608" This is a multi-part message in MIME format. --------------010509070508020406020608 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, just to let you know that I've updated my "homeless" draft regarding the interplay of EAP methods, EAP-Response/Identity and the AAA User-Name fie= ld. As per the discussion at IETF90, I have removed the claim that intermediate proxies or pass-through authenticators might drop the packet due to malformedness as this has not been observed in the wild. The general point in that regard, the possibility of mis-routing the packet due to different interpretations of the content by intermediate systems, is still as valid as it was before :-) There was a comment about RFC3748 and RFC3579's identity hints in EAP-Request/Identity which could help alleviate one of the two problems in the draft (client has multiple identities to choose from; and EAP negotiation is not enough for an exhaustive try). The provisions in RFC3579 are not sufficient to solve the problem, becaus= e * EAP-Request/Identity is optional in some scenarios; peers can (and at least in the Wi-Fi case, typically *do*) initiate the conversation with their EAP-Response/Identity (EAPoL-Start) immediately; i.e. they make the identity selection at a point in time where no hint is available * EAP-Request/Identity may be sent by the NAS instead of the EAP server, and the NAS may not have all identity hints available if it is part of a large multi-operator network (e.g. if a roaming consortium contains thousands of realms, while the NAS only has a "Default Route" to a clearinghouse). * The piggybacking of identity hints in EAP-Request/Identity after a NUL separator is in general a horrible hack. It is bound to fail *at least* in a situation where the list of acceptable realms gets longer than 1020 octets (which is a tiny amount when again looking at a roaming consortium with thousands of realms), see RFC3748 section 5.1. So even if the NAS or a RADIUS server has the full list of realms, it may not be able to send it. A much more general solution than trailing bytes in an optional Request packet are needed, unfortunately. Also, none of this removes the second problem which the draft addresses, namely the requirement of UTF-8 encoding for the EAP-Response/Identity. Greetings, Stefan Winter -------- Forwarded Message -------- Subject: New Version Notification for draft-winter-radext-populating-eapidentity-01.txt Date: Mon, 27 Oct 2014 04:51:49 -0700 From: internet-drafts@ietf.org To: Stefan Winter , Stefan Winter A new version of I-D, draft-winter-radext-populating-eapidentity-01.txt has been successfully submitted by Stefan Winter and posted to the IETF repository. Name: draft-winter-radext-populating-eapidentity Revision: 01 Title: Considerations regarding the correct use of EAP-Response/Identity= Document date: 2014-10-27 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-winter-radext-populating-eapide= ntity-01.txt Status: https://datatracker.ietf.org/doc/draft-winter-radext-populating-eapidenti= ty/ Htmlized: http://tools.ietf.org/html/draft-winter-radext-populating-eapidentity-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-winter-radext-populating-eapiden= tity-01 Abstract: There are some subtle considerations for an EAP peer regarding the content of the EAP-Response/Identity packet when authenticating with EAP to an EAP server. This document describes two such considerations and suggests workarounds to the associated problems. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------010509070508020406020608 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.0.22 (GNU/Linux) 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----- --------------010509070508020406020608-- --NmlP671J998g1f5PsdiJk3tPRt4wRRC5k Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJUTjaFAAoJEMDeajWKOdxms+gQAJd2HzPuB9kkSb+ZI9NnSy+Z GUGQXHSvtUohrq9M+VyjLhzfSMkCg5PV4WqZKKc69mNI5KeZztx+Ek5p6gk8S2YQ CDld0hf+4EY62iUFTJXmZS3p9/GZkvni+oypkt0laQ6dyDTyqP3s84tfUhO4BBiE gIsmeOZ6kYmPRgsO4JME+DRCFnWqXxCJkGzBSIerTtr+jL9SsqdHC27yLFmAZ1MO vq3eg/2hcyN2hlt1sSn9ldmNKn1hjZ0963XYdU/EpoNUazh6PYfbEIlcgOnaFYfg +CR/Pb3O62qro7Y52H3SSU7lg4NMHx8xSfufCPab5SrGR/gEJJ3LtzC9hDw7Nc4A 9w7rhXFdib2LNvu1XxJ+U4Fyee6vwlPbPQ7pl84ZncRHJUYeIhYhpG6+J4QFLjfX guHnUQSRfjgf8znujJVqKi2Tgvc9V/hEDIROK+3N+kv0ha5zOoHtFw6qhEGmWFCz nVwJQfdl5aWVjJo6PHfCKW6tDIOOfEFg1JONuHApBEQWegimXeOhkmCTvTm2LWwS Fqy24IRA/oP1UJiVRRDFZerRKyJG7OhQ2coBxZBshl2NyDQpvU32UF1Jowyfyw5e 9xNuavlMjOf6mDk8zetdPIMXWrRW04SFGB0glVCgFWjZHPq2hK8S3Qn1yqkLR6qR qsFWMTQL+L9QXkWq2xpR =o5Rl -----END PGP SIGNATURE----- --NmlP671J998g1f5PsdiJk3tPRt4wRRC5k-- From nobody Tue Oct 28 15:51:44 2014 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 0D35A1A03E3 for ; Tue, 28 Oct 2014 15:51:42 -0700 (PDT) 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 tHMBLoZCw_ZO for ; Tue, 28 Oct 2014 15:51:39 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFD3F1A00D7 for ; Tue, 28 Oct 2014 15:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8742; q=dns/txt; s=iport; t=1414536699; x=1415746299; h=message-id:date:from:mime-version:to:subject; bh=EQbldYozwyZQ+0rS2g4HDKPPo/FCGU00a9UM+1tyuTk=; b=mT9zs1CUCuIr/gb6c85RMRkWfK9DxLFi5jnRT0mdwc7F8gcKRgOmfSEH n91NG9Fl6if8PWQ8ZsmxRB5QqjZcBTFFldlmqy2pWZRP0NqVZe23Jrcum m9FWtXTc/b+bP4mbyZUmIEdi90c9PLKF4X9m16p3yrhJuBpLPeXnINHTS 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukEADUdUFStJssW/2dsb2JhbABcg2JYAYhgw3aBcIkCAQEBAQF9hQE9FhgDAgECAUsBDAgBARCILQ3FZQEBAQEGAQEBAQEdkESFFwWWVYJDhFCBbYYBjkiDeTwvAYJKAQEB X-IronPort-AV: E=Sophos;i="5.04,805,1406592000"; d="scan'208,217";a="228878737" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 28 Oct 2014 22:51:37 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9SMpaqE013834; Tue, 28 Oct 2014 22:51:36 GMT Message-ID: <54501DF8.3070802@cisco.com> Date: Tue, 28 Oct 2014 23:51:36 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: draft-ietf-radext-nai@tools.ietf.org, "radext@ietf.org" Content-Type: multipart/alternative; boundary="------------000808020402010900090000" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/7fE7ecd6dHB_iNgi9Rot3mvL6Gw Subject: [radext] draft-ietf-radext-nai-08 AD review 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, 28 Oct 2014 22:51:42 -0000 This is a multi-part message in MIME format. --------------000808020402010900090000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is my draft-ietf-radext-nai-08 AD review _Technical:_ - AAA systems MUST therefore be able to handle user identifiers which are not in the NAI format. ... Systems MAY accept user identifiers in forms other than the NAI. These are contradictory. I believe that: - those two sentences (or paragraphs) should be next to each others. - the second sentence should stress "Non AAA systems" _Systems_MAY accept user identifiers in forms other than the NAI. This specification does not forbid that practice. It only codifies the format and interpretation of the NAI. We cannot expect to change existing protocols or practices. We can, however, suggest that using a consistent form for a user identifier is of a benefit to the community. Where protocols carry identifiers which are expected to be transported over an AAA protocol, it is RECOMMENDED that the identifiers be in NAI format. Where the identifiers are not in the NAI format, it is up to the_AAA systems_ to discover this, and to process them. This document does not suggest how that is done. However, existing practice indicates that it is possible. Be consistent between systems, non-AAA systems, and AAA systems Editorial: - when you produce a new draft version, don't forget http://tools.ietf.org/wg/radext/trac/ticket/176 - Considerable interest exists for a set of features that fit within the general category of inter-domain authentiction authentication - Normalization Canonicalization These terms are defined in[RFC6365] Section 4 . We incorporate the definitions here by reference. Isn't "Normalization or Canonicalization" - Like mentioned in the last bullet point below, all links should point to the RFC4282 sections, not to draft-ietf-radext-nai-08 sections. * The requirement inSection 2.1 that realms are ASCII conflicts with the Extensible Authentication Protocol (EAP) and RADIUS, which are both 8-bit clean, and which both recommend the use of UTF-8 for identitifiers. *Section 2.4 required mappings that are language-specific, and which are nearly impossible for intermediate nodes to perform correctly without information about that language. *Section 2.4 requires normalization of user names, which may conflict with local system or administrative requirements. * The recommendations inSection 2.4 for treatment of bidirectional characters have proven to be unworkable. * The prohibition against use of unassigned code points in Section 2.4 effectively prohibits support for new scripts. * No Authentication, Authorization, and Accounting (AAA) client, proxy, or server has implemented any of the requirements in[RFC4282] Section 2.4 , among other sections. - 5 . Administration of Names In order to avoid creating any new administrative procedures, administration of the NAI realm namespace piggybacks on the administration of the DNS namespace. There is a tag issue above. The section tag contains the first line of section 5. Regards, Benoit --------------000808020402010900090000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Here is my draft-ietf-radext-nai-08 AD review

Technical:
- 
   AAA systems MUST therefore be
   able to handle user identifiers which are not in the NAI format. 
   ...

   Systems MAY accept user identifiers in forms other than the NAI.
These are contradictory.
I believe that:
- those two sentences (or paragraphs) should be next to each others.
- the second sentence should stress "Non AAA systems"

   Systems MAY accept user identifiers in forms other than the NAI.
   This specification does not forbid that practice.  It only codifies
   the format and interpretation of the NAI.  We cannot expect to change
   existing protocols or practices.  We can, however, suggest that using
   a consistent form for a user identifier is of a benefit to the
   community.

   Where protocols carry identifiers which are expected to be
   transported over an AAA protocol, it is RECOMMENDED that the
   identifiers be in NAI format.  Where the identifiers are not in the
   NAI format, it is up to the AAA systems to discover this, and to
   process them.  This document does not suggest how that is done.
   However, existing practice indicates that it is possible.
Be consistent between systems, non-AAA systems, and AAA systems

Editorial:

-
when you produce a new draft version, don't forget http://tools.ietf.org/wg/radext/trac/ticket/176

-
  Considerable interest exists for a set of features that fit within
   the general category of inter-domain authentiction

authentication

- 
   Normalization Canonicalization

      These terms are defined in [RFC6365] Section 4.  We incorporate
      the definitions here by reference.
Isn't "Normalization or Canonicalization"

- Like mentioned in the last bullet point below, all links should point to the RFC4282 sections, not to draft-ietf-radext-nai-08 sections.
   *  The requirement in Section 2.1 that realms are ASCII conflicts
      with the Extensible Authentication Protocol (EAP) and RADIUS,
      which are both 8-bit clean, and which both recommend the use of
      UTF-8 for identitifiers.

   * Section 2.4 required mappings that are language-specific,
      and which are nearly impossible for intermediate nodes to perform
      correctly without information about that language.

   * Section 2.4 requires normalization of user names, which
      may conflict with local system or administrative requirements.

   * The recommendations in Section 2.4 for treatment of
      bidirectional characters have proven to be unworkable.

   * The prohibition against use of unassigned code points in
      Section 2.4 effectively prohibits support for new scripts.

   * No Authentication, Authorization, and Accounting (AAA)
      client, proxy, or server has implemented any of the requirements
      in [RFC4282] Section 2.4, among other sections.


- 
5.  Administration of Names


   In order to avoid creating any new administrative procedures,

   administration of the NAI realm namespace piggybacks on the
   administration of the DNS namespace.

There is a tag issue above. The section tag contains the first line of section 5.
Regards, Benoit
--------------000808020402010900090000-- From nobody Wed Oct 29 08:21:41 2014 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 27E441A01D5 for ; Wed, 29 Oct 2014 08:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 1bXKSnwa2ogh for ; Wed, 29 Oct 2014 08:21:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 504041A0636 for ; Wed, 29 Oct 2014 08:21:30 -0700 (PDT) Received: from localhost ([::1]:41124 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XjV3t-0007Av-Aq; Wed, 29 Oct 2014 08:21:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-nai@tools.ietf.org, aland@deployingradius.com, stefan.winter@restena.lu X-Trac-Project: radext Date: Wed, 29 Oct 2014 15:21:25 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/176#comment:5 Message-ID: <080.2fda28bf50b9db6261af4ec8015b3e0f@trac.tools.ietf.org> References: <065.18ebd81ae64d013f63a780221f34a543@trac.tools.ietf.org> X-Trac-Ticket-ID: 176 In-Reply-To: <065.18ebd81ae64d013f63a780221f34a543@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-nai@tools.ietf.org, aland@deployingradius.com, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@freeradius.org Archived-At: http://mailarchive.ietf.org/arch/msg/radext/16hehl8UgC26s8PxVAQ7-peDdxU Cc: radext@ietf.org Subject: Re: [radext] #176 (nai): draft-ietf-radext-nai-05: is the term *Network Access* Identifier still appropriate? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:21:34 -0000 #176: draft-ietf-radext-nai-05: is the term *Network Access* Identifier still appropriate? Changes (by aland@deployingradius.com): * status: new => closed * resolution: => fixed Comment: fixed. I'll push out a new version as soon as I'm allowed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | nai@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: nai | Version: Severity: Waiting for Shepherd | Resolution: fixed Writeup | Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Wed Oct 29 10:41:39 2014 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 C49AA1A8708; Wed, 29 Oct 2014 10:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=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 8QArOy8Tw72m; Wed, 29 Oct 2014 10:41:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A1F1A8737; Wed, 29 Oct 2014 10:41:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141029174123.12598.39479.idtracker@ietfa.amsl.com> Date: Wed, 29 Oct 2014 10:41:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/8N563CyHsQHCM88hdj2yNgVJ7dA Cc: radext@ietf.org Subject: [radext] I-D ACTION:draft-ietf-radext-nai-09.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: Wed, 29 Oct 2014 17:41:36 -0000 --NextPart 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 : The Network Access Identifier Author(s) : A. DeKok Filename : draft-ietf-radext-nai Pages : 25 Date : 2014-10-29 In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client prior to accessing network resources. This document is a revised version of RFC 4282, which addresses issues with international character sets, as well as a number of other corrections to the previous document. A URL for this Internet-Draft is: https://www.ietf.org/internet-drafts/draft-ietf-radext-nai-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-nai"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-10-29104123.I-D@ietf.org> --NextPart-- From nobody Wed Oct 29 13:05:46 2014 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 A8A9A1A8982 for ; Wed, 29 Oct 2014 13:05:42 -0700 (PDT) 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 vt8BsjcHrpC1 for ; Wed, 29 Oct 2014 13:05:40 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 163821A88AF for ; Wed, 29 Oct 2014 13:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10442; q=dns/txt; s=iport; t=1414613115; x=1415822715; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=cgH78YIfopJ+Ds3UYgDDKyr6U87KUZpr6GrNh3ubZrk=; b=lrVPRjfd10FxjJ/1RRKckAHs1Ww0P/7nU3PJs8n0XyFXJb70sthSkweU N/fzKKE9HJ6v0ADl0GFNL9k4OCUldh0YFFPB+Sz8meHYRZ3n+9WpIh5EO fILUGeGU5EJiGM4V59V7VDcs+YcUZ5cdy34mmpHRP7+CSGjTaRnl3ie5x A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwEAIZHUVStJssW/2dsb2JhbABcg2JYzhsBCYZ5VAKBNAEBAQEBfYQDAQEEAQEBawoRCyEMCg8JAwIBAgEVMAYBDAYCAQEQiC0NyCMBAQEBAQEBAQEBAQEBAQEBAQEBGZBLTAqEQQWWV4JDhFCBbYYCjlGDeTwvAYJKAQEB X-IronPort-AV: E=Sophos;i="5.07,279,1413244800"; d="scan'208,217";a="225289394" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 29 Oct 2014 20:05:12 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9TK5BdW002039; Wed, 29 Oct 2014 20:05:11 GMT Message-ID: <54514876.9010105@cisco.com> Date: Wed, 29 Oct 2014 21:05:10 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: draft-ietf-radext-nai@tools.ietf.org, "radext@ietf.org" References: <54501DF8.3070802@cisco.com> In-Reply-To: <54501DF8.3070802@cisco.com> Content-Type: multipart/alternative; boundary="------------070802040405080902030003" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/WCRCeDEx4M11tvTknp_GY0BXVZs Subject: Re: [radext] draft-ietf-radext-nai-08 AD review 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, 29 Oct 2014 20:05:42 -0000 This is a multi-part message in MIME format. --------------070802040405080902030003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Alan, Thanks for the version 9. The technical comment has been taken care of. Thanks. It's however a missed opportunity not to have taken into account the editorial comments below. Regards, Benoit > Dear all, > > Here is my draft-ietf-radext-nai-08 AD review > > _Technical:_ > - > AAA systems MUST therefore be > able to handle user identifiers which are not in the NAI format. > ... > > Systems MAY accept user identifiers in forms other than the NAI. > These are contradictory. > I believe that: > - those two sentences (or paragraphs) should be next to each others. > - the second sentence should stress "Non AAA systems" > > _Systems_MAY accept user identifiers in forms other than the NAI. > This specification does not forbid that practice. It only codifies > the format and interpretation of the NAI. We cannot expect to change > existing protocols or practices. We can, however, suggest that using > a consistent form for a user identifier is of a benefit to the > community. > > Where protocols carry identifiers which are expected to be > transported over an AAA protocol, it is RECOMMENDED that the > identifiers be in NAI format. Where the identifiers are not in the > NAI format, it is up to the_AAA systems_ to discover this, and to > process them. This document does not suggest how that is done. > However, existing practice indicates that it is possible. > Be consistent between systems, non-AAA systems, and AAA systems > > Editorial: > > - > when you produce a new draft version, don't forget > http://tools.ietf.org/wg/radext/trac/ticket/176 > > - > Considerable interest exists for a set of features that fit within > the general category of inter-domain authentiction > > authentication > > - > Normalization Canonicalization > > These terms are defined in[RFC6365] Section 4 . We incorporate > the definitions here by reference. > Isn't "Normalization or Canonicalization" > > - Like mentioned in the last bullet point below, all links should > point to the RFC4282 sections, not to draft-ietf-radext-nai-08 sections. > * The requirement inSection 2.1 that realms are ASCII conflicts > with the Extensible Authentication Protocol (EAP) and RADIUS, > which are both 8-bit clean, and which both recommend the use of > UTF-8 for identitifiers. > > *Section 2.4 required mappings that are language-specific, > and which are nearly impossible for intermediate nodes to perform > correctly without information about that language. > > *Section 2.4 requires normalization of user names, which > may conflict with local system or administrative requirements. > > * The recommendations inSection 2.4 for treatment of > bidirectional characters have proven to be unworkable. > > * The prohibition against use of unassigned code points in > Section 2.4 effectively prohibits support for new scripts. > > * No Authentication, Authorization, and Accounting (AAA) > client, proxy, or server has implemented any of the requirements > in[RFC4282] Section 2.4 , among other sections. > > > - > > > 5 . > Administration of Names > > > In order to avoid creating any new administrative procedures, > > > administration of the NAI realm namespace piggybacks on the > administration of the DNS namespace. > > There is a tag issue above. The section tag contains the first line of section 5. > > Regards, Benoit > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------070802040405080902030003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Alan,

Thanks for the version 9.
The technical comment has been taken care of. Thanks.
It's however a missed opportunity not to have taken into account the editorial comments below.

Regards, Benoit
Dear all,

Here is my draft-ietf-radext-nai-08 AD review

Technical:
- 
   AAA systems MUST therefore be
   able to handle user identifiers which are not in the NAI format. 
   ...

   Systems MAY accept user identifiers in forms other than the NAI.
These are contradictory.
I believe that:
- those two sentences (or paragraphs) should be next to each others.
- the second sentence should stress "Non AAA systems"

   Systems MAY accept user identifiers in forms other than the NAI.
   This specification does not forbid that practice.  It only codifies
   the format and interpretation of the NAI.  We cannot expect to change
   existing protocols or practices.  We can, however, suggest that using
   a consistent form for a user identifier is of a benefit to the
   community.

   Where protocols carry identifiers which are expected to be
   transported over an AAA protocol, it is RECOMMENDED that the
   identifiers be in NAI format.  Where the identifiers are not in the
   NAI format, it is up to the AAA systems to discover this, and to
   process them.  This document does not suggest how that is done.
   However, existing practice indicates that it is possible.
Be consistent between systems, non-AAA systems, and AAA systems

Editorial:

-
when you produce a new draft version, don't forget http://tools.ietf.org/wg/radext/trac/ticket/176

-
  Considerable interest exists for a set of features that fit within
   the general category of inter-domain authentiction

authentication

- 
   Normalization Canonicalization

      These terms are defined in [RFC6365] Section 4.  We incorporate
      the definitions here by reference.
Isn't "Normalization or Canonicalization"

- Like mentioned in the last bullet point below, all links should point to the RFC4282 sections, not to draft-ietf-radext-nai-08 sections.
   *  The requirement in Section 2.1 that realms are ASCII conflicts
      with the Extensible Authentication Protocol (EAP) and RADIUS,
      which are both 8-bit clean, and which both recommend the use of
      UTF-8 for identitifiers.

   * Section 2.4 required mappings that are language-specific,
      and which are nearly impossible for intermediate nodes to perform
      correctly without information about that language.

   * Section 2.4 requires normalization of user names, which
      may conflict with local system or administrative requirements.

   * The recommendations in Section 2.4 for treatment of
      bidirectional characters have proven to be unworkable.

   * The prohibition against use of unassigned code points in
      Section 2.4 effectively prohibits support for new scripts.

   * No Authentication, Authorization, and Accounting (AAA)
      client, proxy, or server has implemented any of the requirements
      in [RFC4282] Section 2.4, among other sections.


- 
5.  Administration of Names


   In order to avoid creating any new administrative procedures,

   administration of the NAI realm namespace piggybacks on the
   administration of the DNS namespace.

There is a tag issue above. The section tag contains the first line of section 5.
Regards, Benoit


_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

--------------070802040405080902030003-- From nobody Wed Oct 29 13:28:22 2014 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 AD0C01A88C8 for ; Wed, 29 Oct 2014 13:28:19 -0700 (PDT) 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 Nn10RXJRfpgg for ; Wed, 29 Oct 2014 13:28:17 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id C55DB1A0154 for ; Wed, 29 Oct 2014 13:28:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 1292D2240404; Wed, 29 Oct 2014 21:28:16 +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 6fQAKENsrahw; Wed, 29 Oct 2014 21:28:15 +0100 (CET) Received: from Thor.local (206-248-157-156.dsl.teksavvy.com [206.248.157.156]) by power.freeradius.org (Postfix) with ESMTPSA id D83D8224021D; Wed, 29 Oct 2014 21:28:14 +0100 (CET) Message-ID: <54514DDD.8090401@deployingradius.com> Date: Wed, 29 Oct 2014 16:28:13 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Benoit Claise References: <54501DF8.3070802@cisco.com> <54514876.9010105@cisco.com> In-Reply-To: <54514876.9010105@cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/SlV6b4BkiYl6Oom_g5PcgGsuYtg Cc: "radext@ietf.org" , draft-ietf-radext-nai@tools.ietf.org Subject: Re: [radext] draft-ietf-radext-nai-08 AD review 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, 29 Oct 2014 20:28:19 -0000 Benoit Claise wrote: > > Alan, > > Thanks for the version 9. > The technical comment has been taken care of. Thanks. > It's however a missed opportunity not to have taken into account the > editorial comments below. I thought I had done that... - "systems" qualified to non-AAA, AAA, and edge - re-work the contradictory sentences - etc. > Regards, Benoit >> Dear all, >> >> Here is my draft-ietf-radext-nai-08 AD review >> >> _Technical:_ >> - >> AAA systems MUST therefore be >> able to handle user identifiers which are not in the NAI format. >> ... >> >> Systems MAY accept user identifiers in forms other than the NAI. >> These are contradictory. >> I believe that: >> - those two sentences (or paragraphs) should be next to each others. >> - the second sentence should stress "Non AAA systems" >> >> _Systems _MAY accept user identifiers in forms other than the NAI. >> This specification does not forbid that practice. It only codifies >> the format and interpretation of the NAI. We cannot expect to change >> existing protocols or practices. We can, however, suggest that using >> a consistent form for a user identifier is of a benefit to the >> community. >> >> Where protocols carry identifiers which are expected to be >> transported over an AAA protocol, it is RECOMMENDED that the >> identifiers be in NAI format. Where the identifiers are not in the >> NAI format, it is up to the _AAA systems_ to discover this, and to >> process them. This document does not suggest how that is done. >> However, existing practice indicates that it is possible. >> Be consistent between systems, non-AAA systems, and AAA systems >> >> Editorial: >> >> - >> when you produce a new draft version, don't forget >> http://tools.ietf.org/wg/radext/trac/ticket/176 >> >> - >> Considerable interest exists for a set of features that fit within >> the general category of inter-domain authentiction >> >> authentication >> >> - >> Normalization Canonicalization >> >> These terms are defined in [RFC6365] Section 4 . We incorporate >> the definitions here by reference. >> Isn't "Normalization or Canonicalization" >> >> - Like mentioned in the last bullet point below, all links should >> point to the RFC4282 sections, not to draft-ietf-radext-nai-08 sections. >> * The requirement in Section 2.1 that realms are ASCII conflicts >> with the Extensible Authentication Protocol (EAP) and RADIUS, >> which are both 8-bit clean, and which both recommend the use of >> UTF-8 for identitifiers. >> >> * Section 2.4 required mappings that are language-specific, >> and which are nearly impossible for intermediate nodes to perform >> correctly without information about that language. >> >> * Section 2.4 requires normalization of user names, which >> may conflict with local system or administrative requirements. >> >> * The recommendations in Section 2.4 for treatment of >> bidirectional characters have proven to be unworkable. >> >> * The prohibition against use of unassigned code points in >> Section 2.4 effectively prohibits support for new scripts. >> >> * No Authentication, Authorization, and Accounting (AAA) >> client, proxy, or server has implemented any of the requirements >> in [RFC4282] Section 2.4 , among other sections. >> >> >> - >> >> >> 5 . >> Administration of Names >> >> >> In order to avoid creating any new administrative procedures, >> >> >> administration of the NAI realm namespace piggybacks on the >> administration of the DNS namespace. >> >> There is a tag issue above. The section tag contains the first line of section 5. >> >> Regards, Benoit >> >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext > From nobody Wed Oct 29 13:44:43 2014 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 6902C1A8AC0 for ; Wed, 29 Oct 2014 13:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 AxtBWJBKIa73 for ; Wed, 29 Oct 2014 13:44:39 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC391A8ABC for ; Wed, 29 Oct 2014 13:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7060; q=dns/txt; s=iport; t=1414615478; x=1415825078; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=DzlGgFA3npqMx38Eeh9WjQdDv7WD7jLCpghE3UhpWSo=; b=Hs/xNvlcTLsuQMBwuD0kRfaDyuHOaLoaToTOLoCVat1TkCy3e2vX4HVv ec2p5trIDXZFOTBxE+6wHSGsAg4+qj5bxMs8p8+lXM2QvlOlziRr43Fyk M6upmtl2IlEoeLT4vh5Vut+KYKO/ACJhhKDyZtitGFMJeIja9XrpBKGIm U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsEAGZRUVStJssW/2dsb2JhbABcg2JYzhsKhnlUAoE0AQEBAQF9hAIBAQEDAQEBATU2CxALGAkMGQ8CFjAGDQEFAgEBEIgkCQ3IGgEBAQEBAQEBAQEBAQEBAQEBAQEBAReQS0UHCoRBBZZXgkOEUIFthgKOUYN5PC8BgkoBAQE X-IronPort-AV: E=Sophos;i="5.07,279,1413244800"; d="scan'208";a="225292729" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 29 Oct 2014 20:44:16 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9TKiGLU004187; Wed, 29 Oct 2014 20:44:16 GMT Message-ID: <545151A0.40007@cisco.com> Date: Wed, 29 Oct 2014 21:44:16 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Alan DeKok References: <54501DF8.3070802@cisco.com> <54514876.9010105@cisco.com> <54514DDD.8090401@deployingradius.com> In-Reply-To: <54514DDD.8090401@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/91ey7w4CJ2whDdH7kL1TJ0_gu94 Cc: "radext@ietf.org" , draft-ietf-radext-nai@tools.ietf.org Subject: Re: [radext] draft-ietf-radext-nai-08 AD review 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, 29 Oct 2014 20:44:41 -0000 On 29/10/2014 21:28, Alan DeKok wrote: > Benoit Claise wrote: >> Alan, >> >> Thanks for the version 9. >> The technical comment has been taken care of. Thanks. >> It's however a missed opportunity not to have taken into account the >> editorial comments below. > I thought I had done that... > > - "systems" qualified to non-AAA, AAA, and edge > > - re-work the contradictory sentences > > - etc. - Considerable interest exists for a set of features that fit within the general category of inter-domain authentiction authentication - Normalization Canonicalization These terms are defined in [RFC6365] Section 4 . We incorporate the definitions here by reference. Isn't "Normalization or Canonicalization" - Like mentioned in the last bullet point below, all links should point to the RFC4282 sections, not to draft-ietf-radext-nai-08 sections. * The requirement in Section 2.1 that realms are ASCII conflicts with the Extensible Authentication Protocol (EAP) and RADIUS, which are both 8-bit clean, and which both recommend the use of UTF-8 for identitifiers. * Section 2.4 required mappings that are language-specific, and which are nearly impossible for intermediate nodes to perform correctly without information about that language. * Section 2.4 requires normalization of user names, which may conflict with local system or administrative requirements. * The recommendations in Section 2.4 for treatment of bidirectional characters have proven to be unworkable. * The prohibition against use of unassigned code points in Section 2.4 effectively prohibits support for new scripts. * No Authentication, Authorization, and Accounting (AAA) client, proxy, or server has implemented any of the requirements in [RFC4282] Section 2.4 , among other sections. - 5 . Administration of Names In order to avoid creating any new administrative procedures, administration of the NAI realm namespace piggybacks on the administration of the DNS namespace. There is a tag issue above. The section tag contains the first line of section 5. Regards, Benoit > >> Regards, Benoit >>> Dear all, >>> >>> Here is my draft-ietf-radext-nai-08 AD review >>> >>> _Technical:_ >>> - >>> AAA systems MUST therefore be >>> able to handle user identifiers which are not in the NAI format. >>> ... >>> >>> Systems MAY accept user identifiers in forms other than the NAI. >>> These are contradictory. >>> I believe that: >>> - those two sentences (or paragraphs) should be next to each others. >>> - the second sentence should stress "Non AAA systems" >>> >>> _Systems _MAY accept user identifiers in forms other than the NAI. >>> This specification does not forbid that practice. It only codifies >>> the format and interpretation of the NAI. We cannot expect to change >>> existing protocols or practices. We can, however, suggest that using >>> a consistent form for a user identifier is of a benefit to the >>> community. >>> >>> Where protocols carry identifiers which are expected to be >>> transported over an AAA protocol, it is RECOMMENDED that the >>> identifiers be in NAI format. Where the identifiers are not in the >>> NAI format, it is up to the _AAA systems_ to discover this, and to >>> process them. This document does not suggest how that is done. >>> However, existing practice indicates that it is possible. >>> Be consistent between systems, non-AAA systems, and AAA systems >>> >>> Editorial: >>> >>> - >>> when you produce a new draft version, don't forget >>> http://tools.ietf.org/wg/radext/trac/ticket/176 >>> >>> - >>> Considerable interest exists for a set of features that fit within >>> the general category of inter-domain authentiction >>> >>> authentication >>> >>> - >>> Normalization Canonicalization >>> >>> These terms are defined in [RFC6365] Section 4 . We incorporate >>> the definitions here by reference. >>> Isn't "Normalization or Canonicalization" >>> >>> - Like mentioned in the last bullet point below, all links should >>> point to the RFC4282 sections, not to draft-ietf-radext-nai-08 sections. >>> * The requirement in Section 2.1 that realms are ASCII conflicts >>> with the Extensible Authentication Protocol (EAP) and RADIUS, >>> which are both 8-bit clean, and which both recommend the use of >>> UTF-8 for identitifiers. >>> >>> * Section 2.4 required mappings that are language-specific, >>> and which are nearly impossible for intermediate nodes to perform >>> correctly without information about that language. >>> >>> * Section 2.4 requires normalization of user names, which >>> may conflict with local system or administrative requirements. >>> >>> * The recommendations in Section 2.4 for treatment of >>> bidirectional characters have proven to be unworkable. >>> >>> * The prohibition against use of unassigned code points in >>> Section 2.4 effectively prohibits support for new scripts. >>> >>> * No Authentication, Authorization, and Accounting (AAA) >>> client, proxy, or server has implemented any of the requirements >>> in [RFC4282] Section 2.4 , among other sections. >>> >>> >>> - >>> >>> >>> 5 . >>> Administration of Names >>> >>> >>> In order to avoid creating any new administrative procedures, >>> >>> >>> administration of the NAI realm namespace piggybacks on the >>> administration of the DNS namespace. >>> >>> There is a tag issue above. The section tag contains the first line of section 5. >>> >>> Regards, Benoit >>> >>> >>> _______________________________________________ >>> radext mailing list >>> radext@ietf.org >>> https://www.ietf.org/mailman/listinfo/radext > . > From nobody Wed Oct 29 13:55:45 2014 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 1D8BE1A8AE3 for ; Wed, 29 Oct 2014 13:55:44 -0700 (PDT) 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 9_8h3977z9jV for ; Wed, 29 Oct 2014 13:55:43 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF9F1A8AE7 for ; Wed, 29 Oct 2014 13:55:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 750942240404; Wed, 29 Oct 2014 21:55:42 +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 PSOV38qXnvRy; Wed, 29 Oct 2014 21:55:42 +0100 (CET) Received: from Thor.local (206-248-157-156.dsl.teksavvy.com [206.248.157.156]) by power.freeradius.org (Postfix) with ESMTPSA id DB965224011C; Wed, 29 Oct 2014 21:55:41 +0100 (CET) Message-ID: <5451544C.4050109@deployingradius.com> Date: Wed, 29 Oct 2014 16:55:40 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Benoit Claise References: <54501DF8.3070802@cisco.com> <54514876.9010105@cisco.com> <54514DDD.8090401@deployingradius.com> <545151A0.40007@cisco.com> In-Reply-To: <545151A0.40007@cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/e472y8n6oRsUK2FvZ3q_5nAkfTs Cc: "radext@ietf.org" , draft-ietf-radext-nai@tools.ietf.org Subject: Re: [radext] draft-ietf-radext-nai-08 AD review 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, 29 Oct 2014 20:55:44 -0000 Ok... I did actually make the edits, I just sent the wrong file. I'll send a -10. Alan DeKok. From nobody Thu Oct 30 00:51:30 2014 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 573151AD047 for ; Thu, 30 Oct 2014 00:51:28 -0700 (PDT) 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 XYq9ECkGGn0D for ; Thu, 30 Oct 2014 00:51:26 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297131AD03A for ; Thu, 30 Oct 2014 00:51:26 -0700 (PDT) Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id 9D05940BFE; Thu, 30 Oct 2014 08:51:24 +0100 (CET) Message-ID: <5451EDF7.4050403@restena.lu> Date: Thu, 30 Oct 2014 08:51:19 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Alan DeKok , Benoit Claise References: <54501DF8.3070802@cisco.com> <54514876.9010105@cisco.com> <54514DDD.8090401@deployingradius.com> <545151A0.40007@cisco.com> <5451544C.4050109@deployingradius.com> In-Reply-To: <5451544C.4050109@deployingradius.com> OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="s3SxAWDHMSaefM2sUDCOCDrk4sjoThrE3" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/Yi8PW3VrnpCm3IOQ_gJHDvQKZd0 Cc: "radext@ietf.org" , draft-ietf-radext-nai@tools.ietf.org Subject: Re: [radext] draft-ietf-radext-nai-08 AD review 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, 30 Oct 2014 07:51:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --s3SxAWDHMSaefM2sUDCOCDrk4sjoThrE3 Content-Type: multipart/mixed; boundary="------------070009080701020509080307" This is a multi-part message in MIME format. --------------070009080701020509080307 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > Ok... I did actually make the edits, I just sent the wrong file. >=20 > I'll send a -10. -09 also currently doesn't contain the fix to TRAC #176. I guess it will be in -10 then. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 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 --------------070009080701020509080307 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.0.22 (GNU/Linux) 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----- --------------070009080701020509080307-- --s3SxAWDHMSaefM2sUDCOCDrk4sjoThrE3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJUUe38AAoJEMDeajWKOdxmvHQQAIprFPDV5zGPXCNN3AYYvpgt ETAkyuI0m2wIDVDxx0ianWPREYwdqqAJCCDTa6ysJNoogvHjaLnlGFfQZBSKkD7R v4FabjnUUrwV8TjqKQ+/5dfxws7yjZ3/DkLq/0Mdz/i2ZBIvt/JX64c48xcJt/tS hBYYa4xJh17MARLpRdLL7F9uAcN8zBQ1wZxTAPzADEQBMLaGXa+08Zo6cfrcOyGe s9USSPB1ob8VSJZXAlAlJyVPPzwL5xskgoDOBPKjtp3AQYa+LxYAhjrkKpTWtUvZ 86kwP4i9jtmSV8skrLVtJcsRsKtE3sFZYKGoEXT5r6VFPVSejoZLsPSzwlOPUY/E RvJMT90DNpRsQ+SnoX3oezzo4HYbDmYSc8HDc6toUBnJZ3w4Mt3ZXC+T/5C212Aw eQ05iiuM77sqq36vCkzasKFvzO0MfGyZkT4hUrOrJADHWfuu9wyDDZ5vArf9JK5v YFr/GrphCw+LXm89Y6rDLvjasLCrLt+Xg0v1g0d9RRYjFzmALL5xxbgncCnUCjdd lyF1tnRpwPnw0ipb41yB5ZSaqC1n+9OrmAo6ma+qMlb0VaM8G7C39/EfQzNMdd3C jxsvNBKr3LIyomdhfalmwjnj2AV3QEimZpCqP+dWiK3cYGG64PxsAYBnNRyG5T94 UZACd8QcPIgL9cjHtHBb =LE8C -----END PGP SIGNATURE----- --s3SxAWDHMSaefM2sUDCOCDrk4sjoThrE3-- From nobody Fri Oct 31 01:53:19 2014 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 B8A041A701D for ; Fri, 31 Oct 2014 01:53:17 -0700 (PDT) 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 SaVD7oJuJ77S for ; Fri, 31 Oct 2014 01:53:15 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178571A1B99 for ; Fri, 31 Oct 2014 01:53:15 -0700 (PDT) Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id 3056340CA5 for ; Fri, 31 Oct 2014 09:53:13 +0100 (CET) Message-ID: <54534DF9.9030205@restena.lu> Date: Fri, 31 Oct 2014 09:53:13 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "radext@ietf.org" References: <20141030145957.10662.72846.idtracker@ietfa.amsl.com> In-Reply-To: <20141030145957.10662.72846.idtracker@ietfa.amsl.com> OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 X-Forwarded-Message-Id: <20141030145957.10662.72846.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6A5HGi0IE3UA8WkLp148BEIHf27i777lr" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/dOIbk8NuNoUsEKNWY0MMe1aXX2M Subject: [radext] Fwd: New Version Notification - draft-ietf-radext-nai-10.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: Fri, 31 Oct 2014 08:53:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6A5HGi0IE3UA8WkLp148BEIHf27i777lr Content-Type: multipart/mixed; boundary="------------050503070103030908010606" This is a multi-part message in MIME format. --------------050503070103030908010606 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I didn't see this annoucement coming up on the mailing list, so here goes= : -------- Forwarded Message -------- Subject: New Version Notification - draft-ietf-radext-nai-10.txt Resent-To: aland@freeradius.org, jouni.nospam@gmail.com, stefan.winter@restena.lu Date: Thu, 30 Oct 2014 07:59:57 -0700 From: ID Tracker To: radext-chairs@tools.ietf.org, draft-ietf-radext-nai@tools.ietf.org, bclaise@cisco.com A new version (-10) has been submitted for draft-ietf-radext-nai-10.txt: https://www.ietf.org/internet-drafts/draft-ietf-radext-nai-10.txt Diff from previous version: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-nai-10 The IETF Secretariat. --------------050503070103030908010606 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.0.22 (GNU/Linux) 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----- --------------050503070103030908010606-- --6A5HGi0IE3UA8WkLp148BEIHf27i777lr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJUU035AAoJEMDeajWKOdxm5mcQALG6KMKMtyiznYTV7pXWUGsn FeFN4GRSKtMvy3t5zO4ZvLTj46xpXUaNWfOxBv7QBiEJZLsR54Dpxsxw12+lUgtj X9bdKvqBqgxXPbBh21EdI0cKCXgWAi1YfwPiPlIdJAW67v8PN7YOjBFsqZUtNsMf a50k7+gS1t8UzbNuE2tojA1BUv2RHwbKBH999jWH3VsRUQnkqThq9PCprSddzGlm FPDzYOumyoMLJzVw+Vz/6TC++xTM0Wzb7T2drO+z1qcaKWw/m2hAw4wzZ7RSQ4hQ tJyrdboxeMwj6Kl4ZFuup2Bp9Ak21sX7/OlOr4GlKmrNDf4TkafTcMmDott+5rbA i4fqAdJGlo/C2OHpbUnT4P4SZ3H4s4qTwAjwEsrfFVWZCi+5pTi21nsvLjPGcIt/ 4+5hjRGay3za8X0BZEnq+yH42VjKsDdvNMXy+jQU1S3OWyu7p6A7NaYYgxVD8J8T DHKjahRIDXQ1vj5TbJTDeGbBx0HImOuoP11YrqW8b2xzh5PBLgXq+bXfLfr+EO4n szzswRRg1RnDrPK/pzYsJvhy7I4tLXP+CswQJ/BHg0daxf3Y4sHqDQGMxZTBguqN uEITqdaiDk4BGYYQGIaQ3K5bgbuestk8tPk2sPGaHvIo/rhuti169zzjCWjQszKU I+2cmqqLpHo27+6dP1wW =GexV -----END PGP SIGNATURE----- --6A5HGi0IE3UA8WkLp148BEIHf27i777lr-- From nobody Fri Oct 31 01:58:38 2014 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 9D29C1A7017 for ; Fri, 31 Oct 2014 01:58:36 -0700 (PDT) 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 TyzzBzzgaVYJ for ; Fri, 31 Oct 2014 01:58:35 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C78341A702E for ; Fri, 31 Oct 2014 01:58:34 -0700 (PDT) Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id 9439E40CA5 for ; Fri, 31 Oct 2014 09:58:33 +0100 (CET) Message-ID: <54534F39.2060908@restena.lu> Date: Fri, 31 Oct 2014 09:58:33 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "radext@ietf.org" OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1i7iai5gtjIVx9kL5GVuWFr6o4bxJr20m" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/M_K7eqZEBPdy0Gl50aR5JlEeSmc Subject: [radext] Agenda online 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, 31 Oct 2014 08:58:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1i7iai5gtjIVx9kL5GVuWFr6o4bxJr20m Content-Type: multipart/mixed; boundary="------------030906030306060904030204" This is a multi-part message in MIME format. --------------030906030306060904030204 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, the draft submission deadline is well over, and I didn't receive requests for changes to the agenda. So I've uploaded the final meeting agenda to the Meeting Materials manager: http://www.ietf.org/proceedings/91/agenda/agenda-91-radext As you may recall, we have 30 more minutes than requested, so if any of the items on the agenda take a bit longer than anticipated, that's no problem this time. I would also like to remind you that if you want to give a remote *presentation*, you should let me or Jouni know before 06 November because the Meetecho support staff needs to know this a bit in advance. Looking forward to seeing you on Oahu, 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 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg 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 --------------030906030306060904030204 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.0.22 (GNU/Linux) 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----- --------------030906030306060904030204-- --1i7iai5gtjIVx9kL5GVuWFr6o4bxJr20m Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJUU085AAoJEMDeajWKOdxm5lgP/RqfcIGt9JYa4nv19ATaxSbi HfZ9aXHy0/VD2Sgjn/V7RKqyQ7ngQJvqU9DKe/eehqRObfnEISEIadRsQqQwwJC4 WcPnwXJybyBYTBuAaVRwrOJUiuOd9Tg8w+5OiuCsmm1AUmydJpxpbLIjD34S6PjM Qiwmp85dgJaOVGcaaj5rLfxY4m2aE40HZZS+O8xZ+FU0cqtjMTXoAoMWgP11N/Md g4sI2Q4QDJKucxOg4ZMxoJSZKpHkLAftqWsYj+r7oje6NSaV709xZ5c1H1uLDZCD wStLjJxXqxsqeK+zf36a0uiQdNQsydpmjr397oZxqiU3GbCRWG61BP5W8Y1mdToe 4S41lnlrlQvWa1ZoaRvZQwSlEzy0+ngRiR/As0XTW9zU/dLczSbpp4dEmX1QYoN+ wONFDMYTKP0coxTSu93O2hv831/eokVTXS6jq9wjdNhGhR7XdRVE4/yruuH6YUaO fktOHfbi3QW7QLJTpokZ+reWp7MJQAGAbYU7CC25ej0rsVj1fACjQSU3eh/pWa9E 7RKX+JuLwOLWaihtGjUaiPVLTsADwlUU45xKMoInJ5B+I8UkylsBdrIRimp+i7rA g5mPs61/RkDzgx0R6axBO1qc8BPD7FfYtlmSi1ixkKodFu4BW/m8+dZZERGoPRn3 bxh/+n/oFJ5/42WbDCsG =m9pK -----END PGP SIGNATURE----- --1i7iai5gtjIVx9kL5GVuWFr6o4bxJr20m-- From nobody Fri Oct 31 03:08:23 2014 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 236EE1A19E2 for ; Fri, 31 Oct 2014 03:08:21 -0700 (PDT) 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 1QsnfOm7DlCT for ; Fri, 31 Oct 2014 03:08:15 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D2601A0073 for ; Fri, 31 Oct 2014 03:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3727; q=dns/txt; s=iport; t=1414750095; x=1415959695; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=Nw8+HrCQCRuZWCnADJDeqQMHYe6KqAx2LtXp9i0sHkc=; b=hhuJRsCbrNPHhlgl7e95IsV3PX375e5OAUI3J193rfKePYXphz6kdTM1 DZVUdIZmjaWZpoycIpyWmlvSsRGyE9lzhiOJKb4tmeZMNiIdT7Fh9XUy8 RpXpH3aJ5BRzlHwR+M5d96CZlalALjMK4YECzpKlaGyrc8D6WLxNV5NL6 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8EAE1fU1StJssW/2dsb2JhbABcg2JYzQsBCYZ5VAKBMQEBAQEBfYQCAQEBBAEBASRHCRILBA0DAQIKJQ8CEAYfCQgGAQwGAgEBiCgDEg3DDA2GOwEBAQEBAQEBAQEBAQEBAQEBAQEBFASOVoIpGAaERQWWYoUFghGHcIdrhm2CNIFFPC8BgkoBAQE X-IronPort-AV: E=Sophos;i="5.07,293,1413244800"; d="scan'208,217";a="227305564" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 31 Oct 2014 10:08:09 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9VA88jk025729; Fri, 31 Oct 2014 10:08:09 GMT Message-ID: <54535F88.50701@cisco.com> Date: Fri, 31 Oct 2014 11:08:08 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Stefan Winter , "radext@ietf.org" References: <20141030145957.10662.72846.idtracker@ietfa.amsl.com> <54534DF9.9030205@restena.lu> In-Reply-To: <54534DF9.9030205@restena.lu> Content-Type: multipart/alternative; boundary="------------090400060700080409060404" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/DvOC9w_1lGgjGk2uMRJd-eRVHS0 Subject: Re: [radext] Fwd: New Version Notification - draft-ietf-radext-nai-10.txt -> IETF LC requested 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, 31 Oct 2014 10:08:21 -0000 This is a multi-part message in MIME format. --------------090400060700080409060404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Alan, Thanks for version 10. The IETF LC has been requested Regards, Benoit > Hi, > > I didn't see this annoucement coming up on the mailing list, so here goes: > > > -------- Forwarded Message -------- > Subject: New Version Notification - draft-ietf-radext-nai-10.txt > Resent-To: aland@freeradius.org, jouni.nospam@gmail.com, > stefan.winter@restena.lu > Date: Thu, 30 Oct 2014 07:59:57 -0700 > From: ID Tracker > To: radext-chairs@tools.ietf.org, draft-ietf-radext-nai@tools.ietf.org, > bclaise@cisco.com > > A new version (-10) has been submitted for draft-ietf-radext-nai-10.txt: > https://www.ietf.org/internet-drafts/draft-ietf-radext-nai-10.txt > > Diff from previous version: > https://tools.ietf.org/rfcdiff?url2=draft-ietf-radext-nai-10 > > The IETF Secretariat. > > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------090400060700080409060404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Alan,

Thanks for version 10.
The IETF LC has been requested

Regards, Benoit
Hi,

I didn't see this annoucement coming up on the mailing list, so here goes:


-------- Forwarded Message --------
Subject: New Version Notification - draft-ietf-radext-nai-10.txt
Resent-To: aland@freeradius.org, jouni.nospam@gmail.com,
stefan.winter@restena.lu
Date: Thu, 30 Oct 2014 07:59:57 -0700
From: ID Tracker <internet-drafts-reply@ietf.org>
To: radext-chairs@tools.ietf.org, draft-ietf-radext-nai@tools.ietf.org,
bclaise@cisco.com

A new version (-10) has been submitted for draft-ietf-radext-nai-10.txt:
https://www.ietf.org/internet-drafts/draft-ietf-radext-nai-10.txt

Diff from previous version:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-radext-nai-10

The IETF Secretariat.





_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

--------------090400060700080409060404-- From nobody Fri Oct 31 05:35:20 2014 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 62D2A1A8A97; Fri, 31 Oct 2014 05:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 3_kWvxzB6FF0; Fri, 31 Oct 2014 05:35:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D94EA1A1B79; Fri, 31 Oct 2014 05:35:15 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141031123515.17404.27765.idtracker@ietfa.amsl.com> Date: Fri, 31 Oct 2014 05:35:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/D2sBq7VarL2Ws9nytHjIjdDflrc Cc: radext@ietf.org Subject: [radext] Last Call: (The Network Access Identifier) to Proposed Standard X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 12:35:17 -0000 The IESG has received a request from the RADIUS EXTensions WG (radext) to consider the following document: - 'The Network Access Identifier' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-11-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client prior to accessing network resources. This document is a revised version of RFC 4282, which addresses issues with international character sets, as well as a number of other corrections to the previous document. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ballot/ No IPR declarations have been submitted directly on this I-D.