RE: Request for Review of RFC 3576 MIB documents

["Nagi Reddy Jonnala \(njonnala\)" <njonnala@cisco.com>]

Initially the Dynamic Authorization Client and Dynamic Authorization
Server terminology was initiated because the "client" and "server"
entities are different here(when compared with
authentication/accounting). For instance, the authentication/accounting
entity that resides on the NAS is described as
"authentication/accounting client" and the same case with
"authentication/accounting server". In the Dynamic Authorization case,
calling the Dynamic Authorization entity that resides on the NAS as
"Dynamic Authorization Client(DAC) actually creates more confusion. So
we had to flip the terminology.

Having said that as mentioned by Murtaza, there could be other entities
like Prepaid Server who are neither Radius authentication nor accounting
servers. 

Though if the WG suggests good terminology, we see no reason to adopt
that terminology instead of DAC and DAS. IMO, though the existing DAC
and DAS terminology may look confusing initially but once the ice is
broken, it would actually make more sense.


Thanks
Nagi.



-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
On Behalf Of Nelson, David
Sent: Friday, July 22, 2005 7:54 PM
To: Murtaza Chiba (mchiba)
Cc: radiusext@ops.ietf.org
Subject: RE: Request for Review of RFC 3576 MIB documents

> > Why can't we just state up front that a DynAuthClient = RADIUS
Server,
> > DynAuthServer = RADIUS Client, and avoid using the DAC and DAS 
> > abbreviations?
> >
> 
> One reason is that the client need not be limited to a RADIUS Server.
> Infact it can be any entity that shares a secret and uses the
interfaces
> specified by RFC3576, for e.g. a Rating Engine or a Captive Portal.

Hmmm.  I don't think it's a good idea for RADIUS RFCs (or the RADEXT WG)
to be documenting protocols for applications that are not RADIUS.  While
I understand that one *could* re-use elements of RADIUS protocol
documents to create a new application, I think that the RADIUS documents
themselves need to stick close to home and describe RADIUS.  Period.

> > Section 5
> > "This table contains one row for each DAS that the DAC shares a
secret
> with."
> >
> > RFC 3576 only talks about secrets shared between RADIUS clients and 
> > servers, not between a DAS and a DAC.
> >
> 
> Kind of same as above.

I offer the same comment as above, in kind.  :-)

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

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