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

From: "Fredrik Johansson" <[email-masked]>
Date: Wed, 11 Apr 2001 17:41:04 +0200

Hi,

Here are some comments on the new base protocol draft.

Section 1.0
last paragraph focussed -> focused

Section 2.0

"Four extensions to Diameter are defined by companion documents:
NASREQ [7], Mobile IP [10], Strong Security [11]. "

I can only see three :-) should Resource Management be added?

Section 2.3
"A Diameter extension is a
   specification that defines one or more Diameter Command-Codes, the
   expected AVPs in an ABNF [31] grammar (see section 3.2), and MAY also
   define new AVPs."

Does an extension really have to specify a Diameter Command-Code? So it's
not possible to define an extension which adds new AVPs to another
extension?

Section 5.0

Can't this section be incorporated in section 12 Message Routing?
B.T.W. why do we need both Origin-Realm and Origin-FQDN? Isn't this
redundant information?
Same applies to Destination-Realm and Destination-FQDN, or have I missed
some use here?

Section 8.0

"The stable states that a state machine may be in are Closed, I-Open
   and R-Open; all other states are intermediate. Note that I-Open and
   R-Open are equivalent except for whether the initiator or responder
   transport connection is used for communication."

If the two Open states are equivalent, why are not the transitions for these
states symetrical?

I-Open           Send-Message     I-Snd-Non-DRI    R-Open
should it really be R-Open or should it be I-Open

Section 9.0

The definition of downstream and upstream seems to be the oposite of how it
is used in this section

Section 10.0

A couple of questions on the table that I know should have come a long time
ago :-)

1. Why should you send a MRI on a unknown AVP but a DSI on an unknown
Command-code? Can it not be up to the sender to decide if it can send it
somewhere else or fix the problem in the case of an unknown AVP, i.e. you
could send a DSI it both cases. It's not up to the receiver to decide where
in the chain the problem occured.

2. Why have MRI at all, why not always let the previous node decide if it
can be fixed locally or if it should be forwarded another step down the
chain?

Section 12.1.1
There can be many servers to which a message can be proxied or redirected,
how should these be prioritised, or should you send to all of them :-)

          "3. REDIRECT - Diameter messages that fall within this
              category MUST have the identity of the home Diameter
              server(s) appended, and returned to the sender of the
              message. See section 12.3 for more information."

Is it really necessary to have the identity of the home Diameter server(s)?
Why not any next hop server?

12.3

"Successful routing table lookups will return one or more home
   Diameter servers that could satisfy the message. The home servers are
   encoded in one or more Redirect-Host AVPs, and the Command-Code field
   is set to Device-Status-Ind."

same here, why not just the next hop server instead of the home Diameter
servers?

Section 13.5
Session Records -> Accounting Records ?!?

Section 18
" - The fact that the Sender's IP Address is used in the
        construction of the Session-Id means that the introduction of
        Network Address Translation MAY cause two hosts to represent the
        same Session Identifier.  This area needs to be investigated
        further to be able to support Diameter hosts on a private
        network."

The Sender's IP Address is not used anymore, the FQDN is used instead so
this should not be an issue.

/Fredrik

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 26 Apr 2001 09:58:28 -0700 (PDT)

> I can only see three :-) 

:(

should Resource Management be added?

No since this is not a WG document, I don't want to list it in the base
protocol.
 
> not possible to define an extension which adds new AVPs to another

That was the agreement on the mailing list, if memory serves. You can still
write an I-D that defines ONLY AVPs, but it is NOT a protocol extension.

> Can't this section be incorporated in section 12 Message Routing?

Seems like this is the second time this comes up. Anyone else?

> Same applies to Destination-Realm and Destination-FQDN, or have I missed

Unless you want to write the algorithm to extract the realm from the FQDN,
then no. Further, this reduces the amount of work at each proxy that would
otherwise have to extract domains from AVPs. This is just so much more
convenient.

> If the two Open states are equivalent, why are not the transitions for these

Sorry, I appear to be a little slow because I don't *quite* catch what you
mean without lots of personal interpretation. Please re-phrase.

> should it really be R-Open or should it be I-Open

I-Open, and it has been fixed.

> The definition of downstream and upstream seems to be the oposite of how it

This has been brought up, and will be fixed in -03.

> Command-code? 

Because the former is a protocol error, while the latter is simply that the
command is not locally supported, and the proxy can forward the request to
another peer, if possible.

> Can it not be up to the sender to decide if it can send it

But a DSI for the former would force the proxy to start stripping AVPs, which
the originator of the message MAY believe is important. 

> can be fixed locally or if it should be forwarded another step down the

There are some errors that proxies should not bother attempting to fix, IMHO.

> Why not any next hop server?

Because a redirect implies that the message is being sent directly to the peer
that can handle the request, no?

> same here, why not just the next hop server instead of the home Diameter

See above. Perhaps redirects can be used in other cases, but I would prefer to
restrict its usage to simplify the text. If you want to abuse redirect servers
in your implementation, I cannot stop you :)

> Session Records -> Accounting Records ?!?

that would make sense.

> this should not be an issue.

ok. should we also just delete the open issue on time AVPs, since this problem
would exist with any protocol that uses NTP time?

PatC