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

Carsten Bormann <cabo@tzi.org> Fri, 24 March 2023 14:24 UTC

Return-Path: <cabo@tzi.org>
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 9367AC15152F for <core@ietfa.amsl.com>; Fri, 24 Mar 2023 07:24:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 ev1p2bBTNJBX for <core@ietfa.amsl.com>; Fri, 24 Mar 2023 07:24:55 -0700 (PDT)
Received: from smtp.uni-bremen.de (smtp.uni-bremen.de [134.102.50.15]) (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 1C2EFC15152D for <core@ietf.org>; Fri, 24 Mar 2023 07:24:52 -0700 (PDT)
Received: from smtpclient.apple (fs85a5b6e1.knge202.ap.nuro.jp [133.165.182.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 4PjkxY0QYmzDCbw; Fri, 24 Mar 2023 15:24:48 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <fb260343-b552-ff15-7665-2033ca209120@mg-soft.si>
Date: Fri, 24 Mar 2023 23:24:35 +0900
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, core@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <BF44B88C-F421-4062-99D5-BD459F651F18@tzi.org>
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>
To: Jernej Tuljak <jernej.tuljak@mg-soft.si>
X-Mailer: Apple Mail (2.3731.400.51.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/F_gztdXK1LHijxZwISv95VN9x4c>
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: Fri, 24 Mar 2023 14:24:59 -0000

Hi Jernej,

Thank you for your implementation work — I hope I can look into this some more tomorrow at the hackathon.


> On 24. Mar 2023, at 22:49, Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:
> 
> You are asking if the same SIDs would be assigned to items of the same YANG module, no matter where this plugin is run. I think this is the case - provided that the version of pyang is the same. The only way to know for sure would be to test for this. If this is a problem in my implementation, it is also a problem in the original one.

I think it might help to point out that we have to levels of requirements here:

— absolute MUSTs
— nice to haves.

The MUSTs include that a SID file that is generated with a an existing SID file and an updated module as input does not change the assignments for the existing (putatively stable) inputs.

The nice to haves include that two people running the same command on the same data get the same output, for some range of platform (e.g., Python) versions.  For Python that probably is limited to the range where insertion order preservation was made a language feature.

Another nice to have is that a small change in the input should not generate wildly different output (this is not a cryptographic hash function :-).  Those who want to survive changes with the least disruption can use the above MUST-have feature — even while still in the unstable state.  Some disruption is unavoidable if this is not done — if a new item is inserted at the start of the module, it will be hard to keep all numbers unchanged (unless we use Laurent’s approach — which requires some attention to avoid deltas getting larger than needed).
The idea to group identities separate as they are usually not subject to delta-encoding (data items are) could be generally applicable, though.

Grüße, Carsten