Subject: [Dime] I-D Action: draft-ietf-dime-realm-based-redirect-06.txt

From: [email-masked]
Date: Thu, 23 Aug 2012 16:24:56 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF.

	Title           : Realm-Based Redirection In Diameter
	Author(s)       : Tina Tsou
                          Ruibing Hao
                          Tom Taylor
	Filename        : draft-ietf-dime-realm-based-redirect-06.txt
	Pages           : 8
	Date            : 2012-08-23

Abstract:
   The Diameter protocol allows a Diameter redirect agent to specify one
   or more individual hosts to which a Diameter message may be
   redirected by an upstream Diameter node.  However, in some
   circumstances an operator may wish to redirect messages to an
   alternate domain without specifying individual hosts.  This document
   specifies a mechanism by which this can be achieved.  New
   applications may incorporate this capability by reference to the
   present document.

   This memo updates Sections 6.13 and 6.14 of RFC3588bis with respect
   to the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time
   AVPs.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dime-realm-based-redirect

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dime-realm-based-redirect-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-realm-based-redirect-06

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tom Taylor <[email-masked]>
Date: Thu, 23 Aug 2012 20:09:00 -0400

The draft has been updated primarily based on comments from Jouni and 
Lionel. Changes:

- Updates RFC3588bis

- Paragraph adding to the Abstract saying the same thing, and giving 
more details.

- Placed the statement that application designers could decide whether 
realm-based redirection applies to the first or to all requests of a 
session into Section 2, "Support of Realm-Based Redirection Within 
Applications".

- In the introductory part of Section 3, noted the extension of 
behaviour with respect to the Redirect-Host-Usage and 
Redirect-Max-Cache-Time AVPs.

- Also in the introductory part, noted that the caching of new routes at 
a proxy or client means that the alternative routing persists for 
subsequent requests until the cache entry times out, with implications 
for use of realm-based routing on a temporary basis.

- In Section 3.2.1, "Behaviour at the Redirecting Server", deleted the 
bullet saying that a request with a Destination-Host AVP should be 
rejected with UNABLE_TO_DELIVER. Added an informational note that the 
Destination-Host AVP would be ignored. My reasoning was that if the 
application specifies that realm-based redirection applies to all 
requests and not just the first request of a session, then that is what 
should happen.

- In Section 3.2.2, "Proxy Behaviour", added a note that instead of 
attempting to reroute the request, the proxy could just forward the 
answer to the upstream peer.

- In the same section, got rid of the bullet calling for verification of 
the alternate realm, given that this happens implicitly when the proxy 
connects with a peer in that realm.

- In Section 3.2.3, "Client Behaviour", got rid of similar text about 
verifying the alternative realm.

- Added a section specifying the new error code 
DIAMETER_REALM_REDIRECT_INDICATION.

- Modified the wording of the Security Considerations section to just 
refer to Section 2.9 (corrected) of 3588bis.

Tom Taylor