From nobody Sat Feb 25 13:10:26 2023 Return-Path: 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 3463FC14CE52; Sat, 25 Feb 2023 13:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 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, 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=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 e2vEO-Vp5lY4; Sat, 25 Feb 2023 13:10:18 -0800 (PST) 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 RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21A0C14CE4F; Sat, 25 Feb 2023 13:10:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 610973898F; Sat, 25 Feb 2023 16:41:46 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 66wgfM_5yvfl; Sat, 25 Feb 2023 16:41:44 -0500 (EST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 4EA183898E; Sat, 25 Feb 2023 16:41:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1677361304; bh=4RX7UpCQfIS44YpeOrCdz4tUdbGE9vhid7mfb1Z6u0s=; h=From:To:CC:Subject:In-Reply-To:References:Date:From; b=eLhcfhrMuqNZ2dUlGmmsTqEb5Vyv9gw1nNVkyZqzanvyJ7wDoANokJWirv0GBSG51 F3PjEh0GcBPZPFKNfBtuQAdOM0ubtUDcIFwF+1W2j6mISAaZ6qTdhZXz/wafJHV7OK KHZv66M3vaVXKAR5jP773RM3+uFL4Xvx2ydksRoes/ZjuxLLx1qJVnX/uqMxi5JGOX 8ZEBaANxk95ymm/33EW3ZKJA1puZcekoEIePqkbPdWu05hNUwbJ1fn7fgbSrMg8++w VjpjyIRa/7GeoqEGOnHJiheKZ0JUXcGi1x8ZwbGNHbeBdmy5bEbm9vaK9pofmTyQJ/ mzLhtjfCx4ZWw== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 570C2EA; Sat, 25 Feb 2023 16:10:12 -0500 (EST) From: Michael Richardson To: Carsten Bormann , "core@ietf.org WG (core@ietf.org)" , cbor@ietf.org CC: anima@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.1 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 Archived-At: Subject: Re: [Cbor] [core] CDDL Model for YANG-SID (draft-ietf-core-sid) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2023 21:10:23 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > draft-ietf-core-sid defines a file format for the interchange of > YANG-SID allocation information. > This is a JSON file, a data model for which is provided in YANG (via > RFC7951 YANG-JSON). > The spec of course also contains an example instance of such a file, > which is directly useful as the SID allocation for the ietf-system YA= NG > module. > However, it appears that the YANG ecosystem currently does not provide > a way to mechanically validate that instance against the YANG model. Yes... I was told to use yanglint, but it's not actually capable of parsing all the new fangled things. > I find this rather unsettling. Me too. I'm not yet convinced that the examples in **RFC8366** even valida= te correctly, which makes it hard for me to know if 8366bis is actually correc= t. > Since we just did a global change (to fix our incorrect representation > of uint64 in YANG-JSON), I wanted to make sure the SID file is not > broken. I will probably be on the hook to fix sid.py to round trip the revised content, so anyone who wants to unicast me and tell me if there is some mag= ic python that makes it do the right thing, I would appreciate it. > So I translated the YANG model into CDDL (and, yes, the example insta= nce does validate, phew). Even without any kind of top-level wrapper dict? I see you added: "ietf-sid-file:sid-file": which pyang *does* insert or parse, and I suspected that it was wrong not t= o. I think you did this manually, right? > While I was at it, I remembered that there are a few other RFCs (or > soon-to-be-RFCs) that would benefit from having CDDL models handy. > So I wrote an I-D [1] that presents a number of such models, includin= g the SID-file model. > [1]: https://www.ietf.org/archive/id/draft-bormann-cbor-rfc-cddl-mode= ls-00.html 2.4. Your favorite RFC here... RFC8366. Not seeing a venu for your draft. The thing is, once it gets translated to CDDL, I'm actually not sure I want to keep the YANG anymore. A huge huge huge amount of effort on our part, f= or almost zero benefit. We didn't really have CDDL 8 years ago, so we had no = clear alternative when we started, but I sure wouldn't go down the YANG path agai= n. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFKBAEBCgA0FiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmP6eTQWHG1jcitpZXRm QHNhbmRlbG1hbi5jYQAKCRCAi3D73dDdZY74B/4q9OyxvWvdc2VTpqhr9cT5IQin tRSmbxAeMHqFFt2t1vnGZJ2SJTzwHWxMrdXy2QpgNz9bJu1u1+3F4PTWVA0r74t/ Qbp7DMK6YWqo1ppfUu08L7vB6E4a9JAVDIL096VLUMhCaI68ywqSgyUOrV1YwSCR I2DiYGrU4dIkgP5Jzhh8NBha2NrtR+pE/SQndLYA9ZLx3T8t4xu6QLnNVGCXuNja bO+QIN1H2s3P+pbW2YInMpSIdg+G/1W0+t9I0wDP6k64fFnztm6QDPlKm3YimSDW jjENwLn8BBBi6e0eilKKdNLx+mJZKL/m5G0sNuqrltBupU/i0jqNHO0EwLhb =d6+s -----END PGP SIGNATURE----- --=-=-=--