Subject: [HOKEY] Separate local ER server from Diameter proxy [Hokey minutes]

From: Qin Wu <[email-masked]>
Date: Tue, 15 Dec 2009 18:50:12 +0800

Hi, Tom and all:
In order to and better deployment scalability, I agree it is not necessary 
to assume that the Hokey server and AAA servers or proxies are collocated

Please see my followup comments inline.

Regards!
-Qin
----- Original Message ----- 
From: "Tom Taylor" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, November 12, 2009 12:57 PM
Subject: [HOKEY] Hokey minutes

I wonder if I could offer an alternative to the meeting notes for my portion of 
the meeting. I am talking about the presentation:

"5.Second presentation – Tom Taylor: Can a Local ERP Server be separated from a 
Diameter Proxy?"

As a preliminary: the first entry under that heading belongs to the previous 
presentation. That is, move the following bullet up:

"- open Questions: additional architecture goals, local Domain Name Discovery, 
ERP capability discovery."

Following is my alternative text for this part of the session, based on 
Dorothy's notes and my own memory.

"5.Second presentation – Tom Taylor: Can a Local ERP Server be separated from a 
Diameter Proxy?

See slides for this presentation at 
http://www.ietf.org/proceedings/09nov/slides/hokey-4.pdf. In summary, these 
slides begin with one showing functional components and potential interfaces to 
the local ERP server. The remaining slides show
  - information flow requirements during the initial authentication phase
  - possible solutions (three alternatives) to achieve this flow

[Qin]: In the three alternatives your proposed, It seems to me the third alternative may be more appropriate.
In the first alternative where the standalone local ER server is not on the path, the authenticator did't need DSRK. why the authenticator request DSRK on behalf  of local ER server? Also in this case, it seems to require the authenticator to support ER funcationality.
In the second alternative, although it is consist with RFC5296, more signaling overhead is required to make local ER server know DSRK.
In contrast with the first two alternatives, the third alternative is more reasonable. because what we need in this case is to trigger local ER server to request DSRK.

  - information flow requirements during the re-authentication phase
  - possible solutions for this phase.

Qin Wu sought clarification of the point about need for a "correlator", 
mentioned on the first information flow slide. 

[Qin]: If we understand correlator as "NAI", I am afraid maybe you mix hokey authorization with DSRK request.
In order to request DSRK, what the local ER server need to do is send local domain name to the home server.
why we need to associate NAI with DSRK? Just for authorization on whether the local ER server is allowed to obtain DSRK?
Would you like to clarify this?