Subject: RE: [Dime] Acct-Application-Id value for NASREQ

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Fri, 22 Dec 2006 20:19:37 -0800

Victor Fajardo <mailto:[email-masked]> supposedly scribbled
on Friday, December 22, 2006 9:08 AM:

> Hi,
> 
> There maybe several points that needs clarification here. My
> historical understanding is that there is a relationship between
> auth-app-id and acct-app-id where the acct-app-id represents the
> accounting application that the auth application (auth-app-id) is
> using. So if an application supports accounting it would include an
> acct-app-id specifying what accounting application it uses and that
> id would be different from the app-id in the message header. 

OK, but I'm not sure where this understanding comes from or why it's not
reflected in the RFCs.  In fact, section 1.2.4 of RFC 3588 seems to
directly contradict this statement: 

   "If the base accounting is used without any mandatory AVPs, new
   commands or additional mechanisms (e.g., application defined state
   machine), then the base protocol defined standard accounting
   application Id (Section 2.4) MUST be used in ACR/ACA commands."

Please note that I am neither denying the existence of such a historical
understanding (I didn't pay any attention to Diameter after the first
couple of years for reasons that needn't be attended to here) nor
disagreeing that that is how it _should_ work.

> 
> The proposals in Sec 2.12 of the errata draft somewhat attempted to
> clarify such app-id assignments (auth-id and acct-id avps) without
> considering this relationship. During the last IETF, there was a
> consensus that at least for Sec 2.12, we should just explain this
> relationship even though most existing applications do not use it.
> This does not really do any harm, i.e. routing problems, since that
> will still be based on the app id of the header. Note that this
> should not be confused with Sec 2.8 of the errata which deals with
> session level messages and their app-id assignments. And the proposal
> on that issue states the use of app id of the application for the
> noted session level messages. 

Actually, I believe that the best thing to do would be to separate the
common application messages which are related to user sessions (ACR,
ACA, STR, STA, etc.) from the actual base protocol which deals with
peer-to-peer connections rather than user sessions, preferably in a new
document.  I think that that approach is much cleaner & more useful in
the long run than a piecemeal approach.  The drawback is that it would
probably mean recycling 3588 at PS rather than advancing to Draft
Standard.
    
...

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

---

From: Victor Fajardo <[email-masked]>
Date: Sat, 23 Dec 2006 09:44:07 -0500

Hi Glen,
> disagreeing that that is how it _should_ work.

Well ... most likely I may have mis-understood as well :) since I was 
basing it on the comments made during the last meeting, your probably 
the better person to clarify. Here's the meeting minutes snippet:

- Issue 13 [Duplication of App id in the header and App Id
            avps]
          
Lionel: The basic question is why do we need to have several
        app ids present in the message.
John: Need clarify text on why its there.
Glen: Fuzzy recollection on why there are two app ids
      present. The idea was that diameter applications would have
      accounting. So one of these ids where either accounting or nothing.
John: Need to do some forensic digging.
Victor: How will this affect routing
Glen: It really would'nt
John: Because you would be routing on the header and
      accounting would be in the body
Glen: But nowadays, virtually no applications include
      accounting so we can remove this feature.
John: What we can do is just put an explanation why we have
      to app ids. And as long as it does'nt do any harm then it should
      be ok.

> probably mean recycling 3588 at PS rather than advancing to Draft

Ok.

best regards,
victor