Re: [netmod] Clarify the meaning of property in RFC7950

Andy Bierman <andy@yumaworks.com> Sat, 13 May 2023 19:49 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC9DC15155C for <netmod@ietfa.amsl.com>; Sat, 13 May 2023 12:49:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks.com
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 QOfUhrp_6f_l for <netmod@ietfa.amsl.com>; Sat, 13 May 2023 12:49:02 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 BB9D7C15155E for <netmod@ietf.org>; Sat, 13 May 2023 12:49:01 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2ac8cc8829fso106297211fa.3 for <netmod@ietf.org>; Sat, 13 May 2023 12:49:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks.com; s=google; t=1684007339; x=1686599339; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Bts+wWa81zeeS5fUHT2qBrKLPi9ygULGABOwXAfCfDw=; b=tDxUX5F7+9PDQzex1jPi2RnHWIqQuKQ+mlYiaqwmeZEFUwc6IzSzYg/WOcBdTVXLb8 BROu8DmYpwsim3RJ+09lDR0ox5fr/XrU/rSbWgkuYCXTSrbs6ekoKz2omNqi28r4hsOu b5h0nFY8ZC7s+TKaMq4tZBFujT5s3jotidk/9SrLbZZ6E+ZQ4Lqyl5GsWkMPI/QqZygH eDQpsBGV2PF94TxiCH0EmV7hSZCeIWXoofjOcDc7khl3HKzk8ES9G2CBa0TsRtdYdqwS eA1O1koXLdlKyQ+OZtwuV9IbNPRox3eJ/ibWShq+SbHiUl+x5hUQIh1XEizCWzkpyt5E yVbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684007339; x=1686599339; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Bts+wWa81zeeS5fUHT2qBrKLPi9ygULGABOwXAfCfDw=; b=Qn6hjFbcA+3GArjVPmAc74uyT3HzzC7EiP8sr8nJqq2anVnhecIxzWPG1O0RXIzm6e Em4xPTYWtloQm9zFrlFMVNMcUwrnUoR+TfB5MoJ8rLMotM7IgKuc0TgATQfPejT2T86x WoOw0ZUouF0xNMvhWOD5NdatZe1pEvcVZumX78caPouzncLf3jEcpb7WBCnhq7sWH/tF 3oamdDzwpfp4tkML5ixsviIvNFQ48v5rYW6GArzd6C8seCTVt6OEmRT0m7oCXwJfqzRM QeFacq43urQtPry4ikS0T+O+LdMRvLxa/DLPxdQqh3kXagmS5guoRNG66qI0VOWHidyW zODQ==
X-Gm-Message-State: AC+VfDzW21XyGAt4VwVTSZNF9kTEykXZ+RFdkuLRSvkzFSNYnM2PmRz5 ADHBH0YjxiU+cDcZ6K6Fcu/Xjb9QKsUMc2lgT26HaQ==
X-Google-Smtp-Source: ACHHUZ4sF/IXkPfzySKM2v1Tq+xwDUrgGh3xDymW5UX7C+hA7Y40RL9D9emDD0Ifv6HqcN+Ey3aQoQro2RTrMLz6+I8=
X-Received: by 2002:a2e:7308:0:b0:2a8:a5b8:184a with SMTP id o8-20020a2e7308000000b002a8a5b8184amr5372803ljc.40.1684007339038; Sat, 13 May 2023 12:48:59 -0700 (PDT)
MIME-Version: 1.0
References: <a303de0d14104061975165f3fbdc647b@huawei.com> <DM6PR08MB5084418C99B18AE0A987BEFF9B7A9@DM6PR08MB5084.namprd08.prod.outlook.com>
In-Reply-To: <DM6PR08MB5084418C99B18AE0A987BEFF9B7A9@DM6PR08MB5084.namprd08.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Sat, 13 May 2023 12:48:47 -0700
Message-ID: <CABCOCHTqHAeEQGxY8+0qwVOGJaTgagYMNZyi+W6sKq0FUFaMHA@mail.gmail.com>
To: "Jason Sterne (Nokia)" <jason.sterne@nokia.com>
Cc: "Fengchong (frank)" <frank.fengchong=40huawei.com@dmarc.ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003e2f1705fb9883e7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Kd7O2RS678zV1nJYvlJvrpUhtHI>
Subject: Re: [netmod] Clarify the meaning of property in RFC7950
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 May 2023 19:49:05 -0000

Hi,

On Sat, May 13, 2023 at 12:02 PM Jason Sterne (Nokia) <
jason.sterne@nokia.com> wrote:

