Subject: [Dime] Proposed changes to draft-ietf-dime-realm-based-redirection (1)

From: Tom Taylor <[email-masked]>
Date: Mon, 4 Apr 2011 16:30:18 -0400

As reported at the meeting, this draft drew comments from Glen Zorn, 
Sebastien Decugis, and Avi Lior during WGLC. This note provides the 
proposed text changes to resolve the first two sets of comments. Avi's 
comment seemed to require direction from the list. However, prompted by 
existing text in Section 2.4 of RFC 3588, I have concluded that he is 
right. I present my argument and proposed changes in a separate note.

Glen Zorn 02/08/2010 (ET)
=========================

Looks fine to me; the only thing that I might add would be a more direct 
pointer to the "normal discovery procedures" mentioned in Section 3.1.2.

Proposed new text:

  ... SHOULD attempt to reroute the request to the indicated realm
  using normal discovery procedures (Section 5.2 of RFC 3588) to
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^
  find an appropriate destination host.

Sebastien Decugis 06/08/2010 (ET)
=================================

1) "(3.1.1) second list item (editorial):

"Furthermore, the redirect agent MUST a Redirect-Realm AVP
                                     ^^^
                               missing word?"

Proposed new text:

  Add the word"insert" following "MUST".

2) (3.1.1) What if the the other peer advertised the Relay application? 
Should the redirect agent consider that it supports
the Redirect-Realm application?

Proposed new text:

    Beginning of the first bullet:

    o  If the peer from which the request was received did not
       advertise the Relay application or
                 ^^^^^^^^^^^^^^^^^^^^^^^^
       an application incorporating the realm-based routing
       capability in the CER/CEA exchange, ...

    Beginning of the second bullet:

    o  Otherwise, if the Relay application or
                     ^^^^^^^^^^^^^^^^^^^^^^^^
       an application supporting the use of realm-based
       redirection was negotiated with the peer, ...

3) (3.1.1) "the message MUST include the Error-
       Reporting-Host AVP if the host setting the Result-Code AVP is
       different from the identity encoded in the Origin-Host AVP,"
IIUC this is an impossible situation, since the Redirect Agent did not 
forward the Request.
I believe this text could be removed for clarity.

Proposed new text:

  Delete the second-last sentence of the second bullet. The deleted
  text reads:

       To prevent confusion at Diameter nodes
       receiving the answer message, the message MUST include the
       Error-Reporting-Host AVP if the host setting the Result-Code
       AVP is different from the identity encoded in the Origin-Host
       AVP, in conformity with Section 7.1 of [RFC3588].

4) (3.1.2) What if the original request contains a Destination-Host AVP?
In that case, should a UNABLE_TO_DELIVER error be returned?
There is probably no point in sending to the alternate realm with a 
Destination-Host in the previous realm, right?
Unless maybe if the Destination-Realm of the request message does not 
match the Origin-Realm of the Redirect indication
(change of broker for example). Any opinion?

Proposed new text:

  Insert the following new text as the new first bullet of *3.1.1*:

    o If the original request contains a Destination-Host AVP, the
      the redirecting agent MUST return an error message with the
      Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.

5) (3.2) This section does not give the value of the M flag for the
new AVP. By the semantics of the application, I believe the M flag 
should be set, right?

Proposed new text:

  Modify the last sentence of the first paragraph of section 3.2
  to read as follows (new text indicated):

    The M flag for the Redirect-Realm AVP MUST be set, and the V
        ^^^^^^                            ^^^^^^^^^^^^^^^^
    flag MUST NOT be set.

Many thanks to Sebastien in particular for his careful review.

Tom Taylor

---

From: Tom Taylor <[email-masked]>
Date: Thu, 21 Apr 2011 09:58:20 -0400

I will implement these changes and submit the updated document.

On 04/04/2011 4:30 PM, Tom Taylor wrote:
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>
>