RE: Items from the IETF-63 meeting requiring confirmation.

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

All,

Please see below my view points on the Dynauth MIBs for issue 92.


> 2.) With regard to draft-ietf-radext-dynauth-client-mib-01 and
draft-ietf-radext-dynauth-server-mib-01, RADEXT Issue 92, > that the
drafts will be revised to use terminology that is consistent with the
base document, RFC 3576.


First I would like to request the group to focus on the below points and
not getting distracted or drawing conclusions on the other previous
discussions.

- Take for instance, Radius Authentication Client MIB, RFC-2618(Same is
true with the Radius Accounting MIB as well). You can observe that there
is the term "Radius Authentication Client" everywhere but you may wonder
where is this terminology coming from? If you refer to the RFC-2865, all
you find is Radius client or server but not Radius *Authentication*
client/server.

  
- However, if you read the "Overview" section of the RFC-2618, you find
the below and I wonder if anybody has problems to understand what
exactly "Radius Authentication Client" is and who is supposed to
implement "Radius Authentication Client MIB". IMO, the term "Radius
Authentication Client" in RFC-2618 makes a lot of sense though there was
*no need* to introduce this term in the base RFC-2865.

  For your quick ref, snippet from RFC-2618, Overview section.
   
   "The RADIUS authentication protocol, described in [16], distinguishes
   between the client function and the server function. In RADIUS
   authentication, clients send Access-Requests, and servers reply with
   Access-Accepts, Access-Rejects, and Access-Challenges.  Typically NAS
   devices implement the client function, and thus would be expected to
   implement the RADIUS authentication client MIB, while RADIUS
   authentication servers implement the server function, and thus would
   be expected to implement the RADIUS authentication server MIB."

- Now, if you see the Dynauth MIBs, no wonder, you observe the Dynamic
Authorization Server/Client terms. Base protocol talks about the Dynamic
Authorization Protocol(RFC-3576) though *no need* to introduce the
Dynamic Authorization Client/Server.

- The only extra section for Dynauth MIBs is to clarify "DAC" and "DAS"
because that in this particular case (in contrast with Radius
Authenticatio/Accounting Client/Server) the client and server
functionality is reversed.

Conclusion:

Terminology is never defined in the base RFCs but introduced
informally(not noted in the bold letters that says "Terminology") in the
respective MIBs as and when appropriate. Like the other MIBs, Dynauth
MIBs also have the overview section that clarifies the terminology. In
the case of the Dynauth MIBs, since the client/server functionality is
reversed, we highlighted/clarified in the Terminology section as per the
WG suggestion.

Had the Dynauth protocol operate on a regular "pull" model instead of
"push" model(i.e., authentication and accounting requests are initiated
by the NAS and acts as client. For the Dynauth, the Radius server
initiates the requests and NAS acts as a server), then we would have
observed *absolutely no difference* with the other MIBs. For instance,
if I could have referred the NAS as a "Dynamic Authorization Client"
then you wouldn't have even noticed the difference between the other
MIBs and Dynauth MIBs.

The terminology has always been introduced/defined in the MIBs. Hence I
don't see a need to define this terminology in the RFC-3576bis/Issues
and Fixes document. 

Hope I can convince atleast some of you. We need your vote especially
when you are in agreement  :-)

Thank you,
Nagi.

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