From nobody Fri Feb 24 12:14:55 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 B661AC14CE53; Fri, 24 Feb 2023 12:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 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, 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 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 UQ-S37X9DYQ2; Fri, 24 Feb 2023 12:14:50 -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 2ABD7C14CE3D; Fri, 24 Feb 2023 12:14:47 -0800 (PST) Received: from [192.168.217.124] (p548dc9a4.dip0.t-ipconnect.de [84.141.201.164]) (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 4PNh2C4npXzDCc1; Fri, 24 Feb 2023 21:14:43 +0100 (CET) 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 Date: Fri, 24 Feb 2023 21:14:43 +0100 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 698962483.20521-1cc3608bcb06af11b265552e21bed6da Content-Transfer-Encoding: quoted-printable Message-Id: To: "core@ietf.org WG (core@ietf.org)" X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [Cbor] 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: Fri, 24 Feb 2023 20:14:53 -0000 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 YANG = module. However, it appears that the YANG ecosystem currently does not provide a = way to mechanically validate that instance against the YANG model. I find this rather unsettling. 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. So I translated the YANG model into CDDL (and, yes, the example instance = does validate, phew). 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, including = the SID-file model. Please enjoy=E2=80=A6 (And please do tell me about other RFCs that would benefit from the = availability of CDDL-based models.) Gr=C3=BC=C3=9Fe, Carsten [1]: = https://www.ietf.org/archive/id/draft-bormann-cbor-rfc-cddl-models-00.html=