IETF Logo Mail Archive

[Cbor] YANG-CBOR, Date formats

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

Return-Path: <mcr@sandelman.ca>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A73C159482; Wed, 29 Jun 2022 05:41:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.104
X-Spam-Level:
X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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=no 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 JY74dyg1OKA3; Wed, 29 Jun 2022 05:41:18 -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)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EABDBC14F726; Wed, 29 Jun 2022 05:41:17 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [142.169.16.73]) by relay.sandelman.ca (Postfix) with ESMTPS id 822321F4BA; Wed, 29 Jun 2022 12:41:09 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 348931A0523; Wed, 29 Jun 2022 06:41:36 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Barry Leiba <barryleiba@computer.org>, cbor@ietf.org
CC: core@ietf.org
In-reply-to: <CALaySJJ+rhJMOfhhc9jDxz_9y+VpyrNoMcFy_b00Ui05c+g4zw@mail.gmail.com>
References: <CALaySJLPtUjdfVss17noK=18RyczpcCGNu=im8CBpiQz=WiLWA@mail.gmail.com> <CALaySJKUNh-AkJa87sCDpzf9OHV8H367VQyzyozXCCXxphUARw@mail.gmail.com> <CALaySJ+P2sP7BU7bNSxRJBByyp04rzVZuukq_e+9wbb5WPRSFQ@mail.gmail.com> <CALaySJKxht1gd1+3mNiAH-kLUAxjdPPk3doK50C_xS74LG+YTQ@mail.gmail.com> <CALaySJJNXpcaBhWQiK+4vmUk+s6mfMvwQFnB9d4YfDtdet09OQ@mail.gmail.com> <CALaySJ+8qLX6kuqXcRp6-OHU_MBkkASfH80bf2EePueduMsCTw@mail.gmail.com> <CALaySJJ+rhJMOfhhc9jDxz_9y+VpyrNoMcFy_b00Ui05c+g4zw@mail.gmail.com>
Comments: In-reply-to Barry Leiba <barryleiba@computer.org> message dated "Tue, 28 Jun 2022 21:37:51 -0400."
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 06:41:36 -0400
Message-ID: <258768.1656499296@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/niSd76rLOEOIiqMPdRwjgDAt35o>
Subject: [Cbor] YANG-CBOR, Date formats
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jun 2022 12:41:19 -0000

Barry Leiba <barryleiba@computer.org> wrote:
    > It's Tuesday evening and the agenda remains empty.  We will, therefore,
    > CANCEL the call on 29 June.  Our next call will be on 13 July, and it
    > will be the last one before IETF 114.

That's mostly fine with me.  I thought to bring up this topic today, but
didn't think to write an email last night about this.

I am grumpy because those of doing interop testing on draft-ietf-anima-constrained-voucher
noticed that *oops* yang:date-and-time does not translate to a CBOR Tag-1
date value.  (My code did this, I never thought different about it, but it's
not to spec)

draft-ietf-core-yang-cbor just got to AUTH48 on Monday.
I think that if we started again today, that yang-cbor/yang-sid would be in the
CBOR WG.

My question is whether we can write a spec making there be some kind of exception.
I think we might also want one for tags 52 and 54 (IPv4/IPv6), and maybe a
few other yang data types that have clear CBOR mappings.

1. would we do this in CBOR now?  (Is it in charter?)
2. is there support for doing this?
3. how fast can we do this?
4. How can draft-ietf-anima-constrainer-voucher leverage this *now*?

2022-06-17T09:21:32Z => 20 characters.
vs 4 bytes until 2038, and 8 bytes after 2038.
(I might suggest we encourage to send 8, because I'd hate for fragmentation
to show up on 19-January-2038 and screw something up)

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

v2.23.0 | Report a Bug | By Email