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

From: "Victor Fajardo" <[email-masked]>
Date: Tue, 6 Oct 2009 11:46:06 -0400

Hi Tom/Tina,

There a few leftover discussions regarding this doc (7/30 - 7/31 thread). Do
you plan on updating the docs based on these comments ? Do you have any
other open issues ?

Regards,
Victor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, July 30, 2009 7:00 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.txt

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)       : T. Tsou, T. Taylor
	Filename        : draft-ietf-dime-realm-based-redirect-01.txt
	Pages           : 6
	Date            : 2009-07-30

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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dime-realm-based-redirect-01.
txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Tom Taylor <[email-masked]>
Date: Tue, 06 Oct 2009 11:54:31 -0400

Yes, I'll update to remove the unneeded content. After that I think the draft is 
in good shape.

---

From: Tom Taylor <[email-masked]>
Date: Tue, 06 Oct 2009 14:00:37 -0400

I'm proposing in response to your concern on advertisement to add the following 
section to the document. Does this meet the requirements?

<section anchor="applic" title="Applicability Statement">

<t>Because realm-based redirection is not part of base Diameter behaviour, 
support for realm-based redirection by the client cannot be guaranteed without 
advertisement at the application level. Designers of new applications MAY wish 
to incorporate a requirement to support realm-based redirection through 
normative reference to this document.</t>

<t> An erstwhile service provider who deploys realm-based redirection without 
support from advertisement imposes a risk upon clients that they are unable to 
complete requests for the service concerned because, thanks to prevailing local 
policies, they have not derived alternative routes to other domains that can 
support the service. The decision to impose such a risk and the administrative 
actions that providers may take to mitigate this risk are based on non-technical 
considerations and are therefore out of scope of this document. </t>

</section><!-- applic -->

Mark Jones wrote:
> The use case I had in mind when I made the comment in the DIME session was a wholesaler for AAA that was previously offering service for a given realm but the AAA service is now being provided by a new wholesaler.
> 
> So the old wholesaler would use the redirect realm AVPs with:
>    Redirect-Realm = <realm of new wholesaler>
>    Redirect-Realm-Usage = ALL_REALM
> 
> The other question I had on this draft was how one advertises support for the realm redirect functionality. I understand from Tom's presentation that nothing too bad happens on the client if it does not support these AVPs but the intended redirect did not happen either and the redirecting server is unaware of the error. The way new functionality (i.e. beyond base functionaltiy) is advertised in Diameter is through the use of application ids in CER/CEA exchanges. If new applications require redirect realm functionaltiy, I would expect the specifications for these new applications to state this dependency and include a normative reference to the redirect realm draft. I think the redirect realm draft should clarify this because redirect realm is not base functionality.
> 
> Regards
> Mark
> 
> ________________________________________
> From: [email-masked] [[email-masked]] On Behalf Of Sebastien Decugis [[email-masked]]
> Sent: Thursday, July 30, 2009 3:24 PM
> To: Tom Taylor
> Cc: [email-masked]
> Subject: Re: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.txt
> 
> Ok, I did not get that, sorry :) Just ignore my comment then.
> 
> Thanks,
> Sebastien.
> 
> Tom Taylor a écrit :
>> No difference, but didn't we say in the meeting we preferred not to
>> overload Redirect-Host-Usage?
>>
>> Sebastien Decugis wrote:
>>> Hi,
>>>
>>> Just quickly going through the new draft revision, I did not find any
>>> difference between Redirect-Host-Usage (RFC3588) and the new
>>> Redirect-Realm-Usage being defined. I am just wondering if the content
>>> is the same, if we cannot just re-use the Redirect-Host-Usage AVP?
>>> Please let me know (and pardon me) if I did miss a subtle difference :)
>>>
>>> My 2 cents,
>>> Sebastien.
>>>
>>>
>>> Tom Taylor a écrit :
>> ...
>>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>

---

From: Mark Jones <[email-masked]>
Date: Tue, 6 Oct 2009 15:56:24 -0400

Hi Tom,

