Re: [radext] I-D Action: draft-ietf-radext-radius-fragmentation-06.txt

Dear all,

we have updated our fragmentation draft with the aim of capturing what 
has been agreed on the mailing list. In particular:

  * The Updates 6929 clause remains by now.
  * A new section called Operational considerations has bee included,
    with subsections for:
      o Flag T: summary of the "Updates 6929" discussion
      o Violation of RFC2865: discussion about the formal violation of
        RFC 2865 regarding the mandatory presence of authentication
        attributes on Access-Request packets, and why there are no known
        operation issues with it.
      o Proxying based on User-Name: indication that, in this
        specification, proxies are supposed to base their routing
        decision on the value of the User-Name attribute.

We have also included a new Acknowledgements section.

Regards,
Alejandro

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the RADIUS EXTensions Working Group of the IETF.
>
>          Title           : Support of fragmentation of RADIUS packets
>          Authors         : Alejandro Perez-Mendez
>                            Rafa Marin-Lopez
>                            Fernando Pereniguez-Garcia
>                            Gabriel Lopez-Millan
>                            Diego R. Lopez
>                            Alan DeKok
> 	Filename        : draft-ietf-radext-radius-fragmentation-06.txt
> 	Pages           : 30
> 	Date            : 2014-04-07
>
> Abstract:
>     The Remote Authentication Dial-In User Service (RADIUS) protocol is
>     limited to a total packet size of 4096 octets.  Provisions exist for
>     fragmenting large amounts of authentication data across multiple
>     packets, via Access-Challenge.  No similar provisions exist for
>     fragmenting large amounts of authorization data.  This document
>     specifies how existing RADIUS mechanisms can be leveraged to provide
>     that functionality.  These mechanisms are largely compatible with
>     existing implementations, and are designed to be invisible to
>     proxies, and "fail-safe" to legacy clients and servers.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-06
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-06
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext