From nobody Thu Oct 1 05:36:38 2020 Return-Path: <01000174e42a0ab6-d29a9843-5a7a-4804-acba-276a859e4612-000000@amazonses.watsen.net> 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 4CFEE3A0FFA for ; Thu, 1 Oct 2020 05:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 024NBU2E0pNj for ; Thu, 1 Oct 2020 05:36:36 -0700 (PDT) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DB3C3A0FB7 for ; Thu, 1 Oct 2020 05:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601555794; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=usURwUXrBfmyQXlVtVOm7QImjwGUI0keGj1LeqcQn7o=; b=EgV64SkUrSFXgf8DGewwTYZH+QX6yb8dnWxGC0zTQT0+lZXLG357Lr3GWdlPITHI MOpkV2nuOMxcw37ffspuuKS7NzNzSjRac+heSu5rdRAic2ynPA3FB8Eq3mGroQbAfHY TWDqEZPfjYPQftciJD6Bm3Tgr573qcG2HiNho3AY= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Kent Watsen In-Reply-To: Date: Thu, 1 Oct 2020 12:36:34 +0000 Cc: =?utf-8?Q?Martin_Bj=C3=B6rklund?= , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000174e42a0ab6-d29a9843-5a7a-4804-acba-276a859e4612-000000@email.amazonses.com> References: To: Qin Wu X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.10.01-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org 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: Thu, 01 Oct 2020 12:36:37 -0000 Hi Qin, > Some opstate must be persisted, e.g., long-lived counters, logs, etc., = but it=E2=80=99s a good point about other opstate not being persisted. = Perhaps =E2=80=9Cnode-tags=E2=80=9D can be used here, to differentiate = which is which=E2=80=A6and servers can indicate if/how they support the = ephemeral opstate leafs in queries? >=20 > [Qin]:That's a good case for node tag, in earlier discussion, we = discussed operation type, which distinguishs cumulative statistics value = from current value. The case discussed here is very close to operation = type proposal discussed earlier. Yes. Thank you for pointing that out. I meant to make the same = observation before. Indeed, such node-tags could have dual-purpose: to = guide a streaming-strategy and a querying-strategy for certain nodes. > Note sure how others feel about =E2=80=9Cdirection: (c), but my = primary use-case revolves around time-series data (e.g., logs), where = the interest is commonly on the most-recent entries, so = "reverse-->offset=E2=80=94>limit=E2=80=9D works nicely. =20 >=20 > Perhaps an alternative would be to lift a concept from Python with = negative indexes so, for instance, offset=3D-N and limit=3D-N gives the = last N entries? > [Qin]: Yes, that's what I thought as well, with negative indexes, (b) = and (c) seems to me, can be combined. Can others comment on this? Presumably, we could eliminate =E2=80=9Cdirection=E2=80=9D (c) with this = approach. =20 Without =E2=80=9Cdirection=E2=80=9D, I think that UIs can still support = the ability to do column-sorts, whereby the user clicks on a column=E2=80=99= s header to toggle ascending vs. descending presentation, but they=E2=80=99= ll have to do it client-side. That is, if wanting to see the 2nd page of results sorted by a column, = something like: sort(column-name) --> offset(-2*pagesize) --> limit(pagesize) Followed by the client then flipping the results to present the results = in the user-selected order, right? That said, given that DB-backends that support sorts commonly also = support direction, it's unclear what this buys us. >>> Sure, but I wonder if, e.g., a netmask filter, is supportable by=20 >>> common DB-backends. I=E2=80=99m hoping we have some DB-experts on = the list! >>=20 >> See above. It can be quite efficient even if the backend doesn't=20 >> support it. >=20 > I don=E2=80=99t see that above, but I don=E2=80=99t doubt that it can = be so, it=E2=80=99s just a whole lot of implementation complexity. It = seems that we should/must support servers doing it, we just need to find = a way (node-tags?) to enable them to express that ability. > [Qin]: My feeling is this efficiency more depends on the amount of = data we need to request. If amount of data we request is huge, maybe, = client-> server-> backend may be the better choice. Is it the amount of data requested or the number of entries in the list? = At least, in my worldview, clients are always requesting a =E2=80=9Cpage=E2= =80=9D of data, so that part is rather consistently small. If the intention is to get a complete dump, then maybe the comment from = yesterday applies, whereby streaming to an external repository that can = be queried offline makes more sense? - especially considering that = the number of on-box logs is likely to be only the most recent (e.g., = days), whereas the complete-dump type queries likely wish to extend = well-past that. K. From nobody Thu Oct 1 06:23:43 2020 Return-Path: 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 4893C3A104E for ; Thu, 1 Oct 2020 06:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.997, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=WqFLY7yf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MQUDpctK 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 QokHJz5bou6c for ; Thu, 1 Oct 2020 06:23:40 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC1E03A104D for ; Thu, 1 Oct 2020 06:23:40 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 108AC1286; Thu, 1 Oct 2020 09:23:39 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 01 Oct 2020 09:23:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm2; bh= /K7O/wIYaM62Cuf8kmoP6mi0EIciUstv6l2gQLTv7yc=; b=WqFLY7yf0prnezri /R0XSIy5iDj9eAN3sks2VdAXyh6iPi9Mx5cw4qEBTnJJDuzl0C4qjuvoXbFRdEZl PGmsktwNdTsAcW4igOH2HiMLXcIpU0CiuVnWHxE4SAEYw7cqoC09LQ93Uizf5WpH YX+b4R0I4kykBpApNjIssbFmO8aq7gIX3tHhnv1uzo/0fMTzjEmCEPBJ6XjRjSL5 mCic/8L9nkvllJHQaIlkuVIAp7XhFMJHNOriwOAHxZtTPbn1hu5M5TSBhi3uZZg/ i19Ugtubx+chPqvQPEdzVWE2k8L43cDa7pl9LRgY4CN2lhj0YQfWI1bG1ok0/7sd 2JLkUQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=/K7O/wIYaM62Cuf8kmoP6mi0EIciUstv6l2gQLTv7 yc=; b=MQUDpctKXeFVOMt6GBXT7CQEDhg7rdoQUp7jrwIysBoVSB0mT9aZ7mx2c NFB7dhjuOozB01YkTXiewoshQVhPX2fSK7ekTLuGF4S86jl1rYdddltRWS5r9iL4 LyUBHIgO6mXBXz2lKSs3IP4C4JoYr/bqAJWJ7a0q9Q2qqNEAVWsW97hMLSjEPjoX PUGEBGD+TfyafhQ0V7QXoJt/1ERKTsJ9NgAvcUCCn9C84BCeuiBJ1co9+xuq0Bvd 7UvYYPoDZ+o8Kv+4Y+7lBYqDdaHID2KQplmGXiDzoyigM6BjHK/FisKlakuuzF9P 4ifswLF/NaQDgM/+MIHGiUvoVghTg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrfeeggdeihecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesthgsre dtredtjeenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdoihgv thhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeehteegtdffgfegffekvdejke evleetuedutddtfffhlefgtedvveehvdeguedtudenucfkphepudehkedrudejgedrgedr vdduheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmsghjodhivghtfhesgeeiieekrdhsvg X-ME-Proxy: Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id C1BF53064674; Thu, 1 Oct 2020 09:23:36 -0400 (EDT) Date: Thu, 01 Oct 2020 15:23:35 +0200 (CEST) Message-Id: <20201001.152335.649983049956449669.id@4668.se> To: kent+ietf@watsen.net Cc: bill.wu@huawei.com, mbj+ietf@4668.se, netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <01000174e42a0ab6-d29a9843-5a7a-4804-acba-276a859e4612-000000@email.amazonses.com> References: <01000174e42a0ab6-d29a9843-5a7a-4804-acba-276a859e4612-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org 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: Thu, 01 Oct 2020 13:23:42 -0000 S2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0PiB3cm90ZToNCj4gSGkgUWluLA0KPiAN Cj4gPiBTb21lIG9wc3RhdGUgbXVzdCBiZSBwZXJzaXN0ZWQsIGUuZy4sIGxvbmctbGl2ZWQgY291 bnRlcnMsIGxvZ3MsIGV0Yy4sDQo+ID4gYnV0IGl04oCZcyBhIGdvb2QgcG9pbnQgYWJvdXQgb3Ro ZXIgb3BzdGF0ZSBub3QgYmVpbmcgcGVyc2lzdGVkLg0KPiA+IFBlcmhhcHMg4oCcbm9kZS10YWdz 4oCdIGNhbiBiZSB1c2VkIGhlcmUsIHRvIGRpZmZlcmVudGlhdGUgd2hpY2ggaXMNCj4gPiB3aGlj aOKApmFuZCBzZXJ2ZXJzIGNhbiBpbmRpY2F0ZSBpZi9ob3cgdGhleSBzdXBwb3J0IHRoZSBlcGhl bWVyYWwNCj4gPiBvcHN0YXRlIGxlYWZzIGluIHF1ZXJpZXM/DQo+ID4gDQo+ID4gW1Fpbl06VGhh dCdzIGEgZ29vZCBjYXNlIGZvciBub2RlIHRhZywgaW4gZWFybGllciBkaXNjdXNzaW9uLCB3ZQ0K PiA+IGRpc2N1c3NlZCBvcGVyYXRpb24gdHlwZSwgd2hpY2ggZGlzdGluZ3Vpc2hzIGN1bXVsYXRp dmUgc3RhdGlzdGljcw0KPiA+IHZhbHVlIGZyb20gY3VycmVudCB2YWx1ZS4gVGhlIGNhc2UgZGlz Y3Vzc2VkIGhlcmUgaXMgdmVyeSBjbG9zZSB0bw0KPiA+IG9wZXJhdGlvbiB0eXBlIHByb3Bvc2Fs IGRpc2N1c3NlZCBlYXJsaWVyLg0KPiANCj4gWWVzLiAgVGhhbmsgeW91IGZvciBwb2ludGluZyB0 aGF0IG91dC4gIEkgbWVhbnQgdG8gbWFrZSB0aGUgc2FtZQ0KPiBvYnNlcnZhdGlvbiBiZWZvcmUu ICBJbmRlZWQsIHN1Y2ggbm9kZS10YWdzIGNvdWxkIGhhdmUgZHVhbC1wdXJwb3NlOg0KPiB0byBn dWlkZSBhIHN0cmVhbWluZy1zdHJhdGVneSBhbmQgYSBxdWVyeWluZy1zdHJhdGVneSBmb3IgY2Vy dGFpbg0KPiBub2Rlcy4NCj4gDQo+IA0KPiA+IE5vdGUgc3VyZSBob3cgb3RoZXJzIGZlZWwgYWJv dXQg4oCcZGlyZWN0aW9uOiAoYyksIGJ1dCBteSBwcmltYXJ5DQo+ID4gdXNlLWNhc2UgcmV2b2x2 ZXMgYXJvdW5kIHRpbWUtc2VyaWVzIGRhdGEgKGUuZy4sIGxvZ3MpLCB3aGVyZSB0aGUNCj4gPiBp bnRlcmVzdCBpcyBjb21tb25seSBvbiB0aGUgbW9zdC1yZWNlbnQgZW50cmllcywgc28NCj4gPiAi cmV2ZXJzZS0tPm9mZnNldOKAlD5saW1pdOKAnSB3b3JrcyBuaWNlbHkuDQo+ID4gDQo+ID4gUGVy aGFwcyBhbiBhbHRlcm5hdGl2ZSB3b3VsZCBiZSB0byBsaWZ0IGEgY29uY2VwdCBmcm9tIFB5dGhv biB3aXRoDQo+ID4gbmVnYXRpdmUgaW5kZXhlcyBzbywgZm9yIGluc3RhbmNlLCBvZmZzZXQ9LU4g YW5kIGxpbWl0PS1OIGdpdmVzIHRoZQ0KPiA+IGxhc3QgTiBlbnRyaWVzPw0KPiA+IFtRaW5dOiBZ ZXMsIHRoYXQncyB3aGF0IEkgdGhvdWdodCBhcyB3ZWxsLCB3aXRoIG5lZ2F0aXZlIGluZGV4ZXMs IChiKQ0KPiA+IGFuZCAoYykgc2VlbXMgdG8gbWUsIGNhbiBiZSBjb21iaW5lZC4NCj4gDQo+IENh biBvdGhlcnMgY29tbWVudCBvbiB0aGlzPw0KDQpJc24ndCB0aGlzIGp1c3QgYW5vdGhlciBzeW50 YXggZm9yIHRoZSBzYW1lIGZ1bmN0aW9uPw0KDQoNCi9tYXJ0aW4NCg0KDQo+IFByZXN1bWFibHks IHdlIGNvdWxkIGVsaW1pbmF0ZSDigJxkaXJlY3Rpb27igJ0gKGMpIHdpdGggdGhpcyBhcHByb2Fj aC4gIA0KPiANCj4gV2l0aG91dCDigJxkaXJlY3Rpb27igJ0sIEkgdGhpbmsgdGhhdCBVSXMgY2Fu IHN0aWxsIHN1cHBvcnQgdGhlIGFiaWxpdHkgdG8NCj4gZG8gY29sdW1uLXNvcnRzLCB3aGVyZWJ5 IHRoZSB1c2VyIGNsaWNrcyBvbiBhIGNvbHVtbuKAmXMgaGVhZGVyIHRvDQo+IHRvZ2dsZSBhc2Nl bmRpbmcgdnMuIGRlc2NlbmRpbmcgcHJlc2VudGF0aW9uLCBidXQgdGhleeKAmWxsIGhhdmUgdG8g ZG8NCj4gaXQgY2xpZW50LXNpZGUuDQo+IA0KPiBUaGF0IGlzLCBpZiB3YW50aW5nIHRvIHNlZSB0 aGUgMm5kIHBhZ2Ugb2YgcmVzdWx0cyBzb3J0ZWQgYnkgYSBjb2x1bW4sDQo+IHNvbWV0aGluZyBs aWtlOg0KPiANCj4gCXNvcnQoY29sdW1uLW5hbWUpIC0tPiBvZmZzZXQoLTIqcGFnZXNpemUpIC0t PiBsaW1pdChwYWdlc2l6ZSkNCj4gDQo+IEZvbGxvd2VkIGJ5IHRoZSBjbGllbnQgdGhlbiBmbGlw cGluZyB0aGUgcmVzdWx0cyB0byBwcmVzZW50IHRoZQ0KPiByZXN1bHRzIGluIHRoZSB1c2VyLXNl bGVjdGVkIG9yZGVyLCByaWdodD8NCj4gDQo+IFRoYXQgc2FpZCwgZ2l2ZW4gdGhhdCBEQi1iYWNr ZW5kcyB0aGF0IHN1cHBvcnQgc29ydHMgY29tbW9ubHkgYWxzbw0KPiBzdXBwb3J0IGRpcmVjdGlv biwgaXQncyB1bmNsZWFyIHdoYXQgdGhpcyBidXlzIHVzLg0KPiANCj4gDQo+ID4+PiBTdXJlLCBi dXQgSSB3b25kZXIgaWYsIGUuZy4sIGEgbmV0bWFzayBmaWx0ZXIsIGlzIHN1cHBvcnRhYmxlIGJ5 IA0KPiA+Pj4gY29tbW9uIERCLWJhY2tlbmRzLiAgSeKAmW0gaG9waW5nIHdlIGhhdmUgc29tZSBE Qi1leHBlcnRzIG9uIHRoZSBsaXN0IQ0KPiA+PiANCj4gPj4gU2VlIGFib3ZlLiAgSXQgY2FuIGJl IHF1aXRlIGVmZmljaWVudCBldmVuIGlmIHRoZSBiYWNrZW5kIGRvZXNuJ3QgDQo+ID4+IHN1cHBv cnQgaXQuDQo+ID4gDQo+ID4gSSBkb27igJl0IHNlZSB0aGF0IGFib3ZlLCBidXQgSSBkb27igJl0 IGRvdWJ0IHRoYXQgaXQgY2FuIGJlIHNvLCBpdOKAmXMganVzdA0KPiA+IGEgd2hvbGUgbG90IG9m IGltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHkuICBJdCBzZWVtcyB0aGF0IHdlDQo+ID4gc2hvdWxk L211c3Qgc3VwcG9ydCBzZXJ2ZXJzIGRvaW5nIGl0LCB3ZSBqdXN0IG5lZWQgdG8gZmluZCBhIHdh eQ0KPiA+IChub2RlLXRhZ3M/KSB0byBlbmFibGUgdGhlbSB0byBleHByZXNzIHRoYXQgYWJpbGl0 eS4NCj4gPiBbUWluXTogTXkgZmVlbGluZyBpcyB0aGlzIGVmZmljaWVuY3kgbW9yZSBkZXBlbmRz IG9uIHRoZSBhbW91bnQgb2YNCj4gPiBkYXRhIHdlIG5lZWQgdG8gcmVxdWVzdC4gSWYgYW1vdW50 IG9mIGRhdGEgd2UgcmVxdWVzdCBpcyBodWdlLCBtYXliZSwNCj4gPiBjbGllbnQtPiBzZXJ2ZXIt PiBiYWNrZW5kIG1heSBiZSB0aGUgYmV0dGVyIGNob2ljZS4NCj4gDQo+IElzIGl0IHRoZSBhbW91 bnQgb2YgZGF0YSByZXF1ZXN0ZWQgb3IgdGhlIG51bWJlciBvZiBlbnRyaWVzIGluIHRoZQ0KPiBs aXN0PyAgQXQgbGVhc3QsIGluIG15IHdvcmxkdmlldywgY2xpZW50cyBhcmUgYWx3YXlzIHJlcXVl c3RpbmcgYQ0KPiDigJxwYWdl4oCdIG9mIGRhdGEsIHNvIHRoYXQgcGFydCBpcyByYXRoZXIgY29u c2lzdGVudGx5IHNtYWxsLg0KPiANCj4gSWYgdGhlIGludGVudGlvbiBpcyB0byBnZXQgYSBjb21w bGV0ZSBkdW1wLCB0aGVuIG1heWJlIHRoZSBjb21tZW50DQo+IGZyb20geWVzdGVyZGF5IGFwcGxp ZXMsIHdoZXJlYnkgc3RyZWFtaW5nIHRvIGFuIGV4dGVybmFsIHJlcG9zaXRvcnkNCj4gdGhhdCBj YW4gYmUgcXVlcmllZCBvZmZsaW5lIG1ha2VzIG1vcmUgc2Vuc2U/ICAtIGVzcGVjaWFsbHkNCj4g Y29uc2lkZXJpbmcgdGhhdCB0aGUgbnVtYmVyIG9mIG9uLWJveCBsb2dzIGlzIGxpa2VseSB0byBi ZSBvbmx5IHRoZQ0KPiBtb3N0IHJlY2VudCAoZS5nLiwgZGF5cyksIHdoZXJlYXMgdGhlIGNvbXBs ZXRlLWR1bXAgdHlwZSBxdWVyaWVzDQo+IGxpa2VseSB3aXNoIHRvIGV4dGVuZCB3ZWxsLXBhc3Qg dGhhdC4NCj4gDQo+IEsuDQo+IA0KPiANCg== From nobody Thu Oct 1 06:32:09 2020 Return-Path: <01000174e45cdb27-6ee646b5-42e6-4547-9366-91b86bf8ac84-000000@amazonses.watsen.net> 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 7D0083A103D for ; Thu, 1 Oct 2020 06:32:07 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 pO_yUY1w1-C2 for ; Thu, 1 Oct 2020 06:32:06 -0700 (PDT) Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28E7B3A1053 for ; Thu, 1 Oct 2020 06:32:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601559125; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=J1f8yfPfh46eBp9SJI97AjGbP79BphHyI0UenX1CFZk=; b=bROcyD5zO8Y83Ea+4qw5YveeCoB0wotfiYD9C5DnJzJZTFw0ULLp7h0oy5iRpTLH LQwtCXMFp7OE/HO5khSuM6RzgUXumhjCBc4NuNg8M3lq2QHufjJKyqgTZiMceTO+NiH XK4DNtNCd/y0R5u+qwKBJLXXIT/rDd/3/Dsc2/HM= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Kent Watsen In-Reply-To: <20201001.152335.649983049956449669.id@4668.se> Date: Thu, 1 Oct 2020 13:32:04 +0000 Cc: Qin Wu , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000174e45cdb27-6ee646b5-42e6-4547-9366-91b86bf8ac84-000000@email.amazonses.com> References: <01000174e42a0ab6-d29a9843-5a7a-4804-acba-276a859e4612-000000@email.amazonses.com> <20201001.152335.649983049956449669.id@4668.se> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.10.01-54.240.48.110 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org 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: Thu, 01 Oct 2020 13:32:08 -0000 > On Oct 1, 2020, at 9:23 AM, Martin Bj=C3=B6rklund = wrote: >=20 > Kent Watsen wrote: >> Hi Qin, >>=20 >>> Some opstate must be persisted, e.g., long-lived counters, logs, = etc., >>> but it=E2=80=99s a good point about other opstate not being = persisted. >>> Perhaps =E2=80=9Cnode-tags=E2=80=9D can be used here, to = differentiate which is >>> which=E2=80=A6and servers can indicate if/how they support the = ephemeral >>> opstate leafs in queries? >>>=20 >>> [Qin]:That's a good case for node tag, in earlier discussion, we >>> discussed operation type, which distinguishs cumulative statistics >>> value from current value. The case discussed here is very close to >>> operation type proposal discussed earlier. >>=20 >> Yes. Thank you for pointing that out. I meant to make the same >> observation before. Indeed, such node-tags could have dual-purpose: >> to guide a streaming-strategy and a querying-strategy for certain >> nodes. >>=20 >>=20 >>> Note sure how others feel about =E2=80=9Cdirection: (c), but my = primary >>> use-case revolves around time-series data (e.g., logs), where the >>> interest is commonly on the most-recent entries, so >>> "reverse-->offset=E2=80=94>limit=E2=80=9D works nicely. >>>=20 >>> Perhaps an alternative would be to lift a concept from Python with >>> negative indexes so, for instance, offset=3D-N and limit=3D-N gives = the >>> last N entries? >>> [Qin]: Yes, that's what I thought as well, with negative indexes, = (b) >>> and (c) seems to me, can be combined. >>=20 >> Can others comment on this? >=20 > Isn't this just another syntax for the same function? No, it is not. K. >=20 > /martin >=20 >=20 >> Presumably, we could eliminate =E2=80=9Cdirection=E2=80=9D (c) with = this approach. =20 >>=20 >> Without =E2=80=9Cdirection=E2=80=9D, I think that UIs can still = support the ability to >> do column-sorts, whereby the user clicks on a column=E2=80=99s header = to >> toggle ascending vs. descending presentation, but they=E2=80=99ll = have to do >> it client-side. >>=20 >> That is, if wanting to see the 2nd page of results sorted by a = column, >> something like: >>=20 >> sort(column-name) --> offset(-2*pagesize) --> limit(pagesize) >>=20 >> Followed by the client then flipping the results to present the >> results in the user-selected order, right? >>=20 >> That said, given that DB-backends that support sorts commonly also >> support direction, it's unclear what this buys us. >>=20 >>=20 >>>>> Sure, but I wonder if, e.g., a netmask filter, is supportable by=20= >>>>> common DB-backends. I=E2=80=99m hoping we have some DB-experts on = the list! >>>>=20 >>>> See above. It can be quite efficient even if the backend doesn't=20= >>>> support it. >>>=20 >>> I don=E2=80=99t see that above, but I don=E2=80=99t doubt that it = can be so, it=E2=80=99s just >>> a whole lot of implementation complexity. It seems that we >>> should/must support servers doing it, we just need to find a way >>> (node-tags?) to enable them to express that ability. >>> [Qin]: My feeling is this efficiency more depends on the amount of >>> data we need to request. If amount of data we request is huge, = maybe, >>> client-> server-> backend may be the better choice. >>=20 >> Is it the amount of data requested or the number of entries in the >> list? At least, in my worldview, clients are always requesting a >> =E2=80=9Cpage=E2=80=9D of data, so that part is rather consistently = small. >>=20 >> If the intention is to get a complete dump, then maybe the comment >> from yesterday applies, whereby streaming to an external repository >> that can be queried offline makes more sense? - especially >> considering that the number of on-box logs is likely to be only the >> most recent (e.g., days), whereas the complete-dump type queries >> likely wish to extend well-past that. >>=20 >> K. >>=20 >>=20 From nobody Thu Oct 1 06:36:43 2020 Return-Path: <01000174e4610ae6-d1488376-ae7e-4d95-ba7e-005fc44b9592-000000@amazonses.watsen.net> 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 2C8F13A1030 for ; Thu, 1 Oct 2020 06:36:42 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 JJcDSfa7mOAa for ; Thu, 1 Oct 2020 06:36:40 -0700 (PDT) Received: from a48-95.smtp-out.amazonses.com (a48-95.smtp-out.amazonses.com [54.240.48.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F25D3A1056 for ; Thu, 1 Oct 2020 06:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601559399; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=fnQNj64pj0GqOdOM4hUlAJP29I0fiiktCwWytHqIiGM=; b=Of0iQjYYViAXxzKepEPMT9kqKXjrgm0fx/IVMkL9Yc4wCqIrdmwWoRUrlFneipzv 5yucXVAwNMHP3gNUR1eiglHaLQgyJ4NrfhWY4mGujanoycV6ZU51gKrP2Uma2SzTAn5 67nLbuLb0clvjh0opeUb+Vkn1mdZfvrlwwgsGhh8= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Kent Watsen In-Reply-To: <20201001.083349.1861081830665539794.id@4668.se> Date: Thu, 1 Oct 2020 13:36:39 +0000 Cc: Olof Hagsand , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000174e4610ae6-d1488376-ae7e-4d95-ba7e-005fc44b9592-000000@email.amazonses.com> References: <01000174e0279006-63781c55-866c-4ea0-add6-a6fa8a11453c-000000@email.amazonses.com> <54cd8891-6c04-3ded-22ca-43a68ac8397f@hagsand.se> <01000174e09a04a9-f53134f8-009f-4d0a-84a1-3165a494054b-000000@email.amazonses.com> <20201001.083349.1861081830665539794.id@4668.se> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.10.01-54.240.48.95 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org 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: Thu, 01 Oct 2020 13:36:42 -0000 Hi Martin, >> A couple messages I sent yesterday alluded to defining an extension >> statement that could be added to nodes in the YANG modules. >>=20 >> Now I=E2=80=99m thinking that one-size doesn=E2=80=99t necessarily = fit all, and >> something like a server-specific =E2=80=9Cnode-tag=E2=80=9D would be = more flexible. >> (https://tools.ietf.org/html/draft-tao-netmod-yang-node-tags >> ) >>=20 >> Maybe the answer is somewhere in-between, i.e., an extension that = acts >> like a =E2=80=9Chint=E2=80=9D and a node-tag indicating if the server = delivered it. >> Bad news w/ an extension is that legacy modules would need to be >> revved or augmented. >>=20 >> One thing, though, filtering on non-indexed nodes is guaranteed to >> have slow performance, thus it seems that we need to enable indexing >> for more than just a list=E2=80=99s keys. >=20 > I disagree with both these statements. This is an implementation > issue. Which two statements? And how do you come to that conclusion, unless = you=E2=80=99re suggested that all queries from particular server are = equally slow? ;) >> My conjecture is that, once we have the indexes for filtering (e), >> they can be used for sorting (d). At least, that=E2=80=99s the way = it works >> with some DB-backends I=E2=80=99m familiar with... >=20 > This is one implementation strategy. We should not design the > standard around one implementation. Please elucidate how this isn=E2=80=99t the case. While a true statement, it=E2=80=99s an unfair implication, as pretty = much *everything* I=E2=80=99ve written on this thread has been about = trying to enable servers with various DB-backends to express which parts = of the solution they can support. Apparently some backends don=E2=80=99t= support =E2=80=9Csorts=E2=80=9D while others do; some backends can = support full Xpath while other can=E2=80=99t, etc. All this means to = me is that we need to define the necessary features and/or node-tags or = whatever to enable each to advertise what it can do best, or at all. If the WG wants the lowest-common denominator, we will likely end up = with just =E2=80=98a', =E2=80=98b', and a heavily redacted Xpath for = =E2=80=98e=E2=80=99. I=E2=80=99m hoping that we can do better than = that, but I=E2=80=99m also okay with leaving it to each solution can = then create proprietary extensions/node-tags, if that is the WG = consensus. > I agree that this can be useful. But as has been pointed out earlier > in this thread, sorting implies a stateful solution which will consume > more resources and probably comes with some additional complexity. True, except I think the augment was in *favor* of doing that, at least = in some cases. Also note that the =E2=80=9Cmore resources=E2=80=9D augment needs to be = amortized over the number of queries. There must be a break-even point = whereby preparing a (resource-intensive) snapshot actually uses less = resources over time, after it's been queried a certain number of times, = than a server doing a fresh (lower-resource) query for each request. > At Cisco/tail-f we implemented such a solution; a more generic "query" > mechanism, for both NETCONF and RESTCONF. Perhaps Per A can share > some details. That would be helpful. The analysis can only take into account that = which is known. I know the Tail-f products used a custom database, but = few know anything about it. =20 Creating a custom database is not easy. I know, as I personally wrote a = very-fast logging system, complete with indices, for a logging database = taking in logs at the rate of 50,000 logs per second, with the total = number of logs retained measured in the billions. =20 I personally do not wish for a *basic* server to have to go through that = pain, hence the interest in supporting common DB-backends (NoSQL, SQL, = etc.), while also enabling systems with special abilities to present = that which can. K. From nobody Thu Oct 1 07:55:58 2020 Return-Path: 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 8F4223A10B9 for ; Thu, 1 Oct 2020 07:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.997, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=HRUb5b/V; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FOXqld+R 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 1Zf6BTo7_BWP for ; Thu, 1 Oct 2020 07:55:54 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB9923A10BC for ; Thu, 1 Oct 2020 07:55:54 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 13AC729E; Thu, 1 Oct 2020 10:55:53 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 01 Oct 2020 10:55:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm2; bh= NSgCjzXMLC1RCgv434QIzqz06KnMY9+xX/4LED9Vi34=; b=HRUb5b/VLq+0ROBo GbOT03gqnVq3gNQUp/MUUX89kcnb1YFh4totY7/k8AjjaWb1Xrp1gAoaE/LIs89j cWhcqKUTWEc0OVJUDQdDyqMIAETFjsdEws/C78h8SxM5qutOKleoWOrrI/pvccn5 8UbdK9fl42aEDkWI0V5o+eUS4/njRUTH7UV75AfnGehesmzB65+tCcL2Eve6KNqf BIUoFYUGhVF2WZiRGdH1pZ+KoxH35MaLLe/p8FywTLsOAupSTb5ZAilJ1hU07ax7 sKlFnakD58IP01TJO5fpUQSs/ad35HS/OUgcGBGv2ogcPXPDHX0uVIzvn/WEFkOg 58dazw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=NSgCjzXMLC1RCgv434QIzqz06KnMY9+xX/4LED9Vi 34=; b=FOXqld+Rj6940nON9KxkcSAcJOG8ub4NLLeU49A9+xmHjXV4Q5shF77bp 7qCI4N1vtlRfBuuPFQmGGJ2K1/0eZZuFTimxRU7ye2AoPCJhLR/DrwUFZ8thV3d0 HASk04SAQa/3f4OSOIY+/Qu3Um7Tjm5ekZfH+otDSSVqT9ntSA9m/Hq/MHiCnqID 9sFlBFbpqLv69CHGAdCb6CwJDzw1T4zj0M363rSg/G8EGTbWr9WRNcHyr6M3Rj0k e9MMD8PW+eSJofkTbqb6yTQSUhPjygssc2bYDDMawk2OEX7Eh8OS3PoYvmSeP8Rq Md/kKFiz9Wii9CdmwAQuV7LGolChg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrfeeggdekfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesthgsre dtredtjeenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdoihgv thhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeefheekgfdukeefheeihefhke egvdffheetvefgfeefgefhvdefueeluddvvdfgheenucffohhmrghinhepihgvthhfrdho rhhgnecukfhppeduheekrddujeegrdegrddvudehnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepmhgsjhdoihgvthhfseegieeikedrshgv X-ME-Proxy: Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id 84A033064682; Thu, 1 Oct 2020 10:55:50 -0400 (EDT) Date: Thu, 01 Oct 2020 16:55:48 +0200 (CEST) Message-Id: <20201001.165548.1275939966226069939.id@4668.se> To: kent+ietf@watsen.net Cc: olof@hagsand.se, netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <01000174e4610ae6-d1488376-ae7e-4d95-ba7e-005fc44b9592-000000@email.amazonses.com> References: <01000174e09a04a9-f53134f8-009f-4d0a-84a1-3165a494054b-000000@email.amazonses.com> <20201001.083349.1861081830665539794.id@4668.se> <01000174e4610ae6-d1488376-ae7e-4d95-ba7e-005fc44b9592-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org 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: Thu, 01 Oct 2020 14:55:57 -0000 SGksDQoNCktlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD4gd3JvdGU6DQo+IEhpIE1h cnRpbiwNCj4gDQo+ID4+IEEgY291cGxlIG1lc3NhZ2VzIEkgc2VudCB5ZXN0ZXJkYXkgYWxsdWRl ZCB0byBkZWZpbmluZyBhbiBleHRlbnNpb24NCj4gPj4gc3RhdGVtZW50IHRoYXQgY291bGQgYmUg YWRkZWQgdG8gbm9kZXMgaW4gdGhlIFlBTkcgbW9kdWxlcy4NCj4gPj4gDQo+ID4+IE5vdyBJ4oCZ bSB0aGlua2luZyB0aGF0IG9uZS1zaXplIGRvZXNu4oCZdCBuZWNlc3NhcmlseSBmaXQgYWxsLCBh bmQNCj4gPj4gc29tZXRoaW5nIGxpa2UgYSBzZXJ2ZXItc3BlY2lmaWMg4oCcbm9kZS10YWfigJ0g d291bGQgYmUgbW9yZSBmbGV4aWJsZS4NCj4gPj4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC10YW8tbmV0bW9kLXlhbmctbm9kZS10YWdzDQo+ID4+IDxodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtdGFvLW5ldG1vZC15YW5nLW5vZGUtdGFncz4pDQo+ID4+IA0KPiA+ PiBNYXliZSB0aGUgYW5zd2VyIGlzIHNvbWV3aGVyZSBpbi1iZXR3ZWVuLCBpLmUuLCBhbiBleHRl bnNpb24gdGhhdCBhY3RzDQo+ID4+IGxpa2UgYSDigJxoaW504oCdIGFuZCBhIG5vZGUtdGFnIGlu ZGljYXRpbmcgaWYgdGhlIHNlcnZlciBkZWxpdmVyZWQgaXQuDQo+ID4+IEJhZCBuZXdzIHcvIGFu IGV4dGVuc2lvbiBpcyB0aGF0IGxlZ2FjeSBtb2R1bGVzIHdvdWxkIG5lZWQgdG8gYmUNCj4gPj4g cmV2dmVkIG9yIGF1Z21lbnRlZC4NCj4gPj4gDQo+ID4+IE9uZSB0aGluZywgdGhvdWdoLCBmaWx0 ZXJpbmcgb24gbm9uLWluZGV4ZWQgbm9kZXMgaXMgZ3VhcmFudGVlZCB0bw0KPiA+PiBoYXZlIHNs b3cgcGVyZm9ybWFuY2UsIHRodXMgaXQgc2VlbXMgdGhhdCB3ZSBuZWVkIHRvIGVuYWJsZSBpbmRl eGluZw0KPiA+PiBmb3IgbW9yZSB0aGFuIGp1c3QgYSBsaXN04oCZcyBrZXlzLg0KPiA+IA0KPiA+ IEkgZGlzYWdyZWUgd2l0aCBib3RoIHRoZXNlIHN0YXRlbWVudHMuICBUaGlzIGlzIGFuIGltcGxl bWVudGF0aW9uDQo+ID4gaXNzdWUuDQo+IA0KPiBXaGljaCB0d28gc3RhdGVtZW50cz8NCg0KMS4g ZmlsdGVyaW5nIG9uIG5vbi1pbmRleGVkIG5vZGVzIGlzIGd1YXJhbnRlZWQgdG8gaGF2ZSBzbG93 DQogICBwZXJmb3JtYW5jZQ0KDQoyLiBpdCBzZWVtcyB0aGF0IHdlIG5lZWQgdG8gZW5hYmxlIGlu ZGV4aW5nICBmb3IgbW9yZSB0aGFuIGp1c3QgYQ0KICAgbGlzdOKAmXMga2V5cw0KDQo+IEFuZCBo b3cgZG8geW91IGNvbWUgdG8gdGhhdCBjb25jbHVzaW9uLCB1bmxlc3MNCj4geW914oCZcmUgc3Vn Z2VzdGVkIHRoYXQgYWxsIHF1ZXJpZXMgZnJvbSBwYXJ0aWN1bGFyIHNlcnZlciBhcmUgZXF1YWxs eQ0KPiBzbG93PyAgOykNCg0KSSdtIHN1Z2dlc3RpbmcgdGhhdCB0aGlzIGlzIGhpZ2hseSBpbXBs ZW1lbnRhdGlvbiBkZXBlbmRlbnQuDQoNCj4gPj4gTXkgY29uamVjdHVyZSBpcyB0aGF0LCBvbmNl IHdlIGhhdmUgdGhlIGluZGV4ZXMgZm9yIGZpbHRlcmluZyAoZSksDQo+ID4+IHRoZXkgY2FuIGJl IHVzZWQgZm9yIHNvcnRpbmcgKGQpLiAgQXQgbGVhc3QsIHRoYXTigJlzIHRoZSB3YXkgaXQgd29y a3MNCj4gPj4gd2l0aCBzb21lIERCLWJhY2tlbmRzIEnigJltIGZhbWlsaWFyIHdpdGguLi4NCj4g PiANCj4gPiBUaGlzIGlzIG9uZSBpbXBsZW1lbnRhdGlvbiBzdHJhdGVneS4gIFdlIHNob3VsZCBu b3QgZGVzaWduIHRoZQ0KPiA+IHN0YW5kYXJkIGFyb3VuZCBvbmUgaW1wbGVtZW50YXRpb24uDQo+ IA0KPiBQbGVhc2UgZWx1Y2lkYXRlIGhvdyB0aGlzIGlzbuKAmXQgdGhlIGNhc2UuDQo+IA0KPiBX aGlsZSBhIHRydWUgc3RhdGVtZW50LCBpdOKAmXMgYW4gdW5mYWlyIGltcGxpY2F0aW9uLCBhcyBw cmV0dHkgbXVjaA0KPiAqZXZlcnl0aGluZyogSeKAmXZlIHdyaXR0ZW4gb24gdGhpcyB0aHJlYWQg aGFzIGJlZW4gYWJvdXQgdHJ5aW5nIHRvDQo+IGVuYWJsZSBzZXJ2ZXJzIHdpdGggdmFyaW91cyBE Qi1iYWNrZW5kcyB0byBleHByZXNzIHdoaWNoIHBhcnRzIG9mIHRoZQ0KPiBzb2x1dGlvbiB0aGV5 IGNhbiBzdXBwb3J0LiAgQXBwYXJlbnRseSBzb21lIGJhY2tlbmRzIGRvbuKAmXQgc3VwcG9ydA0K PiDigJxzb3J0c+KAnSB3aGlsZSBvdGhlcnMgZG87IHNvbWUgYmFja2VuZHMgY2FuIHN1cHBvcnQg ZnVsbCBYcGF0aCB3aGlsZQ0KPiBvdGhlciBjYW7igJl0LCBldGMuICBBbGwgdGhpcyBtZWFucyB0 byBtZSBpcyB0aGF0IHdlIG5lZWQgdG8gZGVmaW5lIHRoZQ0KPiBuZWNlc3NhcnkgZmVhdHVyZXMg YW5kL29yIG5vZGUtdGFncyBvciB3aGF0ZXZlciB0byBlbmFibGUgZWFjaCB0bw0KPiBhZHZlcnRp c2Ugd2hhdCBpdCBjYW4gZG8gYmVzdCwgb3IgYXQgYWxsLg0KPiANCj4gSWYgdGhlIFdHIHdhbnRz IHRoZSBsb3dlc3QtY29tbW9uIGRlbm9taW5hdG9yLCB3ZSB3aWxsIGxpa2VseSBlbmQgdXANCj4g d2l0aCBqdXN0IOKAmGEnLCDigJhiJywgYW5kIGEgaGVhdmlseSByZWRhY3RlZCBYcGF0aCBmb3Ig 4oCYZeKAmS4gIEnigJltIGhvcGluZw0KPiB0aGF0IHdlIGNhbiBkbyBiZXR0ZXIgdGhhbiB0aGF0 LCBidXQgSeKAmW0gYWxzbyBva2F5IHdpdGggbGVhdmluZyBpdCB0bw0KPiBlYWNoIHNvbHV0aW9u IGNhbiB0aGVuIGNyZWF0ZSBwcm9wcmlldGFyeSBleHRlbnNpb25zL25vZGUtdGFncywgaWYNCj4g dGhhdCBpcyB0aGUgV0cgY29uc2Vuc3VzLg0KDQpJIHdvdWxkIHByZWZlciBhbiB1bmNvbnN0cmFp bmVkIGZpbHRlciwgd2l0aCB0aGUgWFBhdGggMS4wIHRoYXQgaXMNCmFscmVhZHkgdXNlZCBpbiBZ QU5HLiAgSXQgd291bGQgYmUgb2sgaWYgc3VwcG9ydCBmb3Igc3VjaCBhIGZpbHRlciB3YXMNCm9w dGlvbmFsIChhIGNhcGFiaWxpdHkpLiAgTXkgcG9pbnQgaXMgdGhhdCBldmVuIGlmIHRoZSBiYWNr ZW5kIGRvZXNuJ3QNCnN1cHBvcnQgZmlsdGVyaW5nIG9uIGEgcGFydGljdWxhciBub2RlLCBmaWx0 ZXJpbmcgaW4gdGhlIHNlcnZlciB3aWxsDQpiZSBtdWNoIG1vcmUgZWZmaWNpZW50IHRoYW4gZmls dGVyaW5nIGluIHRoZSBjbGllbnQuICBIZW5jZSBmaWx0ZXJpbmcNCnNob3VsZG4ndCBiZSBjb25z dHJhaW5lZCB0byBjZXJ0YWluIG5vZGVzLiAgSXQgYWxzbyBtYWtlcyB0aGUgc29sdXRpb24NCm11 Y2ggZWFzaWVyIHRvIHVzZSBmb3IgY2xpZW50cy4NCg0KDQo+ID4gSSBhZ3JlZSB0aGF0IHRoaXMg Y2FuIGJlIHVzZWZ1bC4gIEJ1dCBhcyBoYXMgYmVlbiBwb2ludGVkIG91dCBlYXJsaWVyDQo+ID4g aW4gdGhpcyB0aHJlYWQsIHNvcnRpbmcgaW1wbGllcyBhIHN0YXRlZnVsIHNvbHV0aW9uIHdoaWNo IHdpbGwgY29uc3VtZQ0KPiA+IG1vcmUgcmVzb3VyY2VzIGFuZCBwcm9iYWJseSBjb21lcyB3aXRo IHNvbWUgYWRkaXRpb25hbCBjb21wbGV4aXR5Lg0KPiANCj4gVHJ1ZSwgZXhjZXB0IEkgdGhpbmsg dGhlIGF1Z21lbnQgd2FzIGluICpmYXZvciogb2YgZG9pbmcgdGhhdCwgYXQNCj4gbGVhc3QgaW4g c29tZSBjYXNlcy4NCj4gDQo+IEFsc28gbm90ZSB0aGF0IHRoZSDigJxtb3JlIHJlc291cmNlc+KA nSBhdWdtZW50IG5lZWRzIHRvIGJlIGFtb3J0aXplZCBvdmVyDQo+IHRoZSBudW1iZXIgb2YgcXVl cmllcy4gIFRoZXJlIG11c3QgYmUgYSBicmVhay1ldmVuIHBvaW50IHdoZXJlYnkNCj4gcHJlcGFy aW5nIGEgKHJlc291cmNlLWludGVuc2l2ZSkgc25hcHNob3QgYWN0dWFsbHkgdXNlcyBsZXNzIHJl c291cmNlcw0KPiBvdmVyIHRpbWUsIGFmdGVyIGl0J3MgYmVlbiBxdWVyaWVkIGEgY2VydGFpbiBu dW1iZXIgb2YgdGltZXMsIHRoYW4gYQ0KPiBzZXJ2ZXIgZG9pbmcgYSBmcmVzaCAobG93ZXItcmVz b3VyY2UpIHF1ZXJ5IGZvciBlYWNoIHJlcXVlc3QuDQoNClRvIGJlIGNsZWFyLCBJIHRoaW5rIHN1 Y2ggYSBzb2x1dGlvbiB3b3VsZCBiZSB1c2VmdWwuDQoNCj4gPiBBdCBDaXNjby90YWlsLWYgd2Ug aW1wbGVtZW50ZWQgc3VjaCBhIHNvbHV0aW9uOyBhIG1vcmUgZ2VuZXJpYyAicXVlcnkiDQo+ID4g bWVjaGFuaXNtLCBmb3IgYm90aCBORVRDT05GIGFuZCBSRVNUQ09ORi4gIFBlcmhhcHMgUGVyIEEg Y2FuIHNoYXJlDQo+ID4gc29tZSBkZXRhaWxzLg0KPiANCj4gVGhhdCB3b3VsZCBiZSBoZWxwZnVs LiAgVGhlIGFuYWx5c2lzIGNhbiBvbmx5IHRha2UgaW50byBhY2NvdW50IHRoYXQNCj4gd2hpY2gg aXMga25vd24uICBJIGtub3cgdGhlIFRhaWwtZiBwcm9kdWN0cyB1c2VkIGEgY3VzdG9tIGRhdGFi YXNlLA0KPiBidXQgZmV3IGtub3cgYW55dGhpbmcgYWJvdXQgaXQuDQo+IA0KPiBDcmVhdGluZyBh IGN1c3RvbSBkYXRhYmFzZSBpcyBub3QgZWFzeS4NCg0KUmlnaHQsIGJ1dCBub3RlIHRoYXQgdGhp cyBmaWx0ZXJpbmcgY2FuIGFuZCBzaG91bGQgYmUgYXBwbGllZCB0byBhbGwNCm5vZGVzLCBhbHNv IG9wZXJhdGlvbmFsIHN0YXRlIG5vZGVzIHRoYXQgaXNuJ3Qgc3RvcmVkIGluIGFueSBkYXRhYmFz ZQ0KYXQgYWxsLCBpbW8uDQoNCg0KL21hcnRpbg0KDQoNCj4gSSBrbm93LCBhcyBJIHBlcnNvbmFs bHkgd3JvdGUNCj4gYSB2ZXJ5LWZhc3QgbG9nZ2luZyBzeXN0ZW0sIGNvbXBsZXRlIHdpdGggaW5k aWNlcywgZm9yIGEgbG9nZ2luZw0KPiBkYXRhYmFzZSB0YWtpbmcgaW4gbG9ncyBhdCB0aGUgcmF0 ZSBvZiA1MCwwMDAgbG9ncyBwZXIgc2Vjb25kLCB3aXRoDQo+IHRoZSB0b3RhbCBudW1iZXIgb2Yg bG9ncyByZXRhaW5lZCBtZWFzdXJlZCBpbiB0aGUgYmlsbGlvbnMuDQo+IA0KPiBJIHBlcnNvbmFs bHkgZG8gbm90IHdpc2ggZm9yIGEgKmJhc2ljKiBzZXJ2ZXIgdG8gaGF2ZSB0byBnbyB0aHJvdWdo DQo+IHRoYXQgcGFpbiwgaGVuY2UgdGhlIGludGVyZXN0IGluIHN1cHBvcnRpbmcgY29tbW9uIERC LWJhY2tlbmRzIChOb1NRTCwNCj4gU1FMLCBldGMuKSwgd2hpbGUgYWxzbyBlbmFibGluZyBzeXN0 ZW1zIHdpdGggc3BlY2lhbCBhYmlsaXRpZXMgdG8NCj4gcHJlc2VudCB0aGF0IHdoaWNoIGNhbi4N Cj4gDQo+IEsuDQo+IA0KPiANCj4gDQo+IA0K From nobody Thu Oct 1 07:57:21 2020 Return-Path: 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 03DED3A0EA5 for ; Thu, 1 Oct 2020 07:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.997, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=N11/8cTi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MthX6wFy 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 1zIu5etP17Ig for ; Thu, 1 Oct 2020 07:57:18 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B254E3A0B3A for ; Thu, 1 Oct 2020 07:57:18 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 9A086917; Thu, 1 Oct 2020 10:57:17 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 01 Oct 2020 10:57:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm2; bh= OpMOBlBP5iC7NiOvFaKsazYF905xkGO4rfKAoFP5IB0=; b=N11/8cTiW8via4L5 9D0EnNHBKe2VR/Rp8tNAHOBAgfaYgxZpyswdN600kMX5sHXgEnBEDGKEdO4SNl+F QBHfJVVnuBHiCo2WP2MVC4sQ5Ln4I6oj5LDg52+1Qwl8Y+8lqkkJ5Pl4liK0Kn9h Lw7YuPCKD7BQtZimiftUoqyU/Oe2ln6q4EO7z6b0EQaweBjjSq9OCLa+wE1Id8QL ohj05SXw7xyi4mn3shR2fzcAU1D0Tn8JDfvNecFg9+c1tsA+JG0d/YFap64zBs/5 WuDj1Ca4loHKzvSYPimR0q5nxrPWmSsjgErFRWubMTLXiVKk2nlZ/tnZPOfal8Qo 0dWQaQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=OpMOBlBP5iC7NiOvFaKsazYF905xkGO4rfKAoFP5I B0=; b=MthX6wFygPdPbgm3Ww/xOx6KZKhLxyWKB1MTxVQvxfI/kLigGIpSXMv5d IdLMyoQxeIlYrYH/9ticLO1DRMOeAPwq7eeGUMN1nIxdK89ljijfkMaa2pPYdP+m +PFidH3C3AXsKoGn5Icfk4TmHMTEwgP6WJOVVA6kOF2lsgEgBgb+iciyBrS9XQYX OGhGU9vK48kOvWPHLrsMUFjc8LMByWeEY+j0dfuSsKJHZDSsjJ/tznhW7oVJ/jI1 2NnTqdcz2un8Lsu518lZheBGx1tK1X2aM80NaIucQfzI2MiFJvMPMY+R4y8HVzYG lcWRR1cTcmmiJZy9tBCgRUlSWcVAA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrfeeggdekgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesthgsre dtredtjeenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdoihgv thhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeehteegtdffgfegffekvdejke evleetuedutddtfffhlefgtedvveehvdeguedtudenucfkphepudehkedrudejgedrgedr vdduheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmsghjodhivghtfhesgeeiieekrdhsvg X-ME-Proxy: Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id 208DC306467E; Thu, 1 Oct 2020 10:57:16 -0400 (EDT) Date: Thu, 01 Oct 2020 16:57:15 +0200 (CEST) Message-Id: <20201001.165715.770697558669717572.id@4668.se> To: kent+ietf@watsen.net Cc: bill.wu@huawei.com, netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <01000174e45cdb27-6ee646b5-42e6-4547-9366-91b86bf8ac84-000000@email.amazonses.com> References: <01000174e42a0ab6-d29a9843-5a7a-4804-acba-276a859e4612-000000@email.amazonses.com> <20201001.152335.649983049956449669.id@4668.se> <01000174e45cdb27-6ee646b5-42e6-4547-9366-91b86bf8ac84-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org 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: Thu, 01 Oct 2020 14:57:20 -0000 S2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0PiB3cm90ZToNCj4gDQo+IA0KPiA+IE9u IE9jdCAxLCAyMDIwLCBhdCA5OjIzIEFNLCBNYXJ0aW4gQmrDtnJrbHVuZCA8bWJqK2lldGZANDY2 OC5zZT4gd3JvdGU6DQo+ID4gDQo+ID4gS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0 PiB3cm90ZToNCj4gPj4gSGkgUWluLA0KPiA+PiANCj4gPj4+IFNvbWUgb3BzdGF0ZSBtdXN0IGJl IHBlcnNpc3RlZCwgZS5nLiwgbG9uZy1saXZlZCBjb3VudGVycywgbG9ncywgZXRjLiwNCj4gPj4+ IGJ1dCBpdOKAmXMgYSBnb29kIHBvaW50IGFib3V0IG90aGVyIG9wc3RhdGUgbm90IGJlaW5nIHBl cnNpc3RlZC4NCj4gPj4+IFBlcmhhcHMg4oCcbm9kZS10YWdz4oCdIGNhbiBiZSB1c2VkIGhlcmUs IHRvIGRpZmZlcmVudGlhdGUgd2hpY2ggaXMNCj4gPj4+IHdoaWNo4oCmYW5kIHNlcnZlcnMgY2Fu IGluZGljYXRlIGlmL2hvdyB0aGV5IHN1cHBvcnQgdGhlIGVwaGVtZXJhbA0KPiA+Pj4gb3BzdGF0 ZSBsZWFmcyBpbiBxdWVyaWVzPw0KPiA+Pj4gDQo+ID4+PiBbUWluXTpUaGF0J3MgYSBnb29kIGNh c2UgZm9yIG5vZGUgdGFnLCBpbiBlYXJsaWVyIGRpc2N1c3Npb24sIHdlDQo+ID4+PiBkaXNjdXNz ZWQgb3BlcmF0aW9uIHR5cGUsIHdoaWNoIGRpc3Rpbmd1aXNocyBjdW11bGF0aXZlIHN0YXRpc3Rp Y3MNCj4gPj4+IHZhbHVlIGZyb20gY3VycmVudCB2YWx1ZS4gVGhlIGNhc2UgZGlzY3Vzc2VkIGhl cmUgaXMgdmVyeSBjbG9zZSB0bw0KPiA+Pj4gb3BlcmF0aW9uIHR5cGUgcHJvcG9zYWwgZGlzY3Vz c2VkIGVhcmxpZXIuDQo+ID4+IA0KPiA+PiBZZXMuICBUaGFuayB5b3UgZm9yIHBvaW50aW5nIHRo YXQgb3V0LiAgSSBtZWFudCB0byBtYWtlIHRoZSBzYW1lDQo+ID4+IG9ic2VydmF0aW9uIGJlZm9y ZS4gIEluZGVlZCwgc3VjaCBub2RlLXRhZ3MgY291bGQgaGF2ZSBkdWFsLXB1cnBvc2U6DQo+ID4+ IHRvIGd1aWRlIGEgc3RyZWFtaW5nLXN0cmF0ZWd5IGFuZCBhIHF1ZXJ5aW5nLXN0cmF0ZWd5IGZv ciBjZXJ0YWluDQo+ID4+IG5vZGVzLg0KPiA+PiANCj4gPj4gDQo+ID4+PiBOb3RlIHN1cmUgaG93 IG90aGVycyBmZWVsIGFib3V0IOKAnGRpcmVjdGlvbjogKGMpLCBidXQgbXkgcHJpbWFyeQ0KPiA+ Pj4gdXNlLWNhc2UgcmV2b2x2ZXMgYXJvdW5kIHRpbWUtc2VyaWVzIGRhdGEgKGUuZy4sIGxvZ3Mp LCB3aGVyZSB0aGUNCj4gPj4+IGludGVyZXN0IGlzIGNvbW1vbmx5IG9uIHRoZSBtb3N0LXJlY2Vu dCBlbnRyaWVzLCBzbw0KPiA+Pj4gInJldmVyc2UtLT5vZmZzZXTigJQ+bGltaXTigJ0gd29ya3Mg bmljZWx5Lg0KPiA+Pj4gDQo+ID4+PiBQZXJoYXBzIGFuIGFsdGVybmF0aXZlIHdvdWxkIGJlIHRv IGxpZnQgYSBjb25jZXB0IGZyb20gUHl0aG9uIHdpdGgNCj4gPj4+IG5lZ2F0aXZlIGluZGV4ZXMg c28sIGZvciBpbnN0YW5jZSwgb2Zmc2V0PS1OIGFuZCBsaW1pdD0tTiBnaXZlcyB0aGUNCj4gPj4+ IGxhc3QgTiBlbnRyaWVzPw0KPiA+Pj4gW1Fpbl06IFllcywgdGhhdCdzIHdoYXQgSSB0aG91Z2h0 IGFzIHdlbGwsIHdpdGggbmVnYXRpdmUgaW5kZXhlcywgKGIpDQo+ID4+PiBhbmQgKGMpIHNlZW1z IHRvIG1lLCBjYW4gYmUgY29tYmluZWQuDQo+ID4+IA0KPiA+PiBDYW4gb3RoZXJzIGNvbW1lbnQg b24gdGhpcz8NCj4gPiANCj4gPiBJc24ndCB0aGlzIGp1c3QgYW5vdGhlciBzeW50YXggZm9yIHRo ZSBzYW1lIGZ1bmN0aW9uPw0KPiANCj4gTm8sIGl0IGlzIG5vdC4NCg0KSG93IHNvPyAgSXNuJ3Qg dGhlIGlkZWEgdGhhdCB5b3UgY2FuIGZpcnN0IGFzayBmb3Igb2Zmc2V0PS0xMCwgdGhlbg0KLTIw LCBldGMsIGVzc2VudGlhbGx5IHdhbGtpbmcgdGhlIGxpc3QgYmFja3dhcmRzPyAgKEkgZG9uJ3Qg dW5kZXJzdGFuZA0Kd2hhdCBhIG5lZ2F0aXZlIGxpbWl0IG1lYW5zIHRob3VnaCkuDQoNCg0KL21h cnRpbg0KDQoNCj4gDQo+IEsuDQo+IA0KPiANCj4gPiANCj4gPiAvbWFydGluDQo+ID4gDQo+ID4g DQo+ID4+IFByZXN1bWFibHksIHdlIGNvdWxkIGVsaW1pbmF0ZSDigJxkaXJlY3Rpb27igJ0gKGMp IHdpdGggdGhpcyBhcHByb2FjaC4gIA0KPiA+PiANCj4gPj4gV2l0aG91dCDigJxkaXJlY3Rpb27i gJ0sIEkgdGhpbmsgdGhhdCBVSXMgY2FuIHN0aWxsIHN1cHBvcnQgdGhlIGFiaWxpdHkgdG8NCj4g Pj4gZG8gY29sdW1uLXNvcnRzLCB3aGVyZWJ5IHRoZSB1c2VyIGNsaWNrcyBvbiBhIGNvbHVtbuKA mXMgaGVhZGVyIHRvDQo+ID4+IHRvZ2dsZSBhc2NlbmRpbmcgdnMuIGRlc2NlbmRpbmcgcHJlc2Vu dGF0aW9uLCBidXQgdGhleeKAmWxsIGhhdmUgdG8gZG8NCj4gPj4gaXQgY2xpZW50LXNpZGUuDQo+ ID4+IA0KPiA+PiBUaGF0IGlzLCBpZiB3YW50aW5nIHRvIHNlZSB0aGUgMm5kIHBhZ2Ugb2YgcmVz dWx0cyBzb3J0ZWQgYnkgYSBjb2x1bW4sDQo+ID4+IHNvbWV0aGluZyBsaWtlOg0KPiA+PiANCj4g Pj4gCXNvcnQoY29sdW1uLW5hbWUpIC0tPiBvZmZzZXQoLTIqcGFnZXNpemUpIC0tPiBsaW1pdChw YWdlc2l6ZSkNCj4gPj4gDQo+ID4+IEZvbGxvd2VkIGJ5IHRoZSBjbGllbnQgdGhlbiBmbGlwcGlu ZyB0aGUgcmVzdWx0cyB0byBwcmVzZW50IHRoZQ0KPiA+PiByZXN1bHRzIGluIHRoZSB1c2VyLXNl bGVjdGVkIG9yZGVyLCByaWdodD8NCj4gPj4gDQo+ID4+IFRoYXQgc2FpZCwgZ2l2ZW4gdGhhdCBE Qi1iYWNrZW5kcyB0aGF0IHN1cHBvcnQgc29ydHMgY29tbW9ubHkgYWxzbw0KPiA+PiBzdXBwb3J0 IGRpcmVjdGlvbiwgaXQncyB1bmNsZWFyIHdoYXQgdGhpcyBidXlzIHVzLg0KPiA+PiANCj4gPj4g DQo+ID4+Pj4+IFN1cmUsIGJ1dCBJIHdvbmRlciBpZiwgZS5nLiwgYSBuZXRtYXNrIGZpbHRlciwg aXMgc3VwcG9ydGFibGUgYnkgDQo+ID4+Pj4+IGNvbW1vbiBEQi1iYWNrZW5kcy4gIEnigJltIGhv cGluZyB3ZSBoYXZlIHNvbWUgREItZXhwZXJ0cyBvbiB0aGUgbGlzdCENCj4gPj4+PiANCj4gPj4+ PiBTZWUgYWJvdmUuICBJdCBjYW4gYmUgcXVpdGUgZWZmaWNpZW50IGV2ZW4gaWYgdGhlIGJhY2tl bmQgZG9lc24ndCANCj4gPj4+PiBzdXBwb3J0IGl0Lg0KPiA+Pj4gDQo+ID4+PiBJIGRvbuKAmXQg c2VlIHRoYXQgYWJvdmUsIGJ1dCBJIGRvbuKAmXQgZG91YnQgdGhhdCBpdCBjYW4gYmUgc28sIGl0 4oCZcyBqdXN0DQo+ID4+PiBhIHdob2xlIGxvdCBvZiBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5 LiAgSXQgc2VlbXMgdGhhdCB3ZQ0KPiA+Pj4gc2hvdWxkL211c3Qgc3VwcG9ydCBzZXJ2ZXJzIGRv aW5nIGl0LCB3ZSBqdXN0IG5lZWQgdG8gZmluZCBhIHdheQ0KPiA+Pj4gKG5vZGUtdGFncz8pIHRv IGVuYWJsZSB0aGVtIHRvIGV4cHJlc3MgdGhhdCBhYmlsaXR5Lg0KPiA+Pj4gW1Fpbl06IE15IGZl ZWxpbmcgaXMgdGhpcyBlZmZpY2llbmN5IG1vcmUgZGVwZW5kcyBvbiB0aGUgYW1vdW50IG9mDQo+ ID4+PiBkYXRhIHdlIG5lZWQgdG8gcmVxdWVzdC4gSWYgYW1vdW50IG9mIGRhdGEgd2UgcmVxdWVz dCBpcyBodWdlLCBtYXliZSwNCj4gPj4+IGNsaWVudC0+IHNlcnZlci0+IGJhY2tlbmQgbWF5IGJl IHRoZSBiZXR0ZXIgY2hvaWNlLg0KPiA+PiANCj4gPj4gSXMgaXQgdGhlIGFtb3VudCBvZiBkYXRh IHJlcXVlc3RlZCBvciB0aGUgbnVtYmVyIG9mIGVudHJpZXMgaW4gdGhlDQo+ID4+IGxpc3Q/ICBB dCBsZWFzdCwgaW4gbXkgd29ybGR2aWV3LCBjbGllbnRzIGFyZSBhbHdheXMgcmVxdWVzdGluZyBh DQo+ID4+IOKAnHBhZ2XigJ0gb2YgZGF0YSwgc28gdGhhdCBwYXJ0IGlzIHJhdGhlciBjb25zaXN0 ZW50bHkgc21hbGwuDQo+ID4+IA0KPiA+PiBJZiB0aGUgaW50ZW50aW9uIGlzIHRvIGdldCBhIGNv bXBsZXRlIGR1bXAsIHRoZW4gbWF5YmUgdGhlIGNvbW1lbnQNCj4gPj4gZnJvbSB5ZXN0ZXJkYXkg YXBwbGllcywgd2hlcmVieSBzdHJlYW1pbmcgdG8gYW4gZXh0ZXJuYWwgcmVwb3NpdG9yeQ0KPiA+ PiB0aGF0IGNhbiBiZSBxdWVyaWVkIG9mZmxpbmUgbWFrZXMgbW9yZSBzZW5zZT8gIC0gZXNwZWNp YWxseQ0KPiA+PiBjb25zaWRlcmluZyB0aGF0IHRoZSBudW1iZXIgb2Ygb24tYm94IGxvZ3MgaXMg bGlrZWx5IHRvIGJlIG9ubHkgdGhlDQo+ID4+IG1vc3QgcmVjZW50IChlLmcuLCBkYXlzKSwgd2hl cmVhcyB0aGUgY29tcGxldGUtZHVtcCB0eXBlIHF1ZXJpZXMNCj4gPj4gbGlrZWx5IHdpc2ggdG8g ZXh0ZW5kIHdlbGwtcGFzdCB0aGF0Lg0KPiA+PiANCj4gPj4gSy4NCj4gPj4gDQo+ID4+IA0KPiAN Cg== From nobody Thu Oct 1 09:17:22 2020 Return-Path: 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 29EB83A0C00 for ; Thu, 1 Oct 2020 09:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 jz3naiXggtGh for ; Thu, 1 Oct 2020 09:17:18 -0700 (PDT) Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFAFE3A0B93 for ; Thu, 1 Oct 2020 09:17:17 -0700 (PDT) Received: by mail-lf1-x143.google.com with SMTP id b12so7271276lfp.9 for ; Thu, 01 Oct 2020 09:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+3wWhTIHfkOTX3Eviz8WW6K65JhlIjmV914yW9Q23wI=; b=MyWXCy9xyXFXxJyc/u60iGltRUcu1dBmaLwWTLwkwjJ6Z7hLSi0MGjcyZv7qLi4xFG Y0PvbmogJa95MmpEN1QkBF8p+du1vfau/U9sTtCKDqvceH9myNaEDakfzWlMVoleAXME WGG8MoOunNB+vdQHIM95HluO8PKtLJ+YwGy57EvdA+96kGdxsp4B0ZMZoPiwutR+STg+ 2kuMjMH7rkCMzra4v/nwTyJI1+c8ap85LUOMRt1rTrgVEaXty5ryoLJHwYvhLhfhyD+k ZRuFg6Lu9dMZn/daVvWkrozecD23l+3CZxhgESnoNWFfkIufV2vYhmJnwGfRQyuxfYZQ jWUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+3wWhTIHfkOTX3Eviz8WW6K65JhlIjmV914yW9Q23wI=; b=rhI0p1p0rpgk5zJblvcXxj7jpLL+/QWoOy6iJZs9etLpmdmtLUdia+FIRhPf4Sz0x0 mt44qZqBURlS/tF0H7iWUROtKlITEasKvbD6gNu0hpGC2V4ybGmq3IGj1bGUi6GuappS qW8I2CctlTZoEV74ZC8U4zAQehlW3cF6SPCLojsNJsCDjXXd+skWzb4fEgtf12i1Brkw 3nSCCl60JY4HcjrW9g3QgtHpAYJt+7kQ55sGF/7jUyqaaFqmExTNbJOsqEHsYnZO06TT h9hKGuSvHTQ4LthkwptW3p75c/lLKYD0mYpnf1JzzzLDkh/wvmuIAL7DQLC1uCgWy941 JVyw== X-Gm-Message-State: AOAM530Yy+SEp8pKBERSt2OHIJJeFMq6CDwtvizPk5wdDAoZDSrSaqWY Z/yPiCp/oGyA9gRnb71dA7eNHtDH19D+q79pqf5Gaw== X-Google-Smtp-Source: ABdhPJwp2rPCZ92hvZVS+tG58WCzx6oJHm8KGgKHpPqJ73ObBdPblwvMP9wL8PEekOF9nIkhT/BO4eKvx7smhoMCT7g= X-Received: by 2002:a19:5214:: with SMTP id m20mr2734491lfb.138.1601569035916; Thu, 01 Oct 2020 09:17:15 -0700 (PDT) MIME-Version: 1.0 References: <01000174e42a0ab6-d29a9843-5a7a-4804-acba-276a859e4612-000000@email.amazonses.com> <20201001.152335.649983049956449669.id@4668.se> <01000174e45cdb27-6ee646b5-42e6-4547-9366-91b86bf8ac84-000000@email.amazonses.com> <20201001.165715.770697558669717572.id@4668.se> In-Reply-To: <20201001.165715.770697558669717572.id@4668.se> From: Andy Bierman Date: Thu, 1 Oct 2020 09:17:01 -0700 Message-ID: To: =?UTF-8?Q?Martin_Bj=C3=B6rklund?= Cc: Kent Watsen , Netconf Content-Type: multipart/alternative; boundary="0000000000007839f305b09e5922" Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org 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: Thu, 01 Oct 2020 16:17:20 -0000 --0000000000007839f305b09e5922 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 1, 2020 at 7:57 AM Martin Bj=C3=B6rklund wro= te: > Kent Watsen wrote: > > > > > > > On Oct 1, 2020, at 9:23 AM, Martin Bj=C3=B6rklund = wrote: > > > > > > Kent Watsen wrote: > > >> Hi Qin, > > >> > > >>> Some opstate must be persisted, e.g., long-lived counters, logs, > etc., > > >>> but it=E2=80=99s a good point about other opstate not being persist= ed. > > >>> Perhaps =E2=80=9Cnode-tags=E2=80=9D can be used here, to differenti= ate which is > > >>> which=E2=80=A6and servers can indicate if/how they support the ephe= meral > > >>> opstate leafs in queries? > > >>> > > >>> [Qin]:That's a good case for node tag, in earlier discussion, we > > >>> discussed operation type, which distinguishs cumulative statistics > > >>> value from current value. The case discussed here is very close to > > >>> operation type proposal discussed earlier. > > >> > > >> Yes. Thank you for pointing that out. I meant to make the same > > >> observation before. Indeed, such node-tags could have dual-purpose: > > >> to guide a streaming-strategy and a querying-strategy for certain > > >> nodes. > > >> > > >> > > >>> Note sure how others feel about =E2=80=9Cdirection: (c), but my pri= mary > > >>> use-case revolves around time-series data (e.g., logs), where the > > >>> interest is commonly on the most-recent entries, so > > >>> "reverse-->offset=E2=80=94>limit=E2=80=9D works nicely. > > >>> > > >>> Perhaps an alternative would be to lift a concept from Python with > > >>> negative indexes so, for instance, offset=3D-N and limit=3D-N gives= the > > >>> last N entries? > > >>> [Qin]: Yes, that's what I thought as well, with negative indexes, (= b) > > >>> and (c) seems to me, can be combined. > > >> > > >> Can others comment on this? > > > > > > Isn't this just another syntax for the same function? > > > > No, it is not. > > How so? Isn't the idea that you can first ask for offset=3D-10, then > -20, etc, essentially walking the list backwards? (I don't understand > what a negative limit means though). > > Can somebody explain the use-case for iterating a list backwards? No customer has ever asked for this so I am wondering what we are all missing. I guess it isn't clear that offsets do not work for lists where entries are added and/or deleted over time, unless lots of state is kept by the server. I guess if you are looking for the most expensive heavyweight solution possible then this is a good start. > > /martin > Andy > > > > > > K. > > > > > > > > > > /martin > > > > > > > > >> Presumably, we could eliminate =E2=80=9Cdirection=E2=80=9D (c) with = this approach. > > >> > > >> Without =E2=80=9Cdirection=E2=80=9D, I think that UIs can still supp= ort the ability to > > >> do column-sorts, whereby the user clicks on a column=E2=80=99s heade= r to > > >> toggle ascending vs. descending presentation, but they=E2=80=99ll ha= ve to do > > >> it client-side. > > >> > > >> That is, if wanting to see the 2nd page of results sorted by a colum= n, > > >> something like: > > >> > > >> sort(column-name) --> offset(-2*pagesize) --> limit(pagesize) > > >> > > >> Followed by the client then flipping the results to present the > > >> results in the user-selected order, right? > > >> > > >> That said, given that DB-backends that support sorts commonly also > > >> support direction, it's unclear what this buys us. > > >> > > >> > > >>>>> Sure, but I wonder if, e.g., a netmask filter, is supportable by > > >>>>> common DB-backends. I=E2=80=99m hoping we have some DB-experts o= n the > list! > > >>>> > > >>>> See above. It can be quite efficient even if the backend doesn't > > >>>> support it. > > >>> > > >>> I don=E2=80=99t see that above, but I don=E2=80=99t doubt that it c= an be so, it=E2=80=99s > just > > >>> a whole lot of implementation complexity. It seems that we > > >>> should/must support servers doing it, we just need to find a way > > >>> (node-tags?) to enable them to express that ability. > > >>> [Qin]: My feeling is this efficiency more depends on the amount of > > >>> data we need to request. If amount of data we request is huge, mayb= e, > > >>> client-> server-> backend may be the better choice. > > >> > > >> Is it the amount of data requested or the number of entries in the > > >> list? At least, in my worldview, clients are always requesting a > > >> =E2=80=9Cpage=E2=80=9D of data, so that part is rather consistently = small. > > >> > > >> If the intention is to get a complete dump, then maybe the comment > > >> from yesterday applies, whereby streaming to an external repository > > >> that can be queried offline makes more sense? - especially > > >> considering that the number of on-box logs is likely to be only the > > >> most recent (e.g., days), whereas the complete-dump type queries > > >> likely wish to extend well-past that. > > >> > > >> K. > > >> > > >> > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --0000000000007839f305b09e5922 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Oct 1, 2020 at 7:57 AM Martin= Bj=C3=B6rklund <mbj+ietf@4668.se<= /a>> wrote:
K= ent Watsen <= kent+ietf@watsen.net> wrote:
>
>
> > On Oct 1, 2020, at 9:23 AM, Martin Bj=C3=B6rklund <mbj+ietf@4668.se> wrote= :
> >
> > Kent Watsen <kent+ietf@watsen.net> wrote:
> >> Hi Qin,
> >>
> >>> Some opstate must be persisted, e.g., long-lived counters= , logs, etc.,
> >>> but it=E2=80=99s a good point about other opstate not bei= ng persisted.
> >>> Perhaps =E2=80=9Cnode-tags=E2=80=9D can be used here, to = differentiate which is
> >>> which=E2=80=A6and servers can indicate if/how they suppor= t the ephemeral
> >>> opstate leafs in queries?
> >>>
> >>> [Qin]:That's a good case for node tag, in earlier dis= cussion, we
> >>> discussed operation type, which distinguishs cumulative s= tatistics
> >>> value from current value. The case discussed here is very= close to
> >>> operation type proposal discussed earlier.
> >>
> >> Yes.=C2=A0 Thank you for pointing that out.=C2=A0 I meant to = make the same
> >> observation before.=C2=A0 Indeed, such node-tags could have d= ual-purpose:
> >> to guide a streaming-strategy and a querying-strategy for cer= tain
> >> nodes.
> >>
> >>
> >>> Note sure how others feel about =E2=80=9Cdirection: (c), = but my primary
> >>> use-case revolves around time-series data (e.g., logs), w= here the
> >>> interest is commonly on the most-recent entries, so
> >>> "reverse-->offset=E2=80=94>limit=E2=80=9D work= s nicely.
> >>>
> >>> Perhaps an alternative would be to lift a concept from Py= thon with
> >>> negative indexes so, for instance, offset=3D-N and limit= =3D-N gives the
> >>> last N entries?
> >>> [Qin]: Yes, that's what I thought as well, with negat= ive indexes, (b)
> >>> and (c) seems to me, can be combined.
> >>
> >> Can others comment on this?
> >
> > Isn't this just another syntax for the same function?
>
> No, it is not.

How so?=C2=A0 Isn't the idea that you can first ask for offset=3D-10, t= hen
-20, etc, essentially walking the list backwards?=C2=A0 (I don't unders= tand
what a negative limit means though).




Can some= body explain the use-case for iterating a list backwards?
No cust= omer has ever asked for this so I am wondering what we are all missing.

I guess it isn't clear that offsets do not work f= or lists where entries
are added and/or deleted over time, unless= lots of state is kept by the server.
I guess if you are looking = for the most expensive heavyweight solution possible
then this is= a good start.

=C2=A0

/martin

Andy
=C2=A0


>
> K.
>
>
> >
> > /martin
> >
> >
> >> Presumably, we could eliminate =E2=80=9Cdirection=E2=80=9D (c= ) with this approach.=C2=A0
> >>
> >> Without =E2=80=9Cdirection=E2=80=9D, I think that UIs can sti= ll support the ability to
> >> do column-sorts, whereby the user clicks on a column=E2=80=99= s header to
> >> toggle ascending vs. descending presentation, but they=E2=80= =99ll have to do
> >> it client-side.
> >>
> >> That is, if wanting to see the 2nd page of results sorted by = a column,
> >> something like:
> >>
> >>=C2=A0 =C2=A0 sort(column-name) --> offset(-2*pagesize) --&= gt; limit(pagesize)
> >>
> >> Followed by the client then flipping the results to present t= he
> >> results in the user-selected order, right?
> >>
> >> That said, given that DB-backends that support sorts commonly= also
> >> support direction, it's unclear what this buys us.
> >>
> >>
> >>>>> Sure, but I wonder if, e.g., a netmask filter, is= supportable by
> >>>>> common DB-backends.=C2=A0 I=E2=80=99m hoping we h= ave some DB-experts on the list!
> >>>>
> >>>> See above.=C2=A0 It can be quite efficient even if th= e backend doesn't
> >>>> support it.
> >>>
> >>> I don=E2=80=99t see that above, but I don=E2=80=99t doubt= that it can be so, it=E2=80=99s just
> >>> a whole lot of implementation complexity.=C2=A0 It seems = that we
> >>> should/must support servers doing it, we just need to fin= d a way
> >>> (node-tags?) to enable them to express that ability.
> >>> [Qin]: My feeling is this efficiency more depends on the = amount of
> >>> data we need to request. If amount of data we request is = huge, maybe,
> >>> client-> server-> backend may be the better choice.=
> >>
> >> Is it the amount of data requested or the number of entries i= n the
> >> list?=C2=A0 At least, in my worldview, clients are always req= uesting a
> >> =E2=80=9Cpage=E2=80=9D of data, so that part is rather consis= tently small.
> >>
> >> If the intention is to get a complete dump, then maybe the co= mment
> >> from yesterday applies, whereby streaming to an external repo= sitory
> >> that can be queried offline makes more sense?=C2=A0 - especia= lly
> >> considering that the number of on-box logs is likely to be on= ly the
> >> most recent (e.g., days), whereas the complete-dump type quer= ies
> >> likely wish to extend well-past that.
> >>
> >> K.
> >>
> >>
>
_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--0000000000007839f305b09e5922-- From nobody Thu Oct 1 12:54:08 2020 Return-Path: <01000174e5ba8cc5-39edb446-48d9-4896-a6b5-dcf80f962762-000000@amazonses.watsen.net> 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 5158D3A0410 for ; Thu, 1 Oct 2020 12:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 FQEsut3Q5bOh for ; Thu, 1 Oct 2020 12:54:05 -0700 (PDT) Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960003A0400 for ; Thu, 1 Oct 2020 12:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601582042; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=YvU8fj+dzr7kx4K99DgMfYvv5EGTOe7IeIdspn+2WeM=; b=SRrZ84kVTOBbag5b3jqAvMBM6WOt4ZgQ6FQ5RZ/3L6gJE1L5Wvf5KkkQWMwLowih HvkL/bMIWr6iVmzaWyYiMN1vF81PcYwzyeGaylM+J5pes+jrE/zS89X8DrjoqqP+dNf ACz2oGWMKp1Gd/kARxCpY3B0Q2Ryov5l9PlfLYvo= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Kent Watsen In-Reply-To: <20201001.165548.1275939966226069939.id@4668.se> Date: Thu, 1 Oct 2020 19:54:02 +0000 Cc: Olof Hagsand , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000174e5ba8cc5-39edb446-48d9-4896-a6b5-dcf80f962762-000000@email.amazonses.com> References: <01000174e09a04a9-f53134f8-009f-4d0a-84a1-3165a494054b-000000@email.amazonses.com> <20201001.083349.1861081830665539794.id@4668.se> <01000174e4610ae6-d1488376-ae7e-4d95-ba7e-005fc44b9592-000000@email.amazonses.com> <20201001.165548.1275939966226069939.id@4668.se> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.10.01-54.240.48.110 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org 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: Thu, 01 Oct 2020 19:54:06 -0000 Hi Martin, > I would prefer an unconstrained filter, with the XPath 1.0 that is > already used in YANG. It would be ok if support for such a filter was > optional (a capability). My point is that even if the backend doesn't > support filtering on a particular node, filtering in the server will > be much more efficient than filtering in the client. Hence filtering > shouldn't be constrained to certain nodes. It also makes the solution > much easier to use for clients. 1) Current NC/RC Xpath-filter found in was not intended to filter = large sets of logs. 2) The Xpath-filters used for streaming (s4.4.3 in rfc8040 and = "stream-xpath-filter=E2=80=9D in rfc8639) aren=E2=80=99t a fair = comparison, as said stream-filters are already dispatching one event at = a time. But do note that rc8639 says the following, indciatiing that = full Xpath cannot apply (e.g., preceding-sibling): The XPath expression is evaluated on the representation of individual, delineated event records as contained in the event stream. 3) Here we=E2=80=99re talking about querying a potentially large = repository of logs that are at rest, and full table scans should = avoided. I suggest that we=E2=80=99re dealing with something new here. IMO, for pretty much any CT data, full table scans isn=E2=80=99t a = deal-breaker, as I don=E2=80=99t feel that configured data is ever that = big (even for interfaces or a firewall rulebases). It would be = unfortunate for servers to have a reimplement all the filtering logic = that is normally provided by backends (just because Xpath supports = something that isn=E2=80=99t mappable), and it wouldn=E2=80=99t be as = fast, but it is possible to implement and, to your point, it=E2=80=99s = likely faster for the server to do it than the client. But when it comes to CF data, doing a full table scan is impractical and = index-backed queries can make the difference between the client waiting = seconds vs minutes. This is why I was initially trying to focus on just = solving the CF problem, where the pain is acute. That said, I propose we do =E2=80=9Cboth=E2=80=9D. That is, the default = is a customer-satisfying Xpath-subset known to be mappable to common = DB-backends, and a feature statement is used to enable full Xpath = support. In both cases, the Xpath context node is the individual = list-entry. For some servers claiming full Xpath support, it could be that if a = client=E2=80=99s query uses something beyond the mappable-subset, then = the server silently switches to its =E2=80=9Cslow-path=E2=80=9D logic = (e.g., table scan until =E2=80=9Ccount=E2=80=9D is reached, if = specified). The server=E2=80=99s documentation can describe the = behavior, and even go so far as to suggests that it=E2=80=99s not that = big of a deal for CT lists, but that the client may be waiting for a = long time and/or the server may run out of resources, if applied to a = big CF list. > Right, but note that this filtering can and should be applied to all > nodes, also operational state nodes that isn't stored in any database > at all, imo. This could be when a server silently switches to its slow-path logic. K. From nobody Thu Oct 1 14:20:46 2020 Return-Path: <01000174e60991af-f0cb2586-a767-4c64-b30e-17dbd1c69048-000000@amazonses.watsen.net> 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 848813A093D; Thu, 1 Oct 2020 14:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.612 X-Spam-Level: X-Spam-Status: No, score=0.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SUSPICIOUS_RECIPS=2.51] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 jhNYKTTTDnZI; Thu, 1 Oct 2020 14:20:44 -0700 (PDT) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809E13A0937; Thu, 1 Oct 2020 14:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601587221; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:Cc:To:Feedback-ID; bh=YmAago9mmAE2KqAKqM+avxTAYYK7quG99RC5p5fuugk=; b=DZimw+MsumWFPKHQ9DUB5uPGM7Ls+zkPW0M3YETUg67DiNIzJ46CRYPw4mfcSO4s Ep7xly+4x9VD/D4LjT6xk5o6ond4WQGMIyGL5a22k0pPT6QyUfEJxyoTZmqeae3pzCY IBGSWg4sz4fe367HH8GDyR7z94Ae5OvJo+UUDYAE= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_E0FDA33E-55CC-4C69-A474-AC09F8061866" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <01000174e60991af-f0cb2586-a767-4c64-b30e-17dbd1c69048-000000@email.amazonses.com> Date: Thu, 1 Oct 2020 21:20:21 +0000 Cc: draft-unyte-netconf-udp-notif@ietf.org, draft-unyte-netconf-distributed-notif@ietf.org, draft-kwatsen-netconf-sztp-csr@ietf.org, draft-wang-netconf-bulk-subscribed-notifications@ietf.org, draft-wang-netconf-adaptive-subscription@ietf.org, draft-tao-netconf-notif-node-tag-capabilities@ietf.org, draft-tao-netconf-data-export-capabilities@ietf.org To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.10.01-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Analysis of adoption-suitability polls X-BeenThere: netconf@ietf.org 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: Thu, 01 Oct 2020 21:20:46 -0000 --Apple-Mail=_E0FDA33E-55CC-4C69-A474-AC09F8061866 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you to all who participated in the adoption-suitability polls = initiated on August 5. The chairs apologize for being late with this = response, but wanted to ensure everyone had an opportunity to respond. There were seven drafts up for potential adoption for which we requested = feedback on. While we would=E2=80=99ve liked to see more responses, we = feel that there is enough information to establish initial findings. Adoption Poll Succeeded =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The following drafts presented themselves as having the most = amount and diversity of support, both from authors and non-authors and, = more importantly, have no standing objections: - draft-unyte-netconf-udp-notif - draft-unyte-netconf-distributed-notif - draft-kwatsen-netconf-sztp-csr Authors, please resubmit your drafts as working group documents (e.g., =E2=80=9Cdraft-ietf=E2=80=A6=E2=80=9D). Please submit = them as is, without modification from that reviewed. Adoption Pending =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The following drafts have standing objections that are = unresolved,=20 and also lack significant number and diversity of responses: - draft-wang-netconf-bulk-subscribed-notifications - draft-wang-netconf-adaptive-subscription - draft-tao-netconf-notif-node-tag-capabilities - draft-tao-netconf-data-export-capabilities Authors are encouraged to engage the working group in = discussions about their drafts, and then update and resubmit them when = ready. Thanks, NETCONF Chairs --Apple-Mail=_E0FDA33E-55CC-4C69-A474-AC09F8061866 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Thank you to all who participated = in the adoption-suitability polls initiated on August 5.  The = chairs apologize for being late with this response, but wanted to ensure = everyone had an opportunity to respond.

There were seven drafts up for potential adoption for which = we requested feedback on.  While we would=E2=80=99ve liked to see = more responses, we feel that there is enough information to establish = initial findings.


Adoption = Poll Succeeded
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=

The following drafts presented = themselves as having the most amount
and diversity of support, both = from authors and non-authors and, more
importantly, have no = standing objections:

= - draft-unyte-netconf-udp-notif
- draft-unyte-netconf-distributed-notif
- draft-kwatsen-netconf-sztp-csr

Authors, = please resubmit your drafts as working group documents
(e.g., =E2=80=9Cdraft-ietf=E2=80=A6= =E2=80=9D).  Please submit them as is, without = modification
from that = reviewed.


Adoption = Pending
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The following drafts have = standing objections that are unresolved, 
and = also lack significant number and diversity of responses:

= - draft-wang-netconf-bulk-subscribed-notifications
= - draft-wang-netconf-adaptive-subscription
= - draft-tao-netconf-notif-node-tag-capabilities
= - draft-tao-netconf-data-export-capabilities

Authors are encouraged to engage = the working group in discussions
= about their drafts, and then update and resubmit them when = ready.


Thanks,
NETCONF= Chairs



= --Apple-Mail=_E0FDA33E-55CC-4C69-A474-AC09F8061866-- From nobody Thu Oct 1 23:23:39 2020 Return-Path: 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 80E573A0E7C for ; Thu, 1 Oct 2020 23:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.997, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=evBbUCfV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jZzoU6Xt 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 K9vjRvgZ-DRD for ; Thu, 1 Oct 2020 23:23:36 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0129E3A0E7A for ; Thu, 1 Oct 2020 23:23:35 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 39D1E5C00D1; Fri, 2 Oct 2020 02:23:35 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Fri, 02 Oct 2020 02:23:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm2; bh= u291mqT7TWW8Z+MNIgDDJ+8K7UPGF1t4Yzqmi5fTZ2Y=; b=evBbUCfVejwkgXzJ Z3o87JPlRAYLaJ5YeF1CpSkBu5p8D1tr2uT+umzCCJo1S6fGHxQ8LJe07cn43lIU mjLvUTXJJdtFVcegyqYVK1z/aWY5OU6WSYtyHmpCiKOCYdecMC/th0zIDrtkpvwM A8z/nb13t1Uca6CCaBt+UqKcHROZTdVvhRHXA/i5Mndp+nNrMfPr4QOhMb0sCE+m Hka2b4phsAW5Thw+zWUQje4IIrLm60j2MuTOqq+oLaukhw4hbA+Q7uO7pZkyym8R SOhRQfWKfRyi02Q5B6nppTKw3hyZDP7guGWrmZ3DrLJbX7zSsXzP1wJPA3X4RD3T 3U4Z2Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=u291mqT7TWW8Z+MNIgDDJ+8K7UPGF1t4Yzqmi5fTZ 2Y=; b=jZzoU6XtmZDg9qGrPVHlHT4NMhTzKZXkpOFk/zEggvKq5mt0Mo2Wf3NHt 9ovJ7gVunS8HKq4iIKTB3kJ0u0IkT6cxQs4iD+a8YlvMvsmMqPdb+vMyEZAFRMrg 3wXOrZcCyRKBpRxtxnCs83n/3o4V6kGnd8fc/Czh7XNHLdUqMyMR+pbZdBSe9emJ xTocx4OFY7CLu03Iqt9EZf0yoAbw/hXer7vJjgOPKSr0FTUNz+AkwH7kyKhdqy+U ZG2ZoWmSAcuWc4IdjMZ6+7g86DO8m2DedHAIYuFzyRefCN07T3FmgN0bHE8oqr7v WY9HqM4XJpRkO/jnDmTKbJFpoueZA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrfeehgddutdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtsg ertdertdejnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepheetgedtfffggeffkedvje ekveelteeuuddttdffhfelgfetvdevhedvgeeutddunecukfhppeduheekrddujeegrdeg rddvudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhgsjhdoihgvthhfseegieeikedrshgv X-ME-Proxy: Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id 2D8793064680; Fri, 2 Oct 2020 02:23:33 -0400 (EDT) Date: Fri, 02 Oct 2020 08:23:31 +0200 (CEST) Message-Id: <20201002.082331.2242297379846191383.id@4668.se> To: kent+ietf@watsen.net Cc: olof@hagsand.se, netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <01000174e5ba8cc5-39edb446-48d9-4896-a6b5-dcf80f962762-000000@email.amazonses.com> References: <01000174e4610ae6-d1488376-ae7e-4d95-ba7e-005fc44b9592-000000@email.amazonses.com> <20201001.165548.1275939966226069939.id@4668.se> <01000174e5ba8cc5-39edb446-48d9-4896-a6b5-dcf80f962762-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org 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, 02 Oct 2020 06:23:38 -0000 SGksDQoNCktlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD4gd3JvdGU6DQo+IEhpIE1h cnRpbiwNCj4gDQo+ID4gSSB3b3VsZCBwcmVmZXIgYW4gdW5jb25zdHJhaW5lZCBmaWx0ZXIsIHdp dGggdGhlIFhQYXRoIDEuMCB0aGF0IGlzDQo+ID4gYWxyZWFkeSB1c2VkIGluIFlBTkcuICBJdCB3 b3VsZCBiZSBvayBpZiBzdXBwb3J0IGZvciBzdWNoIGEgZmlsdGVyIHdhcw0KPiA+IG9wdGlvbmFs IChhIGNhcGFiaWxpdHkpLiAgTXkgcG9pbnQgaXMgdGhhdCBldmVuIGlmIHRoZSBiYWNrZW5kIGRv ZXNuJ3QNCj4gPiBzdXBwb3J0IGZpbHRlcmluZyBvbiBhIHBhcnRpY3VsYXIgbm9kZSwgZmlsdGVy aW5nIGluIHRoZSBzZXJ2ZXIgd2lsbA0KPiA+IGJlIG11Y2ggbW9yZSBlZmZpY2llbnQgdGhhbiBm aWx0ZXJpbmcgaW4gdGhlIGNsaWVudC4gIEhlbmNlIGZpbHRlcmluZw0KPiA+IHNob3VsZG4ndCBi ZSBjb25zdHJhaW5lZCB0byBjZXJ0YWluIG5vZGVzLiAgSXQgYWxzbyBtYWtlcyB0aGUgc29sdXRp b24NCj4gPiBtdWNoIGVhc2llciB0byB1c2UgZm9yIGNsaWVudHMuDQo+IA0KPiAxKSBDdXJyZW50 IE5DL1JDIFhwYXRoLWZpbHRlciBmb3VuZCBpbiA8Z2V0PiB3YXMgbm90IGludGVuZGVkIHRvDQo+ IGZpbHRlciBsYXJnZSBzZXRzIG9mIGxvZ3MuDQo+IA0KPiAyKSBUaGUgWHBhdGgtZmlsdGVycyB1 c2VkIGZvciBzdHJlYW1pbmcgKHM0LjQuMyBpbiByZmM4MDQwIGFuZA0KPiAic3RyZWFtLXhwYXRo LWZpbHRlcuKAnSBpbiByZmM4NjM5KSBhcmVu4oCZdCBhIGZhaXIgY29tcGFyaXNvbiwgYXMgc2Fp ZA0KPiBzdHJlYW0tZmlsdGVycyBhcmUgYWxyZWFkeSBkaXNwYXRjaGluZyBvbmUgZXZlbnQgYXQg YSB0aW1lLiAgQnV0IGRvDQo+IG5vdGUgdGhhdCByYzg2Mzkgc2F5cyB0aGUgZm9sbG93aW5nLCBp bmRjaWF0aWluZyB0aGF0IGZ1bGwgWHBhdGgNCj4gY2Fubm90IGFwcGx5IChlLmcuLCBwcmVjZWRp bmctc2libGluZyk6DQo+IA0KPiAJVGhlIFhQYXRoIGV4cHJlc3Npb24gaXMgZXZhbHVhdGVkIG9u IHRoZSByZXByZXNlbnRhdGlvbiBvZg0KPiAJaW5kaXZpZHVhbCwgZGVsaW5lYXRlZCBldmVudCBy ZWNvcmRzIGFzIGNvbnRhaW5lZCBpbg0KPiAJdGhlIGV2ZW50IHN0cmVhbS4NCj4gDQo+IDMpIEhl cmUgd2XigJlyZSB0YWxraW5nIGFib3V0IHF1ZXJ5aW5nIGEgcG90ZW50aWFsbHkgbGFyZ2UgcmVw b3NpdG9yeSBvZg0KPiBsb2dzIHRoYXQgYXJlIGF0IHJlc3QsIGFuZCBmdWxsIHRhYmxlIHNjYW5z IHNob3VsZCBhdm9pZGVkLiAgSSBzdWdnZXN0DQo+IHRoYXQgd2XigJlyZSBkZWFsaW5nIHdpdGgg c29tZXRoaW5nIG5ldyBoZXJlLg0KDQpQZXJoYXBzIHdlIGRvbid0IHVuZGVyc3RhbmQgZWFjaCBv dGhlci4gIEhlcmUncyBhbiBwc2V1ZG8tY29kZSBleGFtcGxlDQpvZiB3aGF0IEkgZW52aXNpb246 DQoNCiAgR0VUIC9pbnRlcmZhY2VzL2ludGVyZmFjZQ0KICBmaWx0ZXIgICdvcGVyLXN0YXR1cyA9 ICJ1cCIgYW5kIHN0YXRpc3RpY3MvaW4tZXJyb3JzID4gMCcNCg0KVGhpcyBpcyBYUGF0aCAxLjAs IGFwcGxpZWQgdG8gb25lIGluc3RhbmNlIGF0IHRoZSB0aW1lLg0KDQoNCg0KPiBJTU8sIGZvciBw cmV0dHkgbXVjaCBhbnkgQ1QgZGF0YSwgZnVsbCB0YWJsZSBzY2FucyBpc27igJl0IGENCj4gZGVh bC1icmVha2VyLCBhcyBJIGRvbuKAmXQgZmVlbCB0aGF0IGNvbmZpZ3VyZWQgZGF0YSBpcyBldmVy IHRoYXQgYmlnDQo+IChldmVuIGZvciBpbnRlcmZhY2VzIG9yIGEgZmlyZXdhbGwgcnVsZWJhc2Vz KS4gIEl0IHdvdWxkIGJlDQo+IHVuZm9ydHVuYXRlIGZvciBzZXJ2ZXJzIHRvIGhhdmUgYSByZWlt cGxlbWVudCBhbGwgdGhlIGZpbHRlcmluZyBsb2dpYw0KPiB0aGF0IGlzIG5vcm1hbGx5IHByb3Zp ZGVkIGJ5IGJhY2tlbmRzIChqdXN0IGJlY2F1c2UgWHBhdGggc3VwcG9ydHMNCj4gc29tZXRoaW5n IHRoYXQgaXNu4oCZdCBtYXBwYWJsZSksIGFuZCBpdCB3b3VsZG7igJl0IGJlIGFzIGZhc3QsIGJ1 dCBpdCBpcw0KPiBwb3NzaWJsZSB0byBpbXBsZW1lbnQgYW5kLCB0byB5b3VyIHBvaW50LCBpdOKA mXMgbGlrZWx5IGZhc3RlciBmb3IgdGhlDQo+IHNlcnZlciB0byBkbyBpdCB0aGFuIHRoZSBjbGll bnQuDQo+IA0KPiBCdXQgd2hlbiBpdCBjb21lcyB0byBDRiBkYXRhLCBkb2luZyBhIGZ1bGwgdGFi bGUgc2NhbiBpcyBpbXByYWN0aWNhbA0KPiBhbmQgaW5kZXgtYmFja2VkIHF1ZXJpZXMgY2FuIG1h a2UgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgY2xpZW50DQo+IHdhaXRpbmcgc2Vjb25kcyB2 cyBtaW51dGVzLiAgVGhpcyBpcyB3aHkgSSB3YXMgaW5pdGlhbGx5IHRyeWluZyB0bw0KPiBmb2N1 cyBvbiBqdXN0IHNvbHZpbmcgdGhlIENGIHByb2JsZW0sIHdoZXJlIHRoZSBwYWluIGlzIGFjdXRl Lg0KDQpXZWxsLCBpdCBpcyBsZXNzIGxpa2VseSB0aGF0IGFuIGltcGxlbWVudGF0aW9uIHVzZXMg YSBmZWF0dXJlLXJpY2ggKGluDQp0ZXJtcyBvZiBxdWVyeSBsYW5ndWFnZSkgREIgdG8gc3RvcmUg YWxsIGl0cyBzdGF0ZSwgdGhhbiBpdHMgY29uZmlnLg0KU28gaXQgd291bGQgcHJvYmFibHkgYmUg ZWFzaWVyIHRvIGltcGxlbWVudCB0aGlzIHVzaW5nICJhbiBpbmRleCIgZm9yDQpjb25maWcgdGhh biBmb3IgY29uZmlnIGZhbHNlLi4uDQoNCj4gVGhhdCBzYWlkLCBJIHByb3Bvc2Ugd2UgZG8g4oCc Ym90aOKAnS4gIFRoYXQgaXMsIHRoZSBkZWZhdWx0IGlzIGENCj4gY3VzdG9tZXItc2F0aXNmeWlu ZyBYcGF0aC1zdWJzZXQga25vd24gdG8gYmUgbWFwcGFibGUgdG8gY29tbW9uDQo+IERCLWJhY2tl bmRzLCBhbmQgYSBmZWF0dXJlIHN0YXRlbWVudCBpcyB1c2VkIHRvIGVuYWJsZSBmdWxsIFhwYXRo DQo+IHN1cHBvcnQuICBJbiBib3RoIGNhc2VzLCB0aGUgWHBhdGggY29udGV4dCBub2RlIGlzIHRo ZSBpbmRpdmlkdWFsDQo+IGxpc3QtZW50cnkuDQo+IA0KPiBGb3Igc29tZSBzZXJ2ZXJzIGNsYWlt aW5nIGZ1bGwgWHBhdGggc3VwcG9ydCwgaXQgY291bGQgYmUgdGhhdCBpZiBhDQo+IGNsaWVudOKA mXMgcXVlcnkgdXNlcyBzb21ldGhpbmcgYmV5b25kIHRoZSBtYXBwYWJsZS1zdWJzZXQsIHRoZW4g dGhlDQo+IHNlcnZlciBzaWxlbnRseSBzd2l0Y2hlcyB0byBpdHMg4oCcc2xvdy1wYXRo4oCdIGxv Z2ljIChlLmcuLCB0YWJsZSBzY2FuDQo+IHVudGlsIOKAnGNvdW504oCdIGlzIHJlYWNoZWQsIGlm IHNwZWNpZmllZCkuICBUaGUgc2VydmVy4oCZcyBkb2N1bWVudGF0aW9uDQo+IGNhbiBkZXNjcmli ZSB0aGUgYmVoYXZpb3IsIGFuZCBldmVuIGdvIHNvIGZhciBhcyB0byBzdWdnZXN0cyB0aGF0IGl0 4oCZcw0KPiBub3QgdGhhdCBiaWcgb2YgYSBkZWFsIGZvciBDVCBsaXN0cywgYnV0IHRoYXQgdGhl IGNsaWVudCBtYXkgYmUNCj4gd2FpdGluZyBmb3IgYSBsb25nIHRpbWUgYW5kL29yIHRoZSBzZXJ2 ZXIgbWF5IHJ1biBvdXQgb2YgcmVzb3VyY2VzLCBpZg0KPiBhcHBsaWVkIHRvIGEgYmlnIENGIGxp c3QuDQoNCkkgYWdyZWUuDQoNCj4gPiBSaWdodCwgYnV0IG5vdGUgdGhhdCB0aGlzIGZpbHRlcmlu ZyBjYW4gYW5kIHNob3VsZCBiZSBhcHBsaWVkIHRvIGFsbA0KPiA+IG5vZGVzLCBhbHNvIG9wZXJh dGlvbmFsIHN0YXRlIG5vZGVzIHRoYXQgaXNuJ3Qgc3RvcmVkIGluIGFueSBkYXRhYmFzZQ0KPiA+ IGF0IGFsbCwgaW1vLg0KPiANCj4gVGhpcyBjb3VsZCBiZSB3aGVuIGEgc2VydmVyIHNpbGVudGx5 IHN3aXRjaGVzIHRvIGl0cyBzbG93LXBhdGggbG9naWMuDQo+IA0KPiBLLg0KDQoNCi9tYXJ0aW4N Cg== From nobody Fri Oct 2 02:37:34 2020 Return-Path: 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 BD10D3A0E77 for ; Fri, 2 Oct 2020 02:37:31 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 4n9XiLq5f-LH for ; Fri, 2 Oct 2020 02:37:29 -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 C61573A0E3C for ; Fri, 2 Oct 2020 02:37:29 -0700 (PDT) Received: from lhreml741-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 197B330D5D65588DFAB1 for ; Fri, 2 Oct 2020 10:37:28 +0100 (IST) Received: from lhreml741-chm.china.huawei.com (10.201.108.191) by lhreml741-chm.china.huawei.com (10.201.108.191) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 2 Oct 2020 10:37:27 +0100 Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml741-chm.china.huawei.com (10.201.108.191) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Fri, 2 Oct 2020 10:37:27 +0100 Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.245]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0487.000; Fri, 2 Oct 2020 17:37:20 +0800 From: Qin Wu To: Kent Watsen CC: =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= , "netconf@ietf.org" Thread-Topic: [netconf] restconf collections Thread-Index: AdaYm18Gp6YTXWSQQdK//NJQJOxchQ== Date: Fri, 2 Oct 2020 09:37:19 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.122.121] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org 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, 02 Oct 2020 09:37:32 -0000 LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBLZW50IFdhdHNlbiBbbWFpbHRvOmtl bnQraWV0ZkB3YXRzZW4ubmV0XSANCuWPkemAgeaXtumXtDogMjAyMOW5tDEw5pyIMeaXpSAyMDoz Nw0K5pS25Lu25Lq6OiBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT4NCuaKhOmAgTogTWFydGlu IEJqw7Zya2x1bmQgPG1iaitpZXRmQDQ2Njguc2U+OyBuZXRjb25mQGlldGYub3JnDQrkuLvpopg6 IFJlOiBbbmV0Y29uZl0gcmVzdGNvbmYgY29sbGVjdGlvbnMNCg0KSGkgUWluLA0KDQo+IFNvbWUg b3BzdGF0ZSBtdXN0IGJlIHBlcnNpc3RlZCwgZS5nLiwgbG9uZy1saXZlZCBjb3VudGVycywgbG9n cywgZXRjLiwgYnV0IGl04oCZcyBhIGdvb2QgcG9pbnQgYWJvdXQgb3RoZXIgb3BzdGF0ZSBub3Qg YmVpbmcgcGVyc2lzdGVkLiAgIFBlcmhhcHMg4oCcbm9kZS10YWdz4oCdIGNhbiBiZSB1c2VkIGhl cmUsIHRvIGRpZmZlcmVudGlhdGUgd2hpY2ggaXMgd2hpY2jigKZhbmQgc2VydmVycyBjYW4gaW5k aWNhdGUgaWYvaG93IHRoZXkgc3VwcG9ydCB0aGUgZXBoZW1lcmFsIG9wc3RhdGUgbGVhZnMgaW4g cXVlcmllcz8NCj4gDQo+IFtRaW5dOlRoYXQncyBhIGdvb2QgY2FzZSBmb3Igbm9kZSB0YWcsIGlu IGVhcmxpZXIgZGlzY3Vzc2lvbiwgd2UgZGlzY3Vzc2VkIG9wZXJhdGlvbiB0eXBlLCB3aGljaCBk aXN0aW5ndWlzaHMgY3VtdWxhdGl2ZSBzdGF0aXN0aWNzIHZhbHVlIGZyb20gY3VycmVudCB2YWx1 ZS4gVGhlIGNhc2UgZGlzY3Vzc2VkIGhlcmUgaXMgdmVyeSBjbG9zZSB0byBvcGVyYXRpb24gdHlw ZSBwcm9wb3NhbCBkaXNjdXNzZWQgZWFybGllci4NCg0KWWVzLiAgVGhhbmsgeW91IGZvciBwb2lu dGluZyB0aGF0IG91dC4gIEkgbWVhbnQgdG8gbWFrZSB0aGUgc2FtZSBvYnNlcnZhdGlvbiBiZWZv cmUuICBJbmRlZWQsIHN1Y2ggbm9kZS10YWdzIGNvdWxkIGhhdmUgZHVhbC1wdXJwb3NlOiB0byBn dWlkZSBhIHN0cmVhbWluZy1zdHJhdGVneSBhbmQgYSBxdWVyeWluZy1zdHJhdGVneSBmb3IgY2Vy dGFpbiBub2Rlcy4NCg0KW1Fpbl06SW4gdGhpcyBjYXNlLCBkbyB5b3UgdGhpbmsgb3JpZ2luIG1l dGFkYXRhIGFubm90YXRpb24gaW4gUkZDODM0MiBjYW4gYmUgcmV1c2VkLCBlLmcuLCB1c2luZyAn b3I6b3JpZ2luID0gb3I6ZHluYW1pYycgdG8gaW5kaWNhdGUgZXBoZW1lcmFsIG9wc3RhdGU/IG9y IHlvdSB0aGluayAnbGlzdCcgc3BlY2lmaWMgbm9kZSB0YWcgaXMgc3RpbGwgbmVlZGVkIHRvIGlu ZGljYXRlIHNlcnZlciBzcGVjaWZpYyBjYXBhYmlsaXR5PyBFLmcuLCBleHBvc2UgREIgcmVsYXRl ZCBjYXBhYmlsaXR5IG9yIGZlYXR1cmVzPw0KTm90ZSB0aGF0IG5vZGUgdGFnIHdlIHByb3Bvc2Vk IGlzIG5vdCBtZXRhZGF0YSBhbm5vdGF0aW9uIGV4dGVuc2lvbi4NCg0KPiBOb3RlIHN1cmUgaG93 IG90aGVycyBmZWVsIGFib3V0IOKAnGRpcmVjdGlvbjogKGMpLCBidXQgbXkgcHJpbWFyeSB1c2Ut Y2FzZSByZXZvbHZlcyBhcm91bmQgdGltZS1zZXJpZXMgZGF0YSAoZS5nLiwgbG9ncyksIHdoZXJl IHRoZSBpbnRlcmVzdCBpcyBjb21tb25seSBvbiB0aGUgbW9zdC1yZWNlbnQgZW50cmllcywgc28g InJldmVyc2UtLT5vZmZzZXTigJQ+bGltaXTigJ0gd29ya3MgbmljZWx5LiAgDQo+IA0KPiBQZXJo YXBzIGFuIGFsdGVybmF0aXZlIHdvdWxkIGJlIHRvIGxpZnQgYSBjb25jZXB0IGZyb20gUHl0aG9u IHdpdGggbmVnYXRpdmUgaW5kZXhlcyBzbywgZm9yIGluc3RhbmNlLCBvZmZzZXQ9LU4gYW5kIGxp bWl0PS1OIGdpdmVzIHRoZSBsYXN0IE4gZW50cmllcz8NCj4gW1Fpbl06IFllcywgdGhhdCdzIHdo YXQgSSB0aG91Z2h0IGFzIHdlbGwsIHdpdGggbmVnYXRpdmUgaW5kZXhlcywgKGIpIGFuZCAoYykg c2VlbXMgdG8gbWUsIGNhbiBiZSBjb21iaW5lZC4NCg0KQ2FuIG90aGVycyBjb21tZW50IG9uIHRo aXM/DQoNClByZXN1bWFibHksIHdlIGNvdWxkIGVsaW1pbmF0ZSDigJxkaXJlY3Rpb27igJ0gKGMp IHdpdGggdGhpcyBhcHByb2FjaC4gIA0KDQpXaXRob3V0IOKAnGRpcmVjdGlvbuKAnSwgSSB0aGlu ayB0aGF0IFVJcyBjYW4gc3RpbGwgc3VwcG9ydCB0aGUgYWJpbGl0eSB0byBkbyBjb2x1bW4tc29y dHMsIHdoZXJlYnkgdGhlIHVzZXIgY2xpY2tzIG9uIGEgY29sdW1u4oCZcyBoZWFkZXIgdG8gdG9n Z2xlIGFzY2VuZGluZyB2cy4gZGVzY2VuZGluZyBwcmVzZW50YXRpb24sIGJ1dCB0aGV54oCZbGwg aGF2ZSB0byBkbyBpdCBjbGllbnQtc2lkZS4NCg0KVGhhdCBpcywgaWYgd2FudGluZyB0byBzZWUg dGhlIDJuZCBwYWdlIG9mIHJlc3VsdHMgc29ydGVkIGJ5IGEgY29sdW1uLCBzb21ldGhpbmcgbGlr ZToNCg0KCXNvcnQoY29sdW1uLW5hbWUpIC0tPiBvZmZzZXQoLTIqcGFnZXNpemUpIC0tPiBsaW1p dChwYWdlc2l6ZSkNCg0KRm9sbG93ZWQgYnkgdGhlIGNsaWVudCB0aGVuIGZsaXBwaW5nIHRoZSBy ZXN1bHRzIHRvIHByZXNlbnQgdGhlIHJlc3VsdHMgaW4gdGhlIHVzZXItc2VsZWN0ZWQgb3JkZXIs IHJpZ2h0Pw0KW1Fpbl06IFllcy4NClRoYXQgc2FpZCwgZ2l2ZW4gdGhhdCBEQi1iYWNrZW5kcyB0 aGF0IHN1cHBvcnQgc29ydHMgY29tbW9ubHkgYWxzbyBzdXBwb3J0IGRpcmVjdGlvbiwgaXQncyB1 bmNsZWFyIHdoYXQgdGhpcyBidXlzIHVzLg0KDQoNCj4+PiBTdXJlLCBidXQgSSB3b25kZXIgaWYs IGUuZy4sIGEgbmV0bWFzayBmaWx0ZXIsIGlzIHN1cHBvcnRhYmxlIGJ5IA0KPj4+IGNvbW1vbiBE Qi1iYWNrZW5kcy4gIEnigJltIGhvcGluZyB3ZSBoYXZlIHNvbWUgREItZXhwZXJ0cyBvbiB0aGUg bGlzdCENCj4+IA0KPj4gU2VlIGFib3ZlLiAgSXQgY2FuIGJlIHF1aXRlIGVmZmljaWVudCBldmVu IGlmIHRoZSBiYWNrZW5kIGRvZXNuJ3QgDQo+PiBzdXBwb3J0IGl0Lg0KPiANCj4gSSBkb27igJl0 IHNlZSB0aGF0IGFib3ZlLCBidXQgSSBkb27igJl0IGRvdWJ0IHRoYXQgaXQgY2FuIGJlIHNvLCBp dOKAmXMganVzdCBhIHdob2xlIGxvdCBvZiBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5LiAgSXQg c2VlbXMgdGhhdCB3ZSBzaG91bGQvbXVzdCBzdXBwb3J0IHNlcnZlcnMgZG9pbmcgaXQsIHdlIGp1 c3QgbmVlZCB0byBmaW5kIGEgd2F5IChub2RlLXRhZ3M/KSB0byBlbmFibGUgdGhlbSB0byBleHBy ZXNzIHRoYXQgYWJpbGl0eS4NCj4gW1Fpbl06IE15IGZlZWxpbmcgaXMgdGhpcyBlZmZpY2llbmN5 IG1vcmUgZGVwZW5kcyBvbiB0aGUgYW1vdW50IG9mIGRhdGEgd2UgbmVlZCB0byByZXF1ZXN0LiBJ ZiBhbW91bnQgb2YgZGF0YSB3ZSByZXF1ZXN0IGlzIGh1Z2UsIG1heWJlLCBjbGllbnQtPiBzZXJ2 ZXItPiBiYWNrZW5kIG1heSBiZSB0aGUgYmV0dGVyIGNob2ljZS4NCg0KSXMgaXQgdGhlIGFtb3Vu dCBvZiBkYXRhIHJlcXVlc3RlZCBvciB0aGUgbnVtYmVyIG9mIGVudHJpZXMgaW4gdGhlIGxpc3Q/ ICBBdCBsZWFzdCwgaW4gbXkgd29ybGR2aWV3LCBjbGllbnRzIGFyZSBhbHdheXMgcmVxdWVzdGlu ZyBhIOKAnHBhZ2XigJ0gb2YgZGF0YSwgc28gdGhhdCBwYXJ0IGlzIHJhdGhlciBjb25zaXN0ZW50 bHkgc21hbGwuDQpbUWluXTogSSB0aGluayBpdCBpcyB0aGUgbGF0dGVyLg0KSWYgdGhlIGludGVu dGlvbiBpcyB0byBnZXQgYSBjb21wbGV0ZSBkdW1wLCB0aGVuIG1heWJlIHRoZSBjb21tZW50IGZy b20geWVzdGVyZGF5IGFwcGxpZXMsIHdoZXJlYnkgc3RyZWFtaW5nIHRvIGFuIGV4dGVybmFsIHJl cG9zaXRvcnkgdGhhdCBjYW4gYmUgcXVlcmllZCBvZmZsaW5lIG1ha2VzIG1vcmUgc2Vuc2U/ICAg IC0gZXNwZWNpYWxseSBjb25zaWRlcmluZyB0aGF0IHRoZSBudW1iZXIgb2Ygb24tYm94IGxvZ3Mg aXMgbGlrZWx5IHRvIGJlIG9ubHkgdGhlIG1vc3QgcmVjZW50IChlLmcuLCBkYXlzKSwgd2hlcmVh cyB0aGUgY29tcGxldGUtZHVtcCB0eXBlIHF1ZXJpZXMgbGlrZWx5IHdpc2ggdG8gZXh0ZW5kIHdl bGwtcGFzdCB0aGF0Lg0KW1Fpbl06IEkgdGhpbmsgc3RyZWFtaW5nIHRvIGFuIGV4dGVybmFsIHJl cG9zaXRvcnkgaXMgYSBkaWZmZXJlbnQgdXNlIGNhc2UsIHdlIGRvbid0IG5lZWQgdG8gY29tcGFy ZSB3aXRoIHRoaXMgcG9sbGluZyB1c2UgY2FzZS4gdGhlIGFzc3VtcHRpb24gd2UgbWFkZSBmb3Ig cGFnaW5nLCBpcyB0aGUgY2xpZW50IGRvZXNuJ3QgaGF2ZSB0byBkZXBsb3kgZXh0ZXJuYWwgcmVw b3NpdG9yeSBmb3IgYW5vdGhlciByb3VuZCBxdWVyeS4gV2UgYXJlIGxvb2tpbmcgZm9yIG5ldHdv cmsgc2lkZSBzb2x1dGlvbiBpbmNsdWRlIGZpbHRlcmluZywgbGltaXQsIG9mZnNldCBwYXJhbWV0 ZXJzIHN1cHBvcnQuDQpLLg0KDQoNCg== From nobody Fri Oct 2 03:01:39 2020 Return-Path: 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 C2D5F3A0EF0 for ; Fri, 2 Oct 2020 03:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 RTGi7jLLLoHM for ; Fri, 2 Oct 2020 03:01:35 -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 CC0193A0F78 for ; Fri, 2 Oct 2020 03:01:34 -0700 (PDT) Received: from lhreml714-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 02931677BE54F8F9A033 for ; Fri, 2 Oct 2020 11:01:33 +0100 (IST) Received: from lhreml714-chm.china.huawei.com (10.201.108.65) by lhreml714-chm.china.huawei.com (10.201.108.65) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 2 Oct 2020 11:01:32 +0100 Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml714-chm.china.huawei.com (10.201.108.65) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Fri, 2 Oct 2020 11:01:32 +0100 Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.245]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0487.000; Fri, 2 Oct 2020 18:01:28 +0800 From: Qin Wu To: Andy Bierman , =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= CC: Netconf Thread-Topic: [netconf] restconf collections Thread-Index: AdaYobKg+bjeJP+oT1CByuaRwLyn8g== Date: Fri, 2 Oct 2020 10:01:27 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.122.121] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAADA3AA34dggeml531mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org 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, 02 Oct 2020 10:01:38 -0000 --_000_B8F9A780D330094D99AF023C5877DABAADA3AA34dggeml531mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSBmZXcgdGhvdWdodCBvbiBuZWdhdGl2ZSBvZmZzZXQuDQrlj5Hku7bkuro6IG5ldGNvbmYgW21h aWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBBbmR5IEJpZXJtYW4NCuWPkemA geaXtumXtDogMjAyMOW5tDEw5pyIMuaXpSAwOjE3DQrmlLbku7bkuro6IE1hcnRpbiBCasO2cmts dW5kIDxtYmoraWV0ZkA0NjY4LnNlPg0K5oqE6YCBOiBOZXRjb25mIDxuZXRjb25mQGlldGYub3Jn Pg0K5Li76aKYOiBSZTogW25ldGNvbmZdIHJlc3Rjb25mIGNvbGxlY3Rpb25zDQoNCg0KDQpPbiBU aHUsIE9jdCAxLCAyMDIwIGF0IDc6NTcgQU0gTWFydGluIEJqw7Zya2x1bmQgPG1iaitpZXRmQDQ2 Njguc2U8bWFpbHRvOm1iaiUyQmlldGZANDY2OC5zZT4+IHdyb3RlOg0KS2VudCBXYXRzZW4gPGtl bnQraWV0ZkB3YXRzZW4ubmV0PG1haWx0bzprZW50JTJCaWV0ZkB3YXRzZW4ubmV0Pj4gd3JvdGU6 DQo+DQo+DQo+ID4gT24gT2N0IDEsIDIwMjAsIGF0IDk6MjMgQU0sIE1hcnRpbiBCasO2cmtsdW5k IDxtYmoraWV0ZkA0NjY4LnNlPG1haWx0bzptYmolMkJpZXRmQDQ2Njguc2U+PiB3cm90ZToNCj4g Pg0KPiA+IEtlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldDxtYWlsdG86a2VudCUyQmll dGZAd2F0c2VuLm5ldD4+IHdyb3RlOg0KPiA+PiBIaSBRaW4sDQo+ID4+DQo+ID4+PiBTb21lIG9w c3RhdGUgbXVzdCBiZSBwZXJzaXN0ZWQsIGUuZy4sIGxvbmctbGl2ZWQgY291bnRlcnMsIGxvZ3Ms IGV0Yy4sDQo+ID4+PiBidXQgaXTigJlzIGEgZ29vZCBwb2ludCBhYm91dCBvdGhlciBvcHN0YXRl IG5vdCBiZWluZyBwZXJzaXN0ZWQuDQo+ID4+PiBQZXJoYXBzIOKAnG5vZGUtdGFnc+KAnSBjYW4g YmUgdXNlZCBoZXJlLCB0byBkaWZmZXJlbnRpYXRlIHdoaWNoIGlzDQo+ID4+PiB3aGljaOKApmFu ZCBzZXJ2ZXJzIGNhbiBpbmRpY2F0ZSBpZi9ob3cgdGhleSBzdXBwb3J0IHRoZSBlcGhlbWVyYWwN Cj4gPj4+IG9wc3RhdGUgbGVhZnMgaW4gcXVlcmllcz8NCj4gPj4+DQo+ID4+PiBbUWluXTpUaGF0 J3MgYSBnb29kIGNhc2UgZm9yIG5vZGUgdGFnLCBpbiBlYXJsaWVyIGRpc2N1c3Npb24sIHdlDQo+ ID4+PiBkaXNjdXNzZWQgb3BlcmF0aW9uIHR5cGUsIHdoaWNoIGRpc3Rpbmd1aXNocyBjdW11bGF0 aXZlIHN0YXRpc3RpY3MNCj4gPj4+IHZhbHVlIGZyb20gY3VycmVudCB2YWx1ZS4gVGhlIGNhc2Ug ZGlzY3Vzc2VkIGhlcmUgaXMgdmVyeSBjbG9zZSB0bw0KPiA+Pj4gb3BlcmF0aW9uIHR5cGUgcHJv cG9zYWwgZGlzY3Vzc2VkIGVhcmxpZXIuDQo+ID4+DQo+ID4+IFllcy4gIFRoYW5rIHlvdSBmb3Ig cG9pbnRpbmcgdGhhdCBvdXQuICBJIG1lYW50IHRvIG1ha2UgdGhlIHNhbWUNCj4gPj4gb2JzZXJ2 YXRpb24gYmVmb3JlLiAgSW5kZWVkLCBzdWNoIG5vZGUtdGFncyBjb3VsZCBoYXZlIGR1YWwtcHVy cG9zZToNCj4gPj4gdG8gZ3VpZGUgYSBzdHJlYW1pbmctc3RyYXRlZ3kgYW5kIGEgcXVlcnlpbmct c3RyYXRlZ3kgZm9yIGNlcnRhaW4NCj4gPj4gbm9kZXMuDQo+ID4+DQo+ID4+DQo+ID4+PiBOb3Rl IHN1cmUgaG93IG90aGVycyBmZWVsIGFib3V0IOKAnGRpcmVjdGlvbjogKGMpLCBidXQgbXkgcHJp bWFyeQ0KPiA+Pj4gdXNlLWNhc2UgcmV2b2x2ZXMgYXJvdW5kIHRpbWUtc2VyaWVzIGRhdGEgKGUu Zy4sIGxvZ3MpLCB3aGVyZSB0aGUNCj4gPj4+IGludGVyZXN0IGlzIGNvbW1vbmx5IG9uIHRoZSBt b3N0LXJlY2VudCBlbnRyaWVzLCBzbw0KPiA+Pj4gInJldmVyc2UtLT5vZmZzZXTigJQ+bGltaXTi gJ0gd29ya3MgbmljZWx5Lg0KPiA+Pj4NCj4gPj4+IFBlcmhhcHMgYW4gYWx0ZXJuYXRpdmUgd291 bGQgYmUgdG8gbGlmdCBhIGNvbmNlcHQgZnJvbSBQeXRob24gd2l0aA0KPiA+Pj4gbmVnYXRpdmUg aW5kZXhlcyBzbywgZm9yIGluc3RhbmNlLCBvZmZzZXQ9LU4gYW5kIGxpbWl0PS1OIGdpdmVzIHRo ZQ0KPiA+Pj4gbGFzdCBOIGVudHJpZXM/DQo+ID4+PiBbUWluXTogWWVzLCB0aGF0J3Mgd2hhdCBJ IHRob3VnaHQgYXMgd2VsbCwgd2l0aCBuZWdhdGl2ZSBpbmRleGVzLCAoYikNCj4gPj4+IGFuZCAo Yykgc2VlbXMgdG8gbWUsIGNhbiBiZSBjb21iaW5lZC4NCj4gPj4NCj4gPj4gQ2FuIG90aGVycyBj b21tZW50IG9uIHRoaXM/DQo+ID4NCj4gPiBJc24ndCB0aGlzIGp1c3QgYW5vdGhlciBzeW50YXgg Zm9yIHRoZSBzYW1lIGZ1bmN0aW9uPw0KPg0KPiBObywgaXQgaXMgbm90Lg0KDQpIb3cgc28/ICBJ c24ndCB0aGUgaWRlYSB0aGF0IHlvdSBjYW4gZmlyc3QgYXNrIGZvciBvZmZzZXQ9LTEwLCB0aGVu DQotMjAsIGV0YywgZXNzZW50aWFsbHkgd2Fsa2luZyB0aGUgbGlzdCBiYWNrd2FyZHM/ICAoSSBk b24ndCB1bmRlcnN0YW5kDQp3aGF0IGEgbmVnYXRpdmUgbGltaXQgbWVhbnMgdGhvdWdoKS4NCg0K Q2FuIHNvbWVib2R5IGV4cGxhaW4gdGhlIHVzZS1jYXNlIGZvciBpdGVyYXRpbmcgYSBsaXN0IGJh Y2t3YXJkcz8NCltRaW5dOiBTZWUgZGlzY3Vzc2lvbiB3aXRoIFJvYmVydA0KaHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9uZXRjb25mL3lSdFdnRGU3UFVVem5TdkZUdmhMWW83 UHBLNC8NCkkgZmVlbCBpZiB0aGUgY2xpZW50IGNhbiByZW1lbWJlciB0aGUgbGFzdCBlbGVtZW50 IGhlIHJlcXVlc3QsIGhlIGNhbiB1c2UgdGhlIGxhc3QgZWxlbWVudCBhcyBjdXJzb3IgYW5jaG9y IHBvaW50DQpBbmQgaXRlcmF0ZSBhIGxpc3QgYmFja3dhcmRzIGJ5IHNlbmRpbmcgdGhlIHNlY29u ZCBwYWdpbmF0ZSByZXF1ZXN0IHdpdGggbmVnYXRpdmUgb2Zmc2V0Lg0KVGhlIGFzc3VtcHRpb24g Zm9yIHRoZSBzZXJ2ZXIgaXMgdGhlIHNlcnZlciBzaG91bGQgcHJvdmlkZSBzbmFwc2hvdCBmb3Ig YWxsIHRoZSBwYWdpbmcgZGF0YSBzdG9yZWQgc29tZXdoZXJlLg0KUmVseWluZyBvbiBEQj8NCk5v IGN1c3RvbWVyIGhhcyBldmVyIGFza2VkIGZvciB0aGlzIHNvIEkgYW0gd29uZGVyaW5nIHdoYXQg d2UgYXJlIGFsbCBtaXNzaW5nLg0KW1Fpbl06IFllcywgYWxsIG91ciBjdXJyZW50IGN1c3RvbWVy IGFzayBmb3IgbGlzdCBmb3J3YXJkcyBjYXBhYmlsaXR5Lg0KDQpJIGd1ZXNzIGl0IGlzbid0IGNs ZWFyIHRoYXQgb2Zmc2V0cyBkbyBub3Qgd29yayBmb3IgbGlzdHMgd2hlcmUgZW50cmllcw0KYXJl IGFkZGVkIGFuZC9vciBkZWxldGVkIG92ZXIgdGltZSwNCg0KW1Fpbl06aG93IGFib3V0IGxvY2sg Y29uZmlndXJhdGlvbiBiZWZvcmUgc2VuZGluZyBwYWdpbmcgcmVxdWVzdD8NCnVubGVzcyBsb3Rz IG9mIHN0YXRlIGlzIGtlcHQgYnkgdGhlIHNlcnZlci4NCkkgZ3Vlc3MgaWYgeW91IGFyZSBsb29r aW5nIGZvciB0aGUgbW9zdCBleHBlbnNpdmUgaGVhdnl3ZWlnaHQgc29sdXRpb24gcG9zc2libGUN CnRoZW4gdGhpcyBpcyBhIGdvb2Qgc3RhcnQuDQoNCg0KDQovbWFydGluDQoNCkFuZHkNCg0KDQoN Cj4NCj4gSy4NCj4NCj4NCj4gPg0KPiA+IC9tYXJ0aW4NCj4gPg0KPiA+DQo+ID4+IFByZXN1bWFi bHksIHdlIGNvdWxkIGVsaW1pbmF0ZSDigJxkaXJlY3Rpb27igJ0gKGMpIHdpdGggdGhpcyBhcHBy b2FjaC4NCj4gPj4NCj4gPj4gV2l0aG91dCDigJxkaXJlY3Rpb27igJ0sIEkgdGhpbmsgdGhhdCBV SXMgY2FuIHN0aWxsIHN1cHBvcnQgdGhlIGFiaWxpdHkgdG8NCj4gPj4gZG8gY29sdW1uLXNvcnRz LCB3aGVyZWJ5IHRoZSB1c2VyIGNsaWNrcyBvbiBhIGNvbHVtbuKAmXMgaGVhZGVyIHRvDQo+ID4+ IHRvZ2dsZSBhc2NlbmRpbmcgdnMuIGRlc2NlbmRpbmcgcHJlc2VudGF0aW9uLCBidXQgdGhleeKA mWxsIGhhdmUgdG8gZG8NCj4gPj4gaXQgY2xpZW50LXNpZGUuDQo+ID4+DQo+ID4+IFRoYXQgaXMs IGlmIHdhbnRpbmcgdG8gc2VlIHRoZSAybmQgcGFnZSBvZiByZXN1bHRzIHNvcnRlZCBieSBhIGNv bHVtbiwNCj4gPj4gc29tZXRoaW5nIGxpa2U6DQo+ID4+DQo+ID4+ICAgIHNvcnQoY29sdW1uLW5h bWUpIC0tPiBvZmZzZXQoLTIqcGFnZXNpemUpIC0tPiBsaW1pdChwYWdlc2l6ZSkNCj4gPj4NCj4g Pj4gRm9sbG93ZWQgYnkgdGhlIGNsaWVudCB0aGVuIGZsaXBwaW5nIHRoZSByZXN1bHRzIHRvIHBy ZXNlbnQgdGhlDQo+ID4+IHJlc3VsdHMgaW4gdGhlIHVzZXItc2VsZWN0ZWQgb3JkZXIsIHJpZ2h0 Pw0KPiA+Pg0KPiA+PiBUaGF0IHNhaWQsIGdpdmVuIHRoYXQgREItYmFja2VuZHMgdGhhdCBzdXBw b3J0IHNvcnRzIGNvbW1vbmx5IGFsc28NCj4gPj4gc3VwcG9ydCBkaXJlY3Rpb24sIGl0J3MgdW5j bGVhciB3aGF0IHRoaXMgYnV5cyB1cy4NCj4gPj4NCj4gPj4NCj4gPj4+Pj4gU3VyZSwgYnV0IEkg d29uZGVyIGlmLCBlLmcuLCBhIG5ldG1hc2sgZmlsdGVyLCBpcyBzdXBwb3J0YWJsZSBieQ0KPiA+ Pj4+PiBjb21tb24gREItYmFja2VuZHMuICBJ4oCZbSBob3Bpbmcgd2UgaGF2ZSBzb21lIERCLWV4 cGVydHMgb24gdGhlIGxpc3QhDQo+ID4+Pj4NCj4gPj4+PiBTZWUgYWJvdmUuICBJdCBjYW4gYmUg cXVpdGUgZWZmaWNpZW50IGV2ZW4gaWYgdGhlIGJhY2tlbmQgZG9lc24ndA0KPiA+Pj4+IHN1cHBv cnQgaXQuDQo+ID4+Pg0KPiA+Pj4gSSBkb27igJl0IHNlZSB0aGF0IGFib3ZlLCBidXQgSSBkb27i gJl0IGRvdWJ0IHRoYXQgaXQgY2FuIGJlIHNvLCBpdOKAmXMganVzdA0KPiA+Pj4gYSB3aG9sZSBs b3Qgb2YgaW1wbGVtZW50YXRpb24gY29tcGxleGl0eS4gIEl0IHNlZW1zIHRoYXQgd2UNCj4gPj4+ IHNob3VsZC9tdXN0IHN1cHBvcnQgc2VydmVycyBkb2luZyBpdCwgd2UganVzdCBuZWVkIHRvIGZp bmQgYSB3YXkNCj4gPj4+IChub2RlLXRhZ3M/KSB0byBlbmFibGUgdGhlbSB0byBleHByZXNzIHRo YXQgYWJpbGl0eS4NCj4gPj4+IFtRaW5dOiBNeSBmZWVsaW5nIGlzIHRoaXMgZWZmaWNpZW5jeSBt b3JlIGRlcGVuZHMgb24gdGhlIGFtb3VudCBvZg0KPiA+Pj4gZGF0YSB3ZSBuZWVkIHRvIHJlcXVl c3QuIElmIGFtb3VudCBvZiBkYXRhIHdlIHJlcXVlc3QgaXMgaHVnZSwgbWF5YmUsDQo+ID4+PiBj bGllbnQtPiBzZXJ2ZXItPiBiYWNrZW5kIG1heSBiZSB0aGUgYmV0dGVyIGNob2ljZS4NCj4gPj4N Cj4gPj4gSXMgaXQgdGhlIGFtb3VudCBvZiBkYXRhIHJlcXVlc3RlZCBvciB0aGUgbnVtYmVyIG9m IGVudHJpZXMgaW4gdGhlDQo+ID4+IGxpc3Q/ICBBdCBsZWFzdCwgaW4gbXkgd29ybGR2aWV3LCBj bGllbnRzIGFyZSBhbHdheXMgcmVxdWVzdGluZyBhDQo+ID4+IOKAnHBhZ2XigJ0gb2YgZGF0YSwg c28gdGhhdCBwYXJ0IGlzIHJhdGhlciBjb25zaXN0ZW50bHkgc21hbGwuDQo+ID4+DQo+ID4+IElm IHRoZSBpbnRlbnRpb24gaXMgdG8gZ2V0IGEgY29tcGxldGUgZHVtcCwgdGhlbiBtYXliZSB0aGUg Y29tbWVudA0KPiA+PiBmcm9tIHllc3RlcmRheSBhcHBsaWVzLCB3aGVyZWJ5IHN0cmVhbWluZyB0 byBhbiBleHRlcm5hbCByZXBvc2l0b3J5DQo+ID4+IHRoYXQgY2FuIGJlIHF1ZXJpZWQgb2ZmbGlu ZSBtYWtlcyBtb3JlIHNlbnNlPyAgLSBlc3BlY2lhbGx5DQo+ID4+IGNvbnNpZGVyaW5nIHRoYXQg dGhlIG51bWJlciBvZiBvbi1ib3ggbG9ncyBpcyBsaWtlbHkgdG8gYmUgb25seSB0aGUNCj4gPj4g bW9zdCByZWNlbnQgKGUuZy4sIGRheXMpLCB3aGVyZWFzIHRoZSBjb21wbGV0ZS1kdW1wIHR5cGUg cXVlcmllcw0KPiA+PiBsaWtlbHkgd2lzaCB0byBleHRlbmQgd2VsbC1wYXN0IHRoYXQuDQo+ID4+ DQo+ID4+IEsuDQo+ID4+DQo+ID4+DQo+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KbmV0Y29uZiBtYWlsaW5nIGxpc3QNCm5ldGNvbmZAaWV0Zi5vcmc8 bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldGNvbmYNCg== --_000_B8F9A780D330094D99AF023C5877DABAADA3AA34dggeml531mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTsN CglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4w cHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkEgZmV3IHRob3VnaHQg b24gbmVnYXRpdmUgb2Zmc2V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1V UyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+ IG5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddDQo8L3NwYW4+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buR JnF1b3Q7LHNhbnMtc2VyaWYiPuS7o+ihqCA8L3NwYW4+DQo8L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx dW90OyxzYW5zLXNlcmlmIj5BbmR5IEJpZXJtYW48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNh bnMtc2VyaWYiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj4gMjAyMDwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVv dDssc2Fucy1zZXJpZiI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjEwPC9zcGFuPuaciDxzcGFuIGxh bmc9IkVOLVVTIj4yPC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4NCiAwOjE3PGJyPg0KPC9z cGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyI+IE1hcnRpbiBCasO2cmtsdW5kICZsdDttYmomIzQzO2lldGZANDY2OC5zZSZndDs8 YnI+DQo8L3NwYW4+PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIj4gTmV0Y29uZiAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+DQo8L3Nw YW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIj4gUmU6IFtuZXRjb25mXSByZXN0Y29uZiBjb2xsZWN0aW9uczxvOnA+PC9vOnA+PC9zcGFu Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+T24gVGh1LCBPY3QgMSwgMjAyMCBhdCA3OjU3IEFNIE1hcnRpbiBCasO2 cmtsdW5kICZsdDs8YSBocmVmPSJtYWlsdG86bWJqJTJCaWV0ZkA0NjY4LnNlIj5tYmomIzQzO2ll dGZANDY2OC5zZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPktlbnQgV2F0c2VuICZsdDs8YSBocmVmPSJtYWlsdG86 a2VudCUyQmlldGZAd2F0c2VuLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmtlbnQmIzQzO2lldGZAd2F0 c2VuLm5ldDwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZn dDsgT24gT2N0IDEsIDIwMjAsIGF0IDk6MjMgQU0sIE1hcnRpbiBCasO2cmtsdW5kICZsdDs8YSBo cmVmPSJtYWlsdG86bWJqJTJCaWV0ZkA0NjY4LnNlIiB0YXJnZXQ9Il9ibGFuayI+bWJqJiM0Mztp ZXRmQDQ2Njguc2U8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 IEtlbnQgV2F0c2VuICZsdDs8YSBocmVmPSJtYWlsdG86a2VudCUyQmlldGZAd2F0c2VuLm5ldCIg dGFyZ2V0PSJfYmxhbmsiPmtlbnQmIzQzO2lldGZAd2F0c2VuLm5ldDwvYT4mZ3Q7IHdyb3RlOjxi cj4NCiZndDsgJmd0OyZndDsgSGkgUWluLDxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsgU29tZSBvcHN0YXRlIG11c3QgYmUgcGVyc2lzdGVkLCBlLmcuLCBsb25nLWxp dmVkIGNvdW50ZXJzLCBsb2dzLCBldGMuLDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IGJ1dCBpdOKA mXMgYSBnb29kIHBvaW50IGFib3V0IG90aGVyIG9wc3RhdGUgbm90IGJlaW5nIHBlcnNpc3RlZC48 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBQZXJoYXBzIOKAnG5vZGUtdGFnc+KAnSBjYW4gYmUgdXNl ZCBoZXJlLCB0byBkaWZmZXJlbnRpYXRlIHdoaWNoIGlzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsg d2hpY2jigKZhbmQgc2VydmVycyBjYW4gaW5kaWNhdGUgaWYvaG93IHRoZXkgc3VwcG9ydCB0aGUg ZXBoZW1lcmFsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgb3BzdGF0ZSBsZWFmcyBpbiBxdWVyaWVz Pzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IFtRaW5dOlRo YXQncyBhIGdvb2QgY2FzZSBmb3Igbm9kZSB0YWcsIGluIGVhcmxpZXIgZGlzY3Vzc2lvbiwgd2U8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBkaXNjdXNzZWQgb3BlcmF0aW9uIHR5cGUsIHdoaWNoIGRp c3Rpbmd1aXNocyBjdW11bGF0aXZlIHN0YXRpc3RpY3M8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyB2 YWx1ZSBmcm9tIGN1cnJlbnQgdmFsdWUuIFRoZSBjYXNlIGRpc2N1c3NlZCBoZXJlIGlzIHZlcnkg Y2xvc2UgdG88YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBvcGVyYXRpb24gdHlwZSBwcm9wb3NhbCBk aXNjdXNzZWQgZWFybGllci48YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsg WWVzLiZuYnNwOyBUaGFuayB5b3UgZm9yIHBvaW50aW5nIHRoYXQgb3V0LiZuYnNwOyBJIG1lYW50 IHRvIG1ha2UgdGhlIHNhbWU8YnI+DQomZ3Q7ICZndDsmZ3Q7IG9ic2VydmF0aW9uIGJlZm9yZS4m bmJzcDsgSW5kZWVkLCBzdWNoIG5vZGUtdGFncyBjb3VsZCBoYXZlIGR1YWwtcHVycG9zZTo8YnI+ DQomZ3Q7ICZndDsmZ3Q7IHRvIGd1aWRlIGEgc3RyZWFtaW5nLXN0cmF0ZWd5IGFuZCBhIHF1ZXJ5 aW5nLXN0cmF0ZWd5IGZvciBjZXJ0YWluPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBub2Rlcy48YnI+DQom Z3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsg Tm90ZSBzdXJlIGhvdyBvdGhlcnMgZmVlbCBhYm91dCDigJxkaXJlY3Rpb246IChjKSwgYnV0IG15 IHByaW1hcnk8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyB1c2UtY2FzZSByZXZvbHZlcyBhcm91bmQg dGltZS1zZXJpZXMgZGF0YSAoZS5nLiwgbG9ncyksIHdoZXJlIHRoZTxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7IGludGVyZXN0IGlzIGNvbW1vbmx5IG9uIHRoZSBtb3N0LXJlY2VudCBlbnRyaWVzLCBz bzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7ICZxdW90O3JldmVyc2UtLSZndDtvZmZzZXTigJQmZ3Q7 bGltaXTigJ0gd29ya3MgbmljZWx5Ljxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7IFBlcmhhcHMgYW4gYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8gbGlmdCBhIGNv bmNlcHQgZnJvbSBQeXRob24gd2l0aDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IG5lZ2F0aXZlIGlu ZGV4ZXMgc28sIGZvciBpbnN0YW5jZSwgb2Zmc2V0PS1OIGFuZCBsaW1pdD0tTiBnaXZlcyB0aGU8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBsYXN0IE4gZW50cmllcz88YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyBbUWluXTogWWVzLCB0aGF0J3Mgd2hhdCBJIHRob3VnaHQgYXMgd2VsbCwgd2l0aCBuZWdh dGl2ZSBpbmRleGVzLCAoYik8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBhbmQgKGMpIHNlZW1zIHRv IG1lLCBjYW4gYmUgY29tYmluZWQuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsm Z3Q7IENhbiBvdGhlcnMgY29tbWVudCBvbiB0aGlzPzxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgSXNuJ3QgdGhpcyBqdXN0IGFub3RoZXIgc3ludGF4IGZvciB0aGUgc2FtZSBmdW5jdGlv bj88YnI+DQomZ3Q7IDxicj4NCiZndDsgTm8sIGl0IGlzIG5vdC48YnI+DQo8YnI+DQpIb3cgc28/ Jm5ic3A7IElzbid0IHRoZSBpZGVhIHRoYXQgeW91IGNhbiBmaXJzdCBhc2sgZm9yIG9mZnNldD0t MTAsIHRoZW48YnI+DQotMjAsIGV0YywgZXNzZW50aWFsbHkgd2Fsa2luZyB0aGUgbGlzdCBiYWNr d2FyZHM/Jm5ic3A7IChJIGRvbid0IHVuZGVyc3RhbmQ8YnI+DQp3aGF0IGEgbmVnYXRpdmUgbGlt aXQgbWVhbnMgdGhvdWdoKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5DYW4gc29tZWJvZHkgZXhwbGFpbiB0aGUgdXNlLWNhc2UgZm9yIGl0 ZXJhdGluZyBhIGxpc3QgYmFja3dhcmRzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ W1Fpbl06IFNlZSBkaXNjdXNzaW9uIHdpdGggUm9iZXJ0PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL25l dGNvbmYveVJ0V2dEZTdQVVV6blN2RlR2aExZbzdQcEs0LyI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5p ZXRmLm9yZy9hcmNoL21zZy9uZXRjb25mL3lSdFdnRGU3UFVVem5TdkZUdmhMWW83UHBLNC88L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGZlZWwgaWYgdGhlIGNsaWVudCBjYW4g cmVtZW1iZXIgdGhlIGxhc3QgZWxlbWVudCBoZSByZXF1ZXN0LCBoZSBjYW4gdXNlIHRoZSBsYXN0 IGVsZW1lbnQgYXMgY3Vyc29yIGFuY2hvciBwb2ludDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+QW5kIGl0ZXJhdGUgYSBsaXN0IGJhY2t3YXJkcyBieSBzZW5kaW5nIHRoZSBzZWNvbmQg cGFnaW5hdGUgcmVxdWVzdCB3aXRoIG5lZ2F0aXZlIG9mZnNldC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlRoZSBhc3N1bXB0aW9uIGZvciB0aGUgc2VydmVyIGlzIHRoZSBzZXJ2ZXIg c2hvdWxkIHByb3ZpZGUgc25hcHNob3QgZm9yIGFsbCB0aGUgcGFnaW5nIGRhdGEgc3RvcmVkIHNv bWV3aGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlbHlpbmcgb24gREI/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPk5vIGN1c3RvbWVyIGhhcyBldmVyIGFza2VkIGZvciB0aGlzIHNv IEkgYW0gd29uZGVyaW5nIHdoYXQgd2UgYXJlIGFsbCBtaXNzaW5nLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1Fpbl06IFllcywgYWxsIG91ciBjdXJyZW50 IGN1c3RvbWVyIGFzayBmb3IgbGlzdCBmb3J3YXJkcyBjYXBhYmlsaXR5LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgZ3Vlc3MgaXQg aXNuJ3QgY2xlYXIgdGhhdCBvZmZzZXRzIGRvIG5vdCB3b3JrIGZvciBsaXN0cyB3aGVyZSBlbnRy aWVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmFyZSBhZGRlZCBhbmQvb3IgZGVsZXRlZCBvdmVyIHRp bWUsIDxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1Fp bl06aG93IGFib3V0IGxvY2sgY29uZmlndXJhdGlvbiBiZWZvcmUgc2VuZGluZyBwYWdpbmcgcmVx dWVzdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+dW5sZXNzIGxvdHMgb2Ygc3RhdGUgaXMga2VwdCBieSB0aGUgc2VydmVyLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5JIGd1ZXNzIGlmIHlvdSBhcmUgbG9va2luZyBmb3IgdGhlIG1v c3QgZXhwZW5zaXZlIGhlYXZ5d2VpZ2h0IHNvbHV0aW9uIHBvc3NpYmxlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPnRoZW4gdGhpcyBpcyBhIGdvb2Qgc3RhcnQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PGJyPg0KL21hcnRpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkFuZHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBLLjxicj4NCiZn dDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IC9tYXJ0aW48YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgUHJlc3VtYWJs eSwgd2UgY291bGQgZWxpbWluYXRlIOKAnGRpcmVjdGlvbuKAnSAoYykgd2l0aCB0aGlzIGFwcHJv YWNoLiZuYnNwOyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgV2l0aG91 dCDigJxkaXJlY3Rpb27igJ0sIEkgdGhpbmsgdGhhdCBVSXMgY2FuIHN0aWxsIHN1cHBvcnQgdGhl IGFiaWxpdHkgdG88YnI+DQomZ3Q7ICZndDsmZ3Q7IGRvIGNvbHVtbi1zb3J0cywgd2hlcmVieSB0 aGUgdXNlciBjbGlja3Mgb24gYSBjb2x1bW7igJlzIGhlYWRlciB0bzxicj4NCiZndDsgJmd0OyZn dDsgdG9nZ2xlIGFzY2VuZGluZyB2cy4gZGVzY2VuZGluZyBwcmVzZW50YXRpb24sIGJ1dCB0aGV5 4oCZbGwgaGF2ZSB0byBkbzxicj4NCiZndDsgJmd0OyZndDsgaXQgY2xpZW50LXNpZGUuPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IFRoYXQgaXMsIGlmIHdhbnRpbmcgdG8g c2VlIHRoZSAybmQgcGFnZSBvZiByZXN1bHRzIHNvcnRlZCBieSBhIGNvbHVtbiw8YnI+DQomZ3Q7 ICZndDsmZ3Q7IHNvbWV0aGluZyBsaWtlOjxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZuYnNwOyAmbmJzcDsgc29ydChjb2x1bW4tbmFtZSkgLS0mZ3Q7IG9mZnNldCgtMipw YWdlc2l6ZSkgLS0mZ3Q7IGxpbWl0KHBhZ2VzaXplKTxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyBGb2xsb3dlZCBieSB0aGUgY2xpZW50IHRoZW4gZmxpcHBpbmcgdGhlIHJl c3VsdHMgdG8gcHJlc2VudCB0aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7IHJlc3VsdHMgaW4gdGhlIHVz ZXItc2VsZWN0ZWQgb3JkZXIsIHJpZ2h0Pzxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAm Z3Q7Jmd0OyBUaGF0IHNhaWQsIGdpdmVuIHRoYXQgREItYmFja2VuZHMgdGhhdCBzdXBwb3J0IHNv cnRzIGNvbW1vbmx5IGFsc288YnI+DQomZ3Q7ICZndDsmZ3Q7IHN1cHBvcnQgZGlyZWN0aW9uLCBp dCdzIHVuY2xlYXIgd2hhdCB0aGlzIGJ1eXMgdXMuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQom Z3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgU3VyZSwgYnV0IEkg d29uZGVyIGlmLCBlLmcuLCBhIG5ldG1hc2sgZmlsdGVyLCBpcyBzdXBwb3J0YWJsZSBieSA8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbW1vbiBEQi1iYWNrZW5kcy4mbmJzcDsgSeKA mW0gaG9waW5nIHdlIGhhdmUgc29tZSBEQi1leHBlcnRzIG9uIHRoZSBsaXN0ITxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgU2VlIGFib3ZlLiZu YnNwOyBJdCBjYW4gYmUgcXVpdGUgZWZmaWNpZW50IGV2ZW4gaWYgdGhlIGJhY2tlbmQgZG9lc24n dCA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgc3VwcG9ydCBpdC48YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBJIGRvbuKAmXQgc2VlIHRoYXQgYWJvdmUs IGJ1dCBJIGRvbuKAmXQgZG91YnQgdGhhdCBpdCBjYW4gYmUgc28sIGl04oCZcyBqdXN0PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsgYSB3aG9sZSBsb3Qgb2YgaW1wbGVtZW50YXRpb24gY29tcGxleGl0 eS4mbmJzcDsgSXQgc2VlbXMgdGhhdCB3ZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IHNob3VsZC9t dXN0IHN1cHBvcnQgc2VydmVycyBkb2luZyBpdCwgd2UganVzdCBuZWVkIHRvIGZpbmQgYSB3YXk8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyAobm9kZS10YWdzPykgdG8gZW5hYmxlIHRoZW0gdG8gZXhw cmVzcyB0aGF0IGFiaWxpdHkuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgW1Fpbl06IE15IGZlZWxp bmcgaXMgdGhpcyBlZmZpY2llbmN5IG1vcmUgZGVwZW5kcyBvbiB0aGUgYW1vdW50IG9mPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsgZGF0YSB3ZSBuZWVkIHRvIHJlcXVlc3QuIElmIGFtb3VudCBvZiBk YXRhIHdlIHJlcXVlc3QgaXMgaHVnZSwgbWF5YmUsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgY2xp ZW50LSZndDsgc2VydmVyLSZndDsgYmFja2VuZCBtYXkgYmUgdGhlIGJldHRlciBjaG9pY2UuPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IElzIGl0IHRoZSBhbW91bnQgb2Yg ZGF0YSByZXF1ZXN0ZWQgb3IgdGhlIG51bWJlciBvZiBlbnRyaWVzIGluIHRoZTxicj4NCiZndDsg Jmd0OyZndDsgbGlzdD8mbmJzcDsgQXQgbGVhc3QsIGluIG15IHdvcmxkdmlldywgY2xpZW50cyBh cmUgYWx3YXlzIHJlcXVlc3RpbmcgYTxicj4NCiZndDsgJmd0OyZndDsg4oCccGFnZeKAnSBvZiBk YXRhLCBzbyB0aGF0IHBhcnQgaXMgcmF0aGVyIGNvbnNpc3RlbnRseSBzbWFsbC48YnI+DQomZ3Q7 ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgSWYgdGhlIGludGVudGlvbiBpcyB0byBnZXQg YSBjb21wbGV0ZSBkdW1wLCB0aGVuIG1heWJlIHRoZSBjb21tZW50PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBmcm9tIHllc3RlcmRheSBhcHBsaWVzLCB3aGVyZWJ5IHN0cmVhbWluZyB0byBhbiBleHRlcm5h bCByZXBvc2l0b3J5PGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0aGF0IGNhbiBiZSBxdWVyaWVkIG9mZmxp bmUgbWFrZXMgbW9yZSBzZW5zZT8mbmJzcDsgLSBlc3BlY2lhbGx5PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBjb25zaWRlcmluZyB0aGF0IHRoZSBudW1iZXIgb2Ygb24tYm94IGxvZ3MgaXMgbGlrZWx5IHRv IGJlIG9ubHkgdGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBtb3N0IHJlY2VudCAoZS5nLiwgZGF5cyks IHdoZXJlYXMgdGhlIGNvbXBsZXRlLWR1bXAgdHlwZSBxdWVyaWVzPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBsaWtlbHkgd2lzaCB0byBleHRlbmQgd2VsbC1wYXN0IHRoYXQuPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IEsuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZn dDsmZ3Q7IDxicj4NCiZndDsgPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpuZXRjb25mIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpuZXRjb25mQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0Y29uZkBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dGNvbmYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldGNvbmY8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B8F9A780D330094D99AF023C5877DABAADA3AA34dggeml531mbschi_-- From nobody Fri Oct 2 04:20:26 2020 Return-Path: <01000174e90a9186-0a4edb66-4120-44b7-a79f-7b9935f6d48f-000000@amazonses.watsen.net> 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 E2FFA3A15C3; Fri, 2 Oct 2020 04:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 MXZxjh-F5QE4; Fri, 2 Oct 2020 04:20:22 -0700 (PDT) Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82DD23A15C1; Fri, 2 Oct 2020 04:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601637618; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=112F6c+AZZkoAf53im10KaL8T+6upaTyW03lQVNDbbc=; b=ivStbwmgNGzf5ac4tYmm1PJa9a9HgKGc1/JAmyCncLhRHqmzrr67cIIUCyy9Q4bc 7iqk0luNra/Mm5CzjYJdyamHh1DJFOG7599nKggfUk69TKl4PoV7GSfHVuUESUfpZ3C SGgpBpbQk8P4ahsDkyPd5mxJCIdPifpp8qzaaf/Y= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Kent Watsen In-Reply-To: <160107496501.14047.597283542214697710@ietfa.amsl.com> Date: Fri, 2 Oct 2020 11:20:18 +0000 Cc: secdir@ietf.org, "netconf@ietf.org" , draft-ietf-netconf-trust-anchors.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-ID: <01000174e90a9186-0a4edb66-4120-44b7-a79f-7b9935f6d48f-000000@email.amazonses.com> References: <160107496501.14047.597283542214697710@ietfa.amsl.com> To: Yoav Nir X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.10.02-54.240.48.94 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] [Last-Call] Secdir last call review of draft-ietf-netconf-trust-anchors-13 X-BeenThere: netconf@ietf.org 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, 02 Oct 2020 11:20:24 -0000 [-last-call] Hi Yoav, Thank you for your review! The takeaway for me is that some = clarifications are needed, but otherwise the draft is fundamentally = okay. I will post an update, or perhaps just a GitHub commit, for your = review, when I get a chance. That said, my getting a chance will be = delayed as I have a major engagement I need to focus on now. This email = is just to let you know that your review has not been forgotten. Thanks again, Kent > On Sep 25, 2020, at 7:02 PM, Yoav Nir via Datatracker = wrote: >=20 > Reviewer: Yoav Nir > Review result: Has Issues >=20 > I have reviewed this document as part of the security directorate's = ongoing > effort to review all IETF documents being processed by the IESG. = These > comments were written primarily for the benefit of the security area = directors. > Document editors and WG chairs should treat these comments just like = any other > last call comments. >=20 > The document defines a YANG model for managing a trust anchor store. = It allows > two kinds of trust anchors: certificates and raw public keys. However, > certificates are not just containers for public keys. Certificates = include > attributes about key usage, path constraints and name constraints, all = of which > constrain the ability to use the public key, and are relevant for = trust > anchors. As far as I can tell the document does not include any = attributes to > equivalently constrain the use of the raw public keys. If the = intention is > that raw public keys will not be constrained, the document should = state this > explicitly. >=20 > Perhaps this is clear to the people who worked on the document, but = it's not > clear to me. Are the trust anchors managed with this module supposed = to be > used to establish trust for the NETCONF or RESTCONF connections? = Section 1.1 > seems to suggest that it does, but then how is the bootstrap problem = solved? > How do we establish the NETCONF connection the first time, and if we = are able > to do that, why do we need more certificates? If the answer is no, = and the > certificates are to be used by other protocols, then perhaps some = re-wording in > section 1.1 would help to show this. Currently, it says: "This = document > presents ... YANG modules that are part of a collection of RFCs ... = define > configuration modules for clients and servers of both the NETCONF and = RESTCONF > protocols." >=20 > The security considerations section is OK, especially sub-section 4.2. > Sub-section 4.1 has the following: >=20 > The YANG module defined in this document defines a mechanism called = a > "truststore" that, by its name, suggests that it will protect its > contents from unauthorized modification. >=20 > Perhaps this is my different perspective, but the name doesn't lead me = to > expect that it protects its contents. I think that the document = should either > just suggest that some mechanism to prevent unauthorized modification = should be > used, or to present such a mechanism in detail. The current text = suggests is > partially specific by mentioning digital signatures and non-volatile = storage, > but not explaining where the trust for the digital signature comes = from and > what policies govern its us: >=20 > In order to satisfy the expectations of a "truststore", it is > RECOMMENDED that implementations ensure that the truststore contents > are signed when persisted to non-volatile memory, to prevent > unauthorized modifications from being made undetected. >=20 > It is too vague to be a specification, but still unnecessarily = constrains the > solution space. I think the correct thing to do is to be explicitly = vague and > to just suggest some mechanism for protecting the content. >=20 >=20 > --=20 > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call From nobody Fri Oct 2 06:07:42 2020 Return-Path: <01000174e96cd06f-4ecb06ac-c7ac-4233-bd5d-97d3dbc74830-000000@amazonses.watsen.net> 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 ED4593A0FD5 for ; Fri, 2 Oct 2020 06:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 nRsLxOOuIAfA for ; Fri, 2 Oct 2020 06:07:38 -0700 (PDT) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A0243A0FCE for ; Fri, 2 Oct 2020 06:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601644056; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=Tjej7FQkTXaybFIRW7DFowIvxdpq8Y9BxBinR0Dklds=; b=To0WI60NnJBHBFIqhKcRJ1noxCKVCeR0G4GZLcHh90/UYRzfw8ulcIBEjZQEf5Zz RJhFMZW5AhwUSxCJ0dt48D49Xnk1SNu8V55nTL/3NoAEGeYS9JT3laUsFGjix+7KaBK YufJ/ZeEp5lYGnMOp5sfJK5colKLC4LP3K2lO2Pc= From: Kent Watsen Message-ID: <01000174e96cd06f-4ecb06ac-c7ac-4233-bd5d-97d3dbc74830-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_54C7951C-B7F7-4214-9B6B-195E94A21AD2" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 2 Oct 2020 13:07:36 +0000 In-Reply-To: <20201002.082331.2242297379846191383.id@4668.se> Cc: Olof Hagsand , "netconf@ietf.org" To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= References: <01000174e4610ae6-d1488376-ae7e-4d95-ba7e-005fc44b9592-000000@email.amazonses.com> <20201001.165548.1275939966226069939.id@4668.se> <01000174e5ba8cc5-39edb446-48d9-4896-a6b5-dcf80f962762-000000@email.amazonses.com> <20201002.082331.2242297379846191383.id@4668.se> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.10.02-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org 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, 02 Oct 2020 13:07:40 -0000 --Apple-Mail=_54C7951C-B7F7-4214-9B6B-195E94A21AD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> 3) Here we=E2=80=99re talking about querying a potentially large = repository of >> logs that are at rest, and full table scans should avoided. I = suggest >> that we=E2=80=99re dealing with something new here. >=20 > Perhaps we don't understand each other. Here's an pseudo-code example > of what I envision: >=20 > GET /interfaces/interface > filter 'oper-status =3D "up" and statistics/in-errors > 0' >=20 > This is XPath 1.0, applied to one instance at the time. Of course I understand Xpath filters, other relevant examples here: - https://tools.ietf.org/html/rfc5277#section-5.2 = - https://tools.ietf.org/html/rfc8040#appendix-B.3.6 = The point was/is that supporting full-Xpath for stream-filters is easy, = or rather doesn=E2=80=99t entail special consideration, as already each = event is in memory for an Xpath analysis. Thus, pointing to existing = usage as evidence that unconstrained Xpath can be used everywhere, = including for potentially very-large CF-lists, is not a given, as it = would be performance-limiting to bring every list-entry into = application-level memory in order to use an Xpath library. In this = case, it is very much desired to push all the querying logic to the = DB-backend. >> But when it comes to CF data, doing a full table scan is impractical >> and index-backed queries can make the difference between the client >> waiting seconds vs minutes. This is why I was initially trying to >> focus on just solving the CF problem, where the pain is acute. >=20 > Well, it is less likely that an implementation uses a feature-rich (in > terms of query language) DB to store all its state, than its config. > So it would probably be easier to implement this using "an index" for > config than for config false... Really? ...my experience is seems opposite. =20 A number of server implementations I=E2=80=99m aware of persist the = entire configuration as a flat-file (e.g., pretty-print XML or JSON). = They bring it into memory and act on it using a feature-rich library = (e.g., Yangson). In my view, this approach hits the low-bar in terms of = what constitutes a =E2=80=9Cdatabase=E2=80=9D.=20 On the flip side, handling large CF-lists (e.g., logs) is where servers = pretty much have to use a real database. An RDB (relational DB) is = common, but a TSDB (time-series DB) = is better suited. Perhaps we=E2=80=99re saying the same thing (yes, config APIs tends to = have better query expressions)=E2=80=A6it might just be your last line = regarding =E2=80=9Cindex=E2=80=9D that=E2=80=99s throwing me (as clearly = the DBs storing large CF-lists are having indexes). >> That said, I propose we do =E2=80=9Cboth=E2=80=9D. >=20 > I agree. Okay, we=E2=80=99ll shoot for a two-pronged approach. Separately, for the RC-list draft only, the plan is to declare = =E2=80=9Clist=E2=80=9D and =E2=80=9Cleaf-list=E2=80=9D nodes (not their = entries) as data resource targets. We only need to do this for GET, but = I assume that it's better to cover all the HTTP operations - thoughts? K.= --Apple-Mail=_54C7951C-B7F7-4214-9B6B-195E94A21AD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

