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

Jernej Tuljak <jernej.tuljak@mg-soft.si> Mon, 20 March 2023 08:37 UTC

Return-Path: <jernej.tuljak@mg-soft.si>
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 029F3C1522D3 for <core@ietfa.amsl.com>; Mon, 20 Mar 2023 01:37:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.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_DNSWL_HI=-5, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mg-soft.si
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 erpbuepuassk for <core@ietfa.amsl.com>; Mon, 20 Mar 2023 01:37:17 -0700 (PDT)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 30BC8C14F738 for <core@ietf.org>; Mon, 20 Mar 2023 01:37:15 -0700 (PDT)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 1924EC41D791; Mon, 20 Mar 2023 09:37:14 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.11.0 galileo.mg-soft.si 1924EC41D791
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mg-soft.si; s=default; t=1679301434; bh=DGEZjo7M2clVFy5lH1E1MBRtaqNWaZ+K1ymUtZoedNE=; h=Date:Subject:To:References:From:In-Reply-To:From; b=o1ozaT30hMRWAtnH5autQs7PnJg2NIUhZV/h6OkjKMLYOliwzDn1x0OlKm79c11Ju +6UkK/c6cDEI6LOpLmzRxSzuqtCjxdt9siOuNwAD/mSJP5Or0weqSZd2eEZXDW6su/ pm/IcKC9py4wJpLXqMh2TJWB4X5DgPcb7N4++PZnWSnHaeoOtWWV7Nyr/ypB1xQks8 Yjzdz1bR5+ijzkQIBMjmgg7fUprdD+F6H0qAOS2ssIfM09MbqJw9w0xdo6BiRAUqk2 k+VpUWpwSUlnPtbdkBRpvDt/u5grSj2hEffbrcOlpkNT/Z7c3P4qV/FcsOZ6FV6oJf uas5lltvyGNVg==
Message-ID: <bed2e140-d5e3-2aba-c2e1-6c8066602660@mg-soft.si>
Date: Mon, 20 Mar 2023 09:37:14 +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
To: Michael Richardson <mcr+ietf@sandelman.ca>, core@ietf.org
References: <mbj4668/pyang/pull/839@github.com> <mbj4668/pyang/pull/839/c1474951745@github.com> <2897262.1679232828@dyas>
Content-Language: en-US
From: Jernej Tuljak <jernej.tuljak@mg-soft.si>
In-Reply-To: <2897262.1679232828@dyas>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/uMhtnFkvueV1EpPtqZgZOsmaZjU>
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: Mon, 20 Mar 2023 08:37:22 -0000

On 19/03/2023 14:33, Michael Richardson wrote:
> jernejt <notifications@github.com> wrote:
>      > Managed to get individual tests in "test/test_sid" working by invoking
>      > `make testX PYANG=pyang`, where X is the number of the test.
>
>      > Yeah, I may have broken rt:yang-data (test5). I'm not sure whether only
>      > the container within it is supposed to get a SID assigned, or both the
>      > container and the enveloping rt:yang-data "node" (this is the main
>      > difference compared to sx:structure). core-sid-20 should probably say
>      > something about this, but doesn't.
>
> Clearly, the document needs a sentence somewhere then
>
>      > Since the new proposal is to "assign
>      > a SID to everything" including stuff that does not currently get to be
>      > instantiated in instance documents, rt:yang-data node should probably
>      > be included in the mapping.
>
> Note that sid-item-status branch has a test-5 and a test-5sx.
>
> test-5 is constrained-voucher (augment/yang-data ersion), and definitely
> everything that has a sid allocated there should probably still have one.
> There are one or two things which were superfluous to the ANIMA WG's needs,
> but we did not worry about it.

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.

This is the former mapping (test5):

SID        Assigned to
---------  --------------------------------------------------
2500       module ietf-constrained-voucher
2501       data /ietf-constrained-voucher:voucher
2502       data /ietf-constrained-voucher:voucher/assertion
2503       data /ietf-constrained-voucher:voucher/created-on
2504       data 
/ietf-constrained-voucher:voucher/domain-cert-revocation-checks
2505       data /ietf-constrained-voucher:voucher/expires-on
2506       data /ietf-constrained-voucher:voucher/idevid-issuer
2507       data /ietf-constrained-voucher:voucher/last-renewal-date
2508       data /ietf-constrained-voucher:voucher/nonce
2509       data /ietf-constrained-voucher:voucher/pinned-domain-cert
2510       data 
/ietf-constrained-voucher:voucher/pinned-domain-subject-public-key-info
2511       data 
/ietf-constrained-voucher:voucher/pinned-sha256-of-subject-public-key-info
2512       data /ietf-constrained-voucher:voucher/serial-number

File ietf-constrained-voucher@2019-08-01.sid created
Number of SIDs available : 50
Number of SIDs used : 13

This is what I get with my patch:

SID        Assigned to
---------  --------------------------------------------------
2500       module ietf-constrained-voucher
2501       data /ietf-constrained-voucher:voucher-constrained-artifact
2502       data 
/ietf-constrained-voucher:voucher-constrained-artifact/voucher
2503       data 
/ietf-constrained-voucher:voucher-constrained-artifact/voucher/assertion
2504       data 
/ietf-constrained-voucher:voucher-constrained-artifact/voucher/created-on
2505       data 
/ietf-constrained-voucher:voucher-constrained-artifact/voucher/domain-cert-revocation-checks
2506       data 
/ietf-constrained-voucher:voucher-constrained-artifact/voucher/expires-on
2507       data 
/ietf-constrained-voucher:voucher-constrained-artifact/voucher/idevid-issuer
2508       data 
/ietf-constrained-voucher:voucher-constrained-artifact/voucher/last-renewal-date
2509       data 
/ietf-constrained-voucher:voucher-constrained-artifact/voucher/nonce
2510       data 
/ietf-constrained-voucher:voucher-constrained-artifact/voucher/pinned-domain-cert
2511       data 
/ietf-constrained-voucher:voucher-constrained-artifact/voucher/pinned-domain-subject-public-key-info
2512       data 
/ietf-constrained-voucher:voucher-constrained-artifact/voucher/pinned-sha256-of-subject-public-key-info
2513       data 
/ietf-constrained-voucher:voucher-constrained-artifact/voucher/serial-number

File ietf-constrained-voucher@2019-08-01.sid created
Number of SIDs available : 50
Number of SIDs used : 14

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
}

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

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

Jernej

>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>   -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
>
>
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core