End-to-End Capability

[Avi Lior <avi@bridgewatersystems.com>]

Hi all,

Farid and I have submitted a draft for capability exchange. A copy can be
found here:
http://mng.ctgisp.com/IETF/RADIUSEXT/draft-lior-radext-end-to-end-caps-00.tx
t.

Background:
This work was originally presented in
draft-adrangi-radius-attributes-extension-01.txt
We have modified it based on email discussions and private conversation.

In essence, it uses bit-pair for capabilities (not attributes).

In the discussion section we also discuss Glen Zorn's question, on whether
or not it makes sense to have the capability exchange also come from the the
Server. Using Glen's own draft we show an example that shows that indeed
that does make sense.  This part is not in the draft yes -- we will wait for
consensus.

Here is a snippet of that from the draft.....

9.1  Bi-directional capability exchange

   Glen Zorn asked the question, why should the capability exchange
   should only come from the client? He is right!

   Using logoff as an example to illustrate why it makes sense.
   Supposing the NAS reports that it supports LOGOFF capability.  It
   would be nice for the Server to be able to tell the NAS that it wants
   to receive the LOGOFF message as decribed in the logoof document.
   The server could do this during Access-Accept or even mid-session
   using CoA.

   By allowing the Server to send the capability attribute back in an
   Access-Accept the server can signal what it supports and what it
   REQUIRES.

   Comments?



> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:gwz@cisco.com] 
> Sent: Wednesday, February 02, 2005 10:34 PM
> To: 'Bernard Aboba'
> Cc: radiusext@ops.ietf.org
> Subject: RE: Proposal: Capabilities Attribute
> 
> 
> Bernard Aboba <mailto:aboba@internaut.com> supposedly scribbled:
> 
> >>>       This Attribute includes a list of attribute types
> supported
> >>>       by the client.  One or more Capabilities attributes MAY be
> >>>       sent within an Access-Request packet.
> >> 
> >> Why only client & request?
> > 
> > The usage scenario I had in mind was a NAS announcing to a 
> server that 
> > it supported various attributes.  This could be useful, for 
> debugging 
> > purposes (oops, I forgot to upgrade that NAS!), or
> backward
> > compatibility (server won't send a new attribute to a NAS that
> > doesn't support it).    
> > 
> > Can you describe how a server could use a Capabilities attribute?
> 
> First, let me apologize for the tardiness of this response.  
> As it stands, by the time a client gets a response (if any) 
> from a server that doesn't support some necessary capability, 
> it's too late: either the request "succeeded" or it failed.  
> However, I don't see any reason to limit the new aspects of 
> the protocol based upon historical limitations.  
> 
> Hope this helps,
> 
> ~gwz
> 
> Why is it that most of the world's problems can't be solved by simply
>   listening to John Coltrane? -- Henry Gabriel
> 
> --
> 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/>