Re: [core] Simplify draft-ietf-core-comi-12.txt

Andy Bierman <> Sun, 19 March 2023 17:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD97DC14F748 for <>; Sun, 19 Mar 2023 10:04:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Dwq5Ij8nRoWK for <>; Sun, 19 Mar 2023 10:04:41 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 0CA36C14F73E for <>; Sun, 19 Mar 2023 10:04:41 -0700 (PDT)
Received: by with SMTP id q16so1364385lfe.10 for <>; Sun, 19 Mar 2023 10:04:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1679245479; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rA4iYw97fp1Qm7eKs12S5kkxW7C7Fs1uxAmITqrm0Ug=; b=PGzt/4wh5CfAl0nwpabeIIh6ABdiB0Ok/3s1UXcAU93i8f2CZcFmM6CNEpzo7BLs7S YXcEh7E1Qq9cIMuqflwIfc5keX8DocGpcgZr3gYkMIDgLk0ddLulpxr9ba6HSrV5U+i3 t9c2w6WZSRRr8YmBzlnqTE6+siXszHfaAOksGTDSp6mWGHOaOYZ3mQiDsVxH3gHGxSRN 0DzwX5XpjwuoIrTkR2JGX2P/hnqFMWCRYtYKaOxu7sjv/ugWX+KLu3rWa/NHanAScghr rq1deiKydjvPtWnow8PkHky6VB82ROM8ZNZVO7A+GR9NaY0+b8RKEj8K3xwIPhEZOKJJ 8ntQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; t=1679245479; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rA4iYw97fp1Qm7eKs12S5kkxW7C7Fs1uxAmITqrm0Ug=; b=mn3ihbrA//NpIimA1xfBxI6YPaSg7sCCFCGR/1322LmLE8gvDI4bqZvyrzQinMMebk 5BNi3BWGpHumU22a0BZ9nkf199SrCHBydvhtT48Ppjs2Y9tsilcJahFrseIuq9y9KakE lbTHxVGtKN61ZNH5lcHkIAwY76GO1BXoDCP/H4P3c6EaWjCom4v5nQ7qmdzFg4hDdEFv 6RGEFRJhi1AuBWDu5LElsKcO2IaJxLgr7Am83uojMemoBTy44hQQczA5Q0c5ehMWiZa1 le9KtOQu399D3b+hb378UFW5r6xhokYkWqMquYEa1FKgyov+kReOnoLzF1raCEUYw+tv ayyg==
X-Gm-Message-State: AO0yUKWXK69+jxLN0bZTjFgjf/u0rvgwS9B0tPXPIYyKyw/nMqJ03Zrk YfkPY1Az50QR43JjVUNukYS8Csy1krMQ9IS+jfbG+VDX8U+uA9Uy
X-Google-Smtp-Source: AK7set/3J7U3NXbi7UC6mkuJncb4FnKGDZhzY+cerkOSIcXKnRcsBkjkqUgKpNE6uQ4QQrF+5mVR3DGqfz4yXKJlqRE=
X-Received: by 2002:ac2:4c3c:0:b0:4e8:4518:6dbe with SMTP id u28-20020ac24c3c000000b004e845186dbemr6251273lfq.7.1679245478723; Sun, 19 Mar 2023 10:04:38 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Andy Bierman <>
Date: Sun, 19 Mar 2023 10:04:27 -0700
Message-ID: <>
To: Carsten Bormann <>
Cc: " WG (" <>
Content-Type: multipart/alternative; boundary="00000000000040150005f743cea7"
Archived-At: <>
Subject: Re: [core] Simplify draft-ietf-core-comi-12.txt
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 19 Mar 2023 17:04:45 -0000

On Sat, Mar 18, 2023 at 2:23 PM Carsten Bormann <> wrote:

> In the interim last Wednesday, we were seriously wondering why we need
> both GET/PUT/POST and FETCH/iPATCH for COMI.  The consensus of the room was
> that the easiest way to solve the problems with generating the URIs for
> GET/PUT/POST was to move over to FETCH/iPATCH completely.

I support the move to FETCH/iPATCH.
(We called it GET/SET back in the day ;-).

The CORE WG has reinvented SNMP and fixed almost everything wrong with it.

-  Varbinds can for any object, not just a leaf
-  Data Model is YANG (replacing legacy SMIv2)
-  Data retrieval is super-efficient instead of extremely inefficient
-  Data representation has no duplication instead of massive key replication
-  Configuration editing based on subtrees (not leafs) is now possible,
-  Capabilities and Error Reporting are much improved and extensible

IMO the protocol should be as lean as possible.
Take out (or make optional) everything that is not needed.


I have created a first draft of this “simplified” version of core-comi.
> No base64 encoding any more…
> All CoAP method/content-format combinations that would have required
> base64-encoding instance identifiers on a URI have been removed.
> GET/PUT/POST/DELETE are still in there for full datastore access.
> I’m not sure about the use case for this, but since it doesn’t need
> instance identifiers in a URI, I left it in.  Please advise.
> I also simplified the POST request for RPC/Action to carry
> application/yang-instances+cbor as a payload.
> This was a single "application/yang-data+cbor; id=sid", but this is now no
> longer used by CORECONF (*) (and it doesn't carry an instance identifier).
> event-streams are still fetched using GET as all the information that is
> needed is in
> the event stream URI, but I don’t know a good way to do ?f= on event
> stream resources.  Should this be moved to FETCH as well?
> (*) I don’t know how to do errors in the way COMI has done them before.
> These don’t cleanly map to application/yang-instances+cbor, as there is no
> data node involved.  (By now, we have RFC 9290…  Does this help here?)
> Please view the draft draft at:
> A diff from main (~ -12) can be seen at:
> Enjoy!
> Grüße, Carsten
> _______________________________________________
> core mailing list