Re: [Dime] Mail regarding draft-ietf-dime-rfc3588bis

Yuval Lifshitz <> Sun, 28 October 2018 12:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 53DDC128CFD for <>; Sun, 28 Oct 2018 05:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Nu3jtoNbIb1K for <>; Sun, 28 Oct 2018 05:06:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 57138128CE4 for <>; Sun, 28 Oct 2018 05:06:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1540728409; bh=/PkwFnpiOWXYI9IE3IwbpOIQrBkLOWcasE45nrXnu1U=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=ahTzXqErmXX+cIWK+NveBygFm8XLkBab4iiHhuWGyixSYkhJhZFWy6BJMnbd8GrPj7ja3Mr0TmizRvEupCTsPXZLEC9lA3kwU8bKW/1rarhbNq820QI8sXLtwZkCGa2gRLwqhzoAW7D1oOUMDV4f5DcGPt6pYVgqbWjHoYgJK02vxliNX913fGjpiM3rnHTxvTj2RuWXHtjnwjK0z+IlstfTzlJX0MfcOV9LVvY2u4ULd7Uwy0p3rB1tog1dMd+uz8Z6lGSw4nIsX6hUbmCBV1PGcPJOoHzpX5rnG27bfSZ60nA3A3kGFfubWoYJ81UH7Ruo2UwqE4dYVshmkMb13A==
X-YMail-OSG: snGHmCgVM1lNT6zbd4DRT0MRTwt03hrzBeH7xAgVd2UzLGFRyyQD77CvWOfd_x3 bhI1MWHGme_91n.a0tqm0uQik1sV4fgOQd6HklwyINV9Lb2rc24xnyeEhNdMZGTovPBawqUV1t9h nm.CtIKjcIbeYgeYXiDpPtDvWQqk__jU9JXNYj6FPlo8yRL8uv4B8Bgz0AfW9V1F_bxXeucFh8zn fnLNWEMpbNeRgdS3e9N6Sh5BidFLvUWdxhRmAB.oWJDh.PQ.JvU4Zv0odS569ifsxdLFSGXMs_l7 PxRwV1XkKaavF0.4KBH_h3XvgbgHhnMZaXSc4Jok.hCc_oEWD7bfJGxEdjZzSahZ.xrQGjmNxII4 FN_pE2MOxQ9NbwO8_KkS8LWF1U.YtEy6iSe1Z9IEC59o6FN.cL82zlgk5NK4NCEtKm7uV.IfFuo1 FvXLtejpuCJW1aG4YyQ4mCI5OuTd5D7YmPlA7uGdPxHEWR1rg5pSfoDS0Jl.bEPRDV5p7rZrGrQC 0BvyJIn1rTR7iFxg3pnIQsFfCmkCx_u3mamKQVi0HpenkN_5j8kzOhJkd2uKj1eRk1rpFG5R55tJ My8LmraWB3lRpJCR0jfhCr809WlPqINmxBgdXTegGf_MOQBugRd7bb5vjefI7IyZoFRUcTOpVoq8 J9OPCU7B4CRT6wWiIEPNxG7Kc4LTPqi9.sbZ22gI3M7LbfwZpnQNMCXVwJOZTKr.O255GqR19xVJ _omQ.L1bilVPAr5bR5Cj0DeIpiESPyXe1B0R4lm97XuZu2t1s.yYRPUm0FErSf.9ynRuogleAoNg AlQyViSAo8oi7qhXuKJ9CM8TcQTdyGBNjHGC5dB3gG79hBC8t0YPCAo8rAL4VvfjjLqDPwCRZ9Ko ugXvtoPSl9CNMpxaWZeDO30HHZh7nPWPJkcQSlFtnbyEX2S5yzclR6or6IQtRxdJzdn5pzAL2suZ HjmEacwzGgINhV0Nhq40TZps.HnZNii6s7DZD1DI.mO_r6qlh.QaswJn3vm4eoNsYlbhwMKTOwwr mc1iK
Received: from by with HTTP; Sun, 28 Oct 2018 12:06:49 +0000
Date: Sun, 28 Oct 2018 12:06:45 +0000 (UTC)
From: Yuval Lifshitz <>
To: "" <>, Villa Silvia <>
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_17665941_437119187.1540728405638"
X-Mailer: WebService/1.1.12512 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36
Archived-At: <>
Subject: Re: [Dime] Mail regarding draft-ietf-dime-rfc3588bis
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 28 Oct 2018 12:06:53 -0000

 Hello Silvia,The server is expected to send the RAR to the same host from which the session was initialized (i.e the Destination-Host of the RAR should be the same as the Origin-Host of the AAR).
