Subject: Re: [Dime] [dime] #11: Review of the draft-ietf-dime-realm-based-redirect-03

From: "dime issue tracker" <[email-masked]>
Date: Mon, 30 Jul 2012 21:09:00 -0000

#11: Review of the draft-ietf-dime-realm-based-redirect-03

Changes (by lionel.morand@…):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 On 12-07-30 01:54 PM, [email-masked] wrote:
 > Hi Tom,
 >
 > I'm in line with the response from Jouni.
 > As proposed by Jouni, a note at the beginning of 3 or 3.1 will be
 suitable.
 > Please acknowledge and I'll close the ticket.
 >
 > Lionel
 >
 > -----Message d'origine-----
 > De : jouni korhonen [mailto:[email-masked]] Envoyé : mardi 24
 > juillet 2012 09:22 À : Tom Taylor Cc : MORAND Lionel RD-CORE Objet :
 > Re: Ticket 11: draft-ietf-dime-realm-based-redirect
 >
 > Hi
 >
 > Which Ticket this was? ;) hmm.. #11 by Lionel I assume..? I have just
 > two notes below. Other than those, I think this is OK.
 >
 >
 > On Jul 24, 2012, at 4:34 AM, Tom Taylor wrote:
 >
 >> Hi, Jouni
 >>
 >> Your turn to decide if a ticket can be closed.
 >>
 >> Tom Taylor
 >>
 >>
 >> Comment 1
 >> =========
 >>
 >>     o If the peer from which the request was received did not advertise
 >>       an application incorporating the realm-based routing capability
 in the CER/CEA exchange, the redirect agent SHOULD set the 'E' bit in the
 answer and set the Result Code to DIAMETER_UNABLE_TO_DELIVER. As an
 alternative, the redirect agent MAY if so configured provide a host-based
 redirect as described in Section 6.1.7 of [RFC3588].
 >>
 >> ==> This last sentence assumes both types of redirection information
 can be provisioned in the Redirect Agent. Should we allow such a
 configuration? If so, how does the Redirect Agent know what information
 should be used when the originator of the request support both redirection
 indication mechanisms (i.e. priority, order, etc.)?
 >>
 >> Response:
 >>
 >> Text giving the alternative was deleted.
 >>
 >> Comment 2
 >> =========
 >>
 >>     o Otherwise, if an application supporting the use of realm-based
 >>
 >>         redirection was negotiated with the peer, the redirect agent
 MUST set the Result-Code AVP to DIAMETER_REALM_REDIRECT_INDICATION rather
 than DIAMETER_REDIRECT_INDICATION.
 >>
 >> ==> Otherwise, if an application supporting the use of realm-based
 >> redirection was negotiated with the peer/
 >>
 >>     Otherwise, if the request is for an application supporting
 >> realm-based redirection,
 >>
 >> Response:
 >>
 >> Text rewritten, clearer that it is application-based behaviour without
 talking about negotiation.
 >>
 >> Comment 3
 >> =========
 >>
 >>         Furthermore, the redirect agent MUST a Redirect-Realm AVP
 containing the realm from the routing table entry in its answer message
 instead of one or more Redirect-Host AVPs.
 >>
 >> ==> s/the redirect agent MUST a Redirect-Realm AVP/the redirect agent
 >> MUST include in the answer a Redirect-Realm AVP
 >>
 >> Response:
 >>
 >> Done.
 >>
 >> Comment 4
 >> =========
 >>
 >>     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].
 >>
 >> ==> Why should we use the Error-Reporting-Host AVP here? The Origin-
 host AVP of the answer will be the diameter indeity of the Redirect
 server, no?
 >>
 >> Response:
 >>
 >> That text deleted.
 >>
 >> Comment 5
 >> =========
 >>
 >>     All other aspects of Section 6.1.7 remain the same as for host-
 based redirection.
 >>
 >> ==> the use of Redirect-Host-usage AVP and Redirect-Max-Cache-Time AVP
 is not exactly the same; Both are related to the Redirect-Host AVP that
 can be found in the answer. In the Realm-based redirection, these AVPs
 have to be associated with the peer resulting of the realm-based discovery
 mechanism, as described in section 3.2. This should be also clarified at
 this stage.
 >>
 >> Response:
 >>
 >> -05 text reads:
 >>
 >>       The server MAY include a copy of the Redirect-Host-Usage AVP,
 >>       which SHOULD be set to REALM_AND_APPLICATION.  If this AVP is
 >>       added, the Redirect-Max-Cache-Time AVP MUST also be included.
 >>       Note that these AVPs apply to the peer discovered by a node
 acting
 >>       on the server's response, as described in the next section.
 >>
 >> Comment 6
 >> =========
 >>
 >> 3.1.2. Behaviour of Other Diameter Nodes
 >>
 >>     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 using normal
 discovery procedures to find an appropriate destination host. The
 receiving Diameter node SHOULD update its cache of routing entries
 according to the direction provided by the Redirect-Max- Cache-Time AVP,
 if present. The cache entry SHOULD be associated with a redirect usage of
 REALM_AND_APPLICATION.
 >>
 >> ==> RFC3588 says that the Redirect-Max-Cache-Time AVP and Redirect-
 Host-Usage AVP is associated with the redirect-host AVP. Here, the use of
 this AVP are modified/enhanced to be associated with the peer discovered
 based on the Realm-based redirection.
 >>
 >> Response:
 >>
 >> I may have fallen short here. With the change from -04 to -05, I
 deleted text about modifying 3588 with respect to these two AVPs. The
 current text in section 3.2.2 reads (bullet 4):
 >>
 >>        A.  update its cache of routing entries for the realm and
 >>            application to which the original request was directed,
 >>            taking into account the Redirect-Host-Usage and Redirect-
 Max-
 >>            Cache-Time AVPs, if present in the answer.
 >>
 >> Do I need to note that this is a modification of 3588bis behaviour?
 > That could be appropriate, I think.
 >
 >
 >
 >> Comment 7
 >> =========
 >>
 >> 3.2. The Redirect-Realm AVP
 >>
 >>     The Redirect-Realm AVP (code TBD) is of type DiameterIdentity?. It
 specifies a realm to which a node receiving a redirect indication
 containing the result code value DIAMETER_REALM_REDIRECT_INDICATION and
 the Redirect-Realm AVP SHOULD route the original request. The V flag for
 the Redirect-Realm AVP MUST NOT be set.
 >>
 >>     Section 6.14 of [RFC3588] is modified to permit the Redirect- Max-
 Cache-Time AVP to be used also to specify the persistence of cache entries
 created by the Redirect-Realm AVP.
 >>
 >> ==> the same kind of information should be present for the use of
 Redirect-Host-Usage AVP.
 >>
 >> Response:
 >>
 >> Same issue as previous comment, of course. The real question is: if I
 add the text referring to the added behaviour, in which section should I
 put it?
 >>
 > First in the header "Updates RFC3588bis (if approved)"
 > Second I would add a bit of explanation into Section 3 or 3.1. They
 > already have a good head start with bullet lists.
 >
 > - Jouni
 >
 >
 Acknowledged and noted in my presentation charts.

-- 
----------------------------------+---------------------
 Reporter:  lionel.morand@…       |       Owner:
     Type:  defect                |      Status:  closed
 Priority:  major                 |   Milestone:
Component:  realm-based-redirect  |     Version:
 Severity:  In WG Last Call       |  Resolution:  fixed
 Keywords:                        |
----------------------------------+---------------------

Ticket URL: <http://wiki.tools.ietf.org/wg/dime/trac/ticket/11#comment:1>
dime <http://tools.ietf.org/wg/dime/>