[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Dealing with compound attributes (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute")
"Nelson, David" <firstname.lastname@example.org> wrote:
> It would seem to me that if the RADIUS protocol engine
> doesn't "care" about the member elements, it does not need to know their
> boundaries. Hence we are back to the opaque blob. If it *does* need to
> know the boundaries, then I claim that it "cares" about the data
> Now, I suppose we could attempt to define "levels of caring". For
> example, in the RADIUS/GEOPRIV draft, there are attributes that contain
> a number of data elements, that when reassembled form a GEOPRIV data
> structure. Is it necessary for the RADIUS protocol engine to know their
If not, then the boundaries may not need to be described in the
RADIUS document. A simple normitive reference to the geopriv document
containing the structure definition would be fine. (It would be nice
for the geopriv authors to respond to comments about their document).
> I personally object to the notion of RADIUS as a packager and shipper
> for arbitrary applications, i.e. RADIUS as transport mechanism. I
> realize that it has been, and continues to be, used in this fashion,
> usually for applications at least vaguely related to AAA.
As more protocols need AAA features, the boundaries between
protocols start to blur. This is unfortunate, but it's happening.
> I think the argument that RADIUS cares "enough" about the individual
> data elements to warrant defining them in explicit sub-fields of a
> RADIUS attribute, but not so much as to require any regularization of
> their on-the-wire encoding, is problematic.
Agreed. The practice should be discouraged. Normitive references
to other standards that describe the sub-fields would be the preferred
> The only scenario that I see that justifies this middle-ground
> "level of caring" is the RADIUS as transport case, i.e. the UPS
> Store model.
And I think those situations are few and far between.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.