3) Here = we=E2=80=99re talking about querying a potentially large repository = of
logs that are at rest, and full table scans should = avoided.  I suggest
that we=E2=80=99re dealing with = something new here.

Perhaps we = don't understand each other.  Here's an pseudo-code example
of what I envision:

 GET = /interfaces/interface
 filter  'oper-status =3D = "up" and statistics/in-errors > 0'

This = is XPath 1.0, applied to one instance at the time.

Of = course I understand Xpath filters, other relevant examples = here:

<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> = - https://tools.ietf.org/html/rfc8040#appendix-B.3.6

The point was/is that supporting full-Xpath = for stream-filters is easy, or rather doesn=E2=80=99t entail special = consideration, as already each event is in memory for an Xpath analysis. =  Thus, pointing to existing usage as evidence that unconstrained = Xpath can be used everywhere, including for potentially very-large = CF-lists, is not a given, as it would be performance-limiting to bring = every list-entry into application-level memory in order to use an Xpath = library.  In this case, it is very much desired to push all the = querying logic to the DB-backend.


But when it comes to CF = data, doing a full table scan is impractical
and = index-backed queries can make the difference between the client
waiting seconds vs minutes.  This is why I was initially = trying to
focus on just solving the CF problem, where the = pain is acute.

Well, it is = less likely that an implementation uses a feature-rich (in
terms of query language) DB to store all its state, than its = config.
So it would probably be easier to implement this = using "an index" for
config than for config false...

