Re: Dealing with compound attributes (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute")

["Alan DeKok" <aland@ox.org>]

"Nelson, David" <dnelson@enterasys.com> 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
> elements.

  Agreed.

> 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
> boundaries?

  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
approach.

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

  Alan DeKok.

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