RE: Potential work items

[Avi Lior <avi@bridgewatersystems.com>]

We are getting converged here....

> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com] 
> Sent: Thursday, January 08, 2004 2:10 PM
> To: Avi Lior; radiusext@ops.ietf.org
> Subject: RE: Potential work items 
> 
> 
> Avi Lior writes...
> 
> > Great!!! I was saying that all along.  Prepaid is exactly that so is
> the
> > Sterman draft.
> > Both of these are add on applications.  They both need specialized
> code in
> > the RADIUS server to perform their Authentication/Authorization.
> 
> My ears prick up when you say "code in the RADIUS server".  
> If you mean a separate application (or service) running on 
> the same host as the RADIUS Server application, and 
> communicating tot eh RADIUS Server via some API, then fine.
> 
> If you mean that the code is integral to the RADIUS Server 
> application and the parser code that understands RADIUS 
> attributes also needs to understand the "opaque" messages, 
> then maybe not so fine.  

So we are in total agreement.  We do not want to break  the parser code of
RADIUS!!!

The intent of my draft and that of the sterman draft is to pass the a string
attribute to some plugin code for futher processing.  That code would know
what to do with the string.

> If the "opaque" message format is not documented as part of, 
> or an extension to, RADIUS or Diameter, then it follows the 
> EAP precedent.

We still need to document the opaque messages though in the RFCs.  This is
akin to Diameter Applications.  For the base RADIUS server (the parsing
engine etc) the string is Opaque but we need to document its contents so
that we have interoperability.

 
> -- Dave
> 
> 
> 

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