RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft

["Avi Lior" <avi@bridgewatersystems.com>]

Emile, 


> This WGs very existence, how reluctantly it was started, is 
> testament that people rather build upon RADIUS than look at 
> DIAMETER for their solutions.

I am sorry you don't get it!!! 

It's not that we rather build upon RADIUS.  We live in a commercial
world that requires us to build upon RADIUS.  We are not given a choice.
We have paying customers who invested millions of dollars each in their
RADIUS infrastructure and they don't want it to go away (yet).


> I find it then entirely foolish to suggest that a blanket 
> transport mechanism for DIAMETER inside RADIUS would solve 
> all our issues. 

Given the evidence I have seen, the Diameter encoding will work.

Take away the 'M' and 'P' bits because I don't think those make sense
much.

Any shortcomings should be addressable -- unless of course the IETF
decides to get in the way as they do with RADIUS.

> I find it incomprehensible that the DIAMETER format would not 
> need any evaluation against the alternatives on the merits, 
> but that people can just wave their hands and say, there's 
> already some diameter parsing code in many RADIUS server's 
> that support TTLS in some form or other, so hey, 'tis the 
> only sensible road ahead.

If you want to transition from RADIUS to Diameter why not get the
attributes aligned -- it will make the cut over a lot easier.


 
> Really, is that all we can muster these days?

I havent seen any better approach so I guess -- yes.

I am sorry that makes you sad.

> Cheers,
> 
> 
> Emile.
> 
> -- 
> E-Advies - Emile van Bergen           emile@e-advies.nl      
> tel. +31 (0)78 6136282           http://www.e-advies.nl    
> 

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