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

From: Benoit Claise <[email-masked]>
Date: Wed, 24 Jul 2013 00:47:01 +0200

Dear authors,

Here is my AD review.
If some points have been discussed on the mailing list, don't hesitate to let me know.

1.
The following sentence contains twice "but instead"

    The result of making realm-based redirection an application-specific
    behaviour is that it cannot be performed by a redirect agent, but
    instead must be performed by a redirect agent as defined in
    [RFC6733  <http://tools.ietf.org/html/rfc6733>], but instead by an application-aware Diameter node
    (Diameter server or proxy).

Don't you mean?

    The result of making realm-based redirection an application-specific
    behaviour is that it cannot be performed by a redirect agent
    [RFC6733  <http://tools.ietf.org/html/rfc6733>], but instead by an application-aware Diameter node
    (Diameter server or proxy).

2.

    Because realm-based redirection is not part of the Diameter base
    protocol [RFC6733  <http://tools.ietf.org/html/rfc6733>], support of realm-based redirection_by a Redirect
    agent_  MUST be specified as part of functionality supported by a
    Diameter application.
    
This contradicts the following sentence
   
    The result of making realm-based redirection an application-specific
    behaviour is that it cannot be performed by a_redirect agent_  
    [RFC6733  <http://tools.ietf.org/html/rfc6733>], but instead by an application-aware Diameter node
    (Diameter server or proxy).

Do I understand correctly that the justification is that, citing RFC 6733, Redirect Agents can't inspect the application.
    "Diameter relays and redirect agents are transparent to the Diameter
    applications, but they MUST support the Diameter base protocol, which
    includes accounting, and all Diameter applications."

I could understand all this if "by a Redirect Agent" would be removed in the first paragraph.
OLD:
    Because realm-based redirection is not part of the Diameter base
    protocol [RFC6733  <http://tools.ietf.org/html/rfc6733>], support of realm-based redirection by a Redirect
    agent MUST be specified as part of functionality supported by a
    Diameter application.

NEW:
    Because realm-based redirection is not part of the Diameter base
    protocol [RFC6733  <http://tools.ietf.org/html/rfc6733>], support of realm-based redirection MUST be
    specified as part of functionality supported by a Diameter application.

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 inSection 2.8.3 of [RFC6733]  <http://tools.ietf.org/html/rfc6733#section-2.8.3>.

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.
Same remark for the first paragraph in 3.2.1

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

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.

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.

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?

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?

Regards, Benoit

---

From: <[email-masked]>
Date: Wed, 24 Jul 2013 14:04:24 +0000

Hi Benoit,

please see below.

Regards,

Lionel (as Doc Shepherd)

De : [email-masked] [mailto:[email-masked]] De la part de Benoit Claise
Envoyé : mercredi 24 juillet 2013 00:47
À : dime mailing list
Objet : [Dime] AD review of draft-ietf-dime-realm-based-redirect

Dear authors,

Here is my AD review.

1.

   [RFC6733<http://tools.ietf.org/html/rfc6733>], but instead by an application-aware Diameter node

Don't you mean?

   [RFC6733<http://tools.ietf.org/html/rfc6733>], but instead by an application-aware Diameter node

[LM] OK.

2.

   protocol [RFC6733<http://tools.ietf.org/html/rfc6733>], support of realm-based redirection by a Redirect

   Diameter application.

   [RFC6733<http://tools.ietf.org/html/rfc6733>], but instead by an application-aware Diameter node

OLD:

   protocol [RFC6733<http://tools.ietf.org/html/rfc6733>], support of realm-based redirection by a Redirect

   Diameter application.

NEW:

   protocol [RFC6733<http://tools.ietf.org/html/rfc6733>], support of realm-based redirection MUST be

[LM] Correct

   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.

3.

[LM] would it be: "operates either only on the initial message of a session, or on any message of a session"

4.

[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.

5.

Proposal

Or

[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."

6.

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.

7.

Section 3.2.2

[LM] yes. See above.

Editorial

Is this intentional?

[LM] should be introduced in the def section.

Regards, Benoit

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Tom Taylor <[email-masked]>
Date: Wed, 24 Jul 2013 16:54:51 -0400

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

> Lionel (as Doc Shepherd)
...
> 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.

> 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.
> [LM] A redirection is always  a "temporary" info so the
> Max-Cache-Time is always present when a cache is created.
>
> 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?

> [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.

> 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.
> DIAMETER_REDIRECT_INDICATION to the client?
[PTT] No action?
> [LM] should be introduced in the def section.
[PTT] OK
...

---

From: Benoit Claise <[email-masked]>
Date: Fri, 26 Jul 2013 15:26:16 +0200

Hi Lionel,

Thanks for the fast reply.
See in line.
>
> Hi Benoit,
>
> please see below.
>
> Regards,
>
> Lionel (as Doc Shepherd)
>
> *De :[email-masked] [mailto:[email-masked]] *De la part 
> de* Benoit Claise
> *Envoyé :* mercredi 24 juillet 2013 00:47
> *À :* dime mailing list
> *Objet :* [Dime] AD review of draft-ietf-dime-realm-based-redirect
>
> Dear authors,
>   
> Here is my AD review.
> */[LM] OK./*
>     protocol [RFC6733  <http://tools.ietf.org/html/rfc6733>], support of realm-based redirection_by a Redirect_
> _    agent_  MUST be specified as part of functionality supported by a
>     Diameter application.
>     
> */[LM] Correct/*
> */[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./*
OK.
So agreed on

The rest of the paragraph is:
    However, despite the change in executing
    role, the behaviour itself is a slight modification of the behaviour
    of a redirect agent as described inSection 2.8.3 of [RFC6733]  <http://tools.ietf.org/html/rfc6733#section-2.8.3>.

Proposal (for the second part of the paragraph):
    However, despite the change in executing
    role, the realm-based redirect proxy/server behaviour is only a slight modification of the behaviour
    of a redirect agent as described inSection 2.8.3 of [RFC6733]  <http://tools.ietf.org/html/rfc6733#section-2.8.3>.

Also, regarding the last point in the email, you should decide if you want to introduce redirecting server or realm-based redirecting server or realm-based redirect proxy/server
  in the terminology. Just be consistent throughout the doc.

> */[LM] would it be:/*"operates either only on the initial message of a session, or on any message of a session"
ok.
> *//*
> */[LM] A redirection is always  a "temporary" info so the Max-Cache-Time is always present when a cache is created./*
>     This AVP_MUST be_  present in answer messages whose 'E' bit is set,
> */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./*
Not that bad indeed. If this is common practice to put pretty high 
number in Redirect-Max-Cache-Time, fine then.
.
> *//*
> */  /*
> */[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:/*
>
> */  /*
> */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."/*
ok
> */[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./*
Please change the text then.
> */[LM] yes. See above./*
> */[LM] should be introduced in the def section./*
/**/thanks and regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Fri, 26 Jul 2013 15:28:57 +0200

Hi Tom,
> point of reference for what follows.
See my reply to Lionel.
> 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
>> for 136 years". So it is not "forever" but not too bad.
Don't think so.
You might want to have a sentence explaining how the "forever" use case 
is done. Up to you.
> [PTT] I like that latter formulation.
Fine.
>> DIAMETER_REDIRECT_INDICATION to the client?
This would be solved by:

Regards, Benoit