Really?=  ...my experience is seems opposite.  

A number of server implementations I=E2=80=99m = aware of persist the entire configuration as a flat-file (e.g., = pretty-print XML or JSON).  They bring it into memory and act on it using a feature-rich library = (e.g., Yangson).  In my view, this approach hits the low-bar in = terms of what constitutes a =E2=80=9Cdatabase=E2=80=9D. 
On the flip side, handling large CF-lists (e.g., = logs) is where servers pretty much have to use a real database.  An = RDB (relational DB) is common, but a TSDB (time-series DB) is better = suited.

Perhaps we=E2=80=99re saying = the same thing (yes, config APIs tends to have better query = expressions)=E2=80=A6it might just be your last line regarding = =E2=80=9Cindex=E2=80=9D that=E2=80=99s throwing me (as clearly the DBs = storing large CF-lists are having indexes).


That said, I propose we do =E2=80=9Cboth=E2=80=9D. =  <snip/>

I = agree.

Okay, we=E2=80=99ll shoot for a two-pronged = approach.



Separately, for the = RC-list draft only, the plan is to declare =E2=80=9Clist=E2=80=9D and = =E2=80=9Cleaf-list=E2=80=9D nodes (not their entries) as data resource = targets.  We only need to do this for GET, but I assume that it's = better to cover all the HTTP operations - thoughts?


