RE: RADIUS Design Guidelines [SEQUENCE]

["Nelson, David" <dnelson@enterasys.com>]

Avi Lior writes...

>Had to start a new thread.

Thanks for getting back to the subject that I'd originally wanted to
discuss.

> Sequence as you propose does not work.
> 
> It only works when all members of a sequence are required 
> except the last one which can be optional -- 

Well, I think that packet formats that have [dynamically] optional data
parts are more complicated, and definitely outside the RADIUS design
paradigm of the TLV.  One type, one length, one value.

> .. or that if an element in the sequence is not required
> its value is still sent (as a zero)

Assuming we were to accept that certain fields in a complex data type
are optional, that would probably be the way to go.
 
> As well the sequence does not work for variable length fields.

I'd indicated the caveats around that in my initial post.

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

What comes around, goes around.  Three years later, it looks as if you
are one again suggesting "sub-types", i.e. sequences of TLVs,
potentially nested in other TLVs.

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

Well, I'm sure that there are multiple definitions of "right".

The WG consensus on this issue, to date, is that we do not want to
redefine the RADIUS data model, even though we acknowledge that it is
very informal and rather limited.  Rather than change the current
practices in on-the-wire encodings in any substantial way, I was looking
for a method of designing attributes and documenting current practices
in a way that leads itself to a more formal and regular (read modular)
construction.  I believe this will enhance the ability for data
dictionary driven implementations to embrace the extended attributes.

The current RADIUS data model is TLV, for single-valued, atomic data
elements.  We are currently discussing how to embrace structured forms
of data elements (V). Over the years, the practice has developed of
declaring the V as a String type (or worse yet, failing to declare its
type at all), and defining the sub-elements of the string as "packed
fields" using the textual descriptions.

This makes it hard(er) to implement using a data dictionary.  I say this
because there is no standard set of data types that can be referenced.
If the String data type is seen to be composed of a SEQUENCE OF other
(base) data types, it is much easier.

You make the point that string fields need a length.  Absolutely.  I
think it is not an unreasonable assumption to make that the RADIUS
String and Text data types *do* include a length, the L in the TLV.
Sicne RADIUS only describes single-valued TLVs, there was no reason to
associate the L with the string V.  One L was always sufficient.  It is
logical, I think, to assume that if a TLV contains a SEQUENCE of string
Vs, that the string Vs will each have associated Ls.

OTOH, as you suggest, it is not a large step to further extend this to
allowing nested TLVs.  I don't think that nested TLVs are needed simply
to express multi-part data values.  That would only be necessary for
variable-content structures.  I think that it is only necessary for us
to be able to work with fixed-content structures.  That will certainly
solve the 85% problem.


--
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/>