Subject: [Dime] Comment on section 9.8.3 of rfc3588bis

From: "Glen Zorn" <[email-masked]>
Date: Tue, 14 Jul 2009 22:23:33 +0700

This section says:

   The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32
   and identifies this record within one session.  As Session-Id AVPs
   are globally unique, the combination of Session-Id and Accounting-
   Record-Number AVPs is also globally unique, and can be used in
   matching accounting records with confirmations.  An easy way to
   produce unique numbers is to set the value to 0 for records of type
   EVENT_RECORD and START_RECORD, and set the value to 1 for the first
   INTERIM_RECORD, 2 for the second, and so on until the value for
   STOP_RECORD is one more than for the last INTERIM_RECORD.

Unfortunately, this ain't necessarily true.  Imagine an accounting
application that doesn't deal with user sessions, but instead reports data
on network conditions (say traffic volume) that is then used for making
admission control decisions.  "Sessions" are irrelevant & therefore, so is
Session-Id so we can pick any globally unique value.  Let's pick the MAC
address of the client.  Since sessions are irrelevant, so is session
lifetime so let's make sessions last forever.  Furthermore, we're reporting
instantaneous snapshots of network traffic, so it makes perfect sense to use
the Accounting-Record-Type of EVENT_RECORD.  We now have a situation where
_all_ the accounting requests have the same Accounting-Record-Number value
(0) and, although the Session-Id value is globally and eternally unique, the
combination of Accounting-Record-Number and Session-Id is not (I know that
this may sound contrived, but it's actually come up recently).  I'm pretty
sure this is legal because the definition of EVENT_RECORD says:

   An Accounting Event Record is used to indicate that a one-time
   event has occurred (meaning that the start and end of the event
   are simultaneous).  This record contains all information relevant
   to the service, and is the only record of the service.

Note the use of the word "service"; if it said "session", there would be no
problem (in this case), since that would force the change of the Session-Id
value after every EVENT_RECORD was sent, but it doesn't say "session"
(unlike the rest of the accounting record type definitions).  However, that
would basically outlaw more than one EVENT_RECORD from occurring in a single
session, which I believe was the intent of the original definition but isn't
particularly useful.  Instead, my proposal is to change section 9.8.3 to
say:

   The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32
   and identifies this record within one session.  The combination of the
   Session-Id and Accounting-Record-Number AVPs MUST be globally unique, 
   and can thus be used to match accounting records with confirmations.  
   Assuming that there is only one EVENT_RECORD per session, an easy way 
   to produce unique numbers is to set the value to 0 for records of type
   EVENT_RECORD and START_RECORD, and set the value to 1 for the first
   INTERIM_RECORD, 2 for the second, and so on until the value for
   STOP_RECORD is one more than for the last INTERIM_RECORD.

~gwz

Play assigns meaning to human activity--work erases it.
  -- P.L. Wilson