Subject: [AAA-WG]: Comments on sections 9-10 of draft-ietf-aaa-diameter-02.txt

From: "Martin Julien (ECE)" <[email-masked]>
Date: Mon, 23 Apr 2001 12:52:02 +0200

Hi Pat,

Some comments on sections 9 and 10 of the draft-ietf-aaa-diameter-02.txt document.

1) I would like to see the content of section 9 and 10 in the same section.
The way they are structured, it would be very easy to merge them and have
a nice introduction to error handling common to both.

2) In 9.1, the message format should also include [Session-ID]. And should the 
DSI-Event be in mandatory in the message, i.e. {}???

3) In 16.1, the Command AVP table says that the Destination-Realm AVP should
be included in the DSI message. So my question is whether or not the routing
table should be used for sending the DSI?, or should the reply IP address and
port be used instead? In fact, if the routing table is used, I guess that the
Destination-FQDN should be used instead, since the Route-Record AVP contains
the FQDN of the proxy, right? The FQDN routing would be more consistent with
the protocol I think.

4) In 16.1, the AVP Session-ID should be 0-1 in the DSI column.

5) In 9.1.1.2, replace "Redirect Notification" by "Redirect Event".

6) In 9.1.1.4, replace DIAMETER_INVALID_RECORD_ROUTE by DIAMETER_INVALID_ROUTE_RECORD.
Also, I think that this event should be in the Transient section, since the
permanent section defines events for which messages can be forwarded to another
node without any modification to its content, which I don't think can be possible
in this case.

7) In 9.1.1.4, replace DIAMETER_ERROR_TOO_BUSY by DIAMETER_TOO_BUSY.

8) In 9.1.1.4, what would be the difference between sending DIAMETER_TOO_BUSY
and DIAMETER_CANNOT_PROCESS_IN_TIME? I don't really see the point of making
a distinction between them.

9) In 10.1, [Error-Message] should be added. It should also appear in 16.1 as
0-1 in the MRI column.

10) In 10.1, [Failed-Vendor-Id] should be added.

11) In 10.1, the * [Destination-Realm], I guess that the * should be 
removed.

12) In 10.1, the {Destination-FQDN} should be added. In 16.1, it should
say 1 instead of 0+. BTW, what does it mean for the STR to have several
Destination-FQDN (as indicated by the 0+ in section 16.1).

13) In 10.1, the [Failed-AVP] should have *. In 16.1, it should be 0+.

14) In 10.1.1, the reference to the table should be to section 16.1,
instead of 14.0.

15) In 10.1.3, is it the Failed-Command-Code AVP or the Failed-Vendor-Id AVP?

16) There is no section 10.2.3, which means that section 10.2.4 should be 10.2.3.
The same applies for 10.2.5

17) In 10.2.4, I think that the DIAMETER_NO_END_2_END_SECURITY error should
be better named DIAMETER_END_2_END_SECURITY, since it indicates that e2e is
used, which is the problem.

18) In 10.2.5, under the description of the DIAMETER_LOOP_DETECTED error,
it says that no further attempts should be done until it is fixed. What is 
the intention behind that? How should it be handled?

19) In 10.4, I guess it should NOT be mandatory
in the MRI, since the Origin should be the default sender of the Result-Code.
It should be only be set if the Result-Code is modified by a node on the way.
16.1 should be modified to reflect 0-1 instead of 1.

20) In 10.4, the reference to the NAI should be replaced by the "FQDN".

Hope this helps,
Martin

---

From: Patrice Calhoun <[email-masked]>
Date: Tue, 24 Apr 2001 14:30:34 -0700 (PDT)

> a nice introduction to error handling common to both.

hmmm... anyone else?

> 
> 2) In 9.1, the message format should also include [Session-ID]. And should
> the  DSI-Event be in mandatory in the message, i.e. {}???

correct on both points.

> the FQDN of the proxy, right? The FQDN routing would be more consistent with

The DSI message MUST NOT include the Destination-FQDN AVP. This was a
cut-and-paste error. The message is hop-by-hop, as is the DRI, and is not
subjected to being proxied.

> 4) In 16.1, the AVP Session-ID should be 0-1 in the DSI column.

correct.

> 5) In 9.1.1.2, replace "Redirect Notification" by "Redirect Event".

ok

> 
> 6) In 9.1.1.4, replace DIAMETER_INVALID_RECORD_ROUTE by
> DIAMETER_INVALID_ROUTE_RECORD. Also, I think that this event should be in
> the Transient section, since the permanent section defines events for which
> messages can be forwarded to another node without any modification to its
> content, which I don't think can be possible in this case.

Well, how would the routes be modified? One is simply supposed to attached the
routes from the request into the response, so I don't understand what an
implementation could do to correct this error.

> 7) In 9.1.1.4, replace DIAMETER_ERROR_TOO_BUSY by DIAMETER_TOO_BUSY.

ok

> and  I don't really see the point of making

DIAMETER_TOO_BUSY - I cannot do this right now.
DIAMETER_CANNOT_PROCESS_IN_TIME - I've been working on it, and the timer
expired.

However, in reading the text, I see that the second use of the latter can be
confused with the too busy event. So, I will take that sentence and move it to
the too busy event.

> 9) In 10.1, [Error-Message] should be added. It should also appear in 16.1 as

ok

> 10) In 10.1, [Failed-Vendor-Id] should be added.

ok

> 11) In 10.1, the * [Destination-Realm], I guess that the * should be 

right.

> Destination-FQDN (as indicated by the 0+ in section 16.1).

done, and STR should be 0-1, not 0+.

> 13) In 10.1, the [Failed-AVP] should have *. In 16.1, it should be 0+.

Right, which re-enforces the previous comment that this really needs to be a
Grouped-AVP. I will also make this correction, otherwise multiple AVP, of
different vendors, would cause problems.

> 14) In 10.1.1, the reference to the table should be to section 16.1,

correct.

> 15) In 10.1.3, is it the Failed-Command-Code AVP or the Failed-Vendor-Id AVP?
See my comment in section 13.

>  16) There is no section 10.2.3, which means that section 10.2.4 should be
> 10.2.3. The same applies for 10.2.5

correct.

> used, which is the problem.

correct.

> the intention behind that? How should it be handled?

There are two fixes, one which entails that the request be sent to another
peer, which is not what the text intended here. What I meant was once the loop
was corrected. The loop most likely would exist due to some configuration
error, but the code would obviously not know when that would occur, so perhaps
that needs to be removed.

> It should be only be set if the Result-Code is modified by a node on the way.

That is what the text reads.

> 16.1 should be modified to reflect 0-1 instead of 1.

Only the node that created the MRI needs to worry about these rules, and
therefore it should be a 1. Intermediate proxies wouldn't add another
Result-Code AVP, and therefore this rule wouldn't apply.

> 20) In 10.4, the reference to the NAI should be replaced by the "FQDN".

thanks.

> Hope this helps,
More than you can imagine! I really appreciate the close read, and comments.

PatC