RFC 2866, "RADIUS Accounting", June 2000Source of RFC: radius (ops)
Errata ID: 4488
Publication Format(s) : TEXT
Reported By: Nick Lowe
Date Reported: 2015-09-29
Rejected by: Benoit Claise
Date Rejected: 2015-10-05
Section 5.11 says:
Acct-Multi-Session-Id Description This attribute is a unique Accounting ID to make it easy to link together multiple related sessions in a log file. Each session linked together would have a unique Acct-Session-Id but the same Acct-Multi-Session-Id. It is strongly recommended that the Acct- Multi-Session-Id contain UTF-8 encoded 10646  characters.
It should say:
Acct-Multi-Session-Id Description This attribute is a globally unique Accounting ID to make it easy to link together multiple related sessions in a log file. Each session linked together would have a globally unique Acct-Session-Id but the same Acct-Multi-Session-Id. It is strongly recommended that the Acct-Multi-Session-Id contain UTF-8 encoded 10646  characters.
The RFC does not explicitly state the scope of uniqueness and it must be clarified to state that Acct-Multi-Session-Ids are expected to be globally unique. I believe this to be the original, implicit intent of the author.
An ideal Acct-Multi-Session-Id would have the properties of a GUID/UUID.
See Errata 4487 for the same clarification on the Acct-Session-Id.
As summarized with Nick:
It looks like the Acct-Session-Id and Acct-Multi-Session-Id errata
both will and should be rejected on the grounds that they would
constitute technical changes based on the original intent of the RFC,
which we now know. That does make sense and would be a reasonable
course of action now that that's known.
I am pleased that I have engendered a discussion on what I believe to
be a pertinent issue here. Alan has commented that he feels another
RADIUS fixes RFC would be sensible. I agree with that course of
Thanks for all your time here!