Subject: [AAA-WG]: [issue] Retain RADIUS attribute types for attributes 0-255

From: "Bob Kopacz" <[email-masked]>
Date: Tue, 18 Sep 2001 17:56:00 -0400

Submitter name: Bob Kopacz
Submitter email address: [email-masked]
Date first submitted: September 18, 2001
Reference: None
Document: draft-ietf-aaa-diameter-mobileip-07
Comment type: T
Priority: 1
Section: 7.1, 7.2, 7.4, 7.5
Rationale/Explanation of issue:

  The first 256 AVP numbers are reserved for compatibility with
  RADIUS.

  However, the type of four of them has been changed in the Diameter
  draft.  Accounting-Input-Octets, Accounting-Output-Octets,
  Accounting-Input-Packets, and Accounting-Output-Packets are AVPs in
  the RADIUS attribute space, but are 32-bit integers in RADIUS and
  64-bit integers in Diameter.

  This makes the dictionary implementation more difficult in servers
  that support both RADIUS and Diameter.

  For the first 256 attributes, we should retain full RADIUS 
  compatibility and retain the original RADIUS type.  If Diameter 
  applications want 64-bit integer counters, then create 
  Diameter-specific AVPs for them.

Requested change:

  (The AVP names are only a suggestion)

  Rename Accounting-Input-Octets as Accounting-Input-Extended-Octets,
  rename Accounting-Output-Octets as Accounting-Output-Extended-Octets,
  rename Accounting-Input-Packets as Accounting-Input-Extended-Packets,
  rename Accounting-Output-Packets as Accounting-Output-Extended-Packets,
  let their values be 64-bit integers,
  and assign them Diameter AVP numbers greater than 255.

---

From: "Kevin Purser" <[email-masked]>
Date: Tue, 18 Sep 2001 15:21:19 -0700

Related to this issue, a similar problem exists in the nasreq-07 spec.
However, while sections 8.1-8.5 indicate that the AVPs in question should be
Unsigned64, the table in section 2.2 indicates that they are in fact
Unsigned32.

Kev