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

Jernej Tuljak <> Mon, 20 March 2023 14:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9BD6C137386 for <>; Mon, 20 Mar 2023 07:41:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, NICE_REPLY_A=-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
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gFSUg-EpVUv8 for <>; Mon, 20 Mar 2023 07:41:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B4CA1C13AE5F for <>; Mon, 20 Mar 2023 07:41:39 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTP id 9D9B8C41D791; Mon, 20 Mar 2023 15:41:37 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.11.0 9D9B8C41D791
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1679323297; bh=Zsa5Kk8KEGFKJD2kzZL4JSa56YzpoeR5Fhlod98pc5M=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=JTZnGX3xTt/2WCxSIXcPrnCJjbgkpg2fbyDKFBpZnzFz3JJjfp/dRoOmPh43JUtrE pbTSVpNZfJ5B6/9MrSNFY/idHnC9GALPiMIpNzRGgJTv4MLrdBnU8kuk22MIoHaXvi mbXQxUHG2TNbVSW7G4W+ksSFtmOljHuYzXaUgKUBS6MmB4DG0xJ2lBZ6DG10tlWcH6 q7NZRpWXNzStycIBqWxWXY6F28mIGuSw0aJVbl3kKXVCxN1i4cFDMNjzW4/pCVzYSm GeVu6VUd1pz1KMCskubo43GEHJvJP7r1zr3BENUplp7UfRLLqOi9RIDI+AFqq6u7iT SlRXbSWaGwEYQ==
Message-ID: <>
Date: Mon, 20 Mar 2023 15:41:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0
Content-Language: en-US
To: Michael Richardson <>
References: <mbj4668/pyang/pull/> <mbj4668/pyang/pull/839/> <2897262.1679232828@dyas> <> <28078.1679313444@localhost>
From: Jernej Tuljak <>
In-Reply-To: <28078.1679313444@localhost>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
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: Mon, 20 Mar 2023 14:41:46 -0000

On 20/03/2023 12:57, Michael Richardson wrote:
> 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.

I'm not sure I understand what you meant. Were you referring to the 
change in the order of assignments for schema nodes? Yes, those occur in 
"pyang definition order" (should be close to the definition order within 
YANG files) in my patch - and the change may be significant. There was 
some grouping by statement keyword lists done previously on each 
statement nesting level, which does not occur in my patch. Or did you 
mean something else?

I did go through all the tests to make sure nothing's breaking other 
than in expected ways, but the amount of cases those check is limited. 
That is also the only measure of stability I can provide at this time. I 
pushed (to my repo) the changes that would be required for test/test_sid 


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