> Hi Frank,
>
>
>
> The table just after the text has this:
>
>
>
> +--------------+--------------+-------------+
>
>                | substatement | section      | cardinality |
>
>                +--------------+--------------+-------------+
>
>                | config       | 7.21.1       | 0..1        |
>
>                | default      | 7.6.4, 7.7.4 | 0..n        |
>
>                | mandatory    | 7.6.5        | 0..1        |
>
>                | max-elements | 7.7.6        | 0..1        |
>
>                | min-elements | 7.7.5        | 0..1        |
>
>                | must         | 7.5.3        | 0..n        |
>
>                | type         | 7.4          | 0..1        |
>
>                | unique       | 7.8.3        | 0..n        |
>
>                | units        | 7.3.3        | 0..1        |
>
>                +--------------+--------------+-------------+
>
>
>
>                         The deviate's Substatements
>
>
>
> That implies to me (since it says “deviate’s substatements”, not just
> “delete substatements”) that only those items can be added/changed/deleted.
> That table is the list of “properties”.
>
>
>
> But the other part of your question here isn’t so clear to me either.
> Every node does have a config true or false property associated with them
> (either explicitly, by default, or inherited from an ancestor). But does
> that mean it “exists” (from the ‘replace’ paragraph)? Does that mean it
> “matches a corresponding keyword in the targer node (from the ‘delete’
> paragraph)?
>
>
>


IMO libyang is correct.

Maybe the RFC text refers to the actual 'config' statement, and 'property'
is not precise terminology.
Every node has an effective config property so it would never be possible
to "add" a config-stmt, only "replace" it.



> In some ways maybe either add or replace should just work in this case
> since it isn’t really ambiguous what the result should be.
>
>
>

Agreed.
I just checked, and our compiler works this way.
It does the patch for add or replace, whether the node has an existing
config-stmt or not.  (oops),


Jason
>


Andy


>
>
> *From:* netmod <netmod-bounces@ietf.org> *On Behalf Of *Fengchong (frank)
> *Sent:* Monday, May 8, 2023 2:15 AM
> *To:* netmod@ietf.org
> *Subject:* [netmod] Clarify the meaning of property in RFC7950
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
> Hi all,
>
>
>
> In RFC7950 sec *7.20.3.2 <https://datatracker.ietf.org/doc/html/rfc7950#section-7.20.3.2>:*
>
>
>
>    The argument "add" adds properties to the target node.  The
>
>    properties to add are identified by substatements to the "deviate"
>
>    statement.  If a property can only appear once, the property MUST NOT
>
>    exist in the target node.
>
>
>
>    The argument "replace" replaces properties of the target node.  The
>
>    properties to replace are identified by substatements to the
>
>    "deviate" statement.  The properties to replace MUST exist in the
>
>    target node.
>
>
>
>    The argument "delete" deletes properties from the target node.  The
>
>    properties to delete are identified by substatements to the "delete"
>
>    statement.  The substatement's keyword MUST match a corresponding
>
>    keyword in the target node, and the argument's string MUST be equal
>
>    to the corresponding keyword's argument string in the target node.
>
>
>
> What’s the meaning of property? Is it a sub-statement?
>
>
>
> I see pyang and libyang have two different explanation. Pyang treat ‘config’ property as always exist property, because ‘config’ statement has default value (true or derived from parent).
>
> But libyang think if there is no ‘config’ sub-statement, then the ‘config’ property will be not exist.
>
>
>
> So there is a conflict when using pyang/libyang to parse YANG module.
>
> For example,
>
> Module a {
>
> Container a {
>
>
>
>    Leaf b {
>
>      Type string;
>
>    }
>
> }
>
>
>
> }
>
>
>
> Module a-dev {
>
>    Deviation  “/a:a/a:b” {
>
>      Deviate add {
>
>        Config false;
>
>     }
>
>    }
>
> }
>
>
>
> This example, pyang will report error, because pyang think ‘config’ property is always exist, so this propery should not be added. But libyang think it’s valid.
>
>
>
> If we change the type of deviate from ‘add’ to ‘replace’.
>
>
>
> Module a-dev {
>
>    Deviation  “/a:a/a:b” {
>
>      Deviate replace {
>
>        Config false;
>
>     }
>
>    }
>
> }
>
>
>
> Pyang will think it’s valid. But libyang think it’s invalid.
>
>
>
> So I think WG should clarify what’s the meaning of property.
>
>
>
> Ref:
>
> Issue on pyang: https://github.com/mbj4668/pyang/issues/815
>
>
>
> Issue on libyang: https://github.com/CESNET/libyang/issues/2010
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>