Subject: [Dime] [Fwd: New Version Notification for draft-tsou-dime-realm-based-redirect-01]

From: Tom Taylor <[email-masked]>
Date: Mon, 13 Jul 2009 21:27:45 -0400

I updated this based on comments received from Glen Zorn, Sebastien Decugis, and 
  Wolfgang Steigerwald. The basic approach was to create a Standards Track 
document updating RFC 3588, using a new Result-Code value, and including 
Error-Reporting-Host so legacy systems don't get confused.

-------- Original Message --------
Subject: New Version Notification for 
draft-tsou-dime-realm-based-redirect-01
Date: Mon, 13 Jul 2009 17:19:39 -0700 (PDT)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
CC: [email-masked]

A new version of I-D, draft-tsou-dime-realm-based-redirect-01.txt has been 
successfuly submitted by Tom Taylor and posted to the IETF repository.

Filename:	 draft-tsou-dime-realm-based-redirect
Revision:	 01
Title:		 Realm-Based Redirection In Diameter
Creation_date:	 2009-07-14
WG ID:		 Independent Submission
Number_of_pages: 5

Abstract:
RFC 3588 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 the means by
which this can be achieved.

The IETF Secretariat.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 14 Jul 2009 11:49:14 +0700

> Error-Reporting-Host so legacy systems don't get confused.

Section 2.1.1. says "the redirect agent MUST insert a Redirect-Realm AVP
containing the realm from the routing table entry in its answer message
instead of one or more Redirect-Host AVPs" but section 2.1.2. says:
   A Diameter node conforming to this specification which receives an
   answer with the result code value DIAMETER_REALM_REDIRECT_INDICATION
   SHOULD attempt to reroute the request to the indicated realm rather
   than the individual host(s) specified in Redirect-Host AVP(s) in the
   redirect indication.
The former implies that no Redirect-Host AVPs would be present in the
message but the latter suggests the opposite.  Which one is it?

Section 2.2 says:
   The Redirect-Realm AVP (code TBD) is of type DiameterIdentity.  It
   specifies a realm to which a node receiving a redirect indication
   containingthe result code value DIAMETER_REALM_REDIRECT_INDICATION
   and this AVP SHOULD route the original request.  The M and V flags
   for the Redirect-Realm AVP MUST NOT be set.
Of course, it's not possible for a Diameter message to be routed to a realm:
it has to be sent to a Diameter node.  How is the node to be chosen?  What
happens if the selected node is unavailable?  What happens if the receiver
doesn't know about any nodes in the realm.  Also, AVPs don't route requests
;-).

In section 2.2, s/containingthe/containing the/

> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 14 Jul 2009 14:04:04 +0900

Hi,

> doesn't know about any nodes in the realm.
I was assuming that the mechanism(s) described in RFC3588 section 5.2
would be implicitly used here (Ex: NAPTR requests).
The node receiving this indication may also already have a routing entry
for the new (intermediate) destination realm.

My 2 cents...
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 14 Jul 2009 12:39:30 +0700

> would be implicitly used here (Ex: NAPTR requests).

That's what I would assume, to, but I don't think that you should need to
make any assumptions.

...

---

From: Tom Taylor <[email-masked]>
Date: Tue, 14 Jul 2009 09:52:45 -0400

That 2.1.2 text is a leftover -- I thought I deleted the reference to 
Redirect-Host AVPs, but I guess I only amended the earlier part of the para. 
Will fix.

I'll improve 2.2.

Thanks for your quick review.

Tom

---

From: Tom Taylor <[email-masked]>
Date: Tue, 14 Jul 2009 09:53:42 -0400

That's what I intended. Thanks for looking at it and commenting.

Tom