RE: Rationalizing the RADIUS data model

[Avi Lior <avi@bridgewatersystems.com>]

Why John?

Because I don't want to do the work for academic reasons!!!!

And I certainly don't want to do the work in RADIUS.

Frankly I think its nuts!!! On one hand the same people that want to do this
are saying that RADIUS will soon die -- and they are turning around and
suggesting we need guideline documents.

And I want this work to be held to the same standards BTW.  Show me who
wants this done?

Finally, the Vendor issue is not a RADIUS problem its an IETF problem.

Like it or not, regardless of what we think the definition for Vendor is -
the IETF provides external entities a mechanism for extending IETF protocols
and that is and has been the Vendor Specific Attribute.  

This is the defacto standard.  Its not busted.  I havent seen any concrete
evidence that it is.

Avi

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] 
> Sent: Thursday, June 10, 2004 11:43 PM
> To: avi@bridgewatersystems.com; barney@databus.com; 
> radiusext@ops.ietf.org
> Subject: RE: Rationalizing the RADIUS data model
> 
> 
> Avi,
> 
> > > Knowing the enforcemant part of the IETF is rather weak, I
> > > don't think you need to worry about this.  If the IETF 
> > > defines a standard content, and insists upon its use for 
> > > standard / interoperable usage, would this be a problem?  
> > >
> > The answer is yes!!!!!
> 
> OK, what problem does this cause?
>  
> > Then what is the point of doing this?  This is going to 
> generate more 
> > heat then light.  It will be a pointless exercise.
> 
> Jari said this already:
> 
> 	.. obviously, the
> 	primary driver for something like this would come from
> 	a longer-term desire to improve and unify the data
> 	models in VSA, SDO, and IETF space. Current drafts on
> 	the IETF stds table do not cause us to run out of attribute
> 	or type space. So the first thing to decide is whether we
> 	want to do something about the "VSA problem", and if
> 	yes, then something like what I proposed would seem
> 	reasonable.
> 
> John
> 

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