[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66
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: email@example.com
> [mailto:firstname.lastname@example.org] On Behalf Of Alan DeKok
> Sent: Wednesday, July 12, 2006 2:26 PM
> To: Emile van Bergen
> Cc: Bernard Aboba; email@example.com
> Subject: Re: Consensus Call: "Sense of the Room" at RADEXT WG
> meeting at IETF 66
> Emile van Bergen <firstname.lastname@example.org> 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
> email@example.com 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 firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.