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

Barry Leiba <barryleiba@computer.org> Mon, 01 March 2021 14:50 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A293A1D76; Mon, 1 Mar 2021 06:50:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZD9PQ5Vze2fk; Mon, 1 Mar 2021 06:50:41 -0800 (PST)
Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EA023A1D7C; Mon, 1 Mar 2021 06:50:41 -0800 (PST)
Received: by mail-lf1-f46.google.com with SMTP id v9so8137979lfa.1; Mon, 01 Mar 2021 06:50:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QeVQhkFZ7ov9UvfzTwkJF5mway57uHmc0f9dOC/S5lQ=; b=QQxTx6yqi3zRpFsIMo4UhckI6bBMNhheMx0lVboAfexbl+berVC8kcf6tdGQvVOuNs PDop13z5Q6TWwc1DandTqNFTNzo6c/socRZ7Z6sVDa9+itxuGR1CIMRTCc+63GWkeHy4 ZipEMvGDVJ7+6d0GH5yzukUVxd7EOFbSPQZs5XzbXExshEMiUJegzrQtvHvPGTSKgQEv 9kV9f533EY9BLPd+XvZUGyIWBC7VBObSno/rBeV29tuNjruW5+g/6ZQj2Tquqtu24NKe nRH0PA6bevqBFRtQD7fny/97DXDoPGpZkJ9YSvMoYX3EckFIUlHnmDecrgCfiCxs4P2B ftqg==
X-Gm-Message-State: AOAM531m/FmsHqJLIRYLMeaNukfGs+V7C2BW+1HuFk3cz3rX09akSx4X A8QHYjZy8NixTTBOITg0R8orBRUpNmqFPYbODhs=
X-Google-Smtp-Source: ABdhPJyWf4zDLSdDI9LOUpxqB2Qnp2fRG0qNkDPZxiJCY1qrO8l8bgv3vLc9JpGQV2MOdB5CuTORodvbxu6VUlzbCqg=
X-Received: by 2002:a19:2242:: with SMTP id i63mr7900447lfi.643.1614610238469; Mon, 01 Mar 2021 06:50:38 -0800 (PST)
MIME-Version: 1.0
References: <161212305848.21181.8553749177220111509@ietfa.amsl.com> <38aacde1-aa19-c193-23e1-c71a14173e06@azu.ca>
In-Reply-To: <38aacde1-aa19-c193-23e1-c71a14173e06@azu.ca>
From: Barry Leiba <barryleiba@computer.org>
Date: Mon, 01 Mar 2021 09:50:27 -0500
Message-ID: <CALaySJKD4beeyFe_-+B6avNfJbN=Ug8fdCfMFHosxV9M24AGow@mail.gmail.com>
To: Mark Jones <mark@azu.ca>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dime-group-signaling@ietf.org, dime-chairs@ietf.org, dime@ietf.org, jounikor@gmail.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/nRKqheSQS7vQHfbEJpWX2RVKY3g>
Subject: Re: [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
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: Mon, 01 Mar 2021 14:50:44 -0000

Thanks, Mark.  I've reviewed your proposed changes and they all look
good.  Thanks for the response and for considering my comments.

Barry

On Tue, Feb 23, 2021 at 1:19 PM Mark Jones <mark@azu.ca> wrote:
>
> Appreciate the thorough review, Barry. Comments inline below.
>
> On 2021-01-31 2:57 p.m., Barry Leiba via Datatracker wrote:
> > 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:
> > https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > 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...”
> >
>
> We intended to say that a session group can be deleted and provide an example.
> The concept of "group" is clearly introduced in the paragraph just above and the
> details are provided in the subsequent sections. We propose the following
> rephrasing:
>
> "It may be required to delete a session group, e.g. at the expiry of a
> promotional period that applied to multiple subscriber profiles".
>
>
> > — 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
> > can”.
> >
>
> Suggested wording:
> "This specification allows a permissive model where either Diameter client or
> Diameter server can create a new group. The creator of the group becomes the
> group owner and assigns a new identifier to the group according to the rules in
> Section 7.3."
>
>
> >    Details about
> >    enforcing a more constraint permission model
> >
> > I think the word you want is “constrained”.
> >
>
> Agreed. Addressed in the next revision.
>
> > — 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”?
> >
>
> We agree that it needs rephrasing and propose:
> "Although Diameter is a peer-to-peer protocol, Diameter AAA applications
> typically assign the role of "Diameter client" to the Diameter node initiating
> the Diameter session and the role of "Diameter server" to the Diameter
> node authorizing the Diameter session. This specification does not restrict
> group creation, assignment or deletion actions to a specific role. In the
> following sections, Diameter node is used to refer to either role."
>
>
> >    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”.
> >
>
> We propose rephrasing to:
> "Any Diameter node that has advertised support of session grouping and group
> operations MUST store and maintain the group assignment as part of the session's
> state."
>
>
> >    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
> > group.”
> >
>
> Agree with suggested rephrasing. Will implement in the next revision.
>
> > — 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?
> >
>
> It should have been "only". However, we believe this sentence has been made
> redundant by previous edits and can now be removed. The previous sentence
> already states that the client MUST remove the session from the group if the
> server rejects the proposed assignment. The session then proceeds as if it were
> not assigned to the group.
>
> >    A Diameter client, which sent a request for session initiation
> >
> > Please remove the comma (and change “which” to “that”).
> >
>
> We propose the following rephrasing:
>
> "If a Diameter client sends a request for session initiation containing one or
> more Session-Group-Info AVPs but the response from the Diameter server does not
> contain a Session-Group-Info AVP, the Diameter client MUST proceed as if the
> request was processed without group assignments."
>
>
> > — 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”.
> >
>
> Agreed. Fixed in next revision.
>
>
> >    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
> > request.”
> >
>
> We came up with the following rephrasing to improve the readability:
> "The Session-Id AVP in the re-authorization request identifies the session that
> is to be removed from all groups to which it had been previously assigned."
>
> > — Section 7.3 —
> >
> >    The
> >    <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”.
> >
>
> Agreed. Will be fixed in next revision.
>
>
> ./Mark