From nobody Mon Jan  5 02:26:16 2015
Return-Path: <bclaise@cisco.com>
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 130C31A1B8A for <radext@ietfa.amsl.com>; Mon,  5 Jan 2015 02:26:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.11
X-Spam-Level: 
X-Spam-Status: No, score=-13.11 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6DtEi67j1xZ for <radext@ietfa.amsl.com>; Mon,  5 Jan 2015 02:26:11 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCAFB1A6D3F for <radext@ietf.org>; Mon,  5 Jan 2015 02:26:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1542; q=dns/txt; s=iport; t=1420453571; x=1421663171; h=message-id:date:from:mime-version:to:subject; bh=kb0VRLvX3FOHX9AuPF8iy7NODOTWXx5rD0ZwoSS9AXc=; b=PZVYn2TGCcA6JbwqMPDj5ImR0nWkK/EyPDavmaYH0y7ZzFUvxxqzeoBn BBNiC95o814f0RLtjpXSzskHwMDplpP0vtPNO3FSK7NIQkaEomg7QvBjG XjXgB3E4RWpziF4UHRa4Vlmj4MPLsdI0A0yfMbs2cnz5EcNImLro2Lzyf I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqQEAKJlqlStJssW/2dsb2JhbABcg1jGd4cPAQEBAQF9hAOBCB8BHRYYAwIBAgFLDQgBAYgoDZlQowABAQEHAQEBARoElCcFlwiGBItMIoNvPYJ0AQEB
X-IronPort-AV: E=Sophos;i="5.07,698,1413244800";  d="scan'208,217";a="300407728"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 05 Jan 2015 10:26:08 +0000
Received: from [10.61.99.148] (dhcp-10-61-99-148.cisco.com [10.61.99.148]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t05AQ8DJ002118 for <radext@ietf.org>; Mon, 5 Jan 2015 10:26:08 GMT
Message-ID: <54AA62E9.5030105@cisco.com>
Date: Mon, 05 Jan 2015 11:09:45 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: "radext@ietf.org" <radext@ietf.org>
Content-Type: multipart/alternative; boundary="------------090600040902010003010109"
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/REuB_UZ1rs3qIihbWn-jNFWXtPY
Subject: [radext] RADEXT co-chair replacement
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jan 2015 10:26:13 -0000

This is a multi-part message in MIME format.
--------------090600040902010003010109
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Jouni expressed the desire to step down as RADEXT co-chair.
I would like to thank Jouni for all these years of RADIUS dedication: 
You clearly made a difference!

In terms of co-chair replacement, Lionel Morand accepted this open position.
Lionel's chair experience, combined with a strong AAA knowledge 
<https://www.youtube.com/watch?v=7yMwP1D3Um4>, will provide a smooth 
transition, I'm sure!

Regards, Benoit





--------------090600040902010003010109
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Dear all,<br>
    <br>
    Jouni expressed the desire to step down as RADEXT co-chair.<br>
    I would like to thank Jouni for all these years of RADIUS
    dedication: You clearly made a difference!<br>
    <br>
    In terms of co-chair replacement, Lionel Morand accepted this open
    position.<br>
    Lionel's chair experience, combined with a strong <a
      href="https://www.youtube.com/watch?v=7yMwP1D3Um4">AAA knowledge</a>,
    will provide a smooth transition, I'm sure!<br>
    <br>
    Regards, Benoit<br>
    <br>
    <br>
    <br>
    <br>
  </body>
</html>

--------------090600040902010003010109--


From nobody Mon Jan  5 05:28:48 2015
Return-Path: <hartmans@painless-security.com>
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 A18AB1A879F for <radext@ietfa.amsl.com>; Mon,  5 Jan 2015 05:28:46 -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 QPUFH9pMhK9q for <radext@ietfa.amsl.com>; Mon,  5 Jan 2015 05:28:45 -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 B47F41A7018 for <radext@ietf.org>; Mon,  5 Jan 2015 05:28:44 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 6353320550 for <radext@ietf.org>; Mon,  5 Jan 2015 08:24:18 -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 x3dGWh7__DzF for <radext@ietf.org>; Mon,  5 Jan 2015 08:24:18 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org (c-50-157-131-57.hsd1.ma.comcast.net [50.157.131.57]) (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 for <radext@ietf.org>; Mon,  5 Jan 2015 08:24:18 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 72A3780EC9; Mon,  5 Jan 2015 08:28:33 -0500 (EST)
From: Sam Hartman <hartmans@painless-security.com>
To: radext@ietf.org
Date: Mon, 05 Jan 2015 08:28:33 -0500
Message-ID: <tslfvbp9x1a.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/XL9Qw4qE4AdYb5dj8zEIAxCom5Q
Subject: [radext] draft-ietf-radext-bigger-packets update in early February
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jan 2015 13:28:46 -0000

Hi, folks.
I'm in the middle of some significant deadlines at work and it will be
early February before I get around to updating bigger packets.
It's about to expire so I plan to republish without updates, but this
version will not include Alan's fixes for the last call comments.

--Sam


From nobody Thu Jan  8 04:12:42 2015
Return-Path: <bclaise@cisco.com>
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 67C2F1A89F0 for <radext@ietfa.amsl.com>; Thu,  8 Jan 2015 04:12:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.21
X-Spam-Level: 
X-Spam-Status: No, score=-12.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 kZVNW4WhfkA4 for <radext@ietfa.amsl.com>; Thu,  8 Jan 2015 04:12:32 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33E841ACD1A for <radext@ietf.org>; Thu,  8 Jan 2015 04:12:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3522; q=dns/txt; s=iport; t=1420719150; x=1421928750; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=p3riW8v1dYIg24wzaEoJhGKic8QYfVpLSlaEkm5ZqL8=; b=kzYutmg36QKu3Hcq5TocGDiW87UkmJdKQod939U5jhwqctzAtx8mE+AM TApN86oQHjE+u0RDyXDHCN3JtZsW7Fnxnj3SSpdQ1WZNcI+34Xpgpl6Bf 3Ym1qLmFXwx9hiWXZsIS6PWrgrl0I/Y1Lm+rvAgU2fTHycQBLpNCBL3hr 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: As4EAPxyrlStJssW/2dsb2JhbABcg1hYxgSFcQKBVAEBAQEBfYQNAQEEeAEQDx0WDwkDAgECAUUGDQEHAQGIKA3GNwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEjygBAUsEB4QpBZF2ggODQYEOgnGCF4gfgzkig289MQGBC4E3AQEB
X-IronPort-AV: E=Sophos;i="5.07,722,1413244800";  d="scan'208,217";a="303699615"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 08 Jan 2015 12:12:28 +0000
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t08CCR1h004160; Thu, 8 Jan 2015 12:12:27 GMT
Message-ID: <54AE742B.9090509@cisco.com>
Date: Thu, 08 Jan 2015 13:12:27 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: "radext@ietf.org" <radext@ietf.org>
References: <54AE70A5.6070407@cisco.com>
In-Reply-To: <54AE70A5.6070407@cisco.com>
X-Forwarded-Message-Id: <54AE70A5.6070407@cisco.com>
Content-Type: multipart/alternative; boundary="------------010905000604000409040809"
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/7HJPN_xiA1DAE9eglfROOJzASYI>
Cc: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
Subject: [radext] RADEXT WG transition to Kathleen as Responsible AD
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jan 2015 12:12:36 -0000

This is a multi-part message in MIME format.
--------------010905000604000409040809
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

In order to execute the IESG YANG Model Work Redistribution plan (see
https://www.ietf.org/mail-archive/web/ietf/current/msg90926.html) and in
accordance with the IETF areas re-organisation steps (see
https://www.ietf.org/mail-archive/web/ietf/current/msg91015.html),
Kathleen Moriarty will become the RADEXT responsible AD. You will be in
good hands with Kathleen, who will also be the DIME responsible AD.

Note that RADEXT WG will remain in the OPS area. While Kathleen will be
the responsible starting now, this change will only appear on the
charter page in a little bit (we're targeting mid February). Indeed, the
tooling aspects will have to checked: we might face a few issues when a
non-OPS AD is responsible for an OPS WG.

I will continue processing the drafts for which I started the AD review.
Practically, it means:
     -draft-ietf-radext-nai-15  <https://datatracker.ietf.org/doc/draft-ietf-radext-nai/>
     -draft-ietf-radext-radius-fragmentation-09  <https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/>

Note that I don't disappear from the IESG and I'm always available if you require
my help, but Kathleen is now your responsible AD.

It was a pleasure being your AD for the last 3 years. Please continue
the good work.

Regards, Benoit




--------------010905000604000409040809
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-forward-container">
      <pre>Dear all,

In order to execute the IESG YANG Model Work Redistribution plan (see 
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mail-archive/web/ietf/current/msg90926.html">https://www.ietf.org/mail-archive/web/ietf/current/msg90926.html</a>) and in 
accordance with the IETF areas re-organisation steps (see 
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mail-archive/web/ietf/current/msg91015.html">https://www.ietf.org/mail-archive/web/ietf/current/msg91015.html</a>), 
Kathleen Moriarty will become the RADEXT responsible AD. You will be in 
good hands with Kathleen, who will also be the DIME responsible AD.

Note that RADEXT WG will remain in the OPS area. While Kathleen will be 
the responsible starting now, this change will only appear on the 
charter page in a little bit (we're targeting mid February). Indeed, the 
tooling aspects will have to checked: we might face a few issues when a 
non-OPS AD is responsible for an OPS WG.

I will continue processing the drafts for which I started the AD review.
Practically, it means:
&nbsp;&nbsp;&nbsp; - <a href="https://datatracker.ietf.org/doc/draft-ietf-radext-nai/">draft-ietf-radext-nai-15</a>
    - <a href="https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/">draft-ietf-radext-radius-fragmentation-09</a>

Note that I don't disappear from the IESG and I'm always available if you require 
my help, but Kathleen is now your responsible AD.

It was a pleasure being your AD for the last 3 years. Please continue 
the good work.

Regards, Benoit
</pre>
      <br>
    </div>
    <br>
  </body>
</html>

--------------010905000604000409040809--


From nobody Fri Jan  9 00:55:16 2015
Return-Path: <internet-drafts@ietf.org>
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 8A48C1A8730; Fri,  9 Jan 2015 00:55:11 -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 vSVaR7CBlc3F; Fri,  9 Jan 2015 00:55:08 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4B31A86FE; Fri,  9 Jan 2015 00:55:08 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p8
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150109085508.20842.98092.idtracker@ietfa.amsl.com>
Date: Fri, 09 Jan 2015 00:55:08 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/6iiAomSWvm3FcS-YWSGfuMwdoVw>
Cc: radext@ietf.org
Subject: [radext] I-D Action: draft-ietf-radext-radius-fragmentation-10.txt
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jan 2015 08:55:12 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

        Title           : Support of fragmentation of RADIUS packets
        Authors         : Alejandro Perez-Mendez
                          Rafa Marin-Lopez
                          Fernando Pereniguez-Garcia
                          Gabriel Lopez-Millan
                          Diego R. Lopez
                          Alan DeKok
	Filename        : draft-ietf-radext-radius-fragmentation-10.txt
	Pages           : 35
	Date            : 2015-01-09

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


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

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

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


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 Jan  9 00:55:19 2015
Return-Path: <internet-drafts@ietf.org>
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 21BBB1A8730 for <radext@ietfa.amsl.com>; Fri,  9 Jan 2015 00:55:13 -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 KvTSK3d18xkJ; Fri,  9 Jan 2015 00:55:11 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5891A871D; Fri,  9 Jan 2015 00:55:09 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu, bclaise@cisco.com
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p8
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150109085509.20842.44036.idtracker@ietfa.amsl.com>
Date: Fri, 09 Jan 2015 00:55:09 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/cdqlb0YzZwgaBJfjJ4d7fyXwczg>
Subject: [radext] New Version Notification - draft-ietf-radext-radius-fragmentation-10.txt
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jan 2015 08:55:13 -0000

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


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

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-10

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 Jan  9 06:26:58 2015
Return-Path: <ietf-secretariat-reply@ietf.org>
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 5C3341A8AA8; Fri,  9 Jan 2015 06:26:53 -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 nWLby63gyInp; Fri,  9 Jan 2015 06:26:51 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF871A8972; Fri,  9 Jan 2015 06:26:51 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: radext@ietf.org, iesg-secretary@ietf.org, iesg@ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p8
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150109142651.10928.13057.idtracker@ietfa.amsl.com>
Date: Fri, 09 Jan 2015 06:26:51 -0800
From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/iAtNYhXLuSJrdYM3uPHh6n2kgc8>
Subject: [radext] Telechat update notice: <draft-ietf-radext-radius-fragmentation-10.txt>
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jan 2015 14:26:53 -0000

Placed on agenda for telechat - 2015-01-22
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/


From nobody Fri Jan  9 12:05:41 2015
Return-Path: <ietf-secretariat-reply@ietf.org>
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 370271AC3E9 for <radext@ietfa.amsl.com>; Fri,  9 Jan 2015 12:05:36 -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 b3CkVg50btRz; Fri,  9 Jan 2015 12:05:33 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 944361A9109; Fri,  9 Jan 2015 12:05:33 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p8
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150109200533.12415.46588.idtracker@ietfa.amsl.com>
Date: Fri, 09 Jan 2015 12:05:33 -0800
From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/-0e_tEod7Rm3ETyDwnmwm9mTLRM>
Subject: [radext] ID Tracker State Update Notice: <draft-ietf-radext-radius-fragmentation-10.txt>
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jan 2015 20:05:36 -0000

IANA review state changed to IANA OK - Actions Needed
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/


From nobody Sat Jan 17 12:43:16 2015
Return-Path: <adrian@olddog.co.uk>
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 446B61AD0C4; Sat, 17 Jan 2015 12:43:13 -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 eFycSu3JxepP; Sat, 17 Jan 2015 12:43:11 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C33ED1ACEE4; Sat, 17 Jan 2015 12:43:11 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p8
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150117204311.10536.79379.idtracker@ietfa.amsl.com>
Date: Sat, 17 Jan 2015 12:43:11 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/B2zxzudKiCpblvjxLbuEY8GyqJ8>
Cc: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu
Subject: [radext] Adrian Farrel's No Objection on draft-ietf-radext-radius-fragmentation-10: (with COMMENT)
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Jan 2015 20:43:13 -0000

Adrian Farrel has entered the following ballot position for
draft-ietf-radext-radius-fragmentation-10: No Objection

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:
----------------------------------------------------------------------

Thank you for positioning this as Experimental and for writing sections 2
and 3: they cleared up any concerns I had.

In section 3 you say:
   Instead, the CoA client MUST send a CoA-Request
   packet containing session identification attributes, along with
   Service-Type = Additional-Authorization, and a State attribute.
   Implementations not supporting fragmentation will respond with a CoA-
   NAK, and an Error-Cause of Unsupported-Service.
Since this is not new behaviour (i.e. an implementation that is not part
of this experiment will follow this behaviour according to previous
specifications), a reference would be nice. Perhaps...
s/the CoA client MUST/according to [RFCfoo] the CoA client will/



From nobody Mon Jan 19 01:15:59 2015
Return-Path: <alex@um.es>
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 481971AD360; Mon, 19 Jan 2015 01:15:50 -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 VkEOrFZJOd8r; Mon, 19 Jan 2015 01:15:46 -0800 (PST)
Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id A437F1AD355; Mon, 19 Jan 2015 01:15:46 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id B94534AF1; Mon, 19 Jan 2015 10:15:42 +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 dK4HSVnqpFav; Mon, 19 Jan 2015 10:15:42 +0100 (CET)
Received: from [155.54.205.116] (inf-205-116.inf.um.es [155.54.205.116]) (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 19893982; Mon, 19 Jan 2015 10:15:35 +0100 (CET)
Message-ID: <54BCCB36.4050404@um.es>
Date: Mon, 19 Jan 2015 10:15:34 +0100
From: Alejandro Perez Mendez <alex@um.es>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Adrian Farrel <adrian@olddog.co.uk>, The IESG <iesg@ietf.org>
References: <20150117204311.10536.79379.idtracker@ietfa.amsl.com>
In-Reply-To: <20150117204311.10536.79379.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/wsboA1T_yz7UL0jtedyf-kN1HkQ>
Cc: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu
Subject: Re: [radext] Adrian Farrel's No Objection on draft-ietf-radext-radius-fragmentation-10: (with COMMENT)
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Jan 2015 09:15:50 -0000

> Adrian Farrel has entered the following ballot position for
> draft-ietf-radext-radius-fragmentation-10: No Objection
>
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for positioning this as Experimental and for writing sections 2
> and 3: they cleared up any concerns I had.
>
> In section 3 you say:
>     Instead, the CoA client MUST send a CoA-Request
>     packet containing session identification attributes, along with
>     Service-Type = Additional-Authorization, and a State attribute.
>     Implementations not supporting fragmentation will respond with a CoA-
>     NAK, and an Error-Cause of Unsupported-Service.
> Since this is not new behaviour (i.e. an implementation that is not part
> of this experiment will follow this behaviour according to previous
> specifications), a reference would be nice. Perhaps...
> s/the CoA client MUST/according to [RFCfoo] the CoA client will/
>
>

Hi Adrian,

thanks for the comment. It makes total sense.
We will do that when we are requested to produce a new version.

Regards,
Alejandro


From nobody Mon Jan 19 15:35:31 2015
Return-Path: <barryleiba@computer.org>
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 924E51B2D29; Mon, 19 Jan 2015 15:35:30 -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 R2RyIkyy2yQw; Mon, 19 Jan 2015 15:35:29 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9381ACE82; Mon, 19 Jan 2015 15:35:29 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Barry Leiba" <barryleiba@computer.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p8
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150119233529.24420.90147.idtracker@ietfa.amsl.com>
Date: Mon, 19 Jan 2015 15:35:29 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/_dIkFA9JnbiRZOjL-JgyIxqvYw4>
Cc: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu
Subject: [radext] Barry Leiba's Discuss on draft-ietf-radext-radius-fragmentation-10: (with DISCUSS and COMMENT)
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Jan 2015 23:35:30 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-radext-radius-fragmentation-10: 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:
----------------------------------------------------------------------

This is just to make sure that the IANA allocations are clear, because I
have some questions about that:

-- Section 14 --

   In particular, this document defines two new RADIUS attributes,
   entitled "Frag-Status" and "Proxy-State-Len" (see section 9),
   assigned values of TBD1 and TBD2 from the Long Extended Space

But these are not defined in Section 9, but in Sections 10.1 and 10.2.

And I see that these are the "Type" values, but where's the allocation of
the "Extended-Type" values that are mentioned in those sections?

Also, there's another "TBA" at the end of Section 14 that points to
Section 4.1, but there is no Section 4.1.  It looks like maybe that's
supposed to be 5.1.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This seems a very well written document, and was easy to read.  In
particular, thanks very much for Section 2: it's one of the best of that
sort of explanation I've seen, and should be a model for other such
specs.

Very minor point: In the diagram in Section 3, I suggest fitting all the
boxed text as in the box that includes "CoA Proxy".  That is, putting
"CoA" on top of "Server" and "client" (why not "Client"?) in the other
boxes makes the separation between the left-side text and the right-side
text just a little clearer.

-- Sections 10.1 and 10.2 --
It's not clear to me how the RFC Editor will know which values to replace
into the four "TBA" items in these sections (two "Type" and two
"Extended-Type" values).  Shouldn't they be distinguished from each
other, to make that clear?  (And see my DISCUSS comments.)



From nobody Mon Jan 19 23:43:41 2015
Return-Path: <alex@um.es>
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 249561B2D75; Mon, 19 Jan 2015 23:43:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 nk2XdwKteqIj; Mon, 19 Jan 2015 23:43:37 -0800 (PST)
Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id C66A91B2D68; Mon, 19 Jan 2015 23:43:36 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 61E2CF0E; Tue, 20 Jan 2015 08:43:34 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon23.um.es
Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SDwhtHaAEbHk; Tue, 20 Jan 2015 08:43:34 +0100 (CET)
Received: from [10.42.0.18] (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 xenon23.um.es (Postfix) with ESMTPSA id 8785F215; Tue, 20 Jan 2015 08:43:29 +0100 (CET)
Message-ID: <54BE0721.6060401@um.es>
Date: Tue, 20 Jan 2015 08:43:29 +0100
From: Alejandro Perez Mendez <alex@um.es>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Barry Leiba <barryleiba@computer.org>, The IESG <iesg@ietf.org>
References: <20150119233529.24420.90147.idtracker@ietfa.amsl.com>
In-Reply-To: <20150119233529.24420.90147.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------020206000204010801040500"
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/T9qY23LbKdcDdXkcWORZpwfySWQ>
Cc: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu
Subject: Re: [radext] Barry Leiba's Discuss on draft-ietf-radext-radius-fragmentation-10: (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 <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Jan 2015 07:43:40 -0000

This is a multi-part message in MIME format.
--------------020206000204010801040500
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Barry,

thanks for your comments. See my responses inline, please.

El 20/01/15 a las 00:35, Barry Leiba escribió:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> This is just to make sure that the IANA allocations are clear, because I
> have some questions about that:
>
> -- Section 14 --
>
>     In particular, this document defines two new RADIUS attributes,
>     entitled "Frag-Status" and "Proxy-State-Len" (see section 9),
>     assigned values of TBD1 and TBD2 from the Long Extended Space
>
> But these are not defined in Section 9, but in Sections 10.1 and 10.2.

Right. It seems I forgot inserting an <xref> in this place, and 
therefore it didn't get updated when we included the new section 2.

>
> And I see that these are the "Type" values, but where's the allocation of
> the "Extended-Type" values that are mentioned in those sections?

Yes. Indeed, this is something the IANA already brought in. Lionel 
Morand provided suggestion of how to solve this issue, that has been 
agreed by us as the best way forward. In particular, the type will be 
fixed to 241, whereas the Extended-Type would be TBDX.

The table would look as follows:

Type       Name                   Length  Meaning
        ----       ----                   ------ -------
241.TBD1   Frag-Status            7       Signals fragmentation
241.TBD2   Proxy-State-Len(*gth*) 7       Indicates the length of the
            received Proxy-State attributes

And the text in section 10.1 and 10.2 would be:

     Type
241 (To be confirmed by IANA)

     Length
7

     Extended-Type
TBDX

>
> Also, there's another "TBA" at the end of Section 14 that points to
> Section 4.1, but there is no Section 4.1.  It looks like maybe that's
> supposed to be 5.1.

Yes. In figure elements it seems that <xref> tags are not possible, and 
I forgot to update these numbers when Section 2 was introduced. The same 
has happened with the table immediately above that one, which points to 
Section 9.1 while it should say 10.1. Both need to be updated.

>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> This seems a very well written document, and was easy to read.  In
> particular, thanks very much for Section 2: it's one of the best of that
> sort of explanation I've seen, and should be a model for other such
> specs.

Thanks.

>
> Very minor point: In the diagram in Section 3, I suggest fitting all the
> boxed text as in the box that includes "CoA Proxy".  That is, putting
> "CoA" on top of "Server" and "client" (why not "Client"?) in the other
> boxes makes the separation between the left-side text and the right-side
> text just a little clearer.

We'll do it. Thanks.

>
> -- Sections 10.1 and 10.2 --
> It's not clear to me how the RFC Editor will know which values to replace
> into the four "TBA" items in these sections (two "Type" and two
> "Extended-Type" values).  Shouldn't they be distinguished from each
> other, to make that clear?  (And see my DISCUSS comments.)
>
>

See my comments above. Now TBA is only applied to the 
"Additional-Authorization" value.

Best regards,
Alejandro


--------------020206000204010801040500
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi Barry,<br>
    <br>
    thanks for your comments. See my responses inline, please.<br>
    <br>
    <div class="moz-cite-prefix">El 20/01/15 a las 00:35, Barry Leiba
      escribió:<br>
    </div>
    <blockquote
      cite="mid:20150119233529.24420.90147.idtracker@ietfa.amsl.com"
      type="cite">
      <pre wrap="">----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is just to make sure that the IANA allocations are clear, because I
have some questions about that:

-- Section 14 --

   In particular, this document defines two new RADIUS attributes,
   entitled "Frag-Status" and "Proxy-State-Len" (see section 9),
   assigned values of TBD1 and TBD2 from the Long Extended Space

But these are not defined in Section 9, but in Sections 10.1 and 10.2.</pre>
    </blockquote>
    <br>
    Right. It seems I forgot inserting an &lt;xref&gt; in this place,
    and therefore it didn't get updated when we included the new section
    2.<br>
    <br>
    <blockquote
      cite="mid:20150119233529.24420.90147.idtracker@ietfa.amsl.com"
      type="cite">
      <pre wrap="">

And I see that these are the "Type" values, but where's the allocation of
the "Extended-Type" values that are mentioned in those sections?</pre>
    </blockquote>
    <br>
    Yes. Indeed, this is something the IANA already brought in. Lionel
    Morand provided suggestion of how to solve this issue, that has been
    agreed by us as the best way forward. In particular, the type will
    be fixed to 241, whereas the Extended-Type would be TBDX.<br>
    <br>
    The table would look as follows: <tt><br>
    </tt><br>
    <tt><span style="font-size: 10pt; color: windowtext;" lang="EN-US">      
        Type       Name                   Length  Meaning<o:p></o:p></span></tt><br>
    <tt>
    </tt><tt><span style="font-size: 10pt; color: windowtext;"
        lang="EN-US">       ----       ----                   ------ 
        -------<o:p></o:p></span></tt><br>
    <tt><span style="font-size: 10pt; color: windowtext;" lang="EN-US">      
        241.TBD1   Frag-Status            7       Signals fragmentation<o:p></o:p></span></tt><br>
    <tt><span style="font-size: 10pt; color: windowtext;" lang="EN-US">      
        241.TBD2   Proxy-State-Len(*gth*) 7       Indicates the length
        of the<o:p></o:p></span></tt><br>
    <tt>
    </tt><tt><span style="font-size: 10pt; color: windowtext;"
        lang="EN-US">                                     
                   received Proxy-State attributes</span></tt><br>
    <br>
    And the text in section 10.1 and 10.2 would be:<br>
    <span style="font-size:10.0pt;font-family:&quot;Courier
      New&quot;;color:windowtext"><br>
    </span><span style="font-size:10.0pt;font-family:&quot;Courier
      New&quot;;color:windowtext"><tt>    Type</tt><tt><o:p></o:p></tt></span><tt></tt><tt><span
        style="font-size: 10pt; color: windowtext;"><o:p> </o:p></span></tt><tt>
    </tt><br>
    <tt><span style="font-size: 10pt; color: windowtext;" lang="EN-US">     
        241 (To be confirmed by IANA)<o:p></o:p></span></tt><br>
    <tt><span style="font-size: 10pt; color: windowtext;" lang="EN-US">  
        <br>
            Length<o:p></o:p></span></tt><br>
    <tt><span style="font-size: 10pt; color: windowtext;" lang="EN-US">     
        7<o:p></o:p></span></tt><br>
    <tt><span style="font-size: 10pt; color: windowtext;" lang="EN-US">   
        <br>
            Extended-Type<o:p></o:p></span></tt><tt><span
        style="font-size: 10pt; color: windowtext;" lang="EN-US"><o:p> </o:p></span></tt>
    <br>
    <tt><span style="font-size: 10pt; color: windowtext;" lang="EN-US">     
        TBDX</span></tt><br>
    <br>
    <blockquote
      cite="mid:20150119233529.24420.90147.idtracker@ietfa.amsl.com"
      type="cite">
      <pre wrap="">

Also, there's another "TBA" at the end of Section 14 that points to
Section 4.1, but there is no Section 4.1.  It looks like maybe that's
supposed to be 5.1.</pre>
    </blockquote>
    <br>
    Yes. In figure elements it seems that &lt;xref&gt; tags are not
    possible, and I forgot to update these numbers when Section 2 was
    introduced. The same has happened with the table immediately above
    that one, which points to Section 9.1 while it should say 10.1. Both
    need to be updated.<br>
    <br>
    <blockquote
      cite="mid:20150119233529.24420.90147.idtracker@ietfa.amsl.com"
      type="cite">
      <pre wrap="">


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This seems a very well written document, and was easy to read.  In
particular, thanks very much for Section 2: it's one of the best of that
sort of explanation I've seen, and should be a model for other such
specs.</pre>
    </blockquote>
    <br>
    Thanks.<br>
    <br>
    <blockquote
      cite="mid:20150119233529.24420.90147.idtracker@ietfa.amsl.com"
      type="cite">
      <pre wrap="">

Very minor point: In the diagram in Section 3, I suggest fitting all the
boxed text as in the box that includes "CoA Proxy".  That is, putting
"CoA" on top of "Server" and "client" (why not "Client"?) in the other
boxes makes the separation between the left-side text and the right-side
text just a little clearer.</pre>
    </blockquote>
    <br>
    We'll do it. Thanks.<br>
    <br>
    <blockquote
      cite="mid:20150119233529.24420.90147.idtracker@ietfa.amsl.com"
      type="cite">
      <pre wrap="">

-- Sections 10.1 and 10.2 --
It's not clear to me how the RFC Editor will know which values to replace
into the four "TBA" items in these sections (two "Type" and two
"Extended-Type" values).  Shouldn't they be distinguished from each
other, to make that clear?  (And see my DISCUSS comments.)


</pre>
    </blockquote>
    <br>
    See my comments above. Now TBA is only applied to the
    "Additional-Authorization" value.<br>
    <br>
    Best regards,<br>
    Alejandro<br>
    <br>
  </body>
</html>

--------------020206000204010801040500--


From nobody Tue Jan 20 03:55:27 2015
Return-Path: <internet-drafts@ietf.org>
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 E2B971B2A1B; Tue, 20 Jan 2015 03:55:22 -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 E2w9KWyDAVjN; Tue, 20 Jan 2015 03:55:21 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 637D91B29EB; Tue, 20 Jan 2015 03:55:21 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p8
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150120115521.18529.86484.idtracker@ietfa.amsl.com>
Date: Tue, 20 Jan 2015 03:55:21 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/lIwP-yd7nA2jZYy_QhIApEEpe_M>
Cc: radext@ietf.org
Subject: [radext] I-D Action: draft-ietf-radext-radius-fragmentation-11.txt
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Jan 2015 11:55:23 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

        Title           : Support of fragmentation of RADIUS packets
        Authors         : Alejandro Perez-Mendez
                          Rafa Marin-Lopez
                          Fernando Pereniguez-Garcia
                          Gabriel Lopez-Millan
                          Diego R. Lopez
                          Alan DeKok
	Filename        : draft-ietf-radext-radius-fragmentation-11.txt
	Pages           : 35
	Date            : 2015-01-20

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


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

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

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


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 Tue Jan 20 03:55:29 2015
Return-Path: <internet-drafts@ietf.org>
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 E72291B2A1B for <radext@ietfa.amsl.com>; Tue, 20 Jan 2015 03:55:25 -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 Wfuw442arFym; Tue, 20 Jan 2015 03:55:24 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B33BA1B2A09; Tue, 20 Jan 2015 03:55:21 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu, bclaise@cisco.com, barryleiba@computer.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p8
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150120115521.18529.73157.idtracker@ietfa.amsl.com>
Date: Tue, 20 Jan 2015 03:55:21 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/yLjx3YhyQIvy4sQNJhZmJCh3QE8>
Subject: [radext] New Version Notification - draft-ietf-radext-radius-fragmentation-11.txt
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Jan 2015 11:55:26 -0000

A new version (-11) has been submitted for draft-ietf-radext-radius-fragmentation:
http://www.ietf.org/internet-drafts/draft-ietf-radext-radius-fragmentation-11.txt


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

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-11

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 Tue Jan 20 06:47:27 2015
Return-Path: <spencerdawkins.ietf@gmail.com>
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 116AC1B2DB5; Tue, 20 Jan 2015 06:47:26 -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 hwm57bLbBuWV; Tue, 20 Jan 2015 06:47:20 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BD31B2CCE; Tue, 20 Jan 2015 06:47:20 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Spencer Dawkins" <spencerdawkins.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p8
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150120144720.5579.43507.idtracker@ietfa.amsl.com>
Date: Tue, 20 Jan 2015 06:47:20 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/Nc0c_5H-iAcNJsdajWfZzuT0bdA>
Cc: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu
Subject: [radext] Spencer Dawkins' No Objection on draft-ietf-radext-radius-fragmentation-11: (with COMMENT)
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Jan 2015 14:47:26 -0000

Spencer Dawkins has entered the following ballot position for
draft-ietf-radext-radius-fragmentation-11: No Objection

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:
----------------------------------------------------------------------

I echo Adrian's thanks for positioning this as Experimental, and
describing what the experiment is.

I echo Barry's "well-written document".

I'm delighted to read this text:

12.4.  Transport behaviour

   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.  Hence, bursts of traffic which could congest links
   between peers are not an issue.



From nobody Tue Jan 20 07:07:10 2015
Return-Path: <barryleiba@gmail.com>
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 C60DB1B2DB8; Tue, 20 Jan 2015 07:06:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-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 qi7JdjCyPVd4; Tue, 20 Jan 2015 07:06:45 -0800 (PST)
Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CF211B2A02; Tue, 20 Jan 2015 07:06:37 -0800 (PST)
Received: by mail-la0-f50.google.com with SMTP id pn19so34719653lab.9; Tue, 20 Jan 2015 07:06:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=0omlV2ve2lUJ5RGDA1wujBD6e1Y9K3no7C9Qm9kaIu4=; b=vdQdjrhHM+Q0ktmVip86DyaSZLrToFAYcFqQk+XtHDStySEaAAG7gcuxBOPwYA3xGT IebbEO3SVjcPXWPkBYu+NwnMzZGDPS2+KVtz7fHpMMLYeyIxpHPZ3bhE2EjF5whl5n5g /3jtClZ9dAey+0SQ+X21gLkCBBjHzSkFriE0p6Sgh/mem723kUYACodLhqNITSKyPLoo P1FiFsg5QMQVFadPboTsDUQSpI2sru2k4FYkg2UIcX13rbNi5ISnZpwWgZTTTg6hgFOW OeIglfci90F46qOAU31LAL+Xg8om6IIWQjF4qdB8d6ptVmGx2F/Mmlby7ppeGk559yCS 3Low==
MIME-Version: 1.0
X-Received: by 10.152.9.170 with SMTP id a10mr3011052lab.1.1421766395322; Tue, 20 Jan 2015 07:06:35 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.152.127.168 with HTTP; Tue, 20 Jan 2015 07:06:35 -0800 (PST)
In-Reply-To: <54BE0721.6060401@um.es>
References: <20150119233529.24420.90147.idtracker@ietfa.amsl.com> <54BE0721.6060401@um.es>
Date: Tue, 20 Jan 2015 10:06:35 -0500
X-Google-Sender-Auth: Q_B8QoYYZ8ytCXJxO6vTZKkxoP4
Message-ID: <CALaySJK1Wk9P50CpfzbNi1iHM5NhsYsr+BujnjG-6x1kPF-7Dg@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Alejandro Perez Mendez <alex@um.es>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/QWzik0USlrh42AEF8SAurq8LUe8>
Cc: "radext@ietf.org" <radext@ietf.org>, Stefan Winter <stefan.winter@restena.lu>, The IESG <iesg@ietf.org>, "radext-chairs@tools.ietf.org" <radext-chairs@tools.ietf.org>, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org
Subject: Re: [radext] Barry Leiba's Discuss on draft-ietf-radext-radius-fragmentation-10: (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 <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Jan 2015 15:06:47 -0000
X-List-Received-Date: Tue, 20 Jan 2015 15:06:47 -0000

Thanks for the quick response, Alejandro.  It all sounds good, and I'm
ready to clear the DISCUSS as soon as I see the revised I-D.

Barry

On Tue, Jan 20, 2015 at 2:43 AM, Alejandro Perez Mendez <alex@um.es> wrote:
> Hi Barry,
>
> thanks for your comments. See my responses inline, please.
>
> El 20/01/15 a las 00:35, Barry Leiba escribi=F3:
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> This is just to make sure that the IANA allocations are clear, because I
> have some questions about that:
>
> -- Section 14 --
>
>    In particular, this document defines two new RADIUS attributes,
>    entitled "Frag-Status" and "Proxy-State-Len" (see section 9),
>    assigned values of TBD1 and TBD2 from the Long Extended Space
>
> But these are not defined in Section 9, but in Sections 10.1 and 10.2.
>
>
> Right. It seems I forgot inserting an <xref> in this place, and therefore=
 it
> didn't get updated when we included the new section 2.
>
>
> And I see that these are the "Type" values, but where's the allocation of
> the "Extended-Type" values that are mentioned in those sections?
>
>
> Yes. Indeed, this is something the IANA already brought in. Lionel Morand
> provided suggestion of how to solve this issue, that has been agreed by u=
s
> as the best way forward. In particular, the type will be fixed to 241,
> whereas the Extended-Type would be TBDX.
>
> The table would look as follows:
>
>        Type       Name                   Length  Meaning
>        ----       ----                   ------  -------
>        241.TBD1   Frag-Status            7       Signals fragmentation
>        241.TBD2   Proxy-State-Len(*gth*) 7       Indicates the length of =
the
>                                                  received Proxy-State
> attributes
>
> And the text in section 10.1 and 10.2 would be:
>
>     Type
>       241 (To be confirmed by IANA)
>
>     Length
>       7
>
>     Extended-Type
>       TBDX
>
>
> Also, there's another "TBA" at the end of Section 14 that points to
> Section 4.1, but there is no Section 4.1.  It looks like maybe that's
> supposed to be 5.1.
>
>
> Yes. In figure elements it seems that <xref> tags are not possible, and I
> forgot to update these numbers when Section 2 was introduced. The same ha=
s
> happened with the table immediately above that one, which points to Secti=
on
> 9.1 while it should say 10.1. Both need to be updated.
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> This seems a very well written document, and was easy to read.  In
> particular, thanks very much for Section 2: it's one of the best of that
> sort of explanation I've seen, and should be a model for other such
> specs.
>
>
> Thanks.
>
>
> Very minor point: In the diagram in Section 3, I suggest fitting all the
> boxed text as in the box that includes "CoA Proxy".  That is, putting
> "CoA" on top of "Server" and "client" (why not "Client"?) in the other
> boxes makes the separation between the left-side text and the right-side
> text just a little clearer.
>
>
> We'll do it. Thanks.
>
>
> -- Sections 10.1 and 10.2 --
> It's not clear to me how the RFC Editor will know which values to replace
> into the four "TBA" items in these sections (two "Type" and two
> "Extended-Type" values).  Shouldn't they be distinguished from each
> other, to make that clear?  (And see my DISCUSS comments.)
>
>
>
> See my comments above. Now TBA is only applied to the
> "Additional-Authorization" value.
>
> Best regards,
> Alejandro
>


From nobody Tue Jan 20 12:24:34 2015
Return-Path: <barryleiba@computer.org>
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 32FA61B2B64; Tue, 20 Jan 2015 12:24: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 KGvAVnXLheNC; Tue, 20 Jan 2015 12:24:27 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9421B2B68; Tue, 20 Jan 2015 12:24:27 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Barry Leiba" <barryleiba@computer.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p8
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150120202427.16025.25740.idtracker@ietfa.amsl.com>
Date: Tue, 20 Jan 2015 12:24:27 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/pQQnnLFRRPFzOu0BSs6RSRAAEUo>
Cc: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu
Subject: [radext] Barry Leiba's No Objection on draft-ietf-radext-radius-fragmentation-11: (with COMMENT)
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Jan 2015 20:24:29 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-radext-radius-fragmentation-11: No Objection

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:
----------------------------------------------------------------------

This seems a very well written document, and was easy to read.  In
particular, thanks very much for Section 2: it's one of the best of that
sort of explanation I've seen, and should be a model for other such
specs.

Version -11 addresses all the minor comments I had; thanks.



From nobody Wed Jan 21 02:26:43 2015
Return-Path: <mls.ietf@gmail.com>
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 556461A1A02; Wed, 21 Jan 2015 02:26:38 -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 plFyiOIeI5AX; Wed, 21 Jan 2015 02:26:37 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B94D41A1A07; Wed, 21 Jan 2015 02:26:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Martin Stiemerling" <mls.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p8
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150121102634.30907.71805.idtracker@ietfa.amsl.com>
Date: Wed, 21 Jan 2015 02:26:34 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/_j86RqHjS4HAi-9mjmjl2U1yFSk>
Cc: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu
Subject: [radext] Martin Stiemerling's No Objection on draft-ietf-radext-radius-fragmentation-11: (with COMMENT)
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jan 2015 10:26:38 -0000

Martin Stiemerling has entered the following ballot position for
draft-ietf-radext-radius-fragmentation-11: No Objection

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:
----------------------------------------------------------------------

A well-written document and thank you for being an experimental
document.

Looking forward to reports from the wild how good or bad it works.



From nobody Wed Jan 21 10:22:04 2015
Return-Path: <Kathleen.Moriarty.ietf@gmail.com>
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 F17371A1B6D; Wed, 21 Jan 2015 10:21:54 -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 70DniLEJVOxD; Wed, 21 Jan 2015 10:21:51 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A98B1A1B71; Wed, 21 Jan 2015 10:21:46 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Kathleen Moriarty" <Kathleen.Moriarty.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p8
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150121182146.9534.92979.idtracker@ietfa.amsl.com>
Date: Wed, 21 Jan 2015 10:21:46 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/UsyVgiESDyXflS_jm0ps7uPxLTw>
Cc: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu
Subject: [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
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jan 2015 18:21:55 -0000

Kathleen Moriarty 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:
----------------------------------------------------------------------

In the security considerations section, I didn't see a discussion on
packet re-assembly and associated security issues such as overlapping
fragments.  If there is a reference that already covers that in the
draft, I missed it and would appreciate you pointing me to it.

In a quick search, I found a couple of references that may be useful for
some text/reference on details of this attack type,  but are at the IP
layer.  The draft already prevents other attack types that involve
ordering and size of fragments with lengths included, so this is just
meant to ask about overlapping fragments.

Section 4 of: https://tools.ietf.org/html/rfc1858
https://tools.ietf.org/html/draft-ietf-6man-overlap-fragment-03

Examples might overlap to change any part of the AAA data once
reassembled.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for your work on this draft, I also agree that it is well written
and placed well as experimental.



From nobody Wed Jan 21 11:31:47 2015
Return-Path: <kathleen.moriarty.ietf@gmail.com>
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 867261A8722; Wed, 21 Jan 2015 11:31:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFj53Ar6iR-w; Wed, 21 Jan 2015 11:31:33 -0800 (PST)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A8F11A871E; Wed, 21 Jan 2015 11:31:33 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id l4so28325938lbv.3; Wed, 21 Jan 2015 11:31:31 -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:content-transfer-encoding; bh=hbqPIIa4wybtUAsKmE3k8rO7SGDTxcUo6ZNCKac1jRw=; b=ZLlCZki8ZttzG5uw77N44TG1JmKBxGeFuavH3XafkmWVWMLH1W5+D/lBACIin0GYG+ E2sL7FY3Hc4T01gfRoG2sqFXWykK2Bud4w7lIfp6oC6RFXMgAnUO7uzuVhLSlVwmWlBK KTpMbuPX29X1SsENbpF3u6igp2699nhT44rXP6zU0wxhTXrZoENx+oupG81h4QqAHZ5u 3qhAG4NSUWI+Cdqh4MIJLQWEdHjxUcxKOuKClS1y9jHFCHVXyBgk42su8jAHoFMpNcp/ OnrS9BkwNCYuBUTTGxRKXRxGrwKVcBFRv2pCJZPYUwMqxWjgHviBEohK1MmEBy3gcGXH qcaA==
MIME-Version: 1.0
X-Received: by 10.152.238.1 with SMTP id vg1mr46642188lac.83.1421868691683; Wed, 21 Jan 2015 11:31:31 -0800 (PST)
Received: by 10.112.145.102 with HTTP; Wed, 21 Jan 2015 11:31:31 -0800 (PST)
In-Reply-To: <81E348FD-93A4-422D-80E5-7498C229FC5D@networkradius.com>
References: <20150121182146.9534.92979.idtracker@ietfa.amsl.com> <81E348FD-93A4-422D-80E5-7498C229FC5D@networkradius.com>
Date: Wed, 21 Jan 2015 14:31:31 -0500
Message-ID: <CAHbuEH6Bi7CgLuU_fEceB=YbXXj6YteowdVMG4cuxrt+-ZPgXg@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: Alan DeKok <aland@networkradius.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/nqGrFh7dZwJoUb1kYgGq4tqvytg>
Cc: radext@ietf.org, Winter Stefan <stefan.winter@restena.lu>, The IESG <iesg@ietf.org>, "radext-chairs@tools.ietf.org" <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 <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jan 2015 19:31:35 -0000

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@gm=
ail.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 desig=
ned to avoid that.
>
>   Unlike IP, there is no =E2=80=9Cfragment offset=E2=80=9D field.  There =
is simply a =E2=80=9Cfragment length=E2=80=9D field.  The fragments are req=
uested and received in lock-step order.  The data in each fragment is appen=
ded 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 interp=
retation.
>
> We could add a short paragraph after the preaching text:
>
> The reconstruction process is performed by simply appending all of the ch=
unks together.  Unlike IPv4 fragmentation, there is no =E2=80=9Cfragment of=
fset=E2=80=9D field.  The chunks in this specification are explicitly order=
ed, as RADIUS 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 s=
ecurity issues with overlapping fragments.  Each chunk simply has a length,=
 with no =E2=80=9Cfragment offset=E2=80=9D field as with IPv4.  The order o=
f the fragments is determined by the order in which they are received.  The=
re 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.  I'll switch to a yes when this text is
added.

--=20

Best regards,
Kathleen


From nobody Wed Jan 21 22:15:23 2015
Return-Path: <presnick@qti.qualcomm.com>
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 615AE1AC41D; Wed, 21 Jan 2015 22:15:19 -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 UiEzqn7QT3Yf; Wed, 21 Jan 2015 22:15:16 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6791AC411; Wed, 21 Jan 2015 22:15:16 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Pete Resnick" <presnick@qti.qualcomm.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p8
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150122061516.7611.80876.idtracker@ietfa.amsl.com>
Date: Wed, 21 Jan 2015 22:15:16 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/O7t3Hm_qF_8-mCH5SC8seiyW3c4>
Cc: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu
Subject: [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
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Jan 2015 06:15:19 -0000

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.





From nobody Thu Jan 22 03:39:12 2015
Return-Path: <bclaise@cisco.com>
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 D91EC1AC7E7; Thu, 22 Jan 2015 03:39:10 -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 2GFCXVv4E1XG; Thu, 22 Jan 2015 03:39:09 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2F91A1A15; Thu, 22 Jan 2015 03:39:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3198; q=dns/txt; s=iport; t=1421926750; x=1423136350; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=rGCXDzQeLrOyxR7cPk3gCjBs1n0WMDPoN082SO10AZM=; b=PX4lcndp9lZ/EATMok7SSfcd5tysQFbTsDuQbNGByzsTTp2eV7iX49vz 422uNwO/Aqpxwa0+5rixykJHKAp94cqDEWM/BAGvqG8K8P1f2p2nlzQee 5WGfDK8DOptREH7dD+PmgzQ2ACwc1Kbt2P8QlLvG+fwYBAJa4hBFPyrW+ c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AssEALPgwFStJssW/2dsb2JhbABag1hYvQmJMgyFJUoCgVsBAQEBAX2EDQEBBAEBATU2CgEQCw4TFg8JAwIBAgEVMAYBDAEFAgEBBYgjDdF7AQEBAQEBAQEBAQEBAQEBAQEBAQEBF48XEAIBTweEKQEEhT+McYVPgRQ2gkiCIIVUhi8igjKBPT0xAYJCAQEB
X-IronPort-AV: E=Sophos;i="5.09,448,1418083200"; d="scan'208";a="322366127"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 22 Jan 2015 11:39:07 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0MBd5xv004080; Thu, 22 Jan 2015 11:39:06 GMT
Message-ID: <54C0E159.3000500@cisco.com>
Date: Thu, 22 Jan 2015 12:39:05 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Pete Resnick <presnick@qti.qualcomm.com>, The IESG <iesg@ietf.org>
References: <20150122061516.7611.80876.idtracker@ietfa.amsl.com>
In-Reply-To: <20150122061516.7611.80876.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/nJTa8pN9tx12n5bUH9ebumVwl34>
Cc: radext@ietf.org, 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 <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Jan 2015 11:39:11 -0000

Hi Pete,

For completeness, this was discussed on the RADEXT mailing list.
See http://www.ietf.org/mail-archive/web/radext/current/msg09079.html
Let's discuss during the IESG telechat.

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 Thu Jan 22 10:21:35 2015
Return-Path: <bclaise@cisco.com>
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 B38CB1ACF19; Thu, 22 Jan 2015 10:21:33 -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 qMU_H36ni_-V; Thu, 22 Jan 2015 10:21:32 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC82C1ACEF6; Thu, 22 Jan 2015 10:21:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4241; q=dns/txt; s=iport; t=1421950876; x=1423160476; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=R0qQsIN410hV7vW3TXPo6E8TmFALnhrMCNvqZd4oZrY=; b=nEMnRdc+Ri77OJUzf0BFeFvScpR6KqDgPPTmklZcFyRqNQIf1krvu6l8 +CldEbJ/zAFwoEH2dY4ekUsa/L3yTTM/7HGJii1ewpKdxfZ+1ATH45WbV nquV4Rc4VxoimomC2tYMPWjturhewiIcMyVGamD9qNtZKIqBgw5MezMwV o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AssEANI+wVStJssW/2dsb2JhbABag1hYvQuJMgyFJUoCgVkBAQEBAX2EDQEBAwEBAQE1NgoBBQsLDhMWDwkDAgECARUwBgEMAQUCAQEFEogJCA3TQwEBAQEBAQEBAQEBAQEBAQEBAQEBARePFxEBUAeEKQEEhT+McYVPgRQ2gkiCIIVUhi8igjKBPT0xAYELgTcBAQE
X-IronPort-AV: E=Sophos;i="5.09,450,1418083200"; d="scan'208";a="322083757"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 22 Jan 2015 18:21:13 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0MILB5d006935; Thu, 22 Jan 2015 18:21:12 GMT
Message-ID: <54C13F97.1090201@cisco.com>
Date: Thu, 22 Jan 2015 19:21:11 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Pete Resnick <presnick@qti.qualcomm.com>, The IESG <iesg@ietf.org>
References: <20150122061516.7611.80876.idtracker@ietfa.amsl.com>
In-Reply-To: <20150122061516.7611.80876.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/LTI6CTGswNOVjJclvhI6D0c4AJU>
Cc: radext@ietf.org, 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 <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Jan 2015 18:21:33 -0000

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 Thu Jan 22 10:24:49 2015
Return-Path: <ietf-secretariat-reply@ietf.org>
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 5E9701AD0A5 for <radext@ietfa.amsl.com>; Thu, 22 Jan 2015 10:24:48 -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 tRu92UMd72UQ; Thu, 22 Jan 2015 10:24:47 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B77F91ACEF6; Thu, 22 Jan 2015 10:24:46 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p8
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150122182446.14999.10443.idtracker@ietfa.amsl.com>
Date: Thu, 22 Jan 2015 10:24:46 -0800
From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/CM667X5QVC831Kgk5mzGg0Xtvb4>
Subject: [radext] ID Tracker State Update Notice: <draft-ietf-radext-radius-fragmentation-11.txt>
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Jan 2015 18:24:48 -0000

IESG state changed to IESG Evaluation::Revised I-D Needed from Waiting for Writeup
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/


From nobody Thu Jan 22 16:38:55 2015
Return-Path: <aland@networkradius.com>
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 4426A1A86F6; Wed, 21 Jan 2015 11:19:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrHCvzcPzhcJ; Wed, 21 Jan 2015 11:19:40 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id C4A371A8549; Wed, 21 Jan 2015 11:19:29 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 87AFE2240350; Wed, 21 Jan 2015 20:18:58 +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 L_gwmWnxX61R; Wed, 21 Jan 2015 20:18:58 +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 A702122401D3; Wed, 21 Jan 2015 20:18:56 +0100 (CET)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Alan DeKok <aland@networkradius.com>
In-Reply-To: <20150121182146.9534.92979.idtracker@ietfa.amsl.com>
Date: Wed, 21 Jan 2015 14:18:54 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <81E348FD-93A4-422D-80E5-7498C229FC5D@networkradius.com>
References: <20150121182146.9534.92979.idtracker@ietfa.amsl.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/BaPU55KsEPAkITQvpmHXccg-Pwk>
X-Mailman-Approved-At: Thu, 22 Jan 2015 16:38:54 -0800
Cc: radext@ietf.org, Winter Stefan <stefan.winter@restena.lu>, The IESG <iesg@ietf.org>, 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 <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jan 2015 19:19:42 -0000

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 =93fragment offset=94 field.  There is simply a =
=93fragment length=94 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.=20

 The overview in Section 4 describes the process.  But it doesn=92t =
explicitly say that the fragments are simply appended.  It just says:

   =85 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 =93reconstruction=94 process open to interpretation.

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 =93fragment =
offset=94 field.  The chunks in this specification are explicitly =
ordered, as RADIUS 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 =93fragment offset=94 field as with IPv4.  The order of =
the fragments is determined by the order in which they are received.  =
There is no ambiguity about the size or placement of each chunk, and =
therefore no security issues associated with overlapping chunks.=


From nobody Fri Jan 23 05:12:28 2015
Return-Path: <jari.arkko@piuha.net>
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 AFC171A90B6; Fri, 23 Jan 2015 05:12:25 -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 aMmIJIWthPfI; Fri, 23 Jan 2015 05:12:24 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9581A90AE; Fri, 23 Jan 2015 05:12:24 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Jari Arkko" <jari.arkko@piuha.net>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p8
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150123131224.2371.18913.idtracker@ietfa.amsl.com>
Date: Fri, 23 Jan 2015 05:12:24 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/WoqGTL40t-Eiu2d4U7RyXPE540Y>
Cc: radext@ietf.org, draft-ietf-radext-nai.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu
Subject: [radext] Jari Arkko's No Objection on draft-ietf-radext-nai-15: (with COMMENT)
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Jan 2015 13:12:25 -0000

Jari Arkko has entered the following ballot position for
draft-ietf-radext-nai-15: No Objection

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-nai/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

As far as I can see, and based on my attempt to find people who would
still have an issue, we have cleared the issues that I worried about
earlier. Thanks for the updates and working on this topic!



From nobody Fri Jan 23 05:35:47 2015
Return-Path: <bclaise@cisco.com>
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 327FF1A90B8; Fri, 23 Jan 2015 05:35:37 -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 JitwcT4HNZhe; Fri, 23 Jan 2015 05:35:32 -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 3422B1A90BA; Fri, 23 Jan 2015 05:35:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=746; q=dns/txt; s=iport; t=1422020132; x=1423229732; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=mbVEO/Tv5IXakmqwf8kBKkJDdcIdpj6OGxogv3txDM8=; b=VA+qgdECv4KnH2/poov/wfNINA7gRik7yQonhs9VM2nxYQk1zBSAsAcn AkLwkzkV5ABPCo7TmQ5KVWID+Xt/bYmOpa3HJFMRuFdWlnzUSW7QHponz PPHd8avI87RBomPeTirmIKCrOJ1BqxboXyoRYkaNMjahFGilEENOMZ70N U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AsgEAI9NwlStJssW/2dsb2JhbABag1hZgn/DVIVjCoFZAQEBAQF9hDYVQTUCBSECEQJMDQEHAQEFiCMNvWOUYwEBAQEBAQEDAQEBAQEBHIEhjleCb4FBBZd/gRSCfoIgjAMig289gTYkgRoBAQE
X-IronPort-AV: E=Sophos;i="5.09,453,1418083200"; d="scan'208";a="319051177"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 23 Jan 2015 13:35:30 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0NDZUhQ020492; Fri, 23 Jan 2015 13:35:30 GMT
Message-ID: <54C24E21.50706@cisco.com>
Date: Fri, 23 Jan 2015 14:35:29 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "radext@ietf.org" <radext@ietf.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/FbbU9OftCvDZJhq9E5OyaAGdGQo>
Cc: IESG IESG <iesg@ietf.org>
Subject: [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 <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Jan 2015 13:35:37 -0000

Dear all,

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

If no feedback within the next two weeks, this version will be approved

Thanks Alan for taking care of all of IESG issues.

Regards, Benoit



From nobody Fri Jan 23 05:41:52 2015
Return-Path: <aland@deployingradius.com>
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 9E5AD1A90BA for <radext@ietfa.amsl.com>; Fri, 23 Jan 2015 05:41:49 -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 YnsaXmSN7rW7 for <radext@ietfa.amsl.com>; Fri, 23 Jan 2015 05:41:47 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id A32271A90C0 for <radext@ietf.org>; Fri, 23 Jan 2015 05:41:47 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id E7CE822405D4; Fri, 23 Jan 2015 14:41:46 +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 2tzXaORvXWWn; Fri, 23 Jan 2015 14:41:46 +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 C88752240274; Fri, 23 Jan 2015 14:41:45 +0100 (CET)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <54C24E21.50706@cisco.com>
Date: Fri, 23 Jan 2015 08:41:44 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <AEF8F60F-7758-4F93-804A-5CB5E1DCEFF8@deployingradius.com>
References: <54C24E21.50706@cisco.com>
To: Benoit Claise <bclaise@cisco.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/lF8FOAMtEiT-raNDO8BmGktkIeU>
Cc: "radext@ietf.org" <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 <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Jan 2015 13:41:49 -0000

On Jan 23, 2015, at 8:35 AM, Benoit Claise <bclaise@cisco.com> 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=3Ddraft-ietf-radext-nai-10&difftype=3D--h=
tml&submit=3DGo!&url2=3Ddraft-ietf-radext-nai-15

  The changes were largely clarifications.  Additional text was added to =
explain the NAI and it=92s 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 =93we=94 was changed to a more =
neutral term.  The ABNF for the NAI was simplified.

  Alan DeKok.


From nobody Tue Jan 27 02:19:15 2015
Return-Path: <internet-drafts@ietf.org>
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 055181A877A; Tue, 27 Jan 2015 02:19:02 -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 Zr8s9HnY2F0A; Tue, 27 Jan 2015 02:18:58 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAA11A8767; Tue, 27 Jan 2015 02:18:58 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.1.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150127101858.8419.73126.idtracker@ietfa.amsl.com>
Date: Tue, 27 Jan 2015 02:18:58 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/CLalIfq9vAz7B0bJn9Z0IzUzMxc>
Cc: radext@ietf.org
Subject: [radext] I-D Action: 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 <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Jan 2015 10:19:03 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

        Title           : Support of fragmentation of RADIUS packets
        Authors         : Alejandro Perez-Mendez
                          Rafa Marin-Lopez
                          Fernando Pereniguez-Garcia
                          Gabriel Lopez-Millan
                          Diego R. Lopez
                          Alan DeKok
	Filename        : draft-ietf-radext-radius-fragmentation-12.txt
	Pages           : 36
	Date            : 2015-01-27

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


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

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

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Jan 27 02:19:16 2015
Return-Path: <internet-drafts@ietf.org>
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 053831A877A for <radext@ietfa.amsl.com>; Tue, 27 Jan 2015 02:19:08 -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 K1qzXmi1CR9s; Tue, 27 Jan 2015 02:19:06 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCD51A876D; Tue, 27 Jan 2015 02:18:59 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu, bclaise@cisco.com, presnick@qti.qualcomm.com, Kathleen.Moriarty.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.1.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150127101859.8419.27059.idtracker@ietfa.amsl.com>
Date: Tue, 27 Jan 2015 02:18:59 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/ZTmh2ldA2UmkvJc2jo8tSYdCoOo>
Subject: [radext] New Version Notification - 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 <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Jan 2015 10:19:08 -0000

A new version (-12) has been submitted for draft-ietf-radext-radius-fragmentation:
http://www.ietf.org/internet-drafts/draft-ietf-radext-radius-fragmentation-12.txt

Sub state has been changed to AD Followup from Revised ID Needed


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

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-12

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.


From nobody Tue Jan 27 02:20:09 2015
Return-Path: <alex@um.es>
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 E65A61A8776; Tue, 27 Jan 2015 02:20:03 -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 qub8fCUjw7wc; Tue, 27 Jan 2015 02:20:00 -0800 (PST)
Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 807771A8761; Tue, 27 Jan 2015 02:20:00 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id E3583C451; Tue, 27 Jan 2015 11:19:58 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon23.um.es
Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dgxPRR2BQypQ; Tue, 27 Jan 2015 11:19:58 +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 xenon23.um.es (Postfix) with ESMTPSA id 0A9B4C417; Tue, 27 Jan 2015 11:19:50 +0100 (CET)
Message-ID: <54C76646.6030108@um.es>
Date: Tue, 27 Jan 2015 11:19:50 +0100
From: Alejandro Perez Mendez <alex@um.es>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Benoit Claise <bclaise@cisco.com>,  Pete Resnick <presnick@qti.qualcomm.com>, The IESG <iesg@ietf.org>
References: <20150122061516.7611.80876.idtracker@ietfa.amsl.com> <54C13F97.1090201@cisco.com>
In-Reply-To: <54C13F97.1090201@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/nSJmJLsniJ_maElYvcGDIs_QthU>
Cc: radext@ietf.org, 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 <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Jan 2015 10:20:04 -0000

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
>> .
>>
>