[Ace] Review draft-tiloca-ace-oscore-gm-admin-01

Jim Schaad <ietf@augustcellars.com> Sun, 07 June 2020 16:22 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E26B3A09B7; Sun, 7 Jun 2020 09:22:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ps-8xDwXRc2k; Sun, 7 Jun 2020 09:22:19 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A91273A09B5; Sun, 7 Jun 2020 09:22:19 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 7 Jun 2020 09:22:13 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: draft-tiloca-ace-oscore-gm-admin@ietf.org
CC: ace@ietf.org
Date: Sun, 07 Jun 2020 09:22:08 -0700
Message-ID: <005b01d63ce7$cbedce80$63c96b80$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdY8RN4g59y7y0TwSfGpg4nfNi820w==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/q55WDjJLdEMVvI0bV7k_VrzRgIY>
Subject: [Ace] Review draft-tiloca-ace-oscore-gm-admin-01
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Jun 2020 16:22:22 -0000

* Does 'joining_path' contain the path or the full URI to the joining
resource.  Is it possible for the Group Manager Administration to be on a
different server (or via a different address) from the Group Manager itself?
Path tends to me to say only path.

* Section 2.3.2.1 - I think it makes more sense to make all of the defaults
to the groupcomm draft from ACE for OSCORE.  Since this is for managing
those types of groups, it should be that document which gets to set the
defaults.  If it wants to refer back to the same documents that is fine, but
it should be that the defaults can change based on changing that document.

* Section 2.3.2.2 - I think there may be a difference between an empty
string and an absent string for group_title.  Just verifying that what you
want is an empty string.

* Section 2.4.1 - I am not sure why this is a subsection of 2.4.

* Section 2.5.3 - What does "or is not fine to consider for tis OSCORE
group" in bullet #4 list #2?  Is this implying some type of judgement on the
part of the AS based on parameters in the group definition or the expected
usage of the group?

* Section 2.5.3 - I think it might make sense to return at least some of the
information in the return value of the POST such as the "joining_path" and
the "as_uri" because just the management path is not sufficient to be able
to start populating the RD.

* Section 2.5.3 - An interesting question - Should it be allowable for the
name to be different between the management and the group key nodes?  I
would like to see some type of discussion at least on the mailing list.
Doing the search on the join path would result in the same answer and little
additional penalty since I doubt that GM Admin clients are going to be
constrained.

* Section 2.5.5 -  The second paragraph makes zero sense to me.  The third
paragraph should just be talking about the update message and not mixing the
create and update messages together.

* Section 2.5.5.2 - I have read this section twice and I still do not think
I understand what is going on here.  How much of this is needed and how much
is extraneous?  Is there some simplification that can be used to make this
easier?

Jim

s/fowllowing/following/