K.
= --Apple-Mail=_54C7951C-B7F7-4214-9B6B-195E94A21AD2-- From nobody Fri Oct 2 06:31:40 2020 Return-Path: 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 C02B53A1623 for ; Fri, 2 Oct 2020 06:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vc79eMK_Le4A for ; Fri, 2 Oct 2020 06:31:37 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 952303A1622 for ; Fri, 2 Oct 2020 06:31:36 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id w3so1196472ljo.5 for ; Fri, 02 Oct 2020 06:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bw7P7ua/zfcwZzuvOY5nH/Y38mZyODr7Y8RVRXqNu1A=; b=JA9FCKIplswjh2meTMRHpQRdZcZHdMcMkZZBJyTJoi3W32RRe0DZajITvsxDPFOVkc RdH4jQL//KrAkdfnsX+QbdLfsABNsGJ+JeLs/SxOamcfHjzZf+hRloGo6ZiyGxlBPImT VwPaPWMK0hBBjkuD358Mo/jRkScyS4VMaVG9O3CQ6ft66qXFHwMl/l+Wdgrnf+t9doZY x8Hvb9iMUknJ4KFq914rAl9jf/IWYq8ASnXTwyHwURy0bijl+mIMiYzthmeK+VgD3x4e 5a+wZ2KVfsceAlOIyI2W0CmVrB5QWUZ/K9t8hmzgLuz9OqVQg6G6U917sGxJi3lnSLyC 6POA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Bw7P7ua/zfcwZzuvOY5nH/Y38mZyODr7Y8RVRXqNu1A=; b=UXspFQHPSv+9NZSrSkefkHw6l6C9PXrsriJeSdElvzc1hZyaQpDS6wCJJCc0CvI0yH a4B7cvpvk+dclLviK8rTDAPhdox9Bl3kEUkfx7zrLM/3Us8Pdd/5zyhWA5XLQXRo8izn w8BAnNCCWggBl1F3YjUZWbCAT7YdwYs4MXxTFXjLurbstkbKqrxlGHHE+Eveuzs4Vcdo xDRiG5HRgai+i2SDYwTVZg5Gw7+qni5ot4n0G5BxlpSN63R9Akcztq+2DvlhvKWFkGQI f86LXPIYnxXZy6gZZ9KmpZi9rAo0KELmpOVp/o1Ekh7SvbBP5a7yTL7f5qWuloOGsuPv WmBg== X-Gm-Message-State: AOAM533HQ1/rUALXkbRtckLiSPoxlfXyqIhU0y+zz37N9xDT0xP/pnch ktPXM97I/A7/74BvbW50W+j8i1FiYAVKM+vpRA0= X-Google-Smtp-Source: ABdhPJyKo+jV620aG9kKUZYOR43SLfGSTBEs4nQKVmn5ccBgqj6fuIrrPu1LzLrVGRyh5/vagGuaUI+YIP9lq4BpniY= X-Received: by 2002:a2e:808f:: with SMTP id i15mr675910ljg.51.1601645494628; Fri, 02 Oct 2020 06:31:34 -0700 (PDT) MIME-Version: 1.0 References: <01000174e4610ae6-d1488376-ae7e-4d95-ba7e-005fc44b9592-000000@email.amazonses.com> <20201001.165548.1275939966226069939.id@4668.se> <01000174e5ba8cc5-39edb446-48d9-4896-a6b5-dcf80f962762-000000@email.amazonses.com> <20201002.082331.2242297379846191383.id@4668.se> <01000174e96cd06f-4ecb06ac-c7ac-4233-bd5d-97d3dbc74830-000000@email.amazonses.com> In-Reply-To: <01000174e96cd06f-4ecb06ac-c7ac-4233-bd5d-97d3dbc74830-000000@email.amazonses.com> From: Hongwei Li Date: Fri, 2 Oct 2020 09:31:22 -0400 Message-ID: To: Kent Watsen Cc: =?UTF-8?Q?Martin_Bj=C3=B6rklund?= , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c375fb05b0b02646" Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org 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, 02 Oct 2020 13:31:40 -0000 --000000000000c375fb05b0b02646 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kent, On Fri, Oct 2, 2020 at 9:07 AM Kent Watsen wrote: > > 3) Here we=E2=80=99re talking about querying a potentially large reposito= ry of > logs that are at rest, and full table scans should avoided. I suggest > that we=E2=80=99re dealing with something new here. > > > Perhaps we don't understand each other. Here's an pseudo-code example > of what I envision: > > GET /interfaces/interface > filter 'oper-status =3D "up" and statistics/in-errors > 0' > > This is XPath 1.0, applied to one instance at the time. > > > Of course I understand Xpath filters, other relevant examples here: > > - https://tools.ietf.org/html/rfc5277#section-5.2 > - https://tools.ietf.org/html/rfc8040#appendix-B.3.6 > > The point was/is that supporting full-Xpath for stream-filters is easy, o= r > rather doesn=E2=80=99t entail special consideration, as already each even= t is in > memory for an Xpath analysis. Thus, pointing to existing usage as eviden= ce > that unconstrained Xpath can be used everywhere, including for potentiall= y > very-large CF-lists, is not a given, as it would be performance-limiting = to > bring every list-entry into application-level memory in order to use an > Xpath library. In this case, it is very much desired to push all the > querying logic to the DB-backend. > > > But when it comes to CF data, doing a full table scan is impractical > and index-backed queries can make the difference between the client > waiting seconds vs minutes. This is why I was initially trying to > focus on just solving the CF problem, where the pain is acute. > > > Well, it is less likely that an implementation uses a feature-rich (in > terms of query language) DB to store all its state, than its config. > So it would probably be easier to implement this using "an index" for > config than for config false... > > > Really? ...my experience is seems opposite. > > A number of server implementations I=E2=80=99m aware of persist the entir= e > configuration as a flat-file (e.g., pretty-print XML or JSON). They brin= g > it into memory and act on it using a feature-rich library (e.g., > Yangson). In my view, this approach hits the low-bar in terms of what > constitutes a =E2=80=9Cdatabase=E2=80=9D. > > On the flip side, handling large CF-lists (e.g., logs) is where servers > pretty much have to use a real database. An RDB (relational DB) is commo= n, > but a TSDB (time-series DB) > is better suited. > [HL] A user case for time series data (e.g., logs), customers want to get > the data in between Time A and Time B. Do we use timestamp filter here? > > Perhaps we=E2=80=99re saying the same thing (yes, config APIs tends to ha= ve better > query expressions)=E2=80=A6it might just be your last line regarding =E2= =80=9Cindex=E2=80=9D that=E2=80=99s > throwing me (as clearly the DBs storing large CF-lists are having indexes= ). > > > That said, I propose we do =E2=80=9Cboth=E2=80=9D. > > > I agree. > > > Okay, we=E2=80=99ll shoot for a two-pronged approach. > > > > Separately, for the RC-list draft only, the plan is to declare =E2=80=9Cl= ist=E2=80=9D and > =E2=80=9Cleaf-list=E2=80=9D nodes (not their entries) as data resource ta= rgets. We only > need to do this for GET, but I assume that it's better to cover all the > HTTP operations - thoughts? > [HL] Data resources should not be bound to some specific operation. > Correct me, if my understanding is wrong. > > K. > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000c375fb05b0b02646 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Kent,


