[netmod] 答复: Clarify the meaning of property in RFC7950

"Fengchong (frank)" <frank.fengchong@huawei.com> Mon, 15 May 2023 07:20 UTC

Return-Path: <frank.fengchong@huawei.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 2CBC5C15199B for <netmod@ietfa.amsl.com>; Mon, 15 May 2023 00:20:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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
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 AyGpkgP-eif8 for <netmod@ietfa.amsl.com>; Mon, 15 May 2023 00:20:14 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 934F4C151992 for <netmod@ietf.org>; Mon, 15 May 2023 00:20:13 -0700 (PDT)
Received: from lhrpeml100002.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4QKW1Z2rzHz67bc0; Mon, 15 May 2023 15:18:26 +0800 (CST)
Received: from dggpemm500004.china.huawei.com (7.185.36.219) by lhrpeml100002.china.huawei.com (7.191.160.241) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Mon, 15 May 2023 08:20:10 +0100
Received: from dggpemm500003.china.huawei.com (7.185.36.56) by dggpemm500004.china.huawei.com (7.185.36.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Mon, 15 May 2023 15:20:08 +0800
Received: from dggpemm500003.china.huawei.com ([7.185.36.56]) by dggpemm500003.china.huawei.com ([7.185.36.56]) with mapi id 15.01.2507.023; Mon, 15 May 2023 15:20:08 +0800
From: "Fengchong (frank)" <frank.fengchong@huawei.com>
To: Andy Bierman <andy@yumaworks.com>, "Jason Sterne (Nokia)" <jason.sterne@nokia.com>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] Clarify the meaning of property in RFC7950
Thread-Index: AdmBefkBKomkmJgWTNm+QEIS0h06QQEUfDiAAAIHHhkASggBcA==
Date: Mon, 15 May 2023 07:20:08 +0000
Message-ID: <d734f12422c4436db65c5c9c06ddb232@huawei.com>
References: <a303de0d14104061975165f3fbdc647b@huawei.com> <DM6PR08MB5084418C99B18AE0A987BEFF9B7A9@DM6PR08MB5084.namprd08.prod.outlook.com> <CABCOCHTqHAeEQGxY8+0qwVOGJaTgagYMNZyi+W6sKq0FUFaMHA@mail.gmail.com>
In-Reply-To: <CABCOCHTqHAeEQGxY8+0qwVOGJaTgagYMNZyi+W6sKq0FUFaMHA@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.113.127]
Content-Type: multipart/alternative; boundary="_000_d734f12422c4436db65c5c9c06ddb232huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/o1j4V321Kuten3QbPzVXn-bfgRU>
Subject: [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: Mon, 15 May 2023 07:20:18 -0000

Hi Andy,
    Please see my reply inline.


发件人: Andy Bierman [mailto:andy@yumaworks.com]
发送时间: 2023年5月14日 3:49
收件人: Jason Sterne (Nokia) <jason.sterne@nokia.com>
抄送: Fengchong (frank) <frank.fengchong@huawei.com>; netmod@ietf.org
主题: Re: [netmod] Clarify the meaning of property in RFC7950

Hi,

On Sat, May 13, 2023 at 12:02 PM Jason Sterne (Nokia) <jason.sterne@nokia.com<mailto: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.
[frank]: the actual ‘config’ statement is effective sub-statement?
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),
[frank]: So, ‘add’ or ‘replace’ should be implemented as ‘merge’?

How about other statements? For instance, ‘mandatory’, ‘type’, ‘min-elements’, etc.

Jason


Andy


From: netmod <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org>> On Behalf Of Fengchong (frank)
Sent: Monday, May 8, 2023 2:15 AM
To: netmod@ietf.org<mailto: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<http://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<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod