Re: [netconf] Current activities on RESTCONF/NETCONF to support paging

"Wisotzky, Sven (Nokia - DE/Stuttgart)" <> Fri, 15 March 2019 14:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F001131281 for <>; Fri, 15 Mar 2019 07:51:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3hNeExEJORd2 for <>; Fri, 15 Mar 2019 07:51:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9FB0F131273 for <>; Fri, 15 Mar 2019 07:51:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Leie06su3+GlGkVsZJ0ALGFG4mg4BQACyp/E2JPjjng=; b=MJZ6SBY0hgHOuc49FhRtcAB06J63SdTzASOY51Rzg8tbvgzw8l0Xk3hQ/TgMv5JTlSyDUygZN59n9DykbJVFJaD9TaMfvSL6Z3T2Lc1Gb+o3PfWv6ddrBnulm/Ql72HnpZs2X+ENzw7rdqI9IF+BXIfOZfR3GGsFjF/vwzVhdcw=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.6; Fri, 15 Mar 2019 14:51:13 +0000
Received: from ([fe80::b093:11dd:7567:2100]) by ([fe80::b093:11dd:7567:2100%4]) with mapi id 15.20.1730.003; Fri, 15 Mar 2019 14:51:13 +0000
From: "Wisotzky, Sven (Nokia - DE/Stuttgart)" <>
To: Robert Varga <>, wangzitao <>, Douglas Hubler <>
CC: "" <>
Thread-Topic: [netconf] Current activities on RESTCONF/NETCONF to support paging
Thread-Index: AdTa0NoVunCd1tZJRWC3RA+1mlX0vQAQ1NuAAAlAPgAAA28FgA==
Date: Fri, 15 Mar 2019 14:51:13 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e6030155-7885-4ad5-450c-08d6a955aba7
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:AM6PR07MB5911;
x-ms-traffictypediagnostic: AM6PR07MB5911:
x-ms-exchange-purlcount: 2
authentication-results: spf=none (sender IP is );
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 09778E995A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(396003)(346002)(136003)(366004)(199004)(189003)(71190400001)(5660300002)(305945005)(36756003)(966005)(6306002)(8936002)(6512007)(14454004)(68736007)(7736002)(4326008)(81156014)(71200400001)(8676002)(53936002)(2906002)(83716004)(110136005)(6116002)(229853002)(99286004)(58126008)(316002)(66066001)(6246003)(3846002)(82746002)(14444005)(6506007)(33656002)(11346002)(561944003)(256004)(476003)(2616005)(76176011)(97736004)(81166006)(6486002)(106356001)(105586002)(446003)(25786009)(478600001)(6436002)(102836004)(86362001)(186003)(53546011)(486006)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB5911;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: X8aM7f+sLYJYqBD1o4FYfaEyHLdkZEcReduZRFYVnX2S8FBM3ZwhDLksOUcty0P+apGJK8vJDZKRitlTOthYftbGvYRgt1KvSiByq0c5ABkMMcSlyC+dCd6a8Ea6kwsSq0mo4QkNDTxcGGzXHgl/1HxTEbWHq/JXkhgWOKMQWhj5ExSOORqOGWz7AyBCV6mTaZva9t+XPnysEY25aD4425p/2SZQBkkazfZKFS/ZWKjHtCVRf8wwa4VuPch52dxtlDZk9WLGBQTCksc+BR6Eo7p4tZCvmEL9EqdmYLuQvbj6F3o8c7NA4nVnTKe3xpa7y99UdXLIjaDq/X3vOHW6unrVMNrtgul+tRQXqVhOk8fzO1RIDCtRNjwewtL/UdpaVyD3uF++rU/ZwrLpzlAfnaomx8q7sHbN/Yao6y2qOwM=
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e6030155-7885-4ad5-450c-08d6a955aba7
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2019 14:51:13.5613 (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: AM6PR07MB5911
Archived-At: <>
Subject: Re: [netconf] Current activities on RESTCONF/NETCONF to support paging
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 Mar 2019 14:51:26 -0000


I would be okay with the limit/offset attributes suggested in draft-ietf-netconf-restconf-collection-00. So this would basically avoid any session state on the server. I do agree, that such approach comes at the caveat that tables might dynamically change while one is requesting follow-up pages. But with all fairness, this is not even guaranteed with traditional NETCONF get / get-config today - given existing vendor's implementations.

Is your suggestion around XPATH, that the WebUI would automatically render smart selection filters such as:
//foo/bar[100 <= position() and position() < 200]
subsequence( /foo/bar, 100, 100 )

I do agree, that this certainly would serve its purpose, depending on the support of XPATH including the position/subsequence functions. But would be concerned would be this dependency. Not really sure, how many vendors do really have full filter/xpath support today in their NETCONF/RESTCONF stacks - at least I do not remind any. Also I could not think of an efficient implementation of this. Likely one would render the full XML document and after this applying the XPATH query. As we are speaking here about extra-large tables - the raw XML document could easily have 100.000's of entries aka 100's of Mbytes. Not really sure about the performance impact and footprint of such solution - but doubt this is the right way of doing it.

I guess your other proposal about YANG PUSH would be almost in the lines of gNMI ONCE subscription. Not sure about about all the implications of this.


´╗┐On 15.03.19, 15:13, "Robert Varga" <>; wrote:

    On 15/03/2019 09:48, Wisotzky, Sven (Nokia - DE/Stuttgart) wrote:
    >> Actually, there are some discussions in this WG. And there is an draft that try to address these issues ( IMO, these problems also exist in NETCONF, therefore, a common solution is required. 
    > It should have been clear from my initial ask. Yes, I am actually interested in a solution which serves both NETCONF and RESTCONF. The problem might be seen more important for RESTCONF - as this is considered protocol of choice for network controllers, talking about a larger scale of objects and traditionally used for communication between WebUI and back-end.
    That is a valid point, but I think this would end up creating a protocol
    on top of RESTCONF, where start of iteration/pagination would create
    some session state on the server.
    I do not want to explode the scope of work, but wouldn't WebUI users be
    better served with a general XPath-based query facility (for example
    allowing filter on GETs)?
    Alternatively, could the problem perhaps be reformulated in terms of