[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Rationalizing the RADIUS data model
Bernard,
This very much seems like a proposal for a charter item. Assuming that
there is consensus on this, should we propose to take this work on?
John
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org]On Behalf Of ext Bernard Aboba
> Sent: 28 May, 2004 19:03
> To: Avi Lior
> Cc: radiusext@ops.ietf.org
> Subject: Rationalizing the RADIUS data model
>
>
> > So I don't know what the benefit of having a new class of
> attribute. What
> > are we really fixing here?
>
> Presumably what we would be fixing is:
>
> a. Providing a migration path from current SDO VSAs to the
> IETF standards
> space.
>
> b. Rationalizing the RADIUS VSA data model with the IETF standard
> attribute data model.
>
> Today because the data models are different and the IETF
> standards space
> is only 8 bits, we have difficulties in migrating arbitrary
> SDO VSAs to
> the IETF standards space.
>
> To get there, I'd suggest we need to do the following:
>
> 1. Take inventory of the data types used in current RADIUS
> RFCs. We've
> discussed this on previous emails, but we still need to
> summarize this
> and draw conclusions from it so we can understand what the current
> RADIUS data model is.
>
> 2. Take inventory of the data types that folks feel they
> need/want going
> forward. Certainly sub-attributes are one element of
> this, but there
> is probably more as well (such as an IPv6 address type).
>
> 3. Put together a draft summarizing what we have now, and analyzing
> where we need to go, including the Diameter/RADIUS translation
> issues.
>
> In terms of attribute definition, we have two proposals on the table:
>
> a. Using a Vendor-Id of zero (0) within the existing VSA
> attribute 26,
> in order to define an extended IETF standard attribute space that
> would mirror the VSA data model, including support for
> sub-attributes.
>
> b. Creating a new attribute that would mirror the VSA data model,
> including support for subattributes.
>
> As I understand it, the primary argument for b) over a) relates to
> potential backward compatibility issues with a). To determine whether
> this is an issue or not we will need to survey existing
> implementations.
>
> Proposal for an IETF extended attribute space:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type | Length | Vendor-Id
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Vendor-Id (cont) |M|R| Vendor type
> |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Vendor length | Attribute-Specific...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>
> Type
>
> 26 for Vendor-Specific
>
> Length
>
> >= 7
>
> Vendor-Id
>
> The high-order octet is 0 and the low-order 3 octets are the SMI
> Network Management Private Enterprise Code of the Vendor in
> network byte order. A value of zero (0) denotes the IETF
> extended attribute space.
>
> M
> 1 = Mandatory
> 0 = Non-mandatory
>
> R
> Reserved for future use, and set to zero (0).
>
> Vendor type
>
> The vendor type field is 14 bits.
>
> Vendor length
>
> The Vendor Length field is one octet, and indicates the
> length of
> this Attribute in octets, including the M, R, Vendor
> type, Vendor
> length and Attribute-Specific fields.
>
> Attribute-specific
>
> The Attribute-Specific field is dependent on the definition of
> the Attribute.
>
> Multiple subattributes MAY be encoded within a
> single IETF extended attribute, although they do not have to be.
>
> --
> 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/>