RE: Proposal: Capabilities Attribute

[Avi Lior <avi@bridgewatersystems.com>]

How would you do a bit per attribute?

To me that is sending a sparse metrics.  And also, not every capability and
or sub-capability maps to an attribute. For example, support for DM or COA
message, they are actually two command codes.

But in prepaid we need to know whether or not the NAS supports a type of
prepaid for example Volume based prepaid or Time based prepaid or both. This
does not map to an attribute but rather a value of one or more attributes.
So it is not safe to say that Capabilities and sub-capabilities map to
attributes.



> -----Original Message-----
> From: Barney Wolff [mailto:barney@databus.com] 
> Sent: Tuesday, January 18, 2005 1:46 PM
> To: Avi Lior
> Cc: radiusext@ops.ietf.org
> Subject: Re: Proposal: Capabilities Attribute
> 
> 
> On Tue, Jan 18, 2005 at 01:25:36PM -0500, Avi Lior wrote:
> > 
> > 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.
> 
> I was arguing for the simplest scheme that solves 
> otherwise-painful problems.  To me, that's a bit per *attribute*.
> 
> I was more urgently arguing for fewer options in feature 
> support.  To paraphrase Yoda, "Support, or do not support.  
> There is no partial." Consider the code and the testing 
> effort implied by a need to handle interacting combinations 
> of subfeatures.
> 
> Regards,
> Barney
> 

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