Re: "Last Look" at the RADIUS Design Guidelines document

[Avi Lior <avi@bridgewatersystems.com>]

I want to start with this point first...

>> 
>> I dont understand ( i never understood) what is the objection around this!!!!
> 
>  The objection I have to your arguments is that they argue against a
> position that is not reflected in the document.  They impose a false
> dichotomy by treating all code changes identically.
> 
>  The document says this:  Simplicity is preferred to complexity.
> Complexity is acceptable in some circumstances.  Complex changes have
> higher risk than simple changes.

I dont agree with that.  You should not make a judgement call about my application layer.  A complex attribute embedded in a VSA or a String does not make RADIUS layer complex!!!

You are asserting that grouping of attributes together adds complexity and I am saying that that is not neccessarily true.

I think you should let the Designer of the "Application" decide - or do a better job talking about design practices of the Application layer.  I rather we keep silence about practices at the application layer.

Grouping of attributes does not introduce complexity but rather reduces it!!!

> 
> 
>  There has been *major* opposition to these statements.  The push seems
> to be that we should have no preference between complexity and
> simplicity, because all code changes are equal, and complex systems are
> no different than simple ones.

I think the push back is based on the fact that we are disagreeing on the application.  If we rely on the RADIUS layer to parse the attributes then yes it is complex.  But this is not about the RADIUS layer.  And the use of these grouped AVPs is actually reduces complexity.

> 
>  50 years of computer science practice shows this argument to be false.
Great point:  50 years of computer science brought us from flat attributes to grouped attributes to objects etc...So what is your point?

> 
>  If you have found a way to make complex changes no more expensive or
> risky than simple changes, you have discovered practices that will
> revolutionize computer science, and will make you personally wealthy.

As the saying goes, from you lips to God's ears!!!!

But i dont think that what we are talking about is so revolutionary.  So I cant take credit for that.  In fact,  it seems that only in RADEXT this is an issue...


> 

> 

Then for other reaction See inline...

On 06-01-2010, at 03:38 , Alan DeKok wrote:

> Avi Lior wrote:
>> When one receives a string that one has to parse then it requires code change - or specific code to parse the string.
> 
>  Code changes are not all the same.
I dont even know how to respond to that.
> 
>> A complex attribute is no different then a string.
> 
>  What ever happened to "KISS"?
What makes you think that a C-Struct is not KISS?
What makes you think that a Group AVP in Diameter is not KISS?

I would argue that it is KISS to group attributes that function together in a single attribute as compared with coming up with concepts like "tags" to try to achieve the same result!!!

I really really dont understand why you would think that a "COMPLEX" attribute does not follow the KISS doctrine.


> 
>> In fact code change is required anytime one has to process any attribute beyond simply transporting the message to the next hop.  Whether  it is at the client, the proxy or the server.
> 
> In fact, bits are exchanged when a client talks to a server, and all
> bits are equal.  So DNS packets (composed of bits) are interchangeable
> with RADIUS packets (composed of bits).
> 
>  Hmm... there's a logical fallacy in that argument...
Correct at the IP layer say.  The payload is simply passed along without the entities doing the transport having to care about what is in the payload.

Similarly, AAA entities that dont need to know what is in the string can pass the string along without carrying what is in it.  But eventually somebody will care about what is inside that string and that entity would have specific code to deal with processing the string.

So is the same if we use a RADIUS attribute of type int.  Entities in the AAA chain can pass it along without understanding the meaning of the AVP and only those parties that need to know whould have the code logic to process the value of that int correctly. 

I think you are confusing the function of lower layer with application layer.  Processing of complex type happens at the "Application Layer" .  Code change is not required in the lower layer.

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