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

Michael Richardson <> Tue, 21 March 2023 17:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE6FCC14CE31 for <>; Tue, 21 Mar 2023 10:13:52 -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 Y8vb6olvegZc for <>; Tue, 21 Mar 2023 10:13:48 -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 AEB91C14CE2C for <>; Tue, 21 Mar 2023 10:13:48 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3DFB3898C; Mon, 20 Mar 2023 08:30:21 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id FGN248Ym2RNl; Mon, 20 Mar 2023 08:30:20 -0400 (EDT)
Received: from ( []) by (Postfix) with ESMTP id 4560A3898B; Mon, 20 Mar 2023 08:30:20 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 (Postfix) with ESMTP id 296F6B18; Mon, 20 Mar 2023 07:57:24 -0400 (EDT)
From: Michael Richardson <>
To: Jernej Tuljak <>
In-Reply-To: <>
References: <mbj4668/pyang/pull/> <mbj4668/pyang/pull/839/> <2897262.1679232828@dyas> <>
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: <>
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: Tue, 21 Mar 2023 17:13:53 -0000

Jernej Tuljak <> 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 <>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide