RE: RADIUS Design Guidelines [SEQUENCE]

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

 Had to start a new thread.

Sequence as you propose does not work.

It only works when all members of a sequence are required expcept the
last one which can be optional -- or
That if an element in the sequence is not required its value is still
sent (as a zero)

As well the sequence does not work for variable length fields.

A sequence of TLVs will work.  Since the Type field allows us to
identify the attribute resolving the first problem.

And Length allows us to handle variable length attributes.

If we are going to do this lets do it right!

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David
> Sent: Monday, August 28, 2006 11:54 AM
> To: radiusext@ops.ietf.org
> Subject: RADIUS Design Guidelines
> 
> I've been giving some thought to the current RADIUS Design 
> Guidelines draft, and the group consensus regarding that 
> document and the Extended Attribute, coming out of IETF-66.
> 
> The currently evolving proposals for Extended Attributes, 
> solve some of the issues that have been identified in the 
> Design Guidelines draft:
> shortage of attribute IDs, grouping of attributes, and an 
> explicit method of fragmentation and reassembly.
> 
> The one remaining issue raised in the RADIUS Design 
> Guidelines draft not addressed is the issue of multi-part 
> data values.  Most of the RADIUS work to date has simply 
> addressed this by defining an attribute, of base-type String, 
> and then defining sub-fields within the string.
> 
> There is nothing inherently wrong with this approach, except 
> perhaps that it makes it more difficult to maintain data 
> dictionary driven implementations.
> 
> I have a suggestion to float, in term of the BCP for attribute design.
> I'd like to suggest that any value portion of a RADIUS TLV 
> that has multiple parts be formally defined in the document 
> as a SEQUENCE of pre-defined RADIUS base-types.  I'm stealing 
> the SMI syntax for SEQUENCE, as used in creating conceptual 
> tables for MIB modules.  It would be relatively easy for data 
> dictionary driven implementations to automatically understand 
> a sequence of pre-defined base types.
> 
> Let me provide a contrived example.  Suppose we want to 
> define a new attribute whose value is a complex number.  For 
> those who may have forgotten, a complex number consists of a 
> real part and an imaginary part.  This is most often 
> represented as: n + m*i, where n and m are real numbers and i 
> is the square root of -1.  Such a hypothetical attribute 
> light look like:
> 
> <example>
> 
> Complex-Number
> 
>    Description
> 
>    A complex number, consisting to two parts, a real part N and an 
>    imaginary part M, such that the value is N + M*i, where i is the
>    square root of -1.
> 
>    A summary of the Complex Number Attribute format is shown below.
>    The fields are transmitted from left to right.
>     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     |            Real-Part (N)
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>           Real-Part (cont)         |          Imaginary-Part (M)
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       Imaginary-Part (cont)
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Type
> 
>       TBA for Complex-Number.
> 
>    Length
> 
>       10
> 
>    Value
> 
>       SEQUENCE OF Real-Part, Imaginary-Part
> 
>    Real-Part
> 
>       RADIUS base-type of Integer.  The real part of the 
> complex number.
> 
>    Imaginary-Part
> 
>       RADIUS base-type of Integer.  The imaginary part of the complex
>       number.
> 
> </example>
> 
> I think there is some value here in the ability for data 
> dictionary driven implementations to easily accommodate 
> multi-part value fields that are simple concatenations, or 
> sequences, of pre-defined base data types.
> 
> A counter example would be an attribute with varying length 
> fields, some maybe only one or two octets in length.  These 
> types of constructs require custom parsing code.
> 
> The one additional caveat, that comes to mind, is that 
> variable length fields would need to (a) only occur at the 
> end of all fixed length fields, (b) have an explicit length 
> field, or (c) have an explicit delimiter field.
> 
> Comments on this line of thought?
> 
> 
> 
> --
> 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/>