RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (4)

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

Source of RFC: radext (sec)

Errata ID: 887
Status: Verified
Type: Technical
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.

Notes:

from pending


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

Errata ID: 26
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Verifier Name: Stefaan De Cnodder
Date Verified: 2006-11-07

 

(for RFC 4672 and 4673)

As specified in RFC 3410 and Part 1 of STD 62, RFC 3411, and
re-stated in the boilerplate Section 3, "The Internet-Standard
Management Framework", there's just one single
Management Information Base (MIB) comprised of various "MIB modules".
Thus, throughout the titles and the text bodies of the RFCs, the
proper term, "RADIUS ... MIB module" should be used consistently,
instead of the rather sluggish "RADIUS ... MIB".

Notes:

from pending

Errata ID: 889
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Verifier Name: Stefaan De Cnodder
Date Verified: 2006-11-07

Section 4 says:

hundredths of a second

It should say:

centiseconds

Notes:

Why not use the common ISO-standard unit-multiple name, "centiseconds" (abbreviation: "cs"), instead of the long-winded "hundredths of a second" ?

This applies to the UNITS and the DESCRIPTION clauses of
- radiusDynAuthClientRoundTripTime (RFC 4672, page 7),
- radiusDynAuthClientCounterDiscontinuity (RFC 4672, page 17),

from pending

--VERIFIER COMMENT--
well, yes, centiseconds can be used as well but both terms are the same.

Errata ID: 890
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Verifier Name: Stefaan De Cnodder
Date Verified: 2006-11-07

In Section 4

The DESCRIPTION clauses of several OBJECT-TYPE invocations 
contain the same spurious fragment of a sentence:

   [...].  Disconnect-NAK packets received from unknown addresses.

This fragment apparently has been copied inadvertently from the
DESCRIPTION clause for radiusDynAuthClientDisconInvalidServerAddress,
and it should be deleted afterwards, in all instances:

  - radiusDynAuthClientCoAInvalidServerAddresses  (page 5),
  - radiusDynAuthClientDisconRequests  (page 8),
  - radiusDynAuthClientDisconAuthOnlyRequests  (page 8), and
  - radiusDynAuthClientDisconRetransmissions  (page 8).

Notes:

from pending

--VERIFIER COMMENT--
correct, this sentence has to be removed everywhere.

Status: Rejected (1)

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

Source of RFC: radext (sec)

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



Advanced Search