RFC 4673, "RADIUS Dynamic Authorization Server MIB", September 2006Source of RFC: radext (ops)
See Also: RFC 4673 w/ inline errata
Errata ID: 888
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Verifier Name: Stefaan De Cnodder
Date Verified: 2006-11-07
severe MIB module structural problem -- issue instantiated similarly in both RFC 4672 and 4673 Let's start with RFC 4672 and the RADIUS-DYNAUTH-CLIENT-MIB module. On page 5 of RFC 4672, two module-global scalar objects are specified; the DESCRIPTION clause of the radiusDynAuthClientDisconInvalidServerAddresses OBJECT-TYPE says: [...]. This counter may experience a discontinuity when the DAC module (re)starts, as indicated by the value of radiusDynAuthClientCounterDiscontinuity." and the literally same sentence appears again in the DESCRIPTION clause of the radiusDynAuthClientCoAInvalidServerAddresses OBJECT-TYPE. This would make sense iff radiusDynAuthClientCounterDiscontinuity would have been defined as another module-global scalar MIB object. But unfortunately, radiusDynAuthClientCounterDiscontinuity is a tabular row object in the radiusDynAuthServerTable, with separate instances for every radiusDynAuthServerIndex instantiated there. So, which object instance should be taken for reference ??? Moreover, should ever the radiusDynAuthServerTable be empty, no such CounterDiscontinuity objects would be instantiated, invalidating the semantical integrity of the MIB module. Thus, let's take a closer look at the DESCRIPTION clause of the radiusDynAuthClientCounterDiscontinuity OBJECT-TYPE, on page 17 of the RFC: DESCRIPTION "The time (in hundredths of a second) since the last counter discontinuity. A discontinuity may be the result of a reinitialization of the DAC module within the managed entity." It remains unclear which scope was intended, i.e. whether "the last counter discontinuity" was meant to just cover the counters within the same conceptual row of the table, of it was meant to cover all the counter objects in the MIB module. If the former interpretation is to be accepted, the references to this object from the scalar objects' DESCRIPTIONS quoted above would be severely ambiguous. In case of the latter interpretation, the semantics of this object indeed do not depend in any way on the conceptual row, i.e. the related radiusDynAuthServerIndex instance; but if an object of the same semantics appears in every table row instantiated, all of its instances must have the same value at any point in time. Hence, the object with that semantics should have been modeled as a module-global scalar object, and not as a tabular object !!! IMHO, such a single, module-global scalar object would perhaps be sufficient for the desired purpose. In a similar way, the module-global scalar counters in the RADIUS-DYNAUTH-SERVER-MIB module, radiusDynAuthServerDisconInvalidClientAddresses and adiusDynAuthServerCoAInvalidClientAddresses, as specified on page 6 of RFC 4673, refer to the object, radiusDynAuthServerCounterDiscontinuity, which turns out to be a tabular row object in the radiusDynAuthClientTable, not another scalar object, thus leading to the same kind of ambiguity. Taken altogether, the specifications are ambigous and will certainly lead to interoperability problems. I strongly propose to revise these MIB module specifications as soon as possible.
seems to be correct. The scalars do not have a discontinuity object.
That sentence should be removed or either an object has to be added. It
seems that the other mibs like RFC4668 also does not have such an object
for the scalars while it has a discontinuity timer for the objects in
the table... It should be for all or for none I would think.