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

[Avi Lior <avi@bridgewatersystems.com>]

On 12-01-2010, at 11:07 , David B. Nelson wrote:

> On Jan 12, 2010, at 10:14 AM, Avi Lior wrote:
> 
>> I am sorry but i dont understand the concept of a non-IETF SDO vs (I  
>> assume) an IETF SDO.
> 
> The is no significant concept there other than the fact that I  
> consider the IETF to be an SDO.
> 
>> I think that that is a personal attack David...
> 
> It was not intended as an attack, but simply as an observation.

I am pretty sure that this response proves something --- I will let the others deal with this in appropriateness. 

> 
>> You have no idea what I have been doing in other SDOs.
> 
> With all due respect, you personally told me as much during one of the  
> IETF social events.  Do you recall?  While I do see an element of  
> irony here, let's not get diverted down that "rathole".

I told you many things in social events.  I don't recall ever telling you that I undermine the IETF or intent to undermine the IETF.  But since you have justification for your accusation (OBSERVATION) care to share?

> 
> I think the main issue of contention is how to reasonably extend the  
> RADIUS protocol to me the need to advanced applications.  I think that  
> it's reasonable to *extended* RADIUS in a forward / backward  
> compatible way.  What I think is unreasonable is to *re-define* RADIUS  
> in a fashion that "breaks" a large number of fielded deployments.

I am not proposing to redefine RADIUS. Please show me where I am doing that WRT to this document.


>  We  
> can argue all day about whether the "traditional" RADIUS Attributes  
> and data model as defined in RFC encompasses the notion of complex  
> attributes.  What I think is compelling is the fact that a large  
> number of existing implementations took the interpretation that it  
> doesn't.
Are you saying that using a String attribute to carry more then one information element is NOT a complex type.  

> 
> Why is it so onerous to utilize the RADIUS Extended Attribute as the  
> vehicle to address the needs fro complex types and other advanced  
> features?  I simply don't understand.

That is a separate argument - different discussion - different draft.  I am not trying to bring in Complex types in this document.

And even in the extended document i did not want to extend the attribute in the sense of COmplex Types.  The working group did.  All we were trying to do is extended the attribute type space beyond 256.

I am not really sure what you are talking about.

Take a look at my comments and comments made by other folks and stick to those topics.  That is if you want to make progress.

Avi



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