RE: Proposal: Capabilities Attribute

[Avi Lior <avi@bridgewatersystems.com>]

Well I think I wasn't making my point clear:

Sending a list of attributes does not fully address all the requirements of
a capability exchange as I pointed out.

We are just thinking about CUI.  Yes it seems to solve the CUI problem but
what about, Dynamic Auth?
 How would you do that in your solution? Or prepaid where I need to know
what is the supported features of the prepaid capability.

It is one thing to say that it is too complex lets keep it simple, but the
solution you proposed has issues with it. We are not trying to save bytes
but get something that works. But even then, saving bytes does become an
issue especially if the attribute is going to be huge and you would have to
use lots of attributes.

For example, transmitting VSA capabilities would require huge number of
attributes.  Since VSA space is much larger then 256 and there would be more
then one dictionary. So you would say lets not worry about capabilities
outside the IETF. But why hide your head in the sand.

The solution we propose would allow for supporting capabilities introduced
by SDOs. They would simply assign a Capability number.  So no need to hide
your head in the sand.



> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: Tuesday, January 18, 2005 2:46 PM
> To: Nelson, David
> Cc: Avi Lior; Barney Wolff; radiusext@ops.ietf.org
> Subject: RE: Proposal: Capabilities Attribute
> 
> 
> > Just to be clear it's not a bit per attribute but rater a 
> bit (or two) 
> > subcapabilites.  The authors of a capability will determine 
> which are 
> > the subcapabilities of their feature.  Obviously we can do this for 
> > existing capabilities.
> 
> I agree that this proposal is too complex.  Grouping existing 
> attributes into "capabilities" and "sub-capabilities" seems 
> is not necessary, particularly if the only justification is 
> saving a few octets in the attribute.
> 
> Let's keep it simple.
> 

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