Subject: [Dime] rfc 4005 - issue #16

From: Glen Zorn <[email-masked]>
Date: Fri, 29 Apr 2011 12:45:59 +0700

Ticket #16 says:

> Section 3.9. Accounting-Request (ACR) Command
>
> "Either the Acct-Application-Id AVP or the Vendor-Specific-
> Application-Id AVP MUST be present."
>
> Mark Jones> I understand that the Acct-Application-Id is required for
> backwards compatibility (it is still redundant since the same app id is
> in the command header)

The Acct-Application-Id is redundant if it is assumed that the Diameter
header is available at every step in server processing, but there are
processing models in which the network headers are stripped after the
initial packet validation and the contents of the Diameter message (sans
header) are forwarded to other processing elements; in this case, the
Acct-Application-Id may be needed for internal message routing.  For
example, in a split accounting service different modules might process
accounting messages for different applications; the presence of the
Acct-Application-Id as an AVP in the body of the message allows this
without the overhead of carrying the Diameter header (most of which is
irrelevant in this usage) along for the ride.

> I
> but don't see why Vendor-Specific-Application-Id
> would ever need be present. The same comment applies to Section 3.10.

My understanding is that the accounting messages in RFC 4005 were
designed with re-usability in mind, possibly including reuse by
vendor-specific apps.

---

From: Stefan Winter <[email-masked]>
Date: Fri, 29 Apr 2011 13:48:45 +0200

Hi,

> header) are forwarded to other processing elements; in this case, [...]
[...] it is the implementation's very own problem if it can't maintain
state properly.

That's how I would have finished this sentence. A protocol's job is to
make sure that information can be transmitted from source to
destination. I don't see it as a protocol's job to make sure the
information is transmitted redundantly, just to support some
implementations that are programmed so that they forget aspects of the
transmission.

Requiring the redundancy in the protocol means that *every*
implementation has extra work, just to enable *some* implementations to
be lazy/badly programmed. I don't really fancy that.

>  the

*shrug* some of the info in the Diameter header is apparently of use.
How is "throwing it all away, and then demand protocol redundancy
because you've thrown away too much" a good approach?

Greetings,

Stefan Winter

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

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Glen Zorn <[email-masked]>
Date: Sat, 30 Apr 2011 13:04:01 +0700

> because you've thrown away too much" a good approach?

At one point in time there was this concept called "layering" that was
quite popular.  I guess it must be obsolete.