I was expecting a stronger statement on advertisement at the application level, e.g.

"Because realm-based redirection is not part of base Diameter behaviour, support for realm-based redirection by the peers MUST be advertised at the application level."

I don't see how the feature works reliably otherwise and punting the risk evaluation to the service provider seems inappropriate for a feature likely to used on inter-service-provider interfaces.

Regards
Mark

> From: Tom Taylor [mailto:[email-masked]] 
> Sent: October 6, 2009 2:01 PM
> To: Mark Jones
> Cc: [email-masked]
> Subject: Re: [Dime] I-D 
> Action:draft-ietf-dime-realm-based-redirect-01.txt
> 
> > The use case I had in mind when I made the comment in the 
> DIME session was a wholesaler for AAA that was previously 
> offering service for a given realm but the AAA service is now 
> being provided by a new wholesaler.
> > 
> > The other question I had on this draft was how one 
> advertises support for the realm redirect functionality. I 
> understand from Tom's presentation that nothing too bad 
> happens on the client if it does not support these AVPs but 
> the intended redirect did not happen either and the 
> redirecting server is unaware of the error. The way new 
> functionality (i.e. beyond base functionaltiy) is advertised 
> in Diameter is through the use of application ids in CER/CEA 
> exchanges. If new applications require redirect realm 
> functionaltiy, I would expect the specifications for these 
> new applications to state this dependency and include a 
> normative reference to the redirect realm draft. I think the 
> redirect realm draft should clarify this because redirect 
> realm is not base functionality.
> > 
> > Regards
> > Mark
> > 
> > From: [email-masked] [[email-masked]] On 
> Behalf Of Sebastien Decugis [[email-masked]]
> > Subject: Re: [Dime] I-D 
> Action:draft-ietf-dime-realm-based-redirect-01.txt
> >

---

From: Tom Taylor <[email-masked]>
Date: Tue, 06 Oct 2009 22:09:19 -0400

What I'm worried about is whether this implies every application out there has 
to be redefined to make use of this feature.

---

From: Mark Jones <[email-masked]>
Date: Wed, 7 Oct 2009 11:47:43 -0400

Hi Tom, 

> Sent: October 6, 2009 10:09 PM
> To: Mark Jones
> Cc: [email-masked]
> Subject: Re: [Dime] I-D 

That is indeed the implication. Alternatively, you define a new application id for the realm-based redirect functionality and it complements the existing applications, i.e. if you need NASREQ with realm-based redirect, the CER/CEA advertises the NASREQ Application Id and the Realm-based Redirect Application ID.

Regards
Mark

> > "Because realm-based redirection is not part of base 
> Diameter behaviour, support for realm-based redirection by 
> the peers MUST be advertised at the application level."
> > 
> > I don't see how the feature works reliably otherwise and 
> punting the risk evaluation to the service provider seems 
> inappropriate for a feature likely to used on 
> inter-service-provider interfaces.
> > 
> > Regards
> > Mark
> > 
> > 
>

---

From: Tom Taylor <[email-masked]>
Date: Wed, 07 Oct 2009 15:49:34 -0400

I'll take the second choice you offer.

---

From: "Victor Fajardo" <[email-masked]>
Date: Tue, 27 Oct 2009 07:01:33 -0400

Hi Tom,

Any plans on submitting and update to the doc ?

Regards,
Victor
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom
Taylor
Sent: Wednesday, October 07, 2009 3:50 PM
To: Mark Jones
Cc: [email-masked]
Subject: Re: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.txt

Mark Jones wrote:
> That is indeed the implication. Alternatively, you define a new
application id for the realm-based redirect functionality and it complements
the existing applications, i.e. if you need NASREQ with realm-based
redirect, the CER/CEA advertises the NASREQ Application Id and the
Realm-based Redirect Application ID.

---

From: Tom Taylor <[email-masked]>
Date: Tue, 27 Oct 2009 11:02:30 -0400

I did so, but it will need manual follow-up because my new ISP thought the 
authentication messages were spam and intercepted them.