[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

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
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)

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:
https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?

[Dime] Roman Danyliw's No Objection on draft-ietf… Roman Danyliw via Datatracker