[core] Re: Coreconf Notifications

Carsten Bormann <cabo@tzi.org> Sat, 20 July 2024 15:42 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 CC09DC14F6AF; Sat, 20 Jul 2024 08:42:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 eoLVtaSY_V0v; Sat, 20 Jul 2024 08:42:40 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.21]) (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 BE664C14F698; Sat, 20 Jul 2024 08:42:39 -0700 (PDT)
Received: from clients-pool6-0352.vpn.uni-bremen.de (clients-pool6-0352.vpn.uni-bremen.de [134.102.91.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4WR9lx1tWKzDCgK; Sat, 20 Jul 2024 17:42:37 +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: <C4AE55E1-0907-4BBD-A2BA-802063E10B50@insa-lyon.fr>
Date: Sat, 20 Jul 2024 17:42:36 +0200
X-Mao-Original-Outgoing-Id: 743182956.362462-1314e7d41d8afa1d69333d821ecf4d10
Content-Transfer-Encoding: quoted-printable
Message-Id: <397772B6-6DAE-4A2D-BFD0-7A77ABE1415E@tzi.org>
References: <E2DFFA8E-9766-4CB4-BCAA-6897402B8FB2@insa-lyon.fr> <5C0595E7-2071-4A6F-A0C8-6F9DE138535F@tzi.org> <C4AE55E1-0907-4BBD-A2BA-802063E10B50@insa-lyon.fr>
To: Alex Huang Feng <alex.huang-feng@insa-lyon.fr>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Message-ID-Hash: OC75WSYX62GBQKOTQCRNXDML65LGR2OA
X-Message-ID-Hash: OC75WSYX62GBQKOTQCRNXDML65LGR2OA
X-MailFrom: cabo@tzi.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-core.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-core-comi@ietf.org, core@ietf.org, Pierre Francois <pierre.francois@insa-lyon.fr>, Vivekananda Boudia <vivekananda.boudia@insa-lyon.fr>, "Thomas. Graf" <Thomas.Graf@swisscom.com>, Benoit Claise <benoit.claise@huawei.com>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [core] Re: Coreconf Notifications
List-Id: "Constrained RESTful Environments (CoRE) Working Group list" <core.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/7HylM0opRtqPnUj_rR3YPnaV91c>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Owner: <mailto:core-owner@ietf.org>
List-Post: <mailto:core@ietf.org>
List-Subscribe: <mailto:core-join@ietf.org>
List-Unsubscribe: <mailto:core-leave@ietf.org>

Hi Alex

On 2024-07-20, at 00:37, Alex Huang Feng <alex.huang-feng@insa-lyon.fr> wrote:
> 
> Thanks for the pointers, will check out this draft. My text does not state that the timestamp needs to be encoded as text-encoded date-time.

I would expect that you would want to encode these using standard YANG means, and (without YANG-CBOR with stand-in tags) that would be the RFC 3339 date-times used in RFC 6991.
(Which resolution do you need in practice for eventtime, by the way?)


> Are you suggesting that the draft should state the usage of tags for date-times? For implementations that does not support tags, isn’t it contra-productive?

You cannot do YANG-CBOR without CBOR tags, so I don’t think there is an actual problem.

By the way, you may want to look at the CoRE telemetry spec [1].
This is six years old (we just didn’t have the RFCs in place for YANG-CBOR and YANG SID at the time, so the draft was a bit premature), but it solves many of the problems being discussed right now.
(Henk will be at the Hackathon, so please talk to him about that.)

Grüße, Carsten

[1]: https://datatracker.ietf.org/doc/html/draft-birkholz-yang-core-telemetry-01