RE: RADIUS Design Guidelines [SEQUENCE]

["Murtaza S. Chiba" <mchiba@cisco.com>]

One way to group attributes, instead of embedding them, is to use
explicit attributes that mark the beginning and end of the group.
Ofcourse, it requires that the intermediate servers dont modify the
sequence of attributes, but I have yet to come across a server that
actually does that apart from removing attributes.

On Tue, 2006-08-29 at 12:28 -0400, Avi Lior wrote:
> 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/>

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