IETF Logo Mail Archive

Re: [netmod] WG Last Call: draft-ietf-netmod-yang-data-ext version 4

Qin Wu <bill.wu@huawei.com> Wed, 02 October 2019 04:31 UTC

Return-Path: <bill.wu@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 232F412008C for <netmod@ietfa.amsl.com>; Tue, 1 Oct 2019 21:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ls8rOAu72U4a for <netmod@ietfa.amsl.com>; Tue, 1 Oct 2019 21:31:33 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AE4112004E for <netmod@ietf.org>; Tue, 1 Oct 2019 21:31:33 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 1A4A49840ED85196DA3D for <netmod@ietf.org>; Wed, 2 Oct 2019 05:31:31 +0100 (IST)
Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 2 Oct 2019 05:31:30 +0100
Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.72]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0439.000; Wed, 2 Oct 2019 12:31:28 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Joel Jaeggli <joelja@bogus.com>, NETMOD Working Group <netmod@ietf.org>
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-yang-data-ext version 4
Thread-Index: AdV41f/2A98S6N+pSy+XzYU6J3ni9w==
Date: Wed, 02 Oct 2019 04:31:27 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAA933E610@dggeml511-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.99.11]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA933E610dggeml511mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Xah_Ok913IDKxUVs1z8DG2mknFE>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-yang-data-ext version 4
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 02 Oct 2019 04:31:36 -0000

Hi, Auhors:
I have read the latest version and have the following comments:

1.       Try to understand the difference between anydata and YANG data structure extension? Is YANG data structure extension targeted to specify the format which can not be represented by anydata?

When will we use anydata? When will we use YANG data structure extension, would this be clarified in the introduction section.

2.        Why is YANG data structure extension not part of RFC7950 or RFC7950bis? It seems two top level YANG statements are introduced in this draft.

3.       In the introduction section, when we say there is no assumption that a YANG data structure can only be used as a top-level

   abstraction, instead of nested within some other data structure. I am wondering what other data structure looks like? Is other data structure specified by YANG data structure defined in this draft or data structure defined by anydata?

If the example is A.5, please add reference to Appendix A.5 in the introduction section.

4.       When we say YANG data structure extension is only valid as a top-level statement, does this conflict with YANG data structure can be nested within some other data structure?

5.       Why augment-structure is also only valid as a top-level statement, why augment-structure is not substatement of YANG data structure? Can we use augment-structure with other data structure instead of YANG data structure defined in this document?

6.       In A.5, how error-code is hooked into rpc-error? Why not use augment-structure in this case? Describe path statement to indicate the relationship with rpc error?

-Qin


发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Joel Jaeggli
发送时间: 2019年9月27日 13:32
收件人: NETMOD Working Group <netmod@ietf.org>
主题: [netmod] WG Last Call: draft-ietf-netmod-yang-data-ext version 4

All,

This starts a two week working group last call for  draft-ietf-netmod-yang-data-ext-04

The working group last call ends on  Friday October 11th 2019.  Please send your comments to the working group mailing list.

Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome!  This is useful and important, even from authors.

https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-04

The diff from 03, produced prior to IETF 105 is available here:

https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-netmod-yang-data-ext-04.txt

Thanks
Joel

v2.23.0 | Report a Bug | By Email