On Fri, Oct 2= , 2020 at 9:07 AM Kent Watsen <kent+ietf@watsen.net> wrote:

3) Here we=E2=80= =99re talking about querying a potentially large repository of
logs that= are at rest, and full table scans should avoided.=C2=A0 I suggest
that = we=E2=80=99re dealing with something new here.

Perhaps = we don't understand each other.=C2=A0 Here's an pseudo-code example=
of what I envision:

=C2=A0GET /interfaces/interface
=C2=A0f= ilter =C2=A0'oper-status =3D "up" and statistics/in-errors &g= t; 0'

This is XPath 1.0, applied to one instance at the time.

Of course I understand Xpath = filters, other relevant examples here:

<= div>
The point was/is that supporting full-Xpath for stream-f= ilters is easy, or rather doesn=E2=80=99t entail special consideration, as = already each event is in memory for an Xpath analysis.=C2=A0 Thus, pointing= to existing usage as evidence that unconstrained Xpath can be used everywh= ere, including for potentially very-large CF-lists, is not a given, as it w= ould be performance-limiting to bring every list-entry into application-lev= el memory in order to use an Xpath library.=C2=A0 In this case, it is very = much desired to push all the querying logic to the DB-backend.

But when it comes to CF data, doing a full table scan is impracti= cal
and index-backed queries can make the difference between the client<= br>waiting seconds vs minutes.=C2=A0 This is why I was initially trying to<= br>focus on just solving the CF problem, where the pain is acute.

Well, it is less likely that an implementation uses a feature-ri= ch (in
terms of query language) DB to store all its state, than its conf= ig.
So it would probably be easier to implement this using "an inde= x" for
config than for config false...
=

Really? =C2=A0...my experience is seems opposite. =C2= =A0

A number of server implementations I=E2=80=99m= aware of persist the entire configuration as a flat-file (e.g., pretty-pri= nt XML or JSON).=C2=A0 They bring it into=C2=A0memory=C2=A0and act on it using a feature-rich library (e.g., Y= angson).=C2=A0 In my view, this approach hits the low-bar in terms of what = constitutes a =E2=80=9Cdatabase=E2=80=9D.=C2=A0

On= the flip side, handling large CF-lists (e.g., logs) is where servers prett= y much have to use a real database.=C2=A0 An RDB (relational DB) is common,= but a=C2=A0TSDB (time-series DB)=C2=A0is better suited.
[HL] A user case for time series data (e.g., logs), customers want to get= the data in between Time A and Time B. Do we use timestamp filter here?
=C2=A0
Per= haps we=E2=80=99re saying the same thing (yes, config APIs tends to have be= tter query expressions)=E2=80=A6it might just be your last line regarding = =E2=80=9Cindex=E2=80=9D that=E2=80=99s throwing me (as clearly the DBs stor= ing large CF-lists are having indexes).


=
That said, I = propose we do =E2=80=9Cboth=E2=80=9D. =C2=A0<snip/>

I agree.

Okay, we=E2=80=99ll shoot for a t= wo-pronged approach.



Separately, for the RC-list draft only, the plan is to declare =E2=80=9Cli= st=E2=80=9D and =E2=80=9Cleaf-list=E2=80=9D nodes (not their entries) as da= ta resource targets.=C2=A0 We only need to do this for GET, but I assume th= at it's better to cover all the HTTP operations - thoughts?
[= HL] Data resources should not be bound to some specific operation. Correct = me, if my understanding is wrong.

