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

From: "Martin Julien (ECE)" <[email-masked]>
Date: Wed, 25 Apr 2001 09:16:18 +0200

Hi Pat,

Thanks for your answers.
See my comments enclosed.

BR,
Martin

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

My point was that we do not need the Destination-Realm AVP, since it
is a message sent only to the next downstream hop. Then, it is 
precisely the role of the Destination-FQDN AVP to direct a message
to a next hop server, since it is used for routing only if it can
be contacted directly from a Diameter node, right? Anyway, the thing
is that it was not clear if any Destination-XXXX AVP at all were 
required?

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

If I understand correctly, this check is only performed
for request/query/indication messages, since it is the
responsibility of the previous hop to add the route-record
and the one of the actual node to validate the information.
For answer/response messages, the only check that is required
is to check if the route-recoud matches the local node.

So, I don't know either what the implementation can do about
it?, and I don't understand neither why the downstream server
should try to re-route the message to another node, as it
is suggested in the DSI-permanent DSI-event. I guess you are
suggesting to re-try other upstream servers until one understand 
the match between the Route-Record and the sending IP address?
That would mean that one of the upstream servers is badly
configured. Maybe that would make sense?

The change of name was due to the fact that Record-Route
should be Route-Record instead, just as described by the AVP.

> > 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.
> 
> That is what the text reads.

Yes, but the message format in 10.1 makes it required {}. It 
should then be [] instead.

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

Same as before, if it is not modified by any proxy servers on the
way, then I guess this AVP should not be included in the message, right?

---

From: Patrice Calhoun <[email-masked]>
Date: Wed, 25 Apr 2001 06:31:04 -0700 (PDT)

> is that it was not clear if any Destination-XXXX AVP at all were 

OOps. I meant to say Destination-Realm, not Destination-FQDN. You are correct
that the *-FQDN is used for hop-by-hop forwarding. The Destination-Realm MUST
NOT be present. However, since this message is NOT proxiable, it is
questionable whether the Destionation-FQDN is really needed at all, since a
Diameter node will create and forward the message to its peer.

However, the presence of the Destination-FQDN could be useful for
implementations when they want to figure out whether they should consume the
message locally or not. That said, a DSI is always consumed locally.

So, I suppose it doesn't really need to be present in the packet.

> is to check if the route-recoud matches the local node.

hmmm... again I misread the question... sorry, my brain was apparently not
fully functional yesterday :(

> configured. Maybe that would make sense?

That is correct. When receiving such an error, another server could be tried.
I will clean up the text to make this more obvious to the reader.

> should be Route-Record instead, just as described by the AVP.

Right, I had missed that one in -02 :(

> should then be [] instead.

Sorry, could you please provide more info. I seem to be missing the problem
(see above on my issue with my non-functional brain :(

> way, then I guess this AVP should not be included in the message, right?

Again, I am confused. You seem to imply that a proxy that receives the MRI
must add the Result-Code AVP, when in fact they should only worry about
proxying the message.

Is there text anywhere that caused this confusion? 

PatC