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

Barry Leiba via Datatracker <noreply@ietf.org> Sun, 31 January 2021 19:57 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 7BB143A11FB; Sun, 31 Jan 2021 11:57:38 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba 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.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <161212305848.21181.8553749177220111509@ietfa.amsl.com>
Date: Sun, 31 Jan 2021 11:57:38 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/bqRFP2JCh0WIq5C7ihIEpKh3xXs>
Subject: [Dime] Barry Leiba'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: Sun, 31 Jan 2021 19:57:39 -0000

Barry Leiba 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:


I have to say that I found this to be challenging to read: much of it is very
dense, with paragraphs giving sometimes-subtly-different conditions, and I
would be reading it thinking, “Does this paragraph apply to my situation?  I
don’t think so, but what about the next one?  Wait, maybe it was the other one
after all.”  I just have to assume that someon actually implementing Diameter
would have an easier time following it.

I have some editorial comments that won’t help with that aspect, but that I
hope will help with clarity in general:

— Section 3.1 —

   A session group, which has sessions assigned, can be deleted, e.g.,
   due to a change in multiple users' subscription profile so that the
   group's assigned sessions do not share certain characteristics

It appears that “has sessions assigned” is restrictive (it’s a required
description, not just extra information).  If so, it should say, “A session
group that has sessions assigned can be deleted, e.g., due to...” without the
internal commas.

Another way to put it might be, “A session group can be deleted even if it has
sessions assigned, e.g., due to...”

— Section 3.3 —

   This specification follows the most flexible model where both, a
   Diameter client and a Diameter server can create a new group and

Nit: no comma here

   Either the client and the server
   can assign a session to a group.

Nit: “Either the client or the server can”, or “Both the client and the server

   Details about
   enforcing a more constraint permission model

I think the word you want is “constrained”.

— Section 4.2 —

   Diameter AAA
   applications typically assign client and server roles to the Diameter
   nodes, which are referred to as relevant Diameter nodes to utilize
   session grouping and issue group commands.

I’m having trouble parsing this sentence and determining what you’re trying to
tell me.  Can you please rephrase or repunctuate it to make it clearer?  What
are referred to as “relevant Diameter nodes”?  What goes with “to utilize
session grouping”?

   Diameter nodes, which are group-aware, MUST store and maintain an
   entry about the group assignment together with a session's state.

Similar to earlier: is “are group aware” meant to be restrictive (there are
Diameter nodes that are group aware and those that are not, and you’re talking
about the former), or non-restrictive (all Diameter nodes are group aware, and
you’re just pointing that fact out).  It is currently written as
non-restrictive, but I think you mean it to be restrictive.  If that is
correct, remove both commas and change “which” to “that”.

   A Diameter node MUST also keep a record about sessions, which
   have been assigned to a session group by itself.

The comma shouldn’t be there, and “which” should be “that”.  But it’s a bit
awkward anyway: may I suggest rephrasing in active voice as, “Each Diameter
node MUST also keep a record about sessions that it has assigned to a session

— Section 4.2.1 —

   If the
   response from the server indicates success in the result code but
   solely the assignment of the session to a session group has been
   rejected by the server, the client treats the session as single
   session without group assignment.

What does “solely” mean in this sentence?

   A Diameter client, which sent a request for session initiation

Please remove the comma (and change “which” to “that”).

— Section 4.2.2 —

   The session, which is to be removed from a group, is

Make it, “The session that is to be removed from the group is”

   When a Diameter client decides to remove a session from all session
   groups, to which the session has been previously assigned,

Remove the comma after “groups”.

   The session, which is to be removed from all groups, to
   which the session has been previously assigned, is identified in the
   Session-Id AVP of the command request.

Make it, “The session that is to be removed from all groups to which it had
been previously assigned is identified in the Session-Id AVP of the command

— Section 7.3 —

   <DiameterIdentity> portion of the Session-Group-Id MUST identify the
   Diameter node, which owns the session group.

Please remove the comma and change “which” to “that”.