Subject: RFCs 4668..4671

From: Alfred Hönes <[email-masked]>
Date: Mon, 6 Nov 2006 21:17:26 +0100 (MEZ)

Hello,
after studying the recently published RFCs on RADIUS related
MIB modules, I would like to send to you, the author, a few
additional comments on RFC 4668..4671.

Because of the more general nature of the issue raised in the second
half of item (1) below, I have copied this note to the MIB doctor
Bert Wijnen.

(0)

Another, general issue has been dealt with in another message
already sent to you, the authors of RFC 4672/73, and Bert Wijnen.
For completeness, I repeat the list of related objects within
your RFCs:

- radiusAuthClientIdentifier
    in the RADIUS-AUTH-CLIENT-MIB, RFC 4668, page 6/7

- radiusAuthClientID          (deprecated object)
    in the RADIUS-AUTH-SERVER-MIB, RFC 4669, page 11
- radiusAuthClientExtID       (replacement / new object)
    in the RADIUS-AUTH-SERVER-MIB, RFC 4669, page 15

- radiusAccClientIdentifier
    in the RADIUS-ACC-CLIENT-MIB, RFC 4670, page 7

- radiusAccClientID           (deprecated object)
    in the RADIUS-ACC-SERVER-MIB, RFC 4671, page 11
- radiusAccClientExtID        (replacement / new object)
    in the RADIUS-ACC-SERVER-MIB, RFC 4671, page 14
)

(1)  misleading RFC titles, including abuse of defined terms

IMHO, the RFC titles, "RADIUS ... MIB for IPv6" are misleading.
In fact, the new RFCs extend the RADIUS MIB modules to cover
IPv6, but they are not IPv6 specific!
Perhaps, better wording would have been "... for IPv4 and IPv6".

Furthermore, a very 'popular' clash of terms shines up here.
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", of all four RFCs, 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 instead of the
rather sluggish "RADIUS ... MIB".

(2)  wrong formula in ASN.1 comments ??
     (RFC 4668 -- legacy from RFC 2618)

Around the page break from page 8 to page 9, and once more,
near the top of page 14, RFC 4668 states the formula:

   --
   -- AccessRequests + PendingRequests + ClientTimeouts =
   -- Successfully received
   --

I strongly suspect that this is wrong (-- and it does not either
match the presentation style of the formulae above in the text).
Conceptually, it makes no sense to count 'PendingRequests' and
'ClientTimeouts' as 'Successfully received', and the subsequent
DESCRIPTION clauses strongly support my suspicion that both
instances of this formula in fact should say:

                    vvv               vvv
   --
|  -- AccessRequests - PendingRequests - ClientTimeouts =
   -- Successfully received
   --

(3)  punctuation (traditional vs. rational quoting)
     (RFC 4669 and RFC 4671 -- legacy)

The DESCRIPTION clause of the radiusAuthServResetTime OBJECT-TYPE
declaration, on page 7 od RFC 4669, says:

                "If the server has a persistent state (e.g., a process)
                 and supports a 'reset' operation (e.g., can be told to
                 re-read configuration files), this value will be the
                 time elapsed (in hundredths of a second) since the
|                server was 'reset.'  [...]
                                  ^^
This does not conform to the 'rational qouting' style required
by the RFC authoring guidelines.  The RFC should say instead:

                "If the server has a persistent state (e.g., a process)
                 and supports a 'reset' operation (e.g., can be told to
                 re-read configuration files), this value will be the
                 time elapsed (in hundredths of a second) since the
|                server was 'reset'.  [...]
                                  ^^

This issues also applies to the DESCRIPTION clauses of
radiusAccServResetTime  (RFC 4671, page 7).

(3')  Note:

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

This also applies to the DESCRIPTION clauses of
  - radiusAuthClientRoundTripTime  (RFC 4668, page 8),
  - radiusAuthClientExtRoundTripTime  (RFC 4668, page 13),
  - radiusAuthServUpTime  (RFC 4669, top of page 7),
  - radiusAccServUpTime  (RFC 4671, page 7),
  - radiusAccServResetTime  (RFC 4671, page 7),
  and three objects in RFC 4672/4673

(4)  typo in RFC 4670

The DESCRIPTION clause of the radiusAccClientRetransmissions
OBJECT-TYPE declaration, on mid-page 9 of RFC 4670 says:

         DESCRIPTION
               "The number of RADIUS Accounting-Request packets
                retransmitted to this RADIUS accounting server.
                Retransmissions include retries where the
                Identifier and Acct-Delay have been updated, as
                well as those in which they remain the same."

it should say, for temproal consistency:

         DESCRIPTION
               "The number of RADIUS Accounting-Request packets
                retransmitted to this RADIUS accounting server.
                Retransmissions include retries where the
                Identifier and Acct-Delay have been updated, as
|               well as those in which they remained the same."
                                                  ^^

I leave it to your decision as to which of the items listed above
should be addressed by an RFC Errata Note submitted to the
RFC-Editor's RFC Errata web page (please make freely use of the
material presented above), or otherwise filed for consideration
in any future update to these RFCs.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+