RE: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66

["Avi Lior" <avi@bridgewatersystems.com>]

Alan,

I am not trying to defend my draft.

But I do not think that RADEXT should be making a choice because
OpenDiameter has implmeneted a particular work.

This is NOT how we should be making decisions.
 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok
> Sent: Wednesday, July 12, 2006 2:26 PM
> To: Emile van Bergen
> Cc: Bernard Aboba; radiusext@ops.ietf.org
> Subject: Re: Consensus Call: "Sense of the Room" at RADEXT WG 
> meeting at IETF 66
> 
> Emile van Bergen <openradius-radextwg@e-advies.nl> wrote:
> > Agreed, however, the inner length field in the Lior proposal seems 
> > redundant, and instead of using attribute 26, vendor 0, I think its 
> > better to allocate a separate attribute
> 
>   I agree.  After seeing this discussion go around in circles 
> for a long time, I think enough is enough.
> 
>   Therefore, I'm happy to announce that FreeRADIUS now has an 
> implementation of the Extended-Attribute from 
> draft-wolff-radext-ext-attribute-00.txt.  For code, see the 
> CVS instructions on www.freeradius.org/development.html
> 
>   We'll reference the "Diameter-Encoded RADIUS Attributes" as 
> DERA's, to distinguish them from RADIUS or proper Diameter AVP's.
> 
>   * Extended-Attribute is attribute 192, because it's in the
>     "Experimental" space from RFC 2865.  Changing this to an IANA
>     allocated number will mean editing 2 lines of text.
>   * The implementation can handle both the Extended-Attribute and
>     Ascend's pseudo-VSA at attribute 192, simultaneously in 
> one packet.
>   * Data types supported include integer, date, IP address, IFID, IPv6
>     address, IPv6 prefix, text and string (limited to 240 bytes or so)
>   * Diameter-style VSA's via the "V" bit are fully supported, and are
>     in a separate attribute space from RADIUS VSA's
>   * no tag, encryption, or grouping is currently supported
>   * no Diameter AVP flags other than "V" are supported
>    (i.e. they're forbidden)
>   * Each DERA must be in it's own Extended-Attribute
>     (i.e. no concatenation, as of yet)
>   * DERA attributes of less than 256 are forbidden, as they should be
>     encoded as RADIUS attributes
>   * DERA attributes of 256..32767 are forbidden, as they have meaning
>     within Diameter, and RADIUS servers cannot properly deal with them
>   * DERA's are arbitrarily assigned the attribute space 32768..65535.
>   * Outside of the RADIUS marshalling/unmarshalling code, nothing else
>     in the server is aware that the attributes are encoded in any
>     special way.
>   * The new attributes are indistinguishable (other than by name) 
>     from existing RADIUS attributes to existing deployments
>   * the RADIUS client included with FreeRADIUS has full support for
>     DERA's in all RADIUS packets, with no code changes to the client.
>   * less than 400 lines of code, limited to a packet handling library
>   * can be easily extended to support multiple Diameter-style AVP's
>     in one or more Extended-Attribute.
>   * with a little more work, can be extended to support text/string
>     DERA's with more than 240 bytes of data.
> 
>   The initial implementation exists.  Let's see if we can 
> have multiple inter-operable implementations.
> 
>   "Rough consensus and running code" has not been making progress.
> Let's try "running code and rough consensus".
> 
>   Alan DeKok.
> 
> --
> to unsubscribe send a message to 
> radiusext-request@ops.ietf.org with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>