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

Steve Donovan <srdonovan@usdonovans.com> Thu, 07 April 2016 13:19 UTC

Return-Path: <srdonovan@usdonovans.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7D11112D90F for <dime@ietfa.amsl.com>; Thu, 7 Apr 2016 06:19:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wmbCrNE2cOz5 for <dime@ietfa.amsl.com>; Thu, 7 Apr 2016 06:19:53 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1CBC12D1B9 for <dime@ietf.org>; Thu, 7 Apr 2016 06:19:50 -0700 (PDT)
Received: from [] (port=60890 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from <srdonovan@usdonovans.com>) id 1ao9qd-0017yL-Oz for dime@ietf.org; Thu, 07 Apr 2016 06:19:50 -0700
From: Steve Donovan <srdonovan@usdonovans.com>
To: "dime@ietf.org" <dime@ietf.org>
Message-ID: <57065E70.3030908@usdonovans.com>
Date: Thu, 07 Apr 2016 10:19:44 -0300
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------040309090706090201030605"
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/RgSIb79tM4lxTRdlh8fBADSOR3I>
Subject: [Dime] Questions on draft-ietf-dime-group-signaling-06.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 07 Apr 2016 13:19:54 -0000


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




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.