Capabilites and Sub-capabilities -- was RE: Proposal: Capabilitie s Attribute

[Avi Lior <avi@bridgewatersystems.com>]

See my subsequent emails.

We already have these examples out there that require to know more then just
capabilities but rather finer details.  I don't think we are adding
unneccesary complexity.

For me what maybe unneccessary complexity would be using two bits to code:
Not supported, Supported, and required.  And that is because I didn't run
into cases but I suppose CUI is one where you could use Supported and
Required. 



> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com] 
> Sent: Tuesday, January 18, 2005 2:09 PM
> To: Avi Lior; Barney Wolff; radiusext@ops.ietf.org
> Subject: RE: Proposal: Capabilities Attribute
> 
> 
> Avi Lior writes...
> 
> > 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, too, question the need for, and desirability of, 
> "sub-capabilities". Let's not make this any more complicated 
> than necessary.  I will define "necessary" for the purposes 
> of this memo as a higher burden of proof than the fact that 
> authors of various drafts have *claimed* that it is 
> "necessary".  As the number of possible attribute support 
> states increases, the likelihood of convergence, correct 
> implementation and global interoperability decreases. Let's KISS.
> 
> -- Dave
> 
> 

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