Re: Capabilities: Summary

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

"Nelson, David" <dnelson@enterasys.com> wrote:
> This could be addressed by encapsulating the existing attributes in the
> extended attribute format.

  Ugh.

> >  Or, *requested* information like location?
> 
> I wonder how many attributes will end up falling into this category?

  Not many.  See "hints" currently sent from NAS to server.

> I am operating under the impression that the Access-Challenge mechanism
> was deemed to be a sufficient solution for the desired attributes use
> cases.  Is that not so?

  Servers may offer limited services to clients that don't support
Access-Challenge.  Requiring Access-Challenge means offering *no*
service to some clients, because they will treat it like Access-Reject.

> Well, yes, customers worry about functionality.  OTOH, if we were to
> communicate functionality, it would require a new IANA registry and
> corresponding RFCs for each code point to define *exactly* what the
> functionality was.  The nice thing about attributes is that that (we
> expect) that the associated functionality is already well defined.

  Yes.  Which is why I proposed the "list of attributes" capability,
which supports both client-server, and server-client exchanges, and
the "mandatory versus requested" capability.

> > The mandatory bit in Diameter is nice, but I don't see it as being
> > incredibly useful in deployments.
> 
> Given that Diameter interoperability is a charter requirement, what does
> this say about the requirements for such a feature in RADIUS?

  If we're extending RADIUS to have features diameter doesn't, then
that would be a problem.

  I'm not sure how Avi's deployment scenarios would work in Diameter.

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