RE: Capabilities: Summary

["Nelson, David" <dnelson@enterasys.com>]

Avi Lior writes...

> Therefore, the conclusion that Farid and I came (and others) came to
was
> not to express capabilities as support for individual attributes but
> rather as "features" and "modes" (I don't know how to express it).

Then perhaps what is really needed is a single new attribute called
Supported-Application-Environment which is an enumerated type, with an
appropriate IANA registry.  If SDOs, consortia, vendors and system
operators can agree on a finite set of business scenarios or application
environments (i.e. bundles of attributes, commands, and related values
and feature support) they can name them.  For example
"3GPP2-Roaming-Feature-Set-One".  Multiple instances of this attribute
would be allowed in Access-request messages.

The argument against this, of course, is that every consortia, vendor
and system operator will want to create custom bundles of RADIUS
behavior for their one "unique" environments and needs.  I would like to
suggest that the set of truly unique business scenarios is finite and
fairly limited in number.  Following the KISS philosophy, and resisting
the urge to tweak and customize, I assert that this could be a viable
solution.

OTHO, I do agree with Bernard that we first need to come to consensus on
the problem statement.  I think your summary, quoted above, is one
reasonable candidate.


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