Subject: RE: [AAA-WG]: Accouting AVP issue...

From: <[email-masked]>
Date: Fri, 22 Feb 2002 15:32:44 +0200

Hi all, 

> A few revisions ago, the base included the accounting AVPs. An issue 
> vwas created by Glen Zorn, and with WG concensus the AVPs were moved 
> to the application specs. 
> If we want to now go back in time, we should go back and understand 
> the original reasoning for moving the AVPs to the application specs. 

I'm going to side with Pat on this.  I think we can forever go back
and forth, and get nowhere.  Let's keep the current text/solution.

John

---

From: David Spence <[email-masked]>
Date: Mon, 25 Feb 2002 18:00:04 -0500

Well, this is a jolly good time to be having philosophic discussions.  But
here goes...

O.K.  We decided to define the acounting AVPs in the applications.  But we
also decided that if an application could reuse an existing AVP, it should. 
As sec 2.3.1 of Base-08 says:

   New applications should attempt to reuse AVPs defined in existing
   application when possible, as opposed to creating a new AVP.

So perhaps one of the applications should define the five overlapping AVPs
and the other should reference them.  Defining them in multiple places
creates inconsistencies.  How could that possibly happen, you ask, in this
age of cut and paste?  Well, believe it or not, it already has happened. 
Compare the definition of Accounting-Input-Extended-Octets in MIP with that
in NASREQ:

MIP:

7.1  Accounting-Input-Extended-Octets AVP

   The Accounting-Input-Extended-Octets AVP (AVP Code 363) is of type
   Unsigned64, and contains the number of octets in IP packets received
   from the user.

NASREQ:

8.1  Accounting-Input-Extended-Octets AVP

   The Accounting-Input-Extended-Octets AVP (AVP Code 363) is of type
   Unsigned64, and contains the number of octets in IP packets received
   by the user.

"from the user" or "by the user"?  MIP is right, in this case; NASREQ is
wrong.  The definition of Accounting-Input-Extended-Packets has the same
problem.

Now one may argue that different applications may have to define how they
use an AVP.  This really would be a good argument for saying something about
the AVP in two places.  But the definition, at least should be word-for-word
the same.

Well it just happens that these particular AVPs are good examples of where
each application might indicate how it does use them.  For instance when a
NAS counts input octets, where and how does it count them?  The answer is
not at all obvious to me from reading the above definition.  Does a NAS, for
instance, count on the user port side or on the network side.  On the user
side, we do PPP, so do we count the PPP header octets?  Well at least, you
say, counting the octets in the layer 3 packet is easy.  Oh, yeah?  Well
what if the PPP link uses Van Jacobson compression?  Then the number of IP
and TCP header octets counted on the user side is different than on the
network side.  And what about fragmentation?  And what about framing
characters used on asynchronous lines?  And on, and on, and on.

So I ask myself, "Could RADIUS really have been as sloppy as that?"  The
answer is no, it wasn't.  RADIUS is much less vague.  RADIUS defines its
Acct-Input-Octets attribute as follows:

      This attribute indicates how many octets have been received from
      the port over the course of this service being provided, and can
      only be present in Accounting-Request records where the Acct-
      Status-Type is set to Stop.

RADIUS says to count the octets as they're received over the port.  Thus the
count would include the PPP header but not the octets saved due to Van
Jacobson compression.  But somehow we lost that in the Diameter NASREQ
draft.

So, after all this rambling, I suggest the following:

1) Both MIP and NASREQ should define the AVPs.

2) Both drafts should contain the verbatim text that is now in MIP
   (not the erroneous text that is now in NASREQ).

3) The NASREQ draft should contain additional NASREQ usage instructions 
   copied verbatim from RADIUS except for the part about only being present 
   in stop records, which is no longer true.]

4) The MIP editor may want to consider adding usage instructions as well.

5) The word Extended should be removed from from the attribute names.  The
   difference between the Acct- prefix and the Accounting- prefix can 
   distinguish the RADIUS attributes from the Diameter attributes.  Also 
   the AVP codes are different -- 363-366 for the Diameter AVPs.

6) The Accounting-Session-Time AVP should be renamed to Acct-Session-Time
   for compatibility with RADIUS because it shares the RADIUS AVP Code of
   46.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Feb 2002 09:56:39 +0200

David Spence wrote:

> ...
> (proposal)

Ok.

Jari