[Ace] Comments about draft-dijk-core-groupcomm-bis-00

Jim Schaad <ietf@augustcellars.com> Tue, 28 May 2019 22:44 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 B37371200A4; Tue, 28 May 2019 15:44:47 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 5ZE1pNG7BNck; Tue, 28 May 2019 15:44:46 -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 B3A71120090; Tue, 28 May 2019 15:44:42 -0700 (PDT)
Received: from Jude (192.168.1.155) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 28 May 2019 15:44:36 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: draft-dijk-core-groupcomm-bis@ietf.org
CC: ace@ietf.org
Date: Tue, 28 May 2019 15:44:33 -0700
Message-ID: <017f01d515a6$ed172890$c74579b0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AdUUNPLwUpqoK9aaSuCnTZIzn4sN5w==
X-Originating-IP: [192.168.1.155]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/6mnrYDx57MbdYXhhBA0sN5QBYCo>
Subject: [Ace] Comments about draft-dijk-core-groupcomm-bis-00
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: Tue, 28 May 2019 22:44:48 -0000

Comments on this draft.

1.  I have an existential problem with this document.  This is a standards
track document that is claiming to do an update to an experimental draft.
However, this is something that I would not expect to be done and it is not
clear just what the updates to that document are and how one would make
edits to that document in order to apply the updates.   My general
expectation for an experimental document is that it would be 1) declared a
failure and killed, 2) declare a partial success and updated for a new
experiment (and thus a new experimental document) or 3) declare a resounding
success then replaced with either a standards or information document.  

2.  You are claiming to update RFC 7641, but it is not clear to me what is
being updated and just what the implications of doing this update are.  As
an example of the types of thing that should be clarified are:
*  If a server does not return a response, should it setup to do a later
observe operation?
*  More information on how correlation should be done with responses.  As an
example, if you do unary observe and the response is routed through a proxy,
there are no problems as long as the responses are not later re-routed
through a new proxy.  However for multicast, if you have two different
servers on the far side of a proxy how does one distinguish between the two
of them if everything is coming through a single proxy?

3.  The introduction does not acknowledge that the same thing can be done
via pub-sub.  It is ok to declare this out of scope but it needs to be done
in up front in the introduction (and probably also in the abstract).

4.  I am not sure that it makes sense to say one should be familiar with
terms from Group OSCORE as one would expect this to be from the general to
the specific for terminology not the other way around.

5.  In section 2.1.1 - you should state that the centralized directory would
be pre-configured in the device.

6. In section 2.1.1 - Do we have any set of properties that are commonly
defined for doing this?  Services in the form of resources are easy to
understand but I don't know how to do this easily.

7. In section 2.3 - It would make sense to distinguish between the cases of
announcing a software update is available and actually distributing the
software update by multicast.

8. Section 3.1.1 - It should potentially be stated here, but definitely
somewhere that for non-secure groups membership in the group is defined by
an endpoint and not by a central endpoint.  This is important in terms of
somebody "attacking" a non-secure group.

9.  Section 3.1.2 - It would make sense to point to group naming as part of
a directory as well as being for DNS.  

10.  Section 3.1.3 - One of the things that I had a problem with when
implementation group broadcast was trying to decide which of the different
local groups should be used for an IPv6 multicast address.  A number of
these different groups are defined for CoAP and a discussion of the
differences or a pointer to the differences would be useful.

11. Section 3.2.1 - Another issue to highlight with tokens is that in the
unicast case, the response is expected to come in on the same connection it
was sent on.  Thus two different connections can re-use the same token
without any problems.  That is not true for multicast as the connection it
comes it on will, by definition, not be the one it was sent on.

12. Section 3.2.1 - Might want to mention the use of Accept as one way to
think about server response delay as you at least know that you are
expecting a response from the server if you have received an accept.

13. Section 3.2.3 - Need to talk about multicast messages, proxies and
caching of results.

14. Section 3.2.5 - Does RFC7641 define behavior about receiving a
"duplicate" observer request?  Would you reply a second time or not? 

15. Section 6.1 - next to last paragraph - /values does not/values, but does
not/

16. Section 6.2 - Should have a consideration about the speed of re-keying
vs the frequency of joins/leaves.

Jim