RE: Proposal: Capabilities Attribute

[Avi Lior <avi@bridgewatersystems.com>]

Thanx Barney.

Interms of justification. There have been at least three features in front
of us the require that the home server know whether or not the NAS supports
a particular capability.  Prepaid, CUI, Bandwidth. 

Just to be clear it's not a bit per attribute but rater a bit (or two) per
subcapabilites.  The authors of a capability will determine which are the
subcapabilities of their feature.  Obviously we can do this for existing
capabilities.

So to summarize:
=================
For the capability: one octet will give us 256 capabilites. Should be okay
or do we want two octets?

For subcapabilites one bit: per subcapabilites. Or as you suggest: using two
bits:

00 means do not support
10 means supported
11 means supported and required




> -----Original Message-----
> From: Barney Wolff [mailto:barney@databus.com] 
> Sent: Tuesday, January 18, 2005 12:38 PM
> To: radiusext@ops.ietf.org
> Subject: Re: Proposal: Capabilities Attribute
> 
> 
> I hope every proposer of a complex attribute is prepared to 
> design, code, debug and support the logic necessary to react 
> to all possible values, in client, proxy, protocol gateway 
> and server.  Otherwise, it becomes what in US politics is 
> called an "unfunded mandate".
> 
> IMHO, anything beyond a single bit per attribute number is 
> overkill. But if we want to expend 2 bits, I'd opt for 1 bit 
> meaning "I accept this attribute" and the other meaning "I 
> require this attribute in an Access-Accept and if missing 
> will treat it as a -Reject".  I would also exclude any 
> VSA-related functions from standard capabilities indication.
> 
> For every perceived problem, there is a solution.  But one 
> has to ask whether the cost of the solution is really less 
> than the cost of leaving the problem unsolved.
> 
> -- 
> Barney Wolff         http://www.databus.com/bwresume.pdf
> I'm available by contract or FT, in the NYC metro area or via 
> the 'Net.
> 
> --
> 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/>