[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/
- [Ace] Review draft-tiloca-ace-oscore-gm-admin-01 Jim Schaad
- Re: [Ace] Review draft-tiloca-ace-oscore-gm-admin… Marco Tiloca