Re: [Dime] [dime] #11: Review of the draft-ietf-dime-realm-based-redirect-03
"dime issue tracker" <trac+dime@trac.tools.ietf.org> Mon, 30 July 2012 21:09 UTC
Return-Path: <trac+dime@trac.tools.ietf.org>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA6521F8650 for <dime@ietfa.amsl.com>; Mon, 30 Jul 2012 14:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftaNStHXUSth for <dime@ietfa.amsl.com>; Mon, 30 Jul 2012 14:09:06 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id C738621F847C for <dime@ietf.org>; Mon, 30 Jul 2012 14:09:05 -0700 (PDT)
Received: from localhost ([127.0.0.1]:46844 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from <trac+dime@trac.tools.ietf.org>) id 1SvxD2-0003bV-22; Mon, 30 Jul 2012 23:09:00 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: dime issue tracker <trac+dime@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: lionel.morand@orange-ftgroup.com
X-Trac-Project: dime
Date: Mon, 30 Jul 2012 21:09:00 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/dime/trac/ticket/11#comment:1
Message-ID: <089.d413d8e8a8944e8f051dcd575d1df9d1@trac.tools.ietf.org>
References: <074.9c7d26cb783155a3f51671783308e5e2@trac.tools.ietf.org>
X-Trac-Ticket-ID: 11
In-Reply-To: <074.9c7d26cb783155a3f51671783308e5e2@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: lionel.morand@orange-ftgroup.com, jouni.nospam@gmail.com, dime@ietf.org
X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #11: Review of the draft-ietf-dime-realm-based-redirect-03
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: dime@ietf.org
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jul 2012 21:09:07 -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, lionel.morand@orange.com 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:jouni.nospam@gmail.com] 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/>
- Re: [Dime] [dime] #11: Review of the draft-ietf-d… dime issue tracker