From nobody Tue Feb 3 04:54:27 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C711A0362; Tue, 3 Feb 2015 04:54:21 -0800 (PST) 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 Cd5Q757pnM8o; Tue, 3 Feb 2015 04:54:19 -0800 (PST) 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 E5B051A0364; Tue, 3 Feb 2015 04:54:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4787; q=dns/txt; s=iport; t=1422968059; x=1424177659; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=f0rxpZTbFpVTIt4OUFT1l+2akK8sJbTbWYn2nU/EUxs=; b=dMbdRpLY/U2zMMJzitCCx6hzca6uDuPEjhGPZ50qSUUe683trcui7anw a89GLtpLSjUJADmz7KBUuUKWWpzyu9QSUMd8zxbCgp2ypj8fSjmZkooqN 985LLYz23OlZGYSe50+kVN0HnbGJZjZ0mm46Rq1zGgUi5qk+guyn62Wrc 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CrBACdxNBU/xbLJq1ag1i8KIktDIUlSgKBXwEBAQEBfYQNAQEEAQEBLwEFNgoBEAshFg8JAwIBAgEVMAYBDAEFAgEBBRKIEg3VdgEBAQEBAQEBAQEBAQEBAQEBAQEBAReKDoUIEQFQB4QpAQSFS40MhVeBFzaCTYIjhWWCfYM9IoICHBSBPT0xAYEKgTcBAQE X-IronPort-AV: E=Sophos;i="5.09,512,1418083200"; d="scan'208";a="332970701" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 03 Feb 2015 12:54:16 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t13CsGxh027800; Tue, 3 Feb 2015 12:54:16 GMT Message-ID: <54D0C4F7.5050502@cisco.com> Date: Tue, 03 Feb 2015 13:54:15 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alejandro Perez Mendez , Pete Resnick , The IESG References: <20150122061516.7611.80876.idtracker@ietfa.amsl.com> <54C13F97.1090201@cisco.com> <54C76646.6030108@um.es> In-Reply-To: <54C76646.6030108@um.es> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: radext@ietf.org, Kathleen Moriarty , draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu Subject: Re: [radext] Pete Resnick's Discuss on draft-ietf-radext-radius-fragmentation-11: (with DISCUSS) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 12:54:22 -0000 Hi Kathleen, Can you please let us know if your DISCUSS is solved. Regards, Benoit > Dear Benoit, > > a new version has been submitted including the requested changes. > > Best regards, > Alejandro > > El 22/01/15 a las 19:21, Benoit Claise escribió: >> Dear all, >> >> This document was discussed during the IESG telechat today. >> >> There are 2 "update" types. >> >> 1. Update RFC 2865: Remote Authentication Dial In User Service >> (RADIUS) and RFC 6158: Radius design guidelines >> The question is: when an experimental RFC violates sentences from a >> standard track doc, do we want a forward pointer to that EXP RFC? The >> discussion went in the direction of not "updating" the standards >> RFCs. This is an experiment after all. >> >> 2. Update RFC 6929: Remote Authentication Dial-In User Service >> (RADIUS) Protocol Extensions >> Here we have the issue of the T flag assignment. >> The IESG understands that this document effectively allocates a bit >> from the structure in RFC 6929. >> We evaluated multiple options: registry, "update" and then requiring >> yet another RFC if the experiment fails, no update. >> In the end, the propose solution is that this experimental RFC should >> not "update" RFC 6929. We should rely on the collective mind of the >> WG to recall that this T flag is used. When/if the experiment will be >> successful, the T flag will be properly assigned. >> >> So the next step is to publish a new revision without the 3 >> "updates", and including Kathleen's DISCUSS. >> >> Thanks and regards, Benoit >> >>> Pete Resnick has entered the following ballot position for >>> draft-ietf-radext-radius-fragmentation-11: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to >>> http://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> I have no concerns with the technical content of the document; I did a >>> quick review, and nothing causes concern. But I do want to briefly >>> DISCUSS a procedural point. I am quite sure I will clear the DISCUSS on >>> the call. >>> >>> The issue of "Updates" worries me a bit. Here's the part that concerned >>> me: >>> >>> Note that if this experiment does not succeed, the >>> "T" flag allocation would not persist, as it is tightly >>> associated to >>> this document. >>> >>> That's true, but using Updates will mean that RFC 6929 will *always* >>> have >>> an "Updated By" pointer pointing to this Experimental RFC. That itself >>> could cause serious confusion, and would likely result in the "T" >>> allocation never being able to be used again. >>> >>> I really don't think this document needs to, or should, update the >>> other >>> documents. 2865 and 6158 are only being updated because this document >>> violates a MUST and a SHOULD. But it's an experiment. Any >>> implementation >>> of 2865 or 6158 not participating in the experiment is going to need to >>> honor those MUSTs and SHOULDs. There's no real reason to call out this >>> update to people who are only looking at those two documents. 6929 is a >>> bit trickier, because of the issue of other folks trying to use the >>> reserved value, but as you say in the document: "not such a great >>> number >>> of specifications extending that field are expected." If/when this >>> document goes to Standards Track, that's the time to let people >>> know. If >>> there's a real fear of this experiment interfering with other >>> implementations, it really is time to make the registry. Finally, I'm >>> concerned about the precedent of Experimental documents updating >>> Standards Track and BCP docs, especially on the grounds provided. >>> Perhaps >>> there's a case for that to happen once in a while, but we don't want >>> pointers to possibly failed experiments to be in the meta-data forever. >>> >>> Like I said, we can sort this on the call pretty quickly. But I want to >>> make sure we understand the implications here. >>> >>> >>> >>> >>> _______________________________________________ >>> radext mailing list >>> radext@ietf.org >>> https://www.ietf.org/mailman/listinfo/radext >>> . >>> >> > > . > From nobody Fri Feb 6 16:15:39 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D672A1A1B62; Fri, 6 Feb 2015 16:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9LoCQbetTuT; Fri, 6 Feb 2015 16:14:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1511A07BE; Fri, 6 Feb 2015 16:13:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150207001343.17579.2118.idtracker@ietfa.amsl.com> Date: Fri, 06 Feb 2015 16:13:43 -0800 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ip-port-radius-ext-03.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: Sat, 07 Feb 2015 00:14:54 -0000 X-List-Received-Date: Sat, 07 Feb 2015 00:14:54 -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 : RADIUS Extensions for IP Port Configuration and Reporting Authors : Dean Cheng Jouni Korhonen Mohamed Boucadair Senthil Sivakumar Filename : draft-ietf-radext-ip-port-radius-ext-03.txt Pages : 36 Date : 2015-02-06 Abstract: This document defines three new RADIUS attributes. For devices that implementing IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report TCP/UDP ports and ICMP identifiers, as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as CGN (Carrier Grade NAT), NAT64, Provider WLAN Gateway, etc. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ip-port-radius-ext-03 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 Feb 6 16:15:43 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9963B1A1BBB; Fri, 6 Feb 2015 16:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPtGa8tuSNC2; Fri, 6 Feb 2015 16:14:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B7C1A88F3; Fri, 6 Feb 2015 16:13:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150207001344.17579.94202.idtracker@ietfa.amsl.com> Date: Fri, 06 Feb 2015 16:13:44 -0800 Archived-At: Subject: [radext] New Version Notification - draft-ietf-radext-ip-port-radius-ext-03.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: Sat, 07 Feb 2015 00:14:58 -0000 A new version (-03) has been submitted for draft-ietf-radext-ip-port-radius-ext: http://www.ietf.org/internet-drafts/draft-ietf-radext-ip-port-radius-ext-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ip-port-radius-ext-03 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. IETF Secretariat. From nobody Fri Feb 6 16:15:46 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-ip-port-radius-ext.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 9BBE41A07BE; Fri, 6 Feb 2015 16:14:58 -0800 (PST) X-Original-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9963B1A1BBB; Fri, 6 Feb 2015 16:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPtGa8tuSNC2; Fri, 6 Feb 2015 16:14:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B7C1A88F3; Fri, 6 Feb 2015 16:13:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150207001344.17579.94202.idtracker@ietfa.amsl.com> Date: Fri, 06 Feb 2015 16:13:44 -0800 Archived-At: Subject: [radext] New Version Notification - draft-ietf-radext-ip-port-radius-ext-03.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: Sat, 07 Feb 2015 00:14:59 -0000 A new version (-03) has been submitted for draft-ietf-radext-ip-port-radius-ext: http://www.ietf.org/internet-drafts/draft-ietf-radext-ip-port-radius-ext-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ip-port-radius-ext-03 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. IETF Secretariat. From nobody Sun Feb 8 12:20:16 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA091A1A06 for ; Sun, 8 Feb 2015 12:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.211 X-Spam-Level: X-Spam-Status: No, score=-12.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_NAIL=2.3, 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 qPYbjDFBB0bo for ; Sun, 8 Feb 2015 12:20:05 -0800 (PST) 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 0C34F1A19F7 for ; Sun, 8 Feb 2015 12:20:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1303; q=dns/txt; s=iport; t=1423426805; x=1424636405; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=x5fHHa0VcUiwulPPl4Bvkt/gAHWd+IcN+N3wlbFJYiE=; b=Jn5NPj5w5JRayklrLFo/UJgniXP9DQWWup5s1wNNqLg2pe8yaJ/tRQWx tqw+UxTc0/ue/KaU7SgOYD9hbBpu9DOGB17J4b3WKlnMMnzWhKp8MZLEI iazLFzXf9nhPy5eCEtbVJyh/5xeYPAFZ3/ivGbkpNOUkbZy+4MJ4rHpav E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DrBADSw9dU/xbLJq1cg1hawnAOhSNKAoFSAQEBAQEBfIQNAQEEAQEBLwEFNgoBEAsYCRYPCQMCAQIBFTAGDQEFAgEBBYgkDchNAQEBAQEBAQEBAQEBAQEBAQEBAQEBF494B4QqAQSYR4EYgwOCJYwwIoNuPjGBBCSBGgEBAQ X-IronPort-AV: E=Sophos;i="5.09,540,1418083200"; d="scan'208";a="339422256" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 08 Feb 2015 20:20:03 +0000 Received: from [10.61.168.73] ([10.61.168.73]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t18KK2Yc016486; Sun, 8 Feb 2015 20:20:02 GMT Message-ID: <54D7C4F2.8050903@cisco.com> Date: Sun, 08 Feb 2015 20:20:02 +0000 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alan DeKok References: <54C24E21.50706@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] draft-ietf-radext-nai: 2 weeks review period 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: Sun, 08 Feb 2015 20:20:10 -0000 FYI, I'll progress the document now. Thanks to all. Regards, Benoit > On Jan 23, 2015, at 8:35 AM, Benoit Claise wrote: >> This important document generated a lot of discussions during the IESG review, and those discussions led to some changes to the document. >> This is one of those situations were the changes are numerous. Therefore I would like to give one last opportunity for the WG to validate the latest document version (basically checking we didn't screw up anything). >> Please review the latest document version, or the diff compared to the draft version that left the WG: http://www.ietf.org/rfcdiff?url1=draft-ietf-radext-nai-10&difftype=--html&submit=Go!&url2=draft-ietf-radext-nai-15 > The changes were largely clarifications. Additional text was added to explain the NAI and it’s use-cases. There was a clearer separation made between the NAI format, and the NAI identifier. The format is what the document standardizes. The identifier is a specific instance of text using the NAI format. The use of “we” was changed to a more neutral term. The ABNF for the NAI was simplified. > > Alan DeKok. > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > From nobody Mon Feb 9 07:00:30 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1191A046D; Mon, 9 Feb 2015 06:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3] 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 M629a_0faNGt; Mon, 9 Feb 2015 06:45:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A1B1A040C; Mon, 9 Feb 2015 06:45:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209144515.13066.69213.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 06:45:15 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: 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, 09 Feb 2015 14:45:16 -0000 IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ From nobody Mon Feb 9 07:01:53 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-nai.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 5840D1A047A; Mon, 9 Feb 2015 06:45:16 -0800 (PST) X-Original-To: xfilter-draft-ietf-radext-nai.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-nai.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1191A046D; Mon, 9 Feb 2015 06:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3] 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 M629a_0faNGt; Mon, 9 Feb 2015 06:45:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A1B1A040C; Mon, 9 Feb 2015 06:45:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209144515.13066.69213.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 06:45:15 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: 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, 09 Feb 2015 14:45:16 -0000 IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ From nobody Mon Feb 9 07:04:48 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129211A049C; Mon, 9 Feb 2015 06:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3] 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 VrAuVJ8-1_m3; Mon, 9 Feb 2015 06:46:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A881A040B; Mon, 9 Feb 2015 06:46:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209144609.6339.5111.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 06:46:09 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: 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, 09 Feb 2015 14:46:11 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ From nobody Mon Feb 9 07:06:11 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-nai.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 3A8BD1A040B; Mon, 9 Feb 2015 06:46:11 -0800 (PST) X-Original-To: xfilter-draft-ietf-radext-nai.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-nai.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129211A049C; Mon, 9 Feb 2015 06:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3] 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 VrAuVJ8-1_m3; Mon, 9 Feb 2015 06:46:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A881A040B; Mon, 9 Feb 2015 06:46:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209144609.6339.5111.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 06:46:09 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: 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, 09 Feb 2015 14:46:11 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ From nobody Mon Feb 9 07:07:33 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9956A1A066C; Mon, 9 Feb 2015 06:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.6 X-Spam-Level: X-Spam-Status: No, score=-99.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3, USER_IN_WHITELIST=-100] 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 YrDh5LT8bVDl; Mon, 9 Feb 2015 06:46:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2071A046D; Mon, 9 Feb 2015 06:46:10 -0800 (PST) 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.10.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209144610.6339.18195.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 06:46:10 -0800 Archived-At: Cc: radext mailing list , radext chair , RFC Editor Subject: [radext] Protocol Action: 'The Network Access Identifier' to Proposed Standard (draft-ietf-radext-nai-15.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, 09 Feb 2015 14:46:13 -0000 The IESG has approved the following document: - 'The Network Access Identifier' (draft-ietf-radext-nai-15.txt) as Proposed Standard This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ Technical Summary 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 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. Working Group Summary The preceding RFC4282 was primarily written for the concrete use case of network access. Over time however, many services made use of the concept defined therein; see Citation information at http://www.arkko.com/tools/allstats/citations-rfc4282.html for a complete list of IETF work; other standardization bodies or other documents not counted. draft-ietf-radext-nai thus had to make modest modifications in order not to create incompatibilities with these existing uses. It also took care to define the NAI in a protocol-agnostic manner to encourage such re-use. One particular issue which was discussed at length was the question: which entity should (be allowed to) normalise or re-encode the realm portions of NAIs; and what to do if such a re-encoding is needed, but not possible. In the core scenario of network access, i.e use with RADIUS and Diameter, character encoding and normalisation information may not be available to any RADIUS/Diameter endpoint at all (the encoding information may get lost at a preceding stage, before the NAI reaches the RADIUS client). In other scenarios, the encoding information may be available at all points in the conversation. The working group finally converged on the text in section 2.6, which puts a bias on endpoints doing all conversions, and intermediate entities doing conversions only inside their local state; not modifying the NAI on the wire. Another aspect that was discussed is that the notion of User-Name in AAA protocols and the term NAI are not an exact match; while User-Name often is used to transmit a NAI, it can also be used to transmit arbitrary strings which do not follow the NAI conventions of either RFC4282 or draft-ietf-radext-nai. The working group concluded that this is a fact of life that can't be changed, and that implementations which inspect a User-Name can't blindly assume to get a NAI; they need to care about their own fallback/failure handling. Such handling is outside the scope of draft-ietf-radext-nai. Document Quality The concept of NAIs is not new, and the definitions of draft-ietf-radext-nai are compatible with implementations of NAIs in the "ASCII" subset. Field evidence suggests that RFC4282's provisions for dealing with characters from outside ASCII were with an overwhelming majority not implemented at all or even violated RFC4282 and did what draft-ietf-radext-nai is now suggesting anyway; so existing implementations do not conflict with the new encoding rules parts that are introduced with draft-ietf-radext-nai. It's thus a reasonable assumption that NAIs as defined in draft-ietf-radext-nai are as widely implemented as the NAIs of RFC4282. The encoding and normalisation questions triggered an i18n review; the person doing that review was Pete Resnick . The review comments were one of the inputs to the discussion and were taken into account in the latest revision of the draft. Personnel The document shepherd is Stefan Winter The responsible area directors of the Operations and Management area are Benoit Claise and Joel Jaeggli From nobody Mon Feb 9 11:44:31 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329C71A8768; Mon, 9 Feb 2015 11:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3] 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 ac9JKKCtLj-G; Mon, 9 Feb 2015 11:16:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CE41A1BAD; Mon, 9 Feb 2015 11:16:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209191602.4623.99412.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 11:16:02 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: 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, 09 Feb 2015 19:16:06 -0000 IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ From nobody Mon Feb 9 11:45:54 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-nai.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 4CED11A8775; Mon, 9 Feb 2015 11:16:06 -0800 (PST) X-Original-To: xfilter-draft-ietf-radext-nai.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-nai.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329C71A8768; Mon, 9 Feb 2015 11:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3] 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 ac9JKKCtLj-G; Mon, 9 Feb 2015 11:16:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CE41A1BAD; Mon, 9 Feb 2015 11:16:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209191602.4623.99412.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 11:16:02 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: 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, 09 Feb 2015 19:16:06 -0000 IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ From nobody Mon Feb 9 12:45:08 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D52E1A87C6; Mon, 9 Feb 2015 12:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3, TVD_SPACE_RATIO=0.001] 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 O9C6Wtihe4dT; Mon, 9 Feb 2015 12:05:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 330EE1A8833; Mon, 9 Feb 2015 12:05:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209200520.965.38456.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 12:05:20 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: 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, 09 Feb 2015 20:05:44 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ From nobody Mon Feb 9 12:46:29 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-nai.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8C5E91A886E; Mon, 9 Feb 2015 12:05:44 -0800 (PST) X-Original-To: xfilter-draft-ietf-radext-nai.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-nai.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D52E1A87C6; Mon, 9 Feb 2015 12:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3, TVD_SPACE_RATIO=0.001] 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 O9C6Wtihe4dT; Mon, 9 Feb 2015 12:05:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 330EE1A8833; Mon, 9 Feb 2015 12:05:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209200520.965.38456.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 12:05:20 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: 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, 09 Feb 2015 20:05:44 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ From nobody Mon Feb 9 12:48:05 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E261A887A; Mon, 9 Feb 2015 12:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3] 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 EgeOWtHjCQ32; Mon, 9 Feb 2015 12:05:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6711A6FDB; Mon, 9 Feb 2015 12:05:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209200521.965.90314.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 12:05:21 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: 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, 09 Feb 2015 20:05:47 -0000 IANA action state changed to No IC ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ From nobody Mon Feb 9 12:49:40 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-nai.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 6816B1A6FDB; Mon, 9 Feb 2015 12:05:47 -0800 (PST) X-Original-To: xfilter-draft-ietf-radext-nai.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-nai.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E261A887A; Mon, 9 Feb 2015 12:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3] 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 EgeOWtHjCQ32; Mon, 9 Feb 2015 12:05:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6711A6FDB; Mon, 9 Feb 2015 12:05:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209200521.965.90314.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 12:05:21 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: 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, 09 Feb 2015 20:05:47 -0000 IANA action state changed to No IC ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ From nobody Mon Feb 9 15:50:31 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03391A8940; Mon, 9 Feb 2015 15:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 icH9fBrbwvTj; Mon, 9 Feb 2015 15:23:20 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (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 069481A7021; Mon, 9 Feb 2015 15:23:20 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id u10so19638480lbd.7; Mon, 09 Feb 2015 15:23:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R0zqZ3jiJwaErWefPLalzrvnRXE7xR4aDjt1SZAdx+o=; b=WKQQWkaXxpkA54OcxaOu1w2O7PFLtmLKge4frD4nA40vCBs6wkTeU8gdarOmIi7dNs yUzmnCpAu7MB0qdCvrratQ/st13Bju1/st+z5yuxxaCSw2hU5dfEIkCTDDC53fILAgJU +FHZ8k49f5Wg0qaiRoe0KyjQrrUOJHs4cS/82Gz1EBZNpcPWTaUVgCDwdd3LrxTN4zeA sa/HkHFm8DMcqdHF3HBTmUehFpk6W9c0XvsjRBMWtalLTC69BV3neNzuF0Kkw4B/aBMH B4/6ik20GHCQxgUdtP+dHTdU5OP3QPk4nSxMFDsLoStXzcgHplWWr1FEtE+W/oMy2d5F 8RxQ== MIME-Version: 1.0 X-Received: by 10.152.8.104 with SMTP id q8mr20803511laa.56.1423524198222; Mon, 09 Feb 2015 15:23:18 -0800 (PST) Received: by 10.112.167.134 with HTTP; Mon, 9 Feb 2015 15:23:18 -0800 (PST) In-Reply-To: <54D0C4F7.5050502@cisco.com> References: <20150122061516.7611.80876.idtracker@ietfa.amsl.com> <54C13F97.1090201@cisco.com> <54C76646.6030108@um.es> <54D0C4F7.5050502@cisco.com> Date: Mon, 9 Feb 2015 18:23:18 -0500 Message-ID: From: Kathleen Moriarty To: Benoit Claise Content-Type: multipart/alternative; boundary=001a11c311982a11a8050eb00edc Archived-At: Cc: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, "radext-chairs@tools.ietf.org" , Stefan Winter , Pete Resnick , The IESG , Alejandro Perez Mendez Subject: Re: [radext] Pete Resnick's Discuss on draft-ietf-radext-radius-fragmentation-11: (with DISCUSS) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 23:23:24 -0000 --001a11c311982a11a8050eb00edc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry, I didn't see this as the thread was on Pete's Discuss. I'll take a look now. Thanks, Kathleen On Tue, Feb 3, 2015 at 7:54 AM, Benoit Claise wrote: > Hi Kathleen, > > Can you please let us know if your DISCUSS is solved. > > Regards, Benoit > >> Dear Benoit, >> >> a new version has been submitted including the requested changes. >> >> Best regards, >> Alejandro >> >> El 22/01/15 a las 19:21, Benoit Claise escribi=C3=B3: >> >>> Dear all, >>> >>> This document was discussed during the IESG telechat today. >>> >>> There are 2 "update" types. >>> >>> 1. Update RFC 2865: Remote Authentication Dial In User Service (RADIUS) >>> and RFC 6158: Radius design guidelines >>> The question is: when an experimental RFC violates sentences from a >>> standard track doc, do we want a forward pointer to that EXP RFC? The >>> discussion went in the direction of not "updating" the standards RFCs. = This >>> is an experiment after all. >>> >>> 2. Update RFC 6929: Remote Authentication Dial-In User Service (RADIUS) >>> Protocol Extensions >>> Here we have the issue of the T flag assignment. >>> The IESG understands that this document effectively allocates a bit fro= m >>> the structure in RFC 6929. >>> We evaluated multiple options: registry, "update" and then requiring ye= t >>> another RFC if the experiment fails, no update. >>> In the end, the propose solution is that this experimental RFC should >>> not "update" RFC 6929. We should rely on the collective mind of the WG = to >>> recall that this T flag is used. When/if the experiment will be success= ful, >>> the T flag will be properly assigned. >>> >>> So the next step is to publish a new revision without the 3 "updates", >>> and including Kathleen's DISCUSS. >>> >>> Thanks and regards, Benoit >>> >>> Pete Resnick has entered the following ballot position for >>>> draft-ietf-radext-radius-fragmentation-11: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut thi= s >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria. >>>> html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation= / >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> I have no concerns with the technical content of the document; I did a >>>> quick review, and nothing causes concern. But I do want to briefly >>>> DISCUSS a procedural point. I am quite sure I will clear the DISCUSS o= n >>>> the call. >>>> >>>> The issue of "Updates" worries me a bit. Here's the part that concerne= d >>>> me: >>>> >>>> Note that if this experiment does not succeed, the >>>> "T" flag allocation would not persist, as it is tightly associated >>>> to >>>> this document. >>>> >>>> That's true, but using Updates will mean that RFC 6929 will *always* >>>> have >>>> an "Updated By" pointer pointing to this Experimental RFC. That itself >>>> could cause serious confusion, and would likely result in the "T" >>>> allocation never being able to be used again. >>>> >>>> I really don't think this document needs to, or should, update the oth= er >>>> documents. 2865 and 6158 are only being updated because this document >>>> violates a MUST and a SHOULD. But it's an experiment. Any implementati= on >>>> of 2865 or 6158 not participating in the experiment is going to need t= o >>>> honor those MUSTs and SHOULDs. There's no real reason to call out this >>>> update to people who are only looking at those two documents. 6929 is = a >>>> bit trickier, because of the issue of other folks trying to use the >>>> reserved value, but as you say in the document: "not such a great numb= er >>>> of specifications extending that field are expected." If/when this >>>> document goes to Standards Track, that's the time to let people know. = If >>>> there's a real fear of this experiment interfering with other >>>> implementations, it really is time to make the registry. Finally, I'm >>>> concerned about the precedent of Experimental documents updating >>>> Standards Track and BCP docs, especially on the grounds provided. >>>> Perhaps >>>> there's a case for that to happen once in a while, but we don't want >>>> pointers to possibly failed experiments to be in the meta-data forever= . >>>> >>>> Like I said, we can sort this on the call pretty quickly. But I want t= o >>>> make sure we understand the implications here. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> radext mailing list >>>> radext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/radext >>>> . >>>> >>>> >>> >> . >> >> > --=20 Best regards, Kathleen --001a11c311982a11a8050eb00edc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, I didn't see this as the thread was on Pete'= ;s Discuss.=C2=A0 I'll take a look now.

