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

From: Glen Zorn <[email-masked]>
Date: Sat, 04 Feb 2012 16:32:08 +0700

Returning to this (at last!)

On 8/30/2011 5:14 PM, jouni korhonen wrote:
> 
> On Aug 21, 2011, at 6:47 PM, Glen Zorn wrote:
> 
>> On 8/21/2011 10:28 PM, jouni korhonen wrote:
>>
>> ...
>>
>>>>> Hmm.. Any particular reason why NASREQ uses base app id for ACR/ACA and not base acct id?

Actually, I don't think that that is the problem: I believe that NASREQ
should use its own app ID in _all_ messages.

>>>>
>>>> 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.
>>>
>>> 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?
> 
> It seems to be the situations.. ;) Thus, fixing the above in RFC4005bis shouldn't then be an issue.
> 
> - Jouni
> 
> 
>>
>> ...
>

---

From: "dime issue tracker" <[email-masked]>
Date: Sat, 04 Feb 2012 11:57:38 -0000

#20: no accounting model specified

Changes (by gwz@…):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 I have made the following modification:

 OLD:

 1.3.  Advertising Application Support

    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].

 NEW:

 1.3.  Advertising Application Support

    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) message.

 1.4.  Application Identification

    The Auth-Application-Id AVP MUST be set to the value one (1) in the
    following messages

    o  AA-Request (Section 3.1)

    o  Re-Auth-Request(Section 3.3)

    o  Session-Termination-Request (Section 3.5)

    o  Abort-Session-Request (Section 3.7)

 1.5.  Accounting Model

    It is RECOMMENDED that the coupled accounting model (Section 9.3 of
    [I-D.ietf-dime-rfc3588bis]) be used with this application; therefore,
    the value of the Acct-Application-Id AVP in the Accounting-Request
    (Section 3.10) and Accounting-Answer (Section 3.9) messages SHOULD be
    set to one (1).

 I believe this fixes the problem.

-- 
--------------------------------+---------------------
 Reporter:  gwz@…               |       Owner:
     Type:  defect              |      Status:  closed
 Priority:  major               |   Milestone:
Component:  rfc4005bis          |     Version:
 Severity:  Active WG Document  |  Resolution:  fixed
 Keywords:                      |
--------------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/20#comment:1>
dime <http://tools.ietf.org/wg/dime/>