RE: RADIUS Design Guidelines [SEQUENCE]

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

One more requirement:

SEQUENCE or (fixed encoding as I call it) does not support the notion
where an element may repeat.

 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David
> Sent: Tuesday, August 29, 2006 11:51 AM
> To: radiusext@ops.ietf.org
> Subject: RE: RADIUS Design Guidelines [SEQUENCE]
> 
> 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/>
> 

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