RE: Capabilities: Summary

["Avi Lior" <avi@bridgewatersystems.com>]

Alan,

I don't think that Capabilities are always about support for a given
attribute or attribute(s).

Sometimes capabilities are about support for a feature like Disconnect
Message or the ability to support change of authorization message.  Note
someone will surely remind me that a NAS that does not support DM or COA
will respond negatively.

But that "Negative" response comes after the fact --- after trying the
command and way after authorizing the session.  

In some cases we would like to know if the NAS supports these
capabilities *during* authentication/authorization time.  3GPP2 for
example have an VSA that communicates the NASes capability in an
Access-Request.

In other cases, it is not the support of the specific attribute but
rather what type of values the attribute can take on.  So its how the
attribute is to be interpreted or assigned values.

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

 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok
> Sent: Thursday, October 13, 2005 9:19 PM
> To: Nelson, David
> Cc: radiusext@ops.ietf.org
> Subject: Re: Capabilities: Summary
> 
> "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/>
> 

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