Subject: [Dime] Errata #1946

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 11 May 2010 12:15:40 +0200

DIME WG,

Please issue a recommendation concerning errata #1946 (related to RFC
4005)

Dan

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 13 May 2010 11:35:05 +0700

> Please issue a recommendation concerning errata #1946 (related to RFC

While the original text is certainly misleading at best, the new text is not
a lot better since is leaves out the Accounting-Input-Packets and
Accounting-Output-Packets AVPs.  I think that a better correction would be
something like this:

   If the Accounting-Input-Octets, Accounting-Input-Packets,
   Accounting-Output-Octets, or Accounting-Output-Packets AVPs are
   present, they SHOULD be translated to the corresponding RADIUS
   attributes.  However, if the value of the Accounting-Input-Octets AVP
   or Accounting-Output-Octets AVP does not fit
   within a 32-bit RADIUS attribute, the RADIUS Acct-Input-
   Gigawords and Acct-Output-Gigawords Attributes must be used.

> 
> Dan
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 13 May 2010 08:56:14 +0200

This looks good to me. 

Other opinions? 

Dan

> -----Original Message-----
> From: Glen Zorn [mailto:[email-masked]] 
> Sent: Thursday, May 13, 2010 7:35 AM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: RE: [Dime] Errata #1946
> 
> While the original text is certainly misleading at best, the 
> new text is not a lot better since is leaves out the 
> Accounting-Input-Packets and Accounting-Output-Packets AVPs.  
> I think that a better correction would be something like this:
>

---

From: David Mitton <[email-masked]>
Date: Thu, 13 May 2010 23:35:04 -0400

I don't think the original text is misleading, just incomplete.

There are two parts here.
1) All 4 Diameter AVPs must be translated into the corresponding 4 
RADIUS attributes.
2) If the Diameter Octets attributes values are greater than 32-bits 
in magnitude, the higher order value must be mapped into the 
additional Gigaword attributes.  What's not stated is, unfortunately 
there are only RADIUS Gigaword Attributes for Octets and not Packets.

Avi's correction fixes the wrong problem, by leaving out the Packets 
translation.
Glen's correction leaves that in, and makes the Gigaword translation 
cases explicit and for that reason is more complete.  One could go a 
step further and point out that there is no RADIUS Acct attribute 
that can carry the full potential 64-bit value of Diameter AVPs 
Accounting-Input-Packets or Accounting-Input-Packets.

Dave.

---

From: Avi Lior <[email-masked]>
Date: Tue, 25 May 2010 15:04:23 -0400

I agree.  Glen's text does improve my text and makes a suggestion that needs to be added as well....

>>   Gigawords and Acct-Output-Gigawords Attributes must be used.
Add the following:
Care must be taken when interworking Diameter with RADIUS due to the fact that there is no attribute available in RADIUS to record overflows in packet counters.  One remedy that can be used is to limit the session time such that packet counter do not overflow.  Another remedy would be to ignore the packet counters altogether and just rely on the octet counters.

End of change

Limiting the session-timer will cause re-authentication.  But re-authentication does not necessarily mean a new accounting session right?

Another possible change would be that the NAS starts another accounting session when it reaches packet counter limits but how do we do that.

I think in reality packet counters are probably not used.

>>   Gigawords and Acct-Output-Gigawords Attributes must be used.

Avi Lior
[email-masked]
office: +1 613-591-9104x6417
    cell: +1 613-796-4183