Subject: [Dime] draft-ietf-dime-realm-based-redirect-04

From: Tom Taylor <[email-masked]>
Date: Tue, 10 Jan 2012 23:08:20 -0500

I have awakened from my long sleep and updated 
draft-ietf-dime-realm-based-redirect in response to the various WGLC 
comments. These were recorded in tickets 1, 4, 5, 6, and 11, which can 
be retrieved using the query

http://trac.tools.ietf.org/wg/dime/trac/query?status=new&status=assigned&status=reopened&component=realm-based-redirect

The update has been submitted, but obviously is subject to change if 
people don't agree with my responses. The behaviour sections were 
extensively rewritten.

Ticket #1
=========

Comment: Add a more direct pointer to the "normal discovery procedures" 
mentioned in Section 3.1.2.

Response: Added a reference to Section 5.2 of RFC 3588.

Ticket # 4
==========

Comment: (3.1.1) Missing word: Furthermore, the redirect agent MUST ^ a 
Redirect-Realm AVP

Response: added "include"

Comment: (3.1.1) If the the other peer advertised the Relay application, 
should the redirect agent consider that it supports the Redirect-Realm 
application?

Response: text modified to talk about application support rather than 
peer capabilities (as suggested by Ticket #11).

Comment: (3.1.1) "the message MUST include the Error-Reporting-Host AVP 
if the host setting the Result-Code AVP is different from the identity 
encoded in the Origin-Host AVP,"

==> IIUC this is an impossible situation, since the Redirect Agent did 
not forward the Request. I believe this text could be removed for clarity.

Response: text removed.

Comment: (3.1.2)

==> What if the original request contains a Destination-Host AVP? In 
that case, should a UNABLE_TO_DELIVER error be returned? There is 
probably no point in sending to the alternate realm with a 
Destination-Host in the previous realm, right? Unless maybe if the 
Destination-Realm of the request message does not match the Origin-Realm 
of the Redirect indication (change of broker for example). Any opinion?

Response: the reasonable action is to strip out the original 
Destination-Host and Destination-Realm AVPs and add a new 
Destination-Realm AVP with the realm identifier taken from the 
Redirect-Realm AVP. Of course, this is going to cause a glitch if the 
request was part of a stateful session. Text added to indicate the 
action and note the consequence as an operational matter.

Comment: (3.2)

==> This section does not give the value of the M flag for the new AVP. 
By the semantics of the application, I believe the M flag should be set, 
right?

Response: text added to indicate the setting of the M flag.

Ticket #5
=========

Comment: Section 2:

     o I really want to see RFC2119 language here. Preferable a MUST 
saying what the application developer has to do.

Response: rewritten to say that support for realm-based redirection MUST 
be embedded in particular applications.

Comment: Section 3.1.1

     o I would use some other wording than "home server".. just use "server"

Response: done.

Comments: Section 3.1.1

     o second bullet: "..redirect agent MUST a Redirect-Realm AVP 
containing.." I assume a verb is missing here.

     o second bullet: the proposed use of Error-Reporting-Host AVP does 
not make sense to me. At least it is different from what RFC3588 Section 
7.1 describes and I don't see a reason why it should do so. My 
understanding is that DIAMETER_REALM_REDIRECT_IDENTICATION works in the 
same way as DIAMETER_REDIRECT_IDENTICATION.

Response: also on ticket #4. Fixed.

Comment: Section 3.1.2

     o What are the cases when SHOULD does not apply here? I mean, why 
these SHOULDs are not MUSTs ?

Response: section rewritten, new actions are all MUST.

Comment: Section 3.2

     o s/Redirect- Max-/Redirect-Max

Response: fixed.

Comment: Section 3.1.1 again [some prologue omitted]
... Based on this, the enhanced realm-based redirection functionality 
can be added to _some_ redirect agent that then need to peek into 
request content to find out that the application supports redirection.. 
This might be an issue since now the realm-based redirection enhanced 
redirect agent may or may not be aware of all applications that support 
the mechanism described in this specification.

     o I would like to see some more text around the expected behavior 
_within_ the redirect agent.

     o I would also like to see some more text around the limitations on 
the application based "recognition" of the realm-based redirect 
functionality. Defining a new application does not imply all realm-based 
redirect agents would automatically know about it.

     o This brings realm-based redirect agent to same application 
updating issues as proxies have. Add some text around this.

Response: I don't see this as a serious issue because the typical 
scenario for deployment of a realm-based redirect agent is on an ad hoc 
basis for specific applications that are being diverted. Hence the agent 
will be configured with the necessary applications, and will take more 
conventional actions for any other applications. Some text added in 
section 2 to make your point.

Ticket #6
=========

Comment: [text omitted]
... This new redirect agent has to differentiate between applications 
that do support realm base redirection vs non-realmbased redirection.

This is new base behavior and thus should be done in Diameter V2

There is an alternative - which i thought was the approach taken when i 
started to read the draft and that is:

-let the Application itself perform the redirection. To use the example 
provided, if the operator does not want to host the application anymore, 
it can let the Application respond back with the realm and/host 
redirection attributes.

Response: presumably you are saying that the redirection should be done 
by the server or possibly a proxy. This doesn't seem to be a problem, if 
the WG prefers to go this way. No action taken pending WG consensus.

Ticket #11
==========

Comment: (3.1.1)    "If the peer from which the request was received did 
not advertise an application incorporating the realm-based routing 
capability in the CER/CEA exchange, the redirect agent SHOULD set the 
'E' bit in the answer and set the Result Code to 
DIAMETER_UNABLE_TO_DELIVER. As an alternative, the redirect agent MAY if 
so configured provide a host-based redirect as described in Section 
6.1.7 of [RFC3588]."

==> This last sentence assumes both types of redirection information can 
be provisioned in the Redirect Agent. Should we allow such a 
configuration? If so, how does the Redirect Agent know what information 
should be used when the originator of the request support both 
redirection indication mechanisms (i.e. priority, order, etc.)?

Response: deleted the alternative.

Comment: (3.1.1) "Otherwise, if an application supporting the use of 
realm-based redirection was negotiated with the peer..."

     Otherwise, if the request is for an application supporting 
realm-based redirection,

Response: modified text as suggested.

Comment: (3.1.1) missing "include", incorrect addition of 
Error-Reporting -Host (covered by other tickets)

Response: fixed.

Comment:  (3.1.1)   "All other aspects of Section 6.1.7 remain the same 
as for host-based redirection."

==> the use of Redirect-Host-usage AVP and Redirect-Max-Cache-Time AVP 
is not exactly the same; Both are related to the Redirect-Host AVP that 
can be found in the answer. In the Realm-based redirection, these AVPs 
have to be associated with the peer resulting of the realm-based 
discovery mechanism, as described in section 3.2. This should be also 
clarified at this stage.

Response: text added to this effect.

Comment: (3.1.2)     "The receiving Diameter node SHOULD update its 
cache of routing entries according to the direction provided by the 
Redirect-Max- Cache-Time AVP, if present. The cache entry SHOULD be 
associated with a redirect usage of REALM_AND_APPLICATION."

==> RFC3588 says that the Redirect-Max-Cache-Time AVP and 
Redirect-Host-Usage AVP is associated with the redirect-host AVP. Here, 
the use of this AVP are modified/enhanced to be associated with the peer 
discovered based on the Realm-based redirection.

Response: new text makes this clear.

Comment: (3.2)     "Section 6.14 of [RFC3588] is modified to permit the 
Redirect- Max- Cache-Time AVP to be used also to specify the persistence 
of cache entries created by the Redirect-Realm AVP."

==> the same kind of information should be present for the use of 
Redirect-Host-Usage AVP.

Response: text moved to an earlier section where it seemed more 
appropriate. Text added to cover Redirect-Host-Usage.