RE: [Dime] AW: : RE: Conclusions on the draft "ResourceManagement Extensions"

A few quick questions/comments about this interesting draft:

1) 2.1
If there is no synchronization on client side, wouldn't using
Origin-State-Id AVP (RFC3588 8.16)solve the problem described in this
section? After failure/restart/takeover client can populate Origin-state-Id
AVP with a value bigger than the one used before the failure and server
should clean up previous sessions.

2) 2.1.1
SCTP multi-homing does not provide host redundancy -unless one has a
distributed SCTP implementation, which probably is not realistic or
something I would recomend to anybody-

3) 2.1.1
Is mentioning about IP address takeover really necessary? IMO, Diameter
entities are addressed by Diameter Identities, hence what is important is
that a backup assuming the identity of a failed active instance -which
doesn't require IP takeover-.

4) As a generic comment, I always thought this type of functionality is to
be addressed by specific applications themselves, e.g. DCCA, if there is
such a need.
Let's consider DCCA:
When there is an open session, client will send from time to time
CCR(Update) or CCR(Terminate), which would be replied with "DIAMETER UNKNOWN
SESSION ID", if server failed/restarted etc... and corresponding state did
not survive. Upon receipt of such an error answer, client can clean up its
own state for this session.
Similarly server can send RAR to client, if CCR(Update) is not received in a
timely manner. If state did not survive on client side after a failure,
client would reply with "DIAMETER UNKNOWN SESSION ID" and server can clean
up session state (Alternatively server may choose not to send RAR and may
abort the session)

AFAICS, for the above example, all cases are covered.

The question is, whose responsibility is that type of fucntionality, base
protocol or applications.

    Thanks,
    Tolga

> -----Original Message-----
> From: Tschofenig, Hannes [mailto:[email protected]]
> Sent: Wednesday, June 21, 2006 11:33 AM
> To: Bernard Aboba; Pat Calhoun (pacalhou)
> Cc: [email protected]; [email protected]
> Subject: [Dime] AW: [AAA-WG]: RE: Conclusions on the draft
> "ResourceManagement Extensions"
>
>
> Hi all,
>
> may I raise your attention to the following draft submitted for
> this meeting.
>
> Requirement for the addition of Auditing Functionality to Diameter
> http://psg.com/~avri/dime/draft-bodin-dime-auditing-reqs-00.txt
>
> Unfortunately, it did not yet show up.
>
> Ciao
> Hannes