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

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

HI Alan,

Please see inline.... 

> -----Original Message-----
> From: aland@nitros9.org [mailto:aland@nitros9.org] On Behalf 
> Of Alan DeKok
> Sent: Thursday, March 16, 2006 1:09 PM
> To: Avi Lior
> Cc: radiusext@ops.ietf.org
> Subject: Re: New Technical Issues RE: WG last call in 
> progress on VLAN/Priority Draft
> 
> "Avi Lior" <avi@bridgewatersystems.com> wrote:
> ...
> 
>   I think we're agreeing on most things, and just nit-picking 
> on details.  That being said, let's continue.

I agree.

> > But alan, you cant go on the assumption that you will only accept 
> > non-binary "code" changes.
> 
>   I'm not assuming that.  I'm assuming that, again, for the 
> 99% common case, dictionary updates are enough to enable the 
> server to deal with new attributes.  This has been true in my 
> experience, in the last decade of working with RADIUS.

That is the past.....today RADIUS and AAA for that matter is being asked
to participate in more complex scenarios.  So we have to let go of the
past ---- let it go .... Let it go   ;-)

Examples of complicated AAA scenarios:

EAP.  RADIUS now has to have an EAP Authentication Server
Prepaid or Credit control
MIPv4
MIPv6
Redirection (complexity on client side)
 
> > Some attributes -- like the prepaid -- or mobile ip -- EAP 
> --- require 
> > complex algorithms to be executed.  I doubt you can do them via 
> > configuraiton files.
> 
>   Which is why I never claimed you could.  Please, don't 
> think I'm unaware of algorithm changes that require updates 
> to the server binary.  I've mentioned that explicitely in 
> previous messages.

OK.  I never claimed you are not aware.  But since the Application has
to parse the attribut anyway then on the transport layer why not just
deal with it as a string?
 
> > Yes. I agree. But my parser in my product is very capable and can 
> > handle more complex attribute structures then the other 
> fellow.  So I 
> > can restate your statement as "complex things should be simle to do"
> 
>   If your parser can handle algorithm updates, too, more power to you.

>   The problem the dictionaries solve is, again, the 99% 
> common case where a more complex parser just isn't necessary.

Yes in the old days ;-) for the simplest of applications.

> > Semantics are handled by clever policy files which use the 
> attribute 
> > to compute some outcome.  The policy files are NOT standard 
> in RADIUS.
> 
>   Agreed.  But again, the dictionaries (to a large extent) 
> simplify policy engines by removing the requirement that the 
> policy engines understand RADIUS attributes.  They don't.  
> They just understand name to type mappings, and instances of 
> named objects.

Sure.  But even in the Good Old Days of RADIUS  attributes like
User-name etc required complex parsing of the user-name usign Regular
expressions.  At least that was true in our deployements.  And our
deployements are never in the enterprise space.
 
> > The bottom line is this:
> > We ought not make descision based on how complex or simple it is to 
> > handle an attribute.  That is nuts.
> 
>   I'm not sure why.  If an application can be supported by 
> simply defining a new attribute, and requiring that the 
> attribute be sent in a packet, then that application could be 
> standardized with little discussion.

That is fine.  But why should we balk when we are faced with a complex
attribute as required by a complex application. The argument that it
breaks the dictionary should NOT stop the work going forward.  The
Dictionary should only parse it up to String.  Let the application
decode the rest.


>   If an application requires more complex changes to the 
> protocol, then the decision to standardize it requires more 
> discussion than the previous case.

Dictionary is not Protocol!!!

Application don't really change the protcol usually.  Even complex ones.
 
>   Complexity *does* influence decisions.  Strongly.

I don't agree that complexity should influnce decision.  I think
uncessary complexity should be reduced.  But not to accept a RADIUs
feature because its too complex is not correct.  A RADIUS feature should
be accepted if it's need is demonstrated regardless of its complexity.

I agree that more complex application require more time to develop but
at the application level and not neccesarily at the protocol level.

And complex application does not necessarily mean a complex attribute.
A simple attribute carrying an integer may be associated with a complex
application.

 
> > My original motivation for having a standard for complex attributes 
> > was because people were encoding attribute using name value 
> pairs such 
> > as: in a String address="24 oberon",phone=" ".  I wanted to 
> stop that 
> > because parsing these strings would slow every RADIUS server out 
> > there, and it was wasting space.
> 
>   Agreed completely.
> 
> > Also I resent somewhat the push now is so much that it 
> ignores what we 
> > did a two years ago.  Based on discussion it was Jari who proposed 
> > encoding RADIUS attributes using Diameter syntax (I seem to recall 
> > that one of you guys were taking credit for that).
> 
>   Sorry for any conflict... that wasn't the intent.
> 
> > I think any other coding scheme is nuts and we should just move on 
> > with diameter encoding.  Unless of course  there is already working 
> > code as in the case of Prepaid.
> 
>   Agreed.  Let's move forward on that basis.
> 
>   Alan DeKok.
> 

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