Thanks,
Kathleen

On Tue, Feb 3, 2015 at 7:54 AM, Benoit Claise &l= t;bclaise@cisco.com<= /a>> wrote:
Hi Kathleen,

Can you please let us know if your DISCUSS is solved.

Regards, Benoit
Dear Benoit,

a new version has been submitted including the requested changes.

Best regards,
Alejandro

El 22/01/15 a las 19:21, Benoit Claise escribi=C3=B3:
Dear all,

This document was discussed during the IESG telechat today.

There are 2 "update" types.

1. Update RFC 2865: Remote Authentication Dial In User Service (RADIUS) and= RFC 6158: Radius design guidelines
The question is: when an experimental RFC violates sentences from a standar= d track doc, do we want a forward pointer to that EXP RFC? The discussion w= ent in the direction of not "updating" the standards RFCs. This i= s an experiment after all.

2. Update RFC 6929: Remote Authentication Dial-In User Service (RADIUS)=C2= =A0 Protocol Extensions
Here we have the issue of the T flag assignment.
The IESG understands that this document effectively allocates a bit from th= e structure in RFC 6929.
We evaluated multiple options: registry, "update" and then requir= ing yet another RFC if the experiment fails, no update.
In the end, the propose solution is that this experimental RFC should not &= quot;update" RFC 6929. We should rely on the collective mind of the WG= to recall that this T flag is used. When/if the experiment will be success= ful, the T flag will be properly assigned.

