Re: [core] [Anima] date-and-time and "created-on" field in constrained-voucher

Carsten Bormann <cabo@tzi.org> Wed, 29 June 2022 15:18 UTC

Return-Path: <cabo@tzi.org>
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 23EFAC14F726; Wed, 29 Jun 2022 08:18:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
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 s2KEfHYPuJMR; Wed, 29 Jun 2022 08:18:25 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A1C6C15948A; Wed, 29 Jun 2022 08:09:34 -0700 (PDT)
Received: from [192.168.217.118] (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4LY4cr0lYTzDCbK; Wed, 29 Jun 2022 17:09:32 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CABCOCHSEyGakhuukHkLU-bWUV26QAzc3vkOuLEMRf8-YZbFtqQ@mail.gmail.com>
Date: Wed, 29 Jun 2022 17:09:31 +0200
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, anima@ietf.org, Core <core@ietf.org>
X-Mao-Original-Outgoing-Id: 678208171.603956-0dac1f43662e6c53da8ef44cb541f683
Content-Transfer-Encoding: quoted-printable
Message-Id: <27FD2DA5-AF36-4E57-ADC8-2D6F8DE62919@tzi.org>
References: <24048.1656352364@localhost> <25937.1656365067@localhost> <CABCOCHS6=F0tfESkVmOk1AFKvsu4tRfKu9A_Sgz5swVXv-eXCQ@mail.gmail.com> <26870.1656383550@localhost> <CABCOCHSkh95PEEM5E3YKe_yc5VmsY90XxT1D-z3AiJwwcG-HhA@mail.gmail.com> <7669.1656440710@localhost> <6DCC06F4-3799-4CC0-8780-21E6B12A4022@tzi.org> <CABCOCHQqtKw6cZ1o7nzDmQBN0zQP70CgeAAc6nFdRa_kB+-DBQ@mail.gmail.com> <09C66776-54C5-4C5D-9DFA-E164A1050170@tzi.org> <E51C95DD-0AC5-40E4-8609-E0B444E77786@tzi.org> <20220629015429.vfps46mvcb7io67o@anna> <04EC3D51-6242-4547-BF7F-397859E8D18E@tzi.org> <CABCOCHSEyGakhuukHkLU-bWUV26QAzc3vkOuLEMRf8-YZbFtqQ@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/j1DozX2VJ_cOSnCc6x4OgYFb0hw>
Subject: Re: [core] [Anima] date-and-time and "created-on" field in constrained-voucher
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: Wed, 29 Jun 2022 15:18:27 -0000

> So your proposal is for the sender to check every single string it sends to the receiver to
> see if some complex 20 byte string can be changed to an 8 byte integer instead?

In an actual implementation, these 20 byte strings never exist.

How a sender finds out that the 4-byte integer is enough is not specified.
The answer is probably: because the data were in platform time format, and we just don’t do a strftime but a memmove(..htonl(..)).

> This seems rather CPU-intensive and not very useful for YANG Push.

The way you describe it definitely is.  
But the specification would not stop you from doing do this, just your implementation common sense.

> I doubt constrained devices have enough CPU for this, or that they need to send
> lots of date-and-time data nodes to justify it.

So far we have:

— date-time and friends (as POSIX time integer): CBOR tag 1
— IP addresses and friends (as binary): CBOR tag 52 and 54

Fortunately, “type binary” is an actual base type, so here we already have actual schema support and therefore support in YANG-CBOR as is.

> The date-and-time typedef for a string is not special in YANG in any way.
> Just another derived type defined in a YANG module.

Indeed, this is the reason why it is hard to do this properly (i.e., deterministically in a way that it is guaranteed that every generator gets the choice right) without additional language support.

Grüße, Carsten