Subject: [Dime] rfc3588bis next revision; was Re: [dime] #20: no accounting model specified

From: jouni korhonen <[email-masked]>
Date: Fri, 19 Aug 2011 15:56:05 +0300

On Apr 29, 2011, at 9:47 AM, dime issue tracker wrote:

> #20: no accounting model specified
> 
> RFC 3588bis says in Section 9.3 that
> 
>    Applications have the option of using one or both of the following
>    accounting application extension models:
> 
>    Split Accounting Service
> 
>       The accounting message will carry the Application Id of the
>       Diameter base accounting application (see Section 2.4).
>       Accounting messages maybe routed to Diameter nodes other than the
>       corresponding Diameter application.  These nodes might be
>       centralized accounting servers that provide accounting service for
>       multiple different Diameter applications.  These nodes MUST
>       advertise the Diameter base accounting Application Id during
>       capabilities exchange.
> 
> 
>    Coupled Accounting Service
> 
>       The accounting messages will carry the Application Id of the
>       application that is using it.  The application itself will process
>       the received accounting records or forward them to an accounting
>       server.  There is no accounting application advertisement required
>       during capabilities exchange and the accounting messages will be
>       routed the same as any of the other application messages.
> 
> However, RFC 4005 uses neither of these models, specifying that
> 
> Diameter applications conforming to this specification MUST advertise
>    support by including the value of one (1) in the Auth-Application-Id
>    of the Capabilities-Exchange-Request (CER), AA-Request (AAR), and AA-
>    Answer (AAA) messages.  All other messages use the Base application
>    id value [I-D.ietf-dime-rfc3588bis].
> 
> This seems incorrect.

Hmm.. how? RFC4005(bis) text to me refers to the split service.. NASREQ App-Id is used for AAR/AAA and base accounting for the rest (ACR/ACA...).

- JOuni

> 
> -- 
> --------------------------------+-------------------------------------------
> Reporter:  gwz@…               |       Owner:     
>     Type:  defect              |      Status:  new
> Priority:  major               |   Milestone:     
> Component:  rfc4005bis          |     Version:     
> Severity:  Active WG Document  |    Keywords:     
> --------------------------------+-------------------------------------------
> 
> Ticket URL: <https://wiki.tools.ietf.org/wg/dime/trac/ticket/20>
> dime <http://tools.ietf.org/wg/dime/>
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Glen Zorn <[email-masked]>
Date: Sat, 20 Aug 2011 15:47:13 +0700

> Hmm.. how? RFC4005(bis) text to me refers to the split service.. NASREQ App-Id is used for AAR/AAA and base accounting for the rest
(ACR/ACA...).

No, 4005 does not say "the Diameter Base Accounting ID", it says "the
Base application id"; they are different things.  Actually, it would be
inappropriate to use the base accounting ID for the rest, since the rest
includes the STR/STA & ASR/ASA messages, which are not accounting messages.

...

---

From: jouni korhonen <[email-masked]>
Date: Sat, 20 Aug 2011 21:49:32 +0300

On Aug 20, 2011, at 11:47 AM, Glen Zorn wrote:

[clip]

> Base application id"; they are different things.  Actually, it would be

Hmm.. Any particular reason why NASREQ uses base app id for ACR/ACA and not base acct id?

> includes the STR/STA & ASR/ASA messages, which are not accounting messages.

Righty.

....

---

From: Glen Zorn <[email-masked]>
Date: Sun, 21 Aug 2011 15:43:58 +0700

On 8/21/2011 1:49 AM, jouni korhonen wrote:

...

> Hmm.. Any particular reason why NASREQ uses base app id for ACR/ACA and not base acct id?

I think that it is an error in 4005.  Actually, I find it hard to
believe that NASREQ would ever work except in a monolithic, "toy"
implementation.  For example, the NASREQ version of the ASR/ASA messages
includes a bunch of optional AVPs (with the 'M' bit set) that are
undefined in RFC 3588 to the base protocol server; it's hard to imagine
how a standard implementation of 3588 could not treat the reception of
such AVPs as an error.

...

---

From: jouni korhonen <[email-masked]>
Date: Sun, 21 Aug 2011 18:28:34 +0300

> how a standard implementation of 3588 could not treat the reception of

MAybe this is then good candidates to be fixed in 4005bis? Or do you think it would make situation worse in real deployments from a backward compatibility point of view?

- Jouni

---

From: Glen Zorn <[email-masked]>
Date: Sun, 21 Aug 2011 22:47:40 +0700

On 8/21/2011 10:28 PM, jouni korhonen wrote:

...

> MAybe this is then good candidates to be fixed in 4005bis? Or do you think it would make situation worse in real deployments from a backward compatibility point of view?

I was under the impression that there are no real deployments; if there
were, someone would certainly have noticed this, don't you think?

...

---

From: jouni korhonen <[email-masked]>
Date: Tue, 30 Aug 2011 13:14:30 +0300

> were, someone would certainly have noticed this, don't you think?

It seems to be the situations.. ;) Thus, fixing the above in RFC4005bis shouldn't then be an issue.

- Jouni