Subject: [Dime] Review of draft-ietf-dime-group-signaling-04.txt

From: Steve Donovan <[email-masked]>
Date: Fri, 31 Oct 2014 11:22:24 -0500

The following are my comments and questions resulting from a review of 
draft-ietf-dime-group-signaling-04.txt

General comments:

- The draft uses the term Diameter peer frequently in a way that does 
not seem to be correct.  A Diameter peer is defined to be a Diameter 
node with a direct connection.  The group signaling mechanism doesn't 
depend on communicating with a true Diameter peer.  It would be better 
to have a different term.

- The document might flow better if capability discovery was discussed 
before the session grouping logic, as session grouping depends on 
capability discovery.  Just a personal preference.

- Are there use cases identified that require supporting a session being 
in an unlimited number of session groups?  This is probably an 
application specification issue, but putting a session in multiple 
groups appears to be pretty complicated to manage if all of the sessions 
in a group need to be in the same "application session state".

- It seems dangerous to not allow a server to reject new group 
assignments.  What happens if the server is out of resources for 
managing groups?

Table in section 3.0

- First operation - Why is the peer the owner of the group, I thought 
the creator is the owner of the group.
- Seventh operation - Why is this needed?  Isn't this the same as 
operation six.
- Eighth operation - Similar question.
- Last operation - If I can delete all sessions in a group owned by my 
peer, why can't I just delete the session group as a whole?

Section 4.1.1

- Isn't server creation of Session Groups dependent on the client 
supporting session groups?

- Paragraph 5 - Shouldn't it also be possible for the server to create 
groups even if the client creates none (assuming the client supports 
groups)?

- Second to last paragraph is not needed.  A server that is RFC6733 
compliant will always do as this says.

- The last paragraph indicates how clients fall back to doing single 
session commands.  There doesn't seem to be a mechanism for a server to 
do the same.

Section 4.4

- The processing implies that the requested operation is applied to all 
sessions in all specified groups before an answer is sent.  How likely 
is this to cause transactions to time-out and be retried?

Section 5

- Second paragraph - Why MUST the proxy maintain consistency of session 
groups between clients and servers?  What if the session groups are only 
meaningful between the client and the proxy?

That's all for now.

Regards,

Steve