K.
_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000c375fb05b0b02646-- From nobody Fri Oct 2 07:46:32 2020 Return-Path: <01000174e9c75096-5f451248-48e7-4add-a56b-9789cddd3e56-000000@amazonses.watsen.net> 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 11EA93A10EB for ; Fri, 2 Oct 2020 07:46:30 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 R313IxK8lyZo for ; Fri, 2 Oct 2020 07:46:29 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA9D3A1092 for ; Fri, 2 Oct 2020 07:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601649988; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=WbpyfFfD+yI4N57PxB1CCLsx66+hD+YZ9ta06+JuHhU=; b=VeZmLhkIzaWxuToscBDm69eomxrKj9mvPRp5PzmElV0sGRb4wtL0nYCaBolvzXG8 Kjd0LwXLwJBLDTAimtXfc8vtGW3qDSYfR0mT/WRPvDWgoZTGpA/zzNp6NPojZVALzc6 u+xUMFCTq9lBUCepQAf8byAdYsqnRUh31a8gQhi0= From: Kent Watsen Message-ID: <01000174e9c75096-5f451248-48e7-4add-a56b-9789cddd3e56-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C6CE3C3F-81F0-48B6-9854-D005124FEDBC" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 2 Oct 2020 14:46:27 +0000 In-Reply-To: Cc: =?utf-8?Q?Martin_Bj=C3=B6rklund?= , "netconf@ietf.org" To: Hongwei Li References: <01000174e4610ae6-d1488376-ae7e-4d95-ba7e-005fc44b9592-000000@email.amazonses.com> <20201001.165548.1275939966226069939.id@4668.se> <01000174e5ba8cc5-39edb446-48d9-4896-a6b5-dcf80f962762-000000@email.amazonses.com> <20201002.082331.2242297379846191383.id@4668.se> <01000174e96cd06f-4ecb06ac-c7ac-4233-bd5d-97d3dbc74830-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.10.02-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org 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, 02 Oct 2020 14:46:30 -0000 --Apple-Mail=_C6CE3C3F-81F0-48B6-9854-D005124FEDBC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Hongwei, > [HL] A user case for time series data (e.g., logs), customers want to = get the data in between Time A and Time B. Do we use timestamp filter = here? Some events have only one timestamp. The database likely has a primary = key (e.g., "record-id=E2=80=9D) and a separate =E2=80=9Ctimestamp=E2=80=9D= field. For all intents and purposes, the logs are persisted in = time-order, so no additional sorting is needed. The physical order is = good enough. However, other events may have distinct "time-generated" and = "time-received=E2=80=9D fields. This is most notable for a = =E2=80=9Clog-receiver=E2=80=9D (or just =E2=80=9Creceiver", in rfc8639 = parlance), as there may be a delay between when a log is generated by a = publisher and when it is persisted by the receiver. In this case, the = user-expectation is undoubtedly to sort on =E2=80=9Ctime-generated=E2=80=9D= . The =E2=80=9Crecord-id=E2=80=9D and =E2=80=9Ctime-received=E2=80=9D = fields are physically in order (same as above), but =E2=80=9Ctime-generate= d=E2=80=9D could be all over the place, so a sort is needed. FWIW, if the goal is to find logs generated in a window of time around a = timestamp, a fast-filter can be used to whittle down the result-set to a = (hopefully) manageable size before the slow-sort as follows: filter "time-generated >=3D timestamp-of-interest - = some-window=E2=80=9D and =E2=80=9Ctime-received <=3D timestamp-of-interest + = some-window" sort-by =E2=80=9Ctime-generated" K. --Apple-Mail=_C6CE3C3F-81F0-48B6-9854-D005124FEDBC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Hongwei,

[HL] A user case = for time series data (e.g., logs), customers want to get the data in = between Time A and Time B. Do we use timestamp filter = here?
Some events have only one timestamp.  The = database likely has a primary key (e.g., "record-id=E2=80=9D) and a = separate =E2=80=9Ctimestamp=E2=80=9D field.  For all intents and = purposes, the logs are persisted in time-order, so no additional sorting = is needed.  The physical order is good enough.

However, other events may have distinct = "time-generated" and "time-received=E2=80=9D fields.  This is most = notable for a =E2=80=9Clog-receiver=E2=80=9D (or just =E2=80=9Creceiver", = in rfc8639 parlance), as there may be a delay between when a log is = generated by a publisher and when it is persisted by the receiver. =   In this case, the user-expectation is undoubtedly to = sort on =E2=80=9Ctime-generated=E2=80=9D. The = =E2=80=9Crecord-id=E2=80=9D and =E2=80=9Ctime-received=E2=80=9D fields = are physically in order (same as above), but =E2=80=9Ctime-generated=E2=80= =9D could be all over the place, so a sort is needed.

FWIW, if the goal is to find logs generated in a window = of time around a timestamp, a fast-filter can be used to whittle down = the result-set to a (hopefully) manageable size before the slow-sort as = follows:

= filter
"time-generated >=3D = timestamp-of-interest - some-window=E2=80=9D
= and
=E2=80=9Ctime-received = <=3D timestamp-of-interest + = some-window"
sort-by
= =E2=80=9Ctime-generated"


K.

= --Apple-Mail=_C6CE3C3F-81F0-48B6-9854-D005124FEDBC-- From nobody Fri Oct 2 08:09:22 2020 Return-Path: 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 776AC3A1654 for ; Fri, 2 Oct 2020 08:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 u51LmrMtZDVo for ; Fri, 2 Oct 2020 08:09:19 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4993A1651 for ; Fri, 2 Oct 2020 08:09:09 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id b22so2241410lfs.13 for ; Fri, 02 Oct 2020 08:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rJSLI5yI5rQ0Zs2OBmCiHeJuFQ2lDnY5UflA9KDYFlw=; b=l3fTYLnGjxWBC2OvHgdZGWPKUeSxak7jkoTZcnGRuW9CIIzpXRq2Konm48hvd0otnw b819yJoIHWHEX2LA8YJPyc4BffiR+rl7acBZPTk9DdW6qcmnqpISJZpDv5FwEfqAFry0 Hf+6rgwEqX4BRO46ILDycEQuxKOBCjsgpG3wpby2qJj7H61vy7X82y7D1OCrDeKP86Da rAAr0SAk75A8xLCF2WV1ffoK17aFH4GSsu4PAYTJSiXqZFQI6rAtgnCUNXHMzQkwI3Vi PGvCuPL9Op5sp1WkqwiL8rm79Q9ys9xmKubxlpBxXotkJZMpop5zG4zNjEaAQu3yCkyd 4PCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rJSLI5yI5rQ0Zs2OBmCiHeJuFQ2lDnY5UflA9KDYFlw=; b=QyXJWkaC5S4sr+RgG2ZP0263XQrsgKMFmB2fx5yRkH9YD71Q7HLAOdy5LZ1hpQNiBB DaYnPFYCZg4DFDbu6WynMaS/rGIrqc3qpE8JPANKc1GMJFCxpF4uSpWqD9+pYe/Nu3Hn qxPlhOiFeS/hTsZr1he6TOodJlwlmJ+d1qp7XQcJFnzylcPmfrrOuvYePEFOgrPpMF82 s0Gm0Pig0KuKiQk5DO1y2giZ6EIZIWHJkRf2dFnawlkK57xYwoh5MYGcGGBqGHBvMM2R WX1a52CtKJwKqG3VqWscNi7/Yc7Gu5ZuqVIQcMSpoUBes+41TH3dwZ5rDUNCc2j65GCI HpKQ== X-Gm-Message-State: AOAM5300ed4qjrYOo/yyWJ8eLyaCW3jwIO78aXjrKh+VXsLpb1gh8LKx eeEEQgF4XUHoWCBIaCu3574GI5O+t0EWPyIoybMg+6/bBTFWeg== X-Google-Smtp-Source: ABdhPJySVo8Pm5DwggRJ250EanxoY0MxOvr5QqrF/YEMn0VJtMuYNgoFtWDKvz9x+LrSj2dXB//J6g4tAg1QKwf9Db8= X-Received: by 2002:a19:5f5d:: with SMTP id a29mr1138089lfj.259.1601651347482; Fri, 02 Oct 2020 08:09:07 -0700 (PDT) MIME-Version: 1.0 References: <01000174e4610ae6-d1488376-ae7e-4d95-ba7e-005fc44b9592-000000@email.amazonses.com> <20201001.165548.1275939966226069939.id@4668.se> <01000174e5ba8cc5-39edb446-48d9-4896-a6b5-dcf80f962762-000000@email.amazonses.com> <20201002.082331.2242297379846191383.id@4668.se> <01000174e96cd06f-4ecb06ac-c7ac-4233-bd5d-97d3dbc74830-000000@email.amazonses.com> <01000174e9c75096-5f451248-48e7-4add-a56b-9789cddd3e56-000000@email.amazonses.com> In-Reply-To: <01000174e9c75096-5f451248-48e7-4add-a56b-9789cddd3e56-000000@email.amazonses.com> From: Hongwei Li Date: Fri, 2 Oct 2020 11:08:56 -0400 Message-ID: To: Kent Watsen Cc: =?UTF-8?Q?Martin_Bj=C3=B6rklund?= , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009eeb5805b0b18336" Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org 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, 02 Oct 2020 15:09:22 -0000 --0000000000009eeb5805b0b18336 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Kent This is clear enough. Just want to make sure we cover that. The next question is: can we avoid the slow-sort? Like to split the request automatically or something else? IMO, this is more on implementation side. On Fri, Oct 2, 2020 at 10:46 AM Kent Watsen wrote: > Hi Hongwei, > > [HL] A user case for time series data (e.g., logs), customers want to get >> the data in between Time A and Time B. Do we use timestamp filter here? >> > > Some events have only one timestamp. The database likely has a primary > key (e.g., "record-id=E2=80=9D) and a separate =E2=80=9Ctimestamp=E2=80= =9D field. For all intents > and purposes, the logs are persisted in time-order, so no additional > sorting is needed. The physical order is good enough. > > However, other events may have distinct "time-generated" and > "time-received=E2=80=9D fields. This is most notable for a =E2=80=9Clog-= receiver=E2=80=9D (or just > =E2=80=9Creceiver", in rfc8639 parlance), as there may be a delay between= when a > log is generated by a publisher and when it is persisted by the receiver.= In > this case, the user-expectation is undoubtedly to sort on =E2=80=9Ctime-g= enerated=E2=80=9D. The > =E2=80=9Crecord-id=E2=80=9D and =E2=80=9Ctime-received=E2=80=9D fields ar= e physically in order (same as > above), but =E2=80=9Ctime-generated=E2=80=9D could be all over the place,= so a sort is > needed. > > FWIW, if the goal is to find logs generated in a window of time around a > timestamp, a fast-filter can be used to whittle down the result-set to a > (hopefully) manageable size before the slow-sort as follows: > > filter > "time-generated >=3D timestamp-of-interest - some-window=E2=80=9D > and > =E2=80=9Ctime-received <=3D timestamp-of-interest + some-window" > sort-by > =E2=80=9Ctime-generated" > > > K. > > --0000000000009eeb5805b0b18336 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Kent
This is clear enough. Just want to make su= re we cover that.
The next question is: can we avoid the slow-sor= t? Like to split the request automatically or something else? IMO, this is = more on implementation side.

On Fri, Oct 2, 2020 at 10:46 AM Kent Wats= en <kent+ietf@watsen.net&g= t; wrote:
Hi Hongwei,

[HL] A = user case for time series data (e.g., logs), customers want to get the data= in between Time A and Time B. Do we use timestamp filter here?
=

Some = events have only one timestamp.=C2=A0 The database likely has a primary key= (e.g., "record-id=E2=80=9D) and a separate =E2=80=9Ctimestamp=E2=80= =9D field.=C2=A0 For all intents and purposes, the logs are persisted in ti= me-order, so no additional sorting is needed.=C2=A0 The physical order is g= ood enough.

However, other events may have distinc= t "time-generated" and "time-received=E2=80=9D fields.=C2=A0= This is most notable for a =E2=80=9Clog-receiver=E2=80=9D (or just =E2=80= =9Creceiver", in rfc8639 parlance), as there may be a delay between wh= en a log is generated by a publisher and when it is persisted by the receiv= er. =C2=A0=C2=A0In this case, the user-exp= ectation is undoubtedly to sort on =E2=80=9Ctime-generated=E2=80=9D.=C2=A0<= /span>The =E2=80=9Crecord-id=E2=80=9D and =E2=80=9Ctime-received=E2=80=9D f= ields are physically in order (same as above), but =E2=80=9Ctime-generated= =E2=80=9D could be all over the place, so a sort is needed.

<= /div>
FWIW, if the goal is to find logs= generated in a window of time around a timestamp, a fast-filter can be use= d to whittle down the result-set to a (hopefully) manageable size before th= e slow-sort as follows:

filter
"time-generated >=3D timestamp-of-interest - some-wind= ow=E2=80=9D
and
=E2=80=9Ctime-received= <=3D=C2=A0timestamp-of-interest + some= -window"
sort-by
=E2=80=9Ct= ime-generated"


K.
--0000000000009eeb5805b0b18336-- From nobody Fri Oct 2 15:27:42 2020 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7533A1706; Fri, 2 Oct 2020 15:27:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.18.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <160167766146.8138.7027968134745816424@ietfa.amsl.com> Date: Fri, 02 Oct 2020 15:27:41 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-sztp-csr-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 22:27:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request Authors : Kent Watsen Russ Housley Sean Turner Filename : draft-ietf-netconf-sztp-csr-00.txt Pages : 29 Date : 2020-10-02 Abstract: This draft extends the "get-bootstrapping-data" RPC defined in RFC 8572 to include an optional certificate signing request (CSR), enabling a bootstrapping device to additionally obtain an identity certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the "onboarding information" response provided in the RPC-reply. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ There is also a HTML versions available at: https://www.ietf.org/id/draft-ietf-netconf-sztp-csr-00.html Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 2 21:56:09 2020 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF903A17F1; Fri, 2 Oct 2020 21:55:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <160170095613.16258.8508938871825187693@ietfa.amsl.com> Date: Fri, 02 Oct 2020 21:55:56 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-distributed-notif-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2020 04:55:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : Subscription to Distributed Notifications Authors : Tianran Zhou Guangying Zheng Eric Voit Thomas Graf Pierre Francois Filename : draft-ietf-netconf-distributed-notif-00.txt Pages : 19 Date : 2020-10-02 Abstract: This documents describes extensions to the YANG notifications subscription to allow metrics being published directly from processors on line cards to target receivers, while subscription is still maintained at the route processor in a distributed forwarding system. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-distributed-notif/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-distributed-notif-00 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 2 21:57:09 2020 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4AD3A17F6; Fri, 2 Oct 2020 21:57:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <160170102380.16011.5923686038613602074@ietfa.amsl.com> Date: Fri, 02 Oct 2020 21:57:03 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-udp-notif-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2020 04:57:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : UDP-based Transport for Configured Subscriptions Authors : Guangying Zheng Tianran Zhou Thomas Graf Pierre Francois Paolo Lucente Filename : draft-ietf-netconf-udp-notif-00.txt Pages : 15 Date : 2020-10-02 Abstract: This document describes an UDP-based notification mechanism to collect data from networking devices. A shim header is proposed to facilitate the streaming of data directly from line cards to a collector. The objective is to rely on a lightweight approach to allow for higher frequency and better transit performance compared to already established notification mechanisms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-notif/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-udp-notif-00 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 13 22:45:24 2020 Return-Path: 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 ECAFC3A1397 for ; Tue, 13 Oct 2020 22:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 UAKFZGhG-vWR for ; Tue, 13 Oct 2020 22:45:21 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80033A1395 for ; Tue, 13 Oct 2020 22:45:21 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id v12so1170401ply.12 for ; Tue, 13 Oct 2020 22:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=I/RMJVpaVYMSJ/Y3tsyWe2rTN5VoVSGJNqHNUrVk7LI=; b=qbPGMfGfT4ew3/00WEAO7QHliSw2GuaD09dPpzvYdwv1VkuCNuk+rE46ufPRp7v3MC d7ZOUqasfHl2m0U4kUluUqHMCeyAG3G42lrI9YQozus4xeGP92aBWTRTtOiWdZpr30gt 0W1sSz8ddOO+NaItcuVAGZvXi0eUSI91MFc2jCh+X4aYDZEacaKDG2WNRlvz8vBKLb9p eqOkv6SBGYoo4QPLfZA2qRKUKwR4djFt67E7oCOZ+NnffJ6DqlFbF5hPUNErH/+ekyEG ZbmRtgRYz8crXY236RbrMSW9zFOQNaK+CTBszVRTn6YZQ+ACgGSv4+ou1zuYBapTut4E cgaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=I/RMJVpaVYMSJ/Y3tsyWe2rTN5VoVSGJNqHNUrVk7LI=; b=W40xel/xQsb8hYEH9qaJkbob8M/3wepgNvR0nsgs0mgTj2ZGaVsq/L7c0DgAZRAX7F 7EdmzPFd/bMHavIJlmziIbLgqHPxwF9XRF9sEYficZXvfHMnaTgT71auHRrq2JrG4XTz Kios6Pm4YdfcyPM3fFOpykNHlqbPvE4nQ0wUNzBaH+nWpT2rd8F7YHQ4P5OXaEnMxkJG vIGIjFoyCSx6mGk7pEHqeu1YVEgaHSTSgpKhn6CaBtEEhztFljfsQWw6tCrI0+ta++d1 IVxrytdR/0X3RcrNbqnFWFbzV8CXabjKxV01SMJ1/8N1MdFKAE87GtDMArb65RhFL/SI HdZQ== X-Gm-Message-State: AOAM530jqnmEf5SvGJT1ioQLPcxwQ1kASMRFisdjKMWd0/bhYoKBUN2u lCqfzpUTTEeSo35FlHTQR+PGFgBTMj1waA== X-Google-Smtp-Source: ABdhPJzobhCvn5Z7/k7i/Wk0QPCs4kcy78d+t6GfnL/KMrqKpSU5ydCWaNUtl9ogkPptOSwUBaLZiA== X-Received: by 2002:a17:902:9347:b029:d3:b2c6:1500 with SMTP id g7-20020a1709029347b02900d3b2c61500mr2891013plp.5.1602654320843; Tue, 13 Oct 2020 22:45:20 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:14dd:9a80:1b49:9ff3? ([2601:647:5600:5020:14dd:9a80:1b49:9ff3]) by smtp.gmail.com with ESMTPSA id x18sm1743516pfj.90.2020.10.13.22.45.19 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Oct 2020 22:45:20 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_6C841C75-344C-41FC-B938-F8028EA6C23C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: <742BBEAF-FDF5-4ABC-999F-919115226CA6@gmail.com> Date: Tue, 13 Oct 2020 22:45:19 -0700 To: Netconf X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [netconf] Normative reference to XML specification X-BeenThere: netconf@ietf.org 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: Wed, 14 Oct 2020 05:45:23 -0000 --Apple-Mail=_6C841C75-344C-41FC-B938-F8028EA6C23C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [As a contributor] Hi WG, RFC Editors want to update the normative reference to XML from what is = specified in RFC 6241. The latest such specification is = W3C.REC-xml-20081126, per the editors. RFC 6241 refers to W3C.REC-xml-20001006. The TWAMP YANG model is trying = to give an example of NETCONF configuration of the model in XML, and the = editors wanted to update the reference to W3C.REC-xml-20081126. I do not = know what the differences between the two versions are, but would it be = ok for them to update the reference?=20 Thanks. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_6C841C75-344C-41FC-B938-F8028EA6C23C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii [As a contributor]

Hi WG,

RFC Editors want to update the normative reference to XML from what is specified in RFC 6241. The latest such specification is W3C.REC-xml-20081126, per the editors.

RFC 6241 refers to W3C.REC-xml-20001006. The TWAMP YANG model is trying to give an example of NETCONF configuration of the model in XML, and the editors wanted to update the reference to W3C.REC-xml-20081126. I do not know what the differences between the two versions are, but would it be ok for them to update the reference? 

Thanks.

Mahesh Jethanandani





--Apple-Mail=_6C841C75-344C-41FC-B938-F8028EA6C23C-- From nobody Tue Oct 13 23:12:00 2020 Return-Path: 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 A49FF3A13A3 for ; Tue, 13 Oct 2020 23:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.997, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=G1NdnBiW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qzqQuVCM 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 mLIwgjvy68Ze for ; Tue, 13 Oct 2020 23:11:56 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79AEF3A139F for ; Tue, 13 Oct 2020 23:11:56 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8D2345C0109; Wed, 14 Oct 2020 02:11:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 14 Oct 2020 02:11:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm3; bh= lh6vXnNRJK8RmR86ix8qa9Pw4obgqlxG7bwtxVQB8cw=; b=G1NdnBiWt4ytaZa6 FjMKCfxslZ6XTDUc5mWcpMufmp3DdkdAUvIWRjQ15mCnvYIKu5TZtdqvcHfLspVR Y38NYOPbeX00JZgH1bSzR2ZNXce76rF+CgeNEVwp7d5knU0akUoCdfBxet2DvFy+ O2GPGsGGyFMjysgiN1DuvHLh4W8OuU6h5Oso5iSEHEpM3cOrpDREN9oD6qKRZpY/ EyQb5YSKWo6GbjM+rOuuUKGRUNVoJlezRdKT2BEC56ADQISmjpJtvLOdrIa5FH4B QpIjldx3oegN720qWYLzbFwH8W3rIaIvqdtsZPyTLYt5mM5f4EO4qHujM89w/SrU 9pTi0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=lh6vXnNRJK8RmR86ix8qa9Pw4obgqlxG7bwtxVQB8 cw=; b=qzqQuVCM/ZbveRplFDU8t6Zm5rjRSrxpZHUtzGgWsbbmvogi4uSVyPZob ZPnWNPdJBDAhTGNlrwfma736deHSvuaohl93/fq04u0nBjPrW8v8Aw1f1W0SZQKb Tn6/YQI+fIj4ItaA3R6GpG/NKnxAkUSj9iAGn4eFHbd7aV2LT/JPqegn/KpdpRzf rEvUMfRvuoBH17kpVh/4jOztUUI5nXzmdD885gdMK5Cg/vFHba/rrni9392C8C20 8afU75WAkdk3XOqxk4RiQmO02bDMENmvfTQjJqWD4Jxlmqg4V8nxUmVChnADNW5U D2a6GU2xmXMPwm/FZ93xiC9s7pxEg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedriedtgddutdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtje ertdertddvnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnheptdeggfdtuddujeekleevvd eivdevheeigeeffeetfefgfeefkeehffdvfeevfffgnecukfhppeduheekrddujeegrdeg rddvudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhgsjhdoihgvthhfseegieeikedrshgv X-ME-Proxy: Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id AD8D03064680; Wed, 14 Oct 2020 02:11:54 -0400 (EDT) Date: Wed, 14 Oct 2020 08:11:53 +0200 (CEST) Message-Id: <20201014.081153.619159600199372484.id@4668.se> To: mjethanandani@gmail.com Cc: netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <742BBEAF-FDF5-4ABC-999F-919115226CA6@gmail.com> References: <742BBEAF-FDF5-4ABC-999F-919115226CA6@gmail.com> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] Normative reference to XML specification X-BeenThere: netconf@ietf.org 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: Wed, 14 Oct 2020 06:11:58 -0000 Hi, Mahesh Jethanandani wrote: > [As a contributor] > > Hi WG, > > RFC Editors want to update the normative reference to XML from what is > specified in RFC 6241. The latest such specification is > W3C.REC-xml-20081126, per the editors. > > RFC 6241 refers to W3C.REC-xml-20001006. The TWAMP YANG model is > trying to give an example of NETCONF configuration of the model in > XML, and the editors wanted to update the reference to > W3C.REC-xml-20081126. I do not know what the differences between the > two versions are, but would it be ok for them to update the reference? I think it is ok. The example is still valid according to XML 1.0 second edition (W3C.REC-xml-20001006) so it is still valid according to RFC 6241. /martin From nobody Wed Oct 14 05:31:13 2020 Return-Path: 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 E44D73A09A4 for ; Wed, 14 Oct 2020 05:31:11 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nlk5owQTK0zh for ; Wed, 14 Oct 2020 05:31:09 -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 88C2E3A0990 for ; Wed, 14 Oct 2020 05:31:09 -0700 (PDT) Received: from lhreml712-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id AEA9C3F641969D24A396 for ; Wed, 14 Oct 2020 13:31:07 +0100 (IST) Received: from lhreml712-chm.china.huawei.com (10.201.108.63) by lhreml712-chm.china.huawei.com (10.201.108.63) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 14 Oct 2020 13:31:07 +0100 Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml712-chm.china.huawei.com (10.201.108.63) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Wed, 14 Oct 2020 13:31:07 +0100 Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.9]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0487.000; Wed, 14 Oct 2020 20:31:00 +0800 From: Qin Wu To: "netconf@ietf.org" Thread-Topic: I-D Action: draft-wang-netconf-adaptive-subscription-02.txt Thread-Index: AdaiJLyBVfnIh5AGS5mpmwY2jWH6+w== Date: Wed, 14 Oct 2020 12:31:00 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.101.103] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] I-D Action: draft-wang-netconf-adaptive-subscription-02.txt X-BeenThere: netconf@ietf.org 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: Wed, 14 Oct 2020 12:31:12 -0000 SGksIGFsbDoNClRoZSB2LTAyIGlzIHBvc3RlZCB0byBhZGRyZXNzIGNvbW1lbnRzIHJhaXNlZCBv biB0aGUgbGlzdCwgdGhlIG1haW4gY2hhbmdlczoNCjEuIERlY291cGxlIGZyb20gRUNBIG1vZGVs IGRyYWZ0LCByZW1vdmUgJ2RhdGEgcGF0aCcgYW5kICd0YXJnZXQnIHBhcmFtZXRlcnMgc2luY2Ug dGhlIGNvbmRpdGlvbiBleHByZXNzaW9uIGlzIGV4dGVybmFsIGNvbmRpdGlvbiB3aGljaCBvbmx5 IGluZmx1ZW5jZSB1cGRhdGUgaW50ZXJ2YWwgY2hhbmdlIGFuZCANCndpbGwgbm90IGltcGFjdCBl dmVudCByZWNvcmRzIG91dHB1dCBnZW5lcmF0aW9uIGZyb20gYSBwdWJsaXNoZXI7DQoyLiBDbGFy aWZ5IHRoZSBkZWZpbml0aW9uIG9mICd4cGF0aC1leHRlcm5hbC1ldmFsJzsNCjMuIFVzYWdlIGV4 YW1wbGUgdXBkYXRlIHRvIGFsaWduIHRoZSBtb2RlbCBwYXJhbWV0ZXIgY2hhbmdlLg0KVGhlIGRp ZmYgaXM6DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtd2FuZy1uZXRj b25mLWFkYXB0aXZlLXN1YnNjcmlwdGlvbi0wMg0KDQotUWluIChvbiBiZWhhbGYgb2YgYXV0aG9y cykNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBJLUQtQW5ub3VuY2UgW21haWx0bzppLWQt YW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcN Creiy83KsbzkOiAyMDIwxOoxMNTCMTTI1SAyMDoyMA0KytW8/sjLOiBpLWQtYW5ub3VuY2VAaWV0 Zi5vcmcNCtb3zOI6IEktRCBBY3Rpb246IGRyYWZ0LXdhbmctbmV0Y29uZi1hZGFwdGl2ZS1zdWJz Y3JpcHRpb24tMDIudHh0DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZy b20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KDQoNCiAgICAgICAg VGl0bGUgICAgICAgICAgIDogQWRhcHRpdmUgU3Vic2NyaXB0aW9uIHRvIFlBTkcgTm90aWZpY2F0 aW9uDQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IFFpbiBXdQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICBXZWkgU29uZw0KICAgICAgICAgICAgICAgICAgICAgICAgICBMaWFuZyBHZW5nDQog ICAgICAgICAgICAgICAgICAgICAgICAgIFBlbmcgTGl1DQogICAgICAgICAgICAgICAgICAgICAg ICAgIFFpdWZhbmcgTWENCglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC13YW5nLW5ldGNvbmYtYWRh cHRpdmUtc3Vic2NyaXB0aW9uLTAyLnR4dA0KCVBhZ2VzICAgICAgICAgICA6IDIzDQoJRGF0ZSAg ICAgICAgICAgIDogMjAyMC0xMC0xNA0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVm aW5lcyBhIFlBTkcgZGF0YSBtb2RlbCBhbmQgYXNzb2NpYXRlZCBtZWNoYW5pc20NCiAgIGVuYWJs aW5nIHN1YnNjcmliZXIncyBhZGFwdGl2ZSBzdWJzY3JpcHRpb25zIHRvIGEgcHVibGlzaGVyJ3Mg ZXZlbnQNCiAgIHN0cmVhbXMgd2l0aCB2YXJpb3VzIGRpZmZlcmVudCBwZXJpb2QgaW50ZXJ2YWxz IHRvIHJlcG9ydCB1cGRhdGVzLg0KICAgQXBwbHlpbmcgdGhlc2UgZWxlbWVudHMgYWxsb3dzIGJv dGggc3Vic2NyaWJlciBhbmQgcHVibGlzaGVyIHRvDQogICBhdXRvbWF0aWNhbGx5IGFkanVzdCB0 aGUgdm9sdW1lIG9mIHRlbGVtZXRyeSB0cmFmZmljIHNlbnQgZnJvbQ0KICAgcHVibGlzaGVyIHRv IHRoZSByZWNlaXZlcnMuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9y IHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13 YW5nLW5ldGNvbmYtYWRhcHRpdmUtc3Vic2NyaXB0aW9uLw0KDQpUaGVyZSBhcmUgYWxzbyBodG1s aXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtd2FuZy1uZXRjb25mLWFkYXB0aXZlLXN1YnNjcmlwdGlvbi0wMg0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC13YW5nLW5ldGNvbmYtYWRhcHRpdmUtc3Vi c2NyaXB0aW9uLTAyDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWls YWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC13YW5nLW5l dGNvbmYtYWRhcHRpdmUtc3Vic2NyaXB0aW9uLTAyDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255 bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJLUQtQW5ub3Vu Y2UgbWFpbGluZyBsaXN0DQpJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQpJbnRlcm5ldC1EcmFmdCBkaXJlY3Rv cmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCBvciBmdHA6Ly9mdHAuaWV0Zi5v cmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K From nobody Wed Oct 21 14:30:40 2020 Return-Path: <010001754d122531-31e209be-eef2-4a70-bdcd-05ff3c821656-000000@amazonses.watsen.net> 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 EA1663A0991; Wed, 21 Oct 2020 14:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 ohXk7kQQSHOC; Wed, 21 Oct 2020 14:30:37 -0700 (PDT) Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7E93A0982; Wed, 21 Oct 2020 14:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1603315836; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:Cc:To:Feedback-ID; bh=b4pGv5Sn3b48cWKvGH9BRoK1V3/ZXo5GW4t47WCpqh8=; b=Um6EqA1txVvjpn97+EOFvftDspRYfBC6dc9gGstpA2n5tVVzVMRbp9qAXlSwmx+B TL2QZ5/0TooeV571F2IL8xT+xoCqGKoaIL2C9jc9nHgVlnCuOLpDaPaZ3dIr9F/xXh0 ksz5g3J0vlFUbxkslr+uEB3mS3uKautYex6VoFBg= From: Kent Watsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <010001754d122531-31e209be-eef2-4a70-bdcd-05ff3c821656-000000@email.amazonses.com> Date: Wed, 21 Oct 2020 21:30:36 +0000 Cc: "netconf-chairs@ietf.org" To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.10.21-54.240.48.93 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Call for 109 discussion topics X-BeenThere: netconf@ietf.org 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: Wed, 21 Oct 2020 21:30:39 -0000 NETCONF WG, According to the preliminary agenda [1], NETCONF is scheduled to meet = for 2-hours on Wednesday, November 18th from 12:00-14:00 Bangkok time = (UTC +7). If you are interested in discussing one or more topics with the WG, = please send requests to the "netconf-chairs" alias (CC-ed) with the = following information, for each discussion, if more than one: - name of the drafts (if any) - name of discussion topic (usually the title of the draft) - name of the person(s) leading the discussion - desired time request (in minutes) Authors, per the 109 Important Dates page [2], the draft submission = cutoff is in two weeks, on Monday November 2nd. Please be sure to = update your drafts before then. [1] = https://datatracker.ietf.org/meeting/109/agenda.html#2020-11-18-110000 [2] https://datatracker.ietf.org/meeting/109/important-dates NETCONF Chairs= From nobody Wed Oct 21 16:14:03 2020 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2728A3A0A4A; Wed, 21 Oct 2020 16:13:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <160332203609.8285.10849278149356694901@ietfa.amsl.com> Date: Wed, 21 Oct 2020 16:13:56 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-https-notif-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 23:13:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : An HTTPS-based Transport for Configured Subscriptions Authors : Mahesh Jethanandani Kent Watsen Filename : draft-ietf-netconf-https-notif-05.txt Pages : 27 Date : 2020-10-21 Abstract: This document defines a YANG data module for configuring HTTPS based configured subscription, as defined in RFC 8639. The use of HTTPS maximizes transport-level interoperability, while allowing for encoding selection from text, e.g. XML or JSON, to binary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-https-notif-05 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-https-notif-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 21 17:42:16 2020 Return-Path: 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 C1E423A0EB7 for ; Wed, 21 Oct 2020 17:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 4WQGK60HMpiH for ; Wed, 21 Oct 2020 17:42:13 -0700 (PDT) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0087C3A0A3B for ; Wed, 21 Oct 2020 17:41:42 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id hk7so52236pjb.2 for ; Wed, 21 Oct 2020 17:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=pm1d0iMzikYjBi0dUmBukTf0HA7H74YpDM3OHem/HU4=; b=tKoPZbUxWZXULGDUQbHXi028cvWReoccHzkWfmtWoz/Q06o8KGHTYKNy+hpioW58Oq 6At82mRsdWnud7TBthJ7ifQg7keI2UGF/wojPB24N28mNsPAZuXdycmYsn8QSQ3SN9pl ayJN42xIDdu5on+EgQLWPs/MiEzQamIOBvJMAxVtCDLgkfw6tlDWHbc4STWDmGQcuVUj RhrYds2yWdjOtxrxiDTJ/op4bAycqnOAQXT7ibQOsDYek4b/0FNqj6oWzv6ryto4Mhls MapwBoqBLf5jlYABf3WNQ3AhaCCcxZPT6lBPd8ptoQNhG70WikfTC7x7g8BjOzf3WvLt uR3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=pm1d0iMzikYjBi0dUmBukTf0HA7H74YpDM3OHem/HU4=; b=n9Wr2E0IDwTbu+Py/MvEiWox0hKJHBFHCAIRBilK62nMy7Uit6rNmspqQ9UHMB8BNy fE5YyvY2eyuyehhLPW4TTAqfjLZyV2qLbS8F0WlO0cCnqhS+7XyC0BzXs+70tAq/Drpk ig+uRlsGcDP751plVuE6Q1g+rTFIUF5Gbmf+d9O0+d0W4I1mL/13gcWC9I2mcarDroIz 9S1kG2wnQyAy7oUtDBFrdfTlGBV+7k/+aM2aGJVbEVhTgiGXpusUX+oeqXFLD7wgfRhA IQrNglkto7ycuKAjIMGch/PhoUyI27jFdc7y92/koWb+661MUjbnBIhLYCYR4k3MIMEm iYPw== X-Gm-Message-State: AOAM531lkNqg8cpjjEKvK1v0uaHAKOXq01j26TrbbXEXDZ4AyaEvGRlI MrWIbcKUyDfSOFRCdudlNC3df8oMeMY= X-Google-Smtp-Source: ABdhPJz99LUNSez/cwntZGmwyS9ImRx+PSk9C7Rw1PdpSs8usZd4NeFyYX6dKlbY4yyftbNSSbe1FA== X-Received: by 2002:a17:902:d703:b029:d5:b4f4:2a13 with SMTP id w3-20020a170902d703b02900d5b4f42a13mr6205997ply.11.1603327302127; Wed, 21 Oct 2020 17:41:42 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:e0e4:4c5:d4ea:84cb? ([2601:647:5600:5020:e0e4:4c5:d4ea:84cb]) by smtp.gmail.com with ESMTPSA id y4sm64055pjc.53.2020.10.21.17.41.40 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Oct 2020 17:41:41 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_A29EFB94-DE84-4539-9EB4-F7AC48FBCD1D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 21 Oct 2020 17:41:40 -0700 References: <160332203609.8285.10849278149356694901@ietfa.amsl.com> To: Netconf In-Reply-To: <160332203609.8285.10849278149356694901@ietfa.amsl.com> Message-Id: <5F4FD9CB-CD33-47C1-8B32-2BDB0113FCDB@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-05.txt X-BeenThere: netconf@ietf.org 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: Thu, 22 Oct 2020 00:42:15 -0000 --Apple-Mail=_A29EFB94-DE84-4539-9EB4-F7AC48FBCD1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This version of the document addresses the question raised in 108 around = an example for what the encoding would look like. The document carried = an example for JSON encoding, which has been updated to a YANG-Push = example in Section 6, and a corresponding XML example has also been = added. Would like to thank Eric Voit for his help in the updates. Cheers. > On Oct 21, 2020, at 4:13 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Network Configuration WG of the IETF. >=20 > Title : An HTTPS-based Transport for Configured = Subscriptions > Authors : Mahesh Jethanandani > Kent Watsen > Filename : draft-ietf-netconf-https-notif-05.txt > Pages : 27 > Date : 2020-10-21 >=20 > Abstract: > This document defines a YANG data module for configuring HTTPS based > configured subscription, as defined in RFC 8639. The use of HTTPS > maximizes transport-level interoperability, while allowing for > encoding selection from text, e.g. XML or JSON, to binary. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-netconf-https-notif-05 > = https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-https-notif-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_A29EFB94-DE84-4539-9EB4-F7AC48FBCD1D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = version of the document addresses the question raised in 108 around an = example for what the encoding would look like. The document carried an = example for JSON encoding, which has been updated to a YANG-Push example = in Section 6, and a corresponding XML example has also been added.

