[core] comments on CORECONF drafts in WGLC

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 30 March 2020 16:22 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id BDFE23A182A for <core@ietfa.amsl.com>; Mon, 30 Mar 2020 09:22:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.012
X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id HG8YQnjaqz_G for <core@ietfa.amsl.com>; Mon, 30 Mar 2020 09:22:32 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360933A0CC7 for <core@ietf.org>; Mon, 30 Mar 2020 09:22:29 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca []) by tuna.sandelman.ca (Postfix) with ESMTP id C81333897E for <core@ietf.org>; Mon, 30 Mar 2020 12:20:54 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5BDB8451 for <core@ietf.org>; Mon, 30 Mar 2020 12:22:23 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: core@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Mon, 30 Mar 2020 12:22:23 -0400
Message-ID: <26233.1585585343@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/YSnbdQ2empFanbcTLuqqkC-7UQg>
Subject: [core] comments on CORECONF drafts in WGLC
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: Mon, 30 Mar 2020 16:22:35 -0000

Hi, I have read:

— draft-ietf-core-yang-cbor-12
— draft-ietf-core-sid-11

I have implementation experience, and I've used these in other protocols, and
I strongly agree that they are ready for publication!

I read the COMI document some time ago, and I thought the approach was
fine.  I do not have any implementation experience, so I have no attempted to
understand the document at that level of detail.
I would have liked to use COMI directly as part of ietf-6tisch-minimal-security's
CoJP, but we would up creating a bespoke CBOR encoding, which is unfortunate.

I suggest that the COMI document include the word "CORECONF" in it's title.
  -> "CoAP Management Interface (CORECONF)"
as I think that it is the starting document that leadds to the other three
documents.  This will make it easier to find in rfc-index.txt.

The security considerations, and authorization for this system is
underspecified.  This was ultimately was killed SNMPv2, and led to a
multi-decade long failure of SNMPv3.
I suspect that this part will have a difficult time with security ADs.

I think that a stronger link to ACE, is in order, and an introspective
interface (using COMI!) into the authorization mechanism would help.
This could be new work, and I suspect that there are many in t2trg and out in
industry groups like OCF and CHIP that would like to have such a thing, but
it is a non-trivial amount of work.

I read draft-ietf-core-yang-library-01 when it was adopted.
I have *no* expertise on the YANG in this document, and I have no expertise
building network management systems that would need to this level of introspection.

As I understand it, this module provides a constrained version of
ietf-yang-library, the purpose of both is to describe which modules a device

I have no experience with introspection of devices like this, even doing
SNMPv2 going back decades: it either worked or it didn't, usually it didn't,
and one just guessed what the device supported, or read the manual.

I understand the goals here, but I'm not certain, particularly in a
constrained *network* that there is value in doing this.  I think that I'd
rather get this information from a URL provided in an RFC8520 (MUD).
I don't object to it though.

I wonder if queries against this module could be answered with static
content generated at compile time, and therefore from "ROM"?

I disagree with the Security Considerations, that knowing the list of
modules helps the attacker to the extent that it is important to provide
specific read controls on it.  Attackers already have a copy of the ROM ;-)
I would say that the entire COMI interface needs authorized read access, and
this module no more than any other module.

I think that there might be future opportunities to link some of this work to
the SUIT work, to the CoSWID work, and maybe to the RATS work.

Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-