Re: [Dime] open issues #1 in DOIC

["Shishufeng (Susan)" <[e-mail]>]

Fine for me.

Best Regards,
Susan

From: Maria Cruz Bartolome [mailto:[e-mail]]
Sent: Tuesday, December 03, 2013 12:13 AM
To: [e-mail]
Subject: Re: [Dime] open issues #1 in DOIC

Looks fine to me

MCruz

From: DiME [mailto:[e-mail]] On Behalf Of Steve Donovan
Sent: lunes, 02 de diciembre de 2013 16:45
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [Dime] open issues #1 in DOIC

Agreed, looks good.

Steve
On 11/29/13 4:04 AM, Jouni Korhonen wrote:



Would work for me.



- Jouni



On Nov 29, 2013, at 11:48 AM, [e-mail]<mailto:[e-mail]> wrote:



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:[e-mail]]

Envoyé : vendredi 29 novembre 2013 10:01

À : MORAND Lionel IMT/OLN

Cc : [e-mail]<mailto:[e-mail]> 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, [e-mail]<mailto:[e-mail]> 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:[e-mail]] De la part de Jouni Korhonen

Envoyé : vendredi 29 novembre 2013 09:30

À : [e-mail]<mailto:[e-mail]> 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

[e-mail]<mailto:[e-mail]>

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.





_______________________________________________

DiME mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/dime