Subject: [Dime] Comment on rfc3588bis ACR definition

From: "Daily William" <[email-masked]>
Date: Wed, 13 Jun 2007 11:48:13 -0400

Dear Victor Fajardo,

First, thank you for all your efforts in shepherding the rfc3588 bis
project and please excuse me for not making this observation earlier.

I would like to ask about an apparent inconsistency in the rfc3855bis,
which also happens to exist in the original RFC 3588.  

For reference, I have included the definition of the Account-Request
ABNF in section 9.7.1 is as follows:

         <ACR> ::= < Diameter Header: 271, REQ, PXY >
                   < Session-Id >
                   { Origin-Host }
                   { Origin-Realm }
                   { Destination-Realm }
                   { Accounting-Record-Type }
                   { Accounting-Record-Number }
                   [ Acct-Application-Id ]
                   [ Vendor-Specific-Application-Id ]
                   [ User-Name ]
                   [ Accounting-Sub-Session-Id ]
                   [ Acct-Session-Id ]
                   [ Acct-Multi-Session-Id ]
                   [ Acct-Interim-Interval ]
                   [ Accounting-Realtime-Required ]
                   [ Origin-State-Id ]
                   [ Event-Timestamp ]
                 * [ Proxy-Info ]
                 * [ Route-Record ]
                 * [ AVP ]

The AVP table for ACR from section 10.2 includes an entry for the AVP
Destination-Host and states that zero or one occurrence for ACR is
supported, however the ABNF for the ACR message does not include the
same AVP as optional.  Likewise the AVP Terminate-Cause is also listed
in the table from 10.2 as 0-1 and it does not appear in the ABNF for
neither ACR nor ACA.

Would you consider this correct?  Perhaps someone could provide some
clarification? 

For what it is worth I would like to propose that the ABNF for ACR and
ACA be updated to be consistent with the table.  I believe
Destination-Host is a useful AVP when the Accounting session extends
over several Diameter transactions.  Adding it as an optional AVP would
be backward compatible and consistent with the original specification
because ACR and ACA includes the any AVP syntax (*[AVP]).

Best regards,

Bill Daily
Comverse, Inc;

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

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 13 Jun 2007 12:16:21 -0400

Hi Daily,

> over several Diameter transactions.  Adding it as an optional AVP 
> would be backward compatible and consistent with the original 
> specification because ACR and ACA includes the any AVP syntax (*[AVP]).
>

Thanks for noticing this. For Destination-Host, the AVP should be added 
as an optional to the ABNF of ACR. For Terminate-Cause, this maybe tied 
to STRs more than anything else so it might best just to fix the 
occurrence table in this case.

regards,
victor

---

From: "Daily William" <[email-masked]>
Date: Wed, 13 Jun 2007 12:41:52 -0400

Hi Victor,

I am glad you agree that the Destination-Host AVP should be added to the
ABNF for ACR.  I believe that this is quite useful.

For the Terminate-Cause AVP I have no real opinion about the nature of
this AVP and defer to your suggestion to update the table.  

I would, however, like to make the following observation.  I think that
it is reasonable for accounting systems to capture session information
similar to the cause of termination in call records, along with lots of
other data.  As an example, the 3GPP Accounting application solves this
with the use of Vender specific AVPs. 

So, perhaps, this is the best practice going forward and tends to
support the suggestion that there is no need for the Termination-Cause
AVP in ACR.

Many thanks,

Bill

-----Original Message-----
From: Victor Fajardo [mailto:[email-masked]] 
Sent: Wednesday, June 13, 2007 12:16 PM
To: Daily William
Cc: [email-masked]
Subject: Re: [Dime] Comment on rfc3588bis ACR definition

Hi Daily,

regards,
victor