Re: [core] implementer feedback on CORE-SID: Re: [mbj4668/pyang] Sid sx structure (PR #839)

Michael Richardson <> Sun, 26 March 2023 18:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C399C1524B3 for <>; Sun, 26 Mar 2023 11:04:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.397
X-Spam-Status: No, score=-4.397 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_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lYU-5s8NE7Cv for <>; Sun, 26 Mar 2023 11:04:02 -0700 (PDT)
Received: from ( []) (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 (Postfix) with ESMTPS id F1C33C1524AE for <>; Sun, 26 Mar 2023 11:04:01 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C97923898C; Sun, 26 Mar 2023 14:37:19 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id vGx35J21XzJZ; Sun, 26 Mar 2023 14:37:16 -0400 (EDT)
Received: from ( []) by (Postfix) with ESMTP id F1C6F3898E; Sun, 26 Mar 2023 14:37:15 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mail; t=1679855835; bh=E90nnHw8+knn2Ou5CjHdZ1dfkMGWfvdB/unxxJ4kslA=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=TNRr6B7V5iEnF6FFTkEaPC1ZAtieuEyabdLtr42CaWvY2sZlDvY2wuMUJBJsrYqld CTJ3mwplFrmIXak1lV9hEe5XXwKiyRlMIR54LGoSguvK0holRAmFueN0RiUykUPgrP GKmg4Rvq6R8SUI7k+T/Nzn0fJ87OSHGXB3MTnpd3IVvp8Zs5MYR+Cl8nOTYcjpajkh wIYRX2yNn0jz8r1VnDkLHWXGEZOicN21eAG7ELMCTGJe2VR4qTNxY6JkcyCGHKOAFO ALu8YCvuXdc/FxwMJw4VjbTR5bu+uJ/aJd6Lpbu8Nd5fmIT7NWRMlN9Qh42klIy/qd cJ6UiVNhN5K3A==
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 91BD03F5; Sun, 26 Mar 2023 14:03:56 -0400 (EDT)
From: Michael Richardson <>
To: Jernej Tuljak <>
In-Reply-To: <>
References: <mbj4668/pyang/pull/> <mbj4668/pyang/pull/839/> <2897262.1679232828@dyas> <> <28078.1679313444@localhost> <> <4633.1679579478@localhost> <>
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<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sun, 26 Mar 2023 14:03:56 -0400
Message-ID: <23436.1679853836@localhost>
Archived-At: <>
Subject: Re: [core] implementer feedback on CORE-SID: Re: [mbj4668/pyang] Sid sx structure (PR #839)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 26 Mar 2023 18:04:06 -0000

Jernej Tuljak <> wrote:
    > It relies on collections.OrderedDict, same as the original
    > implementation. That should be in insertion order on any platform.

I'm saying that I think that we should be explicit in the ordering of our
keys.  Insertion order means that it's unstable if someone re-formats the
YANG document.

    > would be to test for this. If this is a problem in my implementation, it is
    > also a problem in the original one.

I totally agree.

    > I've made more changes on my fork. The original output had a lot of issues
    > that needed to be mended. Here's some of those: there was no
    > "ietf-sid-file:sid-file" wrapper object present in JSON output, lists
    > were encoded with an "s" suffix ("items" instead of "item", for example),
    > "dependency-revision" was not encoded at all, valid leafs such as
    > "description" , "sid-file-version", etc. were being rejected as invalid if
    > present in the .sid file, it was never considered that JSON object keys could
    > appear in their qualified form (with an "ietf-sid-file" prefix;
    > "ietf-sid-file:item"), ...


    > I've also implemented crude validation of a .sid file against the .yang for
    > which the .sid was generated. All items are looked up in the YANG file,
    > including schema node identifiers for the data namespace. One can do that
    > with --sid-check-file-valid option.


    > Files that were generated with the original implementation may be converted
    > with --sid-update-file in a way that should keep all the existing mappings
    > and only assign some new ones.


    > A thing that I did not address are the changes related to "sid-file-status".

Carsten will need to tell me what our conclusion were about hte per-file
status vs the per-item status, as I'm lost about what the consensus was.

Michael Richardson <>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide