[core] Review of draft-tiloca-core-oscore-discovery-05

Jim Schaad <ietf@augustcellars.com> Sat, 06 June 2020 02:08 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF703A0834; Fri, 5 Jun 2020 19:08:23 -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 DTWHBTdcs-mj; Fri, 5 Jun 2020 19:08:22 -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 01D253A0837; Fri, 5 Jun 2020 19:08:21 -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; Fri, 5 Jun 2020 19:08:15 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: draft-tiloca-core-oscore-discovery@ietf.org
CC: core@ietf.org
Date: Fri, 05 Jun 2020 19:08:13 -0700
Message-ID: <000001d63ba7$56bcf690$0436e3b0$@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: AdY6+1VNjaQKSzvxRNGQND+yEpPCwg==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/h62d2c2mYmG43ykz52KvbbEpgDc>
Subject: [core] Review of draft-tiloca-core-oscore-discovery-05
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Jun 2020 02:08:24 -0000

*  Consistently through this document you refer to an OSCORE group, however
the groupcom-bis document talks about a security group.  At some point these
need to be related.  Should you just be talking about security groups?

* Why do you believe that the group manager is going to know what
application groups are associated with any given OSCORE group.   I don't
believe that this information is being specified anyplace as being provided
to the GM.  Does it make sense to register the three different groups that
are from the bis document and make things flow the way one would expect from
a device point of view  Application Group => Security Group, Application
Group=> CoAP Group.  I assume that both clients and servers are going to
know they want to deal with a specific application and start from there.  I
don't know what an application itself as a root node would look like in the
RD.

* I do not understand "Values registered as a string that look like an
integer are not supported".  I need an example for what you are talking
about.  I would have expected that alg=-2 and alg="-2" would both be legal,
but "-2" is a required to be supported since it is a text string per the
definition above.

* I need to get some help.  What is the difference, both theoretical and
factual, between the if= and rt= links.  How much of this should be if= vs
rt= because it is common amount all expected group managers as oppose to
just the Ace group manager.

* In the example in section 3.1 - I don't know that the GM should be the one
registering the "rel" links here.  That should be up to the endpoint
instead.  Perhaps break this up into a POST and a GET?

* In section 5, I believe that the registration of the endpoints is
incorrect.  You are doing this in two steps, but the first registration is
going to be replaced not augmented by the second registration.  You need to
do a single registration here.

* In section 5 - It seems relatively obvious how you deal with an OSCORE
group having multiple applications, but I think you need to have some
discussions on how you deal with an application which has multiple OSCORE
groups in it.

Jim