apparently we do agree. thanks to Josh for his comment. just one thing:
Alan DeKok wrote:
Josh Howlett <[EMAIL PROTECTED]> wrote:
I think the point the original poster was making was that Diameter
allows arbitrary conversations between NASes and servers that are
initiated by either party, vi
hi
just a small preamble: i perfectly understand your position and i do not
expect you to start a diameter implementation tomorrow :-) for me it's
merely a strategic discussion.
Alan DeKok wrote:
Artur Hecker <[EMAIL PROTECTED]> wrote:
well, from my perspective the main arguments would b
Josh Howlett <[EMAIL PROTECTED]> wrote:
> I think the point the original poster was making was that Diameter
> allows arbitrary conversations between NASes and servers that are
> initiated by either party, via "applications", in an extensible manner.
Yup.
Which clients support diameter? I ca
On Thu, 14 Jul 2005, Alan DeKok wrote:
> Artur Hecker <[EMAIL PROTECTED]> wrote:
> > - server-initiated messaging
> > the strict client-server design of radius (imho amplified by the use of
> > the conn-less UDP) does not allow for server-initiated commands such as
> > "disconnect" or "force re-aut
Artur Hecker <[EMAIL PROTECTED]> wrote:
> well, from my perspective the main arguments would be:
...
Those are all nice arguments for diameter, and good reasons why the
protocol was designed.
But I keep coming back to: Where are the client implementations?
There are few to none client impleme
hi alan
sorry for the delay.
you might be right. yet i think that we might ignore some opportunities
which would be possible/supported by diameter.
Like... what?
well, from my perspective the main arguments would be:
- reliability (especially for accounting)
in every related implement
Artur Hecker <[EMAIL PROTECTED]> wrote:
> you might be right. yet i think that we might ignore some opportunities
> which would be possible/supported by diameter.
Like... what?
> i really believe that current usage produces demand in the same
> manner as demand influences the usage. using addi
Stefan Winter <[EMAIL PROTECTED]> wrote:
> > see also "open diameter". it even does EAP...
>
> Well, it does packet handling, providing only a library for the
> server. But in order to really use it, you must first wrap daemon
> glue code around the libraries, and you must be able to do something
> Alan DeKok wrote:
> > See "wire diameter", from Taiwan. I recall it's a student project,
> > but it does give a minimal diameter server.
I took a look at it two months ago or so. It may implement the Diameter
protocol, but does not have any backends on board, so the use case I
mentioned (AD
you might be right. yet i think that we might ignore some opportunities
which would be possible/supported by diameter. i really believe that
current usage produces demand in the same manner as demand influences
the usage. using additional web-based "touches" to trigger server
solicitations by
Artur Hecker <[EMAIL PROTECTED]> wrote:
> well, that's not the point since diameter would be backwards compatible
> to radius... but i do ask myself what the manufacturers are waiting for.
> it could be at least an option.
Diameter will be interesting ole when manufacturers ship millions of
bo
Alan DeKok wrote:
See "wire diameter", from Taiwan. I recall it's a student project,
but it does give a minimal diameter server.
But again, can you think of *one* client implementation of diameter?
I can't.
well, that's not the point since diameter would be backwards compatible
to radi
Stefan Winter <[EMAIL PROTECTED]> wrote:
> Speaking of a radar - is an implementation of the Diameter protocol
> something you have on that radar as well?
Why the heck would we do that?
> To my knowledge, no real usable implementation exists. The only
> serious thing on Open Source side I have
Hi!
> radsec? It addresses the server->server problem, not the supplicant
> login problem.
> Sure, it's on the radar, but so far there hasn't been much
> *practical* interest in implementing it.
Speaking of a radar - is an implementation of the Diameter protocol something
you have on that radar
14 matches
Mail list logo
