RE: Proposal: Capabilities Attribute

[Avi Lior <avi@bridgewatersystems.com>]

Hi Barney,


> This is exactly what I was ranting against.  If you're gonna 
> support prepaid, either do both or don't support it.  As for 
> command support, I might do that with virtual attributes - 
> we're not actually tight on attribute space, and indefinite 
> expansion of RADIUS makes no sense to me.  Unless RADIUS 
> remains forever much less complex than Diameter, it loses its 
> justification for continued use.

Well, this is up to the protocol designers and should not be a choice
mandated by a poor design of a capability attribute.  

So in the case of prepaid (outside the IETF) there were discussions and it
was decided that some prepaid clients would have different capabilities.

As for 
> command support, I might do that with virtual attributes - 

That would be  a hack.  So why are we doing work arounds.  Lets do it right.

> we're not actually tight on attribute space, and indefinite 
> expansion of RADIUS makes no sense to me.  

Well I think we are tight on attributes. RADIUS Digest is adding more then a
dozen attributes. There is another draft that we are wokring on that would
add more then a dozen attributes.

So why comeup with something that is intorducing limits.

> Indefinite 
> expansion of RADIUS makes no sense to me.

Lets not go there.  
 
> 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/>