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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 29 June 2022 12:43 UTC

Return-Path: <mcr@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 BF072C159492; Wed, 29 Jun 2022 05:43:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.105
X-Spam-Level:
X-Spam-Status: No, score=-6.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=0.01] autolearn=ham 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 9nu_pu25GH7e; Wed, 29 Jun 2022 05:43:13 -0700 (PDT)
Received: from relay.sandelman.ca (unknown [IPv6:2a01:7e00:e000:2bb::1]) (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 A3D40C14F726; Wed, 29 Jun 2022 05:41:12 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [142.169.16.73]) by relay.sandelman.ca (Postfix) with ESMTPS id D55C01F4A8; Wed, 29 Jun 2022 12:41:08 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 1223E1A0527; Wed, 29 Jun 2022 07:08:30 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Andy Bierman <andy@yumaworks.com>, Carsten Bormann <cabo@tzi.org>, Core <core@ietf.org>, anima@ietf.org, cbor@ietf.org
In-reply-to: <CABCOCHQqtKw6cZ1o7nzDmQBN0zQP70CgeAAc6nFdRa_kB+-DBQ@mail.gmail.com>
References: <DU0P190MB1978F90B0893D32291F6EE7DFDB99@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <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>
Comments: In-reply-to Andy Bierman <andy@yumaworks.com> message dated "Tue, 28 Jun 2022 13:22:59 -0700."
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 29 Jun 2022 07:08:30 -0400
Message-ID: <261410.1656500910@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/971X6CqGUpUH8lsnTvJ94HVIH5M>
Subject: Re: [core] 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 12:43:14 -0000

Andy Bierman <andy@yumaworks.com> wrote:
    > On Tue, Jun 28, 2022 at 11:30 AM Carsten Bormann <cabo@tzi.org> wrote:

    >> > Andy Bierman <andy@yumaworks.com> wrote: >> I am not in favor of the
    >> YANG-CBOR draft defining special encodings for >> 1 derived type (like
    >> date-and-time).  Implementations may not store the >> named YANG
    >> typedefs defined in various YANG modules.  >> The current draft
    >> (properly) addresses only the base types, not derived >> types.
    >> >
    >> > So, do you think that auxiliary drafts could/should be written to
    >> deal with special > encoding of derived times?
    >> 
    >> Well, first of all we need an architecture that explains how to do
    >> this.  (Who needs to know what to make this happen.)
    >> 
    >> 
    > The key design goal is the YANG modules do not need to be modified to
    > provide efficient encoding options for CBOR.  Instead, tags are used to
    > indicate an alternate encoding is sent on the wire.

    > Each protocol needs a "server capabilities" discovery mechanism.  For
    > example, NETCONF has a <capability> URI, but the current practice is to
    > design a protocol-independent YANG module for the client to read.

I hate this.

1) it fails for data at rest, or which have to go through multiple steps.
2) if I'm trying to reduce code (and bugs) as well as network traffic, then having a
   thing that translates to/from the ascii date representation as an *OPTION*
   is just a non-starter.
   
I'm okay with some extension to SID to inform the encoder/decoder.

I started a thread in cbor@, and I think that we should do the work in cbor@

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