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

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 26 March 2023 18:04 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 2C399C1524B3 for <core@ietfa.amsl.com>; Sun, 26 Mar 2023 11:04:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.397
X-Spam-Level:
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: 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 lYU-5s8NE7Cv for <core@ietfa.amsl.com>; Sun, 26 Mar 2023 11:04:02 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (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 F1C33C1524AE for <core@ietf.org>; Sun, 26 Mar 2023 11:04:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C97923898C; Sun, 26 Mar 2023 14:37:19 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vGx35J21XzJZ; Sun, 26 Mar 2023 14:37:16 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id F1C6F3898E; Sun, 26 Mar 2023 14:37:15 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; 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 sandelman.ca (Postfix) with ESMTP id 91BD03F5; Sun, 26 Mar 2023 14:03:56 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Jernej Tuljak <jernej.tuljak@mg-soft.si>
cc: core@ietf.org
In-Reply-To: <fb260343-b552-ff15-7665-2033ca209120@mg-soft.si>
References: <mbj4668/pyang/pull/839@github.com> <mbj4668/pyang/pull/839/c1474951745@github.com> <2897262.1679232828@dyas> <bed2e140-d5e3-2aba-c2e1-6c8066602660@mg-soft.si> <28078.1679313444@localhost> <ea2899eb-e02c-9ad0-2ead-c0a341410225@mg-soft.si> <4633.1679579478@localhost> <fb260343-b552-ff15-7665-2033ca209120@mg-soft.si>
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: <https://mailarchive.ietf.org/arch/msg/core/n3Jvpp5owewvuuthAUi7jhDPZd8>
Subject: Re: [core] implementer feedback on CORE-SID: Re: [mbj4668/pyang] Sid sx structure (PR #839)
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, 26 Mar 2023 18:04:06 -0000

Jernej Tuljak <jernej.tuljak@mg-soft.si> 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"), ...

Good.

    > 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.

Cool.

    > 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.

good.

    > 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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide