[core] Coreconf Notifications

Alex Huang Feng <alex.huang-feng@insa-lyon.fr> Thu, 18 July 2024 15:56 UTC

Return-Path: <alex.huang-feng@insa-lyon.fr>
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 E47B9C15109C; Thu, 18 Jul 2024 08:56:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.738
X-Spam-Level:
X-Spam-Status: No, score=-4.738 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, HTML_MESSAGE=0.001, RCVD_HELO_IP_MISMATCH=2.368, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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=insa-lyon.fr
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 LA6O7zRyEt23; Thu, 18 Jul 2024 08:56:46 -0700 (PDT)
Received: from smtpout02-ext4.partage.renater.fr (smtpout02-ext4.partage.renater.fr [194.254.241.31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECD11C14F6BC; Thu, 18 Jul 2024 08:56:38 -0700 (PDT)
Received: from zmtaauth02.partage.renater.fr (zmtaauth02.partage.renater.fr [194.254.241.25]) by smtpout20.partage.renater.fr (Postfix) with ESMTP id DA1FCC0186; Thu, 18 Jul 2024 17:56:31 +0200 (CEST)
Received: from zmtaauth02.partage.renater.fr (localhost [127.0.0.1]) by zmtaauth02.partage.renater.fr (Postfix) with ESMTPS id C8D18A079D; Thu, 18 Jul 2024 17:56:31 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zmtaauth02.partage.renater.fr (Postfix) with ESMTP id B753EA07C8; Thu, 18 Jul 2024 17:56:31 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.10.3 zmtaauth02.partage.renater.fr B753EA07C8
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=insa-lyon.fr; s=CB289C06-95B8-49FE-9C4B-D197C6D2E7CB; t=1721318191; bh=27jXCphdiEDqSderI//XTTq+XqhTtyvOuVKYmm83BJE=; h=From:Mime-Version:Message-Id:Date:To; b=KxmzKJau5JwMW8iJjLNWWJqXoLTNhmUrpXiMYNaONUT7dwZygAmqsPiW/T6oDuTN+ VbTHvMcsL/2WEilBESQ/jAyzDXPr5MpGOkZHMtLfci/HXuyRlKDM1f62gYIm+1hh0T yys7Mu3rpbpf+PzM6XF1Hmmmig7bvBmNDvY4UI/kXN5RJM73ymekcb0nmzBfrOtSda jfUkP5nKJG7FtaO7tL0tWbx4KQ4imNWsIvglZUrX+qoiXjmxJRO9M8a4yGhlRbE9Mm QzBsBGavq9ZS+MSAYuUCRiPLLGTfrgiSfP9R+/Z43HBIadDrpz+eLBQNiUfPyqiTfv UKrecRZ9VYigA==
Received: from zmtaauth02.partage.renater.fr ([127.0.0.1]) by localhost (zmtaauth02.partage.renater.fr [127.0.0.1]) (amavis, port 10026) with ESMTP id fCuye95bjaH7; Thu, 18 Jul 2024 17:56:31 +0200 (CEST)
Received: from 24.109.167.30 (unknown [194.254.241.251]) by zmtaauth02.partage.renater.fr (Postfix) with ESMTPA id 50EEFA079D; Thu, 18 Jul 2024 17:56:30 +0200 (CEST)
From: Alex Huang Feng <alex.huang-feng@insa-lyon.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F16C4DA8-0C12-4FAE-95B0-F80763AF332F"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
Message-Id: <E2DFFA8E-9766-4CB4-BCAA-6897402B8FB2@insa-lyon.fr>
Date: Thu, 18 Jul 2024 08:56:18 -0700
To: draft-ietf-core-comi@ietf.org, core@ietf.org
X-Mailer: Apple Mail (2.3774.600.62)
X-Virus-Scanned: clamav-milter 0.103.8 at clamav02
X-Virus-Status: Clean
X-Renater-Ptge-SpamState: clean
X-Renater-Ptge-SpamScore: -100
X-Renater-Ptge-SpamCause: gggruggvucftvghtrhhoucdtuddrgeeftddrgeelgdelgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucftgffptefvgfftnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhtggguffkffevvffosegrtdhmrehhtdejnecuhfhrohhmpeetlhgvgicujfhurghnghcuhfgvnhhguceorghlvgigrdhhuhgrnhhgqdhfvghnghesihhnshgrqdhlhihonhdrfhhrqeenucggtffrrghtthgvrhhnpeeijeeghfeihfefheehveefteeghfejvddtvdeiffelgeetvdeuteevfefhgeehjeenucffohhmrghinhepihgvthhfrdhorhhgpdhgihhthhhusgdrtghomhenucfkphepudelgedrvdehgedrvdeguddrvdehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduleegrddvheegrddvgedurddvhedupdhhvghlohepvdegrddutdelrdduieejrdeftddpmhgrihhlfhhrohhmpegrlhgvgidrhhhurghnghdqfhgvnhhgsehinhhsrgdqlhihohhnrdhfrhdpnhgspghrtghpthhtohepiedprhgtphhtthhopegurhgrfhhtqdhivghtfhdqtghorhgvqdgtohhmihesihgvthhfrdhorhhgpdhrtghpthhtoheptghorhgvsehivghtfhdrohhrghdprhgtphhtthhopehpihgvrhhrvgdrfhhrrghntghoihhssehinhhsrgdqlhihohhnrdhfrhdprhgtphhtthhopehvihhvvghkrghnrghnuggrrdgsohhuughi rgesihhnshgrqdhlhihonhdrfhhrpdhrtghpthhtohepvfhhohhmrghsrdfirhgrfhesshifihhsshgtohhmrdgtohhmpdhrtghpthhtohepsggvnhhoihhtrdgtlhgrihhsvgeshhhurgifvghirdgtohhm
Message-ID-Hash: PN4AYFE76RWVS7S4V7J52HEQNB3IFDOF
X-Message-ID-Hash: PN4AYFE76RWVS7S4V7J52HEQNB3IFDOF
X-MailFrom: alex.huang-feng@insa-lyon.fr
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: 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] Coreconf Notifications
List-Id: "Constrained RESTful Environments (CoRE) Working Group list" <core.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Y2gyFeIWR1xyUI7PKUosJ2jL9wU>
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>

Dear authors and CORE WG,

I have some questions regarding how YANG notifications are encoded in CBOR.

I am co-authoring draft-ahuang-netconf-notif-yang-05 where we are defining how NETCONF notifications are encoded in XML, JSON and CBOR.
This definition is not explicit in JSON (RFC7951).

Reading the YANG-CBOR (RFC9254) specification, the notifications are encoded as a “container-like” instance. This is rather a different approach from XML (RFC7950) and JSON (RFC7951) which to my understanding a leaf “eventTime” needs to be present in the notification as defined in RFC5277.
I am wondering why YANG-CBOR defined YANG notifications differently. I don’t follow this WG closely but would love to hear the reasons which led to the wording in RFC9254. (Or if more consistency with XML and JSON is expected)

For CORECONF, reading https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-17#name-notify-examples, the notifications are also defined without the leaf defined in RFC5277 but still references this RFC.

We plan to use CBOR encoding with YANG-Push (RFC8641) to reduce the size of the YANG-defined messages between the NETCONF server and client.
In https://datatracker.ietf.org/doc/html/draft-ahuang-netconf-notif-yang-05#name-cbor-structure we define how we expect the CBOR message to be encoded.
Having a similar approach to encode YANG notifications between JSON and CBOR ease the development of some open-source projects, such as the integration of YANG in the Kafka message broker.
Here some references of such integration:
- https://datatracker.ietf.org/doc/html/draft-ietf-nmop-yang-message-broker-integration-03
- https://github.com/network-analytics/draft-daisy-kafka-yang-integration/blob/main/schema-registry-yangkit-integration-02.pdf

Note also that we request a .sid file for YANG-SIDs for compressed CBOR messages in https://datatracker.ietf.org/doc/html/draft-ahuang-netconf-notif-yang-05#appendix-A.

We will be onsite in Vancouver, so happy to have a live discussion regarding these encoding mismatches.

I think the integration of YANG and CBOR into Kafka might also be of interest to the WG.
Feel free to ping me back to have a discussion during the IETF week. We will also be present at the Hackathon Saturday and Sunday.

Regards,
Alex