Subject: Re: [Dime] AD review of draft-ietf-dime-realm-based-redirect

From: Benoit Claise <[email-masked]>
Date: Fri, 02 Aug 2013 09:54:03 +0200

Hi Tom,

I reviewed the version 10, just posted.

I find the second sentence below confusing.

    The term "redirect server" denotes the device that returns the realm-
    based redirection.  It replaces "redirect agent" in this context for
    reasons explained in the next section.

Replace "redirect agent": where? compare to what?
I guess you try to say something that you mention later in the draft

    However, despite the change in
    executing role, the behaviour itself is a slight modification of the
    behaviour of a redirect agent as described in Section 2.8.3 of
    [RFC6733].

So basically that a redirect server is almost a redirect agent with a 
slight modification of behaviour (see XXX)
Make it clear in the terminology section, or leave it for later in the 
doc (ie remove the second sentence)

Also the abstract (and some more paragraphs in the draft) still mentions 
redirect agent:

    Abstract

        The Diameter protocol allows a Diameter_redirect agent_  to return to
        the message sender one or more individual hosts as destinations of
        the redirected message.  However,

That's a mistake, right?

Regards, Benoit

> Hi Tom,
>> Thanks for picking this up, Lionel. I started to work on a response last
>> night but got distracted by other work. Comments below marked with 
>> [PTT]. Parts where I have nothing to add to Lionel's responses are 
>> omitted.
>>
>> Tom Taylor
>>
>> On 24/07/2013 10:04 AM, [email-masked] wrote:
>>> Hi Benoit,
>>>
>>> please see below.
>>>
>>> Regards,
>>>
>>> Lionel (as Doc Shepherd)
>>>
>> ...
>>>
>>> But then, if it doesn't apply to a Redirect Agent, then why do we
>>> have this paragraph
>>>
>>> However, despite the change in executing
>>>
>>> role, the behaviour itself is a slight modification of the behaviour
>>>
>>> of a redirect agent as described in Section 2.8.3 of
>>> [RFC6733]<http://tools.ietf.org/html/rfc6733#section-2.8.3>.
>>>
>>> [LM]My understanding is to point out that the role of the Realm-based
>>> redirect proxy/server is very close to the behavior of a "regular"
>>> redirect agent, and therefore most of what applies for Redirect agent
>>> apply to the Realm-based redirect proxy/server.
>>>
>> [PTT] Agreed. The purpose of this text is just to give the reader a 
>> point of reference for what follows.
> See my reply to Lionel.
>>
>>>
>>>
>>> 3.
>>>
>>> An application can specify that realm-based redirection operates
>>> only
>>>
>>> on the initial message of a session, or on any message of a session.
>>>
>>>
>>>
>>> "only the initial message" or "on any message of a session" = "on any
>>> message of a session", right?
>>>
>>> Remove "only", that would make sense with the next sentence in the
>>> paragraph.
>>>
>>> [LM] would it be: "operates either only on the initial message of a
>>> session, or on any message of a session"
>>>
>>>
>>>
>>> Same remark for the first paragraph in 3.2.1
>>>
>> [PTT] I think what I mean to say in Section 2 is: "only on complete 
>> sessions beginning with the initial message, or on every message 
>> within the application, even if earlier messages of the same session 
>> were not redirected. This distinction matters only when realm-based 
>> redirection is first initiated." Then in Section 3.1.2 I would repeat 
>> the first sentence.
> Ah, ok. I understand why you want that distinction. Please clarify the 
> text
>>>
>>>
>>> 4.
>>>
>>> I thought about this use case:
>>>
>>> "consider the case where an operator has offered a specific
>>>
>>> service but no longer wishes to do so.  The operator has arranged
>>> for
>>>
>>> an alternative domain to provide the service."
>>>
>>> Don't we need "Redirect-Max-Cache-Time" = "forever"?
>>>
>>> Unless ... "forever" is meant when the Redirect-Max-Cache-Time AVP is
>>> not present?
>>>
>>> I could not find a definitive answer in the draft or in RFC 6733
>>>
>>> [LM] A redirection is always  a "temporary" info so the
>>> Max-Cache-Time is always present when a cache is created.
>>>
>>> The Redirect-Max-Cache-Time AVP (AVP Code 262) is of type
>>> Unsigned32.
>>>
>>> This AVP MUST be present in answer messages whose 'E' bit is set,
>>>
>>> whose Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION, and
>>>
>>> whose Redirect-Host-Usage AVP set to a non-zero value (i.e. as soon
>>> as you need to cache the info).
>>>
>>> About the "forever", you can't say more than "keep the info cached
>>> for 136 years". So it is not "forever" but not too bad.
>>>
>>>
>> [PTT] No action here?
> Don't think so.
> You might want to have a sentence explaining how the "forever" use 
> case is done. Up to you.
>>
>>>
>>> 5.
>>>
>>> If the redirected request contained a Destination-Host AVP, that
>>>
>>> AVP is ignored by the redirecting server.
>>>
>>>
>>>
>>> Pay attention that you update RFC 6733
>>>
>>>
>>>
>>> Proposal
>>>
>>> If the redirected request contains a Result-Code AVP set to
>>>
>>> DIAMETER_REALM_REDIRECT_INDICATION and a Destination-Host AVP,
>>>
>>> that Destination-Host AVP MUST be ignored by the redirecting server.
>>>
>>>
>>>
>>> Or
>>>
>>> When a directed request contains a Result-Code AVP set to
>>>
>>> DIAMETER_REALM_REDIRECT_INDICATION, the Destination-Host AVP
>>>
>>> content MUST be ignored by the redirecting server.
>>>
>>> [LM] I think that "redirected" is misleading here as "redirected
>>> request" is used as "the request to be redirected".
>>>
>>> The clarification here is about the fact that as per RFC6733, a
>>> request containing a Destination-Host cannot be rerouted: An example
>>> of a case where it is not possible to forward the message to an
>>> alternate server is when the message has a fixed destination, and the
>>> unavailable peer is the message's final destination (see
>>> Destination-Host AVP).  Such an error requires that the agent return
>>> an answer message with the 'E' bit set and the Result-Code AVP set to
>>> DIAMETER_UNABLE_TO_DELIVER.
>>>
>>>
>>>
>>> About ignoring the Destination-Host, I think that it is not possible
>>> to say "MUST be ignored" as it will be application-dependent. For
>>> instance, one criterion for realm based redirection can be: "only for
>>> initial session request when no Destination-host is present". We
>>> could say: "The Realm-based redirection MAY be applied even if a
>>> Destination-Host AVP is present in the request, depending on the
>>> operator-based policy."
>>>
>>>
>> [PTT] I like that latter formulation.
> Fine.
>>
>>>
>>> 6.
>>>
>>> A proxy conforming to this specification that receives an answer
>>>
>>> message with the Result-Code AVP set to
>>>
>>> DIAMETER_REALM_REDIRECT_INDICATION MAY attempt to reroute the
>>>
>>> original request to a server in a realm identified by a Redirect-
>>>
>>> Realm AVP instance in the answer message, or MAY simply forward the
>>>
>>> message toward the client.
>>>
>>>
>>>
>>> It MUST do one of the two things, I guess. Otherwise, doing nothing
>>> is also a valid option according to the text.
>>>
>>> Please mention it.
>>>
>>> [LM] Any proxy can do something but a proxy conforming to this
>>> specification MUST attempt to reroute... and if it fails, MUST
>>> forward the indication to the client.
>>>
>> [PTT] OK, I'll rephrase.
>>>
>>>
>>>
>>> 7.
>>>
>>> Section 3.2.2
>>>
>>> And what if all point of the procedure fail, for all realms, what
>>> should happen?
>>>
>>> DIAMETER_REDIRECT_INDICATION to the client?
>>>
>>> [LM] yes. See above.
>>>
>>>
>> [PTT] No action?
> This would be solved by:
>
>     [LM] Any proxy can do something but a proxy conforming to this
>     specification MUST attempt to reroute... and if it fails, MUST
>     forward the indication to the client. 
>
>>>
>>>
>>>
>>> Editorial
>>>
>>> - Redirect agent versus redirect agent
>>>
>>> - Redirecting Server is a new term AFAICT, and is not really defined
>>> (even if we can guess).
>>>
>>> Is this intentional?
>>>
>>> [LM] should be introduced in the def section.
>>>
>>>
>> [PTT] OK
>>>
>> ...
>>
>>
> Regards, Benoit
>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Tom Taylor <[email-masked]>
Date: Fri, 02 Aug 2013 09:53:10 -0400