So the next step is to publish a new revision without the 3 "updates&q= uot;, and including Kathleen's DISCUSS.

Thanks and regards, Benoit

Pete Resnick has entered the following ballot position for
draft-ietf-radext-radius-fragmentation-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discu= ss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-iet= f-radext-radius-fragmentation/



-------------------------------------------------------------= ---------
DISCUSS:
-------------------------------------------------------------= ---------

I have no concerns with the technical content of the document; I did a
quick review, and nothing causes concern. But I do want to briefly
DISCUSS a procedural point. I am quite sure I will clear the DISCUSS on
the call.

The issue of "Updates" worries me a bit. Here's the part that= concerned
me:

=C2=A0 =C2=A0 Note that if this experiment does not succeed, the
=C2=A0 =C2=A0 "T" flag allocation would not persist, as it is tig= htly associated to
=C2=A0 =C2=A0 this document.

That's true, but using Updates will mean that RFC 6929 will *always* ha= ve
an "Updated By" pointer pointing to this Experimental RFC. That i= tself
could cause serious confusion, and would likely result in the "T"=
allocation never being able to be used again.

I really don't think this document needs to, or should, update the othe= r
documents. 2865 and 6158 are only being updated because this document
violates a MUST and a SHOULD. But it's an experiment. Any implementatio= n
of 2865 or 6158 not participating in the experiment is going to need to
honor those MUSTs and SHOULDs. There's no real reason to call out this<= br> update to people who are only looking at those two documents. 6929 is a
bit trickier, because of the issue of other folks trying to use the
reserved value, but as you say in the document: "not such a great numb= er
of specifications extending that field are expected." If/when this
document goes to Standards Track, that's the time to let people know. I= f
there's a real fear of this experiment interfering with other
implementations, it really is time to make the registry. Finally, I'm concerned about the precedent of Experimental documents updating
Standards Track and BCP docs, especially on the grounds provided. Perhaps there's a case for that to happen once in a while, but we don't wan= t
pointers to possibly failed experiments to be in the meta-data forever.

Like I said, we can sort this on the call pretty quickly. But I want to
make sure we understand the implications here.




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



.





--

