Re: [core] CoRE rechartering: proposed text

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 16 October 2021 22:57 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 15C673A0BD9 for <core@ietfa.amsl.com>; Sat, 16 Oct 2021 15:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 rzCRwniPV3o4 for <core@ietfa.amsl.com>; Sat, 16 Oct 2021 15:57:31 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36EC13A0BD5 for <core@ietf.org>; Sat, 16 Oct 2021 15:57:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3745D18294 for <core@ietf.org>; Sat, 16 Oct 2021 18:57:54 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QATvKEN9iKyu for <core@ietf.org>; Sat, 16 Oct 2021 18:57:53 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id ADF5318290 for <core@ietf.org>; Sat, 16 Oct 2021 18:57:53 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1CB47AC for <core@ietf.org>; Sat, 16 Oct 2021 18:57:27 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "core@ietf.org WG (core@ietf.org)" <core@ietf.org>
In-Reply-To: <290101ab-0022-0ed7-424e-dc5d6c73b401@ri.se>
References: <b91fb1fb-6d54-5594-2424-e1ca37d501f5@ri.se> <fe11a970-4750-1b58-eaed-1863fa0dfe48@ri.se> <AM8P190MB09799B48F4E50F7515BA60B8FDA09@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM> <290101ab-0022-0ed7-424e-dc5d6c73b401@ri.se>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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-sha512"; protocol="application/pgp-signature"
Date: Sat, 16 Oct 2021 18:57:27 -0400
Message-ID: <24137.1634425047@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/zDE0bUeRssTldMPEdqJv7s0Rvbw>
Subject: Re: [core] CoRE rechartering: proposed text
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, 16 Oct 2021 22:57:36 -0000

Hi, I commented on the pull request

> https://github.com/core-wg/core-wg.github.io/pull/1

In summary, I think that we have done a poor job at all of the DTLS things,
and we should have done more work with the TLS WG on this.
That might mean that the IESG needs, when removing this from our charter,
inserting it into the TLS WG charter.

for instance:
> * efficiency of DTLS as the basis for the communication security in CoAP


On the GroupCom security side, unless the work is about to be approved by the
IESG, then I think it should get another WG.  Alas, "short-lived WGs" can
take years to spin up, so I guess it will stay here.  I suggest that the WG
may wish to allocate alternating virtual interims to this in order to
establish a cadence and get the work finished.

Given the virtual interim cadence, I would like to discourage the WG from
holding meetings during the plenary week.

I see that senML document is at the IESG.
I think that if there is more work to do on SenML that it be done elsewhere.

> * optimization-oriented profiling of the EDHOC protocol to establish security material for OSCORE

Why can't LAKE do this?

> * with other IETF WGs, particularly of the constrained node networks
> cluster (6Lo, 6TiSCH, LWIG, ROLL, ACE, CBOR, COSE, IOTOPS, LAKE, SUIT,
> ASDF),

okay, but really are even doing anything explicit?
Can we even depend upon people being in all these groups given the conflicts?
That's partly what IOTOPS is *for*

> * continue and complete its work on the CoRE Resource Directory

Since we say that we want to be DNS-SD interoperable, I wonder if, at this
point, the work should be transferred to DNS-SD. I have seen no evidence that
we've consulted with DNS-SD.  Maybe I missed that part.

I think that any WG that tries to focus on more than three items will find
that really, it will focus is on zero items.  yang-cbor situation is what happens.




--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide