[radext] Document Action: 'Support of fragmentation of RADIUS packets' to Experimental RFC (draft-ietf-radext-radius-fragmentation-12.txt)

The IESG <iesg-secretary@ietf.org> Tue, 10 February 2015 00:09 UTC

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150210000937.24598.33946.idtracker@ietfa.amsl.com>
Date: Mon, 09 Feb 2015 16:09:37 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/4xRraEoIm4Q1UbfLIYvr3wccqYw>
Cc: radext mailing list <radext@ietf.org>, radext chair <radext-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [radext] Document Action: 'Support of fragmentation of RADIUS packets' to Experimental RFC (draft-ietf-radext-radius-fragmentation-12.txt)

The IESG has approved the following document:
- 'Support of fragmentation of RADIUS packets'
  (draft-ietf-radext-radius-fragmentation-12.txt) as Experimental RFC

This document is the product of the RADIUS EXTensions Working Group.

The IESG contact persons are Benoit Claise and Joel Jaeggli.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/





Technical Summary

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

Working Group Summary

   The content of this document was discussed at length in the working
   group, and there are multiple other approaches to the same problem.
   The document thus got significant exposure at the experts of the
   working group. The document has a few rough edges which were the cause
   of discussions. Considering the target status of Experimental, they
   appear minor enough to carry on with the experiment. The authors have
   documented the friction points in their section 11 "Operational
   Considerations". 11.1 in particular shows a process question: is it
   appropriate for an Experimental RFC to update a Standards-track RFC?
   The document attempts to follow that course; if this is ultimately
   agreed after IESG review, the text in that section will be changed
   accordingly.

Document Quality

   At least one implementation is known which implements this
   specification: FreeRADIUS. The sheperd has no information about plans of
   other vendors. There were no particular expert reviews outside the
   working group process; i.e. no MIB doctor review nor Media Type review
   (and no need for those two as the document contains neither MIBs nor 
   requests a Media Type). Since the document adds new transport
   capabilities, a thorough review by transport experts (e.g. TSVDIR) during
   IETF Last Call would be appreciated.

Personnel

   The Document Shepherd is Stefan Winter <stefan.winter@restena.lu>. The 
   responsible Area Directors are Benoit Claise <âbclaise@cisco.com>.

[radext] Document Action: 'Support of fragmentati… The IESG