Best regards,
Kath= leen
--001a11c311982a11a8050eb00edc-- From nobody Mon Feb 9 15:50:41 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177401A87EE; Mon, 9 Feb 2015 15:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 OC5OCTEdZTUH; Mon, 9 Feb 2015 15:26:30 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (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 A0C821A7021; Mon, 9 Feb 2015 15:26:29 -0800 (PST) Received: by lams18 with SMTP id s18so16881163lam.13; Mon, 09 Feb 2015 15:26:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7kHC4JP26zMa5rE9LdHL82VrWCPzsPt6fIk24ZZaqag=; b=cV3bHoCug7iyFTpnTSENRzlvt/zl4ZMdpM5DUAfJ/iccyzQNHSKs8LIFWsIrOhkMNd OqkSvBQLpwNwvm6ilEiJtycsFbQMiplBZVlY3Rx1U0vmaZggrol2LnP2/ZVLPHY8Xg19 IeKJ/dujjBMVFIqmFKY5OnGdihrhbpWPwcuHeJypKsnL2hwBZLuCDQUn2cadeV3fczvJ FLPsfGwSeBjFqLoCwKMaoPlNrt7oVuL2nr3XA9rdzwJfI8wEM+cuIBRHWdy3d425apNn 5XBJFpv0UXzzKMFdrERTlN75M1RQJjo0eXmK0FLSle+c8Gido6vAJZzaZ2lkgY5V60vY iv9Q== MIME-Version: 1.0 X-Received: by 10.152.5.167 with SMTP id t7mr20879571lat.32.1423524388202; Mon, 09 Feb 2015 15:26:28 -0800 (PST) Received: by 10.112.167.134 with HTTP; Mon, 9 Feb 2015 15:26:28 -0800 (PST) In-Reply-To: References: <20150121182146.9534.92979.idtracker@ietfa.amsl.com> <81E348FD-93A4-422D-80E5-7498C229FC5D@networkradius.com> Date: Mon, 9 Feb 2015 18:26:28 -0500 Message-ID: From: Kathleen Moriarty To: Alan DeKok Content-Type: multipart/alternative; boundary=089e01419d867cef68050eb0195a Archived-At: Cc: radext@ietf.org, Winter Stefan , The IESG , "radext-chairs@tools.ietf.org" , draft-ietf-radext-radius-fragmentation.all@tools.ietf.org Subject: Re: [radext] Kathleen Moriarty's Discuss on draft-ietf-radext-radius-fragmentation-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 23:26:32 -0000 --089e01419d867cef68050eb0195a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alan, Thanks for adding int he proposed text into the latest version. Clearing now. Kathleen On Wed, Jan 21, 2015 at 2:31 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Alan, > > On Wed, Jan 21, 2015 at 2:18 PM, Alan DeKok > wrote: > > On Jan 21, 2015, at 1:21 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> In the security considerations section, I didn't see a discussion on > >> packet re-assembly and associated security issues such as overlapping > >> fragments. > > > > There are no overlapping fragments. The fragmentation method was > designed to avoid that. > > > > Unlike IP, there is no =E2=80=9Cfragment offset=E2=80=9D field. Ther= e is simply a > =E2=80=9Cfragment length=E2=80=9D field. The fragments are requested and= received in > lock-step order. The data in each fragment is appended to the previous > data. > > > >> If there is a reference that already covers that in the > >> draft, I missed it and would appreciate you pointing me to it. > > > > Section 12.4 says: > > > > This proposal does not modify the way RADIUS interacts with the > > underlying transport (UDP). That is, RADIUS keeps following a lock- > > step behaviour, that requires receiving an explicit acknowledge for > > each chunk sent. > > > > The overview in Section 4 describes the process. But it doesn=E2=80= =99t > explicitly say that the fragments are simply appended. It just says: > > > > =E2=80=A6 When all the chunks have > > been received, the original list of attributes is reconstructed and > > processed as if it had been received in one packet. > > > > which leaves the =E2=80=9Creconstruction=E2=80=9D process open to inte= rpretation. > > > > We could add a short paragraph after the preaching text: > > > > The reconstruction process is performed by simply appending all of the > chunks together. Unlike IPv4 fragmentation, there is no =E2=80=9Cfragmen= t offset=E2=80=9D > field. The chunks in this specification are explicitly ordered, as RADIU= S > is a lock-step protocol, as noted in Section 12.4. That is, chunk N+1 > cannot be sent until all of the chunks up to and including N have been > received and acknowledged. > > > > We could also add text to the end of Section 12.4: > > > > Another benefit of the lock-step nature of RADIUS, is that there are no > security issues with overlapping fragments. Each chunk simply has a > length, with no =E2=80=9Cfragment offset=E2=80=9D field as with IPv4. Th= e order of the > fragments is determined by the order in which they are received. There i= s > no ambiguity about the size or placement of each chunk, and therefore no > security issues associated with overlapping chunks. > > Thank you for the quick response and proposed text, this looks very > good and I think is helpful. I'll switch to a yes when this text is > added. > > -- > > Best regards, > Kathleen > --=20 Best regards, Kathleen --089e01419d867cef68050eb0195a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alan,

Thanks for adding int he proposed= text into the latest version.=C2=A0 Clearing now.

Kathleen

On Wed, Jan 21, 2015 at 2:31 PM, Kathleen Moriarty &l= t;kat= hleen.moriarty.ietf@gmail.com> wrote:
Alan,

On Wed, Jan 21, 2015 at 2:18 PM, Alan DeKok <aland@networkradius.com> wrote:
> On Jan 21, 2015, at 1:21 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> w= rote:
>> In the security considerations section, I didn't see a discuss= ion on
>> packet re-assembly and associated security issues such as overlapp= ing
>> fragments.
>
>=C2=A0 =C2=A0There are no overlapping fragments.=C2=A0 The fragmentatio= n method was designed to avoid that.
>
>=C2=A0 =C2=A0Unlike IP, there is no =E2=80=9Cfragment offset=E2=80=9D f= ield.=C2=A0 There is simply a =E2=80=9Cfragment length=E2=80=9D field.=C2= =A0 The fragments are requested and received in lock-step order.=C2=A0 The = data in each fragment is appended to the previous data.
>
>>=C2=A0 If there is a reference that already covers that in the
>> draft, I missed it and would appreciate you pointing me to it.
>
>=C2=A0 =C2=A0Section 12.4 says:
>
>=C2=A0 =C2=A0 This proposal does not modify the way RADIUS interacts wi= th the
>=C2=A0 =C2=A0 underlying transport (UDP).=C2=A0 That is, RADIUS keeps f= ollowing a lock-
>=C2=A0 =C2=A0 step behaviour, that requires receiving an explicit ackno= wledge for
>=C2=A0 =C2=A0 each chunk sent.
>
>=C2=A0 The overview in Section 4 describes the process.=C2=A0 But it do= esn=E2=80=99t explicitly say that the fragments are simply appended.=C2=A0 = It just says:
>
>=C2=A0 =C2=A0 =E2=80=A6 When all the chunks have
>=C2=A0 =C2=A0 been received, the original list of attributes is reconst= ructed and
>=C2=A0 =C2=A0 processed as if it had been received in one packet.
>
>=C2=A0 which leaves the =E2=80=9Creconstruction=E2=80=9D process open t= o interpretation.
>
> We could add a short paragraph after the preaching text:
>
> The reconstruction process is performed by simply appending all of the= chunks together.=C2=A0 Unlike IPv4 fragmentation, there is no =E2=80=9Cfra= gment offset=E2=80=9D field.=C2=A0 The chunks in this specification are exp= licitly ordered, as RADIUS is a lock-step protocol, as noted in Section 12.= 4.=C2=A0 That is, chunk N+1 cannot be sent until all of the chunks up to an= d including N have been received and acknowledged.
>
>=C2=A0 =C2=A0We could also add text to the end of Section 12.4:
>
> Another benefit of the lock-step nature of RADIUS, is that there are n= o security issues with overlapping fragments.=C2=A0 Each chunk simply has a= length, with no =E2=80=9Cfragment offset=E2=80=9D field as with IPv4.=C2= =A0 The order of the fragments is determined by the order in which they are= received.=C2=A0 There is no ambiguity about the size or placement of each = chunk, and therefore no security issues associated with overlapping chunks.=

Thank you for the quick response and proposed text, this looks = very
good and I think is helpful.=C2=A0 I'll switch to a yes when this text = is
added.

--

Best regards,
Kathleen



--

Best regards,
Kathleen
--089e01419d867cef68050eb0195a-- From nobody Mon Feb 9 15:50:47 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D1F1A8940; Mon, 9 Feb 2015 15:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 mSxEFMC4gnNM; Mon, 9 Feb 2015 15:27:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6761A8A74; Mon, 9 Feb 2015 15:27:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209232719.18809.67105.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 15:27:19 -0800 Archived-At: Cc: radext@ietf.org, radext-chairs@ietf.org, draft-ietf-radext-radius-fragmentation.all@ietf.org, stefan.winter@restena.lu Subject: [radext] Kathleen Moriarty's Yes on draft-ietf-radext-radius-fragmentation-12: (with COMMENT) 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, 09 Feb 2015 23:27:21 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-radext-radius-fragmentation-12: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for your work on this draft, I also agree that it is well written and placed well as experimental. Thank you for addressing my prior discuss questions. From nobody Mon Feb 9 15:50:50 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-radius-fragmentation.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2338F1A8A74; Mon, 9 Feb 2015 15:27:21 -0800 (PST) X-Original-To: xfilter-draft-ietf-radext-radius-fragmentation.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-radius-fragmentation.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D1F1A8940; Mon, 9 Feb 2015 15:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 mSxEFMC4gnNM; Mon, 9 Feb 2015 15:27:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6761A8A74; Mon, 9 Feb 2015 15:27:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209232719.18809.67105.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 15:27:19 -0800 Archived-At: Cc: radext@ietf.org, radext-chairs@ietf.org, draft-ietf-radext-radius-fragmentation.all@ietf.org, stefan.winter@restena.lu Subject: [radext] Kathleen Moriarty's Yes on draft-ietf-radext-radius-fragmentation-12: (with COMMENT) 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, 09 Feb 2015 23:27:21 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-radext-radius-fragmentation-12: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for your work on this draft, I also agree that it is well written and placed well as experimental. Thank you for addressing my prior discuss questions. From nobody Mon Feb 9 16:10:01 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED6A1A70FD; Mon, 9 Feb 2015 16:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLAR0XG6etOl; Mon, 9 Feb 2015 16:09:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3791A8A6D; Mon, 9 Feb 2015 16:09:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150210000937.24598.21779.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 16:09:37 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: 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: Tue, 10 Feb 2015 00:09:40 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ From nobody Mon Feb 9 16:10:03 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-radius-fragmentation.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 329751A8AC4; Mon, 9 Feb 2015 16:09:40 -0800 (PST) X-Original-To: xfilter-draft-ietf-radext-radius-fragmentation.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-radius-fragmentation.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED6A1A70FD; Mon, 9 Feb 2015 16:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLAR0XG6etOl; Mon, 9 Feb 2015 16:09:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3791A8A6D; Mon, 9 Feb 2015 16:09:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150210000937.24598.21779.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 16:09:37 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: 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: Tue, 10 Feb 2015 00:09:40 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ From nobody Mon Feb 9 16:10:06 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4CF31A8AC5; Mon, 9 Feb 2015 16:09:46 -0800 (PST) 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 cYUs824Ikxae; Mon, 9 Feb 2015 16:09:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EEA1A8AAD; Mon, 9 Feb 2015 16:09:37 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150210000937.24598.33946.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 16:09:37 -0800 Archived-At: Cc: radext mailing list , radext chair , RFC Editor Subject: [radext] Document Action: 'Support of fragmentation of RADIUS packets' to Experimental RFC (draft-ietf-radext-radius-fragmentation-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: Tue, 10 Feb 2015 00:09:46 -0000 The IESG has approved the following document: - 'Support of fragmentation of RADIUS packets' (draft-ietf-radext-radius-fragmentation-12.txt) as Experimental RFC This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ Technical Summary 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. Working Group Summary The content of this document was discussed at length in the working group, and there are multiple other approaches to the same problem. The document thus got significant exposure at the experts of the working group. The document has a few rough edges which were the cause of discussions. Considering the target status of Experimental, they appear minor enough to carry on with the experiment. The authors have documented the friction points in their section 11 "Operational Considerations". 11.1 in particular shows a process question: is it appropriate for an Experimental RFC to update a Standards-track RFC? The document attempts to follow that course; if this is ultimately agreed after IESG review, the text in that section will be changed accordingly. Document Quality At least one implementation is known which implements this specification: FreeRADIUS. The sheperd has no information about plans of other vendors. There were no particular expert reviews outside the working group process; i.e. no MIB doctor review nor Media Type review (and no need for those two as the document contains neither MIBs nor requests a Media Type). Since the document adds new transport capabilities, a thorough review by transport experts (e.g. TSVDIR) during IETF Last Call would be appreciated. Personnel The Document Shepherd is Stefan Winter . The responsible Area Directors are Benoit Claise <​bclaise@cisco.com>. From nobody Tue Feb 10 23:06:26 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739BF1A7D85; Tue, 10 Feb 2015 23:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 NCK-l0A_dV1B; Tue, 10 Feb 2015 23:06:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4F81A0024; Tue, 10 Feb 2015 23:06:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150211070619.27739.85145.idtracker@ietfa.amsl.com> Date: Tue, 10 Feb 2015 23:06:19 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: 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, 11 Feb 2015 07:06:21 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ From nobody Tue Feb 10 23:06:29 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-radius-fragmentation.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C2C9A1A86E2; Tue, 10 Feb 2015 23:06:21 -0800 (PST) X-Original-To: xfilter-draft-ietf-radext-radius-fragmentation.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-radius-fragmentation.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739BF1A7D85; Tue, 10 Feb 2015 23:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 NCK-l0A_dV1B; Tue, 10 Feb 2015 23:06:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4F81A0024; Tue, 10 Feb 2015 23:06:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150211070619.27739.85145.idtracker@ietfa.amsl.com> Date: Tue, 10 Feb 2015 23:06:19 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: 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, 11 Feb 2015 07:06:22 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ From nobody Tue Feb 10 23:07:31 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F761A8760; Tue, 10 Feb 2015 23:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 6c2UhPxMF96V; Tue, 10 Feb 2015 23:07:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0591A8774; Tue, 10 Feb 2015 23:06:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150211070628.27739.72005.idtracker@ietfa.amsl.com> Date: Tue, 10 Feb 2015 23:06:28 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: 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, 11 Feb 2015 07:07:22 -0000 IANA action state changed to Waiting on Authors ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ From nobody Tue Feb 10 23:07:32 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-radius-fragmentation.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 9DF071A87AF; Tue, 10 Feb 2015 23:07:21 -0800 (PST) X-Original-To: xfilter-draft-ietf-radext-radius-fragmentation.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-radius-fragmentation.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F761A8760; Tue, 10 Feb 2015 23:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 6c2UhPxMF96V; Tue, 10 Feb 2015 23:07:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0591A8774; Tue, 10 Feb 2015 23:06:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150211070628.27739.72005.idtracker@ietfa.amsl.com> Date: Tue, 10 Feb 2015 23:06:28 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: 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, 11 Feb 2015 07:07:23 -0000 IANA action state changed to Waiting on Authors ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ From nobody Wed Feb 11 05:39:22 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B16B1A890A; Wed, 11 Feb 2015 05:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 cM52k5BAgcKI; Wed, 11 Feb 2015 05:39:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AF51A88E7; Wed, 11 Feb 2015 05:38:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150211133854.24161.67987.idtracker@ietfa.amsl.com> Date: Wed, 11 Feb 2015 05:38:54 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: 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, 11 Feb 2015 13:39:15 -0000 IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ From nobody Wed Feb 11 05:39:28 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-radius-fragmentation.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id AB4121A88E7; Wed, 11 Feb 2015 05:39:15 -0800 (PST) X-Original-To: xfilter-draft-ietf-radext-radius-fragmentation.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-radius-fragmentation.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B16B1A890A; Wed, 11 Feb 2015 05:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 cM52k5BAgcKI; Wed, 11 Feb 2015 05:39:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AF51A88E7; Wed, 11 Feb 2015 05:38:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150211133854.24161.67987.idtracker@ietfa.amsl.com> Date: Wed, 11 Feb 2015 05:38:54 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: 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, 11 Feb 2015 13:39:15 -0000 IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ From nobody Wed Feb 11 11:06:51 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581D41A8A7B; Wed, 11 Feb 2015 11:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 b7giliIIlBtx; Wed, 11 Feb 2015 11:06:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 219261A1B15; Wed, 11 Feb 2015 11:06:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150211190642.24389.37650.idtracker@ietfa.amsl.com> Date: Wed, 11 Feb 2015 11:06:42 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: 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, 11 Feb 2015 19:06:47 -0000 IANA action state changed to Waiting on RFC Editor ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ From nobody Wed Feb 11 11:07:06 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-radius-fragmentation.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7E3ED1A8A83; Wed, 11 Feb 2015 11:06:47 -0800 (PST) X-Original-To: xfilter-draft-ietf-radext-radius-fragmentation.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-radius-fragmentation.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581D41A8A7B; Wed, 11 Feb 2015 11:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 b7giliIIlBtx; Wed, 11 Feb 2015 11:06:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 219261A1B15; Wed, 11 Feb 2015 11:06:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150211190642.24389.37650.idtracker@ietfa.amsl.com> Date: Wed, 11 Feb 2015 11:06:42 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: 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, 11 Feb 2015 19:06:49 -0000 IANA action state changed to Waiting on RFC Editor ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ From nobody Thu Feb 12 07:33:33 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FEC1A9123; Thu, 12 Feb 2015 07:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4s-5mPnDyj7R; Thu, 12 Feb 2015 07:33:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF191A88E9; Thu, 12 Feb 2015 07:33:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150212153328.25885.52282.idtracker@ietfa.amsl.com> Date: Thu, 12 Feb 2015 07:33:28 -0800 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-bigger-packets-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 15:33:30 -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 : Larger Packets for RADIUS over TCP Author : Sam Hartman Filename : draft-ietf-radext-bigger-packets-02.txt Pages : 9 Date : 2015-02-12 Abstract: The RADIUS over TLS experiment described in RFC 6614 has opened RADIUS to new use cases where the 4096-octet maximum RADIUS packet proves problematic. This specification extends the RADIUS over TCP experiment to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action which requires IESG approval. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-bigger-packets/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-bigger-packets-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-bigger-packets-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 12 07:33:46 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF241A9135; Thu, 12 Feb 2015 07:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSpqkrVIGEPr; Thu, 12 Feb 2015 07:33:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 490071A8AAB; Thu, 12 Feb 2015 07:33:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150212153328.25885.6287.idtracker@ietfa.amsl.com> Date: Thu, 12 Feb 2015 07:33:28 -0800 Archived-At: Subject: [radext] New Version Notification - draft-ietf-radext-bigger-packets-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 15:33:34 -0000 A new version (-02) has been submitted for draft-ietf-radext-bigger-packets: http://www.ietf.org/internet-drafts/draft-ietf-radext-bigger-packets-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-bigger-packets/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-bigger-packets-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Thu Feb 12 07:33:48 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-bigger-packets.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 14EC81A913B; Thu, 12 Feb 2015 07:33:34 -0800 (PST) X-Original-To: xfilter-draft-ietf-radext-bigger-packets.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-bigger-packets.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF241A9135; Thu, 12 Feb 2015 07:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSpqkrVIGEPr; Thu, 12 Feb 2015 07:33:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 490071A8AAB; Thu, 12 Feb 2015 07:33:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150212153328.25885.6287.idtracker@ietfa.amsl.com> Date: Thu, 12 Feb 2015 07:33:28 -0800 Archived-At: Subject: [radext] New Version Notification - draft-ietf-radext-bigger-packets-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 15:33:34 -0000 A new version (-02) has been submitted for draft-ietf-radext-bigger-packets: http://www.ietf.org/internet-drafts/draft-ietf-radext-bigger-packets-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-bigger-packets/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-bigger-packets-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Thu Feb 12 11:06:30 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B976E1A1B94; Thu, 12 Feb 2015 11:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 GYXFjPfRp5l6; Thu, 12 Feb 2015 11:06:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9DC1A1BB9; Thu, 12 Feb 2015 11:06:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150212190618.26265.87372.idtracker@ietfa.amsl.com> Date: Thu, 12 Feb 2015 11:06:18 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: 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: Thu, 12 Feb 2015 19:06:23 -0000 IANA action state changed to RFC-Ed-Ack ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ From nobody Thu Feb 12 11:06:32 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-radius-fragmentation.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id EABA71A1EB7; Thu, 12 Feb 2015 11:06:23 -0800 (PST) X-Original-To: xfilter-draft-ietf-radext-radius-fragmentation.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-radius-fragmentation.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B976E1A1B94; Thu, 12 Feb 2015 11:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 GYXFjPfRp5l6; Thu, 12 Feb 2015 11:06:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9DC1A1BB9; Thu, 12 Feb 2015 11:06:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150212190618.26265.87372.idtracker@ietfa.amsl.com> Date: Thu, 12 Feb 2015 11:06:18 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: 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: Thu, 12 Feb 2015 19:06:25 -0000 IANA action state changed to RFC-Ed-Ack ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ From nobody Tue Feb 24 22:28:02 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1FB1A0070 for ; Tue, 24 Feb 2015 15:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_T00w2hqUjd for ; Tue, 24 Feb 2015 15:07:52 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0107.outbound.protection.outlook.com [207.46.100.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8B5B1A9076 for ; Tue, 24 Feb 2015 15:07:51 -0800 (PST) Received: from BLUPR03MB149.namprd03.prod.outlook.com (10.255.212.17) by BLUPR03MB151.namprd03.prod.outlook.com (10.255.212.25) with Microsoft SMTP Server (TLS) id 15.1.99.9; Tue, 24 Feb 2015 23:07:49 +0000 Received: from BLUPR03MB149.namprd03.prod.outlook.com ([169.254.2.106]) by BLUPR03MB149.namprd03.prod.outlook.com ([169.254.2.106]) with mapi id 15.01.0099.004; Tue, 24 Feb 2015 23:07:49 +0000 From: Bernard Aboba To: RFC Errata System , "mchiba@cisco.com" , "gdommety@cisco.com" , "meklund@cisco.com" , "david@mitton.com" , "bclaise@cisco.com" , "joelja@bogus.com" , "stefan.winter@restena.lu" , "lionel.morand@orange.com" Thread-Topic: [Technical Errata Reported] RFC5176 (4280) Thread-Index: AQHQUHJgGUk59TUm6EeB8xcdubqOpJ0Aa+jQ Date: Tue, 24 Feb 2015 23:07:49 +0000 Message-ID: References: <20150224204147.6CCC6181B3D@rfc-editor.org> In-Reply-To: <20150224204147.6CCC6181B3D@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.160.89] authentication-results: spf=none (sender IP is ) smtp.mailfrom=Bernard.Aboba@microsoft.com; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB151; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005004); SRVR:BLUPR03MB151; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB151; x-forefront-prvs: 04976078F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(377454003)(13464003)(2501003)(33656002)(74316001)(16799955002)(15188155005)(86612001)(101416001)(15975445007)(86362001)(2950100001)(64706001)(19580405001)(19580395003)(68736005)(66066001)(2900100001)(92566002)(97736003)(76576001)(122556002)(105586002)(106116001)(106356001)(99286002)(40100003)(102836002)(50986999)(62966003)(76176999)(54356999)(46102003)(2201001)(87936001)(77156002)(2656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB151; H:BLUPR03MB149.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2015 23:07:49.2469 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB151 Archived-At: X-Mailman-Approved-At: Tue, 24 Feb 2015 22:28:00 -0800 Cc: "radext@ietf.org" , "aland@freeradius.org" Subject: Re: [radext] [Technical Errata Reported] RFC5176 (4280) 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, 24 Feb 2015 23:07:58 -0000 The Description text should also be addressed in this Errata: Description It is possible that a Dynamic Authorization Server cannot honor Disconnect-Request or CoA-Request packets for some reason. The Error-Cause Attribute provides more detail on the cause of the problem. It MAY be included within CoA-NAK and Disconnect-NAK packets. =20 -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]=20 Sent: Tuesday, February 24, 2015 12:42 PM To: mchiba@cisco.com; gdommety@cisco.com; meklund@cisco.com; david@mitton.c= om; Bernard Aboba; bclaise@cisco.com; joelja@bogus.com; stefan.winter@reste= na.lu; lionel.morand@orange.com Cc: aland@freeradius.org; radext@ietf.org; rfc-editor@rfc-editor.org Subject: [Technical Errata Reported] RFC5176 (4280) The following errata report has been submitted for RFC5176, "Dynamic Author= ization Extensions to Remote Authentication Dial In User Service (RADIUS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D5176&eid=3D4280 -------------------------------------- Type: Technical Reported by: Alan DeKok Section: 3.6 Original Text ------------- 0 0 0+ 101 Error-Cause In both tables, for CoA and Disconnect messages. Corrected Text -------------- 0 0+ 0+ 101 Error-Cause In both tables, for CoA and Disconnect messages. Notes ----- Section 3.5 says that Error-Cause may be sent in a CoA-ACK or Disconnect-AC= K packet: ... Values 200-299 represent successful completion, so that these values may only be sent within CoA-ACK or Disconnect-ACK packets Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "R= eply All" to discuss whether it should be verified or rejected. When a deci= sion is reached, the verifying party (IESG) can log in to change the status= and edit the report, if necessary.=20 -------------------------------------- RFC5176 (draft-ietf-radext-rfc3576bis-13) -------------------------------------- Title : Dynamic Authorization Extensions to Remote Authentica= tion Dial In User Service (RADIUS) Publication Date : January 2008 Author(s) : M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba Category : INFORMATIONAL Source : RADIUS EXTensions Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Feb 24 22:28:12 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FF61A88D9 for ; Tue, 24 Feb 2015 12:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 gLzI-g1n4yma for ; Tue, 24 Feb 2015 12:42:14 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id BD3211A88D5 for ; Tue, 24 Feb 2015 12:42:12 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6CCC6181B3D; Tue, 24 Feb 2015 12:41:47 -0800 (PST) To: mchiba@cisco.com, gdommety@cisco.com, meklund@cisco.com, david@mitton.com, bernarda@microsoft.com, bclaise@cisco.com, joelja@bogus.com, stefan.winter@restena.lu, lionel.morand@orange.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150224204147.6CCC6181B3D@rfc-editor.org> Date: Tue, 24 Feb 2015 12:41:47 -0800 (PST) Archived-At: X-Mailman-Approved-At: Tue, 24 Feb 2015 22:28:08 -0800 Cc: radext@ietf.org, aland@freeradius.org, rfc-editor@rfc-editor.org Subject: [radext] [Technical Errata Reported] RFC5176 (4280) 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, 24 Feb 2015 20:42:15 -0000 The following errata report has been submitted for RFC5176, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5176&eid=4280 -------------------------------------- Type: Technical Reported by: Alan DeKok Section: 3.6 Original Text ------------- 0 0 0+ 101 Error-Cause In both tables, for CoA and Disconnect messages. Corrected Text -------------- 0 0+ 0+ 101 Error-Cause In both tables, for CoA and Disconnect messages. Notes ----- Section 3.5 says that Error-Cause may be sent in a CoA-ACK or Disconnect-ACK packet: ... Values 200-299 represent successful completion, so that these values may only be sent within CoA-ACK or Disconnect-ACK packets 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. -------------------------------------- RFC5176 (draft-ietf-radext-rfc3576bis-13) -------------------------------------- Title : Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) Publication Date : January 2008 Author(s) : M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba Category : INFORMATIONAL Source : RADIUS EXTensions Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Wed Feb 25 12:59:00 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08661A6F2E for ; Wed, 25 Feb 2015 06:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTo1Bk2Shhse for ; Wed, 25 Feb 2015 06:46:32 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB7C1A1B92 for ; Wed, 25 Feb 2015 06:46:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 6C05F22403E0; Wed, 25 Feb 2015 15:46:31 +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 bDDtTbBGGVDE; Wed, 25 Feb 2015 15:46:29 +0100 (CET) Received: from [192.168.20.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id 891CD22402ED; Wed, 25 Feb 2015 15:46:26 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: Date: Wed, 25 Feb 2015 09:46:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9BE727B3-42D6-4C3C-84E5-398B32D2D538@freeradius.org> References: <20150224204147.6CCC6181B3D@rfc-editor.org> To: Bernard Aboba X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Wed, 25 Feb 2015 12:58:59 -0800 Cc: "gdommety@cisco.com" , "radext@ietf.org" , "lionel.morand@orange.com" , Winter Stefan , "joelja@bogus.com" , "david@mitton.com" , "bclaise@cisco.com" , "meklund@cisco.com" , "mchiba@cisco.com" , RFC Errata System Subject: Re: [radext] [Technical Errata Reported] RFC5176 (4280) 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, 25 Feb 2015 14:46:34 -0000 I agree. There should be an additional paragraph after the paragraph = below, saying: ... Error-Cause MAY be included in a CoA-ACK and Disconnect-ACK packet to indicate successful actions. If it is included in those packets, the = Value MUST be within the range 200-299. ... There is further discussion of CoA-ACK in the text describing the = allowed VALUEs. But there should be a short sentence in the = Description, too. On Feb 24, 2015, at 6:07 PM, Bernard Aboba = wrote: > The Description text should also be addressed in this Errata: >=20 > Description >=20 > It is possible that a Dynamic Authorization Server cannot honor > Disconnect-Request or CoA-Request packets for some reason. The > Error-Cause Attribute provides more detail on the cause of the > problem. It MAY be included within CoA-NAK and Disconnect-NAK > packets. >=20 >=20 > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]=20 > Sent: Tuesday, February 24, 2015 12:42 PM > To: mchiba@cisco.com; gdommety@cisco.com; meklund@cisco.com; = david@mitton.com; Bernard Aboba; bclaise@cisco.com; joelja@bogus.com; = stefan.winter@restena.lu; lionel.morand@orange.com > Cc: aland@freeradius.org; radext@ietf.org; rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC5176 (4280) >=20 > The following errata report has been submitted for RFC5176, "Dynamic = Authorization Extensions to Remote Authentication Dial In User Service = (RADIUS)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5176&eid=3D4280 >=20 > -------------------------------------- > Type: Technical > Reported by: Alan DeKok >=20 > Section: 3.6 >=20 > Original Text > ------------- > 0 0 0+ 101 Error-Cause >=20 >=20 > In both tables, for CoA and Disconnect messages. >=20 > Corrected Text > -------------- > 0 0+ 0+ 101 Error-Cause >=20 >=20 > In both tables, for CoA and Disconnect messages. >=20 > Notes > ----- > Section 3.5 says that Error-Cause may be sent in a CoA-ACK or = Disconnect-ACK packet: >=20 > ... > Values 200-299 represent successful completion, so that these > values may only be sent within CoA-ACK or Disconnect-ACK packets >=20 > 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.=20 >=20 > -------------------------------------- > RFC5176 (draft-ietf-radext-rfc3576bis-13) > -------------------------------------- > Title : Dynamic Authorization Extensions to Remote = Authentication Dial In User Service (RADIUS) > Publication Date : January 2008 > Author(s) : M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. = Aboba > Category : INFORMATIONAL > Source : RADIUS EXTensions > Area : Operations and Management > Stream : IETF > Verifying Party : IESG >=20 From nobody Wed Feb 25 16:11:22 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819251A6F27 for ; Wed, 25 Feb 2015 16:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 Bc-AQ4t1HFOr for ; Wed, 25 Feb 2015 16:11:18 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (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 56D281A005D for ; Wed, 25 Feb 2015 16:11:18 -0800 (PST) Received: by lbvp9 with SMTP id p9so7524758lbv.3 for ; Wed, 25 Feb 2015 16:11:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=7qMBW8wYfFSgYYe7s/FBk34fJbtGGBIoboeFF+t9ypU=; b=uyl4fltwSVmOuSxIriQSMo/64oGgqE2srk20UFWE2ynSXu9Yw1U4PEO65H8SSxM7ua mE+k5FOzC09dUZFXyHCZyWunXLSZZ/+VtNJhced5DOyx4YpTsVZMFonvPEdEpIfgTPps 9XWVjXU12V7k3fDEVxHCqdBhyZrRubAdpBjlBuxtXOWhSpMmy8lNKOAhSzJOfsMuVGKc u4k9QV1KsrLgD1iApXom3klFLRrbQLTwnmHymw/xfShb1UHrlVQGMjDpoMErhAfWqjgI OsiW7WlD5/zMB0r55jN8Y2vXXbC34kykuWHJhOjBHi/r5MLbQHCkG+skzIU6p9TEBGEf mpPA== MIME-Version: 1.0 X-Received: by 10.112.46.201 with SMTP id x9mr5109176lbm.65.1424909476624; Wed, 25 Feb 2015 16:11:16 -0800 (PST) Received: by 10.112.167.101 with HTTP; Wed, 25 Feb 2015 16:11:16 -0800 (PST) Date: Wed, 25 Feb 2015 19:11:16 -0500 Message-ID: From: Kathleen Moriarty To: radext@ietf.org Content-Type: multipart/alternative; boundary=001a1134586a310015050ff29755 Archived-At: Subject: [radext] AD review of draft-ietf-radext-dynamic-discovery 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, 26 Feb 2015 00:11:20 -0000 --001a1134586a310015050ff29755 Content-Type: text/plain; charset=UTF-8 Hello, I reviewed draft-ietf-radext-dynamic-discovery and found it to be very well written, and covering security and privacy considerations nicely as well. Thank you for that. I just have a few nits and a question to see if some text can be further clarified before progressing this to last call. I'd like to start IETF last call very soon if the WG is ok with that. Nits & comments: Please expand out names of DNS labels on first use (NAPTR, SRV, RR, etc.). They are obvious to most of us, but are not in the list of acronyms that don't have to be spelled out, https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt (If there is a *, RFC editor is okay with not expanding) Section 3.4.3 In the algorithm, I am confused by step 12 that simply says "Proceed with step 18." Are there conditions that would have you decide to skip steps 13-17 or is this meant to be interpreted as proceed with step 18, then go back to step 13? The example later shows that you skip 13-17, but why this happens isn't clear to me. Did I miss an explanation? Section 3.4.4 First paragraph: The second sentence is super long and the last one is also a bit too long, can something be done to make these sentences easier to read? Section 3.4.5 Second to last sentence, just a nit: s/control/controls/ The algorithm therefore control execution time with TIMER. Section 3.4.6 There are some formatting issues at the start of this section, you are probably aware of already. Thank you. -- Best regards, Kathleen --001a1134586a310015050ff29755 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I reviewed draft-ietf= -radext-dynamic-discovery and found it to be very well written, and coverin= g security and privacy considerations nicely as well.=C2=A0 Thank you for t= hat.

I just have a few nits and a question to see = if some text can be further clarified before progressing this to last call.= =C2=A0 I'd like to start IETF last call very soon if the WG is ok with = that. =C2=A0

Nits & comments:

Please expand out names of DNS labels on first use (NAPTR, SRV, RR, etc= .).=C2=A0 They are obvious to most of us, but are not in the list of acrony= ms that don't have to be spelled out,
(If there is a *, RFC edi= tor is okay with not expanding)

Section 3.4.3
In the algorithm, I am confused by step 12 that simply says "Pro= ceed with step 18." =C2=A0Are there conditions that would have you dec= ide to skip steps 13-17 or is this meant to be interpreted as proceed with = step 18, then go back to step 13?=C2=A0 The example later shows that you sk= ip 13-17, but why this happens isn't clear to me.=C2=A0 Did I miss an e= xplanation?=C2=A0

Section 3.4.4
First pa= ragraph: The second sentence is super long and the last one is also a bit t= oo long, can something be done to make these sentences easier to read?

Section 3.4.5
Second to last sentence, just = a nit:
s/control/controls/
The algorithm therefore control execution time with
   TIMER.

Section 3.4.6
There are some f= ormatting issues at the start of this section, you are probably aware of al= ready.

Thank you.
--

Best regards,
Kathleen
=
--001a1134586a310015050ff29755-- From nobody Thu Feb 26 05:59:12 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EB81A00F3 for ; Thu, 26 Feb 2015 05:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 PGP34VRWwjan for ; Thu, 26 Feb 2015 05:59:03 -0800 (PST) Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id 612991A0122 for ; Thu, 26 Feb 2015 05:59:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id 49A403FAD for ; Thu, 26 Feb 2015 14:59:01 +0100 (CET) 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 h70NFsiDzk0K for ; Thu, 26 Feb 2015 14:59:01 +0100 (CET) Received: from [10.42.0.179] (84.121.18.25.dyn.user.ono.com [84.121.18.25]) (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 13E743E90 for ; Thu, 26 Feb 2015 14:59:00 +0100 (CET) Message-ID: <54EF26A3.6040502@um.es> Date: Thu, 26 Feb 2015 14:58:59 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "radext@ietf.org" Content-Type: multipart/alternative; boundary="------------030407000802000303060902" Archived-At: Subject: [radext] Review of draft-ietf-radext-bigger-packets-02.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: Thu, 26 Feb 2015 13:59:10 -0000 This is a multi-part message in MIME format. --------------030407000802000303060902 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Sam, here is my review of the new version of draft. Most of them are just typos. Overall, I think the document is ready for the WGLC, although as I mention below, I would appreciate more information about the handling of the Protocol-Error messages and the in the Proxies. 1. Abstract. RADIUS over TCP experiment needs a reference (RFC6613) as for the RADIUS over TLS experiment mentioned in the first sentence. 2. Abstract and Introduction. I'm not convinced that the reason of having new use cases where more than 4096 bytes are required in RADIUS is motivated only by RFC6614. Other security mechanisms such as IPsec or a trusted network would be enough to motivate use cases such as those described in ABFAB and/or in the aaa-saml draft. In our RADIUS fragmentation draft we mention ABFAB as the motivation. 3. Section 1. s/the RADIUS layer.RADIUS Fragmentation/the RADIUS layer. RADIUS Fragmentation/ 4. Section 1. Reference to draft-ietf-radext-radius-fragmentation seems quite old (-04, April 2014). Nevertheless, it should be an RFC sooner than later, so it can be updated then. 5. Section 1. s/arrises/arises/ 6. Section 2. While the text indicates that RADIUS Servers and CLients MUST be able to receive a packet of maximum length, proxies only SHOULD be able to do that. What's the reason of such a difference? Besides, I think the text should say "Proxies implementing this specification MUST be....". 7. Section 2. It has been difficult to me to understand the following paragraph: Proxies MUST include the Response-Length attribute when forwarding a request received over a transport with a 4096-octet maximum length over a transport with a higher maximum length. I would suggest to reword it, with something like this: (note that I also indicated that the value of the attribute should be 4096. Remove it if that's not correct) When a proxy receives a request over a transport with a 4096-octet maximum length, and this request is to be forwarded over a transport with a higher maximum length, the proxy MUST include a Response-Length attribute with a value of 4096 in such a request. 8. Section 2.1. s/Status-Request messages/Status-Server messages 9. Section 2.1. s/by including the attribute/By including the attribute 10. Section 3. s/When an RFc/When an RFC/ 11. Section 3. This section says that Respone-Length attribute MAY be included in a request to indicate that larger responses are desirable. Shouldn't it say "acceptable" instead of "desirable"? 12. Section 4. The section is titled "Protocol Error Type". Shouldn't it be "Protocol-Error code" instead? 13. Section 4. It is not clear to me what's the purpose of the Original-Packet-Code attribute. It is mentioned in the text, and described which values it should take. However, it is not explained how this value is used. 14. Section 4. s/TBD/TBDCODE/ (according to section 6) 15. Section 4. It is not clear to me how the messages with this code are handled by Proxies. Are they supposed to forward them back to the Client? Should they handle them individually? 16. Section 6. s/the maximum size RADIUS request that is/the maximum size of a RADIUS request that is/ 17. Section 7. s/these attacks/These attacks/ 18. Section 7. Does the sentence "This specification updates RFC 6613 and will be used with [RFC6614]" implies that TLS is mandatory for this specification? (see my comment for abstract and introduction) Regards, Alejandro --------------030407000802000303060902 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Sam,

here is my review of the new version of draft. Most of them are just typos.
Overall, I think the document is ready for the WGLC, although as I mention below, I would appreciate more information about the handling of the Protocol-Error messages and the  in the Proxies.

1. Abstract. RADIUS over TCP experiment needs a reference (RFC6613) as for the RADIUS over TLS experiment mentioned in the first sentence.

2. Abstract and Introduction. I'm not convinced that the reason of having new use cases where more than 4096 bytes are required in RADIUS is motivated only by RFC6614. Other security mechanisms such as IPsec or a trusted network would be enough to motivate use cases such as those described in ABFAB and/or in the aaa-saml draft. In our RADIUS fragmentation draft we mention ABFAB as the motivation.

3. Section 1. s/the RADIUS layer.RADIUS Fragmentation/the RADIUS layer. RADIUS Fragmentation/

4. Section 1. Reference to draft-ietf-radext-radius-fragmentation seems quite old (-04, April 2014). Nevertheless, it should be an RFC sooner than later, so it can be updated then.

5. Section 1. s/arrises/arises/

6. Section 2. While the text indicates that RADIUS Servers and CLients MUST be able to receive a packet of maximum length, proxies only SHOULD be able to do that. What's the reason of such a difference? Besides, I think the text should say "Proxies implementing this specification MUST be....".

7. Section 2. It has been difficult to me to understand the following paragraph:
Proxies MUST include the Response-Length attribute when
   forwarding a request received over a transport with a 4096-octet
   maximum length over a transport with a higher maximum length.

I would suggest to reword it, with something like this: (note that I also indicated that the value of the attribute should be 4096. Remove it if that's not correct)
When a proxy receives a request over a transport with a 4096-octet
   maximum length, and this request is to be forwarded over a transport with 
   a higher maximum length, the proxy MUST include a Response-Length 
   attribute with a value of 4096 in such a request.

8. Section 2.1. s/Status-Request messages/Status-Server messages

9. Section 2.1. s/by including the attribute/By including the attribute

10. Section 3. s/When an RFc/When an RFC/

11. Section 3. This section says that Respone-Length attribute MAY be included in a request to indicate that larger responses are desirable. Shouldn't it say "acceptable" instead of "desirable"?

12. Section 4. The section is titled "Protocol Error Type". Shouldn't it be "Protocol-Error code" instead?

13. Section 4. It is not clear to me what's the purpose of the Original-Packet-Code attribute. It is mentioned in the text, and described which values it should take. However, it is not explained how this value is used.

14. Section 4. s/TBD/TBDCODE/ (according to section 6)

15. Section 4. It is not clear to me how the messages with this code are handled by Proxies. Are they supposed to forward them back to the Client? Should they handle them individually?

16. Section 6. s/the maximum size RADIUS request that is/the maximum size of a RADIUS request that is/

17. Section 7. s/these attacks/These attacks/

18. Section 7. Does the sentence "This specification updates RFC 6613 and will be used with [RFC6614]" implies that TLS is mandatory for this specification? (see my comment for abstract and introduction)

Regards,
Alejandro





--------------030407000802000303060902-- From nobody Thu Feb 26 08:21:17 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043A01A871A for ; Thu, 26 Feb 2015 08:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTKVRvxjTKxA for ; Thu, 26 Feb 2015 08:21:11 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id C72131A1BD1 for ; Thu, 26 Feb 2015 08:21:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 1881622403C7; Thu, 26 Feb 2015 17:21:10 +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 GmbmiMzSmGRe; Thu, 26 Feb 2015 17:21:09 +0100 (CET) Received: from [192.168.20.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id 203052240084; Thu, 26 Feb 2015 17:21:08 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: <54EF26A3.6040502@um.es> Date: Thu, 26 Feb 2015 11:21:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54EF26A3.6040502@um.es> To: Alejandro Perez Mendez X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Review of draft-ietf-radext-bigger-packets-02.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: Thu, 26 Feb 2015 16:21:15 -0000 On Feb 26, 2015, at 8:58 AM, Alejandro Perez Mendez wrote: > 13. Section 4. It is not clear to me what's the purpose of the = Original-Packet-Code attribute. It is mentioned in the text, and = described which values it should take. However, it is not explained how = this value is used. The problem is that there are multiple packet types (Access-Request, = Accounting-Request, etc.) which could theoretically trigger a = Protocol-Error response. We can=92t send a normal response = (Access-Reject, Accounting-Response), because the error is in the = *transport* stage. So we have to send a Protocol-Error packet. But=85 we don=92t want multiple protocol error codes. e.g. = Access-Request-Protocol-Error, Accounting-Request-Protocol-Error, etc. = We just want Protocol-Error. The problem then becomes how do you match Protocol-Error to an = original packet? RADIUS/TCP allows for Access-Request and = Accounting-Request packets to share the same TCP connection. So if the = client receives Protocol-Error with ID 34, is it for Access-Request ID = 34, or Accounting-Request ID 34? Putting the Original-Packet-Code into Protocol-Error solves this = problem. The client can now look up the original packet code = (Access-Request or Accounting-Request), along with the ID (34), and get = the original packet. Alan DeKok. From nobody Thu Feb 26 10:02:08 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193601A90EC for ; Thu, 26 Feb 2015 10:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvOmB-1jrTZL for ; Thu, 26 Feb 2015 10:02:05 -0800 (PST) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id C993B1A040B for ; Thu, 26 Feb 2015 10:02:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id 7329AAD68; Thu, 26 Feb 2015 19:02:03 +0100 (CET) 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 l53KgqCfMOrP; Thu, 26 Feb 2015 19:02:03 +0100 (CET) Received: from [10.42.0.179] (84.121.18.25.dyn.user.ono.com [84.121.18.25]) (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 C695E9657; Thu, 26 Feb 2015 19:01:59 +0100 (CET) Message-ID: <54EF5F97.1060905@um.es> Date: Thu, 26 Feb 2015 19:01:59 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alan DeKok References: <54EF26A3.6040502@um.es> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Review of draft-ietf-radext-bigger-packets-02.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: Thu, 26 Feb 2015 18:02:08 -0000 El 26/02/15 a las 17:21, Alan DeKok escribió: > On Feb 26, 2015, at 8:58 AM, Alejandro Perez Mendez wrote: >> 13. Section 4. It is not clear to me what's the purpose of the Original-Packet-Code attribute. It is mentioned in the text, and described which values it should take. However, it is not explained how this value is used. > The problem is that there are multiple packet types (Access-Request, Accounting-Request, etc.) which could theoretically trigger a Protocol-Error response. We can’t send a normal response (Access-Reject, Accounting-Response), because the error is in the *transport* stage. So we have to send a Protocol-Error packet. > > But… we don’t want multiple protocol error codes. e.g. Access-Request-Protocol-Error, Accounting-Request-Protocol-Error, etc. We just want Protocol-Error. > > The problem then becomes how do you match Protocol-Error to an original packet? RADIUS/TCP allows for Access-Request and Accounting-Request packets to share the same TCP connection. So if the client receives Protocol-Error with ID 34, is it for Access-Request ID 34, or Accounting-Request ID 34? > > Putting the Original-Packet-Code into Protocol-Error solves this problem. The client can now look up the original packet code (Access-Request or Accounting-Request), along with the ID (34), and get the original packet. Hi Alan, thanks for the explanation. It is now clear. It serves to build a unique key in the form of (ID, Original-Packet-Code) which is used by the Client to match it with the corresponding request, as ID by itself cannot do it (is the Client allowed to create parallel Access-Requests and Accounting-Requests with the same ID?) Anyway, I think that this kind of explanation (perhaps not so detailed, but at least a summary) should be in the document. Regards, Alejandro > > Alan DeKok. > From nobody Thu Feb 26 10:06:57 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF0C1A90BF for ; Thu, 26 Feb 2015 10:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdoYJenFPHH6 for ; Thu, 26 Feb 2015 10:06:48 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6CF11A9083 for ; Thu, 26 Feb 2015 10:06:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 1921F20601; Thu, 26 Feb 2015 13:06:11 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksyMsOtyXO-W; Thu, 26 Feb 2015 13:06:10 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.106]) (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; Thu, 26 Feb 2015 13:06:10 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 89E6680480; Thu, 26 Feb 2015 13:06:46 -0500 (EST) From: Sam Hartman To: Alejandro Perez Mendez References: <54EF26A3.6040502@um.es> <54EF5F97.1060905@um.es> Date: Thu, 26 Feb 2015 13:06:46 -0500 In-Reply-To: <54EF5F97.1060905@um.es> (Alejandro Perez Mendez's message of "Thu, 26 Feb 2015 19:01:59 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "radext@ietf.org" , Alan DeKok Subject: Re: [radext] Review of draft-ietf-radext-bigger-packets-02.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: Thu, 26 Feb 2015 18:06:55 -0000 >>>>> "Alejandro" == Alejandro Perez Mendez writes: Alejandro> Hi Alan, Alejandro> thanks for the explanation. It is now clear. It serves to Alejandro> build a unique key in the form of (ID, Alejandro> Original-Packet-Code) which is used by the Client to Alejandro> match it with the corresponding request, as ID by itself Alejandro> cannot do it (is the Client allowed to create parallel Alejandro> Access-Requests and Accounting-Requests with the same Alejandro> ID?) >From my edit buffer: A Protocol-Error packet MUST contain a Original-Packet-Code attribute, along with an Error-Cause attribute. Other attributes MAY be included if desired. The Original-Packet-Code contains the code from the reque\ st that generated the protocol error so that clients can disambiguate requests \ with different codes and the same ID. Is that sufficient? From nobody Thu Feb 26 10:13:38 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569521AC3A0 for ; Thu, 26 Feb 2015 10:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQ9n4DPEKqpl for ; Thu, 26 Feb 2015 10:13:35 -0800 (PST) Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id C8C061AC398 for ; Thu, 26 Feb 2015 10:13:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id BBC4243CB; Thu, 26 Feb 2015 19:13:31 +0100 (CET) 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 BSNRgp5xkGvg; Thu, 26 Feb 2015 19:13:31 +0100 (CET) Received: from [10.42.0.179] (84.121.18.25.dyn.user.ono.com [84.121.18.25]) (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 62165B0F; Thu, 26 Feb 2015 19:13:29 +0100 (CET) Message-ID: <54EF6249.1010600@um.es> Date: Thu, 26 Feb 2015 19:13:29 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Sam Hartman References: <54EF26A3.6040502@um.es> <54EF5F97.1060905@um.es> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "radext@ietf.org" , Alan DeKok Subject: Re: [radext] Review of draft-ietf-radext-bigger-packets-02.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: Thu, 26 Feb 2015 18:13:36 -0000 El 26/02/15 a las 19:06, Sam Hartman escribió: >>>>>> "Alejandro" == Alejandro Perez Mendez writes: > Alejandro> Hi Alan, > > Alejandro> thanks for the explanation. It is now clear. It serves to > Alejandro> build a unique key in the form of (ID, > Alejandro> Original-Packet-Code) which is used by the Client to > Alejandro> match it with the corresponding request, as ID by itself > Alejandro> cannot do it (is the Client allowed to create parallel > Alejandro> Access-Requests and Accounting-Requests with the same > Alejandro> ID?) > > From my edit buffer: > > A Protocol-Error packet MUST contain a Original-Packet-Code > attribute, > along with an Error-Cause attribute. Other attributes MAY be > included if desired. The Original-Packet-Code contains the code > from the reque\ > st that generated the protocol error so that clients can > disambiguate requests \ > with different codes and the same ID. > > Is that sufficient? It is for me.