There is no requirement, however, to send the RAR on the same Diameter connection that was used to send the AAR. For example, if there was a connectivity issue with the client after the AAR was sent, that was resolved (client reconnected wit the same Diameter identity), and then the server want to send the RAR, it should be allowed to send it over the new connection to the same client (with the correct Destination-Host).
Another case is where the client is not directly connected to the server (i.e. a Diameter agent sits between them). In such a case the server may use "realm routing" and send the RAR on any Diameter connection that may reach the desired realm. However, even in this case, the Destination-Host of the RAR must be set to the correct Destination-Host, and it is up to the Diameter agent(s) to route the request to the correct client.
Hope this helps,
    On Friday, October 26, 2018, 3:47:26 p.m. GMT+3, Villa Silvia <> wrote:  
  <!--#yiv4562165256 _filtered #yiv4562165256 {font-family:"Cambria Math";panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv4562165256 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv4562165256 #yiv4562165256 p.yiv4562165256MsoNormal, #yiv4562165256 li.yiv4562165256MsoNormal, #yiv4562165256 div.yiv4562165256MsoNormal {margin:0cm;margin-bottom:.0001pt;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv4562165256 a:link, #yiv4562165256 span.yiv4562165256MsoHyperlink {color:#0563C1;text-decoration:underline;}#yiv4562165256 a:visited, #yiv4562165256 span.yiv4562165256MsoHyperlinkFollowed {color:#954F72;text-decoration:underline;}#yiv4562165256 span.yiv4562165256StileMessaggioDiPostaElettronica17 {font-family:"Calibri", sans-serif;color:windowtext;}#yiv4562165256 .yiv4562165256MsoChpDefault {font-family:"Calibri", sans-serif;} _filtered #yiv4562165256 {margin:70.85pt 2.0cm 2.0cm 2.0cm;}#yiv4562165256 div.yiv4562165256WordSection1 {}-->
Hello Diameter experts and funs,
I have a question on the interpretation of RFC 6733.
I have a Client Diameter that opens many Diameter Connections with different Origin-Hosts and the same Origin-Realm.
The Client need to send AAR in session with maintained state to a Server.
Where a Diameter Server will send requests in session such as RAR or ASR?
The Destination-Host-AVP must be valued with the Origin-Host-AVP of the AAR sent by the client or a different Destination-Host-AVP can be chosen by realm?
What would happen if the diameter connection will fell and lost?
The Diameter Server must/can/cannot choose to send the request to a different Destination-Host-AVP of the same Client Realm?
I cannot understand where is the limit between protocol rules and custom policy local develop solution.
Thank you.
 Internet Email Confidentiality Footer ** La presente comunicazione, con le informazioni in essa contenute e ogni documento o file allegato, e' rivolta unicamente alla/e persona/e cui e' indirizzata ed alle altre da questa autorizzata/e a riceverla. Se non siete i destinatari/autorizzati siete avvisati che qualsiasi azione, copia, comunicazione, divulgazione o simili basate sul contenuto di tali informazioni e' vietata e potrebbe essere contro la legge vigente (ad es. art. 616 C.P., D.Lgs n. 196/2003 Codice Privacy, Regolamento Europeo n. 679/2016/GDPR). Se avete ricevuto questa comunicazione per errore, vi preghiamo di darne immediata notizia al mittente e di distruggere il messaggio originale e ogni file allegato senza farne copia alcuna o riprodurne in alcun modo il contenuto. Al link seguente e' disponibile l'informativa Privacy: ** This e-mail and its attachments are intended for the addressee(s) only and are confidential and/or may contain legally privileged information. If you have received this message by mistake or are not one of the addressees above, you may take no action based on it, and you may not copy or show it to anyone; please reply to this e-mail and point out the error which has occurred. Click here to read your privacy notice:
DiME mailing list