Re: [netconf] Usage examples for max-depth (rfc8526)

"Wisotzky, Sven (Nokia - DE/Stuttgart)" <sven.wisotzky@nokia.com> Tue, 19 March 2019 05:39 UTC

Return-Path: <sven.wisotzky@nokia.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2A5130EFA for <netconf@ietfa.amsl.com>; Mon, 18 Mar 2019 22:39:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
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 mG_O3PO9mi8L for <netconf@ietfa.amsl.com>; Mon, 18 Mar 2019 22:39:40 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40091.outbound.protection.outlook.com [40.107.4.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D6C51277CE for <netconf@ietf.org>; Mon, 18 Mar 2019 22:39:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6LAUh0b3e8Sm8+0IMcLyrmjrXOp8wgSIi9aqXofzhaI=; b=b0KT9rHaUOgWeSOp+Sz7CGWH1OhxUTrM1kuIcImKwSMgO/zaEKRxdrrKlPDrj8QSIHZPDKl7rjlasGS8pJiZYKsLWHBNYvH4F/kCqyFO1Msk7sr+nmyShCwDxv9F8ugr9lE2DMZNzQkBZAH78lTIjwlcfLaV34wRqmGwJ4SkwH4=
Received: from AM6PR07MB5382.eurprd07.prod.outlook.com (20.178.91.74) by AM6PR07MB5060.eurprd07.prod.outlook.com (20.177.188.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.15; Tue, 19 Mar 2019 05:39:36 +0000
Received: from AM6PR07MB5382.eurprd07.prod.outlook.com ([fe80::8df:27dd:40f:ec82]) by AM6PR07MB5382.eurprd07.prod.outlook.com ([fe80::8df:27dd:40f:ec82%2]) with mapi id 15.20.1709.015; Tue, 19 Mar 2019 05:39:36 +0000
From: "Wisotzky, Sven (Nokia - DE/Stuttgart)" <sven.wisotzky@nokia.com>
To: wangzitao <wangzitao@huawei.com>, =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= <balazs.lengyel@ericsson.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] Usage examples for max-depth (rfc8526)
Thread-Index: AdTeA8WykGakdwrtSgumgqfLSpkB8wAGr8oA
Date: Tue, 19 Mar 2019 05:39:36 +0000
Message-ID: <0A40D464-BAE8-4B80-B06F-2910E14D313C@nokia.com>
References: <E6BC9BBCBCACC246846FC685F9FF41EA2D973176@DGGEMM527-MBX.china.huawei.com>
In-Reply-To: <E6BC9BBCBCACC246846FC685F9FF41EA2D973176@DGGEMM527-MBX.china.huawei.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.17.0.190309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=sven.wisotzky@nokia.com;
x-originating-ip: [176.35.138.139]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b608e303-a0ec-49ba-d886-08d6ac2d461c
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR07MB5060;
x-ms-traffictypediagnostic: AM6PR07MB5060:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <AM6PR07MB5060F758A55BB62828983A49E9400@AM6PR07MB5060.eurprd07.prod.outlook.com>
x-forefront-prvs: 0981815F2F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(366004)(376002)(396003)(39860400002)(199004)(189003)(36756003)(446003)(81166006)(53376002)(6246003)(53936002)(105586002)(106356001)(68736007)(5660300002)(97736004)(82746002)(2906002)(8676002)(4326008)(71190400001)(83716004)(71200400001)(6512007)(6306002)(66066001)(33656002)(81156014)(7736002)(186003)(25786009)(66574012)(8936002)(3846002)(229853002)(6116002)(14444005)(102836004)(256004)(478600001)(99286004)(14454004)(486006)(6486002)(305945005)(6436002)(966005)(26005)(6506007)(316002)(86362001)(2616005)(110136005)(11346002)(76176011)(58126008)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB5060; H:AM6PR07MB5382.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: voBBWGRIBdP7U/UQ1ZgGHp27aox/Jmy6Z2IC+x43VbAEIkQlqK3TPs4XSx1V2qRVqYuou8C3FFVNe2z8KUPBO1yx4cfVyeWZyFeFISvIas9VDnZB4otHsFWLsTf1a11VFGLuI/hMFgFy5xVU8ybqqJCWn9k115TdAYLB+GhJhTSj6SVwpaS6JpHJPWnulV/ePscdYoH0QMWoi1ebPiKACFRDO/YNAZssh8EPhIF9ycJl+W1IosC/EqWeQenheClI37MIAc2LuG0ZZYRLWzYMzgSDXUMIX2aB5MKv/xN+Jpehwbw/HSUCaUnBMv5iYqAxzTI+FA2eGXJxsWrPC5M9OBEJFuqAVf84FPq13M9ze0AGHWiqCNlzclqTCl4q5rDUNepYOB5XndHJ5EYT/ju5ICb+4c2AI+aYPYxIzF6X0LQ=
Content-Type: text/plain; charset="utf-8"
Content-ID: <6470E81ADB16FA4BBCB14AD9EB366613@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b608e303-a0ec-49ba-d886-08d6ac2d461c
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2019 05:39:36.7794 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5060
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/7uhLRRX58Ow3WeZ3X6WyG_R3w90>
Subject: Re: [netconf] Usage examples for max-depth (rfc8526)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Mar 2019 05:39:43 -0000

Michael,

Actually I've got an use-case, which requires me to understand if a container or list contains data/entries - while I would like to avoid asking the complete lists as it could be gigantic. I was just wondering if max-depth is the right way of implementing my use-case. But in that case, I would actually prefer, if just a single instance of <user/> is returned. If we would return the empty <user/> element for all list entries - it would become a way to tell the client the number of list entries, which would be useful for me as well - but very inefficient.

/wiso
---

On 19.03.19, 03:36, "netconf on behalf of wangzitao" <netconf-bounces@ietf.org on behalf of wangzitao@huawei.com>; wrote:

    
    -----邮件原件-----
    发件人: netconf [mailto:netconf-bounces@ietf.org] 代表 Balázs Lengyel
    发送时间: 2019年3月18日 23:00
    收件人: netconf@ietf.org
    主题: Re: [netconf] Usage examples for max-depth (rfc8526)
    
    As a private opinion:
    
    Providing a list without keys is kind of useless. IMHO keys should always be present if the list is allowed by depth. In my view the correct answer is:
    
    Example 3: no subtree filter is provided, max-depth=3
            <top xmlns="http://example.com/schema/1.2/config">
              <users>
                <user>
                   <name>Joe</name>
                </user>
                <user>
                   <name>Bill</name>
                </user>
                <user>
                   <name>Balazs</name>
                </user>
              </users>
            </top>
    
    So even if the key name is strictly speaking on depth=4 it should be included in a level 3 get result.
    
    [Michael]: Based on RFC8040, it will only output the <user> list level (depth 4), however, for a list without key and anther parameters, it doesn't seem to be meaningful.
    
    regards Balazs
    
    On 2019. 03. 14. 9:53, Wisotzky, Sven (Nokia - DE/Stuttgart) wrote:
    > Unfortunately the info provided in RFC 8526 about the max-depth attribute is not very precise.
    > Is it fair to assume, that behavior is aligned with the RESTCONF "depth" attribute described in RFC 8040?
    >
    > Let's use the following sample from chapter 3.1.1.3:
    >         <top xmlns="http://example.com/schema/1.2/config">
    >           <users>
    >             <user>
    >               <name>root</name>
    >               <type>superuser</type>
    >               <full-name>Charlie Root</full-name>
    >               <company-info>
    >                 <dept>1</dept>
    >                 <id>1</id>
    >               </company-info>
    >             </user>
    >             <!-- additional <user> elements appear here... -->
    >           </users>
    >         </top>
    >
    > Example 1: no subtree filter is provided, max-depth=1
    >         <top xmlns="http://example.com/schema/1.2/config">
    >         </top>
    >
    > Example 2: no subtree filter is provided, max-depth=2
    >         <top xmlns="http://example.com/schema/1.2/config">
    >           <users>
    >           </users>
    >         </top>
    > Assumption the container <users> would only be present in the result, if this container has any explicit children configuration. If there is no children config, it would not be part of the output.
    >
    > Example 3: no subtree filter is provided, max-depth=3
    >         <top xmlns="http://example.com/schema/1.2/config">
    >           <users>
    >             <user>
    >             </user>
    >           </users>
    >         </top>
    > Somewhat interesting scenario. It provides the netconf client with a method to check, if a list contains any entries. So if the XML node <user> is contained, we would know that the list "user" has at least one entry. However, this XML output would not validate against the YANG model - because list-keys (user/name) are mandatory. In essence, that client requires to be flexible when parsing such result and cannot be restricted to YANG.
    >
    > Example 4: no subtree filter is provided, max-depth=4
    >         <top xmlns="http://example.com/schema/1.2/config">
    >           <users>
    >             <user>
    >               <name>root</name>
    >               <type>superuser</type>
    >               <full-name>Charlie Root</full-name>
    >               <company-info>
    >               </company-info>
    >             </user>
    >             <!-- additional <user> elements appear here... -->
    >           </users>
    >         </top>
    > Similar to example 2, the container <company-info> would only be present, if this container has explicit children configuration.
    >
    >
    > Someone please to confirm, if those examples and assumptions being made are correct!
    >
    > /wiso
    >
    > _______________________________________________
    > netconf mailing list
    > netconf@ietf.org
    > https://www.ietf.org/mailman/listinfo/netconf
    >
    -- 
    Balazs Lengyel                       Ericsson Hungary Ltd.
    Senior Specialist
    Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
    
    
    _______________________________________________
    netconf mailing list
    netconf@ietf.org
    https://www.ietf.org/mailman/listinfo/netconf