Subject: [AAA-WG]: draft-ietf-aaa-diameter-01 / 9.1 Device-Status-Ind

From: "Bob Kopacz" <[email-masked]>
Date: Wed, 28 Mar 2001 21:35:02 -0500

Hi Pat, 

Here's some comments on the DSI.

1. The DSI message needs to convey sufficient information so the
downstream peer can match it against some particular request/query,
for retransmission to an alternate destination.  So we might want to
add something like the following to the draft, right before the
Message Format (this is similar to a paragraph from the MRI
description):

    The Device-Status-Ind message MUST contain the same Hop-by-Hop
    Identifier value in the header as the message which motivated
    sending the DSI.  If the Session-Id AVP was present in the
    original message, the same AVP MUST be present in the DSI.

2. It doesn't seem to make sense to send a DSI for a (say,
undeliverable) Answer/Response, as the downstream peer couldn't
do anything useful with the DSI, and couldn't even match it with
anything as it contain someone else's hop-by-hop identifier.
Furthermore one wouldn't want to start a DSI-war by sending a
DSI in response to an undeliverable DSI or MRI, so (if this
makes sense) you might want to add another sentence like:

    The Device-Status-Ind message is only sent to indicate the
    status of a *-Request or *-Query message, and is not sent to
    indicate the status of a *-Answer, *-Response, or *-Ind message.

Bob K.

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 29 Mar 2001 16:43:20 -0800 (PST)

>     original message, the same AVP MUST be present in the DSI.

I completely agree, this text needs to be present.

>     indicate the status of a *-Answer, *-Response, or *-Ind message.

Two problems here:

1. Let's assume that a Session-Termination-Ind is sent, and it cannot be
delivered, your proposal would cause a silent discard, which is bad. BTW, if a
DSI is sent in response to an MRI, I don't see why the sender would insist on
sending ad nauseum, and create the war you've described above.

2. If an *-Answer of *-Response cannot be delivered, it MAY be useful to know,
since you would know that resources hadn't been allocated for the session.
However, I agree that such a message cannot really be sent to an alternate
peer. I guess what I'm saying is that I am not sure that a blanket statement
like this will work, but a blanket statement is MUCH better than a whole bunch
of special conditions.

PatC