Subject: [Dime] draft-ietf-dime-group-signaling-04 feedback

From: Benoit Claise <[email-masked]>
Date: Tue, 22 Jul 2014 10:11:20 -0400

Hi Marco,

I didn't express myself correctly this morning: not enough coffee or 
maybe too many.

My high level points were:
- The draft doesn't mention that mid-session group assignment 
modifications is an exceptional case
- The draft is not intended for temporary groups

Another potential one, not discussed: The situation of policy conflict 
between Diameter client and Diameter server has to be handled by the 
application.

Regards, Benoit

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 22 Jul 2014 15:09:36 +0000

Hi Benoit,

please see inline.
From: Benoit Claise [mailto:[email-masked]]
Sent: Dienstag, 22. Juli 2014 16:11
To: Marco Liebsch
Cc: dime mailing list
Subject: draft-ietf-dime-group-signaling-04 feedback

Hi Marco,

I didn't express myself correctly this morning: not enough coffee or maybe too many.

My high level points were:
- The draft doesn't mention that mid-session group assignment modifications is an exceptional case
- The draft is not intended for temporary groups

A sessions may be added to one or multiple groups when it is established. Moving a session from
one group to another may happen less often, true. Important is that the specification supports and
describes the procedure for mid-session group modifications.
So your comment is to highlight that in the draft and classify how frequent a certain procedure
may happen ?

We may need to classify the term 'temporary'. A group ID's lifetime may be temporary and the
associated group identifier will be deleted accordingly when the group does not exists
anymore. Sessions, which had been assigned to this group, need individual treatment then.

Temporary in terms of a single command, I doubt it saves signaling costs, as adding/removing
a session to a group mid-session requires signaling.

Another potential one, not discussed: The situation of policy conflict between Diameter client and Diameter server has to be handled by the application.

Do you refer to the policy to manage groups and apply commands to a group ? The draft's permission model has
clear rules about which peer can add/remove a session to/from a group. Certain applications may constrain this
model even more, so true that the application, or better its specification, needs to handle potential conflicts.
Hope that addresses your point.

Best regards,
marco

Regards, Benoit