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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 21 March 2023 17:13 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 EE6FCC14CE31 for <core@ietfa.amsl.com>; Tue, 21 Mar 2023 10:13:52 -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 Y8vb6olvegZc for <core@ietfa.amsl.com>; Tue, 21 Mar 2023 10:13:48 -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 AEB91C14CE2C for <core@ietf.org>; Tue, 21 Mar 2023 10:13:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C3DFB3898C; Mon, 20 Mar 2023 08:30:21 -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 FGN248Ym2RNl; Mon, 20 Mar 2023 08:30:20 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4560A3898B; Mon, 20 Mar 2023 08:30:20 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1679315420; bh=m6vH+/4mzgIinJ1RQMOhl5/xRVxQxzfKBLkv5y8YngU=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=KJ9wDWFqbbTm0WzVk5JtDP4Ibqs9W9Go6FAi9LDHwvnafEfmnHtWafC9iH0C3u+9I yAdxB8j0UGNi3eua5yG/m5vDtawK340ug23UrDBPHe1s5nsYXYNbtFz4zx3ZMFMSYj /7vwkt+oYNK7tgVeiH6XVt40C6f9nTbHEqwxdo4WP/wm4CWDQFoKhnXy0OW0njxJDK 4N/aXUTYQHecchBw0i7p6pcT57cRyUFYCBG2+2etHabARGXMH4EPYDSAe+VyVRRP/1 JiUklhJVvSF/eVBCyucHiOvblFLWgbz+gS8YYj+BCsBYUYCjposa362B53RseXhsP5 mpkiz8Lzx6vTg==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 296F6B18; Mon, 20 Mar 2023 07:57:24 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Jernej Tuljak <jernej.tuljak@mg-soft.si>
cc: core@ietf.org
In-Reply-To: <bed2e140-d5e3-2aba-c2e1-6c8066602660@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>
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: Mon, 20 Mar 2023 07:57:24 -0400
Message-ID: <28078.1679313444@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/5WgRneo-Qm0WAitKZmmWlj8-x6g>
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: Tue, 21 Mar 2023 17:13:53 -0000

Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:
    > The issue I stumbled upon is not the number of mappings, but how the actual
    > mapping for rc:yang_data is done after my changes compared to master.

You have introduced a possible instability in assignments :-)
I can live with that as a one-time hit if it makes the code better, but are
you sure that your code is itself stable?  That might mean sorting keys of a
dict before using them.

    > The difference is that the paths contain the node that represents
    > rc:yang-data in my case (in addition to this node being present in the
    > mapping). That is probably the safer option. There is nothing that prevents a
    > data modeler to define a top-level data definition statement with the same
    > argument as the container within rc:yang-data. For example, in
    > "ietf-constrained-voucher", there could be the following top-level container
    > defined:

    > rc:yang-data voucher-constrained-artifact {
    >     // same as before, statements resulting in a container named "voucher"
    > }

    > container voucher {
    >     // same name as the container within sibling rc:yang-data statement
    > }

Fair enough.

    > The unpatched code would map both "voucher" containers to a single SID,
    > resulting in an ambiguity.

That would be bad.

    > core-sid text should explicitly state that whether it considers rc:yang-data
    > node to be a schema node or not, because neither RFC8040 nor RFC7950 consider
    > it as such. ietf-sid-file YANG module says those values must be schema node
    > identifiers (with the name prefix simplifications).

! I'm really glad to have a second set of eyes on the running code.
Thank you.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide