[Dime] Questions on draft-ietf-dime-group-signaling-06.txt

[Steve Donovan <[e-mail]>]

All,

I have the following questions and comments on the Diameter group 
signaling draft.

Regards,

Steve

-----

General comment - Use of RFC 2119 is not consistent.  There are a number 
of places where lower case must is used, for instance.  It would be 
better to either make those upper case, if that is appropriate, or use a 
different word.

In section 4.2.*

For the case:

    If the Diameter server receives a command request from a Diameter
    client and the command comprises at least one Session-Group-Info AVP
    having the SESSION_GROUP_ALLOCATION_ACTION flag set in the Session-
    Group-Control-Vector AVP set, the server can accept or reject the
    request for group assignment.  Reasons for rejection may be e.g. lack
    of resources for managing additional groups.  When rejected, the
    session must not be assigned to any session group but be treated as
    single session.


Should we say the the client SHOULD retry the request without the 
session-group AVPs?

For the case:

    If the Diameter server accepts the client's request for a group
    assignment, the server must assign the new session to each of the one
    or multiple identified session groups when present in the Session-
    Group-Info AVP.  In case one or multiple identified session groups
    are not already stored by the server, the server must store the new
    identified group(s) to its local list of known session groups.  When
    sending the response to the client, e.g. a service-specific auth
    response as per NASREQ AA-Answer [RFC4005], the server must include
    all Session-Group-Info AVPs as received in the client's request.

What if one of a set of session group addition commands fails at the 
server?  Is it all or nothing, meaning that if the server can't add the 
session to all requested session groups then it must reject the 
request?  Also, should the first must in the paragraph be MUST?

For the case:

    If the Diameter client receives a response to its previously issued
    request from the server and the response comprises at least one
    Session-Group-Info AVP having the SESSION_GROUP_ALLOCATION_ACTION
    flag of the associated Session-Group-Control-Vector AVP set, the
    client MUST add the new session to all session groups as identified
    in the one or multiple Session-Group-Info AVPs.

What if the a session group addition fails at the client?  Should the 
client terminate the session at that point for force the session-group 
state in sync?

For this case:

    A Diameter client, which sent a request for session initiation to a
    Diameter server and appended a single or multiple Session-Group-Id
    AVPs but cannot find any Session-Group-Info AVP in the associated
    response from the Diameter server proceeds as if the request was
    processed for a single session.


Does the client continue to include Session-Group AVPs or should the 
client explicitly remove the session from the session group?

In section 4.4.1

The use of the Group-Response-Action AVP is not clear.  Why would a node 
put a session in a group and then request it to be treated separately?

It would help to have some motivational text for why this is needed.

In section 4.4.3

For the case:

    When a Diameter node receives a request to process a command for one
    or more session groups and the result of processing the command
    succeeds for some sessions identified in one or multiple session
    groups, but fails for one or more sessions, the Result-Code AVP in
    the response message SHOULD indicate DIAMETER_LIMITED_SUCCESS as per
    Section 7.1.2 of [RFC6733].  In case of limited success, the
    sessions, for which the processing of the group command failed, MUST
    be identified using a Failed-AVP AVP as per Session 7.5 of [RFC6733].


What happens to the groups that were successfully set up?  Should the 
client fall back to single session in this case as well?

For section 5

I'm not convinced that the signaling, as defined is complete enough to 
ensure that a proxy can be guaranteed to have accurate session-group 
state.  For the same reason, it also feels like clients and servers can 
end up with different views of session-group state.