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

"Wisotzky, Sven (Nokia - DE/Stuttgart)" <sven.wisotzky@nokia.com> Thu, 14 March 2019 08:53 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 528C9127916 for <netconf@ietfa.amsl.com>; Thu, 14 Mar 2019 01:53:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 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] 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 yX1p-Fr1Xv6n for <netconf@ietfa.amsl.com>; Thu, 14 Mar 2019 01:53:03 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40120.outbound.protection.outlook.com [40.107.4.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482121277C9 for <netconf@ietf.org>; Thu, 14 Mar 2019 01:53:03 -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=d9uzytcNhdUQL4zsbumwPkUtgbPnfja2HDuJ2INhnZ0=; b=cmaDamvYhqY8j6SyEZKOFYIW2wdS0oTt+F8nHXHzyfyUTLsijmxKyUFj2y3gGdMIsOKw+Fzx89T1X/9IyOVmtQVBubZ5U2+zvqA9OXd04RYVrjqkpiGtR2QCjo0XBZGcSUpEN/WuaXGJt+AT4EVVLIEviGkAxvgprPv6qhEiQT4=
Received: from DB7PR07MB5386.eurprd07.prod.outlook.com (20.178.46.26) by DB7PR07MB4935.eurprd07.prod.outlook.com (20.177.192.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.8; Thu, 14 Mar 2019 08:53:00 +0000
Received: from DB7PR07MB5386.eurprd07.prod.outlook.com ([fe80::181c:32c6:16f2:7433]) by DB7PR07MB5386.eurprd07.prod.outlook.com ([fe80::181c:32c6:16f2:7433%3]) with mapi id 15.20.1709.011; Thu, 14 Mar 2019 08:53:00 +0000
From: "Wisotzky, Sven (Nokia - DE/Stuttgart)" <sven.wisotzky@nokia.com>
To: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: Usage examples for max-depth (rfc8526)
Thread-Index: AQHU2kNT5zRVd6q0aUyVnM8yIqQf4A==
Date: Thu, 14 Mar 2019 08:53:00 +0000
Message-ID: <0AA9F087-D2FF-42EA-8ACA-FD44FAA57890@nokia.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
x-originating-ip: [188.97.190.16]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5895082b-5aa4-407d-b23b-08d6a85a768e
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:DB7PR07MB4935;
x-ms-traffictypediagnostic: DB7PR07MB4935:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <DB7PR07MB4935793F4E0B3A5F636D326CE94B0@DB7PR07MB4935.eurprd07.prod.outlook.com>
x-forefront-prvs: 09760A0505
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(366004)(136003)(376002)(39860400002)(189003)(199004)(7736002)(97736004)(81166006)(53376002)(68736007)(102836004)(33656002)(105586002)(2906002)(2351001)(256004)(14444005)(106356001)(5660300002)(2501003)(8676002)(1730700003)(6506007)(8936002)(81156014)(25786009)(99286004)(3846002)(6116002)(6346003)(36756003)(316002)(478600001)(6916009)(2616005)(82746002)(58126008)(14454004)(486006)(186003)(26005)(476003)(5640700003)(305945005)(66066001)(6306002)(86362001)(71200400001)(6486002)(71190400001)(6512007)(83716004)(6436002)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB4935; H:DB7PR07MB5386.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=sven.wisotzky@nokia.com;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: MTZ1YC4WzZmpZmp0tMprU8+MxxuJsgMcqKRd5eRaxemWycglGNAqyhcVOZzPFbQpRFUvSNdegufUHcgxeNwZI3r3htEQRbnA6U/X3wSPKYaZH3h59iai9GkjEg4dRFXfNqG7SsT9fPpdfy7ZfbuXaNG0Sevfzgfl4294uFAuot6hf5nt6ZsREJL96j81v0espFlUmjxgoa0N/EV+MwXlkvh17DaxPmHJyEb2uZda4dFCDRu7ON/oYIpJbSNEjOfuXPxc9kFvTOrz1j7e1e8rr9445pEPweY9DhAFsX/EnY3EQZmX579tKHaDlHfREFMSMNEXrA54Jzb8Dxwg6m4rDTf/OTvse4kV3Jc4BhiEE2jEDWnGSd0fKEXn+yRKql8DzbEuBHdFtn5UzfsWMQeXR/1cl6ziBhxI04hBD55z5xo=
Content-Type: text/plain; charset="utf-8"
Content-ID: <EDE074D1C290FB4AA350A7DDB271476C@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5895082b-5aa4-407d-b23b-08d6a85a768e
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2019 08:53:00.7939 (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: DB7PR07MB4935
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/2XI2PmOwIlnlDlLYHdCYge_oqTc>
Subject: [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: Thu, 14 Mar 2019 08:53:06 -0000

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