[Dime] Roman Danyliw's No Objection on draft-ietf-dime-group-signaling-13: (with COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 03 February 2021 21:12 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dime@ietf.org
Delivered-To: dime@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4140B3A1162; Wed, 3 Feb 2021 13:12:58 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dime-group-signaling@ietf.org, dime-chairs@ietf.org, dime@ietf.org, jounikor@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.25.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <161238677779.11599.14411757834277525186@ietfa.amsl.com>
Date: Wed, 03 Feb 2021 13:12:58 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/XGDDq3GKC2FOH-_Jq_-TtE4RAHI>
Subject: [Dime] Roman Danyliw's No Objection on draft-ietf-dime-group-signaling-13: (with COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 03 Feb 2021 21:12:58 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-dime-group-signaling-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Thanks to Catherine Meadows for the SECDIR review.

** Section 3.3.  I had trouble reconciling the generic design principles
espoused here with the more detailed specification of the protocol documented
in Section 4.*.

The text here says:

This specification follows the most flexible model where both, a
   Diameter client and a Diameter server can create a new group and
   assign a new identifier to that session group.

And the table in this section says that the client could assign itself to a
server owned session group.

Assign a Session to a non-owned Session Group   |    X   |    X   |

However, in Section 4.2.1

  If the Diameter server receives a command request from a Diameter
   client and the command includes at least one Session-Group-Info AVP
   having the SESSION_GROUP_ALLOCATION_ACTION flag in the Session-Group-
   Control-Vector AVP set, the server can accept or reject the request
   for group assignment.

It seems to me that this text in Section 4.2.1 is suggesting that the client
could ask to be put into a group but the server has the ability reject it,
which seems like an implicit permission model.

** Section 7.  In the table in this section the Session-Group-Id is of type
OctetString, but in Section 7.3 it is UTF8String.

** Section 10.  Given the flexible permission model suggested in Section 3.3,
is cautionary guidance needed to say that specific applications using this
capability need to consider the decisions they make based on group membership?