RE: radius dynauth client/server mibs structure

["Nelson, David" <dnelson@enterasys.com>]

Bert Wijnen writes...

(Suggesting a mechanism for addressing the comments from Juergen
Schoenwalder and himself.)

> Let me see, the RFC-Editor note (for each MIB) would read something
aka
> 
> OLD:
>    radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::=
>                                          { radiusDynAuthServerMIB 1 }
> 
>    radiusDynAuthServer           OBJECT IDENTIFIER ::=
>                                   { radiusDynAuthServerMIBObjects 1 }
> 
>    radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE
>          SYNTAX Counter32
>          MAX-ACCESS read-only
>          STATUS current
>          DESCRIPTION
>                "The number of Disconnect-Request packets received from
>                 unknown addresses."
>          ::= { radiusDynAuthServer 1 }
> 
>    radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE
>          SYNTAX Counter32
>          MAX-ACCESS read-only
>          STATUS current
>          DESCRIPTION
>                "The number of CoA-Request packets received from
unknown
>                 addresses."
>          ::= { radiusDynAuthServer 2 }
> 
>    radiusDynAuthServerIdentifier OBJECT-TYPE
>          SYNTAX SnmpAdminString
>          MAX-ACCESS read-only
>          STATUS current
>          DESCRIPTION
>                 "The NAS-Identifier of the RADIUS Dynamic
Authorization
>                  Server. This is not necessarily the same as sysName
in
>                  MIB II."
>          REFERENCE
>                 "RFC 2865, Section 5.32, NAS-Identifier."
>          ::= { radiusDynAuthServer 3 }
> 
>    radiusDynAuthClientTable OBJECT-TYPE
>          SYNTAX SEQUENCE OF RadiusDynAuthClientEntry
>          MAX-ACCESS not-accessible
>          STATUS     current
>          DESCRIPTION
>                "The (conceptual) table listing the RADIUS Dynamic
>                 Authorization Clients with which the server shares a
>                 secret."
>          ::= { radiusDynAuthServer 4 }
> 
> NEW:
>    radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::=
>                                          { radiusDynAuthServerMIB 1 }
> 
> >  radiusDynAuthServerScalars    OBJECT IDENTIFIER ::=
>                                   { radiusDynAuthServerMIBObjects 1 }
> 
>    radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE
>          SYNTAX Counter32
>          MAX-ACCESS read-only
>          STATUS current
>          DESCRIPTION
>                "The number of Disconnect-Request packets received from
>                 unknown addresses."
> >        ::= { radiusDynAuthServerScalars 1 }
> 
>    radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE
>          SYNTAX Counter32
>          MAX-ACCESS read-only
>          STATUS current
>          DESCRIPTION
>                "The number of CoA-Request packets received from
unknown
>                 addresses."
> >        ::= { radiusDynAuthServerScalars 2 }
> 
>    radiusDynAuthServerIdentifier OBJECT-TYPE
>          SYNTAX SnmpAdminString
>          MAX-ACCESS read-only
>          STATUS current
>          DESCRIPTION
>                 "The NAS-Identifier of the RADIUS Dynamic
Authorization
>                  Server. This is not necessarily the same as sysName
in
>                  MIB II."
>          REFERENCE
>                 "RFC 2865, Section 5.32, NAS-Identifier."
> >        ::= { radiusDynAuthServerScalars 3 }
> 
>    radiusDynAuthClientTable OBJECT-TYPE
>          SYNTAX SEQUENCE OF RadiusDynAuthClientEntry
>          MAX-ACCESS not-accessible
>          STATUS     current
>          DESCRIPTION
>                "The (conceptual) table listing the RADIUS Dynamic
>                 Authorization Clients with which the server shares a
>                 secret."
> >        ::= { radiusDynAuthServerMIBObjects 2 }

It has been noted that this is a simple change to make before issuing
the RFC, and before there are implementations in the field.

Is there any objection among the members of the WG to resolving the O&M
Area Directorate comments on these documents, as shown?

Upon hearing no objections, the changes will be applied.  Please respond
prior to March 16 (the IESG Telechat at which these documents are likely
to be discussed).


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