[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RADIUS Design Guidelines [SEQUENCE]
Dave,
See inline....
> -----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.
At least I am consistant. But I am not consitant for the sake of being
consistant.
As well I am not saying this because I am being argumentative or rigid
etc...
I keep asserting the same requirements because that is what is needed.
> > 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.
So you are going to augment the parsing rules for dictionaries and you
don't want to solve the problem completely?
Anyway what you are promposed is what I called fixed field encoding in
the past. It has its merits but that still does not solve my issues --
which are real issues. I need the 'L' and I need the 'T' or something
equivalent to that.
>
> --
> 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/>