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

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

Please see inline with the tag <Nagi>

-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
On Behalf Of Murtaza Chiba (mchiba)
Sent: Thursday, August 25, 2005 5:20 AM
To: Nelson, David
Cc: radiusext@ops.ietf.org
Subject: Re: Items from the IETF-63 meeting requiring confirmation.

David et al.,


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

<Murtaza> Would like to point out that the new terms introduced do use
the terms as found in the RFC3576 as part of its definition.  These new
terms are necessary to make it unambiguous as to what the MIB objects
are referring to.  Else, we will have a strange situation where the
dynauth-client-mib will have objects that are named radiusServer and
dynauth-server-mib having objects name radiusClient at the top level,
which IMO is most likely to be more confusing.

<Nagi> Does it make sense to rename it as "radiusClient" while the other
MIBs call "radiusAuthenticationClient". IMHO, it makes a lot of sense to
call them as they are. i.e., "radiusDynAuthServer" and
"radiusDynAuthClient". The only difference I see is that the DynAuth
MIBs have the formal "Terminology" section and there is a justification
why it is there as I mentioned in my other e-mail.

<Murtaza> Further, the intent for the new terms has been misrepresented
as being an attempt to clarify the RFC3576 rather than its original
intent which was to have unambiguous less confusing object names and
text.

<Nagi> As Murtaza correctly pointed it, the terminology is not needed to
define in the RFC-3576. It is the same with RFC-2865 and RFC-2618.

<Murtaza> If, however, the group at large feels that the terms MUST
change then we
  ask how to make the terms/text less confusing, bearing in mind that
the roles of the RADIUS Server and Client are actually reversed in the
case of the RFC3576.

<Nagi> Would like to know WG opinion as to how the Dynauth MIBs deviated
from the other MIBs and how better we can handle it.

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