IETF Logo Mail Archive

[Cbor] CBOR-YANG/SID

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 02 August 2024 19:48 UTC

Return-Path: <mcr+ietf@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 1AF0CC14F749; Fri, 2 Aug 2024 12:48:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.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_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, 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 (2048-bit key) header.d=sandelman.ca
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 FnoN6vv6mOrL; Fri, 2 Aug 2024 12:48:11 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674BCC14F5E4; Fri, 2 Aug 2024 12:48:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 014123898B; Fri, 2 Aug 2024 15:48:09 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavis, port 10024) with LMTP id H0auQG87JPQb; Fri, 2 Aug 2024 15:48:07 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1722628087; bh=RLOHYso782REwO8yBfiVTcbs1D9iL2f3jMBoGS0W+N8=; h=From:To:Subject:Date:From; b=t6jD5F3ayJ1Y7D8CYpbef26Froosa+xmAJEy6NGB7tNsB3P9GPb13NtfUbyf4781F Dor3JtKqLd7wgwHBfOyRUhl7Z3ijFwlXN8jP5LhEsA+PJ6axbomZFfVeBAMlOMtyzF pag0BrlojkErTzClXWOdFYkVvKDLx8ARTnqW17WCxarwSM7c9bVIxhkNRW/3GaZJL2 qiidhoDUGVTx6Yn2jvaGNV+uoGE+6KtVSAyvaKRyO15fqIWNdfEBLGV4BJy9pEeVTH AGXnDxbuo+5Tkr3JHF5xbUGa+iSNoyBqxDEA1nc8pUIdb3m1ojo5pLumOCSf8RJ+r4 zp2C+ZddDZiHA==
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 75A6738982; Fri, 2 Aug 2024 15:48:07 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 70EF9506; Fri, 2 Aug 2024 15:48:07 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: core@ietf.org, cbor@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6+git; nmh 1.8+dev; GNU Emacs 28.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0;<'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Fri, 02 Aug 2024 15:48:07 -0400
Message-ID: <24615.1722628087@obiwan.sandelman.ca>
Message-ID-Hash: ZNSWIQFHS3R3O4TMJUMAA5YJLOJALQUP
X-Message-ID-Hash: ZNSWIQFHS3R3O4TMJUMAA5YJLOJALQUP
X-MailFrom: mcr+ietf@sandelman.ca
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cbor.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Cbor] CBOR-YANG/SID
List-Id: "Concise Binary Object Representation (CBOR)" <cbor.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/U79yvrE9xWOj_P8hztr-7-lELyY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Owner: <mailto:cbor-owner@ietf.org>
List-Post: <mailto:cbor@ietf.org>
List-Subscribe: <mailto:cbor-join@ietf.org>
List-Unsubscribe: <mailto:cbor-leave@ietf.org>

RFC9595 came out on Wednesday. HUZZAH!
It feels like forever.

Many people have asked why RFC9254 did not say that a YANG date would be
stored as a CBOR TAG 0 or 1.  I actually just assumed, and I think my (ruby)
library did as well that it would be that way, and there was an
interoperation issue discovered.  Oops.
There are other examples.

My understanding is that people would like to write an RFC9254bis that
application protocols could update to.  I'm all for this.

I believe that we should do this in *CBOR* WG, rather than CORE WG.
Comments, views of chairs?

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.27.6 | Report a Bug | By Email | System Status