IETF Logo Mail Archive

[yang-tooling] Re: SID file issues / .sid file differences in pyang and core-wg/pyang

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 07 February 2026 09:57 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: yang-tooling@mail2.ietf.org
Delivered-To: yang-tooling@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 723E4B345CE0 for <yang-tooling@mail2.ietf.org>; Sat, 7 Feb 2026 01:57:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AUMTKT1Nrm4 for <yang-tooling@mail2.ietf.org>; Sat, 7 Feb 2026 01:57:35 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 16B15B345CD5 for <yang-tooling@ietf.org>; Sat, 7 Feb 2026 01:57:35 -0800 (PST)
Received: from dyas.sandelman.ca (unknown [185.201.63.254]) by relay.sandelman.ca (Postfix) with ESMTPS id 4BF811F469 for <yang-tooling@ietf.org>; Sat, 07 Feb 2026 09:57:34 +0000 (UTC)
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id BBC4CAC30A for <yang-tooling@ietf.org>; Sat, 7 Feb 2026 04:57:22 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: yang-tooling@ietf.org
In-Reply-To: <EE144B22-21ED-46E8-8963-3D5639F377E9@tzi.org>
References: <CABCOCHTP52cfDVeguY3iYbzJqmCfg-z5cMeFz-y_3vNw250TEg@mail.gmail.com> <1263365.1770129015@dyas> <CABCOCHRHAEkiAJu=TtaZDERG9eiq_Ay9txRt10DEOgPYu3eprA@mail.gmail.com> <6c4f3e7e-ffa3-404b-83b3-9533f4046212@iotconsultancy.nl> <CABCOCHTWV2amW1wdHPQyd5jeaAVeie1S2xFfFf2ZgZQ6EbCKqg@mail.gmail.com> <4c11110f-fe64-414f-ad78-0183c61851b8@iotconsultancy.nl> <DDC68541-9A77-4AFD-BF36-DF6A75CF888B@tzi.org> <ce89bf21-8806-4590-9f37-a1eefa44b979@iotconsultancy.nl> <408BA8A1-AD8E-4CED-9991-B4632577986E@tzi.org> <7aca3e8e-ac46-4bb5-8b16-f75b51490b55@iotconsultancy.nl> <56406098-2B8F-402B-BE6A-AE9FEA9D7217@tzi.org> <CABCOCHQR30cSFqoFiYrj-PhX42r9o8zkSz9idVSOZYOyLD4A4A@mail.gmail.com> <ee28c8c1-fe81-4f9f-ba36-b60c74b5d156@iotconsultancy.nl> <CABCOCHR-oo5xK2bbagDUtK=1Mi5dBLjNT8r=4Y4QSJoFs0SgRA@mail.gmail.com> <b1256b3f-794b-40e8-a7e8-d1395fa7aa0d@iotconsultancy.nl> <EE144B22-21ED-46E8-8963-3D5639F377E9@tzi.org>
X-Mailer: MH-E 8.6+git; nmh 1.8+dev; Emacs 29.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 07 Feb 2026 09:57:22 +0000
Message-ID: <1518415.1770458242@dyas>
Message-ID-Hash: CLJTHGJNLEP55SBG26SGLKUXQXVX6X5H
X-Message-ID-Hash: CLJTHGJNLEP55SBG26SGLKUXQXVX6X5H
X-MailFrom: mcr+ietf@sandelman.ca
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [yang-tooling] Re: SID file issues / .sid file differences in pyang and core-wg/pyang
List-Id: "Contributing to and tracking the progress of YANG tooling, as it concerns IETF work that uses YANG." <yang-tooling.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-tooling/5V1x0dVDuQH1XZjtCLWGiZiu52A>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-tooling>
List-Help: <mailto:yang-tooling-request@ietf.org?subject=help>
List-Owner: <mailto:yang-tooling-owner@ietf.org>
List-Post: <mailto:yang-tooling@ietf.org>
List-Subscribe: <mailto:yang-tooling-join@ietf.org>
List-Unsubscribe: <mailto:yang-tooling-leave@ietf.org>

Carsten Bormann <cabo@tzi.org> wrote:
    >    * application/yang-data+cbor; id=sid -- for use by applications that
    >    * application/yang-data+cbor; id=name -- for use by applications
    >    * application/yang-data+cbor -- for use by more complex applications

two silly thoughts:
1. can one do 9254 over RESTCONF (HTTP) rather than CoAP?
   If so, I believe that the Accept: headers won't let you negotiate
   parameters, so I don't think a client could indicate what it wanted,
   if the server had flexibility.
   Maybe that's okay, network managers should deal with the complexity.

2. If using CORECONF, then we have Content-Format, so we *can* express those
   three parameter types, right? (340,341,140).

3. So, best choice for some network managers might be CoAP over TCP,
(RFC8323).  Too bad HTTP/2 didn't adopt Content-Format.  Maybe it has other
mechanisms that I'm ignorant of.

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

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