Would like to thank Eric = Voit for his help in the updates.

Cheers.

On Oct = 21, 2020, at 4:13 PM, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of = the Network Configuration WG of the IETF.

=        Title =           : An = HTTPS-based Transport for Configured Subscriptions
=        Authors =         : Mahesh Jethanandani
=             &n= bsp;           &nbs= p;Kent Watsen
Filename =        : = draft-ietf-netconf-https-notif-05.txt
Pages =           : 27
= Date =            : = 2020-10-21

Abstract:
=   This document defines a YANG data module for configuring = HTTPS based
  configured subscription, as = defined in RFC 8639.  The use of HTTPS
=   maximizes transport-level interoperability, while allowing = for
  encoding selection from text, e.g. =  XML or JSON, to binary.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif= /

There are also htmlized versions = available at:
https://tools.ietf.org/html/draft-ietf-netconf-https-notif-05https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-= notif-05

A diff from the previous version = is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-https-no= tif-05


Please note that it = may take a couple of minutes from the time of submission
until the htmlized version and diff are available at = tools.ietf.org.

Internet-Drafts are also = available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_A29EFB94-DE84-4539-9EB4-F7AC48FBCD1D-- From nobody Fri Oct 23 14:16:18 2020 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A74A3A0F0C; Fri, 23 Oct 2020 14:15:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: netconf@ietf.org, rwilton@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160348774454.5087.5262658939511155576@ietfa.amsl.com> Date: Fri, 23 Oct 2020 14:15:44 -0700 Archived-At: Subject: [netconf] netconf - Requested session has been scheduled for IETF 109 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 21:15:47 -0000 Dear Kent Watsen, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. netconf Session 1 (2:00 requested) Wednesday, 18 November 2020, Session I 1200-1400 Room Name: Room 4 size: 504 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/109/sessions/netconf.ics Request Information: --------------------------------------------------------- Working Group Name: Network Configuration Area Name: Operations and Management Area Session Requester: Kent Watsen Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 65 Conflicts to Avoid: Chair Conflict: netmod tcpm idr Technology Overlap: opsarea opsawg People who must be present: Mahesh Jethanandani Kent Watsen Robert Wilton Resources Requested: Special Requests: First morning session preferred. --------------------------------------------------------- From nobody Mon Oct 26 10:43:04 2020 Return-Path: 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 405033A0E6F for ; Mon, 26 Oct 2020 10:42:55 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 kvkfOR03qmWw for ; Mon, 26 Oct 2020 10:42:53 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2092.outbound.protection.outlook.com [40.107.22.92]) (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 BBF003A0E52 for ; Mon, 26 Oct 2020 10:42:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KzwIKCDLIbNWTgahJlsK06a+RvJLbvr+8xfdFITn/sfVMnvmzqTFIJ84ld8MhdImuriZfyjXJoVO6xf3kpa9XqW81nBWYS+urypgKOt8/x5OHGUf183KJQNXv0Pj2CVKtPz3TemEavPr2MX1lWPeKgoD0CV6EuHE5bMVxPgl0XzfcwzU6f47tbxhjjVDg2ElGfnDNGpBOD1tiMFoiBe8ivH5EeseifNM1a/ZjRkhHIsN7Jh1zMFrIyHAsaEoYLyPshW5z63GN1TvCiam7vF96taxOa1Pgo9npnskS+KdfdcyB9PQq2dBa76FOyLkPmBPkI7oTw4uqmS1uKclQYGN8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XXEGzAqboDs05SjbRvPHs2WzeEY0wcL8UazGJrDDRM0=; b=FgQw1TNWjQoMFCBSMv6rC9hjlAYZv8ZLpFxFPVSqvT0/Ztn19O/8xce2QMwxFVXQAQRnKYuYTVFS3/5x732U82T4rV4jDrkKS4LbK/Sy+vfvVdnTosldJ5SLmpRH31mOFuRTX7fBUcRzXOxs8JoiKhjpeMUd32z3T6NYsAYdcu85MIDO9Y0GZMKVWf+g4TC5x0WpXJq7pyXukbC0TLG4uK1a3ELDQMBKoLILsctBprrp1PJQbIT8THRmm4e5Fw7FejqZYE2XzGvGq3KnMhDZgP3PmryNtrQQW+tawmM0P6W6fUz9KQNXguA3sQfyGQe2UbxYkBjkboACeZ+QGgYxtA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XXEGzAqboDs05SjbRvPHs2WzeEY0wcL8UazGJrDDRM0=; b=is1MXzGcjz2mroS36XMtLI+9e05neYL98TMHO4CMLbVZcMXIfeDvhoawglFbG6v0/mr2yhIWlTZph0k0KkU75mUXBgLtDh4T1SqlrYoHx0AhkKueKKQyOv98lpCfYrdKy2kg7NtPTcgH7JQUl4M23J5UVPPDTuObCOISzjzKE+k= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM6PR07MB3845.eurprd07.prod.outlook.com (2603:10a6:209:35::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.4; Mon, 26 Oct 2020 17:42:50 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::ad44:1086:3767:a804]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::ad44:1086:3767:a804%7]) with mapi id 15.20.3499.019; Mon, 26 Oct 2020 17:42:50 +0000 From: tom petch To: Kent Watsen CC: "netconf@ietf.org" Thread-Topic: Netconf over QUIC Thread-Index: AQHWq78ipVhuz0kW80mk+IBTiIy20A== Date: Mon, 26 Oct 2020 17:42:50 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [86.146.121.140] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 56e5f5b7-8237-4f14-9e7b-08d879d68f22 x-ms-traffictypediagnostic: AM6PR07MB3845: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1bpuYgVzOvOwtO1eCwJeVQpS0Og/qJZ+nWAltwus+kqA8qdWTPGX5Ilh5YzBD7vylTUA9P32OuwBKcdr4PUo3odoNFH0h4R0xTR67uycvS1RFCRNMZnrL1CDSb5uVGfCxz7rLTas3XlZKN1pGhdf9Q8RXFTRXtGtTaQmsEZ395Z/h0Y+MNJ5MAwBxvMYSBgNIwSs7cRnaypij8l1s5foqcEXMACSfhy/UfOItVgM6y+ofiP4CKglylUa1T/gQY+JgnZnQ6CaH9+5tI09ABQbPOl5S2oJ9M1TvrWe4GExdfZaQIsyZh3nq1TSnkLPrppfP4NVC1szv3q22ZQCwFn5fA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(346002)(366004)(136003)(376002)(396003)(186003)(7696005)(4326008)(64756008)(91956017)(2906002)(66476007)(86362001)(316002)(9686003)(66556008)(66946007)(6506007)(52536014)(8936002)(3480700007)(76116006)(558084003)(55016002)(478600001)(33656002)(66446008)(71200400001)(8676002)(7116003)(5660300002)(26005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: JJubf/JEuY9bnXg9GNtlyGY7fB9u+KnY5fMylmiYirAKECvZ7iiL9SEGToOOXul969fY3wWtFnNKSgLWoj2B6B49ceOepRct+mARt++mOyEl32U8jxZ3hKGQe5/UuT26z5luuAIIk3dZHc9MZmz++84Br8vz5STpvgY9SYgw+5EF5IGyWEvAw8wfLLOnvhlRFe7z1byjCZlbTyF0UNjcx6MGVMRYZHu6L8wtRg+J9Bc76ZWvrLJTOpP7jo0BQJaDwnZcoHWjBlCDIwyn3cHZ+4KcMkpwvQn41WzgFYR2DFQ3yweZxGM3Y5byjLDPR/jXIPltcDUnH81oKxpyTST5mpbOpMu+nAJCk381EoXp78Z8b7XOIR67f66bArTypVM1hpGS4g8rg9SBKbmEkEe9I2MBZXGUgKVk8CezBmp5hdnqXfU/H186T+rLRBvqQsjOYrB6m4bVd3yOFwdKjVtNYUdTg2e9Mf6xNyAnjuqLEHWWO4AznEfod/Hfs9aTNnNs99VVFZEFAC+OZ6D+KmDnyDXuC2lVQW/7J6Rn9Sdg9YJ9HlQ/Hc5FlFR4p5ijn7TxAoGpOoJFr3P4RyhP+zUBlm94kcO9I2hBb71qfeIVuyTtsoiH9WJoYa+5gZfn4k3qm+M9xIicB4oqmen4uILYnQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 56e5f5b7-8237-4f14-9e7b-08d879d68f22 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2020 17:42:50.2814 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: F/x1JNqLwic8X53V6r6fI+nvBxOD6ENHFj3CTEgM7xzFzlo70l9NNr4oKfn+NdDr8AKhYQ0e4YsGbvlTgYHATQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB3845 Archived-At: Subject: [netconf] Netconf over QUIC X-BeenThere: netconf@ietf.org 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: Mon, 26 Oct 2020 17:43:02 -0000 I see an I-D aimed at the QUIC WG proposing QUIC as a transport for Netconf= . Is this something that the Netconf WG should be involved in ? I do not = recognise the names of the authors of this I-D!=0A= =0A= Tom Petch= From nobody Mon Oct 26 12:46:20 2020 Return-Path: <0100017566724b83-8a93024f-4c00-45bd-8651-20fc9697ec27-000000@amazonses.watsen.net> 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 ED7CA3A0E84 for ; Mon, 26 Oct 2020 12:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 wzicE1Zq6iHa for ; Mon, 26 Oct 2020 12:46:11 -0700 (PDT) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39E043A0ED6 for ; Mon, 26 Oct 2020 12:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1603741568; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=dFKZRj1lGb4uXdLihHV133tBMWP/MqGew3LchC96cYM=; b=MiYDWMXBDZL/pOo6IKmEQHq5QD2unzrVoX6v0M/iR77knpwdD9OBm640NveKeI9u vuvBqjXDM44Hz2bx4ssnCkyTWVLeIFlJQlzLiyG8IY/iMFqmLmO35PoSReAgtTfsjkZ uy9zBDTqdbenwMHBwN7wWCCqpsnol0m4xCI0XgMw= From: Kent Watsen Message-ID: <0100017566724b83-8a93024f-4c00-45bd-8651-20fc9697ec27-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BCA56FC8-4C85-4D21-BF4D-CC3C19D16AA7" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 26 Oct 2020 19:46:07 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: tom petch References: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.10.26-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Netconf over QUIC X-BeenThere: netconf@ietf.org 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: Mon, 26 Oct 2020 19:46:19 -0000 --Apple-Mail=_BCA56FC8-4C85-4D21-BF4D-CC3C19D16AA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 26, 2020, at 1:42 PM, tom petch wrote: >=20 > I see an I-D aimed at the QUIC WG proposing QUIC as a transport for = Netconf. Is this something that the Netconf WG should be involved in ? = I do not recognise the names of the authors of this I-D! >=20 > Tom Petch I haven=E2=80=99t seen the draft but, per your description, the = NETCONF's charter [1] says that the WG is =E2=80=9Cresponsible=E2=80=9D = for: c) The transports and encodings used by the data model-driven = protocols. I don=E2=80=99t think this is an exclusive responsibility, but it would = be odd for another WG to take on this work (especially without involving = us!), likely to the point of an objection. FWIW, what the CORE WG did is different, as they defined a whole new = protocol (COAP), which happens to resemble RESTCONF. [1] https://datatracker.ietf.org/wg/netconf/about/ = Kent // as co-chair --Apple-Mail=_BCA56FC8-4C85-4D21-BF4D-CC3C19D16AA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 26, 2020, at 1:42 PM, tom petch <ietfc@btconnect.com>= wrote:

I see an I-D aimed at the QUIC WG proposing QUIC as a = transport for Netconf.  Is this something that the Netconf WG = should be involved in ?  I do not recognise the names of the = authors of this I-D!

Tom = Petch


I haven=E2=80=99t seen the draft but, = per your description, the NETCONF's charter [1] says that the WG is = =E2=80=9Cresponsible=E2=80=9D for:

c) The transports and encodings = used by the data model-driven protocols.

I = don=E2=80=99t think this is an exclusive responsibility, but it would be = odd for another WG to take on this work (especially without involving = us!), likely to the point of an objection.

FWIW, what the CORE WG did is = different, as they defined a whole new protocol (COAP), which happens to = resemble RESTCONF.

[1] https://datatracker.ietf.org/wg/netconf/about/

Kent // as = co-chair