Technically the Abstract is correct, since it is talking about 
conventional redirection. The real problem is varying points of view of 
the Abstract, Introduction, and Terminology sections. Each of these 
sections needs to focus on the role of the actor (redirect agent, 
redirect server) to pull it all together, whereas the existing point of 
view flits between redirect agent, the redirect messages, what gets back 
to the message sender, ...

Here's a try at making things more coherent.

Abstract

Message redirection is a basic capability provided by the Diameter 
protocol. In its conventional form, message redirection is performed by 
an application-independent "redirect agent", which returns one or more 
individual hosts to the message sender as possible destinations of the 
redirected message.

However, in some circumstances an operator may wish to redirect messages 
to an alternate domain without specifying individual hosts. This 
document specifies an application-specific mechanism by which that can 
be achieved. New applications may incorporate this capability by 
reference to the  present document.

Because the redirection mechanism is application-specific, it must be 
performed by a Diameter server or proxy rather than a redirect agent. A 
new term, "redirect server", is introduced in this document to 
differentiate the application-specific nature of realm-based redirection 
from the conventional Diameter redirection performed by a redirect agent.

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

1. Introduction

Section 2.8.3 of the Diameter base specification [RFC6733] introduces 
and Section 6.1.8 specifies more fully the operation of a redirect 
agent. The redirect indication returned by the redirect agent is 
described in Section 6.1.8 and Sections 6.12-6.14 of [RFC6733], and 
provides to the message sender one or more individual hosts as 
destination of the redirected message.

However, consider the case where an operator has offered a specific 
service but no longer wishes to do so. ... [same as before]

1.1 Terminology

The key words ...

Within this specification, the term "realm-based redirection" is used to 
refer to a mode of operation where a realm rather than an individual 
host is returned as redirect indication.

The term "redirect server" denotes the device (Diameter server or proxy) 
that returns the realm-based redirection. It replaces "redirect agent" 
in this context for reasons explained in the next section. The behaviour 
of the redirect server itself is a slight modification of the behaviour 
of a redirect agent as described in Section 6.1.8 of [RFC6733].

2.

[Remove "However, despite the change in executing role, the behaviour 
itself is a slight modification of the behaviour of a redirect agent as 
described in Section 2.8.3 of [RFC6733]."]