From nobody Mon Feb 22 13:13:53 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0410D1A8770 for ; Mon, 22 Feb 2016 13:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.908 X-Spam-Level: X-Spam-Status: No, score=-101.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 f8FMiazxubKG for ; Mon, 22 Feb 2016 13:13:50 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 252501A876E for ; Mon, 22 Feb 2016 13:13:50 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 21FB3180016; Mon, 22 Feb 2016 13:13:20 -0800 (PST) To: dnelson@elbrysnetworks.com, aland@freeradius.org, bclaise@cisco.com, joelja@bogus.com, stefan.winter@restena.lu, lionel.morand@orange.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160222211320.21FB3180016@rfc-editor.org> Date: Mon, 22 Feb 2016 13:13:20 -0800 (PST) Archived-At: Cc: radext@ietf.org, aland@freeradius.org, rfc-editor@rfc-editor.org Subject: [radext] [Technical Errata Reported] RFC5080 (4623) 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, 22 Feb 2016 21:13:52 -0000 The following errata report has been submitted for RFC5080, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5080&eid=4623 -------------------------------------- Type: Technical Reported by: Alan DeKok Section: 2.2.1 Original Text ------------- For Accounting-Request packets, the default values for MRC, MRD, and MRT SHOULD be zero. These settings will enable a RADIUS client to continue sending accounting requests to a RADIUS server until the request is acknowledged. If any of MRC, MRD, or MRT are non-zero, then the accounting information could potentially be discarded without being recorded. Corrected Text -------------- For Accounting-Request packets, the default values for MRC, MRD, and MRT SHOULD be zero. These settings will enable a RADIUS client to continue sending accounting requests to a RADIUS server until the request is acknowledged. If any of MRC, MRD, or MRT are non-zero, then the accounting information could potentially be discarded without being recorded. This retransmission behavior can be modified for Accounting-Request packets containing Acct-Status-Type of Interim-Update. A "retransmission" which includes an updated Acct-Delay-Time MAY also include updated statistics, but otherwise be treated as a retransmission of the original packet, with timers as described above. Also, when the NAS sends periodic Accounting-Request packets, as when requested via Acct-Interim-Interval ([RFC 2869] Section 5.16), or configured via administrative timers, the NAS SHOULD NOT continue to retransmit an old Accounting-Request packet when it is time to send a new one. The old packet SHOULD be discarded, and the new one sent in its place. The alternative is for a NAS to send a new Accounting-Request packet while it still is trying to send an old one. This situation could lead to the NAS sending multiple Accounting-Request packets simultaneously for the same session, leading to congestive collapse of the network. Notes ----- - if we're retransmitting an Accounting-Request packet, it should be acceptable to update the statistics in it. - i.e. there should not be a requirement that the content remain the same. The Acct-Delay-Time attribute is changing, so why not other things, too? - And MRT of zero for Accounting-Request packet SHOULD NOT mean that the NAS starts a new retransmission timer every 5 minutes. - e.g. if the server is down for 20 minutes, the NAS should have *one* Accounting-Status packet in it's retransmit queue. Not 4. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5080 (draft-ietf-radext-fixes-08) -------------------------------------- Title : Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes Publication Date : December 2007 Author(s) : D. Nelson, A. DeKok Category : PROPOSED STANDARD Source : RADIUS EXTensions Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Mon Feb 22 14:57:05 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB581A8895 for ; Mon, 22 Feb 2016 14:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] 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 1YqXfnjDxYuM for ; Mon, 22 Feb 2016 14:57:02 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 D44F91A8A9E for ; Mon, 22 Feb 2016 14:57:01 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id l143so104136463lfe.2 for ; Mon, 22 Feb 2016 14:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lugatech-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oR8zbct3QY+0Fb+lqGh2/FLaxJ31II8AMVUZVeJPkls=; b=QidOIyl4kiUIHCZMjrYHWOeA41s+zy4TrH+fzBtciEWXBZzZmX1i5ixXbekzBDE8Ze ccXDYhvSb6szmVB+2vUaEl9CfUo3/BqI/LsYN2jekZcg/YeA3ErTyjXtNz6O3AQly/GJ 6ascEvtIRfgJqlL8xdM4H4nAJfcjha4kIbwevsNUH5dv6vOdVA9fChnARdHcBW+8Us6M IWLvSfeHBw1U6NrE7V1BE220Z2tfRjJWTgbASQieQHdZWwAXzlzYZTgi+gD3uKLTEHws E92xTrQqj4mTNWn4fw6NEPiPp+lZMEc3UcwLsvRfr+3iFvu9b1CWGE58Za8AG/4XQR5D yCCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oR8zbct3QY+0Fb+lqGh2/FLaxJ31II8AMVUZVeJPkls=; b=ANi7SLs4ShgsoiT52p8pvUS0IauOfm8vPnQyoCmLCnuDol9uch9k5OAN2I7fbAm8xt dE4hAKRUNuF+QpBrLOl8Gm3f1gdjfftP+Ir99FhgUGWIgvRLxq+cLes6X3+svmaijs8q fSNjAaUBHj7S9rhS3YjmFvMSsxmTJPrc5j1bmRXQghIqO4U2eVDH3xUF+tnBx6EADuy7 R50Fw5xbGHBRnpwbqXw5R9o+qZ297//iXpeFJOBHzLO7f8yfem3/2y0at5nkJZeCGSr5 8R+ANkD9EYZYYVDiWxhcVJxN13wEZ+X3Wv44xA/0ws0sFx07TfjUUkr0d+fJFQqjSq1m JANg== X-Gm-Message-State: AG10YOQHUCEjtToNFE/1gJLXrlveCVBASwc0IvKj7xVuunxRaobrIJ1qMlnYZ4yLeNxAiKZYW93lSUmXJb2yKg== MIME-Version: 1.0 X-Received: by 10.25.26.83 with SMTP id a80mr11327168lfa.36.1456181820123; Mon, 22 Feb 2016 14:57:00 -0800 (PST) Received: by 10.112.126.99 with HTTP; Mon, 22 Feb 2016 14:57:00 -0800 (PST) X-Originating-IP: [94.117.227.198] In-Reply-To: <20160222211320.21FB3180016@rfc-editor.org> References: <20160222211320.21FB3180016@rfc-editor.org> Date: Mon, 22 Feb 2016 22:57:00 +0000 Message-ID: From: Nick Lowe To: RFC Errata System Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: radext@ietf.org, lionel.morand@orange.com, stefan.winter@restena.lu, dnelson@elbrysnetworks.com, joel jaeggli , aland@freeradius.org, Benoit Claise Subject: Re: [radext] [Technical Errata Reported] RFC5080 (4623) 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, 22 Feb 2016 22:57:03 -0000 > This retransmission behavior can be modified for Accounting-Request > packets containing Acct-Status-Type of Interim-Update. A > "retransmission" which includes an updated Acct-Delay-Time MAY also > include updated statistics, but otherwise be treated as a > retransmission of the original packet, with timers as described > above. Also, when the NAS sends periodic Accounting-Request > packets, as when requested via Acct-Interim-Interval ([RFC 2869] > Section 5.16), or configured via administrative timers, the NAS > SHOULD NOT continue to retransmit an old Accounting-Request > packet when it is time to send a new one. The old packet SHOULD > be discarded, and the new one sent in its place. I am not convinced that the Acct-Delay-Time attribute value in a 'retransmitted' Interim-Update Accounting-Request packet should be anything other than 0 where dynamic attribute values have refreshed/overwritten with current information rather than the original contents. It is ripe information at that point. I do think it's reasonable, and a good idea, to not resend the original contents for the dynamic attribute values for a retransmission. From nobody Mon Feb 22 14:59:34 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBCE1ACDC0 for ; Mon, 22 Feb 2016 14:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] 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 q6DLBF18d2K8 for ; Mon, 22 Feb 2016 14:59:33 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (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 46FE31ACDBD for ; Mon, 22 Feb 2016 14:59:33 -0800 (PST) Received: by mail-lb0-x229.google.com with SMTP id bc4so91057051lbc.2 for ; Mon, 22 Feb 2016 14:59:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lugatech-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IaqtLa5Yz33m+S3hApXWMr1QIqg3l44RsY23PoKyBRs=; b=kcI9iT9BydI9Xey1M5eFtmUakDG/v/LoJu2gF9toxtWoX6ZR/H8GQ/Pe4uGrFiGnZb hbPbBBk4MpQib9DdceNWPLoHMBlUfR+95BqMG6c0hfYNQUjI6zM4nUrVsrUAlVpDth7g bOQPpCs00eR/Lqbhgz1fLprSEV9HLi+aN7CsbDup+DIMEUEK7oN3ReGwr/V9TfrXWsOK KKLT1Iccun+Sg2WemYgXYycIIfTIFQ29rKmtxSdpd1IFHT7yPiXx9k6b0UwpTFXzmhWH hi9OnygHcHxEyLtM088NwDgSnJrAjetkWFQj9fXMM6rWryniBa6RkzWwipaJJr+Ap60L dUMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IaqtLa5Yz33m+S3hApXWMr1QIqg3l44RsY23PoKyBRs=; b=KKBaCgqaiIFT3GLL7RVJtUHegHUeFNglGS7wWqGed05bcMR5uzN862u74jicMG1JOV yvCrdv8sCmbnj+geCdIvHb68Ep/0KWRRsD8KU0yiJLOkQuxn3RMHbE0DQ98s3bWEwV1j dYYqxnX+DzAjIU6yvNXYusYfn8yQlCNfE2ddTfUJgUJVkGFNYwoMj3Om81cW4XlC7iuK DeIxU5dd2fSw9Pq7a5Gn8PRK2Bmy/aiEH3eHGLk4UfjLxr4yyIr1rbuT4k59YtnYoQkq zgsAJXPbD7DE4ocwVncXUpWeqTpEQEIWgktct9Mpwgj6yj+mFwuI5PZ3SjcFtgR84mQs DDtA== X-Gm-Message-State: AG10YOTxvGdY9DxmHaa1Vs7KpCyD0eUE/WAaufQJZUFinsdQnnAsvcx+IcYxupc7YhQyQcF89TkwcmDu3zMJZw== MIME-Version: 1.0 X-Received: by 10.112.140.41 with SMTP id rd9mr11343059lbb.138.1456181971397; Mon, 22 Feb 2016 14:59:31 -0800 (PST) Received: by 10.112.126.99 with HTTP; Mon, 22 Feb 2016 14:59:31 -0800 (PST) X-Originating-IP: [94.117.227.198] In-Reply-To: References: <20160222211320.21FB3180016@rfc-editor.org> Date: Mon, 22 Feb 2016 22:59:31 +0000 Message-ID: From: Nick Lowe To: RFC Errata System Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: radext@ietf.org, lionel.morand@orange.com, stefan.winter@restena.lu, dnelson@elbrysnetworks.com, joel jaeggli , aland@freeradius.org, Benoit Claise Subject: Re: [radext] [Technical Errata Reported] RFC5080 (4623) 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, 22 Feb 2016 22:59:34 -0000 The same would apply to the Event-Timestamp attribute, it should contain the current time where this is done not the original time, in my opinion. From nobody Mon Feb 22 15:17:06 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B311B2D23 for ; Mon, 22 Feb 2016 15:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WA6oInytBg8B for ; Mon, 22 Feb 2016 15:17:02 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8A62D1B2C66 for ; Mon, 22 Feb 2016 15:17:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id D467CD45; Mon, 22 Feb 2016 23:17:01 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-e7eQ5jsGmi; Mon, 22 Feb 2016 23:17:01 +0000 (UTC) Received: from [192.168.120.60] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by mail.networkradius.com (Postfix) with ESMTPSA id 2E64A1B1; Mon, 22 Feb 2016 23:17:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Mon, 22 Feb 2016 18:16:56 -0500 Content-Transfer-Encoding: 7bit Message-Id: <31D75A9E-A8F1-40BD-811B-945B83C94F42@freeradius.org> References: <20160222211320.21FB3180016@rfc-editor.org> To: Nick Lowe X-Mailer: Apple Mail (2.3112) Archived-At: Cc: radext@ietf.org, "lionel.morand@orange.com" , Winter Stefan , dnelson@elbrysnetworks.com, joel jaeggli , Benoit Claise , RFC Errata System Subject: Re: [radext] [Technical Errata Reported] RFC5080 (4623) 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, 22 Feb 2016 23:17:04 -0000 I agree with both of Nick's comments. > On Feb 22, 2016, at 5:59 PM, Nick Lowe wrote: > > The same would apply to the Event-Timestamp attribute, it should > contain the current time where this is done not the original time, in > my opinion. From nobody Mon Feb 22 15:33:39 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898621B2E87 for ; Mon, 22 Feb 2016 15:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 b4byMqlS2cR5 for ; Mon, 22 Feb 2016 15:33:37 -0800 (PST) Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id CFBAB1B2E86 for ; Mon, 22 Feb 2016 15:33:36 -0800 (PST) Received: from SMURF.peterd.ws (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 22 Feb 2016 15:33:36 -0800 Date: Mon, 22 Feb 2016 15:33:37 -0800 (Pacific Standard Time) From: Peter Deacon To: Nick Lowe In-Reply-To: Message-ID: References: <20160222211320.21FB3180016@rfc-editor.org> User-Agent: Alpine 2.20.1 (WNT 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Cc: radext@ietf.org, lionel.morand@orange.com, stefan.winter@restena.lu, dnelson@elbrysnetworks.com, joel jaeggli , aland@freeradius.org, Benoit Claise , RFC Errata System Subject: Re: [radext] [Technical Errata Reported] RFC5080 (4623) 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, 22 Feb 2016 23:33:38 -0000 On Mon, 22 Feb 2016, Nick Lowe wrote: >> This retransmission behavior can be modified for Accounting-Request >> packets containing Acct-Status-Type of Interim-Update. A >> "retransmission" which includes an updated Acct-Delay-Time MAY also >> include updated statistics, but otherwise be treated as a >> retransmission of the original packet, with timers as described >> above. Also, when the NAS sends periodic Accounting-Request >> packets, as when requested via Acct-Interim-Interval ([RFC 2869] >> Section 5.16), or configured via administrative timers, the NAS >> SHOULD NOT continue to retransmit an old Accounting-Request >> packet when it is time to send a new one. The old packet SHOULD >> be discarded, and the new one sent in its place. > I am not convinced that the Acct-Delay-Time attribute value in a > 'retransmitted' Interim-Update Accounting-Request packet should be > anything other than 0 where dynamic attribute values have > refreshed/overwritten with current information rather than the > original contents. It is ripe information at that point. The point of Acct-Delay-Time is to provide a signal of queue delay so that time of event is more accurately reflected in accounting stream. >From 5.2 of RFC2866: " This attribute indicates how many seconds the client has been trying to send this record for, and can be subtracted from the time of arrival on the server to find the approximate time of the event generating this Accounting-Request. (Network transit time is ignored.)" The reason you can't update content of accounting when Acct-Delay-Time is updated is because content did not actually happen at the time implied suggested by incremented delay time. Effectively this enables transmission of bad data. For example if you advance both Acct-Delay-Time by 30 seconds and an accounting counter by 1000 to account for current condition at time of transmission the effective result of this signal: 1000 appears to have incremented 30 seconds earlier than it actually occurred. If you want to retransmit old and just update Acct-Delay-Time thats fine. If you want to replace old interim record with a new one and associated reset Acct-Delay-Time thats fine too. Incrementing both Acct-Delay-Time and content should not be allowed because it will provide an illusion that events have occurred earlier than they actually have. regards, Peter From nobody Mon Feb 22 15:41:48 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627CA1B2FBC for ; Mon, 22 Feb 2016 15:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7BeL3hQocwoQ for ; Mon, 22 Feb 2016 15:41:46 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 44F641B2FB7 for ; Mon, 22 Feb 2016 15:41:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 8F5861A62; Mon, 22 Feb 2016 23:41:45 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FR_CRsNgsElx; Mon, 22 Feb 2016 23:41:45 +0000 (UTC) Received: from [192.168.120.60] (OTWAON1140W-LP140-03-1176332297.dsl.bell.ca [70.29.104.9]) by mail.networkradius.com (Postfix) with ESMTPSA id C80FC7B0; Mon, 22 Feb 2016 23:41:43 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Mon, 22 Feb 2016 18:41:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <030E849F-0361-481D-8159-5F8527B42C31@freeradius.org> References: <20160222211320.21FB3180016@rfc-editor.org> To: Peter Deacon X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Nick Lowe , radext@ietf.org, "lionel.morand@orange.com" , Winter Stefan , dnelson@elbrysnetworks.com, joel jaeggli , Benoit Claise , RFC Errata System Subject: Re: [radext] [Technical Errata Reported] RFC5080 (4623) 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, 22 Feb 2016 23:41:47 -0000 On Feb 22, 2016, at 6:33 PM, Peter Deacon = wrote: > If you want to retransmit old and just update Acct-Delay-Time thats = fine. >=20 > If you want to replace old interim record with a new one and = associated reset Acct-Delay-Time thats fine too. >=20 > Incrementing both Acct-Delay-Time and content should not be allowed = because it will provide an illusion that events have occurred earlier = than they actually have. Yes. Alan DeKok. From nobody Mon Feb 22 21:04:11 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF49B1A9108 for ; Mon, 22 Feb 2016 21:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] 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 fx9H9Jnpj0le for ; Mon, 22 Feb 2016 21:04:08 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F801A9101 for ; Mon, 22 Feb 2016 21:04:08 -0800 (PST) Received: from mb-2.local ([IPv6:2601:647:4204:51:70bc:a1f9:1c36:2b70]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u1N5409e082587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 23 Feb 2016 05:04:00 GMT (envelope-from joelja@bogus.com) To: Nick Lowe , RFC Errata System References: <20160222211320.21FB3180016@rfc-editor.org> From: joel jaeggli Message-ID: <3712540a-1037-508d-311e-32ddf3353ad0@bogus.com> Date: Mon, 22 Feb 2016 21:03:59 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OKK2vkdsEo95FeieHdUGoog7JWF9U9k4K" Archived-At: Cc: radext@ietf.org, lionel.morand@orange.com, stefan.winter@restena.lu, dnelson@elbrysnetworks.com, aland@freeradius.org, Benoit Claise Subject: Re: [radext] [Technical Errata Reported] RFC5080 (4623) 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, 23 Feb 2016 05:04:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OKK2vkdsEo95FeieHdUGoog7JWF9U9k4K Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/22/16 2:57 PM, Nick Lowe wrote: >> This retransmission behavior can be modified for Accounting-Request= >> packets containing Acct-Status-Type of Interim-Update. A >> "retransmission" which includes an updated Acct-Delay-Time MAY also= >> include updated statistics, but otherwise be treated as a >> retransmission of the original packet, with timers as described >> above. Also, when the NAS sends periodic Accounting-Request >> packets, as when requested via Acct-Interim-Interval ([RFC 2869] >> Section 5.16), or configured via administrative timers, the NAS >> SHOULD NOT continue to retransmit an old Accounting-Request >> packet when it is time to send a new one. The old packet SHOULD >> be discarded, and the new one sent in its place. >=20 > I am not convinced that the Acct-Delay-Time attribute value in a > 'retransmitted' Interim-Update Accounting-Request packet should be > anything other than 0 where dynamic attribute values have > refreshed/overwritten with current information rather than the > original contents. It is ripe information at that point. >=20 > I do think it's reasonable, and a good idea, to not resend the > original contents for the dynamic attribute values for a > retransmission. So, you would therefore flag these as hold for document update? --OKK2vkdsEo95FeieHdUGoog7JWF9U9k4K Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlbL6EAACgkQ8AA1q7Z/VrLh8QCdG/OzI0yDR48Yx4l319ZpN4L6 DL0An0xJUlEpz13cyskA4DswiN9pfHyH =FDXi -----END PGP SIGNATURE----- --OKK2vkdsEo95FeieHdUGoog7JWF9U9k4K-- From nobody Tue Feb 23 02:48:37 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4C21AD363 for ; Tue, 23 Feb 2016 02:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] 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 ctLfHw6MRwVm for ; Tue, 23 Feb 2016 02:48:34 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (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 DC6291AD0C4 for ; Tue, 23 Feb 2016 02:48:33 -0800 (PST) Received: by mail-lb0-x22e.google.com with SMTP id bc4so98430467lbc.2 for ; Tue, 23 Feb 2016 02:48:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lugatech-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mkr+HOTz0cefXjVzjXNWiRweVzhLV07dtwpKu201X04=; b=KYOcUcda+F3vsONr6dSZZveA+8Ycka0KQl4RyfOTnyK0OqweNrjSR17WranAKaWK6V t5ZBfYIpeJHUpmCznwQwS6f9CjyfzVnMil5qEZSc/sznQt/rgJ688cnmfiKXueP/RbN6 sQntvOpMmX5sHv3JEj0MX3A2ilJ3TI8YnKCnnfc1QITR5m/sapYqZHjlv0q9Ix6UJKKm +y1RU83EmXTI/fUXFjqmgjQFAWUUaqerdxr+++KHTRD9jRP6zj1hjEEcoiGih3mSzKXE LYTTQbTAnOzHNCW9nVve997w+uvODhmWKNomp6AA9dqflExsF+QxPqVko2xaDSix1NYE +nBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mkr+HOTz0cefXjVzjXNWiRweVzhLV07dtwpKu201X04=; b=LVEhLGmYY+P2WpPoyqZneD+Nln9WbjAutwJvKt/ZAki/jHXcX7xPAAnvnOP4uPISc1 IjwXqkVJMrPBnT9uJqJ2oZDHu+Dng/+yY1AO/WRP2hYsAE6zuAjLG/nDYS84C4W4YRri 4f43Fea23DH0JqYfK1xWML+6gcwAynjNRGk6zrRKwOzhTD9PkoeFvaHbpot/6/BuBGAn 8EWOSg5MmqDehSZ57i9Uohn8Ly0+Qt3/zU6xc3XBhopqJUkrsI25XszL4OB9ArtHimte v6PLi+UC8J+0jw0wScTbiygXORY5jhU5ATl10HI0JSG+z6dQOT8rexZxqCLse8x6C2Pi E0lw== X-Gm-Message-State: AG10YORggKh8Z7t+MwJPH6EyRu9X+AOV4VRTuPP+9yvWfkHgBHTBigJc8/x7ke7BSV7IrIIlljUGfV6KU+UlqA== MIME-Version: 1.0 X-Received: by 10.112.156.100 with SMTP id wd4mr3473838lbb.9.1456224511886; Tue, 23 Feb 2016 02:48:31 -0800 (PST) Received: by 10.112.126.99 with HTTP; Tue, 23 Feb 2016 02:48:31 -0800 (PST) X-Originating-IP: [94.117.107.98] In-Reply-To: <3712540a-1037-508d-311e-32ddf3353ad0@bogus.com> References: <20160222211320.21FB3180016@rfc-editor.org> <3712540a-1037-508d-311e-32ddf3353ad0@bogus.com> Date: Tue, 23 Feb 2016 10:48:31 +0000 Message-ID: From: Nick Lowe To: joel jaeggli Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: radext@ietf.org, lionel.morand@orange.com, stefan.winter@restena.lu, dnelson@elbrysnetworks.com, Alan DeKok , Benoit Claise , RFC Errata System Subject: Re: [radext] [Technical Errata Reported] RFC5080 (4623) 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, 23 Feb 2016 10:48:36 -0000 Personally, I do not feel that it would be appropriate to hold this for a document update as this is an ambiguous area of RADIUS accounting due to deficiencies in the RFCs that causes real implementation issues. These pertain to accuracy, reliability and scalability. It does not change anything in a backwards incompatible way, rather further asserts has previously been implicit best practice. I do, however, think that it is necessary to iterate the amended text to the RFC given in the errata to something that is more encompassing, along the lines of: For Accounting-Request packets, the default values for MRC, MRD, and MRT SHOULD be zero. These settings will enable a RADIUS client to continue sending accounting requests to a RADIUS server until the request is acknowledged. If any of MRC, MRD, or MRT are non-zero, then the accounting information could potentially be discarded without being recorded. Both the Acct-Delay-Time and Event-Timestamp attributes SHOULD be present in all Accounting-Request packets. At least one MUST be present. The value of the Acct-Delay-Time attribute MUST be calculated from a monotonic timer rather than a system clock to ensure that it is accurate and not subject to shifts in the clock, which typically occurs as clock synchronization completes via NTP. The Event-Timestamp attribute contains UNIX time, the number of seconds that have elapsed since January 1, 1970 00:00:00 UTC. Where the value of this is known to be inaccurate by being impossibly close to the UNIX time epoch, this MUST NOT be included. The Event-Timestamp attribute SHOULD take priority over the Acct-Delay-Time where both are present at a receiver as it is not subject to network transmission delays. The retransmission behavior of Accounting-Request packets containing an Acct-Status-Type of Interim-Update SHOULD be special cased. A retransmission, that would otherwise have included an accrued Acct-Delay-Time value, SHOULD instead include refreshed values for its attributes with dynamic content with an Acct-Delay-Time value of 0. It will otherwise be treated as a retransmission of the original packet with timers as described above. For the avoidance of doubt, where refreshed values are supplied and an Event-Timestamp attribute is present, this MUST contain the current timestamp and not that of the original transmission. Where a RADIUS server receives multiple Accounting-Request packets with identical timestamps, supplied or calculated, careful consideration MUST be given to the order of precedence. For the common Acct-Status-Types, the following order or precedence is correct: Accounting-On, Start, Interim-Update, Stop, Accounting-Off. When a NAS sends periodic Accounting-Request packets, as when requested via Acct-Interim-Interval ([RFC 2869] Section 5.16) or configured via administrative timers, the NAS SHOULD NOT continue to retransmit an old Accounting-Request packet when it becomes time to send a new one. The old packet SHOULD be discarded, and the new one sent in its place. The alternative is for a NAS to send a new Accounting-Request packet while still attempting to send one or more that are preceding. This situation could lead to the NAS sending multiple Accounting-Request packets simultaneously for the same session, which could lead to congestive collapse of the network. From nobody Tue Feb 23 02:52:22 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D171ACE1B for ; Tue, 23 Feb 2016 02:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] 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 c93T71aZJgc9 for ; Tue, 23 Feb 2016 02:52:20 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (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 48E211A9086 for ; Tue, 23 Feb 2016 02:52:20 -0800 (PST) Received: by mail-lb0-x229.google.com with SMTP id bc4so98480966lbc.2 for ; Tue, 23 Feb 2016 02:52:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lugatech-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+G+Uws54mN2fk45mfHvlhbT3aWoo6RdoKaPQoaiOBwc=; b=jsUqoyiYbCzWEhh5zME2QBBDHQZNw+NuZ2jX2X/nME259SHVdsk2aBFjfkouB1UZTe IPCpcw8vQ6SqB78LougdmvqROARj9x9ZYtgihUjCAVlW3JeO2qCQnMTv37YBpXuLyeBe uMm/UypFeN/R3b/FawvAM0UxgbZuVdUnvS2pDluWk+H5bsfMA5lEJCEd08xor+iEXrg7 0nlPKtGtDE4nC9f5A101ZdBTt/y1MBe7DcxooFKu/ErF8EURzS+Zuhhw+78ueGDfsu6R lfKbgOsNy0qg7UFJkcUudcPx41pZXF4PfUOiHGve82VTT9ajxB0pWEkv1EgtXlytcIJ5 C3vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+G+Uws54mN2fk45mfHvlhbT3aWoo6RdoKaPQoaiOBwc=; b=gYgeShArKtlCB+zCoJR151Lgk4pIhpyX6G/7u0WMWUrVdGdIeN5F+Anp+PoUHhaKoK DweBZgVQ4eXHrhUUGYyEDwQtZLophJ4GrObxyRPGKHxKYEbsDLJHNh8W6a71PhC7x3Jy HhEXhYMeS4sA7CaG3aud5SucU0fHYJFqvZ2yPeR4CJy5hYMB8Cn+AAgXoGwGSfiwBjTd NfT9+qc08dcGkJaWimwRLf1W3cJYjkbCwYqHw/bUm7UfwZBZI6NVLiH9QidRPpbMbWR2 u+pSo3HeC6hdJbaW/fONZF0+Inow7DzODF3oqxEYcj3o8y36ekntsXbCTqCnhXkB53b4 5wMw== X-Gm-Message-State: AG10YOQ+cWnpTflz7eJ02W5urTLBMtmlyzu2TH1QeLHcZQNn4G2fN4iS+C/pPNV6TY/RFBnWymAxv8/RB20uSw== MIME-Version: 1.0 X-Received: by 10.112.67.1 with SMTP id j1mr9595855lbt.103.1456224738590; Tue, 23 Feb 2016 02:52:18 -0800 (PST) Received: by 10.112.126.99 with HTTP; Tue, 23 Feb 2016 02:52:18 -0800 (PST) X-Originating-IP: [94.117.107.98] In-Reply-To: References: <20160222211320.21FB3180016@rfc-editor.org> <3712540a-1037-508d-311e-32ddf3353ad0@bogus.com> Date: Tue, 23 Feb 2016 10:52:18 +0000 Message-ID: From: Nick Lowe To: joel jaeggli Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: radext@ietf.org, lionel.morand@orange.com, stefan.winter@restena.lu, dnelson@elbrysnetworks.com, Alan DeKok , Benoit Claise , RFC Errata System Subject: Re: [radext] [Technical Errata Reported] RFC5080 (4623) 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, 23 Feb 2016 10:52:21 -0000 Further clarification: For Accounting-Request packets, the default values for MRC, MRD, and MRT SHOULD be zero. These settings will enable a RADIUS client to continue sending accounting requests to a RADIUS server until the request is acknowledged. If any of MRC, MRD, or MRT are non-zero, then the accounting information could potentially be discarded without being recorded. Both the Acct-Delay-Time and Event-Timestamp attributes SHOULD be present in all Accounting-Request packets. At least one MUST be present. The value of the Acct-Delay-Time attribute MUST be calculated from a monotonic timer rather than a system clock to ensure that it is accurate and not subject to shifts in the clock, which typically occurs as clock synchronization completes via NTP. The Event-Timestamp attribute contains UNIX time, the number of seconds that have elapsed since January 1, 1970 00:00:00 UTC. Where the value of this is known to be inaccurate by being impossibly close to the UNIX time epoch, this MUST NOT be included. The Event-Timestamp attribute SHOULD take priority over the Acct-Delay-Time where both are present at a receiver as it is not subject to network transmission delays. The retransmission behavior of Accounting-Request packets containing an Acct-Status-Type of Interim-Update SHOULD be special cased. A retransmission, that would otherwise have included an accrued Acct-Delay-Time value, SHOULD instead include refreshed values for its attributes with dynamic content with an Acct-Delay-Time value of 0. It will still in all other respects be treated as a retransmission of the original packet with timers as described above. For the avoidance of doubt, where refreshed values are supplied and an Event-Timestamp attribute is present, this MUST contain the current timestamp and not that of the original transmission. Where a RADIUS server receives multiple Accounting-Request packets with identical timestamps, supplied or calculated, careful consideration MUST be given to the order of precedence. For the common Acct-Status-Types, the following order or precedence is correct: Accounting-On, Start, Interim-Update, Stop, Accounting-Off. When a NAS sends periodic Accounting-Request packets, as when requested via Acct-Interim-Interval ([RFC 2869] Section 5.16) or configured via administrative timers, the NAS SHOULD NOT continue to retransmit an old Accounting-Request packet when it becomes time to send a new one. The old packet SHOULD be discarded, and the new one sent in its place. The alternative is for a NAS to send a new Accounting-Request packet while still attempting to send one or more that are preceding. This situation could lead to the NAS sending multiple Accounting-Request packets simultaneously for the same session, which could lead to congestive collapse of the network. From nobody Tue Feb 23 05:28:33 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F401B2CC4 for ; Tue, 23 Feb 2016 05:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DvjxYurqxf9G for ; Tue, 23 Feb 2016 05:28:29 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id A64C31B2CCB for ; Tue, 23 Feb 2016 05:28:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 00927D24; Tue, 23 Feb 2016 13:28:26 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVJlqXaei5wT; Tue, 23 Feb 2016 13:28:25 +0000 (UTC) Received: from [192.168.120.60] (OTWAON1140W-LP140-03-1176332297.dsl.bell.ca [70.29.104.9]) by mail.networkradius.com (Postfix) with ESMTPSA id 3733676; Tue, 23 Feb 2016 13:28:24 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <3712540a-1037-508d-311e-32ddf3353ad0@bogus.com> Date: Tue, 23 Feb 2016 08:28:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <51E763F0-6F07-4947-8760-BC8B1E9AE62E@freeradius.org> References: <20160222211320.21FB3180016@rfc-editor.org> <3712540a-1037-508d-311e-32ddf3353ad0@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Nick Lowe , radext@ietf.org, "lionel.morand@orange.com" , Winter Stefan , dnelson@elbrysnetworks.com, Benoit Claise , RFC Errata System Subject: Re: [radext] [Technical Errata Reported] RFC5080 (4623) 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, 23 Feb 2016 13:28:32 -0000 On Feb 23, 2016, at 12:03 AM, joel jaeggli wrote: > So, you would therefore flag these as hold for document update? Yes. There are no current plans in RADEXT to update 5080, but it's worth = keeping track of things which need updating. Alan DeKok. From nobody Tue Feb 23 05:32:27 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9561B2D0A for ; Tue, 23 Feb 2016 05:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8xby4IpkOODq for ; Tue, 23 Feb 2016 05:32:13 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id CA89A1ACE42 for ; Tue, 23 Feb 2016 05:32:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 20F8ED24; Tue, 23 Feb 2016 13:32:12 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AYASqKvyRhx; Tue, 23 Feb 2016 13:32:12 +0000 (UTC) Received: from [192.168.120.60] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by mail.networkradius.com (Postfix) with ESMTPSA id 7D4DD458; Tue, 23 Feb 2016 13:32:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Tue, 23 Feb 2016 08:32:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6F349AE7-6B63-4371-B1F9-8C55A565C575@freeradius.org> References: <20160222211320.21FB3180016@rfc-editor.org> <3712540a-1037-508d-311e-32ddf3353ad0@bogus.com> To: Nick Lowe X-Mailer: Apple Mail (2.3112) Archived-At: Cc: radext@ietf.org, "lionel.morand@orange.com" , Winter Stefan , dnelson@elbrysnetworks.com, joel jaeggli , Benoit Claise , RFC Errata System Subject: Re: [radext] [Technical Errata Reported] RFC5080 (4623) 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, 23 Feb 2016 13:32:18 -0000 On Feb 23, 2016, at 5:52 AM, Nick Lowe wrote: >=20 > Further clarification: > ... >=20 > Both the Acct-Delay-Time and Event-Timestamp attributes SHOULD be > present in all Accounting-Request packets. That's good, but this paragraph doesn't really belong in that section = of RFC 5080, and it doesn't flow with the rest of the text. I'd suggest filing another errata for that paragraph.=20 > The retransmission behavior of Accounting-Request packets containing > an Acct-Status-Type of Interim-Update SHOULD be special cased. A > retransmission, that would otherwise have included an accrued > Acct-Delay-Time value, SHOULD instead include refreshed values for its > attributes with dynamic content with an Acct-Delay-Time value of 0. > It will still in all other respects be treated as a retransmission of > the original packet with timers as described above. For the avoidance > of doubt, where refreshed values are supplied and an Event-Timestamp > attribute is present, this MUST contain the current timestamp and not > that of the original transmission. That's good. > Where a RADIUS server receives multiple Accounting-Request packets > with identical timestamps, supplied or calculated, careful > consideration MUST be given to the order of precedence. For the > common Acct-Status-Types, the following order or precedence is > correct: Accounting-On, Start, Interim-Update, Stop, Accounting-Off. That paragraph doesn't really belong in the section which deals with = retransmission behaviour. I agree with the sentiment, but I'd suggest = filing another errata for this topic. > When a NAS sends periodic Accounting-Request packets, as when > requested via Acct-Interim-Interval ([RFC 2869] Section 5.16) or > configured via administrative timers, the NAS SHOULD NOT continue to > retransmit an old Accounting-Request packet when it becomes time to > send a new one. The old packet SHOULD be discarded, and the new one > sent in its place. >=20 > The alternative is for a NAS to send a new Accounting-Request packet > while still attempting to send one or more that are preceding. This text is unclear. > This > situation could lead to the NAS sending multiple Accounting-Request > packets simultaneously for the same session, which could lead to > congestive collapse of the network.