[core] CORECONF k parameter encoding

Koen Zandberg <koen.zandberg@inria.fr> Thu, 15 September 2022 14:34 UTC

Return-Path: <koen.zandberg@inria.fr>
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 D6199C1526E2 for <core@ietfa.amsl.com>; Thu, 15 Sep 2022 07:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=inria.fr
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPwiA3fkDSZv for <core@ietfa.amsl.com>; Thu, 15 Sep 2022 07:34:24 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49C51C1526E1 for <core@ietf.org>; Thu, 15 Sep 2022 07:34:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=message-id:date:mime-version:to:from:subject; bh=EcTQSIdp9ksSSTBvm1S8Yj4QaJmI9qpdZcnD23+XB+E=; b=oJ1GmFgJV8knHwaKsUW8azp04rXQ9zlcT1yZkdzdUnAaxyZUEE1qLxNa OSMcSMHr5S/mOrIL8QKkbN5oyUAu9WDcyytlZXoesWLb+wMiaEsJqyyBq UscCkVm5/3WBASzfJaX3Q8vQYqImIRUhpiXki3Dp7bq6T6J2zQnBHfnHo 4=;
Authentication-Results: mail2-relais-roc.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=koen.zandberg@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr
X-IronPort-AV: E=Sophos;i="5.93,318,1654552800"; d="scan'208";a="52984624"
Received: from 185-227-75-229.dsl.cambrium.nl (HELO [10.1.7.20]) ([185.227.75.229]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Sep 2022 16:34:22 +0200
Message-ID: <4e9673fa-f1cb-a36a-50d2-b2583f144164@inria.fr>
Date: Thu, 15 Sep 2022 16:34:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0
Content-Language: en-US
To: core@ietf.org
From: Koen Zandberg <koen.zandberg@inria.fr>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------DzDKmb6hsFp0Vj1fFuhgCX99"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/iIglJzch9FwcaFJxxLyiAnhoepo>
Subject: [core] CORECONF k parameter encoding
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 15 Sep 2022 14:34:28 -0000

Dear all,

I'm working on an open source implementation of draft-ietf-core-comi-11 
for RIOT[1]. The implementation is still very minimal, gluing a couple 
of YANG modules to RIOT internals and expose them via CORECONF. So far 
there is support to configure IPv6 addresses, get the system information 
and the sensors available over CORECONF.

One thing I'm running into, where I'm wondering if there has been 
previous discussion on this, is the encoding of YANG datatypes in the 
'k' query parameter. There is a large variety of different encoding 
methods for the content, increasing the decoding complexity on the 
constrained device. Has it been consider of encoding all query params as 
a CBOR array and urlSafeBase64 as key value. The upside to this approach 
is that decoding the query parameter for a GET and DELETE requests 
closely matches the decoding of the payload with FETCH and iPATCH 
requests. Encoding the 'k' parameter also as CBOR array results in that 
for both a FETCH and a GET, the YANG list keys can in both cases be 
retrieved by iterating over a CBOR array.

Has this way of encoding been considered? Or am I missing a potential 
issue with encoding the query parameter as CBOR?

 From what I get from the current status of the document is that I'm a 
bit late to the party here in terms of feedback, please let me know if 
I'm too late with the feedback here.

Best regards,

Koen Zandberg

[1]: https://github.com/bergzand/RIOT/tree/wip/coreconf/sys/net/coreconf