[core] CORECONF: rcmon information (capabilities, streams)?
Carsten Bormann <cabo@tzi.org> Sun, 06 November 2022 12:28 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 32F25C14F74C for <core@ietfa.amsl.com>; Sun, 6 Nov 2022 04:28:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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 MQa9GxJduGU9 for <core@ietfa.amsl.com>; Sun, 6 Nov 2022 04:28:52 -0800 (PST)
Received: from smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (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 4AAEAC14F746 for <core@ietf.org>; Sun, 6 Nov 2022 04:28:51 -0800 (PST)
Received: from client-0190.vpn.uni-bremen.de (client-0190.vpn.uni-bremen.de [134.102.107.190]) (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 4N4tvM0dZKzDCbP; Sun, 6 Nov 2022 13:28:47 +0100 (CET)
From: Carsten Bormann <cabo@tzi.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mao-Original-Outgoing-Id: 689430525.3195831-465e9a6a5860851a120d42d93bebf3b7
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Date: Sun, 06 Nov 2022 12:28:45 +0000
Message-Id: <71ECA71C-1FBD-4CF6-92BB-BA0E6136558D@tzi.org>
To: "core@ietf.org WG (core@ietf.org)" <core@ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/6i1b5tenXTOXistJp1xR2BUkN9A>
Subject: [core] CORECONF: rcmon information (capabilities, streams)?
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: Sun, 06 Nov 2022 12:28:56 -0000
Koen Zandberg and I had a discussion about the last finishing touches to CORECONF. draft-ietf-core-yang-library provides a constrained version of the module underlying Section 10 of RFC 8040, so clients can find out what modules a (usually constrained) server provides. But there is also Section 9 of RFC 8040, which defines its own module (rcmon). It turns out that, from that, clients will need the capabilities indication, and also possibly the streams information. Can we just use rcmon as is in CORECONF or should we also define a constrained version of that? Grüße, Carsten
- [core] CORECONF: rcmon information (capabilities,… Carsten Bormann