RE: Proposal: Capabilities Attribute

[Avi Lior <avi@bridgewatersystems.com>]

David,

> it(Prepaid) does seem to me to be an 
> example of a protocol with way too much complexity to be 
> successful in broad deployments, involving more that a very 
> small number of implementations.

Diameter is significantly more complex protocol then RADIUS.  Hmmmmmmm is it
an example of a protocol with way too much complexity to be successful in
broad deployments, involving more than a very small number of
implementations?

I don't know.

As Mozart said when the King complained that his compositions had too many
notes; his reply, "This composition has just the right number of notes."

While I respect your personal opinion on the complexity issue and perhaps I
agree in theory; Prepaid is one example to the contrary.  It would be nice
to reduce the number of notes but more often then not that leads to bad
music or bad procols that have a zero life.  Complex protocols such as
Diameter and Prepaid can be successful in broad deployements.  

Just speaking to my personal knowledge on prepaid: Prepaid requirements have
been analyized by many many engineers in 3GPP, 3GPP2, all their customers;
and folks in AAA-WG and RADEXT and many other engineers who work for
companies.  I am sure that they are even more concerned by overlly complex
requirements and protocols.  The Protocol produced in the case of Diameter
was reviewed by 3GPP and AAA-WG and I am sure that they were concerned about
complex protocols. The AAA-WG and their solution has the "same number of
notes" (more or less) as the RADIUS solution.  I would tend to think that
Prepaid has the right number of notes.

As for implementation: both RADIUS and DIAMETER have been provided by many
companies. Also we know from our meeting that many folks have implemented
similar solutions and are looking for the features that Diameter and RADIUS
protocols are offering.

As for deployments, Prepaid as been deployed both in 3GPP and 3GPP2. And
serving millions of subscribers today.


Avi


> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com] 
> Sent: Tuesday, January 18, 2005 3:35 PM
> To: radiusext@ops.ietf.org
> Subject: RE: Proposal: Capabilities Attribute
> 
> 
> Avi Lior writes...
> 
> > Well I think I wasn't making my point clear:
> 
> <snip>
>  
> > 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.
> 
> Well, I think I did understand what you were trying to say... 
> I just didn't agree.
> 
> I guess I'm moderately opposed to complex protocols, with 
> lots of nuances in option support, sub-options, 
> sub-capabilities and partial compliance states.  And I'm 
> opposed to using RADIUS to facilitate that sort of thing.
> 
> We are not debating the issue of Prepaid Services, but since 
> you used it as an example, it does seem to me to be an 
> example of a protocol with way too much complexity to be 
> successful in broad deployments, involving more that a very 
> small number of implementations.  It would be better, IMHO, 
> to have a few "profiles" of compliance, rather than allowing 
> all the conceivable scenarios.
> 
> 
> --
> 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/>