RFC 4672, "RADIUS Dynamic Authorization Client MIB", September 2006

Errata ID: 886
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Rejected by: Stefaan De Cnodder
Date Rejected: 2006-11-07

(for RFC 4672 and 4673)

I am surprised that the 'OID anchor' of the RADIUS-DYNAUTH-xxx-MIB
modules does not match the OID hierarchy used in the other RADIUS
MIB modules published/updated concurrently.
I would have expected the new RADIUS MIB modules to be assigned OIDs
in the following, hierarchical way (using abbreviated notation):

  radiusMIB                  { mib-2 67 }  -- legacy, assigned by IANA
  radiusDynAuth              { radiusMIB 3 }       -- new
  RADIUS-DYNAUTH-CLIENT-MIB  { radiusDynAuth 1 }   -- new
  RADIUS-DYNAUTH-SERVER-MIB  { radiusDynAuth 2 }   -- new

instead of obtaining separate IANA assignments for the MIB module
OIDs, directly under mib-2.

Has there been a strong reason for this deviation from the established
pattern?

Notes:

from pending

--VERIFIER COMMENT--
Yes, there is a strong reason for it. In fact original in the first
versions of the draft, it was as follows:

radiusDynamicAuthorization OBJECT IDENTIFIER ::= { radiusMIB 3 }

radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::=
{ radiusDynAuthServerMIB 1 }

radiusDynAuthServer OBJECT IDENTIFIER ::=
{ radiusDynAuthServerMIBObjects 1 }


check
http://www.watersprings.org/pub/id/draft-decnodder-radext-dynauth-server-mib-00.txt

The reason for not doing so was that this was more difficult to
maintain. It was discussed at the mailinglist but I should search in the
archives to find it back.

Report New Errata