RE: Proposal: Capabilities Attribute

[Avi Lior <avi@bridgewatersystems.com>]

Hi,

We already have proposed a scheme for doing this in one of the other drafts.
I will post the attribte below:

The requirements as we saw them is:

NAS advertizes support for a capability. Prepaid, Dynamic Auth.
NAS advertizes subcapabilities of a given feature.

So using prepaid as an example, you adveritze that NAS supports prepaid and
also what kind of prepaid support is available. For example, Volume based,
Time based, etc...

Another example:  Support for Dynamic Auth RFC 3576
NAS may support DM, COA (PUSH model), COA (PULL model)

To Bernards design.  Its almost identical to ours except that we bit encode
the subcapabilities instead of pushing the dictionary to the Server.  This
is more efficient and in somecase a subcapability may have no attributes
(see the above example for Dynamic Auth) or too many attributes.

So here is what we proposed in the following
(http://www.ietf.org/internet-drafts/draft-adrangi-radius-attributes-ext 

NOTE we are thinking a much simpler layout for this attribute (same as
Bernard suggested):

So instead of an integer we will use a string with the first part being the
capability followed by one or more octest representing bit mask for
suboptions.  This would make it simpler to extend.

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Type      |    Length     |  Integer                      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Name  
      
     Generic Capability 
    
   Type 
    
     To be assigned by IANA 
    
   Length 
    
     = 6               
     
   Integer 
    
   The format of this Integer is as follows: 
    
   0xCCCTSSSS 
    
   Where: 
     CCC is a 12-bit indicator that identifies the capability ID.  
     CCC = 0x000 and 0xFFF is reserved.   
    
     T is a 4-bit indicator used for extending the sub-capability   
     space. T = 0xF is reserved. 
      
     SSSS is 16-bit indicator that identifies the sub-capabilities ID.  
     These are determined by the application writer and may represent a 
     number of mutually exclusive sub-capabilities or mutually 
     inclusive sub-capabilities codes as bits. 
    
   Extension of sub-capabilities: 
    
      T=0x0 represents the first 16 bits of sub-capabilities 
      T=0x1 represents the next  16 bits of sub-capabilities 
      T=0xF represents the last  16 bits of sub-capabilities 
    
   The following Capability Identities are assigned by this RFC. 
   Additional capability ids may be assigned later.  See the IANA 
   section. 
    
   Note: we have to assign some capabilities from radius and 
   also sub-capabilities. Candidates would be from RFCs 2865, 2869, 
   2867, 3162, 3576, 3580.   


> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: Monday, January 17, 2005 1:23 AM
> To: Glen Zorn (gwz)
> Cc: radiusext@ops.ietf.org
> Subject: RE: Proposal: Capabilities Attribute
> 
> 
> > >       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?
> 
> --
> 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/>