Re: [Dime] open issues #1 in DOIC

<lionel.morand@orange.com> Fri, 29 November 2013 09:48 UTC

Return-Path: <lionel.morand@orange.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F384F1AC7F1 for <dime@ietfa.amsl.com>; Fri, 29 Nov 2013 01:48:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.899
X-Spam-Level:
X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecPbj_PRkDGW for <dime@ietfa.amsl.com>; Fri, 29 Nov 2013 01:48:17 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id BB7361A1F55 for <dime@ietf.org>; Fri, 29 Nov 2013 01:48:16 -0800 (PST)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id BFD551900D8; Fri, 29 Nov 2013 10:48:14 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 0A3A2158061; Fri, 29 Nov 2013 10:48:14 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Fri, 29 Nov 2013 10:48:13 +0100
From: <lionel.morand@orange.com>
To: Jouni Korhonen <jouni.nospam@gmail.com>
Thread-Topic: [Dime] open issues #1 in DOIC
Thread-Index: AQHO7N0388Z4Ak2nq0as3rZt2kE0jJo74RCA///3XwCAABTMoA==
Date: Fri, 29 Nov 2013 09:48:12 +0000
Message-ID: <3468_1385718494_529862DE_3468_4222_1_6B7134B31289DC4FAF731D844122B36E309600@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <5E28C8B7-2E5E-41E8-9592-24A19AD76826@gmail.com> <9889_1385714340_529852A4_9889_16410_1_6B7134B31289DC4FAF731D844122B36E3093B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52EDD6D4-71CD-439F-9D2D-439CC656C3CC@gmail.com>
In-Reply-To: <52EDD6D4-71CD-439F-9D2D-439CC656C3CC@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.29.44815
Cc: "dime@ietf.org list" <dime@ietf.org>
Subject: Re: [Dime] open issues #1 in DOIC
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Fri, 29 Nov 2013 09:48:19 -0000

Actually, I realized that we are redefining something somehow already in use in RFC 6733:

9.6. Correlation of Accounting Records


   If an application uses accounting messages, it can correlate
   accounting records with a specific application session by using the
   Session-Id of the particular application session in the accounting
   messages.  Accounting messages MAY also use a different Session-Id
   from that of the application sessions, in which case, other session-
   related information is needed to perform correlation.

We could maybe reuse the same type of wording to simplify the definition:

Pseudo-session applications are applications that
do not rely on the Session-Id AVP for correlation 
of application messages related to the same session
but use another session-related information for this
purpose. The 3GPP defined Cx application [3GPP.29.229]
is an example of a pseudo-session application.

OK?

Regards,

Lionel

-----Message d'origine-----
De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Envoyé : vendredi 29 novembre 2013 10:01
À : MORAND Lionel IMT/OLN
Cc : dime@ietf.org list
Objet : Re: [Dime] open issues #1 in DOIC


   Pseudo-session applications:

      While this class of application does not use the Diameter
      Session-ID AVP to correlate requests, there is an implied ordering
      of transactions defined by the application and except for the
      Session-ID differences pseudo-session based applications are
      generally assumed to behave like session-based application.  The
      3GPP defined Cx application [3GPP.29.229] is an example of a
      pseudo-session application.


Would this suffice?

- Jouni



On Nov 29, 2013, at 10:38 AM, lionel.morand@orange.com wrote:

> Hi,
> 
> For me, "pseudo-session" refers to session-based oriented applications that do not rely on the session-id for message correlations but on something else e.g. user-name. So it is implied that the same server is contacted by the client managing the session. In the Cx example, the same origin-host will be used in the client-initiated requests after the initial exchange and the server discovery phase.
> 
> Regards,
> 
> Lionel 
> 
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
> Envoyé : vendredi 29 novembre 2013 09:30
> À : dime@ietf.org list
> Objet : [Dime] open issues #1 in DOIC
> 
> Folks,
> 
>           [OpenIssue: Do we assume that all requests in a pseudo-session
>           typically need to go to the same server?]
> 
> 
> The example here is in context of Cx. Not that I am expert on Cx (or anything)
> but based on the CCF the requests _may_ have destination-host. Thus, I assume
> that it is an implementation issue whether pseudo-sessions need to go to the
> same server.. I guess we cannot have such firm requirement. Correct?
> 
> - Jouni
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
> 


_________________________________________________________________________________________________________________________

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.