= --Apple-Mail=_BCA56FC8-4C85-4D21-BF4D-CC3C19D16AA7-- From nobody Tue Oct 27 10:17:27 2020 Return-Path: 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 21E1F3A1260 for ; Tue, 27 Oct 2020 10:17:26 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=btconnect.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 ElF-bz8TZam1 for ; Tue, 27 Oct 2020 10:17:24 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2111.outbound.protection.outlook.com [40.107.21.111]) (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 ABCD93A125F for ; Tue, 27 Oct 2020 10:17:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Gbd4e9V/t+a+LgyK+B1l2aLHRvVfrFCF0KK1yR0dDc+B2p+JbFMIVRaC3XonUIJJ4xttddqBXEeGgj+Nz7Oh/W6OJSY3h22o5cZNpMq0lpDqRTFJ2QcN6eLRllHv3enPe6LesjD2NpMErfjmcBbChGu1J3VSLombsPJGTBmbWBx4hGoeAQNEo4h53vivdb7AzuDRVzccGHVQV8/Fgr8EKirH37o6VE+emU2zlv+bIcjBLe04cwnbolZy4kiv4I5bZnMS85NGqAeca1+R136ydwLICvf1q0NcPkenCX/0rq+piSO1xCxTgMBN3uCGDU2urkdy74FbDqow/u/qPPgMUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H9ufQcu1P5T4o3navcaFbjPjAnK4zG4axmS7XnUjd4k=; b=KR++oB+lfWpAxWtiD5LMM2DHKvbRzoTDtVDQmm45a9ITvDQ0ZrafZeRWetNuhdK/OWtndJJ7MOuH43CcM6Ywsd6ks7AlpBC62+qoX5vrmB8y04gahlnedJLl+aPBYGMIH6IlhdJq4F/VjgMN9q170AgXJOr15rBAdsefM0gOfangy/ubgXENWOYwIMAQqEwB/VXvdiKTgCmFxoc4TNoJ/4QFJfjmsoU8g0a4FnVRA2ARrNSeUlVnrqoeOBj5gK6mEZ0tAv2jotNExzRbLWYYSTC3ju7+xIjWCX/m2+9v+cT1UkxCWAQABWr224Qgg3qTO6FxFRCchnCnwb4JKN7JEw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H9ufQcu1P5T4o3navcaFbjPjAnK4zG4axmS7XnUjd4k=; b=Q1WDBsofvQIzu/OdZd/aPtxCFEl9cylafJXnlyPa4i8bKTh/wmf4i+6yQsgVo6fw+sRtOrsP98p3HOW622d1gqv6nUP4bIdijYFwPc5BYCNDZ9fq7H88hdvk2OAgGFbaBRtzE/ciTZ9ozTVZBUpaDIyEQVwfcDYROlMb6RsRLxk= Received: from VI1PR07MB6256.eurprd07.prod.outlook.com (2603:10a6:800:133::7) by VI1PR0701MB3056.eurprd07.prod.outlook.com (2603:10a6:800:86::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.6; Tue, 27 Oct 2020 17:17:20 +0000 Received: from VI1PR07MB6256.eurprd07.prod.outlook.com ([fe80::6163:5bba:8389:75f8]) by VI1PR07MB6256.eurprd07.prod.outlook.com ([fe80::6163:5bba:8389:75f8%4]) with mapi id 15.20.3499.015; Tue, 27 Oct 2020 17:17:20 +0000 From: tom petch To: Kent Watsen CC: "netconf@ietf.org" Thread-Topic: Netconf over QUIC Thread-Index: AQHWq78ipVhuz0kW80mk+IBTiIy20KmqScyAgAFoL0o= Date: Tue, 27 Oct 2020 17:17:20 +0000 Message-ID: References: , <0100017566724b83-8a93024f-4c00-45bd-8651-20fc9697ec27-000000@email.amazonses.com> In-Reply-To: <0100017566724b83-8a93024f-4c00-45bd-8651-20fc9697ec27-000000@email.amazonses.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [86.146.121.140] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4b9e6b34-586e-43cc-a068-08d87a9c29dd x-ms-traffictypediagnostic: VI1PR0701MB3056: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OfyZgvCORdLnfbkr3O39UHGG5u4h9OZmBuR3LLLpzjWrNrmpfC0yDZZe+8saRtwP+sULxnvb2ecQ0oq3OI8lRMZoz4YZuhXCmtPfvb3qQkOc81h3nvnEJ+E4PG/YaUOxER9SZB5e+67gDHd4JUaaYu+Tlld3CalcmYavLBny/YutbaO8qu/jfnW31pfCcQKZ5c93iB7zOEOZDWj6D7mXJ+ghI0ghcgUNEk/WSFAcE0sfEV9YuMRz5UPC2htXQMIw0U1+fAq+421i0Zfjp+qFpcj3N7F/O/CFeknCjUdiXosWR/fF42mUi9RdFMjGbrukGLS96F9pyhtWVv16sjHLRHbO8g16TBgF9K4f0Fdkxdq6zueXQYPEZ1kCwcWRQTZv9f0K+k9vAcXDfeh6nwCgbw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6256.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(39860400002)(376002)(346002)(136003)(366004)(7116003)(6506007)(3480700007)(9686003)(26005)(7696005)(53546011)(186003)(33656002)(52536014)(86362001)(2906002)(478600001)(71200400001)(966005)(4326008)(83380400001)(64756008)(55016002)(66446008)(66946007)(66574015)(76116006)(8676002)(5660300002)(66556008)(316002)(91956017)(66476007)(8936002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: rwWhKG2NEGbXDUL6AaPYNANp7Zpx/l71UqCF90PgR6qzfu7QGiOrvDxdGTXw1idhVksZ4rE6SXonjq87PK2YVRZee7SyjfQd1hppvHNmQk/N/NI+h6qGVrJFZBsuvYKjQDF3LwpejWmpdcCogM04w+dXPa+De9ZD21LIcRu6PouHlEVJARcbBOTX3KEeAxqT/Nj5K5p2m7bczyQgMF5MIzZbp/0y5FJGVP2lyzlEjWU1bEubSK+a28l5dfyQSgFzHSnsxAn1S3bi4Dmjls9rpQoUo/dgvc+WHxy4G4ctvDVG+CcJNYJLB0KIxwnmxUTiXcRl4evE2W+WC5TAL/xMM9WxKAc3q/HXXPTPcoKowZ611PNEqK8B9aFgyW0daXnv3xkf6w09Ax+FzHHJExgl67R6LjDChdATLLVhasVow+Rf7pYXsjzfebC2K8THooAZSyAPgcnk167inzIHr9SRh/RzFXQVmtXhP5C+77bRmMK/YNW0wi+eQHo+xryymEgnsKwS55UZvRJJr9hVz6hXi4GJxrqMrpouvLD/hywwgnpWLL/IgJMpJqtl8xF7xcbZUdQvFApbPB+i5ZcSs7uHOIwCjl2rQuNM/4w0eK8r8SctGM8hoX3wBUf5suB+3K6pOXruo6NHL4HorItWmm41iA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6256.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4b9e6b34-586e-43cc-a068-08d87a9c29dd X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2020 17:17:20.7936 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Pp3zY4ewqUaN/jbpn6wEOblEPqiRwt8AoB0DxelYrM6hQuXcy4yjkTq02U9H7pSMVEiO5cg03n69cNCSWh7JNA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3056 Archived-At: Subject: Re: [netconf] Netconf over QUIC X-BeenThere: netconf@ietf.org 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: Tue, 27 Oct 2020 17:17:26 -0000 From: Kent Watsen =0A= Sent: 26 October 2020 19:46=0A= =0A= On Oct 26, 2020, at 1:42 PM, tom petch > wrote:=0A= =0A= I see an I-D aimed at the QUIC WG proposing QUIC as a transport for Netconf= . Is this something that the Netconf WG should be involved in ? I do not = recognise the names of the authors of this I-D!=0A= =0A= Tom Petch=0A= =0A= =0A= Kent =0A= some more details=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= Network Working Group J. Dai=0A= INTERNET-DRAFT X. Wang=0A= Intended Status: Proposed Standard Y. Kou=0A= Expires: April 26, 2021 L. Zhou=0A= China Information Communication Technologies Group=0A= October 26, 2020=0A= =0A= Using NETCONF over QUIC connection =0A= draft-dai-quic-netconf-03=0A= =0A= Abstract=0A= =0A= The Network Configuration Protocol (NETCONF) provides mechanisms to =0A= install, manipulate, and delete the configuration of network devices.=0A= At present, almost all implementations of NETCONF are based on TCP =0A= based protocol. QUIC, a new UDP-based transport protocol, can =0A= facilitate to improve the transportation performance, information =0A= security and resource utility when being used as an infrastructure layer= =0A= of NETCONF. This document describes how to use the QUIC protocol as the = =0A= transport protocol of NETCONF(It is so called NETCONFoQUIC).=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= =0A= Tom Petch=0A= =0A= I haven=92t seen the draft but, per your description, the NETCONF's charter= [1] says that the WG is =93responsible=94 for:=0A= =0A= c) The transports and encodings used by the data model-driven protocols.=0A= =0A= I don=92t think this is an exclusive responsibility, but it would be odd fo= r another WG to take on this work (especially without involving us!), likel= y to the point of an objection.=0A= =0A= FWIW, what the CORE WG did is different, as they defined a whole new protoc= ol (COAP), which happens to resemble RESTCONF.=0A= =0A= [1] https://datatracker.ietf.org/wg/netconf/about/=0A= =0A= Kent // as co-chair=0A= =0A= From nobody Tue Oct 27 10:19:57 2020 Return-Path: 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 EAA873A125F for ; Tue, 27 Oct 2020 10:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 kOAfKc3yICMG for ; Tue, 27 Oct 2020 10:19:55 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 241D13A1237 for ; Tue, 27 Oct 2020 10:19:54 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 09RHBhb5016068; Tue, 27 Oct 2020 17:19:45 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=VeQnJonx3NeRbOAol/anEzORCy90jVgSuRcD75TzQnw=; b=X+67YYmLXxA4bn/VUL8z6qwdBYtQyZRRBBTUjfLJJugDcVOvvO7TIQW15llFHohiJWOT 4eczTyfE4pagjzfQLxKqXOYtQD8WJk8+KGCz7vXTLc69KW2Nz1mBIJRob3eONlYqDYMP XBJtl/YXvw5GUDGyL6/GAwwIIfv7BroAqBclJL5bE9lDg1qRiQxv+jBGZVcIR5u2GUMn ZUQXruEd10CbiRVWn5aAeL75BMHR1eALMsntXy2cwByXNs2pviTZDSeIE5xahD0HKR42 sg9til3P08EsQ6sqDieCPfe/ISAQHLSs3rJIQHU9MhRZuhkri4MufKbQSX4yAhsrKad1 IQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 34cces0cdm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Oct 2020 17:19:45 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 09RH53RT007228; Tue, 27 Oct 2020 13:19:44 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 34cfkxxst3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 27 Oct 2020 13:19:44 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 27 Oct 2020 13:19:43 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1497.007; Tue, 27 Oct 2020 13:19:43 -0400 From: "Salz, Rich" To: tom petch , Kent Watsen CC: "netconf@ietf.org" Thread-Topic: [netconf] Netconf over QUIC Thread-Index: AQHWrIVbpVhuz0kW80mk+IBTiIy20A== Date: Tue, 27 Oct 2020 17:19:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.42.20101102 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-10-27_10:2020-10-26, 2020-10-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxscore=0 suspectscore=0 adultscore=0 phishscore=0 mlxlogscore=591 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010270102 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-10-27_10:2020-10-26, 2020-10-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=552 impostorscore=0 bulkscore=0 phishscore=0 mlxscore=0 spamscore=0 clxscore=1011 adultscore=0 malwarescore=0 priorityscore=1501 suspectscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010270103 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.18) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint1 Archived-At: Subject: Re: [netconf] Netconf over QUIC X-BeenThere: netconf@ietf.org 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: Tue, 27 Oct 2020 17:19:56 -0000 SXQgc2hvdWxkIGJlIHByZXR0eSBzaW1wbGUgdG8gY29udGFjdCB0aGUgUVVJQyBjaGFpcnMgYW5k IGFzayB0aGVtIHRvIHNlbmQgdGhlIGF1dGhvcnMgb3ZlciBoZXJlLg0KDQo= From nobody Wed Oct 28 17:33:02 2020 Return-Path: <0100017571c59d4d-f1032aa5-103d-4443-933e-4db30f2ef641-000000@amazonses.watsen.net> 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 27AB13A03F3 for ; Wed, 28 Oct 2020 17:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 tInjFW-trldb for ; Wed, 28 Oct 2020 17:32:59 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 128D63A0039 for ; Wed, 28 Oct 2020 17:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1603931577; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=qdTlQCFsaszutKQsACHrDK0Ryl2zelvK8KKIT4R3Omw=; b=RJoe5xi3R64bmvlPmbx/kA0ww8Mx3qE0BHA0gpM3QKne27nmGKWvRQu2XJ3vT1eG AAPQjpQWCFErdSyT4LfCLB1qR8hcvFUUxGOfeD0+GIgqucCX2Qo5zZfCjZWSny51RvL LUg+mUSLqi7QAS+srIKuWvOIdnU2r4/ra1lkW+Yg= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_B5B43C4F-44FC-436A-9134-57DF603A074C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 29 Oct 2020 00:32:57 +0000 References: <01000174e4610ae6-d1488376-ae7e-4d95-ba7e-005fc44b9592-000000@email.amazonses.com> <20201001.165548.1275939966226069939.id@4668.se> <01000174e5ba8cc5-39edb446-48d9-4896-a6b5-dcf80f962762-000000@email.amazonses.com> <20201002.082331.2242297379846191383.id@4668.se> <01000174e96cd06f-4ecb06ac-c7ac-4233-bd5d-97d3dbc74830-000000@email.amazonses.com> <01000174e9c75096-5f451248-48e7-4add-a56b-9789cddd3e56-000000@email.amazonses.com> To: "netconf@ietf.org" In-Reply-To: Message-ID: <0100017571c59d4d-f1032aa5-103d-4443-933e-4db30f2ef641-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.10.29-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org 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: Thu, 29 Oct 2020 00:33:01 -0000 --Apple-Mail=_B5B43C4F-44FC-436A-9134-57DF603A074C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [Update: a spinoff team has formed and is working on two I-D=E2=80=99s] One issue has come up, regarding the encoding when GET returns a list or = leaf-leaf. Generally, in RFC 8040, GET returns an instance of the targeted = resource. This continues to be possible with JSON, as the = list/leaf-list is a JSON array, but no array-equivalent exists with XML. = =20 This is likely why Section 4.3 states "More than one element MUST NOT be = returned for XML encoding=E2=80=9D, though this statement never needed = to be said, as there is no case where more than one element would be = returned anyway! This intent of this email is to discuss changing that statement in 4.3, = that is, to allow more than one element to be returned for the XML = encoding. Following are what I hope the WG can agree on being valid responses: =3D=3D=3D=3D=3D JSON =3D=3D=3D=3D=3D REQUEST GET = /restconf/data/example-jukebox:jukebox/library/artist?where=3D Host: example.com Accept: application/yang-data+json RESPONSE-1 (list exists, but no matching content) HTTP/1.1 204 No Content Date: Thu, 26 Jan 2017 20:56:30 GMT Server: example-server RESPONSE-2 (matching content) HTTP/1.1 200 OK Date: Thu, 26 Jan 2017 20:56:30 GMT Server: example-server Content-Type: application/yang-data+json { "example-jukebox:artist=E2=80=9D: [ { =E2=80=9Cname=E2=80=9D: "Foo Fighters=E2=80=9D, =E2=80=9Calbum=E2=80=9D: { =E2=80=9Cname=E2=80=9D: "One by One=E2=80=9D, =E2=80=9Cyear=E2=80=9D: 2012 } }, { =E2=80=9Cname=E2=80=9D: "Nick Cave and the Bad Seeds=E2=80=9D, =E2=80=9Calbum=E2=80=9D: { =E2=80=9Cname=E2=80=9D: "Tender Pre=E2=80=9D, =E2=80=9Cyear=E2=80=9D: 1988 } } ] } =3D=3D=3D=3D=3D XML =3D=3D=3D=3D=3D REQUEST GET = /restconf/data/example-jukebox:jukebox/library/artist?where=3D Host: example.com Accept: application/yang-data+xml RESPONSE-1 (list exists, but no matching content) HTTP/1.1 204 No Content Date: Thu, 26 Jan 2017 20:56:30 GMT Server: example-server RESPONSE-2 (matching content) HTTP/1.1 200 OK Date: Thu, 26 Jan 2017 20:56:30 GMT Server: example-server Content-Type: application/yang-data+xml Foo Fighters One by One 2012 Nick Cave and the Bad Seeds Tender Prey 1988 Thoughts? If no objection, we will proceed as per above. PS: I am aware, of course, of the pseudo-parent element = (=E2=80=9Ccollection=E2=80=9D) defined in in = draft-ietf-netconf-restconf-collection. The hope is to avoid needing to = introduce a pseudo element, as the above seems simpler, more consistent, = and without issues, other than requiring that statement in Section 4.3 = to be rescinded. K. --Apple-Mail=_B5B43C4F-44FC-436A-9134-57DF603A074C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 [Update: a spinoff team has formed and is working on two = I-D=E2=80=99s]

One issue has come up, = regarding the encoding when GET returns a list or leaf-leaf.

Generally, in RFC 8040, GET returns an = instance of the targeted resource.  This continues to be possible = with JSON, as the list/leaf-list is a JSON array, but no = array-equivalent exists with XML.  

This is likely why Section 4.3 states "More than = one element MUST NOT be returned for XML encoding=E2=80=9D, though this = statement never needed to be said, as there is no case where more = than one element would be returned anyway!

This intent = of this email is to discuss changing that statement in 4.3, that is, to = allow more than one element to be returned for the XML = encoding.

Following are what I hope the WG can agree on being valid = responses:

=3D=3D=3D=3D=3D JSON =3D=3D=3D=3D=3D=


 REQUEST

  =   GET = /restconf/data/example-jukebox:jukebox/library/artist?where=3D<expr>=
  =   Host: example.com
    Accept: = application/yang-data+json


 RESPONSE-1 = (list exists, but no matching content)

 =   HTTP/1.1 204 No Content
    Date: Thu, = 26 Jan 2017 20:56:30 GMT
    Server: = example-server


 RESPONSE-2 (matching content)

    HTTP/1.1 200 OK
  =   Date: Thu, 26 Jan 2017 20:56:30 GMT
    = Server: example-server
    Content-Type: = application/yang-data+json

    = {
      "example-jukebox:artist=E2=80=9D: = [
        {
  =        =E2=80=9Cname=E2=80=9D: "Foo Fighters=E2=80=9D,=
          =E2=80=9Calbum=E2=80= =9D: {
            = =E2=80=9Cname=E2=80=9D: "One by One=E2=80=9D,
  =           =E2=80=9Cyear=E2=80=9D: = 2012
  =         }

        },
    =     {
          = =E2=80=9Cname=E2=80=9D: "Nick Cave and the Bad Seeds=E2=80=9D,
          =E2=80=9Calbum=E2=80=9D: = {
            =E2=80=9Cname=E2= =80=9D: "Tender Pre=E2=80=9D,
        =     =E2=80=9Cyear=E2=80=9D: 1988
    =       }
        }
      ]
    }



=3D=3D=3D=3D=3D = XML =3D=3D=3D=3D=3D


  = REQUEST

    GET = /restconf/data/example-jukebox:jukebox/library/artist?where=3D<expr>=
  =   Host: example.com
    Accept: = application/yang-data+xml


  RESPONSE-1 = (list exists, but no matching content)

 =   HTTP/1.1 204 No Content
    Date: Thu, = 26 Jan 2017 20:56:30 GMT
    Server: = example-server


  = RESPONSE-2 (matching content)

  =   HTTP/1.1 200 OK
    Date: Thu, 26 = Jan 2017 20:56:30 GMT
    Server: = example-server
    Content-Type: = application/yang-data+xml

    = <artist xmlns=3D"https://example.com/ns/example-jukebox">
      <name>Foo = Fighters</name>
      <album>
        <name>One by = One</name>
        = <year>2012</year>
      </album>
    = </artist>
  =   <artist xmlns=3D"https://example.com/ns/example-jukebox">
  =     <name>Nick Cave and the Bad = Seeds</name>
      <album>
        <name>Tender = Prey</name>
        = <year>1988</year>
      </album>
    = </artist>



Thoughts?  If no = objection, we will proceed as per above.

PS: I am aware, of course, = of the pseudo-parent element (=E2=80=9Ccollection=E2=80=9D) defined in = in draft-ietf-netconf-restconf-collection.  The hope is to avoid = needing to introduce a pseudo element, as the above seems simpler, more = consistent, and without issues, other than requiring that statement in = Section 4.3 to be rescinded.


K.


= --Apple-Mail=_B5B43C4F-44FC-436A-9134-57DF603A074C-- From nobody Thu Oct 29 00:51:15 2020 Return-Path: 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 1181A3A0B8E for ; Thu, 29 Oct 2020 00:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.999, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=eZjJ5FxD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GXXRYbvs 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 R2PcT3-STv_r for ; Thu, 29 Oct 2020 00:51:11 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4858F3A0B72 for ; Thu, 29 Oct 2020 00:51:11 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id A06075C006F; Thu, 29 Oct 2020 03:51:10 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 29 Oct 2020 03:51:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm3; bh= +nwcrWagG2XZRbqyP1NLAsJe27KM3oc2B4RysbZFgaU=; b=eZjJ5FxDPFVg8BBk XT4dN109/Hqtd68aWvEytdQSn47TBOD3UIcz1Q5vPxtKzaPOiZw18cB53qnB69Yd 0674KPHJDCOfeASDWz4DFmCMQ3qYss0r0dd029PUlHsJEJRZ0YLhFnqN1dvUDZeB V+cGK0XWcrpuan3fiDLMS1OvjsKRml9cQPbXDQiAcmhkQqvdvT2bqRGEsYFZKwIt FZczO1WVDte2zraeCzRwudp/Ird3d4SXlQ0d7vCOBfjc5w7/DEzfFbX/RpzCQkHi +k7zteG/dOp+YAq94GujfCR5/IsJp/gMutMrJ2qr4RFquYZI2tXHUx3MIBcPNmL+ GEqr3A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=+nwcrWagG2XZRbqyP1NLAsJe27KM3oc2B4RysbZFg aU=; b=GXXRYbvsaNw4FNJhSEU0HHPgTG3FjvBEyyiI1B/kcGY5EqB2RuKpbl8wG w6nwbWNILqlUI21mlQcLMsAaGyYQU0ETs2PwZsJZlyWu6aAx6zxiKEeuwrMcJB/J bqnaO23VtGI4lGzDR/gxo7ig2NGkQF5d5178L/Mi+I8vS7aSQbAM3+Ltaufxiyzn GXuTdrGyOfIcG36BRgtc7KI/mBS7CKEe7WSZvrZa0POmkoWGxCMnOHRv3wHZ93rY QO5fHgA10JWEhxvH69TAo4S2dPQUnkwVXGqZ2B+OOsj6bax74xmYXC/R2dpe8pVu 2BIp+LuMe9/g4ud7pFJB3xuIi8UdQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrledvgddufeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtsg ertdertdejnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepiefhtddvgeffvdelveevle egffevheeghfeujefhteeiueduudevgfeiieffhefgnecuffhomhgrihhnpegvgigrmhhp lhgvrdgtohhmnecukfhppedvuddvrddvudegrdduuddriedtnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgsjhdoihgvthhfseegieeikedr shgv X-ME-Proxy: Received: from localhost (212-214-11-60-static.se.customer.tele2.net [212.214.11.60]) by mail.messagingengine.com (Postfix) with ESMTPA id 9230D3280059; Thu, 29 Oct 2020 03:51:09 -0400 (EDT) Date: Thu, 29 Oct 2020 08:51:08 +0100 (CET) Message-Id: <20201029.085108.142889809049265936.id@4668.se> To: kent+ietf@watsen.net Cc: netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <0100017571c59d4d-f1032aa5-103d-4443-933e-4db30f2ef641-000000@email.amazonses.com> References: <01000174e9c75096-5f451248-48e7-4add-a56b-9789cddd3e56-000000@email.amazonses.com> <0100017571c59d4d-f1032aa5-103d-4443-933e-4db30f2ef641-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org 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: Thu, 29 Oct 2020 07:51:14 -0000 S2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0PiB3cm90ZToNCj4gW1VwZGF0ZTogYSBz cGlub2ZmIHRlYW0gaGFzIGZvcm1lZCBhbmQgaXMgd29ya2luZyBvbiB0d28gSS1E4oCZc10NCj4g DQo+IE9uZSBpc3N1ZSBoYXMgY29tZSB1cCwgcmVnYXJkaW5nIHRoZSBlbmNvZGluZyB3aGVuIEdF VCByZXR1cm5zIGEgbGlzdA0KPiBvciBsZWFmLWxlYWYuDQo+IA0KPiBHZW5lcmFsbHksIGluIFJG QyA4MDQwLCBHRVQgcmV0dXJucyBhbiBpbnN0YW5jZSBvZiB0aGUgdGFyZ2V0ZWQNCj4gcmVzb3Vy Y2UuICBUaGlzIGNvbnRpbnVlcyB0byBiZSBwb3NzaWJsZSB3aXRoIEpTT04sIGFzIHRoZQ0KPiBs aXN0L2xlYWYtbGlzdCBpcyBhIEpTT04gYXJyYXksIGJ1dCBubyBhcnJheS1lcXVpdmFsZW50IGV4 aXN0cyB3aXRoDQo+IFhNTC4NCj4gDQo+IFRoaXMgaXMgbGlrZWx5IHdoeSBTZWN0aW9uIDQuMyBz dGF0ZXMgIk1vcmUgdGhhbiBvbmUgZWxlbWVudCBNVVNUIE5PVA0KPiBiZSByZXR1cm5lZCBmb3Ig WE1MIGVuY29kaW5n4oCdLCB0aG91Z2ggdGhpcyBzdGF0ZW1lbnQgbmV2ZXIgbmVlZGVkIHRvDQo+ IGJlIHNhaWQsIGFzIHRoZXJlIGlzIG5vIGNhc2Ugd2hlcmUgbW9yZSB0aGFuIG9uZSBlbGVtZW50 IHdvdWxkIGJlDQo+IHJldHVybmVkIGFueXdheSENCj4gDQo+IFRoaXMgaW50ZW50IG9mIHRoaXMg ZW1haWwgaXMgdG8gZGlzY3VzcyBjaGFuZ2luZyB0aGF0IHN0YXRlbWVudCBpbg0KPiA0LjMsIHRo YXQgaXMsIHRvIGFsbG93IG1vcmUgdGhhbiBvbmUgZWxlbWVudCB0byBiZSByZXR1cm5lZCBmb3Ig dGhlDQo+IFhNTCBlbmNvZGluZy4NCj4gDQo+IEZvbGxvd2luZyBhcmUgd2hhdCBJIGhvcGUgdGhl IFdHIGNhbiBhZ3JlZSBvbiBiZWluZyB2YWxpZCByZXNwb25zZXM6DQo+IA0KPiA9PT09PSBKU09O ID09PT09DQo+IA0KPiANCj4gIFJFUVVFU1QNCj4gDQo+ICAgICBHRVQgL3Jlc3Rjb25mL2RhdGEv ZXhhbXBsZS1qdWtlYm94Omp1a2Vib3gvbGlicmFyeS9hcnRpc3Q/d2hlcmU9PGV4cHI+DQo+ICAg ICBIb3N0OiBleGFtcGxlLmNvbQ0KPiAgICAgQWNjZXB0OiBhcHBsaWNhdGlvbi95YW5nLWRhdGEr anNvbg0KPiANCj4gDQo+ICBSRVNQT05TRS0xIChsaXN0IGV4aXN0cywgYnV0IG5vIG1hdGNoaW5n IGNvbnRlbnQpDQo+IA0KPiAgICAgSFRUUC8xLjEgMjA0IE5vIENvbnRlbnQNCj4gICAgIERhdGU6 IFRodSwgMjYgSmFuIDIwMTcgMjA6NTY6MzAgR01UDQo+ICAgICBTZXJ2ZXI6IGV4YW1wbGUtc2Vy dmVyDQo+IA0KPiANCj4gIFJFU1BPTlNFLTIgKG1hdGNoaW5nIGNvbnRlbnQpDQo+IA0KPiAgICAg SFRUUC8xLjEgMjAwIE9LDQo+ICAgICBEYXRlOiBUaHUsIDI2IEphbiAyMDE3IDIwOjU2OjMwIEdN VA0KPiAgICAgU2VydmVyOiBleGFtcGxlLXNlcnZlcg0KPiAgICAgQ29udGVudC1UeXBlOiBhcHBs aWNhdGlvbi95YW5nLWRhdGEranNvbg0KPiANCj4gICAgIHsNCj4gICAgICAgImV4YW1wbGUtanVr ZWJveDphcnRpc3TigJ06IFsNCj4gICAgICAgICB7DQo+ICAgICAgICAgIOKAnG5hbWXigJ06ICJG b28gRmlnaHRlcnPigJ0sDQo+ICAgICAgICAgICDigJxhbGJ1beKAnTogew0KPiAgICAgICAgICAg ICDigJxuYW1l4oCdOiAiT25lIGJ5IE9uZeKAnSwNCj4gICAgICAgICAgICAg4oCceWVhcuKAnTog MjAxMg0KPiAgICAgICAgICAgfQ0KPiANCj4gICAgICAgICB9LA0KPiAgICAgICAgIHsNCj4gICAg ICAgICAgIOKAnG5hbWXigJ06ICJOaWNrIENhdmUgYW5kIHRoZSBCYWQgU2VlZHPigJ0sDQo+ICAg ICAgICAgICDigJxhbGJ1beKAnTogew0KPiAgICAgICAgICAgICDigJxuYW1l4oCdOiAiVGVuZGVy IFByZeKAnSwNCj4gICAgICAgICAgICAg4oCceWVhcuKAnTogMTk4OA0KPiAgICAgICAgICAgfQ0K PiAgICAgICAgIH0NCj4gICAgICAgXQ0KPiAgICAgfQ0KPiANCj4gDQo+IA0KPiA9PT09PSBYTUwg PT09PT0NCj4gDQo+IA0KPiAgIFJFUVVFU1QNCj4gDQo+ICAgICBHRVQgL3Jlc3Rjb25mL2RhdGEv ZXhhbXBsZS1qdWtlYm94Omp1a2Vib3gvbGlicmFyeS9hcnRpc3Q/d2hlcmU9PGV4cHI+DQo+ICAg ICBIb3N0OiBleGFtcGxlLmNvbQ0KPiAgICAgQWNjZXB0OiBhcHBsaWNhdGlvbi95YW5nLWRhdGEr eG1sDQo+IA0KPiANCj4gICBSRVNQT05TRS0xIChsaXN0IGV4aXN0cywgYnV0IG5vIG1hdGNoaW5n IGNvbnRlbnQpDQo+IA0KPiAgICAgSFRUUC8xLjEgMjA0IE5vIENvbnRlbnQNCj4gICAgIERhdGU6 IFRodSwgMjYgSmFuIDIwMTcgMjA6NTY6MzAgR01UDQo+ICAgICBTZXJ2ZXI6IGV4YW1wbGUtc2Vy dmVyDQo+IA0KPiANCj4gICBSRVNQT05TRS0yIChtYXRjaGluZyBjb250ZW50KQ0KPiANCj4gICAg IEhUVFAvMS4xIDIwMCBPSw0KPiAgICAgRGF0ZTogVGh1LCAyNiBKYW4gMjAxNyAyMDo1NjozMCBH TVQNCj4gICAgIFNlcnZlcjogZXhhbXBsZS1zZXJ2ZXINCj4gICAgIENvbnRlbnQtVHlwZTogYXBw bGljYXRpb24veWFuZy1kYXRhK3htbA0KPiANCj4gICAgIDxhcnRpc3QgeG1sbnM9Imh0dHBzOi8v ZXhhbXBsZS5jb20vbnMvZXhhbXBsZS1qdWtlYm94Ij4NCj4gICAgICAgPG5hbWU+Rm9vIEZpZ2h0 ZXJzPC9uYW1lPg0KPiAgICAgICA8YWxidW0+DQo+ICAgICAgICAgPG5hbWU+T25lIGJ5IE9uZTwv bmFtZT4NCj4gICAgICAgICA8eWVhcj4yMDEyPC95ZWFyPg0KPiAgICAgICA8L2FsYnVtPg0KPiAg ICAgPC9hcnRpc3Q+DQo+ICAgICA8YXJ0aXN0IHhtbG5zPSJodHRwczovL2V4YW1wbGUuY29tL25z L2V4YW1wbGUtanVrZWJveCI+DQo+ICAgICAgIDxuYW1lPk5pY2sgQ2F2ZSBhbmQgdGhlIEJhZCBT ZWVkczwvbmFtZT4NCj4gICAgICAgPGFsYnVtPg0KPiAgICAgICAgIDxuYW1lPlRlbmRlciBQcmV5 PC9uYW1lPg0KPiAgICAgICAgIDx5ZWFyPjE5ODg8L3llYXI+DQo+ICAgICAgIDwvYWxidW0+DQo+ ICAgICA8L2FydGlzdD4NCj4gDQo+IA0KPiANCj4gVGhvdWdodHM/ICBJZiBubyBvYmplY3Rpb24s IHdlIHdpbGwgcHJvY2VlZCBhcyBwZXIgYWJvdmUuDQo+IA0KPiBQUzogSSBhbSBhd2FyZSwgb2Yg Y291cnNlLCBvZiB0aGUgcHNldWRvLXBhcmVudCBlbGVtZW50ICjigJxjb2xsZWN0aW9u4oCdKQ0K PiBkZWZpbmVkIGluIGluIGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1jb2xsZWN0aW9uLiAg VGhlIGhvcGUgaXMgdG8NCj4gYXZvaWQgbmVlZGluZyB0byBpbnRyb2R1Y2UgYSBwc2V1ZG8gZWxl bWVudCwgYXMgdGhlIGFib3ZlIHNlZW1zDQo+IHNpbXBsZXIsIG1vcmUgY29uc2lzdGVudCwgYW5k IHdpdGhvdXQgaXNzdWVzLCBvdGhlciB0aGFuIHJlcXVpcmluZw0KPiB0aGF0IHN0YXRlbWVudCBp biBTZWN0aW9uIDQuMyB0byBiZSByZXNjaW5kZWQuDQoNClRoaXMgaXMgbm90IGEgZ29vZCBwcm9w b3NhbCwgc2luY2UgdGhlIHJlc3VsdCBpcyBub3QgYSB2YWxpZCBYTUwNCmRvY3VtZW50LiAgQW4g WE1MIGRvY3VtZW50IGhhcyBleGFjdGx5IG9uZSByb290IGVsZW1lbnQuDQoNCkFsc28sIHRoZSBt ZWRpYSB0eXBlcyB1c2VkIGluIHRoZSBleGFtcGxlcyBhcmUgbWlzbGVhZGluZy4gIFRoZQ0KZXhh bXBsZSByZXBseSBkb2Vzbid0IG1hdGNoIHRoZSBtZWRpYSB0eXBlDQoiYXBwbGljYXRpb24veWFu Zy1kYXRhK2pzb24iIChzYW1lIGZvciB4bWwpLg0KDQpJIHN1Z2dlc3QgeW91IGRlZmluZSBuZXcg bWVkaWEgdHlwZXMgYW5kIGEgImNvbGxlY3Rpb24iIHJvb3QNCmVsZW1lbnQ7IG9yIGtlZXAgdGhl IG1lZGlhIHR5cGVzIGFuZCBkZWZpbmUgImNvbGxlY3Rpb24iIGluIGEgWUFORw0KbW9kdWxlIGFz Og0KDQogIGFueWRhdGEgY29sbGVjdGlvbjsNCg0KDQovbWFydGluDQo= From nobody Thu Oct 29 09:05:17 2020 Return-Path: <01000175751b1e3f-d4a84796-9f90-49eb-bbea-d3be5966f233-000000@amazonses.watsen.net> 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 5211B3A083F for ; Thu, 29 Oct 2020 09:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 cIqykY3wU6ee for ; Thu, 29 Oct 2020 09:05:14 -0700 (PDT) Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E763A07BD for ; Thu, 29 Oct 2020 09:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1603987513; h=Content-Type:Content-Transfer-Encoding:From:Mime-Version:Subject:Date:Message-Id:References:Cc:In-Reply-To:To:Feedback-ID; bh=a6ZCE0AZ9w88Sj0lgKHy2sUTpfcC58fse5bWnakJAiY=; b=YsS4XbPU7t9bRWLVFsykDZUh2Em7v9CyoGjR86ovgNyON92s082ZqPInivq57h3U 1DdLSuOvXZ3dCurGjmaATov13g5l2CzT5kd4UlXYdtMY2aQf+z/q5ugYe/d+AKcO4na U28IYV1QgEa74H9KPwpGAjYsdJqK6KBpGvZ7ecFY= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Kent Watsen Mime-Version: 1.0 (1.0) Date: Thu, 29 Oct 2020 16:05:13 +0000 Message-ID: <01000175751b1e3f-d4a84796-9f90-49eb-bbea-d3be5966f233-000000@email.amazonses.com> References: <20201029.085108.142889809049265936.id@4668.se> Cc: netconf@ietf.org In-Reply-To: <20201029.085108.142889809049265936.id@4668.se> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: iPhone Mail (18A393) X-SES-Outgoing: 2020.10.29-54.240.48.110 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org 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: Thu, 29 Oct 2020 16:05:15 -0000 Hi Martin, > This is not a good proposal, since the result is not a valid XML > document. =20 How is this important? It=E2=80=99s not an HTTP-constraint, right? and I d= on=E2=80=99t think it is needed for message-framing either. =20 I guess, as you mention below, the media-type is inappropriate (though 11.3.= 1 isn=E2=80=99t as clear as one might hope), so maybe the response is okay i= f only changing the media type? > An XML document has exactly one root element. >=20 > Also, the media types used in the examples are misleading. The > example reply doesn't match the media type > "application/yang-data+json" (same for xml). How isn=E2=80=99t the media-type okay for JSON, for the response in the prev= ious message? It seems valid to me... No dispute regarding the XML media-type. =20 > I suggest you define new media types and a "collection" root > element; or keep the media types and define "collection" in a YANG > module as: >=20 > anydata collection; Noted, but first would like to understand why simply changing the media-type= alone (while keeping the responses in the previous message) isn=E2=80=99t s= ufficient, for both xml and json.=20 Each media-type can define its own format so, e.g., =E2=80=9Capplication/yan= g-data+xml-list" could be used to define a list of XML documents, right? That said, I acknowledge that having a root-element may aid xml-parsers, and= thus perhaps worthwhile for that reason...just want to ensure we understand= the motivations accurately. K.=20= From nobody Thu Oct 29 09:22:27 2020 Return-Path: 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 546323A09EF for ; Thu, 29 Oct 2020 09:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.999, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=FCtNUxhb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Tu3z2Iel 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 r_-Tq6KVbpOe for ; Thu, 29 Oct 2020 09:22:24 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE223A09E7 for ; Thu, 29 Oct 2020 09:22:24 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 498897BC; Thu, 29 Oct 2020 12:22:23 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 29 Oct 2020 12:22:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm3; bh= fPDCqfq4eUXn3KhsW8NRdD6KPeKkZAihDKWmRAkxfps=; b=FCtNUxhbQo/g497J WmzF14s5hQSXYHdMBSQhjPo5uIrnmTlC2cZrzvoayGyKtcHMZcndXu069l2usr84 wWV0rX83yHql63LvLt6P/W4kzR5e/rHUkXWwgBfrjfznSlaxxHXrF3gIuOenyFoc MUvLiBCKFYqc48TwiJlBA2TXYe6e5qgTTmih7zrADB3MpNg6D/dHnyintAby20Xe AFciZN3pRb6+cz3844B2F7h+oIwnrzhytAvQDu30IQpaCGF/WwHslwVVyGxMr0ff ZgGg1dO+8e4pKhe01/NUdL47ci9ZaAf1eJFISK3A8J0atdrieezrB0b+kMtGiyEf OFch0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=fPDCqfq4eUXn3KhsW8NRdD6KPeKkZAihDKWmRAkxf ps=; b=Tu3z2IeliF5UnN+VnLlB22JSgevkcFBr6S6nPlOxa0gOHm4GlEpE4q12T kCBRt8G2/RPN4/dRWVHEgBJSbYwNGybsDH1+8AqLaEaO73bnBCsOWn4ndUCLll9G 6bnqJSZEXaWutcAu3aTqIXgCLxFs4WW9WR56diKYhIytrF1qRu/vIj+pAYILi9l1 yZMqW/E8R8KAO3jx2bgmgy+1yMlLVnrpDO+1VQGxzcTPxI9Pqaj7GrrRuoUwBNmL UnIJ+H72FjfAiAhVrA+SCPzBptL7fZmv0RnZeiMxWE5csfjgC/vWg8n2jCzlMGe2 ctZR7y880Zzg1fI46te0ESPaTz7mA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrleefgdekjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesthgsre dtredtjeenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdoihgv thhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeehteegtdffgfegffekvdejke evleetuedutddtfffhlefgtedvveehvdeguedtudenucfkphepvdduvddrvddugedruddu rdeitdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmsghjodhivghtfhesgeeiieekrdhsvg X-ME-Proxy: Received: from localhost (212-214-11-60-static.se.customer.tele2.net [212.214.11.60]) by mail.messagingengine.com (Postfix) with ESMTPA id 240453280064; Thu, 29 Oct 2020 12:22:22 -0400 (EDT) Date: Thu, 29 Oct 2020 17:22:20 +0100 (CET) Message-Id: <20201029.172220.1401832604665061345.id@4668.se> To: kent+ietf@watsen.net Cc: netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <01000175751b1e3f-d4a84796-9f90-49eb-bbea-d3be5966f233-000000@email.amazonses.com> References: <20201029.085108.142889809049265936.id@4668.se> <01000175751b1e3f-d4a84796-9f90-49eb-bbea-d3be5966f233-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org 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: Thu, 29 Oct 2020 16:22:25 -0000 S2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0PiB3cm90ZToNCj4gSGkgTWFydGluLA0K PiANCj4gPiBUaGlzIGlzIG5vdCBhIGdvb2QgcHJvcG9zYWwsIHNpbmNlIHRoZSByZXN1bHQgaXMg bm90IGEgdmFsaWQgWE1MDQo+ID4gZG9jdW1lbnQuICANCj4gDQo+IEhvdyBpcyB0aGlzIGltcG9y dGFudD8NCg0KSSB3aWxsIGJlIGRpZmZpY3VsdCB0byBwYXJzZSwgc2luY2UgeW91IGNhbid0IGp1 c3QgcGFyc2UgaXQgd2l0aCBhDQpzdGFuZGFyZCBYTUwgcGFyc2VyLg0KDQoNCj4gSXTigJlzIG5v dCBhbiBIVFRQLWNvbnN0cmFpbnQsIHJpZ2h0Pw0KDQpOby4NCg0KPiBhbmQgSQ0KPiBkb27igJl0 IHRoaW5rIGl0IGlzIG5lZWRlZCBmb3IgbWVzc2FnZS1mcmFtaW5nIGVpdGhlci4NCj4gDQo+IEkg Z3Vlc3MsIGFzIHlvdSBtZW50aW9uIGJlbG93LCB0aGUgbWVkaWEtdHlwZSBpcyBpbmFwcHJvcHJp YXRlICh0aG91Z2gNCj4gMTEuMy4xIGlzbuKAmXQgYXMgY2xlYXIgYXMgb25lIG1pZ2h0IGhvcGUp LCBzbyBtYXliZSB0aGUgcmVzcG9uc2UgaXMNCj4gb2theSBpZiBvbmx5IGNoYW5naW5nIHRoZSBt ZWRpYSB0eXBlPw0KDQpTdXJlLCBmcm9tIGEgcHVyZSBtZWRpYSB0eXBlIHBvdzsgYnV0IEkgc3Rp bGwgdGhpbmsgaXQgd291bGQgYmUgYQ0KbWlzdGFrZSB0byBzZW5kIGEgY29uY2F0ZW5hdGlvbiBv ZiB2YWxpZCBYTUwgZG9jdW1lbnRzIHcvbyBhbnkNCnNlcGFyYXRvcnMgKGFuZCBhZGRpbmcgY3Vz dG9tIHNlcGFyYXRvcnMgbWF5IHdvcmssIGJ1dCBub3RlIGhvdyB0aGUNCm9yaWdpbmFsIE5FVENP TkYgWE1MIGVuY29kaW5nIHRyaWVkIHRvIGRvIHRoYXQsIGJ1dCBmYWlsZWQuLi4pLg0KDQo+ID4g QW4gWE1MIGRvY3VtZW50IGhhcyBleGFjdGx5IG9uZSByb290IGVsZW1lbnQuDQo+ID4gDQo+ID4g QWxzbywgdGhlIG1lZGlhIHR5cGVzIHVzZWQgaW4gdGhlIGV4YW1wbGVzIGFyZSBtaXNsZWFkaW5n LiAgVGhlDQo+ID4gZXhhbXBsZSByZXBseSBkb2Vzbid0IG1hdGNoIHRoZSBtZWRpYSB0eXBlDQo+ ID4gImFwcGxpY2F0aW9uL3lhbmctZGF0YStqc29uIiAoc2FtZSBmb3IgeG1sKS4NCj4gDQo+IEhv dyBpc27igJl0IHRoZSBtZWRpYS10eXBlIG9rYXkgZm9yIEpTT04sIGZvciB0aGUgcmVzcG9uc2Ug aW4gdGhlDQo+IHByZXZpb3VzIG1lc3NhZ2U/ICBJdCBzZWVtcyB2YWxpZCB0byBtZS4uLg0KDQpZ b3UncmUgcmlnaHQsIGl0IGlzIHZhbGlkLiAgTXkgYmFkLiAgSSBmb3Jnb3QgaG93IGNsZXZlciB0 aGUgSlNPTg0KZW5jb2Rpbmcgb2YgYSBzaW5nbGUgbGlzdCBlbnRyeSB3YXMgOy0pDQoNCj4gTm8g ZGlzcHV0ZSByZWdhcmRpbmcgdGhlIFhNTCBtZWRpYS10eXBlLiAgDQo+IA0KPiANCj4gPiBJIHN1 Z2dlc3QgeW91IGRlZmluZSBuZXcgbWVkaWEgdHlwZXMgYW5kIGEgImNvbGxlY3Rpb24iIHJvb3QN Cj4gPiBlbGVtZW50OyBvciBrZWVwIHRoZSBtZWRpYSB0eXBlcyBhbmQgZGVmaW5lICJjb2xsZWN0 aW9uIiBpbiBhIFlBTkcNCj4gPiBtb2R1bGUgYXM6DQo+ID4gDQo+ID4gIGFueWRhdGEgY29sbGVj dGlvbjsNCj4gDQo+IE5vdGVkLCBidXQgZmlyc3Qgd291bGQgbGlrZSB0byB1bmRlcnN0YW5kIHdo eSBzaW1wbHkgY2hhbmdpbmcgdGhlDQo+IG1lZGlhLXR5cGUgYWxvbmUgKHdoaWxlIGtlZXBpbmcg dGhlIHJlc3BvbnNlcyBpbiB0aGUgcHJldmlvdXMgbWVzc2FnZSkNCj4gaXNu4oCZdCBzdWZmaWNp ZW50LCBmb3IgYm90aCB4bWwgYW5kIGpzb24uDQo+IA0KPiBFYWNoIG1lZGlhLXR5cGUgY2FuIGRl ZmluZSBpdHMgb3duIGZvcm1hdCBzbywgZS5nLiwNCj4g4oCcYXBwbGljYXRpb24veWFuZy1kYXRh K3htbC1saXN0IiBjb3VsZCBiZSB1c2VkIHRvIGRlZmluZSBhIGxpc3Qgb2YgWE1MDQo+IGRvY3Vt ZW50cywgcmlnaHQ/DQo+IA0KPiBUaGF0IHNhaWQsIEkgYWNrbm93bGVkZ2UgdGhhdCBoYXZpbmcg YSByb290LWVsZW1lbnQgbWF5IGFpZA0KPiB4bWwtcGFyc2VycywgYW5kIHRodXMgcGVyaGFwcyB3 b3J0aHdoaWxlIGZvciB0aGF0IHJlYXNvbi4uLmp1c3Qgd2FudA0KPiB0byBlbnN1cmUgd2UgdW5k ZXJzdGFuZCB0aGUgbW90aXZhdGlvbnMgYWNjdXJhdGVseS4NCg0KWWVzIHRoaXMgaXMgbXkgY29u Y2Vybi4NCg0KDQovbWFydGluDQo= From nobody Thu Oct 29 12:00:22 2020 Return-Path: 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 30C173A0A60 for ; Thu, 29 Oct 2020 12:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 1hD_xvLursLS for ; Thu, 29 Oct 2020 12:00:14 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4902C3A0A82 for ; Thu, 29 Oct 2020 12:00:13 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id 141so4679692lfn.5 for ; Thu, 29 Oct 2020 12:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iRkKTS3Zh/XQJA3toybPnH0eq0Ifpc4c25hibhaCLpk=; b=UTNJB9HZX7UHDr0L8R/p+PnVyxKEkNDm7h5bB81PmqSTbri780aeKUN39cNyLzc66+ cMtgD3CAIk5Nw1PjXzA8vVmgW+vxDPvY92gOxvZlLOcGgRTGiEjtCZCNWBHoOqYuY4JH ApCyG5hBM9TqJrc1guSmqq6MHTTVvbIkmVwiu94U6fVEKwJQNgQZb98E3bsJhrqnpSUJ u35Rtl7WsAyrNLr8v9DTWUTSwDTO/qRutg01M5OzYSw8klBxsbHQwx6yjghQkrQMZcMU fiGIr1ZHIllQw3TADh50gyzrSLC5GZl15cWGEFRrWcUtAtQ+eWVO1B8RZWXAzQH2EROf 7BVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iRkKTS3Zh/XQJA3toybPnH0eq0Ifpc4c25hibhaCLpk=; b=KKlj2lby6BVuz8cC+M6MNUtdNo08v0NUJypcAEX2h/HQw2g9uzt2kNfWGNh59YZNdB j/TbHBEee+aPYWL7Ehh6lL5rk75o8mM4Laio0NyW+7vF492rqTpqUjBdukeJ5U/iX6n1 Rw5WrrIkWbpJuz+Jt8zQIysWd6MBy/i2M0cAKPddcLeLvnvmQOBv3M0LmJM5MvCnw0T5 oFgqEx3QbTVL9uGf9OhI/PzfIn2SpRMqDkrtch7NWN1Mr3JM9kpqeI/tV4aK+KWihbQf 9u/QXPV9bIc7AP/e7JqSHnotGqJfUSGR9K5tGAln9jgrJRtFzxIPtLzmCAm2FmrANp7Y QBbQ== X-Gm-Message-State: AOAM532xp1M7qBFPgDq3bnGKb9Sbf6t3y3QO+FJsmPAdzYKToj3DD326 0LNNLP2CtnB3tut/2fTrTRwCPKRhXAqpIM340vu3qw== X-Google-Smtp-Source: ABdhPJxn6bJqWLBaN6hvYfiYLb3Zg+lGh6wkTC7RthoSpNTtzmA3RrBH4eFm9OXzp3NnEumJ6TIlFkDnoEZX7R6RJ5c= X-Received: by 2002:ac2:5618:: with SMTP id v24mr2041653lfd.138.1603998011223; Thu, 29 Oct 2020 12:00:11 -0700 (PDT) MIME-Version: 1.0 References: <20201029.085108.142889809049265936.id@4668.se> <01000175751b1e3f-d4a84796-9f90-49eb-bbea-d3be5966f233-000000@email.amazonses.com> <20201029.172220.1401832604665061345.id@4668.se> In-Reply-To: <20201029.172220.1401832604665061345.id@4668.se> From: Andy Bierman Date: Thu, 29 Oct 2020 11:59:59 -0700 Message-ID: To: =?UTF-8?Q?Martin_Bj=C3=B6rklund?= Cc: Kent Watsen , Netconf Content-Type: multipart/alternative; boundary="000000000000ae096405b2d3e3cb" Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org 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: Thu, 29 Oct 2020 19:00:22 -0000 --000000000000ae096405b2d3e3cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 29, 2020 at 9:22 AM Martin Bj=C3=B6rklund wr= ote: > Kent Watsen wrote: > > Hi Martin, > > > > > This is not a good proposal, since the result is not a valid XML > > > document. > > > > How is this important? > > I will be difficult to parse, since you can't just parse it with a > standard XML parser. > > +1 It is perplexing why interoperability with standard XML tools would be forfeited just to save the encoding length of 1 container (about 30 bytes) Andy > > It=E2=80=99s not an HTTP-constraint, right? > > No. > > > and I > > don=E2=80=99t think it is needed for message-framing either. > > > > I guess, as you mention below, the media-type is inappropriate (though > > 11.3.1 isn=E2=80=99t as clear as one might hope), so maybe the response= is > > okay if only changing the media type? > > Sure, from a pure media type pow; but I still think it would be a > mistake to send a concatenation of valid XML documents w/o any > separators (and adding custom separators may work, but note how the > original NETCONF XML encoding tried to do that, but failed...). > > > > An XML document has exactly one root element. > > > > > > Also, the media types used in the examples are misleading. The > > > example reply doesn't match the media type > > > "application/yang-data+json" (same for xml). > > > > How isn=E2=80=99t the media-type okay for JSON, for the response in the > > previous message? It seems valid to me... > > You're right, it is valid. My bad. I forgot how clever the JSON > encoding of a single list entry was ;-) > > > No dispute regarding the XML media-type. > > > > > > > I suggest you define new media types and a "collection" root > > > element; or keep the media types and define "collection" in a YANG > > > module as: > > > > > > anydata collection; > > > > Noted, but first would like to understand why simply changing the > > media-type alone (while keeping the responses in the previous message) > > isn=E2=80=99t sufficient, for both xml and json. > > > > Each media-type can define its own format so, e.g., > > =E2=80=9Capplication/yang-data+xml-list" could be used to define a list= of XML > > documents, right? > > > > That said, I acknowledge that having a root-element may aid > > xml-parsers, and thus perhaps worthwhile for that reason...just want > > to ensure we understand the motivations accurately. > > Yes this is my concern. > > > /martin > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000ae096405b2d3e3cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Oct 29, 2020 at 9:22 AM Marti= n Bj=C3=B6rklund <mbj+ietf@4668.se= > wrote:
= Kent Watsen <kent+ietf@watsen.net> wrote:
> Hi Martin,
>
> > This is not a good proposal, since the result is not a valid XML<= br> > > document.=C2=A0
>
> How is this important?

I will be difficult to parse, since you can't just parse it with a
standard XML parser.


+1

It is perp= lexing why interoperability with standard XML tools would be forfeited
just to save the encoding length of 1 container=C2=A0 (about 30 bytes= )


Andy


> It=E2=80=99s not an HTTP-constraint, right?

No.

> and I
> don=E2=80=99t think it is needed for message-framing either.
>
> I guess, as you mention below, the media-type is inappropriate (though=
> 11.3.1 isn=E2=80=99t as clear as one might hope), so maybe the respons= e is
> okay if only changing the media type?

Sure, from a pure media type pow; but I still think it would be a
mistake to send a concatenation of valid XML documents w/o any
separators (and adding custom separators may work, but note how the
original NETCONF XML encoding tried to do that, but failed...).

> > An XML document has exactly one root element.
> >
> > Also, the media types used in the examples are misleading.=C2=A0 = The
> > example reply doesn't match the media type
> > "application/yang-data+json" (same for xml).
>
> How isn=E2=80=99t the media-type okay for JSON, for the response in th= e
> previous message?=C2=A0 It seems valid to me...

You're right, it is valid.=C2=A0 My bad.=C2=A0 I forgot how clever the = JSON
encoding of a single list entry was ;-)

> No dispute regarding the XML media-type.=C2=A0
>
>
> > I suggest you define new media types and a "collection"= root
> > element; or keep the media types and define "collection"= ; in a YANG
> > module as:
> >
> >=C2=A0 anydata collection;
>
> Noted, but first would like to understand why simply changing the
> media-type alone (while keeping the responses in the previous message)=
> isn=E2=80=99t sufficient, for both xml and json.
>
> Each media-type can define its own format so, e.g.,
> =E2=80=9Capplication/yang-data+xml-list" could be used to define = a list of XML
> documents, right?
>
> That said, I acknowledge that having a root-element may aid
> xml-parsers, and thus perhaps worthwhile for that reason...just want > to ensure we understand the motivations accurately.

Yes this is my concern.


/martin
_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000ae096405b2d3e3cb--