From nobody Fri Mar 1 08:59:18 2019 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 9C22B130E69; Fri, 1 Mar 2019 08:59:16 -0800 (PST) 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: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155145955659.6242.267097065161200775@ietfa.amsl.com> Date: Fri, 01 Mar 2019 08:59:16 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-notification-capabilities-01.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, 01 Mar 2019 16:59:17 -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 : YangPush Notification Capabilities Authors : Balazs Lengyel Alexander Clemm Filename : draft-ietf-netconf-notification-capabilities-01.txt Pages : 11 Date : 2019-03-01 Abstract: This document proposes a YANG module that allows a YANG server to specify server capabilities related to "Subscription to YANG Datastores" (YangPush). It proposes to use YANG Instance Data to document this information already in implementation time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-01 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-capabilities-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-notification-capabilities-01 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 Mar 1 13:10:23 2019 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 CEFBF130ED6; Fri, 1 Mar 2019 13:09:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ibagdona@gmail.com, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155147459583.6101.7765846533417207991.idtracker@ietfa.amsl.com> Date: Fri, 01 Mar 2019 13:09:55 -0800 Archived-At: Subject: [netconf] netconf - Requested session has been scheduled for IETF 104 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, 01 Mar 2019 21:09:56 -0000 Dear Mahesh Jethanandani, 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) Monday, 25 March 2019, Morning Session I 0900-1100 Room Name: Grand Ballroom size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/104/sessions/netconf.ics Request Information: --------------------------------------------------------- Working Group Name: Network Configuration Area Name: Operations and Management Area Session Requester: Mahesh Jethanandani Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: netmod Second Priority: opsarea opsawg tsvwg babel rtgwg bfd Third Priority: sacm saag People who must be present: Mahesh Jethanandani Kent Watsen Ignas Bagdonas Resources Requested: Special Requests: MUST schedule for Monday or Tuesday. --------------------------------------------------------- From nobody Sat Mar 2 05:57:14 2019 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 D3121129441 for ; Sat, 2 Mar 2019 05:57:12 -0800 (PST) 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, 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 maksd9JcUyi9 for ; Sat, 2 Mar 2019 05:57:10 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8C7128CF3 for ; Sat, 2 Mar 2019 05:57:10 -0800 (PST) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id C39941AE0493; Sat, 2 Mar 2019 14:57:07 +0100 (CET) Date: Sat, 02 Mar 2019 14:57:07 +0100 (CET) Message-Id: <20190302.145707.1083539826475521165.mbj@tail-f.com> To: kent@watsen.net Cc: nite@hq.sk, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <01000169371e0725-87668eaf-d19c-4fb0-9e60-f5c3c209776e-000000@email.amazonses.com> References: <01000169371e0725-87668eaf-d19c-4fb0-9e60-f5c3c209776e-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] RFC6241/RFC7952 model-level interop? 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: Sat, 02 Mar 2019 13:57:13 -0000 Kent Watsen wrote: > Hi Robert, > > There is currently no plan to do this, nor is there an rfc6241bis in sight, > though one may be prompted by the YANG-next discussion happening > in NETMOD. > > Options (open to comments): > > a) file an Errata An RFC errata is not appropriate for enhancing an existing module with new definitions. > b) file a feature request (start a NETCONF-next issue tracker?) It is probably a good idea to have such a tracker. > c) submit an I-D that *updates* just this aspect of RFC 6241 > d) submit an I-D for rfc6241bis (we're probably not ready for this yet) > e) any other choices? /martin > > Kent > > > > On Feb 28, 2019, at 11:04 AM, Robert Varga wrote: > > > > Hello, > > > > as an implementer of both RFC6241 and RFC7952, I would find it very > > useful if there were an ietf-netconf.yang which includes the annotation > > definition of edit-config's operation attribute (Section 7.2). > > > > Are there any plans for RFC6241bis or similar, bringing only an update > > to ietf-netconf.yang? > > > > Thanks, > > Robert > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Sat Mar 2 14:13:01 2019 Return-Path: <0100016940779c37-14c8936f-ddf9-4ddd-a3d4-d3eb2a233fd6-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 7C605130DFA for ; Sat, 2 Mar 2019 14:12:59 -0800 (PST) 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_DNSWL_NONE=-0.0001, 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 MkDvZjGGwbbL for ; Sat, 2 Mar 2019 14:12:57 -0800 (PST) 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 A5B66128B33 for ; Sat, 2 Mar 2019 14:12:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1551564774; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=azwoBcSl6YhWnDMagdfTEypYeqCjlnZhuuxFjlZLmkQ=; b=YWB5/WyqrRqoWrG1Z3yzNGVcxtcdaE6m70jGUnSl4e8l5EOZyn0r8Ul28QpdUTxH 6eKppDUrT3m7040RQhpNYChiI9Xa2FfIeyKB2qwnZcXBHS75TKPbY+MTww2QxWYJTX2 Ylw3nGxukYuLRWhLi6CaTSXqYB1RQdmRJbWZfBmM= From: Kent Watsen Message-ID: <0100016940779c37-14c8936f-ddf9-4ddd-a3d4-d3eb2a233fd6-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2B5DBF91-E37E-43AE-981A-0667CA70E3D7" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Sat, 2 Mar 2019 22:12:54 +0000 In-Reply-To: <20190302.145707.1083539826475521165.mbj@tail-f.com> Cc: netconf@ietf.org To: Robert Varga References: <01000169371e0725-87668eaf-d19c-4fb0-9e60-f5c3c209776e-000000@email.amazonses.com> <20190302.145707.1083539826475521165.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.02-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] RFC6241/RFC7952 model-level interop? 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: Sat, 02 Mar 2019 22:12:59 -0000 --Apple-Mail=_2B5DBF91-E37E-43AE-981A-0667CA70E3D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All. I've created trackers for NETCONF-next and RESTCONF-next here: - https://github.com/netconf-wg/netconf-next - https://github.com/netconf-wg/restconf-next Robert, please add your request to the netconf-next issue tracker. Thanks, Kent > On Mar 2, 2019, at 8:57 AM, Martin Bjorklund wrote: >=20 > Kent Watsen > wrote: >> Hi Robert, >>=20 >> There is currently no plan to do this, nor is there an rfc6241bis in = sight, >> though one may be prompted by the YANG-next discussion happening >> in NETMOD. >>=20 >> Options (open to comments): >>=20 >> a) file an Errata >=20 > An RFC errata is not appropriate for enhancing an existing module with > new definitions. >=20 >> b) file a feature request (start a NETCONF-next issue tracker?)=20 >=20 > It is probably a good idea to have such a tracker. >=20 >> c) submit an I-D that *updates* just this aspect of RFC 6241 >> d) submit an I-D for rfc6241bis (we're probably not ready for this = yet) >> e) any other choices? >=20 >=20 > /martin >=20 >=20 >>=20 >> Kent >>=20 >>=20 >>> On Feb 28, 2019, at 11:04 AM, Robert Varga wrote: >>>=20 >>> Hello, >>>=20 >>> as an implementer of both RFC6241 and RFC7952, I would find it very >>> useful if there were an ietf-netconf.yang which includes the = annotation >>> definition of edit-config's operation attribute (Section 7.2). >>>=20 >>> Are there any plans for RFC6241bis or similar, bringing only an = update >>> to ietf-netconf.yang? >>>=20 >>> Thanks, >>> Robert >>>=20 >>> _______________________________________________ >>> netconf mailing list >>> netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>=20 >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >>=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = --Apple-Mail=_2B5DBF91-E37E-43AE-981A-0667CA70E3D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
All.

I've created trackers for NETCONF-next and RESTCONF-next = here:

  - = https://github.com/netconf-wg/netconf-next
  - = https://github.com/netconf-wg/restconf-next


Robert, please add your request to the = netconf-next issue tracker.

Thanks,
Kent



On Mar 2, 2019, at 8:57 AM, = Martin Bjorklund <mbj@tail-f.com> wrote:

Kent Watsen <kent@watsen.net> wrote:
Hi = Robert,

There is currently no plan to do = this, nor is there an rfc6241bis in sight,
though one may = be prompted by the YANG-next discussion happening
in = NETMOD.

Options (open to comments):

a) file an Errata
An RFC errata is not appropriate = for enhancing an existing module with
new definitions.

b) file a feature request (start a = NETCONF-next issue tracker?) 

It is probably a good idea to have such a tracker.

c) = submit an I-D that *updates* just this aspect of RFC 6241
d)= submit an I-D for rfc6241bis  (we're probably not ready for this = yet)
e) any other choices?


/martin



Kent


On Feb 28, 2019, at 11:04 AM, Robert Varga = <nite@hq.sk> = wrote:

Hello,

as= an implementer of both RFC6241 and RFC7952, I would find it very
useful if there were an ietf-netconf.yang which includes the = annotation
definition of edit-config's operation attribute = (Section 7.2).

Are there any plans for = RFC6241bis or similar, bringing only an update
to = ietf-netconf.yang?

Thanks,
Robert

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

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

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

= --Apple-Mail=_2B5DBF91-E37E-43AE-981A-0667CA70E3D7-- From nobody Tue Mar 5 05:32:24 2019 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 D08991310F6; Tue, 5 Mar 2019 05:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz 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 XJZixwGYn1WY; Tue, 5 Mar 2019 05:32:10 -0800 (PST) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [78.128.211.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B34741310A6; Tue, 5 Mar 2019 05:32:10 -0800 (PST) Received: by kalendar.cesnet.cz (Postfix, from userid 999) id 0E007604E8; Tue, 5 Mar 2019 14:32:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1551792728; bh=e7gs2I/DQgLKLc46kGprNn2cLM6h/a7fuoXzg8//C+g=; h=From:Date:Cc:To:Subject; b=ojM3A3RuxmDKnruXhKjH31uRsHSOJi5kJ/cMpWwz5AvngVW2dayFHYWPo1LEaFUkv B18RHFD112GPgsooGgwui2yTE0DnhY9UETKw8jBXZIif8l5neeLKccU55cJhoqEJZw toJ/Io80vHNsC8CpwVY/Dr9LBjIJj3SQRXbq94KI= Content-Type: text/plain; charset="utf-8" From: =?utf-8?q?Michal_Va=C5=A1ko?= X-Forward: 2001:67c:1220:80c:b5:55d3:81d5:8636 Date: Tue, 05 Mar 2019 14:32:08 +0100 Cc: "netconf" To: "netmod" MIME-Version: 1.0 Message-ID: <4a3-5c7e7a80-3-125b9e20@241827065> User-Agent: SOGoMail 2.3.23 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [netconf] netconf-config-change and NMDA 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, 05 Mar 2019 13:32:14 -0000 Hi, I have encountered a problem while validating ietf-netconf-notification= s netconf-config-change notification while following NMDA. The RFC [1] = says that the "target" instance-identifier in this notification should = be validated against operational datastore. In my use-case there was a = running datastore modification and the "target" was not found in the op= erational datastore so the notification failed to be validated. I still= believe the notification should be valid and this seems to be the resu= lt of a flaw in the specification somewhere. Thanks for any input. Regards, Michal [1] https://tools.ietf.org/html/rfc8342#section-6.1 From nobody Tue Mar 5 05:54:56 2019 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 1134D1312C0; Tue, 5 Mar 2019 05:54:46 -0800 (PST) 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, 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 ZqL_oPD9gcQ5; Tue, 5 Mar 2019 05:54:43 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1E89A131291; Tue, 5 Mar 2019 05:54:43 -0800 (PST) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 208111AE0386; Tue, 5 Mar 2019 14:54:41 +0100 (CET) Date: Tue, 05 Mar 2019 14:54:41 +0100 (CET) Message-Id: <20190305.145441.1898245510911942384.mbj@tail-f.com> To: mvasko@cesnet.cz Cc: netmod@ietf.org, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <4a3-5c7e7a80-3-125b9e20@241827065> References: <4a3-5c7e7a80-3-125b9e20@241827065> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] netconf-config-change and NMDA 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, 05 Mar 2019 13:54:48 -0000 Hi, Michal Va=A8ko wrote: > Hi, > I have encountered a problem while validating > ietf-netconf-notifications netconf-config-change notification while > following NMDA. The RFC [1] says that the "target" instance-identifie= r > in this notification should be validated against operational > datastore. In my use-case there was a running datastore modification > and the "target" was not found in the operational datastore so the > notification failed to be validated. I still believe the notification= > should be valid and this seems to be the result of a flaw in the > specification somewhere. Thanks for any input. I think that the problem existed even before NMDA. The netconf-config-change says that the target refers to a node in the affected datastore, and if the affected datastore was startup the instance-identifier wouldn't validate with the given XPath context. Also, even in the case that the datastore was 'running', if the operation was 'delete', the target node could presumably point to the deleted node, which wouldn't validate. Not sure what the right fix is; maybe we shouldn't use an instance-identifier at all in this notification? Or maybe it is ok since the description clearly says that the target refers to a node in the affected datastore. [OTOH, in general it is very hard to tell if validation against the operational state works or not, since it requires a stable snapshot of the operational state.] /martin > = > Regards, > Michal > = > [1] https://tools.ietf.org/html/rfc8342#section-6.1 > = > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > = From nobody Wed Mar 6 19:58:29 2019 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 8F67B12F295; Wed, 6 Mar 2019 19:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 d2tSst7N46oQ; Wed, 6 Mar 2019 19:58:25 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C6F9128CF2; Wed, 6 Mar 2019 19:58:25 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0D8DBB824DA; Wed, 6 Mar 2019 19:58:25 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, netconf@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190307035825.0D8DBB824DA@rfc-editor.org> Date: Wed, 6 Mar 2019 19:58:25 -0800 (PST) Archived-At: Subject: [netconf] =?utf-8?q?RFC_8525_on_YANG_Library?= 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, 07 Mar 2019 03:58:27 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8525 Title: YANG Library Author: A. Bierman, M. Bjorklund, J. Schoenwaelder, K. Watsen, R. Wilton Status: Standards Track Stream: IETF Date: March 2019 Mailbox: andy@yumaworks.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, kent+ietf@watsen.net, rwilton@cisco.com Pages: 32 Characters: 57003 Obsoletes: RFC 7895 I-D Tag: draft-ietf-netconf-rfc7895bis-07.txt URL: https://www.rfc-editor.org/info/rfc8525 DOI: 10.17487/RFC8525 This document describes a YANG library that provides information about the YANG modules, datastores, and datastore schemas used by a network management server. Simple caching mechanisms are provided to allow clients to minimize retrieval of this information. This version of the YANG library supports the Network Management Datastore Architecture (NMDA) by listing all datastores supported by a network management server and the schema that is used by each of these datastores. This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Mar 6 19:58:49 2019 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 42B7D13139E; Wed, 6 Mar 2019 19:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 VVFL1zSHcKZr; Wed, 6 Mar 2019 19:58:42 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62D9313138C; Wed, 6 Mar 2019 19:58:39 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id F07CAB824E7; Wed, 6 Mar 2019 19:58:38 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, netconf@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190307035838.F07CAB824E7@rfc-editor.org> Date: Wed, 6 Mar 2019 19:58:38 -0800 (PST) Archived-At: Subject: [netconf] =?utf-8?q?RFC_8526_on_NETCONF_Extensions_to_Support_th?= =?utf-8?q?e_Network_Management_Datastore_Architecture?= 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, 07 Mar 2019 03:58:48 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8526 Title: NETCONF Extensions to Support the Network Management Datastore Architecture Author: M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton Status: Standards Track Stream: IETF Date: March 2019 Mailbox: mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, phil@juniper.net, kent+ietf@watsen.net, rwilton@cisco.com Pages: 23 Characters: 42453 Updates: RFC 6241, RFC 7950 I-D Tag: draft-ietf-netconf-nmda-netconf-08.txt URL: https://www.rfc-editor.org/info/rfc8526 DOI: 10.17487/RFC8526 This document extends the NETCONF protocol defined in RFC 6241 in order to support the Network Management Datastore Architecture defined in RFC 8342. This document updates both RFC 6241 and RFC 7950. The update to RFC 6241 adds new operations and , and augments existing operations , , and . The update to RFC 7950 requires the usage of I-D.ietf-netconf-rfc7895bis by NETCONF servers implementing the Network Management Datastore Architecture. RFC Ed.: Please replace "I-D.ietf-netconf-rfc7895bis" above with its final RFC assignment and remove this note. This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Mar 6 19:59:14 2019 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 4A3BD1313A9; Wed, 6 Mar 2019 19:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 mIlh1PFO0u5x; Wed, 6 Mar 2019 19:58:57 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D08E1313BB; Wed, 6 Mar 2019 19:58:55 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 475D9B824F3; Wed, 6 Mar 2019 19:58:55 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, netconf@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190307035855.475D9B824F3@rfc-editor.org> Date: Wed, 6 Mar 2019 19:58:55 -0800 (PST) Archived-At: Subject: [netconf] =?utf-8?q?RFC_8527_on_RESTCONF_Extensions_to_Support_t?= =?utf-8?q?he_Network_Management_Datastore_Architecture?= 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, 07 Mar 2019 03:59:05 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8527 Title: RESTCONF Extensions to Support the Network Management Datastore Architecture Author: M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton Status: Standards Track Stream: IETF Date: March 2019 Mailbox: mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, phil@juniper.net, kent+ietf@watsen.net, rwilton@cisco.com Pages: 9 Characters: 15757 Updates: RFC 8040 I-D Tag: draft-ietf-netconf-nmda-restconf-05.txt URL: https://www.rfc-editor.org/info/rfc8527 DOI: 10.17487/RFC8527 This document extends the RESTCONF protocol defined in RFC 8040 in order to support the Network Management Datastore Architecture (NMDA) defined in RFC 8342. This document updates RFC 8040 by introducing new datastore resources, adding a new query parameter, and requiring the usage of the YANG library (described in RFC 8525) by RESTCONF servers implementing the NMDA. This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sat Mar 9 10:21:28 2019 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 95E0D130EB9; Sat, 9 Mar 2019 10:21:10 -0800 (PST) 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: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155215567056.28810.15925255497294072529@ietfa.amsl.com> Date: Sat, 09 Mar 2019 10:21:10 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-crypto-types-03.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, 09 Mar 2019 18:21:21 -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 : Common YANG Data Types for Cryptography Authors : Kent Watsen Wang Haiguang Filename : draft-ietf-netconf-crypto-types-03.txt Pages : 51 Date : 2019-03-09 Abstract: This document defines YANG identities, typedefs, the groupings useful for cryptographic applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-03 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-03 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 Sat Mar 9 10:39:24 2019 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 E43D612008F; Sat, 9 Mar 2019 10:39:14 -0800 (PST) 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: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155215675489.28743.2869712398011378773@ietfa.amsl.com> Date: Sat, 09 Mar 2019 10:39:14 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-crypto-types-04.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, 09 Mar 2019 18:39:15 -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 : Common YANG Data Types for Cryptography Authors : Kent Watsen Wang Haiguang Filename : draft-ietf-netconf-crypto-types-04.txt Pages : 51 Date : 2019-03-09 Abstract: This document defines YANG identities, typedefs, the groupings useful for cryptographic applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-04 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-04 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 Sat Mar 9 10:51:42 2019 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 E18A112426E; Sat, 9 Mar 2019 10:51:33 -0800 (PST) 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: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155215749389.28806.7857052692503359344@ietfa.amsl.com> Date: Sat, 09 Mar 2019 10:51:33 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-crypto-types-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: Sat, 09 Mar 2019 18:51:34 -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 : Common YANG Data Types for Cryptography Authors : Kent Watsen Wang Haiguang Filename : draft-ietf-netconf-crypto-types-05.txt Pages : 51 Date : 2019-03-09 Abstract: This document defines YANG identities, typedefs, the groupings useful for cryptographic applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-05 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-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 Sat Mar 9 11:22:31 2019 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 A696A12426E; Sat, 9 Mar 2019 11:22:22 -0800 (PST) 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: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155215934264.28587.8508197533523677567@ietfa.amsl.com> Date: Sat, 09 Mar 2019 11:22:22 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-trust-anchors-03.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, 09 Mar 2019 19:22:23 -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 : YANG Data Model for Global Trust Anchors Author : Kent Watsen Filename : draft-ietf-netconf-trust-anchors-03.txt Pages : 15 Date : 2019-03-09 Abstract: This document defines a YANG 1.1 data model for configuring global sets of X.509 certificates and SSH host-keys that can be referenced by other data models for trust. While the SSH host-keys are uniquely for the SSH protocol, the X.509 certificates may have multiple uses, including authenticating protocol peers and verifying signatures. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "XXXX" --> the assigned RFC value for this draft o "YYYY" --> the assigned RFC value for draft-ietf-netconf-crypto- types Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2019-03-09" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-trust-anchors/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-03 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trust-anchors-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-trust-anchors-03 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 Sat Mar 9 11:37:51 2019 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 D8F22127983; Sat, 9 Mar 2019 11:37:49 -0800 (PST) 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: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155216026986.28678.2589128115762808684@ietfa.amsl.com> Date: Sat, 09 Mar 2019 11:37:49 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-keystore-08.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, 09 Mar 2019 19:37:50 -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 : YANG Data Model for a Centralized Keystore Mechanism Author : Kent Watsen Filename : draft-ietf-netconf-keystore-08.txt Pages : 22 Date : 2019-03-09 Abstract: This document defines a YANG 1.1 module called "ietf-keystore" that enables centralized configuration of asymmetric keys and their associated certificates, and notification for when configured certificates are about to expire. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-keystore/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-keystore-08 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-keystore-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-keystore-08 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 Sat Mar 9 18:30:11 2019 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 759721275E9; Sat, 9 Mar 2019 18:30:03 -0800 (PST) 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: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155218500344.28810.17742993339369130929@ietfa.amsl.com> Date: Sat, 09 Mar 2019 18:30:03 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-ssh-client-server-09.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: Sun, 10 Mar 2019 02:30: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 : YANG Groupings for SSH Clients and SSH Servers Authors : Kent Watsen Gary Wu Liang Xia Filename : draft-ietf-netconf-ssh-client-server-09.txt Pages : 42 Date : 2019-03-09 Abstract: This document defines three YANG modules: the first defines groupings for a generic SSH client, the second defines groupings for a generic SSH server, and the third defines common identities and groupings used by both the client and the server. It is intended that these groupings will be used by applications using the SSH protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-ssh-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-09 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-ssh-client-server-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-ssh-client-server-09 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 Sat Mar 9 18:49:03 2019 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 76706127962; Sat, 9 Mar 2019 18:48:56 -0800 (PST) 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: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155218613645.28635.16975784356777540189@ietfa.amsl.com> Date: Sat, 09 Mar 2019 18:48:56 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-ssh-client-server-10.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: Sun, 10 Mar 2019 02:48: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 : YANG Groupings for SSH Clients and SSH Servers Authors : Kent Watsen Gary Wu Liang Xia Filename : draft-ietf-netconf-ssh-client-server-10.txt Pages : 42 Date : 2019-03-09 Abstract: This document defines three YANG modules: the first defines groupings for a generic SSH client, the second defines groupings for a generic SSH server, and the third defines common identities and groupings used by both the client and the server. It is intended that these groupings will be used by applications using the SSH protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-ssh-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-10 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-ssh-client-server-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-ssh-client-server-10 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 Sat Mar 9 19:20:13 2019 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 5957A1274D0; Sat, 9 Mar 2019 19:20:05 -0800 (PST) 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: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155218800534.28794.13712275769731896029@ietfa.amsl.com> Date: Sat, 09 Mar 2019 19:20:05 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-tls-client-server-09.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: Sun, 10 Mar 2019 03:20:05 -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 : YANG Groupings for TLS Clients and TLS Servers Authors : Kent Watsen Gary Wu Liang Xia Filename : draft-ietf-netconf-tls-client-server-09.txt Pages : 41 Date : 2019-03-09 Abstract: This document defines three YANG modules: the first defines groupings for a generic TLS client, the second defines groupings for a generic TLS server, and the third defines common identities and groupings used by both the client and the server. It is intended that these groupings will be used by applications using the TLS protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-tls-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-09 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tls-client-server-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-tls-client-server-09 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 Sat Mar 9 19:29:24 2019 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 E7AD01274D0; Sat, 9 Mar 2019 19:29:15 -0800 (PST) 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: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155218855592.28562.9525728269612745215@ietfa.amsl.com> Date: Sat, 09 Mar 2019 19:29:15 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-tls-client-server-10.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: Sun, 10 Mar 2019 03:29:16 -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 : YANG Groupings for TLS Clients and TLS Servers Authors : Kent Watsen Gary Wu Liang Xia Filename : draft-ietf-netconf-tls-client-server-10.txt Pages : 41 Date : 2019-03-09 Abstract: This document defines three YANG modules: the first defines groupings for a generic TLS client, the second defines groupings for a generic TLS server, and the third defines common identities and groupings used by both the client and the server. It is intended that these groupings will be used by applications using the TLS protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-tls-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-10 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tls-client-server-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-tls-client-server-10 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 Sat Mar 9 19:58:08 2019 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 36D2B1274D0; Sat, 9 Mar 2019 19:57:58 -0800 (PST) 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: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155219027817.28664.8150153797718565032@ietfa.amsl.com> Date: Sat, 09 Mar 2019 19:57:58 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-ssh-client-server-11.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: Sun, 10 Mar 2019 03:57:58 -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 : YANG Groupings for SSH Clients and SSH Servers Authors : Kent Watsen Gary Wu Liang Xia Filename : draft-ietf-netconf-ssh-client-server-11.txt Pages : 43 Date : 2019-03-09 Abstract: This document defines three YANG modules: the first defines groupings for a generic SSH client, the second defines groupings for a generic SSH server, and the third defines common identities and groupings used by both the client and the server. It is intended that these groupings will be used by applications using the SSH protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-ssh-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-11 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-ssh-client-server-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-ssh-client-server-11 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 Sat Mar 9 20:01:01 2019 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 03A251274D0; Sat, 9 Mar 2019 20:01:00 -0800 (PST) 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: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155219045999.28702.17063995571681512610@ietfa.amsl.com> Date: Sat, 09 Mar 2019 20:01:00 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-netconf-client-server-09.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: Sun, 10 Mar 2019 04:01:00 -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 : NETCONF Client and Server Models Author : Kent Watsen Filename : draft-ietf-netconf-netconf-client-server-09.txt Pages : 59 Date : 2019-03-09 Abstract: This document defines two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server. Both modules support both the SSH and TLS transport protocols, and support both standard NETCONF and NETCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. This document contains references to other drafts in progress, both in the Normative References section, as well as in body text throughout. Please update the following references to reflect their final RFC assignments: o I-D.ietf-netconf-keystore o I-D.ietf-netconf-ssh-client-server o I-D.ietf-netconf-tls-client-server Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "XXXX" --> the assigned RFC value for this draft o "YYYY" --> the assigned RFC value for I-D.ietf-netconf-ssh-client- server o "ZZZZ" --> the assigned RFC value for I-D.ietf-netconf-tls-client- server o "AAAA" --> the assigned RFC value for I-D.ietf-netconf-tcp-client- server Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2019-03-09" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-09 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-client-server-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-netconf-client-server-09 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 Sat Mar 9 20:29:54 2019 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 BEBA51277D7; Sat, 9 Mar 2019 20:29:45 -0800 (PST) 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: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155219218575.28714.16409746718962520582@ietfa.amsl.com> Date: Sat, 09 Mar 2019 20:29:45 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-netconf-client-server-10.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: Sun, 10 Mar 2019 04:29:46 -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 : NETCONF Client and Server Models Author : Kent Watsen Filename : draft-ietf-netconf-netconf-client-server-10.txt Pages : 58 Date : 2019-03-09 Abstract: This document defines two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server. Both modules support both the SSH and TLS transport protocols, and support both standard NETCONF and NETCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. This document contains references to other drafts in progress, both in the Normative References section, as well as in body text throughout. Please update the following references to reflect their final RFC assignments: o I-D.ietf-netconf-keystore o I-D.ietf-netconf-ssh-client-server o I-D.ietf-netconf-tls-client-server Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "XXXX" --> the assigned RFC value for this draft o "YYYY" --> the assigned RFC value for I-D.ietf-netconf-ssh-client- server o "ZZZZ" --> the assigned RFC value for I-D.ietf-netconf-tls-client- server o "AAAA" --> the assigned RFC value for I-D.ietf-netconf-tcp-client- server Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2019-03-09" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-10 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-client-server-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-netconf-client-server-10 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 Sat Mar 9 21:02:14 2019 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 F21B31279A2; Sat, 9 Mar 2019 21:02:04 -0800 (PST) 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: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155219412496.28710.3885938617774935157@ietfa.amsl.com> Date: Sat, 09 Mar 2019 21:02:04 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-restconf-client-server-09.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: Sun, 10 Mar 2019 05:02:05 -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 : RESTCONF Client and Server Models Author : Kent Watsen Filename : draft-ietf-netconf-restconf-client-server-09.txt Pages : 43 Date : 2019-03-09 Abstract: This document defines two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. Both modules support the TLS transport protocol with both standard RESTCONF and RESTCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. This document contains references to other drafts in progress, both in the Normative References section, as well as in body text throughout. Please update the following references to reflect their final RFC assignments: o I-D.ietf-netconf-keystore o I-D.ietf-netconf-tls-client-server Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "XXXX" --> the assigned RFC value for this draft o "AAAA" --> the assigned RFC value for I-D.ietf-netconf-tcp-client- server o "CCCC" --> the assigned RFC value for I-D.ietf-netconf-tls-client- server o "BBBB" --> the assigned RFC value for I-D.ietf-netconf-http- client-server Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2019-03-09" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-09 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-client-server-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-client-server-09 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 Sat Mar 9 21:03:43 2019 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 228F5130F2A; Sat, 9 Mar 2019 21:03:25 -0800 (PST) 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: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155219420510.28794.11449109431469162095@ietfa.amsl.com> Date: Sat, 09 Mar 2019 21:03:25 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-restconf-client-server-10.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: Sun, 10 Mar 2019 05:03:35 -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 : RESTCONF Client and Server Models Author : Kent Watsen Filename : draft-ietf-netconf-restconf-client-server-10.txt Pages : 43 Date : 2019-03-09 Abstract: This document defines two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. Both modules support the TLS transport protocol with both standard RESTCONF and RESTCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. This document contains references to other drafts in progress, both in the Normative References section, as well as in body text throughout. Please update the following references to reflect their final RFC assignments: o I-D.ietf-netconf-keystore o I-D.ietf-netconf-tcp-client-server o I-D.ietf-netconf-tls-client-server o I-D.ietf-netconf-http-client-server Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "XXXX" --> the assigned RFC value for this draft o "AAAA" --> the assigned RFC value for I-D.ietf-netconf-tcp-client- server o "CCCC" --> the assigned RFC value for I-D.ietf-netconf-tls-client- server o "BBBB" --> the assigned RFC value for I-D.ietf-netconf-http- client-server Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2019-03-09" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-10 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-client-server-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-client-server-10 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 Sun Mar 10 11:35:01 2019 Return-Path: <0100016968e2ed4e-56a5fabf-f4ee-402a-a52d-a52d65eddba0-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 5E71D127887 for ; Sun, 10 Mar 2019 11:35:00 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 dKY0_aZWjotg for ; Sun, 10 Mar 2019 11:34:58 -0700 (PDT) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED1401200ED for ; Sun, 10 Mar 2019 11:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1552242896; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=4fi67zxZ5d3vtJjwbh1uyUIfYVVwVAMx5v5qpF1L1cQ=; b=QN/0Za7/dtjaw/m2GRFqSmeTYav1a2h+j+VDNWMr3v2wXm1RZnotOvaJcZP2/rBS ouou20bHpNzBayeRYU30C1NVLOZrDo/j26O3dV9kdfjEaKUzdrfscP7srCHI3U9mx+3 N/UfioycdD9jE3p9rQfVKxnO7AKK/QTQZY+cFrTY= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_BBF20955-1BA1-4265-936F-0C19167112F6" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-ID: <0100016968e2ed4e-56a5fabf-f4ee-402a-a52d-a52d65eddba0-000000@email.amazonses.com> Date: Sun, 10 Mar 2019 18:34:56 +0000 To: netconf@ietf.org X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.10-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] update to all the client/server drafts 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: Sun, 10 Mar 2019 18:35:00 -0000 --Apple-Mail=_BBF20955-1BA1-4265-936F-0C19167112F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear WG, You undoubtedly noticed the flurry of draft-submissions yesterday. Here is a brief synopsis of the what changed: 1) identities in the crypto-types draft were moved around 2) added new drafts tcp-client-server and http-client-server 3) added per protocol-layer keepalive configuration 4) reformatted all YANG modules using `pyang -f yang --keep-comments` Heads up: I published separate drafts for #4, thus doubling the total number = of publications. I did this so that folks could see the diffs to the = YANG modules without all the reformatting clutter, but you have to look = at=20 the diff of the version *before* the most recent version to see it. Here are the two new drafts: = https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00 = = https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-00 = Kent // as a contributor= --Apple-Mail=_BBF20955-1BA1-4265-936F-0C19167112F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Dear WG,

You undoubtedly noticed = the flurry of draft-submissions yesterday.
Here is = a brief synopsis of the what changed:

1) identities in the crypto-types draft = were moved around
2) added new drafts = tcp-client-server and http-client-server
3) added = per protocol-layer keepalive  configuration
4) = reformatted all YANG modules using `pyang -f yang = --keep-comments`

Heads up:

    I published separate drafts for #4, thus = doubling the total number of
    = publications.  I did this so that folks could see the diffs to the = YANG
    modules without all the = reformatting clutter, but you have to look at 
    the diff of the version *before* the most = recent version to see it.

Here are the two new drafts:

    https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-se= rver-00
    https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-s= erver-00

Kent   // as a = contributor
= --Apple-Mail=_BBF20955-1BA1-4265-936F-0C19167112F6-- From nobody Sun Mar 10 15:49:01 2019 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 ED1F11274A1 for ; Sun, 10 Mar 2019 15:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 dA9jcDbx9mYq for ; Sun, 10 Mar 2019 15:48:57 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 D7C69124408 for ; Sun, 10 Mar 2019 15:48:56 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id h6so2000194lfc.2 for ; Sun, 10 Mar 2019 15:48:56 -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; bh=+2hFtpVgNxGxFh7KdbqUNhwdxjbhrYis2vpq5dIL0OI=; b=GRK3ufbuH9imS229LwaQzoP6llRhxuxqaTLVUDzsfBYuEzqy1ivzDDk3Tu8OQ9QRye heV+K0f903COiel3qg/q6awJPnLWsVheXcmfMCZkxsT7x8Xw2YKKNgLmreTc6osttVWS lkVodsQbUDobd2ZuPAM/3kCxxR37qDpTiXRXq+c4xNBrgOUcG6y0+9+BddUUaed1WoWj e6IlA44AHUpODJOj6iD0fxEe5Rqo61Sgrka5TILwZ+yUxf3F4TM02P8A5wAPYVi/rpjv Lb+Z9GT2kuWC9bSlOxuoZ2iBnTMIPUwxub6MugNfybnwUdL72K61jfkQTXcPHYOL0r47 FlWQ== 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; bh=+2hFtpVgNxGxFh7KdbqUNhwdxjbhrYis2vpq5dIL0OI=; b=ujMUjiIt7KxFWwqsADWrmYPpDbQC6scr4DWrgZIWQ9xDds6VaJuHDkFMHcS7iqsw1W flKOYZo+tUf68lBGLRPDb+oLrpG7jlO9oqSBTP4xj6TFNevzWFLenOIV7OWJCNjHE7UI tAYOJMi8Zp8HwJzK8NVRSlSQY4Q+89d+NIMubeLQsDDXizUbqjS2SXbUVexKEJ0A+clK R2XJZeVrAaLZFce/l2jKfsvYuZ1MW8Q6J9DLgH/YvrZHGdSPPZw2+ujnTpQfs/K8xIiL jr5Lqy/311E87ClPBvd5xXaqSyd7r0if+AqQ/NsKdy4cONN8bgHpcIsnqbNBzDV1MH10 G2yQ== X-Gm-Message-State: APjAAAVdQchNJ7YzyyC9zinpfT/N7YGxvmoOH12nG6+BXUPjdBHFL9tp BFZYl2FcfW4fTlr21ApHE8i0GTOk69HnpoWx6wOZPFS1 X-Google-Smtp-Source: APXvYqylU96fSpCGtVz2AUyeszmIwKL6Mhay1G3zDm/UGjI9IWWxVKqw2XMhxOepUp74IXgN0AbrLgOCE++LH0ADaqI= X-Received: by 2002:a19:ced0:: with SMTP id e199mr13341264lfg.40.1552258134379; Sun, 10 Mar 2019 15:48:54 -0700 (PDT) MIME-Version: 1.0 References: <155225788929.31119.6163123092023904647@ietfa.amsl.com> In-Reply-To: <155225788929.31119.6163123092023904647@ietfa.amsl.com> From: Andy Bierman Date: Sun, 10 Mar 2019 15:48:43 -0700 Message-ID: To: Netconf Content-Type: multipart/alternative; boundary="000000000000b3237d0583c54250" Archived-At: Subject: [netconf] Fwd: I-D Action: draft-bierman-netconf-module-tag-ops-00.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: Sun, 10 Mar 2019 22:49:00 -0000 --000000000000b3237d0583c54250 Content-Type: text/plain; charset="UTF-8" FYI, I have written a draft proposing some standard usage of the Module Tags draft. I would like a 10 - 15 minute slot at the NETCONF WG meeting to discuss the problem statement of using module tags in standard protocols. Andy ---------- Forwarded message --------- From: Date: Sun, Mar 10, 2019 at 3:45 PM Subject: I-D Action: draft-bierman-netconf-module-tag-ops-00.txt To: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Module Tag Operations Author : Andy Bierman Filename : draft-bierman-netconf-module-tag-ops-00.txt Pages : 15 Date : 2019-03-10 Abstract: This document describes enhancements to existing NETCONF and RESTCONF (NMDA) operations for using module tags to represent YANG datastore content. This can simplify usage of these operations by a client. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bierman-netconf-module-tag-ops/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-bierman-netconf-module-tag-ops-00 https://datatracker.ietf.org/doc/html/draft-bierman-netconf-module-tag-ops-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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --000000000000b3237d0583c54250 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FYI,

I have written a draft proposing s= ome standard usage of the Module Tags draft.
I would like a 10 - = 15 minute slot at the NETCONF WG meeting to discuss the
problem s= tatement of using module tags in standard protocols.

Andy

---------- Forwarded message ---------
From: <internet-drafts@ietf.org= >
Date: Sun, Mar 10, 2019 at 3:45 PM
Subject: I-D Actio= n: draft-bierman-netconf-module-tag-ops-00.txt
To: <i-d-announce@ietf.org>


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Module Tag Operations
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Andy= Bierman
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-bie= rman-netconf-module-tag-ops-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 15
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-03-10

Abstract:
=C2=A0 =C2=A0This document describes enhancements to existing NETCONF and R= ESTCONF
=C2=A0 =C2=A0(NMDA) operations for using module tags to represent YANG data= store
=C2=A0 =C2=A0content.=C2=A0 This can simplify usage of these operations by = a client.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/d= oc/draft-bierman-netconf-module-tag-ops/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft= -bierman-netconf-module-tag-ops-00
https://datatracker.iet= f.org/doc/html/draft-bierman-netconf-module-tag-ops-00


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce=
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
--000000000000b3237d0583c54250-- From nobody Mon Mar 11 01:17:57 2019 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 E998813106D; Mon, 11 Mar 2019 01:17:48 -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: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155229226889.16809.6104712795955178997@ietfa.amsl.com> Date: Mon, 11 Mar 2019 01:17:48 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-udp-pub-channel-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: Mon, 11 Mar 2019 08:17:49 -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 Publication Channel for Streaming Telemetry Authors : Guangying Zheng Tianran Zhou Alexander Clemm Filename : draft-ietf-netconf-udp-pub-channel-05.txt Pages : 21 Date : 2019-03-11 Abstract: This document describes a UDP-based publication channel for streaming telemetry use to collect data from devices. A new shim header is proposed to facilitate the distributed data collection mechanism which directly pushes data from line cards to the collector. Because of the lightweight UDP encapsulation, higher frequency and better transit performance can be achieved. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-pub-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-udp-pub-channel-05 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-pub-channel-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-udp-pub-channel-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 Mon Mar 11 09:26:40 2019 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 D624513113E for ; Mon, 11 Mar 2019 09:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZsN_atVkHyRx for ; Mon, 11 Mar 2019 09:26:26 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 9590813110F for ; Mon, 11 Mar 2019 09:26:24 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id y18so3929212lfe.1 for ; Mon, 11 Mar 2019 09:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=GXl/7Ym0SDg66n82nqrAN65xGT/NDcvy/wls+ThiEd8=; b=UiC3bT7SzyaPZnb9ZdRkuzTTU4ZmJeWljTUq3EgwLnoUUaO9C5Joe6+u0TMOXKi0JP zFa+j3H2ILSqGlEK5QUDnUk5pyb6JEQzsjKlWr4m6UoCzZN0tk08ou4wbVVe5x2Rlpre MqtdkthREZIWi+WAEK85DryV7wcmpnKhjQ8drY0aIPTLugZuABbMJUHevABmud7iqWez uBabQaaCil3UZu2Cr4K3RfBtfCJ269x62DIbVe+hYEUVU/CQF05wlJIs8TQREIPKWLpH UY5ssGil8OnLBVhxX24VPd/Zw0oJX+ksUFtw9cuYIa0ot00u3ticVbFAcex1uYuHzYsl pBZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GXl/7Ym0SDg66n82nqrAN65xGT/NDcvy/wls+ThiEd8=; b=c5YuBOgGKjr/AesylJWdAvctKHogCECYQfMBJRq9jAkL/l2/DeWaW4oQd18g6ZUiKn jKcy3O51WXbxjbTZRqOFcGEJ3fyXi322Bq3Wmn6wmff1VO56mZT1tfUmMEPxIMwGOP28 urWtL+nnsw5/u2cjFudlPsga1HAWUElxJrny6E/J7PBSY0tsU6kYlYb/wBrFkNuMDLMd QC0ViWT7CtECavDjoZ4QXDpuDh4wnsGWM+n6KiLcqabaQKkApSvt3JWmf96LcvQYwRM4 RddDesRRpWW49jFr1raKZIsE9bGoR8WO3ux9QUlZzxHGUUbnIoX2r5paSHKsytBGd7/P t7Lw== X-Gm-Message-State: APjAAAXAfJJLxCcl4pcgjZxjNYFSWVxvzSc11p93v/+3JnVzRcp5otQ4 wliSmXoDRZe8OW79XJGWZjMRjFxh7m2DuNAz1yLOM0/G X-Google-Smtp-Source: APXvYqyzXQ/owgCguq9OPLSV6G9xfSVMhwcXqsgGYtjPpfqjY+L6R8wviW23c8iccHuvjVvGtPieiUlGlxfn7oSj4Cw= X-Received: by 2002:ac2:4142:: with SMTP id c2mr18257192lfi.84.1552321582314; Mon, 11 Mar 2019 09:26:22 -0700 (PDT) MIME-Version: 1.0 From: Fabio Zaccantte Date: Mon, 11 Mar 2019 13:24:40 -0300 Message-ID: To: netconf@ietf.org Content-Type: multipart/alternative; boundary="0000000000007db8c60583d408e1" Archived-At: Subject: [netconf] Question about router management with Netopeer2 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, 11 Mar 2019 16:26:34 -0000 --0000000000007db8c60583d408e1 Content-Type: text/plain; charset="UTF-8" Hi, i would like to know about routing management with Netopeer2. I have one router and one pc like my server. Do i need to install NETCONF im my router? Do i need to install NETOPEER in the my server? Sorry if my questions is basic, but i am new in NETCONF. Regards, Fabio. --0000000000007db8c60583d408e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, i would like to know about routing ma= nagement with Netopeer2. I have one router and one pc like my server.
=
=C2=A0
Do i need to install NETCONF im my router?
<= div>
Do i need to install=C2=A0NETOPEER=C2=A0in the my server= ?

Sorry if my questions is basic, but i am new in = NETCONF.

Regards,
Fabio.
--0000000000007db8c60583d408e1-- From nobody Tue Mar 12 04:46:28 2019 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 2EBB6130F28 for ; Tue, 12 Mar 2019 04:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz 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 m4T4PJGOZMAq for ; Tue, 12 Mar 2019 04:46:24 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (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 29559130F1C for ; Tue, 12 Mar 2019 04:46:23 -0700 (PDT) Received: from pckrejci.nat9.vcit.vutbr.net (unknown [IPv6:2001:67c:1220:80c:d0:552c:73a5:18da]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id A7666400065; Tue, 12 Mar 2019 12:46:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1552391180; bh=lwqnVJek0Px7fLsfvZn7aTKgFMUjV4H6kUW2NOrZXDc=; h=Subject:To:References:From:Date:In-Reply-To; b=aL3FjPgcvb97aFw1FSOe2lJJRNYxkuSibJIQHQT4j+kkGnXfyHVctXZrU652hnCfm 81dInAIP8x7sxcAvozngd7BBM6txMgQ+ygiEzO74MQUlQtPzTFvBJFiJIpHTyT6lRO 196/h82gGT0P2m8ZYaVHX+nPQ+bIafyBozZWK6bs= To: Fabio Zaccantte , netconf@ietf.org References: From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= Openpgp: preference=signencrypt Autocrypt: addr=rkrejci@cesnet.cz; prefer-encrypt=mutual; keydata= mQGiBEKfHd4RBADDE8CtJpEtOraXBKfQg0KCRZu7BRALixoLqW98U+N9h+PJ+gCnFaKNmnYu fXWLYKTJRUlaoMGIJOZjHpr/zvwozSR+VJkxCsTyNYTF8vIfN3Iwrxy9e8CNy/O1GI50K/ld WWMDl+3M2NztiBFPrCT0b/U5ErsN7bTrf2XLEQRpZwCg95POGbJPqPAaaok2KU5e2u0/flsD /AyC0aRO66Ci0OGw0R5sCJmzZ5xE5eBUvfx0N0IC16aojrwRYM5yf+bULtBDd4wPI1R+VH/X P6OrDgzlDmutJthVtYfCcho3IhqnVo1R/UvJxjF3ATKbOnVHL4xwiLSrRDb6rKVyd1+Kc7cq +JABgFl+JP4xndytvvUXdVqhuSUFBACCDdDtxutkclBrvEp2guBIftuT4/oK3IWxgtevlGfY LZXwdD6pIWS1z6y6xthoFTsLWS1QCFk2ZXmAgvOV/lnW0iGHwO5kCfzvWJq7weeH2FGuBgq+ WInxhdIFD/QwiXV6EPUWzAoC5Fx4Cz5ySFSd6n0C1Mrzin3ABtPHRpUT8rQpUmFkZWsgS3Jl amNpIChDRVNORVQpIDxya3JlamNpQGNlc25ldC5jej6IYgQTEQIAIgUCTT/pkAIbAwYLCQgH AwIGFQgCCQoLBBYCAwECHgECF4AACgkQIMoxClN+p/31DwCfWVWX1IWaUa6+QbuVvZQIkb6m Rn8AoLRvdANGe/As/Nxabu+KKtrorkQ6uQENBEKfHeIQBACwORs231u+o9/pM7y85ZlZhnNY iJziZ4P5W9lD5cwcEUFgTt1upUmjjSMWr5x4HL6o5jZeKOQMxiYP+8qA8OPEM6fzemS1Uj9M 6RXUaoUZFrcKD6BvneyyKuGgNa9bQfTG0aDOqaxy4lYFNcHVeo9sXJ+6adVxlCo/GzZ6zznn nwADBQP+IZQoao7aCFkZOVk8F5AW9Iiz0hk1trdCw88vD5fPMqcLxOQEsKrHAjibTWyOy1il 9zgLyVjcBzOs+v6UvbcJRybyaITC7j4IFPr78euVup/AeL+A9ay+ZWKHMFzALD+VjLyYAiRL w2MBjdqAKbPh2Ei1HXJoOX5JTWWnMRsBey+ISQQYEQIACQUCQp8d4gIbDAAKCRAgyjEKU36n /YssAKDVrEroZMSci018ipG4q6w11TsriwCghwCwX0isavqXJTbw10hwJePlDns= Message-ID: <8dcacb89-35ec-f61d-5325-4a5299c27482@cesnet.cz> Date: Tue, 12 Mar 2019 12:46:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [netconf] Question about router management with Netopeer2 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, 12 Mar 2019 11:46:27 -0000 Hi Fabio, please see the Netopeer2 docs (start here [1]) and if you will still have= questions, use the project's github issue tracker [2]. Netopeer2 is just= one of the NETCONF implementations, so the protocol specification mailin= g list (netconf@ietf.org) is not the right place for your questions. Regards, Radek [1] - https://github.com/CESNET/Netopeer2/blob/master/server/README.md [2] - https://github.com/CESNET/Netopeer2/issues Dne 11. 03. 19 v 17:24 Fabio Zaccantte napsal(a): > Hi, i would like to know about routing management with Netopeer2. I hav= e one router and one pc like my server. > =C2=A0 > Do i need to install NETCONF im my router? > > Do i need to install=C2=A0NETOPEER=C2=A0in the my server? > > Sorry if my questions is basic, but i am new in NETCONF. > > Regards, > Fabio. > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=20 Radek Krejci mobile : +420 732 212 714 office : +420 234 680 256 e-mail : rkrejci@cesnet.cz LinkedIn: http://www.linkedin.com/in/radekkrejci CESNET, Association of Legal Entities Zikova 4 Office: Bozetechova 1 160 00 Praha 6 612 66 Brno Czech Republic Czech Republic From nobody Wed Mar 13 17:21:56 2019 Return-Path: <0100016979939b1b-3ddaf119-fd79-4b38-b80b-2be09d10fc3c-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 E02EA124BA8 for ; Wed, 13 Mar 2019 17:21:54 -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_DNSWL_NONE=-0.0001, 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 DNQ1aeDQe-kU for ; Wed, 13 Mar 2019 17:21:52 -0700 (PDT) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDCAF1200D7 for ; Wed, 13 Mar 2019 17:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1552522910; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=mSYictm9Zd/g6t9be9TXKK/Vh5jL/wf25E7GV9FOack=; b=iBAEtcxbNOtbqPchYjf2KmDZuBXf0SOAkIbM57OKdaYM/ipQsfH2f53zn/VqKUKg mQhWLFaVBlYxkLKt7mMm/kpzFbs4TglZUzhqWQWbqKdAq7TZj81Rj3gXcZ3UdWOTVtO 5lSIp0PoeMMXnnKZImsMkmVatisxKVrahS1VtInM= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_07AD5DBB-89B1-4086-AA60-A377AC560D8B" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-ID: <0100016979939b1b-3ddaf119-fd79-4b38-b80b-2be09d10fc3c-000000@email.amazonses.com> Date: Thu, 14 Mar 2019 00:21:50 +0000 To: netconf@ietf.org X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.14-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] NETCONF 104 Draft Agenda 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, 14 Mar 2019 00:21:55 -0000 --Apple-Mail=_07AD5DBB-89B1-4086-AA60-A377AC560D8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Draft agenda below (also posted here: = https://datatracker.ietf.org/doc/agenda-104-netconf = ). Please send any comments and/or concerns to the chairs. ALERT: Due to a large number of folks not being present for NETMOD = Session-2 on=20 Friday, and an unusually low NETCONF agenda, the NETCONF = Chairs agreed to let NETMOD use some of its scheduled time, thus enabling = NETMOD to CANCEL its originally scheduled second session. Agenda for the NETCONF WG Session in IETF 104 --------------------------------------------- Session: *** Special meeting, time split with NETMOD WG *** MONDAY, March 25, 2019 09:00-11:00 (NETCONF: 9-10, NETMOD 10-11) Morning Session I Room: Grand Ballroom =20 WG Chairs: Mahesh Jethanandani (mjethanandani at gmail dot com) Kent Watsen (kwatsen at juniper dot net) =20 Available During Session: Audio stream: http://mp3.conf.meetecho.com/ietf/ietf1046.m3u Etherpad: = http://etherpad.tools.ietf.org/p/notes-ietf-104-netconf Slides: = https://datatracker.ietf.org/meeting/104/session/netconf Meetecho: http://www.meetecho.com/ietf104/netconf/ Jabber: xmpp:netconf@jabber.ietf.org?join =20 Available Post Session: Recording: https://www.ietf.org/audio/ietf104/ YouTube: https://www.youtube.com/user/ietf/playlists =20 =20 Introduction Chairs (10 minutes) Session Intro & WG Status =20 Chartered items: Kent Watsen (10 min) Status and Issues on Client-Server Drafts https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-05 https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-03 https://tools.ietf.org/html/draft-ietf-netconf-keystore-08 https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-11 https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-10 = https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-10 = https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-10 = https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00 = https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-00 Tianran Zhou (10 min) Subscription to Multiple Stream Originators = https://tools.ietf.org/html/draft-zhou-netconf-multi-stream-originators-04= Balazs Lengyel (10 min) YangPush Notification Capabilities = https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-0= 1 Non-Chartered items: Michael Wang / Qin Wu (10 min) NMDA Backwards-Compatibility with Legacy Devices https://tools.ietf.org/html/draft-wu-netconf-nmda-compatibility-00 Andy Bierman (10 min) Module Tag Operations https://tools.ietf.org/html/draft-bierman-netconf-module-tag-ops-00 NETMOD WG items: Lou Berger & Kent Watsen, as NETMOD Chairs (5 minutes) Introduction Rob Wilton and Company (45 min) YANG Versioning Design Team Update https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02 https://tools.ietf.org/html/draft-verdt-netmod-yang-semver-00 Rob Wilton (10 min) YANG Packages https://tools.ietf.org/html/draft-rwilton-netmod-yang-packages-01 --Apple-Mail=_07AD5DBB-89B1-4086-AA60-A377AC560D8B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Draft agenda below (also posted here: https://datatracker.ietf.org/doc/agenda-104-netconf).
=
Please send any comments and/or concerns to the = chairs.

ALERT: = Due to a large number of folks not being present for NETMOD Session-2 = on 
            =  Friday, and an unusually low NETCONF agenda, the NETCONF Chairs = agreed
            =  to let NETMOD use some of its scheduled time, thus enabling NETMOD = to
            =  CANCEL its originally scheduled second session.

Agenda for the NETCONF WG =
Session in IETF 104
---------------------------------------------

Session:   *** Special meeting, time split with NETMOD WG ***

   MONDAY, March 25, 2019 09:00-11:00   (NETCONF: 9-10, NETMOD 10-11)
   Morning Session I
   Room: Grand Ballroom
         =20
WG Chairs:
   Mahesh Jethanandani (mjethanandani at gmail dot com)
   Kent Watsen (kwatsen at juniper dot net)
         =20
Available During Session:
   Audio stream:  http://mp3.conf.meetecho.com/ietf/ietf1046.m3u
   Etherpad:      http://etherpad.tools.ietf.org/p/notes-ietf-104-netconf
   Slides:        https://datatracker.ietf.org/meeting/104/session/netconf
   Meetecho:      http://www.meetecho.com/ietf104/netconf/
   Jabber:        xmpp:netconf@jabber.ietf.org?join
         =20
Available Post Session:
   Recording:     https://www.ietf.org/audio/ietf104/
   YouTube:       https://www.youtube.com/user/ietf/playlists
         =20
         =20
Introduction

  Chairs (10 minutes)
  Session Intro & WG Status
         =20
Chartered items:

   Kent Watsen (10 min)
   Status and Issues on Client-Server Drafts
   https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-05<=
/a>
   https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-03=

   https://tools.ietf.org/html/draft-ietf-netconf-keystore-08
   https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-serve=
r-11
   https://tools.ietf.org/html/draft-ietf-netconf-tls-client-serve=
r-10
   https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-s=
erver-10
   https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-=
server-10
   https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-se=
rver-00
   https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-s=
erver-00

   Tianran Zhou (10 min)
   Subscription to Multiple Stream Originators
   https://tools.ietf.org/html/draft-zhou-netconf-multi-stream-ori=
ginators-04

   Balazs Lengyel (10 min)
   YangPush Notification Capabilities
   https://tools.ietf.org/html/draft-ietf-netconf-notification-cap=
abilities-01

Non-Chartered items:

   Michael Wang / Qin Wu (10 min)
   NMDA Backwards-Compatibility with Legacy Devices
   https://tools.ietf.org/html/draft-wu-netconf-nmda-compatibility=
-00

   Andy Bierman (10 min)
   Module Tag Operations
   https://tools.ietf.org/html/draft-bierman-netconf-module-tag-op=
s-00

NETMOD WG items:

  Lou Berger & Kent Watsen, as NETMOD Chairs (5 minutes)
  Introduction

  Rob Wilton and Company (45 min)
  YANG Versioning Design Team Update
  https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-=
reqs-02
  https://tools.ietf.org/html/draft-verdt-netmod-yang-semver-00

  Rob Wilton (10 min)
  YANG Packages
  https://tools.ietf.org/html/draft-rwilton-netmod-yang-packages-=
01
= --Apple-Mail=_07AD5DBB-89B1-4086-AA60-A377AC560D8B-- From nobody Thu Mar 14 01:53:08 2019 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 528C9127916 for ; Thu, 14 Mar 2019 01:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yX1p-Fr1Xv6n for ; Thu, 14 Mar 2019 01:53:03 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40120.outbound.protection.outlook.com [40.107.4.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482121277C9 for ; Thu, 14 Mar 2019 01:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=d9uzytcNhdUQL4zsbumwPkUtgbPnfja2HDuJ2INhnZ0=; b=cmaDamvYhqY8j6SyEZKOFYIW2wdS0oTt+F8nHXHzyfyUTLsijmxKyUFj2y3gGdMIsOKw+Fzx89T1X/9IyOVmtQVBubZ5U2+zvqA9OXd04RYVrjqkpiGtR2QCjo0XBZGcSUpEN/WuaXGJt+AT4EVVLIEviGkAxvgprPv6qhEiQT4= Received: from DB7PR07MB5386.eurprd07.prod.outlook.com (20.178.46.26) by DB7PR07MB4935.eurprd07.prod.outlook.com (20.177.192.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.8; Thu, 14 Mar 2019 08:53:00 +0000 Received: from DB7PR07MB5386.eurprd07.prod.outlook.com ([fe80::181c:32c6:16f2:7433]) by DB7PR07MB5386.eurprd07.prod.outlook.com ([fe80::181c:32c6:16f2:7433%3]) with mapi id 15.20.1709.011; Thu, 14 Mar 2019 08:53:00 +0000 From: "Wisotzky, Sven (Nokia - DE/Stuttgart)" To: "netconf@ietf.org" Thread-Topic: Usage examples for max-depth (rfc8526) Thread-Index: AQHU2kNT5zRVd6q0aUyVnM8yIqQf4A== Date: Thu, 14 Mar 2019 08:53:00 +0000 Message-ID: <0AA9F087-D2FF-42EA-8ACA-FD44FAA57890@nokia.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.0.190309 x-originating-ip: [188.97.190.16] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5895082b-5aa4-407d-b23b-08d6a85a768e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:DB7PR07MB4935; x-ms-traffictypediagnostic: DB7PR07MB4935: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 09760A0505 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(366004)(136003)(376002)(39860400002)(189003)(199004)(7736002)(97736004)(81166006)(53376002)(68736007)(102836004)(33656002)(105586002)(2906002)(2351001)(256004)(14444005)(106356001)(5660300002)(2501003)(8676002)(1730700003)(6506007)(8936002)(81156014)(25786009)(99286004)(3846002)(6116002)(6346003)(36756003)(316002)(478600001)(6916009)(2616005)(82746002)(58126008)(14454004)(486006)(186003)(26005)(476003)(5640700003)(305945005)(66066001)(6306002)(86362001)(71200400001)(6486002)(71190400001)(6512007)(83716004)(6436002)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB4935; H:DB7PR07MB5386.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=sven.wisotzky@nokia.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: MTZ1YC4WzZmpZmp0tMprU8+MxxuJsgMcqKRd5eRaxemWycglGNAqyhcVOZzPFbQpRFUvSNdegufUHcgxeNwZI3r3htEQRbnA6U/X3wSPKYaZH3h59iai9GkjEg4dRFXfNqG7SsT9fPpdfy7ZfbuXaNG0Sevfzgfl4294uFAuot6hf5nt6ZsREJL96j81v0espFlUmjxgoa0N/EV+MwXlkvh17DaxPmHJyEb2uZda4dFCDRu7ON/oYIpJbSNEjOfuXPxc9kFvTOrz1j7e1e8rr9445pEPweY9DhAFsX/EnY3EQZmX579tKHaDlHfREFMSMNEXrA54Jzb8Dxwg6m4rDTf/OTvse4kV3Jc4BhiEE2jEDWnGSd0fKEXn+yRKql8DzbEuBHdFtn5UzfsWMQeXR/1cl6ziBhxI04hBD55z5xo= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5895082b-5aa4-407d-b23b-08d6a85a768e X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2019 08:53:00.7939 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4935 Archived-At: Subject: [netconf] Usage examples for max-depth (rfc8526) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 08:53:06 -0000 VW5mb3J0dW5hdGVseSB0aGUgaW5mbyBwcm92aWRlZCBpbiBSRkMgODUyNiBhYm91dCB0aGUgbWF4 LWRlcHRoIGF0dHJpYnV0ZSBpcyBub3QgdmVyeSBwcmVjaXNlLg0KSXMgaXQgZmFpciB0byBhc3N1 bWUsIHRoYXQgYmVoYXZpb3IgaXMgYWxpZ25lZCB3aXRoIHRoZSBSRVNUQ09ORiAiZGVwdGgiIGF0 dHJpYnV0ZSBkZXNjcmliZWQgaW4gUkZDIDgwNDA/DQoNCkxldCdzIHVzZSB0aGUgZm9sbG93aW5n IHNhbXBsZSBmcm9tIGNoYXB0ZXIgMy4xLjEuMzoNCiAgICAgICA8dG9wIHhtbG5zPSJodHRwOi8v ZXhhbXBsZS5jb20vc2NoZW1hLzEuMi9jb25maWciPg0KICAgICAgICAgPHVzZXJzPg0KICAgICAg ICAgICA8dXNlcj4NCiAgICAgICAgICAgICA8bmFtZT5yb290PC9uYW1lPg0KICAgICAgICAgICAg IDx0eXBlPnN1cGVydXNlcjwvdHlwZT4NCiAgICAgICAgICAgICA8ZnVsbC1uYW1lPkNoYXJsaWUg Um9vdDwvZnVsbC1uYW1lPg0KICAgICAgICAgICAgIDxjb21wYW55LWluZm8+DQogICAgICAgICAg ICAgICA8ZGVwdD4xPC9kZXB0Pg0KICAgICAgICAgICAgICAgPGlkPjE8L2lkPg0KICAgICAgICAg ICAgIDwvY29tcGFueS1pbmZvPg0KICAgICAgICAgICA8L3VzZXI+DQogICAgICAgICAgIDwhLS0g YWRkaXRpb25hbCA8dXNlcj4gZWxlbWVudHMgYXBwZWFyIGhlcmUuLi4gLS0+DQogICAgICAgICA8 L3VzZXJzPg0KICAgICAgIDwvdG9wPg0KDQpFeGFtcGxlIDE6IG5vIHN1YnRyZWUgZmlsdGVyIGlz IHByb3ZpZGVkLCBtYXgtZGVwdGg9MQ0KICAgICAgIDx0b3AgeG1sbnM9Imh0dHA6Ly9leGFtcGxl LmNvbS9zY2hlbWEvMS4yL2NvbmZpZyI+DQogICAgICAgPC90b3A+DQoNCkV4YW1wbGUgMjogbm8g c3VidHJlZSBmaWx0ZXIgaXMgcHJvdmlkZWQsIG1heC1kZXB0aD0yDQogICAgICAgPHRvcCB4bWxu cz0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS8xLjIvY29uZmlnIj4NCiAgICAgICAgIDx1c2Vy cz4NCiAgICAgICAgIDwvdXNlcnM+DQogICAgICAgPC90b3A+DQpBc3N1bXB0aW9uIHRoZSBjb250 YWluZXIgPHVzZXJzPiB3b3VsZCBvbmx5IGJlIHByZXNlbnQgaW4gdGhlIHJlc3VsdCwgaWYgdGhp cyBjb250YWluZXIgaGFzIGFueSBleHBsaWNpdCBjaGlsZHJlbiBjb25maWd1cmF0aW9uLiBJZiB0 aGVyZSBpcyBubyBjaGlsZHJlbiBjb25maWcsIGl0IHdvdWxkIG5vdCBiZSBwYXJ0IG9mIHRoZSBv dXRwdXQuDQoNCkV4YW1wbGUgMzogbm8gc3VidHJlZSBmaWx0ZXIgaXMgcHJvdmlkZWQsIG1heC1k ZXB0aD0zDQogICAgICAgPHRvcCB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS8xLjIv Y29uZmlnIj4NCiAgICAgICAgIDx1c2Vycz4NCiAgICAgICAgICAgPHVzZXI+DQogICAgICAgICAg IDwvdXNlcj4NCiAgICAgICAgIDwvdXNlcnM+DQogICAgICAgPC90b3A+DQpTb21ld2hhdCBpbnRl cmVzdGluZyBzY2VuYXJpby4gSXQgcHJvdmlkZXMgdGhlIG5ldGNvbmYgY2xpZW50IHdpdGggYSBt ZXRob2QgdG8gY2hlY2ssIGlmIGEgbGlzdCBjb250YWlucyBhbnkgZW50cmllcy4gU28gaWYgdGhl IFhNTCBub2RlIDx1c2VyPiBpcyBjb250YWluZWQsIHdlIHdvdWxkIGtub3cgdGhhdCB0aGUgbGlz dCAidXNlciIgaGFzIGF0IGxlYXN0IG9uZSBlbnRyeS4gSG93ZXZlciwgdGhpcyBYTUwgb3V0cHV0 IHdvdWxkIG5vdCB2YWxpZGF0ZSBhZ2FpbnN0IHRoZSBZQU5HIG1vZGVsIC0gYmVjYXVzZSBsaXN0 LWtleXMgKHVzZXIvbmFtZSkgYXJlIG1hbmRhdG9yeS4gSW4gZXNzZW5jZSwgdGhhdCBjbGllbnQg cmVxdWlyZXMgdG8gYmUgZmxleGlibGUgd2hlbiBwYXJzaW5nIHN1Y2ggcmVzdWx0IGFuZCBjYW5u b3QgYmUgcmVzdHJpY3RlZCB0byBZQU5HLg0KDQpFeGFtcGxlIDQ6IG5vIHN1YnRyZWUgZmlsdGVy IGlzIHByb3ZpZGVkLCBtYXgtZGVwdGg9NA0KICAgICAgIDx0b3AgeG1sbnM9Imh0dHA6Ly9leGFt cGxlLmNvbS9zY2hlbWEvMS4yL2NvbmZpZyI+DQogICAgICAgICA8dXNlcnM+DQogICAgICAgICAg IDx1c2VyPg0KICAgICAgICAgICAgIDxuYW1lPnJvb3Q8L25hbWU+DQogICAgICAgICAgICAgPHR5 cGU+c3VwZXJ1c2VyPC90eXBlPg0KICAgICAgICAgICAgIDxmdWxsLW5hbWU+Q2hhcmxpZSBSb290 PC9mdWxsLW5hbWU+DQogICAgICAgICAgICAgPGNvbXBhbnktaW5mbz4NCiAgICAgICAgICAgICA8 L2NvbXBhbnktaW5mbz4NCiAgICAgICAgICAgPC91c2VyPg0KICAgICAgICAgICA8IS0tIGFkZGl0 aW9uYWwgPHVzZXI+IGVsZW1lbnRzIGFwcGVhciBoZXJlLi4uIC0tPg0KICAgICAgICAgPC91c2Vy cz4NCiAgICAgICA8L3RvcD4NClNpbWlsYXIgdG8gZXhhbXBsZSAyLCB0aGUgY29udGFpbmVyIDxj b21wYW55LWluZm8+IHdvdWxkIG9ubHkgYmUgcHJlc2VudCwgaWYgdGhpcyBjb250YWluZXIgaGFz IGV4cGxpY2l0IGNoaWxkcmVuIGNvbmZpZ3VyYXRpb24uDQoNCg0KU29tZW9uZSBwbGVhc2UgdG8g Y29uZmlybSwgaWYgdGhvc2UgZXhhbXBsZXMgYW5kIGFzc3VtcHRpb25zIGJlaW5nIG1hZGUgYXJl IGNvcnJlY3QhDQoNCi93aXNvDQoNCg== From nobody Thu Mar 14 02:24:02 2019 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 14FF512867A for ; Thu, 14 Mar 2019 02:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1sLi5wjy67u for ; Thu, 14 Mar 2019 02:23:57 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03on0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0a::723]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6A9F12865E for ; Thu, 14 Mar 2019 02:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wJX/kHuHSGndkLn2KcD7jGjkrhsnGESqMYXxhwJz+q4=; b=XZzbNnEeAtDy787ON325fxUGvXPPLOjaxH/AlQFbQSAekwZ9oRRJrO5eW+ARdMGro031hcmsaoVE9piak2q9BOu4FfkAZv45GJgNVUbkqqoFwZhVvTFlpIO169hcIpkANhP5cgxAjSvfTKaaKXgDAiV7bWM8TtPEZQoUIXbctV4= Received: from DB7PR07MB5386.eurprd07.prod.outlook.com (20.178.46.26) by DB7PR07MB5418.eurprd07.prod.outlook.com (20.178.84.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.8; Thu, 14 Mar 2019 09:23:54 +0000 Received: from DB7PR07MB5386.eurprd07.prod.outlook.com ([fe80::181c:32c6:16f2:7433]) by DB7PR07MB5386.eurprd07.prod.outlook.com ([fe80::181c:32c6:16f2:7433%3]) with mapi id 15.20.1709.011; Thu, 14 Mar 2019 09:23:54 +0000 From: "Wisotzky, Sven (Nokia - DE/Stuttgart)" To: "netconf@ietf.org" Thread-Topic: Current activities on RESTCONF/NETCONF to support paging Thread-Index: AQHU2kekdlWyfgR30USJDGKLseBWag== Date: Thu, 14 Mar 2019 09:23:53 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.0.190309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=sven.wisotzky@nokia.com; x-originating-ip: [188.97.190.16] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9133f481-cef4-4e19-ac1d-08d6a85ec717 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:DB7PR07MB5418; x-ms-traffictypediagnostic: DB7PR07MB5418: x-microsoft-antispam-prvs: x-forefront-prvs: 09760A0505 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(366004)(346002)(376002)(136003)(189003)(199004)(6436002)(68736007)(7736002)(256004)(316002)(99286004)(6486002)(36756003)(2351001)(105586002)(106356001)(33656002)(58126008)(71190400001)(83716004)(81166006)(81156014)(71200400001)(8676002)(97736004)(14444005)(66066001)(53936002)(2616005)(8936002)(476003)(1730700003)(3846002)(5640700003)(25786009)(486006)(6306002)(54896002)(6512007)(5660300002)(2501003)(6506007)(2906002)(478600001)(102836004)(14454004)(6916009)(86362001)(6116002)(82746002)(186003)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB5418; H:DB7PR07MB5386.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: TNH71Gg0RoA/4DpO9NuPFEVYq1R48BZLhJz0L4ny2ZBbZF4NBroqX/lkIQAbtGhUqQCHwWZLHld8Iz17SHzEg4AIm5wwu18B08x3c/uDWEr+M6BuwM0qKno5ATC6qvqRtc0zD7lg6MWrjRk2OYF3nmtlngpGwA2cn9RyTvr3/SsrgZDFbv1fkj/IG5P5YjeFSkWAFoIiUpYuloeJLmU7fc3pgJARXcqG9ufJLrwhw/+2ymb0tTWx4UV3ML5KV96vKNwDldOuvCdXJq03aVcemNNcyComKX6wsOcBg/i7Op9kRsNEhuWtZvSDbs56mbTlKCvBtzNFTbqTThat8JQDXsNGFj9gOWdD3JxNfkyZ+D5sfeyojY8S8FHyUqgsiEeqwqm7u48wcG+d0N3LppE8X8A7pPmC42PN4vzr/D7V2m4= Content-Type: multipart/alternative; boundary="_000_C88A38CA44B542A09DFAA67AE5456951nokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9133f481-cef4-4e19-ac1d-08d6a85ec717 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2019 09:23:53.8912 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5418 Archived-At: Subject: [netconf] Current activities on RESTCONF/NETCONF to support paging 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, 14 Mar 2019 09:24:01 -0000 --_000_C88A38CA44B542A09DFAA67AE5456951nokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsLA0KDQpUaGVyZSB3YXMgc29tZSBkaXNjdXNzaW9uIGluIGVhcmxpZXIgZGF5cyAoYmFjayBp biAyMDEyLzIwMTQpIHRvIHN1cHBvcnQgcGFnaW5nIGZvciBleHRyYS1sb25nIGxpc3RzLiBUaGUg bWFpbiB1c2UtY2FzZSBpcyBjbGVhcmx5IHRvIGltcHJvdmUgc3VwcG9ydCBmb3IgaW50ZXJhY3Rp dmUgdXNlci1mcm9udGVuZHMsIGFzIGxvYWRpbmcgZW50aXJlIGxpc3RzIHdpdGggcG90ZW50aWFs bHkgbW9yZSB0aGFuIDEwMC4wMDDigJlzIG9iamVjdHMgZWFzaWx5IGNhbiBiZWNvbWUgYSBuaWdo dG1hcmU6IGxvYWRpbmcgdGltZSwgbWVtb3J5IGNvbnN1bXB0aW9uLCBjcmFzaGVzLCDigKYNCg0K Rm9yIHRoZSBzYWtlIG9mIGltcGxlbWVudGF0aW9uLCBvbmUgd291bGQgc2ltcGx5IHByb3ZpZGUg YW4gYXR0cmlidXRlIGNhbGxlZCDigJxtYXgtY291bnTigJ0sIOKAnG1heC1lbnRyaWVz4oCdLCDi gJxtYXgtZWxlbWVudHPigJ0gb3Ig4oCcbGltaXTigJ0g4oCTIHdoaWNoIGJhc2ljYWxseSBkZWZp bmVzIHRoZSB1cHBlciBsaW1pdCBvZiBsaXN0IGVudHJpZXMgdG8gYmUgcmV0dXJuZWQuIEFza2lu ZyBmb3IgbGltaXQ9MTAg4oCTIGV2ZW4gaWYgdGhlIGxpc3QgY29udGFpbnMgYSAxMDBrIHRoZSBy ZXN1bHQgd291bGQgc2ltcGx5IHNob3cgMTAuIEZyb20gYW4gdXNlci1pbnRlcmZhY2UgcG9pbnQg b2YgdmlldywgdGhpcyBtaWdodCBiZSBlbm91Z2gg4oCTIGFzIHVzZXJzIHdvdWxkIHNlZSBob3cg dGhlIGxpc3QgZW50cmllcyBsb29rIGxpa2UgdG8gbmFycm93IGRvd24gdGhlIHNlYXJjaCBieSBh ZGRpbmcgYWRkaXRpb25hbCBzZWFyY2gvZmlsdGVyIGNyaXRlcmlhLiBTbyB0byBwcm90ZWN0IHRo ZSBjbGllbnQgc3lzdGVtIGFuZCBpbXByb3ZlbWVudHMgb24gbG9hZGluZyB0aW1lL21lbW9yeSBj b25zdW1wdGlvbnMg4oCTIHRoaXMgbWlnaHQgYmUganVzdCBlbm91Z2guDQoNCk1vcmUgYWR2YW5j ZWQgaW1wbGVtZW50YXRpb25zIG1pZ2h0IGFsbG93IHRoZSBORVRDT05GIGNsaWVudCB0byBzcGVj aWZ5IHRoZSDigJxvZmZzZXTigJ0gd2hpY2ggaXMgYmFzaWNhbGx5IHRoZSBpbmRleCBvZiB0aGUg Zmlyc3QgbGlzdCBlbnRyeSB0byBiZSByZXR1cm5lZC4gSW4gc3VjaCBjYXNlLCB0aGUgY2xpZW50 IGNvdWxkIGNvbnRpbnVlIHRvIGxvYWQgZnVydGhlciBwYWdlcyBvbiBjdXN0b21lciBkZW1hbmQg KGxpa2UgZHluYW1pY2FsbHkgd2hpbGUgc2Nyb2xsaW5nIGRvd24gdGhlIGxpc3Qgb3IgcHJlc3Np bmcgb24gdGhlIG5leHQgYnV0dG9uKS4gRXZlbiBpZiBwZW9wbGUgYXJlIG5vdCBjdXJpb3VzIHRo YXQgbXVjaCBhYm91dCBtZW1vcnkgY29uc3VtcHRpb24sIGV2ZW4gaXQgc2hvdWxkIGJlIHBvc3Np YmxlIHRvIGNvbnRpbnVlIGxvYWRpbmcgdGhlIHJlbWFpbmluZyBsaXN0IGluIHRoZSBiYWNrZ3Jv dW5kIOKAkyB3aGlsZSBzaG93aW5nIHRoZSBmaXJzdCBYIGl0ZW1zIGZhc3RlciBvbiB0aGUgdXNl ci1pbnRlcmZhY2VzLg0KDQpUbyBtYWtlIHN1Y2ggcGFnaW5nIHNvbHV0aW9uIGV2ZW4gbW9yZSBj b21wbGV0ZSwgZm9sbG93aW5nIHVzZS1jYXNlcyBhcmUgdG8gYmUgcmV2aWV3ZWQgZnJvbSBhIFJF U1RDT05GL05FVENPTkYgQVBJIHBvaW50IG9mIHZpZXc6DQovMS8gSG93IHRvIGZpZ3VyZSBvdXQg dGhlIG51bWJlciBvZiBsaXN0IGVudHJpZXMgbWF0Y2hpbmcgdGhlIGdpdmVuIGNyaXRlcmlhIGZv ciBhIGdpdmVuIGxpc3QsIHdpdGhvdXQgdGhlIG5lZWQgdG8gcG9sbCB0aGUgZW50aXJlIGxpc3Q/ IFRoaXMgY291bGQgYmUgaGVscGZ1bCB0byBvcGVyYXRvcnMgc3RyYWlnaHQgYXdheSwgYnV0IGFs c28gYWxsb3dzIGVhc2llciBpbXBsZW1lbnRhdGlvbiBmb3IgdGhpbmdzIGxpa2UgcHJvZ3Jlc3Mg YmFycy4NCi8yLyBEZWZpbmUgYSBzb3J0aW5nIGNyaXRlcmlhIGZvciBzZWFyY2ggcmVzdWx0cw0K LzMvIEltcHJvdmUgZmlsdGVyaW5nIGNhcGFiaWxpdGllcyBmb3Igc3VidHJlZSBmaWx0ZXJzIChl LmcuIGNvbnRhaW5zIG9wZXJhdG9yKQ0KDQpJIGRpZCBub3QgZm91bmQgYW55IGFjdGl2ZSBEUkFG VCBvciBSRkMgZm9yIHRoaXMuIFRoYXQgc2FpZCwgd2UgY2FuIHNlZSB2YXJpb3VzIHZlbmRvcnMg aW1wbGVtZW50aW5nIHByb3ByaWV0YXJ5IHNvbHV0aW9ucyBmb3IgdGhpcyBpbiB0aGVpciBSRVNU Q09ORiBzdGFja3MuDQpXb3VsZCByZWFsbHkgbGlrZSB0byBzZWUgYW4gSUVURiBkZWZpbmVkIGFw cHJvYWNoIGZvciB0aGlzLCB0byBhdm9pZCBtdWx0aS12ZW5kb3IgY2xpZW50cyBuZWVkIHRvIGRl YWwgdmFyaW91cyB2ZW5kb3JzIGltcGxlbWVudGF0aW9ucy4NCg0KL3dpc28NCg== --_000_C88A38CA44B542A09DFAA67AE5456951nokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: <22663762F799FD458407BB2185B351FA@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVk LXNwYWNlO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDIuMGNtIDcw Ljg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iREUiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0 RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFsbCw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+VGhlcmUgd2FzIHNvbWUgZGlzY3Vzc2lvbiBpbiBlYXJsaWVyIGRheXMgKGJhY2sgaW4gMjAx Mi8yMDE0KSB0byBzdXBwb3J0IHBhZ2luZyBmb3IgZXh0cmEtbG9uZyBsaXN0cy4gVGhlIG1haW4g dXNlLWNhc2UgaXMgY2xlYXJseSB0byBpbXByb3ZlIHN1cHBvcnQgZm9yIGludGVyYWN0aXZlIHVz ZXItZnJvbnRlbmRzLCBhcyBsb2FkaW5nDQogZW50aXJlIGxpc3RzIHdpdGggcG90ZW50aWFsbHkg bW9yZSB0aGFuIDEwMC4wMDDigJlzIG9iamVjdHMgZWFzaWx5IGNhbiBiZWNvbWUgYSBuaWdodG1h cmU6IGxvYWRpbmcgdGltZSwgbWVtb3J5IGNvbnN1bXB0aW9uLCBjcmFzaGVzLCDigKY8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Rm9yIHRoZSBzYWtlIG9mIGltcGxlbWVudGF0aW9uLCBvbmUgd291bGQgc2ltcGx5IHBy b3ZpZGUgYW4gYXR0cmlidXRlIGNhbGxlZCDigJxtYXgtY291bnTigJ0sIOKAnG1heC1lbnRyaWVz 4oCdLCDigJxtYXgtZWxlbWVudHPigJ0gb3Ig4oCcbGltaXTigJ0g4oCTIHdoaWNoIGJhc2ljYWxs eSBkZWZpbmVzIHRoZSB1cHBlciBsaW1pdCBvZiBsaXN0IGVudHJpZXMgdG8NCiBiZSByZXR1cm5l ZC4gQXNraW5nIGZvciBsaW1pdD0xMCDigJMgZXZlbiBpZiB0aGUgbGlzdCBjb250YWlucyBhIDEw MGsgdGhlIHJlc3VsdCB3b3VsZCBzaW1wbHkgc2hvdyAxMC4gRnJvbSBhbiB1c2VyLWludGVyZmFj ZSBwb2ludCBvZiB2aWV3LCB0aGlzIG1pZ2h0IGJlIGVub3VnaCDigJMgYXMgdXNlcnMgd291bGQg c2VlIGhvdyB0aGUgbGlzdCBlbnRyaWVzIGxvb2sgbGlrZSB0byBuYXJyb3cgZG93biB0aGUgc2Vh cmNoIGJ5IGFkZGluZyBhZGRpdGlvbmFsDQogc2VhcmNoL2ZpbHRlciBjcml0ZXJpYS4gU28gdG8g cHJvdGVjdCB0aGUgY2xpZW50IHN5c3RlbSBhbmQgaW1wcm92ZW1lbnRzIG9uIGxvYWRpbmcgdGlt ZS9tZW1vcnkgY29uc3VtcHRpb25zIOKAkyB0aGlzIG1pZ2h0IGJlIGp1c3QgZW5vdWdoLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5Nb3JlIGFkdmFuY2VkIGltcGxlbWVudGF0aW9ucyBtaWdodCBhbGxvdyB0aGUgTkVU Q09ORiBjbGllbnQgdG8gc3BlY2lmeSB0aGUg4oCcb2Zmc2V04oCdIHdoaWNoIGlzIGJhc2ljYWxs eSB0aGUgaW5kZXggb2YgdGhlIGZpcnN0IGxpc3QgZW50cnkgdG8gYmUgcmV0dXJuZWQuIEluIHN1 Y2ggY2FzZSwgdGhlIGNsaWVudCBjb3VsZCBjb250aW51ZQ0KIHRvIGxvYWQgZnVydGhlciBwYWdl cyBvbiBjdXN0b21lciBkZW1hbmQgKGxpa2UgZHluYW1pY2FsbHkgd2hpbGUgc2Nyb2xsaW5nIGRv d24gdGhlIGxpc3Qgb3IgcHJlc3Npbmcgb24gdGhlIG5leHQgYnV0dG9uKS4gRXZlbiBpZiBwZW9w bGUgYXJlIG5vdCBjdXJpb3VzIHRoYXQgbXVjaCBhYm91dCBtZW1vcnkgY29uc3VtcHRpb24sIGV2 ZW4gaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGNvbnRpbnVlIGxvYWRpbmcgdGhlIHJlbWFpbmlu ZyBsaXN0IGluDQogdGhlIGJhY2tncm91bmQg4oCTIHdoaWxlIHNob3dpbmcgdGhlIGZpcnN0IFgg aXRlbXMgZmFzdGVyIG9uIHRoZSB1c2VyLWludGVyZmFjZXMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRvIG1ha2Ug c3VjaCBwYWdpbmcgc29sdXRpb24gZXZlbiBtb3JlIGNvbXBsZXRlLCBmb2xsb3dpbmcgdXNlLWNh c2VzIGFyZSB0byBiZSByZXZpZXdlZCBmcm9tIGEgUkVTVENPTkYvTkVUQ09ORiBBUEkgcG9pbnQg b2Ygdmlldzo8YnI+DQovMS8gSG93IHRvIGZpZ3VyZSBvdXQgdGhlIG51bWJlciBvZiBsaXN0IGVu dHJpZXMgbWF0Y2hpbmcgdGhlIGdpdmVuIGNyaXRlcmlhIGZvciBhIGdpdmVuIGxpc3QsIHdpdGhv dXQgdGhlIG5lZWQgdG8gcG9sbCB0aGUgZW50aXJlIGxpc3Q/IFRoaXMgY291bGQgYmUgaGVscGZ1 bCB0byBvcGVyYXRvcnMgc3RyYWlnaHQgYXdheSwgYnV0IGFsc28gYWxsb3dzIGVhc2llciBpbXBs ZW1lbnRhdGlvbiBmb3IgdGhpbmdzIGxpa2UgcHJvZ3Jlc3MgYmFycy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPi8yLyBEZWZpbmUgYSBzb3J0aW5nIGNyaXRlcmlhIGZvciBzZWFyY2gg cmVzdWx0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+LzMvIEltcHJvdmUgZmlsdGVy aW5nIGNhcGFiaWxpdGllcyBmb3Igc3VidHJlZSBmaWx0ZXJzIChlLmcuIGNvbnRhaW5zIG9wZXJh dG9yKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5JIGRpZCBub3QgZm91bmQgYW55IGFjdGl2ZSBEUkFGVCBvciBSRkMg Zm9yIHRoaXMuIFRoYXQgc2FpZCwgd2UgY2FuIHNlZSB2YXJpb3VzIHZlbmRvcnMgaW1wbGVtZW50 aW5nIHByb3ByaWV0YXJ5IHNvbHV0aW9ucyBmb3IgdGhpcyBpbiB0aGVpciBSRVNUQ09ORiBzdGFj a3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Xb3VsZCByZWFsbHkgbGlrZSB0byBz ZWUgYW4gSUVURiBkZWZpbmVkIGFwcHJvYWNoIGZvciB0aGlzLCB0byBhdm9pZCBtdWx0aS12ZW5k b3IgY2xpZW50cyBuZWVkIHRvIGRlYWwgdmFyaW91cyB2ZW5kb3JzIGltcGxlbWVudGF0aW9ucy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+L3dpc288bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_C88A38CA44B542A09DFAA67AE5456951nokiacom_-- From nobody Thu Mar 14 02:36:01 2019 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 36BB1128701 for ; Thu, 14 Mar 2019 02:35:59 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 VMkfAMbKVMi1 for ; Thu, 14 Mar 2019 02:35:56 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E49F4128CB7 for ; Thu, 14 Mar 2019 02:35:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 705D99A; Thu, 14 Mar 2019 10:35:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id cmwwUYC7cQ8j; Thu, 14 Mar 2019 10:35:54 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 14 Mar 2019 10:35:54 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B20C20089; Thu, 14 Mar 2019 10:35:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id kqbV1BDcRafY; Thu, 14 Mar 2019 10:35:54 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id EBACC20086; Thu, 14 Mar 2019 10:35:53 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Thu, 14 Mar 2019 10:35:53 +0100 Received: by anna.localdomain (Postfix, from userid 501) id B4F47300734331; Thu, 14 Mar 2019 10:35:52 +0100 (CET) Date: Thu, 14 Mar 2019 10:35:52 +0100 From: Juergen Schoenwaelder To: "Wisotzky, Sven (Nokia - DE/Stuttgart)" CC: "netconf@ietf.org" Message-ID: <20190314093552.3pwa7ptrre4t2stk@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Wisotzky, Sven (Nokia - DE/Stuttgart)" , "netconf@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] Current activities on RESTCONF/NETCONF to support paging 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, 14 Mar 2019 09:35:59 -0000 One of the issues to consider is that depending on the datastore accessed, the data can change more or less rapidly and it is unclear whether you want servers to maintain potentially big amounts of state between requests. If you retrieve data in chunks, the question is whether you can simply put the data back together or the client side or whether this may lead to data that never really existed in that form on the server. With RESTCONF, etags may help to check whether the resource queried remains consistent (but then the server still has to be able to decide etag changes). But backing up for this discussion of details, I agree that this is a problem worth solving by standardizing a common solution. /js On Thu, Mar 14, 2019 at 09:23:53AM +0000, Wisotzky, Sven (Nokia - DE/Stut= tgart) wrote: > All, >=20 > There was some discussion in earlier days (back in 2012/2014) to suppor= t paging for extra-long lists. The main use-case is clearly to improve su= pport for interactive user-frontends, as loading entire lists with potent= ially more than 100.000=E2=80=99s objects easily can become a nightmare: = loading time, memory consumption, crashes, =E2=80=A6 >=20 > For the sake of implementation, one would simply provide an attribute c= alled =E2=80=9Cmax-count=E2=80=9D, =E2=80=9Cmax-entries=E2=80=9D, =E2=80=9C= max-elements=E2=80=9D or =E2=80=9Climit=E2=80=9D =E2=80=93 which basicall= y defines the upper limit of list entries to be returned. Asking for limi= t=3D10 =E2=80=93 even if the list contains a 100k the result would simply= show 10. From an user-interface point of view, this might be enough =E2=80= =93 as users would see how the list entries look like to narrow down the = search by adding additional search/filter criteria. So to protect the cli= ent system and improvements on loading time/memory consumptions =E2=80=93= this might be just enough. >=20 > More advanced implementations might allow the NETCONF client to specify= the =E2=80=9Coffset=E2=80=9D which is basically the index of the first l= ist entry to be returned. In such case, the client could continue to load= further pages on customer demand (like dynamically while scrolling down = the list or pressing on the next button). Even if people are not curious = that much about memory consumption, even it should be possible to continu= e loading the remaining list in the background =E2=80=93 while showing th= e first X items faster on the user-interfaces. >=20 > To make such paging solution even more complete, following use-cases ar= e to be reviewed from a RESTCONF/NETCONF API point of view: > /1/ How to figure out the number of list entries matching the given cri= teria for a given list, without the need to poll the entire list? This co= uld be helpful to operators straight away, but also allows easier impleme= ntation for things like progress bars. > /2/ Define a sorting criteria for search results > /3/ Improve filtering capabilities for subtree filters (e.g. contains o= perator) >=20 > I did not found any active DRAFT or RFC for this. That said, we can see= various vendors implementing proprietary solutions for this in their RES= TCONF stacks. > Would really like to see an IETF defined approach for this, to avoid mu= lti-vendor clients need to deal various vendors implementations. >=20 > /wiso > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Mar 14 02:38:14 2019 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 B60A312D84D for ; Thu, 14 Mar 2019 02:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 OAgpMzHK7Z4X for ; Thu, 14 Mar 2019 02:38:00 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 D0B5C128BCC for ; Thu, 14 Mar 2019 02:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x2E9bpvT018312; Thu, 14 Mar 2019 10:37:56 +0100 (CET) Received: from client-0024.vpn.uni-bremen.de (client-0024.vpn.uni-bremen.de [134.102.107.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 44KkCM47VQz1Bp8; Thu, 14 Mar 2019 10:37:51 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Thu, 14 Mar 2019 10:37:50 +0100 Cc: "netconf@ietf.org" X-Mao-Original-Outgoing-Id: 574249069.085375-ed076113238fa96eba629a19145ce51f Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Wisotzky, Sven (Nokia - DE/Stuttgart)" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netconf] Current activities on RESTCONF/NETCONF to support paging 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, 14 Mar 2019 09:38:13 -0000 On Mar 14, 2019, at 10:23, Wisotzky, Sven (Nokia - DE/Stuttgart) = wrote: >=20 > paging for extra-long lists We happen to have page/count in the CoRE resource directory for this = purpose. = https://tools.ietf.org/html/draft-ietf-core-resource-directory-20#section-= 6.2 This is not YANG-based but maybe an example for how this can be done. And, no, we haven=E2=80=99t solved the concurrency problem either. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Mar 14 02:41:37 2019 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 2A457128B36 for ; Thu, 14 Mar 2019 02:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=swm.pp.se 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 cY7DzKl4aTj7 for ; Thu, 14 Mar 2019 02:41:32 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 9DBCC1288AB for ; Thu, 14 Mar 2019 02:41:32 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 62C01B3; Thu, 14 Mar 2019 10:41:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1552556490; bh=Ce6WL7FDr9nnYJ7cNgZ0wj5SoGEpd8oI9BZoVoq6xKk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ksVgxuCmtUIBX+FbfHICSwjOOFckGPTojueZM8uHOcSZKlpOUeehiSixBv+rJcfv3 ar66ORFP0VgVW+fFQCnHgaVgCX7nqW2GTdpH1Uk9HCcXJffyx/HQKQnHHbwK1cjUgN yE5uP6sbsShp+KuoUVGxgxaxf3hsUR8EgjQ+ELy8= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6091EB2; Thu, 14 Mar 2019 10:41:30 +0100 (CET) Date: Thu, 14 Mar 2019 10:41:30 +0100 (CET) From: Mikael Abrahamsson To: Juergen Schoenwaelder cc: "Wisotzky, Sven (Nokia - DE/Stuttgart)" , "netconf@ietf.org" In-Reply-To: <20190314093552.3pwa7ptrre4t2stk@anna.jacobs.jacobs-university.de> Message-ID: References: <20190314093552.3pwa7ptrre4t2stk@anna.jacobs.jacobs-university.de> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [netconf] Current activities on RESTCONF/NETCONF to support paging 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, 14 Mar 2019 09:41:35 -0000 On Thu, 14 Mar 2019, Juergen Schoenwaelder wrote: > One of the issues to consider is that depending on the datastore > accessed, the data can change more or less rapidly and it is unclear > whether you want servers to maintain potentially big amounts of state > between requests. If you retrieve data in chunks, the question is > whether you can simply put the data back together or the client side > or whether this may lead to data that never really existed in that > form on the server. With RESTCONF, etags may help to check whether the > resource queried remains consistent (but then the server still has to > be able to decide etag changes). > > But backing up for this discussion of details, I agree that this is a > problem worth solving by standardizing a common solution. We have run into several use-cases where we'd like to be able to handle tens of millions of entries and still keep it declarative configuration and stay away from RPCs (which is what often is suggested). Examples of these use-cases are AFTR binding tables (think huge NAT/tunnel box), DHCP servers (with millions of leases potentially also configured static leases) and DNS servers (tens of millions of DNS zones). So yes, I fully support working on solving this problem-space. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Mar 14 03:07:43 2019 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 24A92129441 for ; Thu, 14 Mar 2019 03:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7L8vX1zsY_0 for ; Thu, 14 Mar 2019 03:07:36 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on072a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5A441288AB for ; Thu, 14 Mar 2019 03:07:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aGsHviQmee4Bxk/mqp4LuNeW2d/RumiRl2XBGCC4sS4=; b=JMcK78rpN3RyjdXtjtCICo26k7BgKUu7mIaVRPuCJPAZim3ftYq/GJlRSnnH5HHmPuLs1gN0oOZCDJSoLYMR4yWBrXbn24vM7+pUdcC/ZlaiXWDSjdzMk6D0gJatrogKVxQ7zXdzfEwGajsuB9itlr828+swIssy/B/Zx9M57GM= Received: from DB7PR07MB5386.eurprd07.prod.outlook.com (20.178.46.26) by DB7PR07MB3977.eurprd07.prod.outlook.com (52.134.100.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.9; Thu, 14 Mar 2019 10:07:33 +0000 Received: from DB7PR07MB5386.eurprd07.prod.outlook.com ([fe80::181c:32c6:16f2:7433]) by DB7PR07MB5386.eurprd07.prod.outlook.com ([fe80::181c:32c6:16f2:7433%3]) with mapi id 15.20.1709.011; Thu, 14 Mar 2019 10:07:33 +0000 From: "Wisotzky, Sven (Nokia - DE/Stuttgart)" To: Juergen Schoenwaelder CC: "netconf@ietf.org" Thread-Topic: [netconf] Current activities on RESTCONF/NETCONF to support paging Thread-Index: AQHU2kekdlWyfgR30USJDGKLseBWaqYK3hEAgAAZnQA= Date: Thu, 14 Mar 2019 10:07:33 +0000 Message-ID: <9DE27BCF-61F3-4085-A1F8-0FEAD76F85A5@nokia.com> References: <20190314093552.3pwa7ptrre4t2stk@anna.jacobs.jacobs-university.de> In-Reply-To: <20190314093552.3pwa7ptrre4t2stk@anna.jacobs.jacobs-university.de> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.0.190309 x-originating-ip: [188.97.190.16] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c370b8c9-40c5-492f-9403-08d6a864e060 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:DB7PR07MB3977; x-ms-traffictypediagnostic: DB7PR07MB3977: x-ms-exchange-purlcount: 2 authentication-results: spf=none (sender IP is ) smtp.mailfrom=sven.wisotzky@nokia.com; x-microsoft-antispam-prvs: x-forefront-prvs: 09760A0505 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(376002)(366004)(396003)(39860400002)(189003)(199004)(6306002)(105586002)(6512007)(14444005)(81166006)(3846002)(99286004)(6486002)(6116002)(97736004)(14454004)(8676002)(58126008)(8936002)(106356001)(305945005)(86362001)(256004)(6506007)(6246003)(7736002)(53936002)(76176011)(229853002)(71190400001)(83716004)(71200400001)(36756003)(66574012)(102836004)(186003)(26005)(82746002)(316002)(66066001)(6436002)(68736007)(446003)(2616005)(2906002)(486006)(476003)(11346002)(478600001)(6916009)(5660300002)(81156014)(25786009)(4326008)(966005)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB3977; H:DB7PR07MB5386.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: y6vqSo/wFcfoCFCGIsBgfbRERawVoHzn8ujSFATvX623VN5fGAMmU+JkMBdEmT1jrBCsawzNgNrN5rkDMrUe31o7fJcliSIahcrMpxh0JApyEFDxc0Mep32Rv1TiHAYvU+wGCEpEPDtKGC+809TWzzPsBKJGnofEerqwdvB7YrIxUyIqMYeKEacJd9L/xgg0qgqDUD2MBnK2xfWgG2RRJppnfj8qAP6OGUKdyn1aV3WduAJRAeppz0CyU/DjbWDBp7NvISVE8KAeYe5dRc1Pp98YIk5z3BFDsrcST+60kpxAQ6zvQdsESrXuNO1t5Ud4rQXt2BvRTJuZ+BS3sGI/acCRXtLMOeFFodas+mqAAGTqJyCXjztlEZx8QSzRHp0iqUPuprR5qf0WZCLKwhsbM3UVhokw/uV5yiHMZj1fdyA= Content-Type: text/plain; charset="utf-8" Content-ID: <6FA052BAF9EF0A47967DAC562FF52553@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: c370b8c9-40c5-492f-9403-08d6a864e060 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2019 10:07:33.2654 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB3977 Archived-At: Subject: Re: [netconf] Current activities on RESTCONF/NETCONF to support paging 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, 14 Mar 2019 10:07:40 -0000 SGkgSsO8cmdlbiwNCg0KSSBhbSBub3Qgc3VyZSBpZiB0aGlzIGlzIHNvIG11Y2ggZGlmZmVyZW50 IGZyb20gcmV0cmlldmluZyBodWdlIGxpc3RzIHVzaW5nIGdldCBvciBnZXQtY29uZmlnIHRvZGF5 LiBDYXB0dXJpbmcgaW5mb3JtYXRpb24sIFhNTCByZW5kZXJpbmcgYW5kIHRyYW5zbWlzc2lvbiB3 aWxsIHRha2UgdGltZSAtIHNvIG5vYm9keSB3b3VsZCBiZSBzdXJwcmlzZWQsIHRoYXQgcmVjZWl2 aW5nIGEgbGlzdCB3aXRoICsxMDBrIGVudHJpZXMgZWFzaWx5IHRha2VzIHNldmVyYWwgbWludXRl cy4gSW4gc3VjaCBzaXR1YXRpb24sIGl0IHJlYWxseSBkZXBlbmRzIG9uIHRoZSBzZXJ2ZXIgaW1w bGVtZW50YXRpb24gLSBpZiBjb25jdXJyZW50IGNoYW5nZXMgaW1wYWN0IHRoZSByZXN1bHQgb2Yg Z2V0L2dldC1jb25maWcgb3BlcmF0aW9uIG9uLXRoZS1mbHksIG1ha2luZyB0aGUgcmVzdWx0IGlu Y29uc2lzdGVudC4NCg0KQ2xlYXJseSBhIE5FVENPTkYvUkVTVENPTkYgc2VydmVyIGNvdWxkIGF2 b2lkIHN1Y2ggcHJvYmxlbXMgYnkgdGFraW5nIGEgc2hvcnQtdGVybSBsb2cgd2hpbGUgY2FwdHVy aW5nIGFuZCBjYWNoaW5nIGFsbCB0aGUgaW5mb3JtYXRpb24sIHdoaWxlIHRoZSBYTUwgcmVuZGVy aW5nIGFuZCB0cmFuc21pc3Npb24gd291bGQgdXNlIHRoYXQgc25hcHNob3Qgd2hpY2ggd291bGQg YmUgZnVsbHkgY29uc2lzdGVudC4gQnV0IHRvIGltcGxlbWVudCBhIE5DL1JDIHNlcnZlciB0aGF0 IHdheSwgY29tZXMgYXQgc29tZSBleHBlbnNlIG9mIG1lbW9yeSBmb290cHJpbnQgd2hpY2ggaXMg dHlwaWNhbGx5IHF1aXRlIGxpbWl0ZWQgb24gbmV0d29yayBlcXVpcG1lbnQgYW5kIGlzIGxpa2Vs eSBvbmUgb2YgdGhlIHJlYXNvbnMgd2h5IE5FVENPTkYgWFBBVEggc3VwcG9ydCBpcyByYXJlbHkg c3VwcG9ydGVkIGluIHRoZSBpbmR1c3RyeS4NCg0KVGhhdCBiZWluZyBzYWlkLCB0aGUgb25seSB3 YXkgZm9yIGEgbXVsdGktdmVuZG9yIE5FVENPTkYgY2xpZW50IHRvIGVuc3VyZSBkYXRhIGNvbnNp c3RlbmN5IGlzIHRvIGxvY2sgdGhlIHJ1bm5pbmcgZGF0YXN0b3JlIHdoaWxlIGV4ZWN1dGluZyBh IGdldC1jb25maWcgb3BlcmF0aW9uLg0KDQpCYXNlZCBvbiB0aGlzLCB0aGUgc2FtZSBjb3VsZCBl YXNpbHkgYmUgYXBwbGllZCB0byBwYWdpbmcuIFNvIGlmIHBhZ2luZyBpcyBzaW1wbHkgdXNlZCB0 byBtYWtlIHRoZSB1c2VyLWludGVyZmFjZSBzaG93aW5nIHRhYmxlcyBmYXN0ZXIgd2hpbGUgbG9h ZGluZyB0aGUgcmVtYWluaW5nIHRhYmxlIGluIHRoZSBiYWNrZ3JvdW5kLCB0aGUgbmV0Y29uZiBz ZXJ2ZXIgY291bGQgbG9jayB0aGUgZGF0YXN0b3JlIGZvciB0aGUgZW50aXJlIG9wZXJhdGlvbiB0 byBlbmZvcmNlIGEgYmV0dGVyIGxldmVsIG9mIGNvbnNpc3RlbmN5Lg0KDQpIb3dldmVyLCBhcyBw ZXIgbXkgaW5pdGlhbCBwb3N0IGJlbG93LCBqdXN0IGRlZmluaW5nIGEgbGltaXQgKGFrYSBtYXgt Y291bnQpIGlzIGEgdmVyeSBlZmZpY2llbnQgaW5pdGlhbCBzdGVwIHRvIGltcHJvdmUgbG9hZGlu ZyB0aW1lIGFuZCBhdm9pZCBjcmFzaGVzLiBBbmQgdGhlIHVzZXItaW50ZXJmYWNlIGNvdWxkIGJl IGltcGxlbWVudGVkIGluIGEgd2F5IHRvIGZpcnN0IGp1c3QgYXNrIGZvciAxMDAgZW50cmllcyB0 byBoYXZlIHNvbWV0aGluZyB0byBzaG93LCB3aGlsZSBhZnRlciB0aGlzIGFza2luZyB0aGUgZW50 aXJlIGxpc3QgaW4gdGhlIGJhY2tncm91bmQuIEp1c3Qgbm90IGEgYmlnIGZhbiBvZiB0aGlzLCBi ZWNhdXNlIGlmIHdvdWxkIGNhdXNlIHNvbWUgb3ZlcmhlYWQuDQoNCkFib3V0IHRoZSBudW1iZXIg b2YgbGlzdCBlbnRyaWVzLCBjbGVhcmx5IG9uZSBjb3VsZCBwdXQgdGhpcyBudW1iZXIgZm9yIGFu eSBsaXN0IGludG8gdGhlIHN0YXRlIG1vZGVsLiBCdXQgYWdhaW4sIEkgYmVsaWV2ZSBpdCBpcyBt dWNoIGJldHRlciB0byBoYXZlIGEgZ2VuZXJpYyBhcHByb2FjaCBmb3IgdGhpcy4NCg0KL3dpc28N Cg0K77u/T24gMTQuMDMuMTksIDEwOjM1LCAiSnVlcmdlbiBTY2hvZW53YWVsZGVyIiA8ai5zY2hv ZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCg0KICAgIE9uZSBvZiB0aGUg aXNzdWVzIHRvIGNvbnNpZGVyIGlzIHRoYXQgZGVwZW5kaW5nIG9uIHRoZSBkYXRhc3RvcmUNCiAg ICBhY2Nlc3NlZCwgdGhlIGRhdGEgY2FuIGNoYW5nZSBtb3JlIG9yIGxlc3MgcmFwaWRseSBhbmQg aXQgaXMgdW5jbGVhcg0KICAgIHdoZXRoZXIgeW91IHdhbnQgc2VydmVycyB0byBtYWludGFpbiBw b3RlbnRpYWxseSBiaWcgYW1vdW50cyBvZiBzdGF0ZQ0KICAgIGJldHdlZW4gcmVxdWVzdHMuIElm IHlvdSByZXRyaWV2ZSBkYXRhIGluIGNodW5rcywgdGhlIHF1ZXN0aW9uIGlzDQogICAgd2hldGhl ciB5b3UgY2FuIHNpbXBseSBwdXQgdGhlIGRhdGEgYmFjayB0b2dldGhlciBvciB0aGUgY2xpZW50 IHNpZGUNCiAgICBvciB3aGV0aGVyIHRoaXMgbWF5IGxlYWQgdG8gZGF0YSB0aGF0IG5ldmVyIHJl YWxseSBleGlzdGVkIGluIHRoYXQNCiAgICBmb3JtIG9uIHRoZSBzZXJ2ZXIuIFdpdGggUkVTVENP TkYsIGV0YWdzIG1heSBoZWxwIHRvIGNoZWNrIHdoZXRoZXIgdGhlDQogICAgcmVzb3VyY2UgcXVl cmllZCByZW1haW5zIGNvbnNpc3RlbnQgKGJ1dCB0aGVuIHRoZSBzZXJ2ZXIgc3RpbGwgaGFzIHRv DQogICAgYmUgYWJsZSB0byBkZWNpZGUgZXRhZyBjaGFuZ2VzKS4NCiAgICANCiAgICBCdXQgYmFj a2luZyB1cCBmb3IgdGhpcyBkaXNjdXNzaW9uIG9mIGRldGFpbHMsIEkgYWdyZWUgdGhhdCB0aGlz IGlzIGENCiAgICBwcm9ibGVtIHdvcnRoIHNvbHZpbmcgYnkgc3RhbmRhcmRpemluZyBhIGNvbW1v biBzb2x1dGlvbi4NCiAgICANCiAgICAvanMNCiAgICANCiAgICBPbiBUaHUsIE1hciAxNCwgMjAx OSBhdCAwOToyMzo1M0FNICswMDAwLCBXaXNvdHpreSwgU3ZlbiAoTm9raWEgLSBERS9TdHV0dGdh cnQpIHdyb3RlOg0KICAgID4gQWxsLA0KICAgID4gDQogICAgPiBUaGVyZSB3YXMgc29tZSBkaXNj dXNzaW9uIGluIGVhcmxpZXIgZGF5cyAoYmFjayBpbiAyMDEyLzIwMTQpIHRvIHN1cHBvcnQgcGFn aW5nIGZvciBleHRyYS1sb25nIGxpc3RzLiBUaGUgbWFpbiB1c2UtY2FzZSBpcyBjbGVhcmx5IHRv IGltcHJvdmUgc3VwcG9ydCBmb3IgaW50ZXJhY3RpdmUgdXNlci1mcm9udGVuZHMsIGFzIGxvYWRp bmcgZW50aXJlIGxpc3RzIHdpdGggcG90ZW50aWFsbHkgbW9yZSB0aGFuIDEwMC4wMDDigJlzIG9i amVjdHMgZWFzaWx5IGNhbiBiZWNvbWUgYSBuaWdodG1hcmU6IGxvYWRpbmcgdGltZSwgbWVtb3J5 IGNvbnN1bXB0aW9uLCBjcmFzaGVzLCDigKYNCiAgICA+IA0KICAgID4gRm9yIHRoZSBzYWtlIG9m IGltcGxlbWVudGF0aW9uLCBvbmUgd291bGQgc2ltcGx5IHByb3ZpZGUgYW4gYXR0cmlidXRlIGNh bGxlZCDigJxtYXgtY291bnTigJ0sIOKAnG1heC1lbnRyaWVz4oCdLCDigJxtYXgtZWxlbWVudHPi gJ0gb3Ig4oCcbGltaXTigJ0g4oCTIHdoaWNoIGJhc2ljYWxseSBkZWZpbmVzIHRoZSB1cHBlciBs aW1pdCBvZiBsaXN0IGVudHJpZXMgdG8gYmUgcmV0dXJuZWQuIEFza2luZyBmb3IgbGltaXQ9MTAg 4oCTIGV2ZW4gaWYgdGhlIGxpc3QgY29udGFpbnMgYSAxMDBrIHRoZSByZXN1bHQgd291bGQgc2lt cGx5IHNob3cgMTAuIEZyb20gYW4gdXNlci1pbnRlcmZhY2UgcG9pbnQgb2YgdmlldywgdGhpcyBt aWdodCBiZSBlbm91Z2gg4oCTIGFzIHVzZXJzIHdvdWxkIHNlZSBob3cgdGhlIGxpc3QgZW50cmll cyBsb29rIGxpa2UgdG8gbmFycm93IGRvd24gdGhlIHNlYXJjaCBieSBhZGRpbmcgYWRkaXRpb25h bCBzZWFyY2gvZmlsdGVyIGNyaXRlcmlhLiBTbyB0byBwcm90ZWN0IHRoZSBjbGllbnQgc3lzdGVt IGFuZCBpbXByb3ZlbWVudHMgb24gbG9hZGluZyB0aW1lL21lbW9yeSBjb25zdW1wdGlvbnMg4oCT IHRoaXMgbWlnaHQgYmUganVzdCBlbm91Z2guDQogICAgPiANCiAgICA+IE1vcmUgYWR2YW5jZWQg aW1wbGVtZW50YXRpb25zIG1pZ2h0IGFsbG93IHRoZSBORVRDT05GIGNsaWVudCB0byBzcGVjaWZ5 IHRoZSDigJxvZmZzZXTigJ0gd2hpY2ggaXMgYmFzaWNhbGx5IHRoZSBpbmRleCBvZiB0aGUgZmly c3QgbGlzdCBlbnRyeSB0byBiZSByZXR1cm5lZC4gSW4gc3VjaCBjYXNlLCB0aGUgY2xpZW50IGNv dWxkIGNvbnRpbnVlIHRvIGxvYWQgZnVydGhlciBwYWdlcyBvbiBjdXN0b21lciBkZW1hbmQgKGxp a2UgZHluYW1pY2FsbHkgd2hpbGUgc2Nyb2xsaW5nIGRvd24gdGhlIGxpc3Qgb3IgcHJlc3Npbmcg b24gdGhlIG5leHQgYnV0dG9uKS4gRXZlbiBpZiBwZW9wbGUgYXJlIG5vdCBjdXJpb3VzIHRoYXQg bXVjaCBhYm91dCBtZW1vcnkgY29uc3VtcHRpb24sIGV2ZW4gaXQgc2hvdWxkIGJlIHBvc3NpYmxl IHRvIGNvbnRpbnVlIGxvYWRpbmcgdGhlIHJlbWFpbmluZyBsaXN0IGluIHRoZSBiYWNrZ3JvdW5k IOKAkyB3aGlsZSBzaG93aW5nIHRoZSBmaXJzdCBYIGl0ZW1zIGZhc3RlciBvbiB0aGUgdXNlci1p bnRlcmZhY2VzLg0KICAgID4gDQogICAgPiBUbyBtYWtlIHN1Y2ggcGFnaW5nIHNvbHV0aW9uIGV2 ZW4gbW9yZSBjb21wbGV0ZSwgZm9sbG93aW5nIHVzZS1jYXNlcyBhcmUgdG8gYmUgcmV2aWV3ZWQg ZnJvbSBhIFJFU1RDT05GL05FVENPTkYgQVBJIHBvaW50IG9mIHZpZXc6DQogICAgPiAvMS8gSG93 IHRvIGZpZ3VyZSBvdXQgdGhlIG51bWJlciBvZiBsaXN0IGVudHJpZXMgbWF0Y2hpbmcgdGhlIGdp dmVuIGNyaXRlcmlhIGZvciBhIGdpdmVuIGxpc3QsIHdpdGhvdXQgdGhlIG5lZWQgdG8gcG9sbCB0 aGUgZW50aXJlIGxpc3Q/IFRoaXMgY291bGQgYmUgaGVscGZ1bCB0byBvcGVyYXRvcnMgc3RyYWln aHQgYXdheSwgYnV0IGFsc28gYWxsb3dzIGVhc2llciBpbXBsZW1lbnRhdGlvbiBmb3IgdGhpbmdz IGxpa2UgcHJvZ3Jlc3MgYmFycy4NCiAgICA+IC8yLyBEZWZpbmUgYSBzb3J0aW5nIGNyaXRlcmlh IGZvciBzZWFyY2ggcmVzdWx0cw0KICAgID4gLzMvIEltcHJvdmUgZmlsdGVyaW5nIGNhcGFiaWxp dGllcyBmb3Igc3VidHJlZSBmaWx0ZXJzIChlLmcuIGNvbnRhaW5zIG9wZXJhdG9yKQ0KICAgID4g DQogICAgPiBJIGRpZCBub3QgZm91bmQgYW55IGFjdGl2ZSBEUkFGVCBvciBSRkMgZm9yIHRoaXMu IFRoYXQgc2FpZCwgd2UgY2FuIHNlZSB2YXJpb3VzIHZlbmRvcnMgaW1wbGVtZW50aW5nIHByb3By aWV0YXJ5IHNvbHV0aW9ucyBmb3IgdGhpcyBpbiB0aGVpciBSRVNUQ09ORiBzdGFja3MuDQogICAg PiBXb3VsZCByZWFsbHkgbGlrZSB0byBzZWUgYW4gSUVURiBkZWZpbmVkIGFwcHJvYWNoIGZvciB0 aGlzLCB0byBhdm9pZCBtdWx0aS12ZW5kb3IgY2xpZW50cyBuZWVkIHRvIGRlYWwgdmFyaW91cyB2 ZW5kb3JzIGltcGxlbWVudGF0aW9ucy4NCiAgICA+IA0KICAgID4gL3dpc28NCiAgICANCiAgICA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiBu ZXRjb25mIG1haWxpbmcgbGlzdA0KICAgID4gbmV0Y29uZkBpZXRmLm9yZw0KICAgID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQogICAgDQogICAgDQogICAg LS0gDQogICAgSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0 eSBCcmVtZW4gZ0dtYkgNCiAgICBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1 cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQogICAgRmF4OiAgICs0OSA0MjEgMjAw IDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KICAgIA0K DQo= From nobody Thu Mar 14 03:24:15 2019 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 439FA1295D8 for ; Thu, 14 Mar 2019 03:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 E-jGMC1EWp-x for ; Thu, 14 Mar 2019 03:24:11 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6242C128CB7 for ; Thu, 14 Mar 2019 03:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6232; q=dns/txt; s=iport; t=1552559051; x=1553768651; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tB2OGEj23f0dOaGHsEKUSJPKquTbOxo5HoQKhMG9ORY=; b=U6gr95l2V/oO5/keFtjT3yoFJfmqoxMhiA1dfZrsmtx/o4fGCPWBmdx/ Dv16/Sz8vhJTND5C4+YLU5p9qcXeacc7v74QnztDHelQNeaMHPOy34XzG 3WNzmcD5zPyomA51fUGBYBWsR0X/TM3IZEvD9r3Es7tukpxIhmLMfL6zW E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABZKopc/5BdJa1hAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYFgL2iBAycKhAGIHI0smDCBewsBARg?= =?us-ascii?q?LhANGAheENyI0CQ0BAQMBAQkBAwJtHAyFSgEBAQQBASEROgsFBwICAgEGAg4?= =?us-ascii?q?CAQQBAQECAiYCAgIZDAsVCAgCBA4FCBODCIF1D5Irm2aBL4oyBQWBBiQBiyw?= =?us-ascii?q?XgUA/hCODHgEBgTsQLQomgkOCVwOJfRJDggCXbgkCkxUhk0udZgIRFYEoHzi?= =?us-ascii?q?BVnAVO4JsghYXg36EYYU/QTGNW4EtgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.58,478,1544486400"; d="scan'208";a="244807997" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Mar 2019 10:24:10 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x2EAOAkh008823 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Mar 2019 10:24:10 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 14 Mar 2019 05:24:09 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Thu, 14 Mar 2019 05:24:09 -0500 From: "Rob Wilton (rwilton)" To: Juergen Schoenwaelder , "Wisotzky, Sven (Nokia - DE/Stuttgart)" CC: "netconf@ietf.org" Thread-Topic: [netconf] Current activities on RESTCONF/NETCONF to support paging Thread-Index: AQHU2kekdlWyfgR30USJDGKLseBWaqYLMeMA//+yIDA= Date: Thu, 14 Mar 2019 10:24:09 +0000 Message-ID: References: <20190314093552.3pwa7ptrre4t2stk@anna.jacobs.jacobs-university.de> In-Reply-To: <20190314093552.3pwa7ptrre4t2stk@anna.jacobs.jacobs-university.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.63.23.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [netconf] Current activities on RESTCONF/NETCONF to support paging 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, 14 Mar 2019 10:24:15 -0000 SSBhZ3JlZSB0aGF0IHRoaXMgd291bGQgYmUgYSB1c2VmdWwgcHJvYmxlbSB0byBzb2x2ZS4NCg0K SSBhbHNvIGFncmVlIHdpdGggSnVlcmdlbiB0aGF0IHRoZXJlIHdpbGwgbGlrZWx5IGJlIGNvbnNp c3RlbmN5IGlzc3VlcyBkZXBlbmRpbmcgb24gaW1wbGVtZW50YXRpb24sIHBhcnRpY3VsYXJseSBp ZiB0aGUgZGF0YSBpcyBjb21pbmcgZnJvbSA8b3BlcmF0aW9uYWw+LiAgQnV0IEkgc3VzcGVjdCB0 aGF0IHRoaXMgaXNzdWUgYWxyZWFkeSBleGlzdHMgZm9yIG1hbnkgbm9uLXRyaXZpYWwgaW1wbGVt ZW50YXRpb25zIChlLmcuIHdoZXJlIHRoZSBvcGVyYXRpb25hbCBkYXRhIGlzIGRpc3RyaWJ1dGVk IHRvIGRhZW1vbnMsIGxpbmVjYXJkcywgb3IgcmVtb3RlIHNsYXZlIGRldmljZXMpLg0KDQpSZXF1 aXJpbmcgdGhhdCBhIGNvbnNpc3RlbnQgdmlldyBvZiB0aGUgY29udmVudGlvbmFsIGNvbmZpZ3Vy YXRpb24gZGF0YXN0b3JlcyBjYW4gYmUgcHJvdmlkZWQgKHdpdGhvdXQgbG9ja2luZykgbWlnaHQg YmUgYSByZWFzb25hYmxlIGNvbXByb21pc2UuDQoNClRoYW5rcywNClJvYg0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBuZXRjb25mIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5v cmc+IE9uIEJlaGFsZiBPZiBKdWVyZ2VuIFNjaG9lbndhZWxkZXINClNlbnQ6IDE0IE1hcmNoIDIw MTkgMDk6MzYNClRvOiBXaXNvdHpreSwgU3ZlbiAoTm9raWEgLSBERS9TdHV0dGdhcnQpIDxzdmVu Lndpc290emt5QG5va2lhLmNvbT4NCkNjOiBuZXRjb25mQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W25ldGNvbmZdIEN1cnJlbnQgYWN0aXZpdGllcyBvbiBSRVNUQ09ORi9ORVRDT05GIHRvIHN1cHBv cnQgcGFnaW5nDQoNCk9uZSBvZiB0aGUgaXNzdWVzIHRvIGNvbnNpZGVyIGlzIHRoYXQgZGVwZW5k aW5nIG9uIHRoZSBkYXRhc3RvcmUgYWNjZXNzZWQsIHRoZSBkYXRhIGNhbiBjaGFuZ2UgbW9yZSBv ciBsZXNzIHJhcGlkbHkgYW5kIGl0IGlzIHVuY2xlYXIgd2hldGhlciB5b3Ugd2FudCBzZXJ2ZXJz IHRvIG1haW50YWluIHBvdGVudGlhbGx5IGJpZyBhbW91bnRzIG9mIHN0YXRlIGJldHdlZW4gcmVx dWVzdHMuIElmIHlvdSByZXRyaWV2ZSBkYXRhIGluIGNodW5rcywgdGhlIHF1ZXN0aW9uIGlzIHdo ZXRoZXIgeW91IGNhbiBzaW1wbHkgcHV0IHRoZSBkYXRhIGJhY2sgdG9nZXRoZXIgb3IgdGhlIGNs aWVudCBzaWRlIG9yIHdoZXRoZXIgdGhpcyBtYXkgbGVhZCB0byBkYXRhIHRoYXQgbmV2ZXIgcmVh bGx5IGV4aXN0ZWQgaW4gdGhhdCBmb3JtIG9uIHRoZSBzZXJ2ZXIuIFdpdGggUkVTVENPTkYsIGV0 YWdzIG1heSBoZWxwIHRvIGNoZWNrIHdoZXRoZXIgdGhlIHJlc291cmNlIHF1ZXJpZWQgcmVtYWlu cyBjb25zaXN0ZW50IChidXQgdGhlbiB0aGUgc2VydmVyIHN0aWxsIGhhcyB0byBiZSBhYmxlIHRv IGRlY2lkZSBldGFnIGNoYW5nZXMpLg0KDQpCdXQgYmFja2luZyB1cCBmb3IgdGhpcyBkaXNjdXNz aW9uIG9mIGRldGFpbHMsIEkgYWdyZWUgdGhhdCB0aGlzIGlzIGEgcHJvYmxlbSB3b3J0aCBzb2x2 aW5nIGJ5IHN0YW5kYXJkaXppbmcgYSBjb21tb24gc29sdXRpb24uDQoNCi9qcw0KDQpPbiBUaHUs IE1hciAxNCwgMjAxOSBhdCAwOToyMzo1M0FNICswMDAwLCBXaXNvdHpreSwgU3ZlbiAoTm9raWEg LSBERS9TdHV0dGdhcnQpIHdyb3RlOg0KPiBBbGwsDQo+IA0KPiBUaGVyZSB3YXMgc29tZSBkaXNj dXNzaW9uIGluIGVhcmxpZXIgZGF5cyAoYmFjayBpbiAyMDEyLzIwMTQpIHRvIA0KPiBzdXBwb3J0 IHBhZ2luZyBmb3IgZXh0cmEtbG9uZyBsaXN0cy4gVGhlIG1haW4gdXNlLWNhc2UgaXMgY2xlYXJs eSB0byANCj4gaW1wcm92ZSBzdXBwb3J0IGZvciBpbnRlcmFjdGl2ZSB1c2VyLWZyb250ZW5kcywg YXMgbG9hZGluZyBlbnRpcmUgDQo+IGxpc3RzIHdpdGggcG90ZW50aWFsbHkgbW9yZSB0aGFuIDEw MC4wMDDigJlzIG9iamVjdHMgZWFzaWx5IGNhbiBiZWNvbWUgYSANCj4gbmlnaHRtYXJlOiBsb2Fk aW5nIHRpbWUsIG1lbW9yeSBjb25zdW1wdGlvbiwgY3Jhc2hlcywg4oCmDQo+IA0KPiBGb3IgdGhl IHNha2Ugb2YgaW1wbGVtZW50YXRpb24sIG9uZSB3b3VsZCBzaW1wbHkgcHJvdmlkZSBhbiBhdHRy aWJ1dGUgY2FsbGVkIOKAnG1heC1jb3VudOKAnSwg4oCcbWF4LWVudHJpZXPigJ0sIOKAnG1heC1l bGVtZW50c+KAnSBvciDigJxsaW1pdOKAnSDigJMgd2hpY2ggYmFzaWNhbGx5IGRlZmluZXMgdGhl IHVwcGVyIGxpbWl0IG9mIGxpc3QgZW50cmllcyB0byBiZSByZXR1cm5lZC4gQXNraW5nIGZvciBs aW1pdD0xMCDigJMgZXZlbiBpZiB0aGUgbGlzdCBjb250YWlucyBhIDEwMGsgdGhlIHJlc3VsdCB3 b3VsZCBzaW1wbHkgc2hvdyAxMC4gRnJvbSBhbiB1c2VyLWludGVyZmFjZSBwb2ludCBvZiB2aWV3 LCB0aGlzIG1pZ2h0IGJlIGVub3VnaCDigJMgYXMgdXNlcnMgd291bGQgc2VlIGhvdyB0aGUgbGlz dCBlbnRyaWVzIGxvb2sgbGlrZSB0byBuYXJyb3cgZG93biB0aGUgc2VhcmNoIGJ5IGFkZGluZyBh ZGRpdGlvbmFsIHNlYXJjaC9maWx0ZXIgY3JpdGVyaWEuIFNvIHRvIHByb3RlY3QgdGhlIGNsaWVu dCBzeXN0ZW0gYW5kIGltcHJvdmVtZW50cyBvbiBsb2FkaW5nIHRpbWUvbWVtb3J5IGNvbnN1bXB0 aW9ucyDigJMgdGhpcyBtaWdodCBiZSBqdXN0IGVub3VnaC4NCj4gDQo+IE1vcmUgYWR2YW5jZWQg aW1wbGVtZW50YXRpb25zIG1pZ2h0IGFsbG93IHRoZSBORVRDT05GIGNsaWVudCB0byBzcGVjaWZ5 IHRoZSDigJxvZmZzZXTigJ0gd2hpY2ggaXMgYmFzaWNhbGx5IHRoZSBpbmRleCBvZiB0aGUgZmly c3QgbGlzdCBlbnRyeSB0byBiZSByZXR1cm5lZC4gSW4gc3VjaCBjYXNlLCB0aGUgY2xpZW50IGNv dWxkIGNvbnRpbnVlIHRvIGxvYWQgZnVydGhlciBwYWdlcyBvbiBjdXN0b21lciBkZW1hbmQgKGxp a2UgZHluYW1pY2FsbHkgd2hpbGUgc2Nyb2xsaW5nIGRvd24gdGhlIGxpc3Qgb3IgcHJlc3Npbmcg b24gdGhlIG5leHQgYnV0dG9uKS4gRXZlbiBpZiBwZW9wbGUgYXJlIG5vdCBjdXJpb3VzIHRoYXQg bXVjaCBhYm91dCBtZW1vcnkgY29uc3VtcHRpb24sIGV2ZW4gaXQgc2hvdWxkIGJlIHBvc3NpYmxl IHRvIGNvbnRpbnVlIGxvYWRpbmcgdGhlIHJlbWFpbmluZyBsaXN0IGluIHRoZSBiYWNrZ3JvdW5k IOKAkyB3aGlsZSBzaG93aW5nIHRoZSBmaXJzdCBYIGl0ZW1zIGZhc3RlciBvbiB0aGUgdXNlci1p bnRlcmZhY2VzLg0KPiANCj4gVG8gbWFrZSBzdWNoIHBhZ2luZyBzb2x1dGlvbiBldmVuIG1vcmUg Y29tcGxldGUsIGZvbGxvd2luZyB1c2UtY2FzZXMgYXJlIHRvIGJlIHJldmlld2VkIGZyb20gYSBS RVNUQ09ORi9ORVRDT05GIEFQSSBwb2ludCBvZiB2aWV3Og0KPiAvMS8gSG93IHRvIGZpZ3VyZSBv dXQgdGhlIG51bWJlciBvZiBsaXN0IGVudHJpZXMgbWF0Y2hpbmcgdGhlIGdpdmVuIGNyaXRlcmlh IGZvciBhIGdpdmVuIGxpc3QsIHdpdGhvdXQgdGhlIG5lZWQgdG8gcG9sbCB0aGUgZW50aXJlIGxp c3Q/IFRoaXMgY291bGQgYmUgaGVscGZ1bCB0byBvcGVyYXRvcnMgc3RyYWlnaHQgYXdheSwgYnV0 IGFsc28gYWxsb3dzIGVhc2llciBpbXBsZW1lbnRhdGlvbiBmb3IgdGhpbmdzIGxpa2UgcHJvZ3Jl c3MgYmFycy4NCj4gLzIvIERlZmluZSBhIHNvcnRpbmcgY3JpdGVyaWEgZm9yIHNlYXJjaCByZXN1 bHRzIC8zLyBJbXByb3ZlIGZpbHRlcmluZyANCj4gY2FwYWJpbGl0aWVzIGZvciBzdWJ0cmVlIGZp bHRlcnMgKGUuZy4gY29udGFpbnMgb3BlcmF0b3IpDQo+IA0KPiBJIGRpZCBub3QgZm91bmQgYW55 IGFjdGl2ZSBEUkFGVCBvciBSRkMgZm9yIHRoaXMuIFRoYXQgc2FpZCwgd2UgY2FuIHNlZSB2YXJp b3VzIHZlbmRvcnMgaW1wbGVtZW50aW5nIHByb3ByaWV0YXJ5IHNvbHV0aW9ucyBmb3IgdGhpcyBp biB0aGVpciBSRVNUQ09ORiBzdGFja3MuDQo+IFdvdWxkIHJlYWxseSBsaWtlIHRvIHNlZSBhbiBJ RVRGIGRlZmluZWQgYXBwcm9hY2ggZm9yIHRoaXMsIHRvIGF2b2lkIG11bHRpLXZlbmRvciBjbGll bnRzIG5lZWQgdG8gZGVhbCB2YXJpb3VzIHZlbmRvcnMgaW1wbGVtZW50YXRpb25zLg0KPiANCj4g L3dpc28NCg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBuZXRjb25mIG1haWxpbmcgbGlzdA0KPiBuZXRjb25mQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KDQoNCi0tIA0KSnVlcmdlbiBT Y2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNClBo b25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1l biB8IEdlcm1hbnkNCkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3 LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCm5ldGNvbmYgbWFpbGluZyBsaXN0DQpuZXRjb25mQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg== From nobody Thu Mar 14 03:41:59 2019 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 CAE5A128B36 for ; Thu, 14 Mar 2019 03:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I86JMZ13ztFM for ; Thu, 14 Mar 2019 03:41:54 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80101.outbound.protection.outlook.com [40.107.8.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A2A0127918 for ; Thu, 14 Mar 2019 03:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0j8WrnpE0Z9I5FYOa56GARcJjG6PsFv7cneHIcEcDHI=; b=qbjILwg69bkgChaihotCZuoyNgkXY+h1GOemkLOGADRHv67CfRgeTSfXgLBXivIxpEIJ1d7FeuS8mzb2I87qFop90q8GvicCK4N1Wj7G2OwL01bK1ThHAvixGd464vJrzZX6sh9TM+/bZXqMGwo/sK30hzuHXZ/6x4K5LmVhOi0= Received: from DB7PR07MB5386.eurprd07.prod.outlook.com (20.178.46.26) by DB7PR07MB4650.eurprd07.prod.outlook.com (52.135.134.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.6; Thu, 14 Mar 2019 10:41:51 +0000 Received: from DB7PR07MB5386.eurprd07.prod.outlook.com ([fe80::181c:32c6:16f2:7433]) by DB7PR07MB5386.eurprd07.prod.outlook.com ([fe80::181c:32c6:16f2:7433%3]) with mapi id 15.20.1709.011; Thu, 14 Mar 2019 10:41:51 +0000 From: "Wisotzky, Sven (Nokia - DE/Stuttgart)" To: "Rob Wilton (rwilton)" , Juergen Schoenwaelder CC: "netconf@ietf.org" Thread-Topic: [netconf] Current activities on RESTCONF/NETCONF to support paging Thread-Index: AQHU2kekdlWyfgR30USJDGKLseBWaqYK3hEAgAANfoCAABW0AA== Date: Thu, 14 Mar 2019 10:41:51 +0000 Message-ID: <721AEEB2-BE3B-465D-A6BB-DBBEEBACFD75@nokia.com> References: <20190314093552.3pwa7ptrre4t2stk@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.0.190309 x-originating-ip: [188.97.190.16] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fb369f2a-dc36-4488-b37f-08d6a869ab34 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:DB7PR07MB4650; x-ms-traffictypediagnostic: DB7PR07MB4650: x-ms-exchange-purlcount: 2 authentication-results: spf=none (sender IP is ) smtp.mailfrom=sven.wisotzky@nokia.com; x-microsoft-antispam-prvs: x-forefront-prvs: 09760A0505 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(346002)(39860400002)(396003)(366004)(13464003)(199004)(189003)(486006)(76176011)(3846002)(6512007)(6246003)(53936002)(256004)(14444005)(476003)(6116002)(66066001)(11346002)(2616005)(82746002)(446003)(6436002)(186003)(478600001)(36756003)(97736004)(86362001)(316002)(4326008)(6486002)(6306002)(7736002)(305945005)(26005)(58126008)(102836004)(106356001)(68736007)(33656002)(81166006)(25786009)(5660300002)(105586002)(8936002)(229853002)(2906002)(71200400001)(53546011)(6506007)(71190400001)(110136005)(81156014)(99286004)(83716004)(14454004)(966005)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB4650; H:DB7PR07MB5386.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: mY36aV1wTC6t+knzvqcP97Vj8ic1PY/wICy9OfVGFmt/1hXXnX3MBvEF2OJp0mQUMDL1uhsKv28fJYaa71yKi4dJPHedJB42VUoe5Y40fESYwv3fLvNq38mF2THj15tKQlz1IkriLLYYJeSwahlDJfX+LU11eVz7JoJqff7DvsWL4JzznjnsMKLRFnqeNHt1c8F2UMtcVj7XofDkX3geNs/HvdqkFIdsacVNHutumsfFHw/c2b36bpeM52SOS8zLlsNMy+6fBGfJ5Xm+/TmkTdmv5J3GFXPW4tMU2TF7JYogsM8igjp4jurwfTYcMWzfTnn3KPX/VQ3DaJfHEtX/KCrWCcVREiVAZYFSR2mIpYK7ODpFQDVytjgyozI0gHAHtE3Lb6lS0Ui3+XGmWR6f2gN6fM+61VxEWbV6dJ+clTc= Content-Type: text/plain; charset="utf-8" Content-ID: <1CA0C23A15F7D14695406453210E58DB@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: fb369f2a-dc36-4488-b37f-08d6a869ab34 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2019 10:41:51.5893 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4650 Archived-At: Subject: Re: [netconf] Current activities on RESTCONF/NETCONF to support paging 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, 14 Mar 2019 10:41:58 -0000 SGkgUm9iLA0KDQpJbiB0aGF0IGNhc2Ugd2Ugd291bGQgc29tZWhvdyByZXF1aXJlIHRvIGNhY2hl IHRoZSByZXN1bHQgYW5kIHRvIGhhdmUgc29tZSBzb3J0IG9mIHF1ZXJ5LWlkZW50aWZpZXIsIHRv IHJlZmVyZW5jZSBiYWNrIHRvIHRoZSByZXN1bHQgdmVjdG9yLiBTb3VuZHMgYSBiaXQgbGlrZSBv dmVya2lsbCB0byBtZS4gUmVhbGx5IHB1c2hlcyB0aGUgc2VydmVyLXNpZGUgcmVxdWlyZW1lbnRz IChlLmcuIG1lbW9yeSBmb290cHJpbnQpIC0gYnV0IGFsc28ga2VlcHMgdGhlIHF1ZXN0aW9uIG9w ZW4sIG9uIGhvdyBsb25nIHlvdSB3b3VsZCBsaWtlIHRoZSBrZWVwIHRoZSByZXN1bHQgaW4gdGhl IHF1ZXJ5IGNhY2hlLg0KDQovd2lzbw0KDQoNCg0K77u/T24gMTQuMDMuMTksIDExOjI0LCAiUm9i IFdpbHRvbiAocndpbHRvbikiIDxyd2lsdG9uQGNpc2NvLmNvbT4gd3JvdGU6DQoNCiAgICBJIGFn cmVlIHRoYXQgdGhpcyB3b3VsZCBiZSBhIHVzZWZ1bCBwcm9ibGVtIHRvIHNvbHZlLg0KICAgIA0K ICAgIEkgYWxzbyBhZ3JlZSB3aXRoIEp1ZXJnZW4gdGhhdCB0aGVyZSB3aWxsIGxpa2VseSBiZSBj b25zaXN0ZW5jeSBpc3N1ZXMgZGVwZW5kaW5nIG9uIGltcGxlbWVudGF0aW9uLCBwYXJ0aWN1bGFy bHkgaWYgdGhlIGRhdGEgaXMgY29taW5nIGZyb20gPG9wZXJhdGlvbmFsPi4gIEJ1dCBJIHN1c3Bl Y3QgdGhhdCB0aGlzIGlzc3VlIGFscmVhZHkgZXhpc3RzIGZvciBtYW55IG5vbi10cml2aWFsIGlt cGxlbWVudGF0aW9ucyAoZS5nLiB3aGVyZSB0aGUgb3BlcmF0aW9uYWwgZGF0YSBpcyBkaXN0cmli dXRlZCB0byBkYWVtb25zLCBsaW5lY2FyZHMsIG9yIHJlbW90ZSBzbGF2ZSBkZXZpY2VzKS4NCiAg ICANCiAgICBSZXF1aXJpbmcgdGhhdCBhIGNvbnNpc3RlbnQgdmlldyBvZiB0aGUgY29udmVudGlv bmFsIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlcyBjYW4gYmUgcHJvdmlkZWQgKHdpdGhvdXQgbG9j a2luZykgbWlnaHQgYmUgYSByZWFzb25hYmxlIGNvbXByb21pc2UuDQogICAgDQogICAgVGhhbmtz LA0KICAgIFJvYg0KICAgIA0KICAgIA0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQog ICAgRnJvbTogbmV0Y29uZiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2Yg SnVlcmdlbiBTY2hvZW53YWVsZGVyDQogICAgU2VudDogMTQgTWFyY2ggMjAxOSAwOTozNg0KICAg IFRvOiBXaXNvdHpreSwgU3ZlbiAoTm9raWEgLSBERS9TdHV0dGdhcnQpIDxzdmVuLndpc290emt5 QG5va2lhLmNvbT4NCiAgICBDYzogbmV0Y29uZkBpZXRmLm9yZw0KICAgIFN1YmplY3Q6IFJlOiBb bmV0Y29uZl0gQ3VycmVudCBhY3Rpdml0aWVzIG9uIFJFU1RDT05GL05FVENPTkYgdG8gc3VwcG9y dCBwYWdpbmcNCiAgICANCiAgICBPbmUgb2YgdGhlIGlzc3VlcyB0byBjb25zaWRlciBpcyB0aGF0 IGRlcGVuZGluZyBvbiB0aGUgZGF0YXN0b3JlIGFjY2Vzc2VkLCB0aGUgZGF0YSBjYW4gY2hhbmdl IG1vcmUgb3IgbGVzcyByYXBpZGx5IGFuZCBpdCBpcyB1bmNsZWFyIHdoZXRoZXIgeW91IHdhbnQg c2VydmVycyB0byBtYWludGFpbiBwb3RlbnRpYWxseSBiaWcgYW1vdW50cyBvZiBzdGF0ZSBiZXR3 ZWVuIHJlcXVlc3RzLiBJZiB5b3UgcmV0cmlldmUgZGF0YSBpbiBjaHVua3MsIHRoZSBxdWVzdGlv biBpcyB3aGV0aGVyIHlvdSBjYW4gc2ltcGx5IHB1dCB0aGUgZGF0YSBiYWNrIHRvZ2V0aGVyIG9y IHRoZSBjbGllbnQgc2lkZSBvciB3aGV0aGVyIHRoaXMgbWF5IGxlYWQgdG8gZGF0YSB0aGF0IG5l dmVyIHJlYWxseSBleGlzdGVkIGluIHRoYXQgZm9ybSBvbiB0aGUgc2VydmVyLiBXaXRoIFJFU1RD T05GLCBldGFncyBtYXkgaGVscCB0byBjaGVjayB3aGV0aGVyIHRoZSByZXNvdXJjZSBxdWVyaWVk IHJlbWFpbnMgY29uc2lzdGVudCAoYnV0IHRoZW4gdGhlIHNlcnZlciBzdGlsbCBoYXMgdG8gYmUg YWJsZSB0byBkZWNpZGUgZXRhZyBjaGFuZ2VzKS4NCiAgICANCiAgICBCdXQgYmFja2luZyB1cCBm b3IgdGhpcyBkaXNjdXNzaW9uIG9mIGRldGFpbHMsIEkgYWdyZWUgdGhhdCB0aGlzIGlzIGEgcHJv YmxlbSB3b3J0aCBzb2x2aW5nIGJ5IHN0YW5kYXJkaXppbmcgYSBjb21tb24gc29sdXRpb24uDQog ICAgDQogICAgL2pzDQogICAgDQogICAgT24gVGh1LCBNYXIgMTQsIDIwMTkgYXQgMDk6MjM6NTNB TSArMDAwMCwgV2lzb3R6a3ksIFN2ZW4gKE5va2lhIC0gREUvU3R1dHRnYXJ0KSB3cm90ZToNCiAg ICA+IEFsbCwNCiAgICA+IA0KICAgID4gVGhlcmUgd2FzIHNvbWUgZGlzY3Vzc2lvbiBpbiBlYXJs aWVyIGRheXMgKGJhY2sgaW4gMjAxMi8yMDE0KSB0byANCiAgICA+IHN1cHBvcnQgcGFnaW5nIGZv ciBleHRyYS1sb25nIGxpc3RzLiBUaGUgbWFpbiB1c2UtY2FzZSBpcyBjbGVhcmx5IHRvIA0KICAg ID4gaW1wcm92ZSBzdXBwb3J0IGZvciBpbnRlcmFjdGl2ZSB1c2VyLWZyb250ZW5kcywgYXMgbG9h ZGluZyBlbnRpcmUgDQogICAgPiBsaXN0cyB3aXRoIHBvdGVudGlhbGx5IG1vcmUgdGhhbiAxMDAu MDAw4oCZcyBvYmplY3RzIGVhc2lseSBjYW4gYmVjb21lIGEgDQogICAgPiBuaWdodG1hcmU6IGxv YWRpbmcgdGltZSwgbWVtb3J5IGNvbnN1bXB0aW9uLCBjcmFzaGVzLCDigKYNCiAgICA+IA0KICAg ID4gRm9yIHRoZSBzYWtlIG9mIGltcGxlbWVudGF0aW9uLCBvbmUgd291bGQgc2ltcGx5IHByb3Zp ZGUgYW4gYXR0cmlidXRlIGNhbGxlZCDigJxtYXgtY291bnTigJ0sIOKAnG1heC1lbnRyaWVz4oCd LCDigJxtYXgtZWxlbWVudHPigJ0gb3Ig4oCcbGltaXTigJ0g4oCTIHdoaWNoIGJhc2ljYWxseSBk ZWZpbmVzIHRoZSB1cHBlciBsaW1pdCBvZiBsaXN0IGVudHJpZXMgdG8gYmUgcmV0dXJuZWQuIEFz a2luZyBmb3IgbGltaXQ9MTAg4oCTIGV2ZW4gaWYgdGhlIGxpc3QgY29udGFpbnMgYSAxMDBrIHRo ZSByZXN1bHQgd291bGQgc2ltcGx5IHNob3cgMTAuIEZyb20gYW4gdXNlci1pbnRlcmZhY2UgcG9p bnQgb2YgdmlldywgdGhpcyBtaWdodCBiZSBlbm91Z2gg4oCTIGFzIHVzZXJzIHdvdWxkIHNlZSBo b3cgdGhlIGxpc3QgZW50cmllcyBsb29rIGxpa2UgdG8gbmFycm93IGRvd24gdGhlIHNlYXJjaCBi eSBhZGRpbmcgYWRkaXRpb25hbCBzZWFyY2gvZmlsdGVyIGNyaXRlcmlhLiBTbyB0byBwcm90ZWN0 IHRoZSBjbGllbnQgc3lzdGVtIGFuZCBpbXByb3ZlbWVudHMgb24gbG9hZGluZyB0aW1lL21lbW9y eSBjb25zdW1wdGlvbnMg4oCTIHRoaXMgbWlnaHQgYmUganVzdCBlbm91Z2guDQogICAgPiANCiAg ICA+IE1vcmUgYWR2YW5jZWQgaW1wbGVtZW50YXRpb25zIG1pZ2h0IGFsbG93IHRoZSBORVRDT05G IGNsaWVudCB0byBzcGVjaWZ5IHRoZSDigJxvZmZzZXTigJ0gd2hpY2ggaXMgYmFzaWNhbGx5IHRo ZSBpbmRleCBvZiB0aGUgZmlyc3QgbGlzdCBlbnRyeSB0byBiZSByZXR1cm5lZC4gSW4gc3VjaCBj YXNlLCB0aGUgY2xpZW50IGNvdWxkIGNvbnRpbnVlIHRvIGxvYWQgZnVydGhlciBwYWdlcyBvbiBj dXN0b21lciBkZW1hbmQgKGxpa2UgZHluYW1pY2FsbHkgd2hpbGUgc2Nyb2xsaW5nIGRvd24gdGhl IGxpc3Qgb3IgcHJlc3Npbmcgb24gdGhlIG5leHQgYnV0dG9uKS4gRXZlbiBpZiBwZW9wbGUgYXJl IG5vdCBjdXJpb3VzIHRoYXQgbXVjaCBhYm91dCBtZW1vcnkgY29uc3VtcHRpb24sIGV2ZW4gaXQg c2hvdWxkIGJlIHBvc3NpYmxlIHRvIGNvbnRpbnVlIGxvYWRpbmcgdGhlIHJlbWFpbmluZyBsaXN0 IGluIHRoZSBiYWNrZ3JvdW5kIOKAkyB3aGlsZSBzaG93aW5nIHRoZSBmaXJzdCBYIGl0ZW1zIGZh c3RlciBvbiB0aGUgdXNlci1pbnRlcmZhY2VzLg0KICAgID4gDQogICAgPiBUbyBtYWtlIHN1Y2gg cGFnaW5nIHNvbHV0aW9uIGV2ZW4gbW9yZSBjb21wbGV0ZSwgZm9sbG93aW5nIHVzZS1jYXNlcyBh cmUgdG8gYmUgcmV2aWV3ZWQgZnJvbSBhIFJFU1RDT05GL05FVENPTkYgQVBJIHBvaW50IG9mIHZp ZXc6DQogICAgPiAvMS8gSG93IHRvIGZpZ3VyZSBvdXQgdGhlIG51bWJlciBvZiBsaXN0IGVudHJp ZXMgbWF0Y2hpbmcgdGhlIGdpdmVuIGNyaXRlcmlhIGZvciBhIGdpdmVuIGxpc3QsIHdpdGhvdXQg dGhlIG5lZWQgdG8gcG9sbCB0aGUgZW50aXJlIGxpc3Q/IFRoaXMgY291bGQgYmUgaGVscGZ1bCB0 byBvcGVyYXRvcnMgc3RyYWlnaHQgYXdheSwgYnV0IGFsc28gYWxsb3dzIGVhc2llciBpbXBsZW1l bnRhdGlvbiBmb3IgdGhpbmdzIGxpa2UgcHJvZ3Jlc3MgYmFycy4NCiAgICA+IC8yLyBEZWZpbmUg YSBzb3J0aW5nIGNyaXRlcmlhIGZvciBzZWFyY2ggcmVzdWx0cyAvMy8gSW1wcm92ZSBmaWx0ZXJp bmcgDQogICAgPiBjYXBhYmlsaXRpZXMgZm9yIHN1YnRyZWUgZmlsdGVycyAoZS5nLiBjb250YWlu cyBvcGVyYXRvcikNCiAgICA+IA0KICAgID4gSSBkaWQgbm90IGZvdW5kIGFueSBhY3RpdmUgRFJB RlQgb3IgUkZDIGZvciB0aGlzLiBUaGF0IHNhaWQsIHdlIGNhbiBzZWUgdmFyaW91cyB2ZW5kb3Jz IGltcGxlbWVudGluZyBwcm9wcmlldGFyeSBzb2x1dGlvbnMgZm9yIHRoaXMgaW4gdGhlaXIgUkVT VENPTkYgc3RhY2tzLg0KICAgID4gV291bGQgcmVhbGx5IGxpa2UgdG8gc2VlIGFuIElFVEYgZGVm aW5lZCBhcHByb2FjaCBmb3IgdGhpcywgdG8gYXZvaWQgbXVsdGktdmVuZG9yIGNsaWVudHMgbmVl ZCB0byBkZWFsIHZhcmlvdXMgdmVuZG9ycyBpbXBsZW1lbnRhdGlvbnMuDQogICAgPiANCiAgICA+ IC93aXNvDQogICAgDQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KICAgID4gbmV0Y29uZiBtYWlsaW5nIGxpc3QNCiAgICA+IG5ldGNvbmZAaWV0 Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29u Zg0KICAgIA0KICAgIA0KICAgIC0tIA0KICAgIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAg ICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQogICAgUGhvbmU6ICs0OSA0MjEgMjAw IDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KICAg IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11bml2 ZXJzaXR5LmRlLz4NCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KICAgIG5ldGNvbmYgbWFpbGluZyBsaXN0DQogICAgbmV0Y29uZkBpZXRm Lm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K ICAgIA0KDQo= From nobody Thu Mar 14 03:49:56 2019 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 C0C3E128B36 for ; Thu, 14 Mar 2019 03:49:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 01_-cwAeACzm for ; Thu, 14 Mar 2019 03:49:52 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8DF1288AB for ; Thu, 14 Mar 2019 03:49:52 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 7B62FF5D; Thu, 14 Mar 2019 11:49:50 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Jflrb2easqrn; Thu, 14 Mar 2019 11:49:50 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 14 Mar 2019 11:49:50 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6696620086; Thu, 14 Mar 2019 11:49:50 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id KpwXQzYZq9Jh; Thu, 14 Mar 2019 11:49:50 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 2FEC020082; Thu, 14 Mar 2019 11:49:50 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Thu, 14 Mar 2019 11:49:49 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 1EC4930073452E; Thu, 14 Mar 2019 11:49:48 +0100 (CET) Date: Thu, 14 Mar 2019 11:49:48 +0100 From: Juergen Schoenwaelder To: "Wisotzky, Sven (Nokia - DE/Stuttgart)" CC: "netconf@ietf.org" Message-ID: <20190314104948.db6tbadwgo74pbgz@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Wisotzky, Sven (Nokia - DE/Stuttgart)" , "netconf@ietf.org" References: <20190314093552.3pwa7ptrre4t2stk@anna.jacobs.jacobs-university.de> <9DE27BCF-61F3-4085-A1F8-0FEAD76F85A5@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <9DE27BCF-61F3-4085-A1F8-0FEAD76F85A5@nokia.com> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netconf] Current activities on RESTCONF/NETCONF to support paging 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, 14 Mar 2019 10:49:55 -0000 On Thu, Mar 14, 2019 at 10:07:33AM +0000, Wisotzky, Sven (Nokia - DE/Stuttgart) wrote: > > However, as per my initial post below, just defining a limit (aka max-count) is a very efficient initial step to improve loading time and avoid crashes. Sorry, but if code crashes, then someone has to fix the code. Adding query parameters is not the right answer for this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Mar 14 05:14:24 2019 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 90B8E1288AB for ; Thu, 14 Mar 2019 05:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBSUuDWTEPXF for ; Thu, 14 Mar 2019 05:14:20 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80135.outbound.protection.outlook.com [40.107.8.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADD5012DF71 for ; Thu, 14 Mar 2019 05:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HbBCidErZGCT4LHQZFjKuIAyxcA2zhghRTusk3AdzCU=; b=V5fgxIK4HloxOhir10YWvfzoCr/eElyG8vO9fTTKrtwFUo9XH/nTxwIggCX+D6NsZnP9qbL0sGK2EkfcBnGdaCavGtwdOWcW7+XK7wSHVxWwLPKDu7sSP+fRmjiVzWsH/+rnNjrAruEjp/hgSVAyUPXMHXLSodfW2Wj+lwRklyg= Received: from DB7PR07MB5386.eurprd07.prod.outlook.com (20.178.46.26) by DB7PR07MB5546.eurprd07.prod.outlook.com (20.178.45.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.8; Thu, 14 Mar 2019 12:14:16 +0000 Received: from DB7PR07MB5386.eurprd07.prod.outlook.com ([fe80::181c:32c6:16f2:7433]) by DB7PR07MB5386.eurprd07.prod.outlook.com ([fe80::181c:32c6:16f2:7433%3]) with mapi id 15.20.1709.011; Thu, 14 Mar 2019 12:14:16 +0000 From: "Wisotzky, Sven (Nokia - DE/Stuttgart)" To: Juergen Schoenwaelder CC: "netconf@ietf.org" Thread-Topic: [netconf] Current activities on RESTCONF/NETCONF to support paging Thread-Index: AQHU2kekdlWyfgR30USJDGKLseBWaqYK3hEAgAAZnQD///sMAIAAKFuA Date: Thu, 14 Mar 2019 12:14:15 +0000 Message-ID: <84900927-1EB4-4DD5-9020-1F17990D1285@nokia.com> References: <20190314093552.3pwa7ptrre4t2stk@anna.jacobs.jacobs-university.de> <9DE27BCF-61F3-4085-A1F8-0FEAD76F85A5@nokia.com> <20190314104948.db6tbadwgo74pbgz@anna.jacobs.jacobs-university.de> In-Reply-To: <20190314104948.db6tbadwgo74pbgz@anna.jacobs.jacobs-university.de> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.0.190309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=sven.wisotzky@nokia.com; x-originating-ip: [188.97.190.16] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1c15466e-32b0-4bd4-80f9-08d6a87693e7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:DB7PR07MB5546; x-ms-traffictypediagnostic: DB7PR07MB5546: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 09760A0505 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(376002)(346002)(396003)(366004)(199004)(189003)(6916009)(316002)(26005)(81166006)(6116002)(7736002)(446003)(11346002)(6246003)(81156014)(8676002)(93886005)(5660300002)(53936002)(36756003)(83716004)(97736004)(102836004)(99286004)(3846002)(71200400001)(6306002)(256004)(14444005)(58126008)(66574012)(6512007)(186003)(71190400001)(2906002)(229853002)(6486002)(82746002)(8936002)(2616005)(486006)(305945005)(14454004)(86362001)(76176011)(476003)(105586002)(106356001)(25786009)(66066001)(6506007)(68736007)(4326008)(33656002)(6436002)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB5546; H:DB7PR07MB5386.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: pUrN1xxnO+EqtW2FS12PvE84PEGEbBzdsk+Km9roEzIw16p+4wip4Jo8yoV2xuIcRM9kj57EReTn3WqIVzGRWqMAwCYx0XOvWJCQM2WxgKn5y3fKATx3Viu07y4Ls6VpNShTYQ2ycH8vbNnRVLTnvKQZAuuMvVzyW4Dr7KoYy/5Tb3LfdSJSVN5wV8qvFnSxm+7vsuTgwKRAytAuiyNkhGnzzojdVV6mt4TiblD0YxNibSFLPL4ghaaOzm7YQqWs0aHK2A6dWLBTdadWsF/2uvtvAw8n21gHRiyYH1rOlfjP4mUBjpQ5lbEfYqvzRopGlsYQQo9GEBXsMY6aNowCsmJI7+w3kVZoru/epxj94qnE8pRi2lfHdaQ5j1BWblyCrcH7vrd1FCT2+TRMXAr0vM4LzWlyNJXLe38rZpP1qrQ= Content-Type: text/plain; charset="utf-8" Content-ID: <14296DAEB3A0E44BAFAF3A3204E14049@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1c15466e-32b0-4bd4-80f9-08d6a87693e7 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2019 12:14:15.9352 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5546 Archived-At: Subject: Re: [netconf] Current activities on RESTCONF/NETCONF to support paging 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, 14 Mar 2019 12:14:22 -0000 RGVwZW5kcyBvbiB3aGF0ZXZlciB3ZSBjYWxsIGhlcmUgYSBjcmFzaC4gVGhlIGNoYWxsZW5naW5n IHBhcnQgb2YgTkVUQ09ORi9SRVNUQ09ORiBpcywgdGhhdCB0aGUgY2xpZW50IHdvdWxkIG5vdCBr bm93IGhvdyBiaWcgdGhlIGdldC9nZXQtY29uZmlnIHJlcGx5IHdvdWxkIGJlY29tZS4gSGF2aW5n IGEgSlMtYmFzZWQgV2ViVUkgY2xpZW50IHJ1bm5pbmcgYSBSRVNUQ09ORiBxdWVyeSwgeW91IGVh c2lseSBlbmQgdXAgaW4gc2l0dWF0aW9ucywgd2hlcmUgeW91IGJhc2ljYWxseSBuZWVkIHRvIHRl cm1pbmF0ZSB0aGUgamF2YXNjcmlwdCBiZWNhdXNlIGl0IHJ1bnMgb3V0IG9mIG1lbW9yeS4gQW5k IEkndmUgZXZlbiBzZWVuIHNpdHVhdGlvbnMsIHdoZXJlIHRoZSBicm93c2VyIGl0c2VsZiBkaWQg bm90IHJlc3BvbmQgYW55bW9yZSAoc3dhcHBpbmcgdG8gZGlzaywgLi4uKS4NCg0KQnkgaW50cm9k dWNpbmcgYSBwcm90ZWN0aW9uIG1lY2hhbmlzbXMgbGlrZSBtYXgtY291bnQsIHRoZSBjbGllbnQg Y2FuIGNvbnRyb2wgdG8gYSBjZXJ0YWluIGV4dGVudCBob3cgbXVjaCBkYXRhIHdpbGwgYmUgcmVj ZWl2ZWQuIEFuZCBieSB1c2luZyBwYWdpbmcgZm9yIHBvc3QgbG9hZGluZyBpbiB0aGUgYmFja2dy b3VuZCwgdGhlIGNsaWVudCBjb3VsZCBzdGlsbCBkZWNpZGUgaWYgaXQgaXMgcG9zc2libGUgdG8g bG9hZCBhbm90aGVyIHBhZ2Ugb3Igbm90LiBTbyB3aGVuIHJ1bm5pbmcgb3V0LW9mLW1lbW9yeSBv ciB3aGVuIHN0YXJ0IHN3YXBwaW5nLCB0aGUgY2xpZW50IGNvdWxkIGF2b2lkIGxvYWRpbmcgYW55 IGZ1cnRoZXIgcGFnZXMuIEdlbmVyYWxseSBJIGFtIHRoaW5raW5nIHRoaXMgaXMgYSB2ZXJ5IHJl YXNvbmFibGUgYWthIGNvbnRyb2xsZWQgIGFwcHJvYWNoLg0KDQpXaXRoIE5FVENPTkYgdG9kYXks IGZvciBzdXJlIG9uZSBjb3VsZCB0ZXJtaW5hdGUgdGhlIE5FVENPTkYgc2Vzc2lvbnMgaWYgdG9v IG11Y2ggZGF0YSBpcyByZWNlaXZlZCBhbmQgbWlnaHQgdHJ5IHVzaW5nIGEgWE1MIHN0cmVhbSBy ZWFkZXIgdG8gcHJvY2VzcyB3aGF0IGhhcyBiZWVuIHJlY2VpdmVkIHNvIGZhci4gQnV0IHdvdWxk IGNsYWltIHRoYXQgdGhpcyBpcyBub3QgYSBnb29kIGFwcHJvYWNoIGF0IGFsbCBhbmQgc2hvdWxk IGJlIGF2b2lkZWQuDQoNCi93aXNvDQoNCg0KDQoNCu+7v09uIDE0LjAzLjE5LCAxMTo0OSwgIkp1 ZXJnZW4gU2Nob2Vud2FlbGRlciIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5k ZT4gd3JvdGU6DQoNCiAgICBPbiBUaHUsIE1hciAxNCwgMjAxOSBhdCAxMDowNzozM0FNICswMDAw LCBXaXNvdHpreSwgU3ZlbiAoTm9raWEgLSBERS9TdHV0dGdhcnQpIHdyb3RlOg0KICAgID4gDQog ICAgPiBIb3dldmVyLCBhcyBwZXIgbXkgaW5pdGlhbCBwb3N0IGJlbG93LCBqdXN0IGRlZmluaW5n IGEgbGltaXQgKGFrYSBtYXgtY291bnQpIGlzIGEgdmVyeSBlZmZpY2llbnQgaW5pdGlhbCBzdGVw IHRvIGltcHJvdmUgbG9hZGluZyB0aW1lIGFuZCBhdm9pZCBjcmFzaGVzLg0KICAgIA0KICAgIFNv cnJ5LCBidXQgaWYgY29kZSBjcmFzaGVzLCB0aGVuIHNvbWVvbmUgaGFzIHRvIGZpeCB0aGUgY29k ZS4gQWRkaW5nDQogICAgcXVlcnkgcGFyYW1ldGVycyBpcyBub3QgdGhlIHJpZ2h0IGFuc3dlciBm b3IgdGhpcy4NCiAgICANCiAgICAvanMNCiAgICANCiAgICAtLSANCiAgICBKdWVyZ2VuIFNjaG9l bndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KICAgIFBo b25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1l biB8IEdlcm1hbnkNCiAgICBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczov L3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQogICAgDQoNCg== From nobody Thu Mar 14 07:42:04 2019 Return-Path: <010001697ca6f106-1e69b94e-9037-4846-afae-5a95b7063620-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 E55F4130EA9 for ; Thu, 14 Mar 2019 07:41:53 -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_DNSWL_NONE=-0.0001, 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 1x6whpxTmqAB for ; Thu, 14 Mar 2019 07:41:51 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6AE130E95 for ; Thu, 14 Mar 2019 07:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1552574509; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=I4AJCi1fuu/8l2YaOyZoJBTG4d64f87oFxC9I+5e5DY=; b=aUcS4P+lUk627/uV2/RnSitksf3AHJSCRov4kgLRtpfB5vEwXYQ1W+hUQbGAv465 lUwNg4vadcHr3gZNUsjbl6LtmuXVdlQnm6fO2KYh1CU2Bj9ju5OGhkaN0CbxK8ZApCt lBptswLCix0pbE5nGSTAvpohtorKCiVmru8w04ok= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_74E94A00-7F93-4B5E-BF08-6A781EA4F48C" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 14 Mar 2019 14:41:49 +0000 References: <0100016979939b1b-3ddaf119-fd79-4b38-b80b-2be09d10fc3c-000000@email.amazonses.com> To: Netconf In-Reply-To: <0100016979939b1b-3ddaf119-fd79-4b38-b80b-2be09d10fc3c-000000@email.amazonses.com> Message-ID: <010001697ca6f106-1e69b94e-9037-4846-afae-5a95b7063620-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.14-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] NETCONF 104 Draft Agenda 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, 14 Mar 2019 14:42:02 -0000 --Apple-Mail=_74E94A00-7F93-4B5E-BF08-6A781EA4F48C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Draft agenda has been updated (also posted here: = https://datatracker.ietf.org/doc/agenda-104-netconf) Please send any comments and/or concerns to the chairs. Agenda for the NETCONF WG Session in IETF 104 --------------------------------------------- Session: *** Special meeting, time split with NETMOD WG *** MONDAY, March 25, 2019 09:00-11:00 (NETCONF: 9-10, NETMOD 10-11) Morning Session I Room: Grand Ballroom =20 WG Chairs: Mahesh Jethanandani (mjethanandani at gmail dot com) Kent Watsen (kent+ietf at watsen dot net) =20 Available During Session: Audio stream: http://mp3.conf.meetecho.com/ietf/ietf1046.m3u Etherpad: = http://etherpad.tools.ietf.org/p/notes-ietf-104-netconf Slides: = https://datatracker.ietf.org/meeting/104/session/netconf Meetecho: http://www.meetecho.com/ietf104/netconf/ Jabber: xmpp:netconf@jabber.ietf.org?join =20 Available Post Session: Recording: https://www.ietf.org/audio/ietf104/ YouTube: https://www.youtube.com/user/ietf/playlists =20 =20 Introduction Chairs (10 minutes) Session Intro & WG Status =20 Chartered items: Kent Watsen (10 min) Status and Issues on Client-Server Drafts https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-05 https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-03 https://tools.ietf.org/html/draft-ietf-netconf-keystore-08 https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-11 https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-10 = https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-10 = https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-10 = https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00 = https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-00 Balazs Lengyel (10 min) YangPush Notification Capabilities = https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-0= 1 Non-Chartered items: Tianran Zhou (10 min) Subscription to Multiple Stream Originators = https://tools.ietf.org/html/draft-zhou-netconf-multi-stream-originators-04= Michael Wang / Qin Wu (10 min) NMDA Backwards-Compatibility with Legacy Devices https://tools.ietf.org/html/draft-wu-netconf-nmda-compatibility-00 Andy Bierman (10 min) Module Tag Operations https://tools.ietf.org/html/draft-bierman-netconf-module-tag-ops-00 NETMOD WG items: Lou Berger & Kent Watsen, as NETMOD Chairs (5 minutes) Introduction Rob Wilton and Company (55 min) YANG Versioning Design Team Update https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02 https://tools.ietf.org/html/draft-verdt-netmod-yang-semver-00 https://tools.ietf.org/html/draft-rwilton-netmod-yang-packages-01 https://tools.ietf.org/html/draft-wilton-netmod-yang-ver-selection-00 --Apple-Mail=_74E94A00-7F93-4B5E-BF08-6A781EA4F48C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Draft agenda has been updated (also posted here: https://datatracker.ietf.org/doc/agenda-104-netconf)
Please send any comments and/or concerns to the chairs.

Agenda for the NETCONF WG Session in IETF 104
---------------------------------------------

Session:   *** Special meeting, time split with NETMOD WG ***

   MONDAY, March 25, 2019 09:00-11:00   (NETCONF: 9-10, NETMOD 10-11)
   Morning Session I
   Room: Grand Ballroom
          
WG Chairs:
   Mahesh Jethanandani (mjethanandani at gmail dot com)
   Kent Watsen (kent+ietf at watsen dot net)
          
Available During Session:
   Audio stream:  http://mp3.conf.meetecho.com/ietf/ietf1046.m3u
   Etherpad:      http://etherpad.tools.ietf.org/p/notes-ietf-104-netconf
   Slides:        https://datatracker.ietf.org/meeting/104/session/netconf
   Meetecho:      http://www.meetecho.com/ietf104/netconf/
   Jabber:        xmpp:netconf@jabber.ietf.org?join
          
Available Post Session:
   Recording:     https://www.ietf.org/audio/ietf104/
   YouTube:       https://www.youtube.com/user/ietf/playlists
          
          
Introduction

  Chairs (10 minutes)
  Session Intro & WG Status
          
Chartered items:

   Kent Watsen (10 min)
   Status and Issues on Client-Server Drafts
   https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-05
   https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-03
   https://tools.ietf.org/html/draft-ietf-netconf-keystore-08
   https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-11
   https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-10
   https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-10
   https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-10
   https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00
   https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-00

   Balazs Lengyel (10 min)
   YangPush Notification Capabilities
   https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-01

Non-Chartered items:

   Tianran Zhou (10 min)
   Subscription to Multiple Stream Originators
   https://tools.ietf.org/html/draft-zhou-netconf-multi-stream-originators-04

   Michael Wang / Qin Wu (10 min)
   NMDA Backwards-Compatibility with Legacy Devices
   https://tools.ietf.org/html/draft-wu-netconf-nmda-compatibility-00

   Andy Bierman (10 min)
   Module Tag Operations
   https://tools.ietf.org/html/draft-bierman-netconf-module-tag-ops-00

NETMOD WG items:

  Lou Berger & Kent Watsen, as NETMOD Chairs (5 minutes)
  Introduction

  Rob Wilton and Company (55 min)
  YANG Versioning Design Team Update
  https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02
  https://tools.ietf.org/html/draft-verdt-netmod-yang-semver-00
  https://tools.ietf.org/html/draft-rwilton-netmod-yang-packages-01
  https://tools.ietf.org/html/draft-wilton-netmod-yang-ver-selection-00
--Apple-Mail=_74E94A00-7F93-4B5E-BF08-6A781EA4F48C-- From nobody Thu Mar 14 10:07:06 2019 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 9E4A91312A5 for ; Thu, 14 Mar 2019 10:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.247 X-Spam-Level: X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 gLHc2v4o2oQs for ; Thu, 14 Mar 2019 10:06:50 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on072e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::72e]) (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 718C3130F5F for ; Thu, 14 Mar 2019 10:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kYn5MethdVlYKJDMuF4zQR0Sn2h+/fwYr6V3kAcF81g=; b=UUSogZM4hJJHR3UaGvKVX0DijZQxrFwvE1ys3RF1lC+5MrMVQBOsIOZgpl2wpNkE1YAop3wwTuemajA5OmuLByk4sJ28gjhXqTrBu0LieqiwcBEclsO7zQkCv3RMt6E2wZkWjf/Nonasd6Ys7QHgbyaPdGno5+QfPwNodasZtMg= Received: from VI1PR07MB4768.eurprd07.prod.outlook.com (20.177.57.155) by VI1PR07MB4989.eurprd07.prod.outlook.com (20.178.9.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.11; Thu, 14 Mar 2019 17:06:46 +0000 Received: from VI1PR07MB4768.eurprd07.prod.outlook.com ([fe80::f4b6:8b99:765a:92e2]) by VI1PR07MB4768.eurprd07.prod.outlook.com ([fe80::f4b6:8b99:765a:92e2%4]) with mapi id 15.20.1730.003; Thu, 14 Mar 2019 17:06:45 +0000 From: tom petch To: "Wisotzky, Sven (Nokia - DE/Stuttgart)" , Juergen Schoenwaelder CC: "netconf@ietf.org" Thread-Topic: [netconf] Current activities on RESTCONF/NETCONF to support paging Thread-Index: AQHU2ohNY2OPoaj9d0esxqiuw6QcZg== Date: Thu, 14 Mar 2019 17:06:45 +0000 Message-ID: <024e01d4da87$fbcc5720$4001a8c0@gateway.2wire.net> References: <20190314093552.3pwa7ptrre4t2stk@anna.jacobs.jacobs-university.de> <9DE27BCF-61F3-4085-A1F8-0FEAD76F85A5@nokia.com> <20190314104948.db6tbadwgo74pbgz@anna.jacobs.jacobs-university.de> <84900927-1EB4-4DD5-9020-1F17990D1285@nokia.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0190.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a::34) To VI1PR07MB4768.eurprd07.prod.outlook.com (2603:10a6:803:76::27) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.156.84.54] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9b62fece-9985-4a14-f35b-08d6a89f6fe4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB4989; x-ms-traffictypediagnostic: VI1PR07MB4989: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 09760A0505 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(136003)(376002)(396003)(346002)(199004)(189003)(13464003)(44716002)(14496001)(8676002)(61296003)(3846002)(6116002)(6246003)(6436002)(305945005)(316002)(296002)(14454004)(99286004)(4326008)(478600001)(25786009)(68736007)(93886005)(71190400001)(71200400001)(486006)(7736002)(476003)(97736004)(2906002)(84392002)(26005)(6306002)(4720700003)(6512007)(86152003)(9686003)(81166006)(81156014)(102836004)(66574012)(105586002)(52116002)(966005)(106356001)(53936002)(81686011)(76176011)(6506007)(81816011)(229853002)(386003)(66066001)(50226002)(44736005)(186003)(256004)(8936002)(110136005)(86362001)(446003)(14444005)(6486002)(1556002)(5660300002)(62236002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4989; H:VI1PR07MB4768.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: EZsuIIoNriXKQMzV3Fo8bKSL0JQdwwNLly+8OYq/JrzrodEWClTMWZMIwyZM1veqP3/qemmbpZpYW8RsipKVV6StOyzyLpvD9wDMFRwPwGmNdkFgb/oKX7YIk2Qka8J3U9Ew8UoGFzzfLIV9XWoPolMIii6jlnS6oGf/XOITgdBj4YBAfDm8vvt2WILWVCEMvs27A5Lo9U0+5JYA+v5QHeeOWGTBkcDRxQ2AgHD31BLD3HgHJndFiVhmRWXulLjljNDoEeSX3v1gFAFXLR+/bw4dw1Iwkd3YhWPIMVWpm51oFFd3XfpeaTnFJLxW4HGfrq2xxGgSCSnL8KWT1geTJoaP5V1lEtZsruNkICuEoFj81c960svPWeI2DgW+cFHPlDr1/xmDywD79/L9/Yqf0XraFzFhbLkAuKIq8vQ8VAk= Content-Type: text/plain; charset="utf-8" Content-ID: <6A68C4EDFCDC4148A2856C64215C3E93@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9b62fece-9985-4a14-f35b-08d6a89f6fe4 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2019 17:06:45.9112 (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-Transport-CrossTenantHeadersStamped: VI1PR07MB4989 Archived-At: Subject: Re: [netconf] Current activities on RESTCONF/NETCONF to support paging 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, 14 Mar 2019 17:07:00 -0000 LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIldpc290emt5LCBTdmVuIChOb2tp YSAtIERFL1N0dXR0Z2FydCkiIDxzdmVuLndpc290emt5QG5va2lhLmNvbT4NClNlbnQ6IFRodXJz ZGF5LCBNYXJjaCAxNCwgMjAxOSAxMjoxNCBQTQ0KDQo+IERlcGVuZHMgb24gd2hhdGV2ZXIgd2Ug Y2FsbCBoZXJlIGEgY3Jhc2guIFRoZSBjaGFsbGVuZ2luZyBwYXJ0IG9mDQpORVRDT05GL1JFU1RD T05GIGlzLCB0aGF0IHRoZSBjbGllbnQgd291bGQgbm90IGtub3cgaG93IGJpZyB0aGUNCmdldC9n ZXQtY29uZmlnIHJlcGx5IHdvdWxkIGJlY29tZS4gSGF2aW5nIGEgSlMtYmFzZWQgV2ViVUkgY2xp ZW50DQpydW5uaW5nIGEgUkVTVENPTkYgcXVlcnksIHlvdSBlYXNpbHkgZW5kIHVwIGluIHNpdHVh dGlvbnMsIHdoZXJlIHlvdQ0KYmFzaWNhbGx5IG5lZWQgdG8gdGVybWluYXRlIHRoZSBqYXZhc2Ny aXB0IGJlY2F1c2UgaXQgcnVucyBvdXQgb2YNCm1lbW9yeS4gQW5kIEkndmUgZXZlbiBzZWVuIHNp dHVhdGlvbnMsIHdoZXJlIHRoZSBicm93c2VyIGl0c2VsZiBkaWQgbm90DQpyZXNwb25kIGFueW1v cmUgKHN3YXBwaW5nIHRvIGRpc2ssIC4uLikuDQoNCk9uZSBhZnRlcm5vb24sIEkgc2V0IGFuIFNO TVAgZ2V0LW5leHQgZ29pbmcgb24gUk1PTiBhbmQgaXQgd2FzIHN0aWxsDQpnb2luZyB0aGUgbmV4 dCBkYXk7IEkgdGhlbiB0cmllZCBvdmVyIGEgd2Vla2VuZCBhbmQgaXQgd2FzIHN0aWxsIGdvaW5n DQp0aGUgbmV4dCB3ZWVrLiAgRGF0YSB3YXMgYmVpbmcgYWRkZWQgdG8gdGhlIHRhYmxlIGZhc3Rl ciB0aGFuIG15IGhpZ2gNCnNwZWVkIExBTiBjb3VsZCByZXRyaWV2ZSBpdC4gIE5laXRoZXIgc3lz dGVtIGNyYXNoZWQgYWx0aG91Z2ggcmVzcG9uc2UNCnRpbWVzIGZvciBvdGhlciBhcHBsaWNhdGlv bnMgZWxvbmdhdGVkLg0KDQpJIGFtIHJlbWluZGVkIG9mIGUtbWFpbCB3aGVyZSBhIFBPUCBjbGll bnQgbWF5IGFjY2VzcyBhIHZlcnkgbGFyZ2UgbGlzdA0Kb2YgZS1tYWlscyBvbiBhIHNlcnZlci4g IFRoZSBmaXJzdCByZXNwb25zZSBpcyBhIGNvdW50IG9mIGhvdyBtYW55IHRoZXJlDQphcmUgY3Vy cmVudGx5OyB0aGUgY2xpZW50IGNhbiB0aGVuIHJlcXVlc3QgdGhlIHN1bW1hcnkgZGF0YSBmb3Ig ZWFjaA0KYmVmb3JlIGRlY2lkaW5nIHdoaWNoIHRvIGRvd25sb2FkIGluIGZ1bGwuICBUaGlzIHdh cyBkZXNpZ25lZCBiZWZvcmUgdGhlDQpjbG91ZCB3YXMgdGhvdWdodCBvZiBhbmQgaXQgaXMgYSBz eXN0ZW0gdGhhdCBzdGlsbCB3b3JrcyB3ZWxsLg0KDQpUb20gUGV0Y2gNCg0KDQoNCg0KDQoNCg0K Pg0KPiBCeSBpbnRyb2R1Y2luZyBhIHByb3RlY3Rpb24gbWVjaGFuaXNtcyBsaWtlIG1heC1jb3Vu dCwgdGhlIGNsaWVudCBjYW4NCmNvbnRyb2wgdG8gYSBjZXJ0YWluIGV4dGVudCBob3cgbXVjaCBk YXRhIHdpbGwgYmUgcmVjZWl2ZWQuIEFuZCBieSB1c2luZw0KcGFnaW5nIGZvciBwb3N0IGxvYWRp bmcgaW4gdGhlIGJhY2tncm91bmQsIHRoZSBjbGllbnQgY291bGQgc3RpbGwgZGVjaWRlDQppZiBp dCBpcyBwb3NzaWJsZSB0byBsb2FkIGFub3RoZXIgcGFnZSBvciBub3QuIFNvIHdoZW4gcnVubmlu Zw0Kb3V0LW9mLW1lbW9yeSBvciB3aGVuIHN0YXJ0IHN3YXBwaW5nLCB0aGUgY2xpZW50IGNvdWxk IGF2b2lkIGxvYWRpbmcgYW55DQpmdXJ0aGVyIHBhZ2VzLiBHZW5lcmFsbHkgSSBhbSB0aGlua2lu ZyB0aGlzIGlzIGEgdmVyeSByZWFzb25hYmxlIGFrYQ0KY29udHJvbGxlZCAgYXBwcm9hY2guDQo+ DQo+IFdpdGggTkVUQ09ORiB0b2RheSwgZm9yIHN1cmUgb25lIGNvdWxkIHRlcm1pbmF0ZSB0aGUg TkVUQ09ORiBzZXNzaW9ucw0KaWYgdG9vIG11Y2ggZGF0YSBpcyByZWNlaXZlZCBhbmQgbWlnaHQg dHJ5IHVzaW5nIGEgWE1MIHN0cmVhbSByZWFkZXIgdG8NCnByb2Nlc3Mgd2hhdCBoYXMgYmVlbiBy ZWNlaXZlZCBzbyBmYXIuIEJ1dCB3b3VsZCBjbGFpbSB0aGF0IHRoaXMgaXMgbm90DQphIGdvb2Qg YXBwcm9hY2ggYXQgYWxsIGFuZCBzaG91bGQgYmUgYXZvaWRlZC4NCj4NCj4gL3dpc28NCj4NCj4N Cj4NCj4NCj4g77u/T24gMTQuMDMuMTksIDExOjQ5LCAiSnVlcmdlbiBTY2hvZW53YWVsZGVyIg0K PGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+DQo+ICAgICBP biBUaHUsIE1hciAxNCwgMjAxOSBhdCAxMDowNzozM0FNICswMDAwLCBXaXNvdHpreSwgU3ZlbiAo Tm9raWEgLQ0KREUvU3R1dHRnYXJ0KSB3cm90ZToNCj4gICAgID4NCj4gICAgID4gSG93ZXZlciwg YXMgcGVyIG15IGluaXRpYWwgcG9zdCBiZWxvdywganVzdCBkZWZpbmluZyBhIGxpbWl0DQooYWth IG1heC1jb3VudCkgaXMgYSB2ZXJ5IGVmZmljaWVudCBpbml0aWFsIHN0ZXAgdG8gaW1wcm92ZSBs b2FkaW5nIHRpbWUNCmFuZCBhdm9pZCBjcmFzaGVzLg0KPg0KPiAgICAgU29ycnksIGJ1dCBpZiBj b2RlIGNyYXNoZXMsIHRoZW4gc29tZW9uZSBoYXMgdG8gZml4IHRoZSBjb2RlLg0KQWRkaW5nDQo+ ICAgICBxdWVyeSBwYXJhbWV0ZXJzIGlzIG5vdCB0aGUgcmlnaHQgYW5zd2VyIGZvciB0aGlzLg0K Pg0KPiAgICAgL2pzDQo+DQo+ICAgICAtLQ0KPiAgICAgSnVlcmdlbiBTY2hvZW53YWVsZGVyICAg ICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gICAgIFBob25lOiArNDkg NDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8DQpHZXJt YW55DQo+ICAgICBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMw0KPGh0dHBzOi8vd3d3LmphY29icy11 bml2ZXJzaXR5LmRlLz4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gbmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gbmV0Y29uZkBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4NCg0K From nobody Thu Mar 14 13:08:58 2019 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 4BE5E12785F for ; Thu, 14 Mar 2019 13:08:56 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hubler-us.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 eyqikA9bXkbT for ; Thu, 14 Mar 2019 13:08:53 -0700 (PDT) Received: from mail-it1-x12a.google.com (mail-it1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 A6A611277DE for ; Thu, 14 Mar 2019 13:08:53 -0700 (PDT) Received: by mail-it1-x12a.google.com with SMTP id m137so6794856ita.0 for ; Thu, 14 Mar 2019 13:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hubler-us.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E22qDmRjUthyZS70dBox4PEEQiL/TMZTqDWxoKKtiso=; b=w1eVT+pD0wTYOD7GSYetwcH43uZqqE3oaJR4U4WwuclhH9oDXHDRIF3JeTuYXOMUNx 7CA3mriFr1lL1am7OvFkzi02gjuwpFi415boyeQngQ68cAIxwiD0XZ92D+hU2H9cc6Ny hwa92vF5przQUl0bb3DA3kh4/Y7EaYeMscgwHcwQf2ugbW8cURKBpBBulCOOB6FEiAdV lHj6jxAujNqtAycAN3GIucUP5L5OpRQAQE6P82UhpeRG+CUYZ7QvbxiOYMTx0B9GX3wg dNAFSdTWhZbV78yP/JVhF3foQLjmLk+oj7aPhLXEbkWaarpTEiYxbjwlSnr+gZznYuV9 B5pg== 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=E22qDmRjUthyZS70dBox4PEEQiL/TMZTqDWxoKKtiso=; b=CBCbAhRvgaCxDbi8b3iSPz4cjfRc+0fZyPLlSn+80EQuxoYIpISn36CuIOu8B6GZMm dVzt21T0tn5hOL+HBgAuk0j3g/aADU4v0iaYgRgpyM27vMMZKvkWiaUBdJlIj81YNK2z jJrEpLA+XKsQjET1HmdcIVtwHxS7nrbcs6Q2ccMWwEGT81dFos5cFMFgL8esPGcRyB29 6bXEwZXEsHF7SvtWgVTaiPCdv+gA681mE7BspYESIdYWK79RSKpamhYBs8FaIDgtVFRA TNQqvVzpZgoJodU1InshTMxltcIhL2y9kOOirz/HnNbXJcE0AskUQTVm8n2XPTKiLP0Z /sQA== X-Gm-Message-State: APjAAAVpzGgRN7MSfb6qdYnCT5Aut1Z/KqKHYqTBYj+tqiGlvH5scTpo u6086u81uR8y6ABKUTPTDYVEgMWsC6Q= X-Google-Smtp-Source: APXvYqzb5nqX6cNBDfQxg86iQzIQPRjTtq667d+1R/DEj9nzETHt78m8QwWsTyFVytXTp1lIwfYSGA== X-Received: by 2002:a24:ac58:: with SMTP id m24mr179707iti.129.1552594132799; Thu, 14 Mar 2019 13:08:52 -0700 (PDT) Received: from mail-io1-f42.google.com (mail-io1-f42.google.com. [209.85.166.42]) by smtp.gmail.com with ESMTPSA id c25sm7129473ioa.75.2019.03.14.13.08.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Mar 2019 13:08:52 -0700 (PDT) Received: by mail-io1-f42.google.com with SMTP id x4so6293346ion.2 for ; Thu, 14 Mar 2019 13:08:51 -0700 (PDT) X-Received: by 2002:a5e:8e45:: with SMTP id r5mr9636665ioo.221.1552594131694; Thu, 14 Mar 2019 13:08:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Douglas Hubler Date: Thu, 14 Mar 2019 16:08:40 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Wisotzky, Sven (Nokia - DE/Stuttgart)" Cc: "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b33a610584137d21" Archived-At: Subject: Re: [netconf] Current activities on RESTCONF/NETCONF to support paging 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, 14 Mar 2019 20:08:57 -0000 --000000000000b33a610584137d21 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 14, 2019 at 5:24 AM Wisotzky, Sven (Nokia - DE/Stuttgart) < sven.wisotzky@nokia.com> wrote: > There was some discussion in earlier days (back in 2012/2014) to support > paging for extra-long lists. The main use-case is clearly to improve > support for interactive user-frontends, as loading entire lists with > potentially more than 100.000=E2=80=99s objects easily can become a night= mare: > loading time, memory consumption, crashes, =E2=80=A6 > speaking from experience, RESTCONF is very usable straight from interactive user-frontends and this is one of the key things missing. I did add a custom parameter to FreeCONF's RESTCONF implementation to support this. Maybe I took this took far, but I decided that because data is in a hierarchy you might have multiple lists you need to page thru so I came up this this parameter range=3Db/c!N-M returns rows N thru M inclusive in list under path b/c. And that you can specify multiple ranges for multiple paths. Front ends usually have no problem remembering what number they are on to track N and M. As brought-up, for lists that are highly dynamic, this strategy is bit naive and maybe etags can help the clients that need to know when list has changed and they might need to start over. For my backend, I could start iteration at row N without have to manage a cursor. I did not found any active DRAFT or RFC for this. That said, we can see > various vendors implementing proprietary solutions for this in their > RESTCONF stacks. > > Would really like to see an IETF defined approach for this, to avoid > multi-vendor clients need to deal various vendors implementations. > +1 --000000000000b33a610584137d21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Mar 14, 2019 at 5:24 AM Wisot= zky, Sven (Nokia - DE/Stuttgart) <sven.wisotzky@nokia.com> wrote:

There was some discus= sion in earlier days (back in 2012/2014) to support paging for extra-long l= ists. The main use-case is clearly to improve support for interactive user-= frontends, as loading entire lists with potentially more than 100.000=E2=80=99s objects easily c= an become a nightmare: loading time, memory consumption, crashes, =E2=80=A6=


speaking from e= xperience, RESTCONF is very usable straight from interactive user-frontends= and this is one of the key things missing.=C2=A0 I did add a custom parame= ter to FreeCONF's RESTCONF implementation to support this.=C2=A0 Maybe = I took this took far, but I decided that because data is in a hierarchy you= might have multiple lists you need to page thru so I came up this this par= ameter

=C2=A0= =C2=A0range=3Db/c!N-M

returns rows N thru M inclusive in list under pa= th b/c.=C2=A0 And that you can specify multiple ranges for multiple paths.= =C2=A0=C2=A0Front ends usually have no problem remembering what numbe= r they are on to track N and M.

As br= ought-up, for lists that are highly dynamic, this strategy is bit naive and= maybe etags can help the clients that need to know when list has changed a= nd they might need to start over.=C2=A0 For my backend, I could start itera= tion at row N without have to manage a cursor.

=

I did = not found any active DRAFT or RFC for this. That said, we can see various v= endors implementing proprietary solutions for this in their RESTCONF stacks= .

Would = really like to see an IETF defined approach for this, to avoid multi-vendor= clients need to deal various vendors implementations.


+1

--000000000000b33a610584137d21-- From nobody Thu Mar 14 18:54:56 2019 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 B5665130F29 for ; Thu, 14 Mar 2019 18:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 OFgH1LN0OVZs for ; Thu, 14 Mar 2019 18:54:51 -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 1EE0F124B16 for ; Thu, 14 Mar 2019 18:54:51 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 05D7174E7E5BE1FF5D46 for ; Fri, 15 Mar 2019 01:54:49 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 15 Mar 2019 01:54:43 +0000 Received: from DGGEMM527-MBX.china.huawei.com ([169.254.6.77]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0415.000; Fri, 15 Mar 2019 09:54:37 +0800 From: wangzitao To: Douglas Hubler , "Wisotzky, Sven (Nokia - DE/Stuttgart)" CC: "netconf@ietf.org" Thread-Topic: [netconf] Current activities on RESTCONF/NETCONF to support paging Thread-Index: AdTa0NoVunCd1tZJRWC3RA+1mlX0vQ== Date: Fri, 15 Mar 2019 01:54:36 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.142.117] Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EA2D9703A5DGGEMM527MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Current activities on RESTCONF/NETCONF to support paging 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, 15 Mar 2019 01:54:54 -0000 --_000_E6BC9BBCBCACC246846FC685F9FF41EA2D9703A5DGGEMM527MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQrlj5Hku7bkuro6IG5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIOS7 o+ihqCBEb3VnbGFzIEh1Ymxlcg0K5Y+R6YCB5pe26Ze0OiAyMDE55bm0M+aciDE15pelIDQ6MDkN CuaUtuS7tuS6ujogV2lzb3R6a3ksIFN2ZW4gKE5va2lhIC0gREUvU3R1dHRnYXJ0KSA8c3Zlbi53 aXNvdHpreUBub2tpYS5jb20+DQrmioTpgIE6IG5ldGNvbmZAaWV0Zi5vcmcNCuS4u+mimDogUmU6 IFtuZXRjb25mXSBDdXJyZW50IGFjdGl2aXRpZXMgb24gUkVTVENPTkYvTkVUQ09ORiB0byBzdXBw b3J0IHBhZ2luZw0KDQoNCg0KT24gVGh1LCBNYXIgMTQsIDIwMTkgYXQgNToyNCBBTSBXaXNvdHpr eSwgU3ZlbiAoTm9raWEgLSBERS9TdHV0dGdhcnQpIDxzdmVuLndpc290emt5QG5va2lhLmNvbTxt YWlsdG86c3Zlbi53aXNvdHpreUBub2tpYS5jb20+PiB3cm90ZToNClRoZXJlIHdhcyBzb21lIGRp c2N1c3Npb24gaW4gZWFybGllciBkYXlzIChiYWNrIGluIDIwMTIvMjAxNCkgdG8gc3VwcG9ydCBw YWdpbmcgZm9yIGV4dHJhLWxvbmcgbGlzdHMuIFRoZSBtYWluIHVzZS1jYXNlIGlzIGNsZWFybHkg dG8gaW1wcm92ZSBzdXBwb3J0IGZvciBpbnRlcmFjdGl2ZSB1c2VyLWZyb250ZW5kcywgYXMgbG9h ZGluZyBlbnRpcmUgbGlzdHMgd2l0aCBwb3RlbnRpYWxseSBtb3JlIHRoYW4gMTAwLjAwMOKAmXMg b2JqZWN0cyBlYXNpbHkgY2FuIGJlY29tZSBhIG5pZ2h0bWFyZTogbG9hZGluZyB0aW1lLCBtZW1v cnkgY29uc3VtcHRpb24sIGNyYXNoZXMsIOKApg0KDQpzcGVha2luZyBmcm9tIGV4cGVyaWVuY2Us IFJFU1RDT05GIGlzIHZlcnkgdXNhYmxlIHN0cmFpZ2h0IGZyb20gaW50ZXJhY3RpdmUgdXNlci1m cm9udGVuZHMgYW5kIHRoaXMgaXMgb25lIG9mIHRoZSBrZXkgdGhpbmdzIG1pc3NpbmcuICBJIGRp ZCBhZGQgYSBjdXN0b20gcGFyYW1ldGVyIHRvIEZyZWVDT05GJ3MgUkVTVENPTkYgaW1wbGVtZW50 YXRpb24gdG8gc3VwcG9ydCB0aGlzLiAgTWF5YmUgSSB0b29rIHRoaXMgdG9vayBmYXIsIGJ1dCBJ IGRlY2lkZWQgdGhhdCBiZWNhdXNlIGRhdGEgaXMgaW4gYSBoaWVyYXJjaHkgeW91IG1pZ2h0IGhh dmUgbXVsdGlwbGUgbGlzdHMgeW91IG5lZWQgdG8gcGFnZSB0aHJ1IHNvIEkgY2FtZSB1cCB0aGlz IHRoaXMgcGFyYW1ldGVyDQoNCiAgIHJhbmdlPWIvYyFOLU0NCg0KcmV0dXJucyByb3dzIE4gdGhy dSBNIGluY2x1c2l2ZSBpbiBsaXN0IHVuZGVyIHBhdGggYi9jLiAgQW5kIHRoYXQgeW91IGNhbiBz cGVjaWZ5IG11bHRpcGxlIHJhbmdlcyBmb3IgbXVsdGlwbGUgcGF0aHMuICBGcm9udCBlbmRzIHVz dWFsbHkgaGF2ZSBubyBwcm9ibGVtIHJlbWVtYmVyaW5nIHdoYXQgbnVtYmVyIHRoZXkgYXJlIG9u IHRvIHRyYWNrIE4gYW5kIE0uDQoNCkFzIGJyb3VnaHQtdXAsIGZvciBsaXN0cyB0aGF0IGFyZSBo aWdobHkgZHluYW1pYywgdGhpcyBzdHJhdGVneSBpcyBiaXQgbmFpdmUgYW5kIG1heWJlIGV0YWdz IGNhbiBoZWxwIHRoZSBjbGllbnRzIHRoYXQgbmVlZCB0byBrbm93IHdoZW4gbGlzdCBoYXMgY2hh bmdlZCBhbmQgdGhleSBtaWdodCBuZWVkIHRvIHN0YXJ0IG92ZXIuICBGb3IgbXkgYmFja2VuZCwg SSBjb3VsZCBzdGFydCBpdGVyYXRpb24gYXQgcm93IE4gd2l0aG91dCBoYXZlIHRvIG1hbmFnZSBh IGN1cnNvci4NCg0KDQpJIGRpZCBub3QgZm91bmQgYW55IGFjdGl2ZSBEUkFGVCBvciBSRkMgZm9y IHRoaXMuIFRoYXQgc2FpZCwgd2UgY2FuIHNlZSB2YXJpb3VzIHZlbmRvcnMgaW1wbGVtZW50aW5n IHByb3ByaWV0YXJ5IHNvbHV0aW9ucyBmb3IgdGhpcyBpbiB0aGVpciBSRVNUQ09ORiBzdGFja3Mu Lg0KV291bGQgcmVhbGx5IGxpa2UgdG8gc2VlIGFuIElFVEYgZGVmaW5lZCBhcHByb2FjaCBmb3Ig dGhpcywgdG8gYXZvaWQgbXVsdGktdmVuZG9yIGNsaWVudHMgbmVlZCB0byBkZWFsIHZhcmlvdXMg dmVuZG9ycyBpbXBsZW1lbnRhdGlvbnMuDQoNCisxDQpBZ3JlZSB3aXRoIHlvdS4gQWN0dWFsbHks IHRoZXJlIGFyZSBzb21lIGRpc2N1c3Npb25zIGluIHRoaXMgV0cuIEFuZCB0aGVyZSBpcyBhbiBl eHBpcmVkPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2RyYWZ0LWlldGYtbmV0 Y29uZi1yZXN0Y29uZi1jb2xsZWN0aW9uPiBkcmFmdCB0aGF0IHRyeSB0byBhZGRyZXNzIHRoZXNl IGlzc3VlcyAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1y ZXN0Y29uZi1jb2xsZWN0aW9uLTAwKS4NCklNTywgdGhlc2UgcHJvYmxlbXMgYWxzbyBleGlzdCBp biBORVRDT05GLCB0aGVyZWZvcmUsIGEgY29tbW9uIHNvbHV0aW9uIGlzIHJlcXVpcmVkLg0KDQpC ZXN0IFJlZ2FyZHMhDQotTWljaGFlbA0KDQo= --_000_E6BC9BBCBCACC246846FC685F9FF41EA2D9703A5DGGEMM527MBXchi_ 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 aWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMgMiAyIDQgMiAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAg MyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N 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 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNl cmlmIj7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvl vq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+IG5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJv dW5jZXNAaWV0Zi5vcmddDQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuS7o+ihqCA8 L3NwYW4+DQo8L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj5Eb3VnbGFzIEh1 Ymxlcjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5Y+R6YCB5pe26Ze0PHNw YW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7 LHNhbnMtc2VyaWYiPiAyMDE5PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lubQ8c3BhbiBs YW5nPSJFTi1VUyI+Mzwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+MTU8L3NwYW4+5pelPHNw YW4gbGFuZz0iRU4tVVMiPg0KIDQ6MDk8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFu Zz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gV2lzb3R6a3ksIFN2ZW4g KE5va2lhIC0gREUvU3R1dHRnYXJ0KSAmbHQ7c3Zlbi53aXNvdHpreUBub2tpYS5jb20mZ3Q7PGJy Pg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyI+IG5ldGNvbmZAaWV0Zi5vcmc8YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4g bGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6IFtuZXRjb25m XSBDdXJyZW50IGFjdGl2aXRpZXMgb24gUkVTVENPTkYvTkVUQ09ORiB0byBzdXBwb3J0IHBhZ2lu ZzxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVGh1LCBNYXIgMTQsIDIwMTkgYXQg NToyNCBBTSBXaXNvdHpreSwgU3ZlbiAoTm9raWEgLSBERS9TdHV0dGdhcnQpICZsdDs8YSBocmVm PSJtYWlsdG86c3Zlbi53aXNvdHpreUBub2tpYS5jb20iPnN2ZW4ud2lzb3R6a3lAbm9raWEuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkRFIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlcmUgd2FzIHNvbWUgZGlzY3Vzc2lvbiBpbiBlYXJs aWVyIGRheXMgKGJhY2sgaW4gMjAxMi8yMDE0KSB0byBzdXBwb3J0IHBhZ2luZyBmb3IgZXh0cmEt bG9uZyBsaXN0cy4gVGhlIG1haW4gdXNlLWNhc2UgaXMgY2xlYXJseSB0byBpbXByb3ZlDQogc3Vw cG9ydCBmb3IgaW50ZXJhY3RpdmUgdXNlci1mcm9udGVuZHMsIGFzIGxvYWRpbmcgZW50aXJlIGxp c3RzIHdpdGggcG90ZW50aWFsbHkgbW9yZSB0aGFuIDEwMC4wMDDigJlzIG9iamVjdHMgZWFzaWx5 IGNhbiBiZWNvbWUgYSBuaWdodG1hcmU6IGxvYWRpbmcgdGltZSwgbWVtb3J5IGNvbnN1bXB0aW9u LCBjcmFzaGVzLCDigKY8L3NwYW4+PHNwYW4gbGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5zcGVh a2luZyBmcm9tIGV4cGVyaWVuY2UsIFJFU1RDT05GIGlzIHZlcnkgdXNhYmxlIHN0cmFpZ2h0IGZy b20gaW50ZXJhY3RpdmUgdXNlci1mcm9udGVuZHMgYW5kIHRoaXMgaXMgb25lIG9mIHRoZSBrZXkg dGhpbmdzIG1pc3NpbmcuJm5ic3A7IEkgZGlkIGFkZCBhIGN1c3RvbSBwYXJhbWV0ZXIgdG8gRnJl ZUNPTkYncyBSRVNUQ09ORiBpbXBsZW1lbnRhdGlvbiB0byBzdXBwb3J0IHRoaXMuJm5ic3A7DQog TWF5YmUgSSB0b29rIHRoaXMgdG9vayBmYXIsIGJ1dCBJIGRlY2lkZWQgdGhhdCBiZWNhdXNlIGRh dGEgaXMgaW4gYSBoaWVyYXJjaHkgeW91IG1pZ2h0IGhhdmUgbXVsdGlwbGUgbGlzdHMgeW91IG5l ZWQgdG8gcGFnZSB0aHJ1IHNvIEkgY2FtZSB1cCB0aGlzIHRoaXMgcGFyYW1ldGVyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazti YWNrZ3JvdW5kOiNGOUY5RjkiPiZuYnNwOyAmbmJzcDtyYW5nZT1iL2MhTi1NPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI1MjUyNSI+cmV0dXJucyByb3dzIE4gdGhydSBNIGluY2x1 c2l2ZSBpbiBsaXN0IHVuZGVyIHBhdGggYi9jLiZuYnNwOyBBbmQgdGhhdCB5b3UgY2FuIHNwZWNp ZnkgbXVsdGlwbGUgcmFuZ2VzIGZvciBtdWx0aXBsZSBwYXRocy4mbmJzcDsmbmJzcDtGcm9udCBl bmRzIHVzdWFsbHkgaGF2ZSBubyBwcm9ibGVtDQogcmVtZW1iZXJpbmcgd2hhdCBudW1iZXIgdGhl eSBhcmUgb24gdG8gdHJhY2sgTiBhbmQgTS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMjUyNTI1Ij5BcyBicm91Z2h0LXVwLCBmb3IgbGlzdHMgdGhhdCBhcmUgaGlnaGx5IGR5bmFt aWMsIHRoaXMgc3RyYXRlZ3kgaXMgYml0IG5haXZlIGFuZCBtYXliZSBldGFncyBjYW4gaGVscCB0 aGUgY2xpZW50cyB0aGF0IG5lZWQgdG8ga25vdyB3aGVuIGxpc3QgaGFzIGNoYW5nZWQNCiBhbmQg dGhleSBtaWdodCBuZWVkIHRvIHN0YXJ0IG92ZXIuJm5ic3A7IEZvciBteSBiYWNrZW5kLCBJIGNv dWxkIHN0YXJ0IGl0ZXJhdGlvbiBhdCByb3cgTiB3aXRob3V0IGhhdmUgdG8gbWFuYWdlIGEgY3Vy c29yLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGRpZCBub3QgZm91bmQg YW55IGFjdGl2ZSBEUkFGVCBvciBSRkMgZm9yIHRoaXMuIFRoYXQgc2FpZCwgd2UgY2FuIHNlZSB2 YXJpb3VzIHZlbmRvcnMgaW1wbGVtZW50aW5nIHByb3ByaWV0YXJ5IHNvbHV0aW9ucyBmb3IgdGhp cyBpbg0KIHRoZWlyIFJFU1RDT05GIHN0YWNrcy4uPC9zcGFuPjxzcGFuIGxhbmc9IkRFIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+V291bGQgcmVhbGx5IGxpa2UgdG8gc2VlIGFu IElFVEYgZGVmaW5lZCBhcHByb2FjaCBmb3IgdGhpcywgdG8gYXZvaWQgbXVsdGktdmVuZG9yIGNs aWVudHMgbmVlZCB0byBkZWFsIHZhcmlvdXMgdmVuZG9ycyBpbXBsZW1lbnRhdGlvbnMuPC9zcGFu PjxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+JiM0MzsxPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+QWdyZWUgd2l0aCB5b3UuIEFjdHVhbGx5LCB0aGVyZSBhcmUgc29tZSBkaXNj dXNzaW9ucyBpbiB0aGlzIFdHLiBBbmQgdGhlcmUgaXMgYW4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2RyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1jb2xs ZWN0aW9uIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO3RleHQtZGVjb3JhdGlvbjpub25l Ij5leHBpcmVkPC9zcGFuPjwvYT4gZHJhZnQgdGhhdCB0cnkgdG8gYWRkcmVzcyB0aGVzZSBpc3N1 ZXMgKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNv bmYtcmVzdGNvbmYtY29sbGVjdGlvbi0wMCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1jb2xsZWN0aW9uLTAwPC9hPikuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SU1PLCB0aGVzZSBwcm9ibGVtcyBhbHNvIGV4aXN0IGluIE5FVENPTkYsIHRoZXJlZm9yZSwg YSBjb21tb24gc29sdXRpb24gaXMgcmVxdWlyZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5CZXN0IFJlZ2FyZHMhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LU1pY2hhZWw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E6BC9BBCBCACC246846FC685F9FF41EA2D9703A5DGGEMM527MBXchi_-- From nobody Fri Mar 15 01:48:10 2019 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 24CA81311EC for ; Fri, 15 Mar 2019 01:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBrsh5Fvk6PG for ; Fri, 15 Mar 2019 01:48:05 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70128.outbound.protection.outlook.com [40.107.7.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA22212797C for ; Fri, 15 Mar 2019 01:48:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kUjRSRSK01pYBUKlDWNlrHY0jPYMNRdlrPqJkQpakmg=; b=PMOaYZmZjkG3BvJAF1F8CtkmdUAa43JhM/dOkz6BtOHHhKMIn3X9vpq3hSM3uRMU5l4NhidVGQe4fWCUbQHQkNw4ZdcSAAH+Rv3iDLl1JPA2jdLnn0aaP3/Xs3gtYOSzTnxLHAJcv4XCuZuR58vwnHaOWAptIqOGC+5NAl/xEbo= Received: from AM6PR07MB5382.eurprd07.prod.outlook.com (20.178.91.74) by AM6PR07MB3957.eurprd07.prod.outlook.com (52.134.116.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.6; Fri, 15 Mar 2019 08:48:01 +0000 Received: from AM6PR07MB5382.eurprd07.prod.outlook.com ([fe80::b093:11dd:7567:2100]) by AM6PR07MB5382.eurprd07.prod.outlook.com ([fe80::b093:11dd:7567:2100%4]) with mapi id 15.20.1730.003; Fri, 15 Mar 2019 08:48:01 +0000 From: "Wisotzky, Sven (Nokia - DE/Stuttgart)" To: wangzitao , Douglas Hubler CC: "netconf@ietf.org" Thread-Topic: [netconf] Current activities on RESTCONF/NETCONF to support paging Thread-Index: AdTa0NoVunCd1tZJRWC3RA+1mlX0vQAQ1NuA Date: Fri, 15 Mar 2019 08:48:01 +0000 Message-ID: <78942E33-29B9-4A00-829A-9667854BAF56@nokia.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.0.190309 x-originating-ip: [94.219.217.253] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e57be375-8df9-4696-8322-08d6a922eea1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR07MB3957; x-ms-traffictypediagnostic: AM6PR07MB3957: x-ms-exchange-purlcount: 2 authentication-results: spf=none (sender IP is ) smtp.mailfrom=sven.wisotzky@nokia.com; x-microsoft-antispam-prvs: x-forefront-prvs: 09778E995A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(396003)(366004)(39860400002)(346002)(376002)(136003)(189003)(199004)(26005)(6306002)(6512007)(106356001)(25786009)(6486002)(316002)(99286004)(446003)(97736004)(5660300002)(305945005)(110136005)(82746002)(186003)(58126008)(11346002)(2616005)(6506007)(8676002)(76176011)(102836004)(81166006)(81156014)(8936002)(7736002)(476003)(68736007)(486006)(36756003)(66066001)(966005)(6246003)(4326008)(33656002)(256004)(14444005)(229853002)(478600001)(2906002)(86362001)(14454004)(53936002)(6116002)(3846002)(83716004)(71200400001)(4744005)(71190400001)(6436002)(105586002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB3957; H:AM6PR07MB5382.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: lFB4OpfYwsgJThlQHtk4GG6PsR+VD7q1iEn3uWL4k2oGuqgoOh7mS6u3vN8p+EEK0PrPDt/36CqQ+mSR4SKZUPTkuvkX2hvY25BtssFT3eO6W5SaT/nkLgdfRqR9vlHOw6FQjRkBCJYDAENzOQlpDzd0x+/InUf3uHYruep8UTsr0ZmaM70f/Wjcyt8wUIG8OTrZTPLf8zbdKOcTCYeDcVT7ABI+WithJepmgu2GPmA0mlJyqiRpLs9xAQfrfeKyRi7mdRcdY85QRqtc1UlYs7irzjXJNyASB4MsVi86CT0oAedTvNXYbmoaPA8kRyim/+/JWCgfCY1IU5wIhOyGGNl3lZNclviQJxwoGJOrtYUdrjEOVr+J7D0X8feXflIpLkpTz/Otk0Q8etfBI457WWjFHyz7JDIQt9o728SDubM= Content-Type: text/plain; charset="utf-8" Content-ID: <8B778CDE6F6C8C4887F6406F8EFDBCE7@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: e57be375-8df9-4696-8322-08d6a922eea1 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2019 08:48:01.5567 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB3957 Archived-At: Subject: Re: [netconf] Current activities on RESTCONF/NETCONF to support paging 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, 15 Mar 2019 08:48:08 -0000 PiBBY3R1YWxseSwgdGhlcmUgYXJlIHNvbWUgZGlzY3Vzc2lvbnMgaW4gdGhpcyBXRy4gQW5kIHRo ZXJlIGlzIGFuIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2RyYWZ0LWlldGYt bmV0Y29uZi1yZXN0Y29uZi1jb2xsZWN0aW9uIGRyYWZ0IHRoYXQgdHJ5IHRvIGFkZHJlc3MgdGhl c2UgaXNzdWVzIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25m LXJlc3Rjb25mLWNvbGxlY3Rpb24tMDApLiBJTU8sIHRoZXNlIHByb2JsZW1zIGFsc28gZXhpc3Qg aW4gTkVUQ09ORiwgdGhlcmVmb3JlLCBhIGNvbW1vbiBzb2x1dGlvbiBpcyByZXF1aXJlZC4gDQrC oA0KSXQgc2hvdWxkIGhhdmUgYmVlbiBjbGVhciBmcm9tIG15IGluaXRpYWwgYXNrLiBZZXMsIEkg YW0gYWN0dWFsbHkgaW50ZXJlc3RlZCBpbiBhIHNvbHV0aW9uIHdoaWNoIHNlcnZlcyBib3RoIE5F VENPTkYgYW5kIFJFU1RDT05GLiBUaGUgcHJvYmxlbSBtaWdodCBiZSBzZWVuIG1vcmUgaW1wb3J0 YW50IGZvciBSRVNUQ09ORiAtIGFzIHRoaXMgaXMgY29uc2lkZXJlZCBwcm90b2NvbCBvZiBjaG9p Y2UgZm9yIG5ldHdvcmsgY29udHJvbGxlcnMsIHRhbGtpbmcgYWJvdXQgYSBsYXJnZXIgc2NhbGUg b2Ygb2JqZWN0cyBhbmQgdHJhZGl0aW9uYWxseSB1c2VkIGZvciBjb21tdW5pY2F0aW9uIGJldHdl ZW4gV2ViVUkgYW5kIGJhY2stZW5kLg0KDQpUaGUgYmlnZ2VyIGNoYWxsZW5nZSByZWdhcmRpbmcg TkVUQ09ORiBpcywgdGhhdCBuZXR3b3JraW5nIGRldmljZXMgYXJlIG9mdGVuIG1vcmUgcmVzdHJp Y3RlZCByZWdhcmRpbmcgbWFuYWdlbWVudCBwbGFuZSBmb290cHJpbnQgKENQVS9NZW1vcnkpLiBT byB3aGF0ZXZlciBzb2x1dGlvbiB3ZSBjb21lIHVwIHdpdGgsIGl0IG11c3QgYmUgZWFzeSB0byBp bXBsZW1lbnQgd2l0aG91dCByZXF1aXJpbmcgbGFyZ2Ugc2VydmVyLXNpZGUgZm9vdHByaW50Lg0K DQpTdmVuIA0KDQo= From nobody Fri Mar 15 03:59:35 2019 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 576F31286CD for ; Fri, 15 Mar 2019 03:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.247 X-Spam-Level: X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 opfmn5EmAEjb for ; Fri, 15 Mar 2019 03:59:30 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50109.outbound.protection.outlook.com [40.107.5.109]) (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 ACEE41311F2 for ; Fri, 15 Mar 2019 03:59:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oe3pZjaf30+wxwKFYmpvilcPYUVZdFSJ8Kmj9ddQlq8=; b=TkOzU9Dql+xLaBAocf8mbxmzItplhryYx9vzPFA6j6I2aAcnjG+wVVow4JCMCKWxRjGeJEb8sslTNuw2TjZGO3DZRwKnWVuFmL9hQtOXATUGmRcGz5B/oOqLKpK/VnNRWO79jqLbcQ6f/Ii6E05mnvewmv8kGIySQkHy1Zw/RzI= Received: from VI1PR07MB4768.eurprd07.prod.outlook.com (20.177.57.155) by VI1PR07MB4477.eurprd07.prod.outlook.com (20.177.57.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.7; Fri, 15 Mar 2019 10:59:26 +0000 Received: from VI1PR07MB4768.eurprd07.prod.outlook.com ([fe80::f4b6:8b99:765a:92e2]) by VI1PR07MB4768.eurprd07.prod.outlook.com ([fe80::f4b6:8b99:765a:92e2%4]) with mapi id 15.20.1730.003; Fri, 15 Mar 2019 10:59:26 +0000 From: tom petch To: "netconf@ietf.org" Thread-Topic: I-D Action: draft-thaler-iftype-reg-01.txt Thread-Index: AQHU2x4o8jg1/iD4HE6Tx/rYtHmRzw== Date: Fri, 15 Mar 2019 10:59:26 +0000 Message-ID: <01c501d4db1d$d5790640$4001a8c0@gateway.2wire.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0124.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9f::16) To VI1PR07MB4768.eurprd07.prod.outlook.com (2603:10a6:803:76::27) x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.156.84.54] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b28844c5-1de9-41cb-416f-08d6a9354a39 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB4477; x-ms-traffictypediagnostic: VI1PR07MB4477: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-forefront-prvs: 09778E995A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(396003)(366004)(346002)(136003)(13464003)(199004)(189003)(106356001)(316002)(71190400001)(2473003)(6512007)(8936002)(62236002)(26005)(9686003)(44716002)(97736004)(2906002)(2501003)(6306002)(186003)(71200400001)(2351001)(5660300002)(7736002)(6916009)(105586002)(14496001)(53936002)(478600001)(61296003)(25786009)(84392002)(4720700003)(305945005)(229853002)(1730700003)(486006)(81156014)(6116002)(3846002)(66574012)(81816011)(102836004)(44736005)(68736007)(6486002)(86152003)(81686011)(386003)(476003)(66066001)(52116002)(6436002)(99286004)(966005)(1556002)(8676002)(6346003)(256004)(86362001)(14454004)(50226002)(5640700003)(81166006)(6506007)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4477; H:VI1PR07MB4768.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: XOmAdYm5QsUbLJO0qAm+Z8tvkGFU6IuSM9XTtUIPhfZCNggTLVVj3PiPh093ixaNkAXeXJeyY21j/DwDIXxBqHzTt0QB2ZX5Gc8TvWhdn1CaGKfrk2t0dDnchOg7DHi2X57UZ31xOy08NyIkdA7BfCjwEwUPCgCuX1c80m8q/1NgzxnqIjAWQxuZx27ztu6lsQRTfAPn7rx8fIvEDvjWDQoHjnBMe9p/SFIdc/uvPXTZgrAP47EWdBEUPNfCHbLwkpFbk1kbgf7JKlbt4FvqekIe6AIEbwcYr9WowWHRsqKYeW31xnjUmYK3wofyoESHGav2Vli9xUNlX9a18Olc+w4AzBs0x9tFpKHjXCiCQ4yzN82Uwr5xC5kmBv7juqZ7b1D0/lj3WDKhRdy8eLadKkdrozbqUFIm6s0ErR76jXQ= Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: b28844c5-1de9-41cb-416f-08d6a9354a39 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2019 10:59:26.8694 (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-Transport-CrossTenantHeadersStamped: VI1PR07MB4477 Archived-At: Subject: [netconf] Fw: I-D Action: draft-thaler-iftype-reg-01.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: Fri, 15 Mar 2019 10:59:32 -0000 Anyone know where this is being discussed? Tom Petch ----- Original Message ----- From: To: Sent: Tuesday, March 05, 2019 8:50 PM > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Guidelines and Registration Procedures for Interface Types > Authors : David Thaler > Dan Romascanu > Filename : draft-thaler-iftype-reg-01.txt > Pages : 9 > Date : 2019-03-05 > > Abstract: > The registration and use of interface types ("ifType" values) > predated the use of IANA Considerations sections and YANG modules, > and so confusion has arisen about the interface type allocation > process. This document provides updated guidelines for the > definition of new interface types, for consideration by those who are > defining, registering, or evaluating those definitions. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-thaler-iftype-reg/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-thaler-iftype-reg-01 > https://datatracker.ietf.org/doc/html/draft-thaler-iftype-reg-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-thaler-iftype-reg-01 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Mar 15 07:13:08 2019 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 DB6CC130D7A for ; Fri, 15 Mar 2019 07:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk 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 iHErxXBEOeZe for ; Fri, 15 Mar 2019 07:13:04 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1982D12B003 for ; Fri, 15 Mar 2019 07:13:03 -0700 (PDT) Received: from nitebug.nitenet.local (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id D71F424249F; Fri, 15 Mar 2019 15:13:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1552659180; bh=QCMA1QlEQbaZQBwIalgsvm9Q4ExQF5get5fUSZB3m3E=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=aw7tiYlzH1qnZCB7Y66BolR1dhOm+BUHAdORLSICmq5hiZxfLewWdeE8ENoHYZWHW Y/svxiGqMzA9AWUApVvLP/sNMDTE/UtCdSpQ6HBcPuEMjQ0SaMgI6gNdRgw3A6FZli Yu8VMbsmUvqXPRPOhjyg8dfWD1rUn5MMm2KBRFYA= To: "Wisotzky, Sven (Nokia - DE/Stuttgart)" , wangzitao , Douglas Hubler Cc: "netconf@ietf.org" References: <78942E33-29B9-4A00-829A-9667854BAF56@nokia.com> From: Robert Varga Openpgp: preference=signencrypt Message-ID: Date: Fri, 15 Mar 2019 15:12:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <78942E33-29B9-4A00-829A-9667854BAF56@nokia.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uqCLyWUSV0t4pfyk7QlvXiPrh4fUKgdt6" Archived-At: Subject: Re: [netconf] Current activities on RESTCONF/NETCONF to support paging 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, 15 Mar 2019 14:13:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uqCLyWUSV0t4pfyk7QlvXiPrh4fUKgdt6 Content-Type: multipart/mixed; boundary="E3dXFMNnTNw57TJ1EE9yT78B3r3btDSbU"; protected-headers="v1" From: Robert Varga To: "Wisotzky, Sven (Nokia - DE/Stuttgart)" , wangzitao , Douglas Hubler Cc: "netconf@ietf.org" Message-ID: Subject: Re: [netconf] Current activities on RESTCONF/NETCONF to support paging References: <78942E33-29B9-4A00-829A-9667854BAF56@nokia.com> In-Reply-To: <78942E33-29B9-4A00-829A-9667854BAF56@nokia.com> --E3dXFMNnTNw57TJ1EE9yT78B3r3btDSbU Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 15/03/2019 09:48, Wisotzky, Sven (Nokia - DE/Stuttgart) wrote: >> Actually, there are some discussions in this WG. And there is an https= ://datatracker.ietf.org/drafts/draft-ietf-netconf-restconf-collection dra= ft that try to address these issues (https://tools.ietf.org/html/draft-ie= tf-netconf-restconf-collection-00). IMO, these problems also exist in NET= CONF, therefore, a common solution is required.=20 > =C2=A0 > It should have been clear from my initial ask. Yes, I am actually inter= ested in a solution which serves both NETCONF and RESTCONF. The problem m= ight be seen more important for RESTCONF - as this is considered protocol= of choice for network controllers, talking about a larger scale of objec= ts and traditionally used for communication between WebUI and back-end. That is a valid point, but I think this would end up creating a protocol on top of RESTCONF, where start of iteration/pagination would create some session state on the server. I do not want to explode the scope of work, but wouldn't WebUI users be better served with a general XPath-based query facility (for example allowing filter on GETs)? Alternatively, could the problem perhaps be reformulated in terms of draft-ietf-netconf-yang-push? Regards, Robert --E3dXFMNnTNw57TJ1EE9yT78B3r3btDSbU-- --uqCLyWUSV0t4pfyk7QlvXiPrh4fUKgdt6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQI/BAEBCgApFiEEdj+N7pgGP1gKvbdQJKB0S2uuNdsFAlyLsuYLHG5pdGVAaHEu c2sACgkQJKB0S2uuNdsCaQ//UlMoqfgcSqfglirdjCVJtYHqAd0dNiHz+I+7AL2I mJRkahBrX5Y79Jb2xyyxb14qC0WTZc407bVc3W3fcE6BmzekNotEZfBAAbzfKlco MK1nLrmcqN5VZw7GrRDwjXnTqEn5FxMUscgzwStHKjjcymaqqKEN/6ItKfxVZ+Qb DIZ0Bg0NJELmVc0qL7MMGET1qlMDdOS7JJwEQ7k3VZ7x4NWtPyfV5Y6+zS+xZZVt t6/ijmsxqbbMe1QrDBhhp5vqpZPNslcoRBpY8BSPpfFCRbZ2lpL3loQwqsGLjspK F4GCwtiDQibv9uwSE2V6vi5VdqCN3Y1hguJuqoedaqiuivjykhe3uoUCwJeuUY1Y /s+Vt0CRPlmlOUB1ADaF4SBMGUQR8906mvb/hurnKo8gvINkRuxY3uFeZSDGsc4l exWkyYxMBhBx15XCIgJLwUC3P8BHshk1ZUMWxnRyAZidRA2EzvOVcq/A2++9oG5M IlXYZMKRnx30IM887W6BAv1d5OPpSdkHlx8CcijJ1VgO7mRgVz7XfFfXlGQpHGT/ +GeU+e2UjpPSKSp/+2X/y3zc/Y9JEzlvhZzqHy/AqFgsOyyrI1fjeOznA9byeHSA 6xRYFIomPWWUVfFkimNPrv15ZAnIiV0HfsNjKKFuy/Knn2k4mCccAbz578ubNfri kSU= =w4Sn -----END PGP SIGNATURE----- --uqCLyWUSV0t4pfyk7QlvXiPrh4fUKgdt6-- From nobody Fri Mar 15 07:51:28 2019 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 7F001131281 for ; Fri, 15 Mar 2019 07:51: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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hNeExEJORd2 for ; Fri, 15 Mar 2019 07:51:21 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50116.outbound.protection.outlook.com [40.107.5.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FB0F131273 for ; Fri, 15 Mar 2019 07:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Leie06su3+GlGkVsZJ0ALGFG4mg4BQACyp/E2JPjjng=; b=MJZ6SBY0hgHOuc49FhRtcAB06J63SdTzASOY51Rzg8tbvgzw8l0Xk3hQ/TgMv5JTlSyDUygZN59n9DykbJVFJaD9TaMfvSL6Z3T2Lc1Gb+o3PfWv6ddrBnulm/Ql72HnpZs2X+ENzw7rdqI9IF+BXIfOZfR3GGsFjF/vwzVhdcw= Received: from AM6PR07MB5382.eurprd07.prod.outlook.com (20.178.91.74) by AM6PR07MB5911.eurprd07.prod.outlook.com (20.178.88.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.6; Fri, 15 Mar 2019 14:51:13 +0000 Received: from AM6PR07MB5382.eurprd07.prod.outlook.com ([fe80::b093:11dd:7567:2100]) by AM6PR07MB5382.eurprd07.prod.outlook.com ([fe80::b093:11dd:7567:2100%4]) with mapi id 15.20.1730.003; Fri, 15 Mar 2019 14:51:13 +0000 From: "Wisotzky, Sven (Nokia - DE/Stuttgart)" To: Robert Varga , wangzitao , Douglas Hubler CC: "netconf@ietf.org" Thread-Topic: [netconf] Current activities on RESTCONF/NETCONF to support paging Thread-Index: AdTa0NoVunCd1tZJRWC3RA+1mlX0vQAQ1NuAAAlAPgAAA28FgA== Date: Fri, 15 Mar 2019 14:51:13 +0000 Message-ID: References: <78942E33-29B9-4A00-829A-9667854BAF56@nokia.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.0.190309 x-originating-ip: [94.219.217.253] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e6030155-7885-4ad5-450c-08d6a955aba7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR07MB5911; x-ms-traffictypediagnostic: AM6PR07MB5911: x-ms-exchange-purlcount: 2 authentication-results: spf=none (sender IP is ) smtp.mailfrom=sven.wisotzky@nokia.com; x-microsoft-antispam-prvs: x-forefront-prvs: 09778E995A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(396003)(346002)(136003)(366004)(199004)(189003)(71190400001)(5660300002)(305945005)(36756003)(966005)(6306002)(8936002)(6512007)(14454004)(68736007)(7736002)(4326008)(81156014)(71200400001)(8676002)(53936002)(2906002)(83716004)(110136005)(6116002)(229853002)(99286004)(58126008)(316002)(66066001)(6246003)(3846002)(82746002)(14444005)(6506007)(33656002)(11346002)(561944003)(256004)(476003)(2616005)(76176011)(97736004)(81166006)(6486002)(106356001)(105586002)(446003)(25786009)(478600001)(6436002)(102836004)(86362001)(186003)(53546011)(486006)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB5911; H:AM6PR07MB5382.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: X8aM7f+sLYJYqBD1o4FYfaEyHLdkZEcReduZRFYVnX2S8FBM3ZwhDLksOUcty0P+apGJK8vJDZKRitlTOthYftbGvYRgt1KvSiByq0c5ABkMMcSlyC+dCd6a8Ea6kwsSq0mo4QkNDTxcGGzXHgl/1HxTEbWHq/JXkhgWOKMQWhj5ExSOORqOGWz7AyBCV6mTaZva9t+XPnysEY25aD4425p/2SZQBkkazfZKFS/ZWKjHtCVRf8wwa4VuPch52dxtlDZk9WLGBQTCksc+BR6Eo7p4tZCvmEL9EqdmYLuQvbj6F3o8c7NA4nVnTKe3xpa7y99UdXLIjaDq/X3vOHW6unrVMNrtgul+tRQXqVhOk8fzO1RIDCtRNjwewtL/UdpaVyD3uF++rU/ZwrLpzlAfnaomx8q7sHbN/Yao6y2qOwM= Content-Type: text/plain; charset="utf-8" Content-ID: <2BDC04B08B9118488066DBA667450B44@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: e6030155-7885-4ad5-450c-08d6a955aba7 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2019 14:51:13.5613 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5911 Archived-At: Subject: Re: [netconf] Current activities on RESTCONF/NETCONF to support paging X-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, 15 Mar 2019 14:51:26 -0000 Um9iZXJ0LA0KDQpJIHdvdWxkIGJlIG9rYXkgd2l0aCB0aGUgbGltaXQvb2Zmc2V0IGF0dHJpYnV0 ZXMgc3VnZ2VzdGVkIGluIGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1jb2xsZWN0aW9uLTAw LiBTbyB0aGlzIHdvdWxkIGJhc2ljYWxseSBhdm9pZCBhbnkgc2Vzc2lvbiBzdGF0ZSBvbiB0aGUg c2VydmVyLiBJIGRvIGFncmVlLCB0aGF0IHN1Y2ggYXBwcm9hY2ggY29tZXMgYXQgdGhlIGNhdmVh dCB0aGF0IHRhYmxlcyBtaWdodCBkeW5hbWljYWxseSBjaGFuZ2Ugd2hpbGUgb25lIGlzIHJlcXVl c3RpbmcgZm9sbG93LXVwIHBhZ2VzLiBCdXQgd2l0aCBhbGwgZmFpcm5lc3MsIHRoaXMgaXMgbm90 IGV2ZW4gZ3VhcmFudGVlZCB3aXRoIHRyYWRpdGlvbmFsIE5FVENPTkYgZ2V0IC8gZ2V0LWNvbmZp ZyB0b2RheSAtIGdpdmVuIGV4aXN0aW5nIHZlbmRvcidzIGltcGxlbWVudGF0aW9ucy4NCg0KSXMg eW91ciBzdWdnZXN0aW9uIGFyb3VuZCBYUEFUSCwgdGhhdCB0aGUgV2ViVUkgd291bGQgYXV0b21h dGljYWxseSByZW5kZXIgc21hcnQgc2VsZWN0aW9uIGZpbHRlcnMgc3VjaCBhczoNCi8vZm9vL2Jh clsxMDAgPD0gcG9zaXRpb24oKSBhbmQgcG9zaXRpb24oKSA8IDIwMF0NCnN1YnNlcXVlbmNlKCAv Zm9vL2JhciwgMTAwLCAxMDAgKQ0KDQpJIGRvIGFncmVlLCB0aGF0IHRoaXMgY2VydGFpbmx5IHdv dWxkIHNlcnZlIGl0cyBwdXJwb3NlLCBkZXBlbmRpbmcgb24gdGhlIHN1cHBvcnQgb2YgWFBBVEgg aW5jbHVkaW5nIHRoZSBwb3NpdGlvbi9zdWJzZXF1ZW5jZSBmdW5jdGlvbnMuIEJ1dCB3b3VsZCBi ZSBjb25jZXJuZWQgd291bGQgYmUgdGhpcyBkZXBlbmRlbmN5LiBOb3QgcmVhbGx5IHN1cmUsIGhv dyBtYW55IHZlbmRvcnMgZG8gcmVhbGx5IGhhdmUgZnVsbCBmaWx0ZXIveHBhdGggc3VwcG9ydCB0 b2RheSBpbiB0aGVpciBORVRDT05GL1JFU1RDT05GIHN0YWNrcyAtIGF0IGxlYXN0IEkgZG8gbm90 IHJlbWluZCBhbnkuIEFsc28gSSBjb3VsZCBub3QgdGhpbmsgb2YgYW4gZWZmaWNpZW50IGltcGxl bWVudGF0aW9uIG9mIHRoaXMuIExpa2VseSBvbmUgd291bGQgcmVuZGVyIHRoZSBmdWxsIFhNTCBk b2N1bWVudCBhbmQgYWZ0ZXIgdGhpcyBhcHBseWluZyB0aGUgWFBBVEggcXVlcnkuIEFzIHdlIGFy ZSBzcGVha2luZyBoZXJlIGFib3V0IGV4dHJhLWxhcmdlIHRhYmxlcyAtIHRoZSByYXcgWE1MIGRv Y3VtZW50IGNvdWxkIGVhc2lseSBoYXZlIDEwMC4wMDAncyBvZiBlbnRyaWVzIGFrYSAxMDAncyBv ZiBNYnl0ZXMuIE5vdCByZWFsbHkgc3VyZSBhYm91dCB0aGUgcGVyZm9ybWFuY2UgaW1wYWN0IGFu ZCBmb290cHJpbnQgb2Ygc3VjaCBzb2x1dGlvbiAtIGJ1dCBkb3VidCB0aGlzIGlzIHRoZSByaWdo dCB3YXkgb2YgZG9pbmcgaXQuDQoNCkkgZ3Vlc3MgeW91ciBvdGhlciBwcm9wb3NhbCBhYm91dCBZ QU5HIFBVU0ggd291bGQgYmUgYWxtb3N0IGluIHRoZSBsaW5lcyBvZiBnTk1JIE9OQ0Ugc3Vic2Ny aXB0aW9uLiBOb3Qgc3VyZSBhYm91dCBhYm91dCBhbGwgdGhlIGltcGxpY2F0aW9ucyBvZiB0aGlz Lg0KDQovd2lzbw0KDQoNCg0K77u/T24gMTUuMDMuMTksIDE1OjEzLCAiUm9iZXJ0IFZhcmdhIiA8 bml0ZUBocS5zaz4gd3JvdGU6DQoNCiAgICBPbiAxNS8wMy8yMDE5IDA5OjQ4LCBXaXNvdHpreSwg U3ZlbiAoTm9raWEgLSBERS9TdHV0dGdhcnQpIHdyb3RlOg0KICAgID4+IEFjdHVhbGx5LCB0aGVy ZSBhcmUgc29tZSBkaXNjdXNzaW9ucyBpbiB0aGlzIFdHLiBBbmQgdGhlcmUgaXMgYW4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25m LWNvbGxlY3Rpb24gZHJhZnQgdGhhdCB0cnkgdG8gYWRkcmVzcyB0aGVzZSBpc3N1ZXMgKGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtY29sbGVj dGlvbi0wMCkuIElNTywgdGhlc2UgcHJvYmxlbXMgYWxzbyBleGlzdCBpbiBORVRDT05GLCB0aGVy ZWZvcmUsIGEgY29tbW9uIHNvbHV0aW9uIGlzIHJlcXVpcmVkLiANCiAgICA+ICANCiAgICA+IEl0 IHNob3VsZCBoYXZlIGJlZW4gY2xlYXIgZnJvbSBteSBpbml0aWFsIGFzay4gWWVzLCBJIGFtIGFj dHVhbGx5IGludGVyZXN0ZWQgaW4gYSBzb2x1dGlvbiB3aGljaCBzZXJ2ZXMgYm90aCBORVRDT05G IGFuZCBSRVNUQ09ORi4gVGhlIHByb2JsZW0gbWlnaHQgYmUgc2VlbiBtb3JlIGltcG9ydGFudCBm b3IgUkVTVENPTkYgLSBhcyB0aGlzIGlzIGNvbnNpZGVyZWQgcHJvdG9jb2wgb2YgY2hvaWNlIGZv ciBuZXR3b3JrIGNvbnRyb2xsZXJzLCB0YWxraW5nIGFib3V0IGEgbGFyZ2VyIHNjYWxlIG9mIG9i amVjdHMgYW5kIHRyYWRpdGlvbmFsbHkgdXNlZCBmb3IgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIFdl YlVJIGFuZCBiYWNrLWVuZC4NCiAgICANCiAgICBUaGF0IGlzIGEgdmFsaWQgcG9pbnQsIGJ1dCBJ IHRoaW5rIHRoaXMgd291bGQgZW5kIHVwIGNyZWF0aW5nIGEgcHJvdG9jb2wNCiAgICBvbiB0b3Ag b2YgUkVTVENPTkYsIHdoZXJlIHN0YXJ0IG9mIGl0ZXJhdGlvbi9wYWdpbmF0aW9uIHdvdWxkIGNy ZWF0ZQ0KICAgIHNvbWUgc2Vzc2lvbiBzdGF0ZSBvbiB0aGUgc2VydmVyLg0KICAgIA0KICAgIEkg ZG8gbm90IHdhbnQgdG8gZXhwbG9kZSB0aGUgc2NvcGUgb2Ygd29yaywgYnV0IHdvdWxkbid0IFdl YlVJIHVzZXJzIGJlDQogICAgYmV0dGVyIHNlcnZlZCB3aXRoIGEgZ2VuZXJhbCBYUGF0aC1iYXNl ZCBxdWVyeSBmYWNpbGl0eSAoZm9yIGV4YW1wbGUNCiAgICBhbGxvd2luZyBmaWx0ZXIgb24gR0VU cyk/DQogICAgDQogICAgQWx0ZXJuYXRpdmVseSwgY291bGQgdGhlIHByb2JsZW0gcGVyaGFwcyBi ZSByZWZvcm11bGF0ZWQgaW4gdGVybXMgb2YNCiAgICBkcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1w dXNoPw0KICAgIA0KICAgIFJlZ2FyZHMsDQogICAgUm9iZXJ0DQogICAgDQogICAgDQoNCg== From nobody Sun Mar 17 13:39:45 2019 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 6614C12AF7B for ; Sun, 17 Mar 2019 13:39:43 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 t5Vi5w_Ein05 for ; Sun, 17 Mar 2019 13:39:40 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 B57471279AD for ; Sun, 17 Mar 2019 13:39:39 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id x9so8164665ljc.7 for ; Sun, 17 Mar 2019 13:39:39 -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=mjXs+ZkovtRssfG0bh/a6wnEcdtWNYKGoAogDyDOZnY=; b=YeofuCgSVofAFKLwz7FiYfe7MVgISpyoKGOQQxATWIusP0SEDw/MLsPjh/FR2Mu2Jk /G2iRCAABnP0wh6tjnhFGhu+OQYBos0frftsov1id8gp365bodg7HpOZxNhTYiXSm6qW Q3Noyd1Ikr1HZDDh4otSkBf/szkxI8CQpxFfaZU2v4XSCUBW7alLynXXdh/TdbNfL6MV 1Urtv1Vh83dTWQt5hfooCgMevveuTb6xkD6AQgFk0vchTgtnAW93ohQAyq2/i1SdVqUR ZgPlchmR8gqSAOC1oeoKMoco5PquQJ74ziv9pIJZV5DzcDWo3ejszOQH8H3Ddtyfv9km vRHQ== 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=mjXs+ZkovtRssfG0bh/a6wnEcdtWNYKGoAogDyDOZnY=; b=jRakzY4kPrnYox4Vdwp3rIGDxcv5PeNmFoiyOka1kMC8ba2KbS3nyLoOm2rDpHseq0 m7IbeasuaqDq7U4cj2rcC5EVLELDkYX0++5wIj+5AE5amqcaCapd2SQXA7GSAmQCccs9 DwvYmGfyA6T/PAxk6wLZfRopmnZQxcKvuZs5lDmF59JTBkKLSdsvJd4+GKZKc7rJ1jMz c78tyBt4vp00hWor1+0lbrCH1b6C2Bc4cRFeIsVvRXuwmPDtjKrXeONNklMQgcgY0ux7 Ie+wGfmfkpGj+AxbWxS3AMUqpg405VBZpm9fo7Q46u0UertIKyToGjU10HAb+K/Ss66J DB0Q== X-Gm-Message-State: APjAAAXy07rQfcejTwAO7pyCtR2Q28qOroqhMcItE6CUDPSSzMddlCk2 a5JIHOokasYLqyOwxQlaEI6aY6nvDvqnlaLgFM7gfg== X-Google-Smtp-Source: APXvYqz6/3ZpKoA0RVBlfS87MJHJopD4cbVgXoWQ+VHPG8n6W6YMM+YPTgsVzDFJ+W9WaePXbOyoGIXX/HIgCWs581U= X-Received: by 2002:a2e:9594:: with SMTP id w20mr8524927ljh.173.1552855177795; Sun, 17 Mar 2019 13:39:37 -0700 (PDT) MIME-Version: 1.0 References: <20190314093552.3pwa7ptrre4t2stk@anna.jacobs.jacobs-university.de> In-Reply-To: From: Andy Bierman Date: Sun, 17 Mar 2019 13:39:26 -0700 Message-ID: To: "Rob Wilton (rwilton)" Cc: Juergen Schoenwaelder , "Wisotzky, Sven (Nokia - DE/Stuttgart)" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="00000000000042c162058450459b" Archived-At: Subject: Re: [netconf] Current activities on RESTCONF/NETCONF to support paging 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: Sun, 17 Mar 2019 20:39:44 -0000 --00000000000042c162058450459b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 14, 2019 at 3:24 AM Rob Wilton (rwilton) wrote: > I agree that this would be a useful problem to solve. > > I also agree with Juergen that there will likely be consistency issues > depending on implementation, particularly if the data is coming from > . But I suspect that this issue already exists for many > non-trivial implementations (e.g. where the operational data is distribut= ed > to daemons, linecards, or remote slave devices). > > Requiring that a consistent view of the conventional configuration > datastores can be provided (without locking) might be a reasonable > compromise. > > This thread has already mentioned some of the reasons the RESTCONF Collections draft got shelved. 1) this is not a RESTCONF-specific problem, so a RESTCONF-specific solution will not solve the problem 2) there is no agreement on how much state a server should maintain during the "get-bulk walk". 3) some features like sorting require all data to be retrieved within the server and sorted, instead of streaming the data 4) position-based "get-next" is error-prone in dynamic operational state; it requires expensive locking in configuration I agree a standard solution would be beneficial to client developers, if all 4 issues could be solved Thanks, > Rob > > Andy > > -----Original Message----- > From: netconf On Behalf Of Juergen > Schoenwaelder > Sent: 14 March 2019 09:36 > To: Wisotzky, Sven (Nokia - DE/Stuttgart) > Cc: netconf@ietf.org > Subject: Re: [netconf] Current activities on RESTCONF/NETCONF to support > paging > > One of the issues to consider is that depending on the datastore accessed= , > the data can change more or less rapidly and it is unclear whether you wa= nt > servers to maintain potentially big amounts of state between requests. If > you retrieve data in chunks, the question is whether you can simply put t= he > data back together or the client side or whether this may lead to data th= at > never really existed in that form on the server. With RESTCONF, etags may > help to check whether the resource queried remains consistent (but then t= he > server still has to be able to decide etag changes). > > But backing up for this discussion of details, I agree that this is a > problem worth solving by standardizing a common solution. > > /js > > On Thu, Mar 14, 2019 at 09:23:53AM +0000, Wisotzky, Sven (Nokia - > DE/Stuttgart) wrote: > > All, > > > > There was some discussion in earlier days (back in 2012/2014) to > > support paging for extra-long lists. The main use-case is clearly to > > improve support for interactive user-frontends, as loading entire > > lists with potentially more than 100.000=E2=80=99s objects easily can b= ecome a > > nightmare: loading time, memory consumption, crashes, =E2=80=A6 > > > > For the sake of implementation, one would simply provide an attribute > called =E2=80=9Cmax-count=E2=80=9D, =E2=80=9Cmax-entries=E2=80=9D, =E2=80= =9Cmax-elements=E2=80=9D or =E2=80=9Climit=E2=80=9D =E2=80=93 which > basically defines the upper limit of list entries to be returned. Asking > for limit=3D10 =E2=80=93 even if the list contains a 100k the result woul= d simply > show 10. From an user-interface point of view, this might be enough =E2= =80=93 as > users would see how the list entries look like to narrow down the search = by > adding additional search/filter criteria. So to protect the client system > and improvements on loading time/memory consumptions =E2=80=93 this might= be just > enough. > > > > More advanced implementations might allow the NETCONF client to specify > the =E2=80=9Coffset=E2=80=9D which is basically the index of the first li= st entry to be > returned. In such case, the client could continue to load further pages o= n > customer demand (like dynamically while scrolling down the list or pressi= ng > on the next button). Even if people are not curious that much about memor= y > consumption, even it should be possible to continue loading the remaining > list in the background =E2=80=93 while showing the first X items faster o= n the > user-interfaces. > > > > To make such paging solution even more complete, following use-cases ar= e > to be reviewed from a RESTCONF/NETCONF API point of view: > > /1/ How to figure out the number of list entries matching the given > criteria for a given list, without the need to poll the entire list? This > could be helpful to operators straight away, but also allows easier > implementation for things like progress bars. > > /2/ Define a sorting criteria for search results /3/ Improve filtering > > capabilities for subtree filters (e.g. contains operator) > > > > I did not found any active DRAFT or RFC for this. That said, we can see > various vendors implementing proprietary solutions for this in their > RESTCONF stacks. > > Would really like to see an IETF defined approach for this, to avoid > multi-vendor clients need to deal various vendors implementations. > > > > /wiso > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --00000000000042c162058450459b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Mar 14, 2019 at 3:24 AM Rob W= ilton (rwilton) <rwilton@cisco.com<= /a>> wrote:
I= agree that this would be a useful problem to solve.

I also agree with Juergen that there will likely be consistency issues depe= nding on implementation, particularly if the data is coming from <operat= ional>.=C2=A0 But I suspect that this issue already exists for many non-= trivial implementations (e.g. where the operational data is distributed to = daemons, linecards, or remote slave devices).

Requiring that a consistent view of the conventional configuration datastor= es can be provided (without locking) might be a reasonable compromise.



<= /div>
=C2=A01) this is not a RESTCONF-specific problem, so a RESTCONF-s= pecific solution will not solve the problem
=C2=A02) there is no = agreement on how much state a server should maintain during the "get-b= ulk walk".=C2=A0
=C2=A03) some features like sorting require= all data to be retrieved within the server and sorted, instead of streamin= g the data
=C2=A04) position-based "get-next" is error-= prone in dynamic operational state; it requires expensive locking in config= uration

I agree a standard solution would be benef= icial to client developers, if all 4 issues could be solved

<= /div>

Thanks,
Rob


Andy

=C2=A0

-----Original Message-----
From: netconf <netconf-bounces@ietf.org> On Behalf Of Juergen Schoenwaelder Sent: 14 March 2019 09:36
To: Wisotzky, Sven (Nokia - DE/Stuttgart) <sven.wisotzky@nokia.com>
Cc: netconf@ietf.org<= /a>
Subject: Re: [netconf] Current activities on RESTCONF/NETCONF to support pa= ging

One of the issues to consider is that depending on the datastore accessed, = the data can change more or less rapidly and it is unclear whether you want= servers to maintain potentially big amounts of state between requests. If = you retrieve data in chunks, the question is whether you can simply put the= data back together or the client side or whether this may lead to data tha= t never really existed in that form on the server. With RESTCONF, etags may= help to check whether the resource queried remains consistent (but then th= e server still has to be able to decide etag changes).

But backing up for this discussion of details, I agree that this is a probl= em worth solving by standardizing a common solution.

/js

On Thu, Mar 14, 2019 at 09:23:53AM +0000, Wisotzky, Sven (Nokia - DE/Stuttg= art) wrote:
> All,
>
> There was some discussion in earlier days (back in 2012/2014) to
> support paging for extra-long lists. The main use-case is clearly to <= br> > improve support for interactive user-frontends, as loading entire
> lists with potentially more than 100.000=E2=80=99s objects easily can = become a
> nightmare: loading time, memory consumption, crashes, =E2=80=A6
>
> For the sake of implementation, one would simply provide an attribute = called =E2=80=9Cmax-count=E2=80=9D, =E2=80=9Cmax-entries=E2=80=9D, =E2=80= =9Cmax-elements=E2=80=9D or =E2=80=9Climit=E2=80=9D =E2=80=93 which basical= ly defines the upper limit of list entries to be returned. Asking for limit= =3D10 =E2=80=93 even if the list contains a 100k the result would simply sh= ow 10. From an user-interface point of view, this might be enough =E2=80=93= as users would see how the list entries look like to narrow down the searc= h by adding additional search/filter criteria. So to protect the client sys= tem and improvements on loading time/memory consumptions =E2=80=93 this mig= ht be just enough.
>
> More advanced implementations might allow the NETCONF client to specif= y the =E2=80=9Coffset=E2=80=9D which is basically the index of the first li= st entry to be returned. In such case, the client could continue to load fu= rther pages on customer demand (like dynamically while scrolling down the l= ist or pressing on the next button). Even if people are not curious that mu= ch about memory consumption, even it should be possible to continue loading= the remaining list in the background =E2=80=93 while showing the first X i= tems faster on the user-interfaces.
>
> To make such paging solution even more complete, following use-cases a= re to be reviewed from a RESTCONF/NETCONF API point of view:
> /1/ How to figure out the number of list entries matching the given cr= iteria for a given list, without the need to poll the entire list? This cou= ld be helpful to operators straight away, but also allows easier implementa= tion for things like progress bars.
> /2/ Define a sorting criteria for search results /3/ Improve filtering=
> capabilities for subtree filters (e.g. contains operator)
>
> I did not found any active DRAFT or RFC for this. That said, we can se= e various vendors implementing proprietary solutions for this in their REST= CONF stacks.
> Would really like to see an IETF defined approach for this, to avoid m= ulti-vendor clients need to deal various vendors implementations.
>
> /wiso

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

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--00000000000042c162058450459b-- From nobody Sun Mar 17 18:39:59 2019 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 276D7130F28 for ; Sun, 17 Mar 2019 18:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gqh1tCKfeSEz for ; Sun, 17 Mar 2019 18:39:55 -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 F2220130F20 for ; Sun, 17 Mar 2019 18:39:54 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id C4A4B303C66F4366D210 for ; Mon, 18 Mar 2019 01:39:52 +0000 (GMT) Received: from lhreml707-chm.china.huawei.com (10.201.108.56) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 18 Mar 2019 01:39:52 +0000 Received: from lhreml707-chm.china.huawei.com (10.201.108.56) by lhreml707-chm.china.huawei.com (10.201.108.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Mon, 18 Mar 2019 01:39:52 +0000 Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml707-chm.china.huawei.com (10.201.108.56) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Mon, 18 Mar 2019 01:39:52 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Mon, 18 Mar 2019 09:39:42 +0800 From: Qin Wu To: "Wisotzky, Sven (Nokia - DE/Stuttgart)" , wangzitao , Douglas Hubler CC: "netconf@ietf.org" Thread-Topic: [netconf] Current activities on RESTCONF/NETCONF to support paging Thread-Index: AdTdKqjdB7vGGWJfR4qgcU5/Okn5Fg== Date: Mon, 18 Mar 2019 01:39:41 +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.134.31.203] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Current activities on RESTCONF/NETCONF to support paging 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, 18 Mar 2019 01:39:57 -0000 LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBuZXRjb25mIFttYWlsdG86bmV0Y29u Zi1ib3VuY2VzQGlldGYub3JnXSDku6PooaggV2lzb3R6a3ksIFN2ZW4gKE5va2lhIC0gREUvU3R1 dHRnYXJ0KQ0K5Y+R6YCB5pe26Ze0OiAyMDE55bm0M+aciDE15pelIDE2OjQ4DQrmlLbku7bkuro6 IHdhbmd6aXRhbyA8d2FuZ3ppdGFvQGh1YXdlaS5jb20+OyBEb3VnbGFzIEh1YmxlciA8ZG91Z2xh c0BodWJsZXIudXM+DQrmioTpgIE6IG5ldGNvbmZAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtuZXRj b25mXSBDdXJyZW50IGFjdGl2aXRpZXMgb24gUkVTVENPTkYvTkVUQ09ORiB0byBzdXBwb3J0IHBh Z2luZw0KDQo+IEFjdHVhbGx5LCB0aGVyZSBhcmUgc29tZSBkaXNjdXNzaW9ucyBpbiB0aGlzIFdH LiBBbmQgdGhlcmUgaXMgYW4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvZHJh ZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLWNvbGxlY3Rpb24gZHJhZnQgdGhhdCB0cnkgdG8gYWRk cmVzcyB0aGVzZSBpc3N1ZXMgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW5ldGNvbmYtcmVzdGNvbmYtY29sbGVjdGlvbi0wMCkuIElNTywgdGhlc2UgcHJvYmxlbXMgYWxz byBleGlzdCBpbiBORVRDT05GLCB0aGVyZWZvcmUsIGEgY29tbW9uIHNvbHV0aW9uIGlzIHJlcXVp cmVkLiANCsKgDQpJdCBzaG91bGQgaGF2ZSBiZWVuIGNsZWFyIGZyb20gbXkgaW5pdGlhbCBhc2su IFllcywgSSBhbSBhY3R1YWxseSBpbnRlcmVzdGVkIGluIGEgc29sdXRpb24gd2hpY2ggc2VydmVz IGJvdGggTkVUQ09ORiBhbmQgUkVTVENPTkYuIFRoZSBwcm9ibGVtIG1pZ2h0IGJlIHNlZW4gbW9y ZSBpbXBvcnRhbnQgZm9yIFJFU1RDT05GIC0gYXMgdGhpcyBpcyBjb25zaWRlcmVkIHByb3RvY29s IG9mIGNob2ljZSBmb3IgbmV0d29yayBjb250cm9sbGVycywgdGFsa2luZyBhYm91dCBhIGxhcmdl ciBzY2FsZSBvZiBvYmplY3RzIGFuZCB0cmFkaXRpb25hbGx5IHVzZWQgZm9yIGNvbW11bmljYXRp b24gYmV0d2VlbiBXZWJVSSBhbmQgYmFjay1lbmQuDQoNClRoZSBiaWdnZXIgY2hhbGxlbmdlIHJl Z2FyZGluZyBORVRDT05GIGlzLCB0aGF0IG5ldHdvcmtpbmcgZGV2aWNlcyBhcmUgb2Z0ZW4gbW9y ZSByZXN0cmljdGVkIHJlZ2FyZGluZyBtYW5hZ2VtZW50IHBsYW5lIGZvb3RwcmludCAoQ1BVL01l bW9yeSkuIFNvIHdoYXRldmVyIHNvbHV0aW9uIHdlIGNvbWUgdXAgd2l0aCwgaXQgbXVzdCBiZSBl YXN5IHRvIGltcGxlbWVudCB3aXRob3V0IHJlcXVpcmluZyBsYXJnZSBzZXJ2ZXItc2lkZSBmb290 cHJpbnQuDQoNCltRaW5dOiBBZ3JlZSwgdGhlcmUgaXMgYW5vdGhlciByZWxldmFudCBkcmFmdCBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhlbmctbmV0Y29uZi1mcmFnbWVudGF0 aW9uLTAwDQp3aGljaCB0cnkgdG8gYWRkcmVzcyB0aGlzIGlzc3VlLiBCdXQgdGhlIGJpZyBjaGFs bGVuZ2UgaXMgbGFyZ2Ugc2l6ZSBkYXRhIGhhbmRsaW5nLCB3aGV0aGVyIGl0IHNob3VsZCBiZSBz dGF0ZWxlc3Mgb3Igc3RhdGVmdWwuIEhvdyBtdWNoIHN0YXRlIGRvZXMgYm90aCBzaWRlIG5lZWQg dG8ga2VlcD8NCg0KU3ZlbiANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCm5ldGNvbmYgbWFpbGluZyBsaXN0DQpuZXRjb25mQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg== From nobody Mon Mar 18 05:57:51 2019 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 03F9C127983 for ; Mon, 18 Mar 2019 05:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwkErAUFgI5q for ; Mon, 18 Mar 2019 05:57:47 -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 9716312797C for ; Mon, 18 Mar 2019 05:57:47 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D84DD6EABD01D3C6C66C; Mon, 18 Mar 2019 12:57:45 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 18 Mar 2019 12:57:45 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0415.000; Mon, 18 Mar 2019 20:57:40 +0800 From: Qin Wu To: tom petch , "Wisotzky, Sven (Nokia - DE/Stuttgart)" , Juergen Schoenwaelder CC: "netconf@ietf.org" Thread-Topic: [netconf] Current activities on RESTCONF/NETCONF to support paging Thread-Index: AdTdiVphQgOJn0z1RGyB3QijnnVcOw== Date: Mon, 18 Mar 2019 12:57:39 +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.134.31.203] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Current activities on RESTCONF/NETCONF to support paging 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, 18 Mar 2019 12:57:50 -0000 LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBuZXRjb25mIFttYWlsdG86bmV0Y29u Zi1ib3VuY2VzQGlldGYub3JnXSDku6PooaggdG9tIHBldGNoDQrlj5HpgIHml7bpl7Q6IDIwMTnl ubQz5pyIMTXml6UgMTowNw0K5pS25Lu25Lq6OiBXaXNvdHpreSwgU3ZlbiAoTm9raWEgLSBERS9T dHV0dGdhcnQpIDxzdmVuLndpc290emt5QG5va2lhLmNvbT47IEp1ZXJnZW4gU2Nob2Vud2FlbGRl ciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPg0K5oqE6YCBOiBuZXRjb25m QGlldGYub3JnDQrkuLvpopg6IFJlOiBbbmV0Y29uZl0gQ3VycmVudCBhY3Rpdml0aWVzIG9uIFJF U1RDT05GL05FVENPTkYgdG8gc3VwcG9ydCBwYWdpbmcNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLQ0KRnJvbTogIldpc290emt5LCBTdmVuIChOb2tpYSAtIERFL1N0dXR0Z2FydCkiIDxz dmVuLndpc290emt5QG5va2lhLmNvbT4NClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxNCwgMjAxOSAx MjoxNCBQTQ0KDQo+IERlcGVuZHMgb24gd2hhdGV2ZXIgd2UgY2FsbCBoZXJlIGEgY3Jhc2guIFRo ZSBjaGFsbGVuZ2luZyBwYXJ0IG9mDQpORVRDT05GL1JFU1RDT05GIGlzLCB0aGF0IHRoZSBjbGll bnQgd291bGQgbm90IGtub3cgaG93IGJpZyB0aGUgZ2V0L2dldC1jb25maWcgcmVwbHkgd291bGQg YmVjb21lLiBIYXZpbmcgYSBKUy1iYXNlZCBXZWJVSSBjbGllbnQgcnVubmluZyBhIFJFU1RDT05G IHF1ZXJ5LCB5b3UgZWFzaWx5IGVuZCB1cCBpbiBzaXR1YXRpb25zLCB3aGVyZSB5b3UgYmFzaWNh bGx5IG5lZWQgdG8gdGVybWluYXRlIHRoZSBqYXZhc2NyaXB0IGJlY2F1c2UgaXQgcnVucyBvdXQg b2YgbWVtb3J5LiBBbmQgSSd2ZSBldmVuIHNlZW4gc2l0dWF0aW9ucywgd2hlcmUgdGhlIGJyb3dz ZXIgaXRzZWxmIGRpZCBub3QgcmVzcG9uZCBhbnltb3JlIChzd2FwcGluZyB0byBkaXNrLCAuLi4p Lg0KDQpPbmUgYWZ0ZXJub29uLCBJIHNldCBhbiBTTk1QIGdldC1uZXh0IGdvaW5nIG9uIFJNT04g YW5kIGl0IHdhcyBzdGlsbCBnb2luZyB0aGUgbmV4dCBkYXk7IEkgdGhlbiB0cmllZCBvdmVyIGEg d2Vla2VuZCBhbmQgaXQgd2FzIHN0aWxsIGdvaW5nIHRoZSBuZXh0IHdlZWsuICBEYXRhIHdhcyBi ZWluZyBhZGRlZCB0byB0aGUgdGFibGUgZmFzdGVyIHRoYW4gbXkgaGlnaCBzcGVlZCBMQU4gY291 bGQgcmV0cmlldmUgaXQuICBOZWl0aGVyIHN5c3RlbSBjcmFzaGVkIGFsdGhvdWdoIHJlc3BvbnNl IHRpbWVzIGZvciBvdGhlciBhcHBsaWNhdGlvbnMgZWxvbmdhdGVkLg0KDQpJIGFtIHJlbWluZGVk IG9mIGUtbWFpbCB3aGVyZSBhIFBPUCBjbGllbnQgbWF5IGFjY2VzcyBhIHZlcnkgbGFyZ2UgbGlz dCBvZiBlLW1haWxzIG9uIGEgc2VydmVyLiAgVGhlIGZpcnN0IHJlc3BvbnNlIGlzIGEgY291bnQg b2YgaG93IG1hbnkgdGhlcmUgYXJlIGN1cnJlbnRseTsgdGhlIGNsaWVudCBjYW4gdGhlbiByZXF1 ZXN0IHRoZSBzdW1tYXJ5IGRhdGEgZm9yIGVhY2ggYmVmb3JlIGRlY2lkaW5nIHdoaWNoIHRvIGRv d25sb2FkIGluIGZ1bGwuICBUaGlzIHdhcyBkZXNpZ25lZCBiZWZvcmUgdGhlIGNsb3VkIHdhcyB0 aG91Z2h0IG9mIGFuZCBpdCBpcyBhIHN5c3RlbSB0aGF0IHN0aWxsIHdvcmtzIHdlbGwuDQoNCltR aW5dOkhhdmUgYSBsaXR0bGUgYml0IGJyYWluc3Rvcm0sIGluIEhUVFAgU3RyZWFtaW5nLCB3ZSBt YXkgY3JlYXRlIG1hbmlmZXN0IGZpbGUgZm9yIHRoZSBsb2NhdGlvbiBvZiBhZGRpdGlvbmFsIHN0 cmVhbXMgb3IgbmV4dCBjaHVuay4gVGhlIGVuY29kZXIgb3IgYXV0b21hdGVkIHNjcmlwdHMgdXBs b2FkIHRoZSBmaWxlcyB0byBORVRDT05GL1JFU1RDT05GIHNlcnZlciwgdGhlIGNsaWVudCBuZWVk IHRvIGRvd25sb2FkIHN1Y2ggbWFuaWZlc3QgZmlsZS4NCg0KVG9tIFBldGNoDQoNCg0KDQoNCg0K DQoNCj4NCj4gQnkgaW50cm9kdWNpbmcgYSBwcm90ZWN0aW9uIG1lY2hhbmlzbXMgbGlrZSBtYXgt Y291bnQsIHRoZSBjbGllbnQgY2FuDQpjb250cm9sIHRvIGEgY2VydGFpbiBleHRlbnQgaG93IG11 Y2ggZGF0YSB3aWxsIGJlIHJlY2VpdmVkLiBBbmQgYnkgdXNpbmcgcGFnaW5nIGZvciBwb3N0IGxv YWRpbmcgaW4gdGhlIGJhY2tncm91bmQsIHRoZSBjbGllbnQgY291bGQgc3RpbGwgZGVjaWRlIGlm IGl0IGlzIHBvc3NpYmxlIHRvIGxvYWQgYW5vdGhlciBwYWdlIG9yIG5vdC4gU28gd2hlbiBydW5u aW5nIG91dC1vZi1tZW1vcnkgb3Igd2hlbiBzdGFydCBzd2FwcGluZywgdGhlIGNsaWVudCBjb3Vs ZCBhdm9pZCBsb2FkaW5nIGFueSBmdXJ0aGVyIHBhZ2VzLiBHZW5lcmFsbHkgSSBhbSB0aGlua2lu ZyB0aGlzIGlzIGEgdmVyeSByZWFzb25hYmxlIGFrYSBjb250cm9sbGVkICBhcHByb2FjaC4NCj4N Cj4gV2l0aCBORVRDT05GIHRvZGF5LCBmb3Igc3VyZSBvbmUgY291bGQgdGVybWluYXRlIHRoZSBO RVRDT05GIHNlc3Npb25zDQppZiB0b28gbXVjaCBkYXRhIGlzIHJlY2VpdmVkIGFuZCBtaWdodCB0 cnkgdXNpbmcgYSBYTUwgc3RyZWFtIHJlYWRlciB0byBwcm9jZXNzIHdoYXQgaGFzIGJlZW4gcmVj ZWl2ZWQgc28gZmFyLiBCdXQgd291bGQgY2xhaW0gdGhhdCB0aGlzIGlzIG5vdCBhIGdvb2QgYXBw cm9hY2ggYXQgYWxsIGFuZCBzaG91bGQgYmUgYXZvaWRlZC4NCj4NCj4gL3dpc28NCj4NCj4NCj4N Cj4NCj4g77u/T24gMTQuMDMuMTksIDExOjQ5LCAiSnVlcmdlbiBTY2hvZW53YWVsZGVyIg0KPGou c2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+DQo+ICAgICBPbiBU aHUsIE1hciAxNCwgMjAxOSBhdCAxMDowNzozM0FNICswMDAwLCBXaXNvdHpreSwgU3ZlbiAoTm9r aWEgLQ0KREUvU3R1dHRnYXJ0KSB3cm90ZToNCj4gICAgID4NCj4gICAgID4gSG93ZXZlciwgYXMg cGVyIG15IGluaXRpYWwgcG9zdCBiZWxvdywganVzdCBkZWZpbmluZyBhIGxpbWl0DQooYWthIG1h eC1jb3VudCkgaXMgYSB2ZXJ5IGVmZmljaWVudCBpbml0aWFsIHN0ZXAgdG8gaW1wcm92ZSBsb2Fk aW5nIHRpbWUgYW5kIGF2b2lkIGNyYXNoZXMuDQo+DQo+ICAgICBTb3JyeSwgYnV0IGlmIGNvZGUg Y3Jhc2hlcywgdGhlbiBzb21lb25lIGhhcyB0byBmaXggdGhlIGNvZGUuDQpBZGRpbmcNCj4gICAg IHF1ZXJ5IHBhcmFtZXRlcnMgaXMgbm90IHRoZSByaWdodCBhbnN3ZXIgZm9yIHRoaXMuDQo+DQo+ ICAgICAvanMNCj4NCj4gICAgIC0tDQo+ICAgICBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAg ICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiAgICAgUGhvbmU6ICs0OSA0MjEg MjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwNCkdlcm1hbnkN Cj4gICAgIEZheDogICArNDkgNDIxIDIwMCAzMTAzDQo8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZl cnNpdHkuZGUvPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBuZXRjb25mIG1haWxpbmcgbGlzdA0KPiBuZXRjb25mQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0Y29uZiBtYWls aW5nIGxpc3QNCm5ldGNvbmZAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0Y29uZg0K From nobody Mon Mar 18 08:00:05 2019 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 C8448130E9A for ; Mon, 18 Mar 2019 08:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.323 X-Spam-Level: X-Spam-Status: No, score=-3.323 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, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=hRrnEyMX; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Y1SpCrq2 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 I7ZcuMFp5RG5 for ; Mon, 18 Mar 2019 08:00:01 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 98E951286C8 for ; Mon, 18 Mar 2019 08:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1552921198; x=1555513198; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JLH19Wd2R9hX+U8kbD5M1H3zBNmH7pz7K3uB8PFxa50=; b=hRrnEyMX0HYR9z+MeRML5VL0+4FCJ5Lkl5o8abLg8fpV08O7GKMNtrao9cvFbAl1 ulb8eBC/M52wXf8shcT3Nk3+1Kx8QbaQnyawgc0/L2rk/W1VN8Zw6mmlpquxv0YB n4/80wUcA4Nu7R0Tc74kgmTaopms91EVBThlKQaH8d0=; X-AuditID: c1b4fb3a-5c9c29e00000672c-38-5c8fb26e3ce6 Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 56.0B.26412.E62BF8C5; Mon, 18 Mar 2019 15:59:58 +0100 (CET) Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 18 Mar 2019 15:59:51 +0100 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Mon, 18 Mar 2019 15:59:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JLH19Wd2R9hX+U8kbD5M1H3zBNmH7pz7K3uB8PFxa50=; b=Y1SpCrq2XhKveWjbN01OsZkHmTstb6/hL9qDvDeOEZB02/XjnONeeFJAO3LAtdFEY8UUajoW56PO8pYTILDQrCCFc2m4QQPcrOeP2JKOX1HA/YKgQfQAYI0MzQhLMRa/qhr9RYqpg7hRXT/6HY6oxuyCUmem7ZvEaZ4mPFWwkzw= Received: from DB7PR07MB3850.eurprd07.prod.outlook.com (52.134.99.143) by DB7PR07MB5749.eurprd07.prod.outlook.com (20.177.194.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.9; Mon, 18 Mar 2019 14:59:50 +0000 Received: from DB7PR07MB3850.eurprd07.prod.outlook.com ([fe80::4134:60f8:af37:d7aa]) by DB7PR07MB3850.eurprd07.prod.outlook.com ([fe80::4134:60f8:af37:d7aa%5]) with mapi id 15.20.1730.008; Mon, 18 Mar 2019 14:59:50 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: "netconf@ietf.org" Thread-Topic: [netconf] Usage examples for max-depth (rfc8526) Thread-Index: AQHU3Zs8C50xFm0Mhk6nZPyvEnoyNg== Date: Mon, 18 Mar 2019 14:59:50 +0000 Message-ID: <5318827d-5aaf-71cf-203f-ed6d550b0dcd@ericsson.com> References: <0AA9F087-D2FF-42EA-8ACA-FD44FAA57890@nokia.com> In-Reply-To: <0AA9F087-D2FF-42EA-8ACA-FD44FAA57890@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [89.135.192.225] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 x-clientproxiedby: HE1PR05CA0247.eurprd05.prod.outlook.com (2603:10a6:3:fb::23) To DB7PR07MB3850.eurprd07.prod.outlook.com (2603:10a6:5:7::15) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 72046e08-99bd-4f5d-a016-08d6abb25eb4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:DB7PR07MB5749; x-ms-traffictypediagnostic: DB7PR07MB5749: x-microsoft-antispam-prvs: x-forefront-prvs: 098076C36C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(366004)(136003)(346002)(396003)(189003)(199004)(65806001)(8676002)(229853002)(85182001)(6486002)(8936002)(446003)(6116002)(3846002)(99936001)(5640700003)(53936002)(6436002)(6346003)(26005)(966005)(6306002)(305945005)(316002)(2906002)(7736002)(105586002)(14444005)(256004)(186003)(2351001)(6916009)(14454004)(486006)(106356001)(6512007)(85202003)(97736004)(102836004)(52116002)(76176011)(86362001)(6506007)(386003)(64126003)(53376002)(65826007)(31696002)(36756003)(71200400001)(5660300002)(71190400001)(2501003)(11346002)(81166006)(1730700003)(81156014)(2616005)(25786009)(99286004)(478600001)(6246003)(31686004)(58126008)(65956001)(66066001)(476003)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5749; H:DB7PR07MB3850.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: zE/iHlC3z4Jmnuq+lBskblE9WaAy/nsliivYtOuVSgyLVqCtfbA+U/L5D/QNhF1UqPvZeKPzNyTvHObpr/WmFMe1NuwxwxfueoL8gmmP0YvD0yqEAgtBMyNNjhDOu0LmO490IOV9dychX9lasBambX+5BWmlBIJnHamDM2TGrisRUybZ0GkXWlmRpgDJkneNHMPoNcB5EQ3BwDODKZ88t0FqGyGhYPvIyL09LqnKpi8KVokiuuUkk4dxM9U4KeHNZIiLbZQyLfOJs3cSMf1q3nMpeu8PXSUkWipbo1vCnzwZk5NzxoCJM7pyw7hJ5Y+4S58b0tz+8ht4o9ABNAnJAdoOE5055mdgVUCYxJSpkIWhFS/SmxktzLeG9JeNRDEiH+A59Te9nUZo5+kELMAE3u+bodAL+2BRqpxGx2vRItc= Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070606050209000605010302" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 72046e08-99bd-4f5d-a016-08d6abb25eb4 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2019 14:59:50.5711 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5749 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0hTYRjHe885246ryevSfFiGOpLI1NIyLC/rnkVWH0usHHlQU6ftLFPD MinMmSilNUd5QwzUzFQywYpJ3ioxb2SK5HSROSorMTWzdnYW1Lff83/+z/tceGlS2iOQ0bEq DaNWKePlQjFVdKwp1VtVnxexyTQmCyisHxHsQKEVFfPEURQuDopi4mOTGfXGkEhxTGvHgiCp +HBK891cUQZq3q1FdjTgLTCVXS7QIjEtxc8R9NwpRnwwi8BgLkScS4orCMjrUnAJCueTMFvX ZHPdJKB0rIHig3EENY0LIq5EiPdA1udnBMeOeD1c1k8LOF6JgyHPMCPi9RDIXLpN8ewD8406 i05bWniASefCyRKsgPlFLcnJUhwEvV/CONnO8kqm8ZF1OIRXwY8XNdZOJHaGYVMJwa/mCMbe l0KeneDjxJKAZznopoat7IRPQNfkK+v6gG8g6O69RvEmL+h+Y0I8r4G+khwbh4FxpkDEF0wg GHrSIuSGA+wJ2jpbbRzUjFXZmrlAf2cZYfMLYbGkneJPysC9+1dRPvLW/zO43uIjcTaC7/oB Qm89gAN0FZko3rQVihuMJM8boLLMTP5fzHEg6BYMQp7doSDHKOLZH8xtXxHPm6Gy9pewFImr kBPLsGxCtJ+fD6OOPc2yiSofFaOpR5avZWj8uf0xMnzY2YowjeQrJBHleRFSgTKZTU1oRWst 74zXVb9GMkqVqGLkjhLFAUtaEqVMTWPUiafU5+IZthWtpim5s2RR6hAhxdFKDRPHMEmM+m+W oO1kGSi6adlw37ri/f5XBsxDLVnhfo0XEjr3ne2f8FT+/uRe57roXJ8mqPFJJ64HHro4+vD9 09qe0G/2B73exR8xnalO81zuNzUii9LaF5W+zdYETJLtkaNubgrXueMPcqtOzng0m0XKbfrg Dt+UvQuDbbe8ps8HmtIvaUp2zQ3SpEaoU8gpNkbp60mqWeUf1RwQH2IDAAA= Archived-At: Subject: Re: [netconf] Usage examples for max-depth (rfc8526) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 15:00:04 -0000 --------------ms070606050209000605010302 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US As a private opinion: Providing a list without keys is kind of useless. IMHO keys should=20 always be present if the list is allowed by depth. In my view the=20 correct answer is: Example 3: no subtree filter is provided, max-depth=3D3 Joe Bill Balazs So even if the key name is strictly speaking on depth=3D4 it should be=20 included in a level 3 get result. regards Balazs On 2019. 03. 14. 9:53, Wisotzky, Sven (Nokia - DE/Stuttgart) wrote: > Unfortunately the info provided in RFC 8526 about the max-depth attribu= te is not very precise. > Is it fair to assume, that behavior is aligned with the RESTCONF "depth= " attribute described in RFC 8040? > > Let's use the following sample from chapter 3.1.1.3: > > > > root > superuser > Charlie Root > > 1 > 1 > > > > > > > Example 1: no subtree filter is provided, max-depth=3D1 > > > > Example 2: no subtree filter is provided, max-depth=3D2 > > > > > Assumption the container would only be present in the result, i= f this container has any explicit children configuration. If there is no = children config, it would not be part of the output. > > Example 3: no subtree filter is provided, max-depth=3D3 > > > > > > > Somewhat interesting scenario. It provides the netconf client with a me= thod to check, if a list contains any entries. So if the XML node = is contained, we would know that the list "user" has at least one entry. = However, this XML output would not validate against the YANG model - beca= use list-keys (user/name) are mandatory. In essence, that client requires= to be flexible when parsing such result and cannot be restricted to YANG= =2E > > Example 4: no subtree filter is provided, max-depth=3D4 > > > > root > superuser > Charlie Root > > > > > > > Similar to example 2, the container would only be presen= t, if this container has explicit children configuration. > > > Someone please to confirm, if those examples and assumptions being made= are correct! > > /wiso > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --=20 Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com --------------ms070606050209000605010302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20 wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4 ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9 ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9 YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF 1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6 EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0 NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA 7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+ MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0 LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9 2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa 49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDMxODE0NTk0Nlow LwYJKoZIhvcNAQkEMSIEIDpwSrxGVXAEDjSh7NQPzvUiBsh74C8vHfT+Q6l5QIoCMGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBAEhZo95MxEHSU5J1mqrFdlyv2rbaILSs8Gsmbi3rJ2wVGnp9 ptHfYgWwvqMQGDnR28nA0F/MSN5oxcOge1F91bf0vqn0rjqRanWM/AZ82Ax2n4BSlZzINYMo TR02ikXq9nXK0AJQzpA8V+emwJotvdJ9VCuYJRiQ1egT1nFHw34+TJ7eODghTG4AeKrWNH5J KjFoTr1AQeFZgjE3Rk56n6XmqP6K9jVbQQygVvwtboau4fSvbNIw6OQISi6vY5jOzcI3DXu/ qWabo/Pqjt1zz9dfWDr8fj9tbyfX0i55CqoOoALW0QUz5+ipM4CIQ7lkgQrdnhQ6Y4NAJxv8 GUiB8kMAAAAAAAA= --------------ms070606050209000605010302-- From nobody Mon Mar 18 10:58:58 2019 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 34DE8129AB8 for ; Mon, 18 Mar 2019 10:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 IQAM63NSJihz for ; Mon, 18 Mar 2019 10:58:53 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986EB1200D8 for ; Mon, 18 Mar 2019 10:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4049; q=dns/txt; s=iport; t=1552931933; x=1554141533; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=IHtZMhGDP4/Ahhn9Hut2gK/KVUd2vpyX8T1EdpvjtQA=; b=nAMPZrW+sdzWeh9Scw763sX8qxc7WTeU9dLvHlOkGPifiUVAEOy2FPvv Q+PdHaeXDTLhPqbqzPRPQ1x4nDp01XpKT66eG8y0Q3YclHwjpwV767F01 9rgfwnzP3tHcCEaltNqN96JkGlrAeGOU7kc2poZ19yLZMCLD2quatpl7L k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAACZ249c/40NJK1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBgWEvaIEDJwqXP4INmDGBewsBARgLhAN?= =?us-ascii?q?GAoRaIjYHDQEBAwEBCQECAQJtHAyFSgEBAQQBASUTNBcEAgEIEQQBAR8QJws?= =?us-ascii?q?dCAIEARIIgxuBdQ+rMjOKMoEvAYsvF4FAP4QjgxMLAQGBS4V3A4oKhnuTUAk?= =?us-ascii?q?Ch1mJH4IjIYF8W4UUi2yLB4V4jQMCERWBKCYCL4FWcBU7gmwJhW+FFIU/QTG?= =?us-ascii?q?HNiuBAYEfAQE?= X-IronPort-AV: E=Sophos;i="5.58,494,1544486400"; d="scan'208";a="526382660" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Mar 2019 17:58:52 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x2IHwq8w001751 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Mar 2019 17:58:52 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Mar 2019 12:58:51 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Mon, 18 Mar 2019 12:58:51 -0500 From: "Rob Wilton (rwilton)" To: "Wisotzky, Sven (Nokia - DE/Stuttgart)" , "netconf@ietf.org" Thread-Topic: Usage examples for max-depth (rfc8526) Thread-Index: AQHU2kNT5zRVd6q0aUyVnM8yIqQf4KYRrJdg Date: Mon, 18 Mar 2019 17:58:51 +0000 Message-ID: <073d696fedfc42838bc3eb0b92fa3b4e@XCH-RCD-007.cisco.com> References: <0AA9F087-D2FF-42EA-8ACA-FD44FAA57890@nokia.com> In-Reply-To: <0AA9F087-D2FF-42EA-8ACA-FD44FAA57890@nokia.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.63.23.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [netconf] Usage examples for max-depth (rfc8526) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 17:58:57 -0000 Hi Sven, Yes, I think that intention is to be consistent with the RESTCONF behaviour= . Although, there might be a slight bug in the example 3 on page 129 of RF= C 8040; I would expect both "artist" and "song" to be represented as empty = arrays rather than empty objects. My take is, assuming top is a top level container: Example 1: yes Example 2: yes, but your assumption does not necessarily hold. Section 7.5= .7 of RFC 7950 allows non-presence container to be returned even if it does= not contain any children, so I don't think that you can infer anything if = it is present in the output. If the container has presence then your assum= ption does hold. Example 3: yes, that is what I would expect the output to be. Example 4. Same answer as for 2. In terms of the expected behaviour then I think that the result should be e= quivalent to the server generating the full output for the request and then= removing all nodes that are deeper than the depth parameter. Obviously a = server could implement it more efficiently than this. Thanks, Rob -----Original Message----- From: netconf On Behalf Of Wisotzky, Sven (Nokia= - DE/Stuttgart) Sent: 14 March 2019 08:53 To: netconf@ietf.org Subject: [netconf] Usage examples for max-depth (rfc8526) Unfortunately the info provided in RFC 8526 about the max-depth attribute i= s not very precise. Is it fair to assume, that behavior is aligned with the RESTCONF "depth" at= tribute described in RFC 8040? Let's use the following sample from chapter 3.1.1.3: root superuser Charlie Root 1 1 Example 1: no subtree filter is provided, max-depth=3D1 Example 2: no subtree filter is provided, max-depth=3D2 Assumption the container would only be present in the result, if th= is container has any explicit children configuration. If there is no childr= en config, it would not be part of the output. Example 3: no subtree filter is provided, max-depth=3D3 Somewhat interesting scenario. It provides the netconf client with a method= to check, if a list contains any entries. So if the XML node is con= tained, we would know that the list "user" has at least one entry. However,= this XML output would not validate against the YANG model - because list-k= eys (user/name) are mandatory. In essence, that client requires to be flexi= ble when parsing such result and cannot be restricted to YANG. Example 4: no subtree filter is provided, max-depth=3D4 root superuser Charlie Root Similar to example 2, the container would only be present, i= f this container has explicit children configuration. Someone please to confirm, if those examples and assumptions being made are= correct! /wiso _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Mar 18 11:11:36 2019 Return-Path: <0100016992005c43-0478ab12-3b35-48bd-ab0b-a278c3015ba4-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 D601013114B for ; Mon, 18 Mar 2019 11:11:33 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 F9prGiwH-nDB for ; Mon, 18 Mar 2019 11:11:32 -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 7096A13111D for ; Mon, 18 Mar 2019 11:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1552932691; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=bsZfQu2N++pZJOnqqnTgQVTPmK8Y7bcB+RACTqKl5GA=; b=R6UXkwhA0EfXoDLY8zrVXbDLA0LOddbfq9nhPT2QIargZXqowJ9eFXvK1wQQdD38 OGV4IuGh7haTgkGUeAMw0Pz7Rvf+7o5MXUkPsL4cPL7WhZKGauax9UQrKjpGvkr5t28 8WV7TnAZAEPJV4O8EnBxOxGJYnwixFYRb988Um3o= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Kent Watsen In-Reply-To: Date: Mon, 18 Mar 2019 18:11:31 +0000 Cc: tom petch , "Wisotzky, Sven (Nokia - DE/Stuttgart)" , Juergen Schoenwaelder , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <0100016992005c43-0478ab12-3b35-48bd-ab0b-a278c3015ba4-000000@email.amazonses.com> References: To: Qin Wu X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.18-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Current activities on RESTCONF/NETCONF to support paging 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, 18 Mar 2019 18:11:34 -0000 Now that NMDA, Zero Touch, and YANG Push are behind us, and also that = the suite of client server/drafts are nearly behind us as well, now is a = good time to start thinking about what we'd like to work on next. =20 The "collections" and/or "netconf-fragmentation" drafts seem like a = prime candidates. Thank you Sven and others for raising awareness to = these holdovers from before. Thanks, Kent From nobody Mon Mar 18 15:15:02 2019 Return-Path: <0100016992df3dee-810edfad-751d-4cc9-92b5-76496bdb52bf-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 99884127133; Mon, 18 Mar 2019 15:15:00 -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_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 yOqc-j6rvi9P; Mon, 18 Mar 2019 15:14:59 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 416E8124B91; Mon, 18 Mar 2019 15:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1552947298; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:Cc:To:Feedback-ID; bh=WObu7FuKfv1KfTL79Jadf5ZAxRnlYdkSuKq1QOLQbQg=; b=j2/1BpzB2M6ag/+bKaP/o9PBa83ICcc38fev+xUty5+0x4wVHhzWG8Tt8cSjI2ZC qyDiyaYzehVSWFXMmtWI343Xao4nRbVIU3G9ij7ebadXHx47QqIhakAKqonD9j1plPr b2tPECgLQQYNiG08ZUkHb9FuqkCi7nu2pW8kRdpI= From: Kent Watsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-ID: <0100016992df3dee-810edfad-751d-4cc9-92b5-76496bdb52bf-000000@email.amazonses.com> Date: Mon, 18 Mar 2019 22:14:57 +0000 Cc: netconf-chairs@ietf.org To: netconf@ietf.org X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.18-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] 104 Presenters: please send your slides 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, 18 Mar 2019 22:15:01 -0000 Dear NETCONF 104 Presenters, Please send your slides to the chairs alias (CC-ed) by this Friday. Thanks you! Kent and Mahesh From nobody Mon Mar 18 20:36:35 2019 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 7FB581279A9 for ; Mon, 18 Mar 2019 20:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 3NPJSj4HkiHk for ; Mon, 18 Mar 2019 20:36:30 -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 947E11279A2 for ; Mon, 18 Mar 2019 20:36:30 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 13EA88EBE31D9328A899; Tue, 19 Mar 2019 03:36:28 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 19 Mar 2019 03:36:27 +0000 Received: from DGGEMM527-MBX.china.huawei.com ([169.254.6.77]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0415.000; Tue, 19 Mar 2019 11:36:25 +0800 From: wangzitao To: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , "netconf@ietf.org" Thread-Topic: [netconf] Usage examples for max-depth (rfc8526) Thread-Index: AdTeA8WykGakdwrtSgumgqfLSpkB8w== Date: Tue, 19 Mar 2019 03:36:24 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.142.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Usage examples for max-depth (rfc8526) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 03:36:34 -0000 DQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IG5ldGNvbmYgW21haWx0bzpuZXRj b25mLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBCYWzDoXpzIExlbmd5ZWwNCuWPkemAgeaXtumX tDogMjAxOeW5tDPmnIgxOOaXpSAyMzowMA0K5pS25Lu25Lq6OiBuZXRjb25mQGlldGYub3JnDQrk uLvpopg6IFJlOiBbbmV0Y29uZl0gVXNhZ2UgZXhhbXBsZXMgZm9yIG1heC1kZXB0aCAocmZjODUy NikNCg0KQXMgYSBwcml2YXRlIG9waW5pb246DQoNClByb3ZpZGluZyBhIGxpc3Qgd2l0aG91dCBr ZXlzIGlzIGtpbmQgb2YgdXNlbGVzcy4gSU1ITyBrZXlzIHNob3VsZCBhbHdheXMgYmUgcHJlc2Vu dCBpZiB0aGUgbGlzdCBpcyBhbGxvd2VkIGJ5IGRlcHRoLiBJbiBteSB2aWV3IHRoZSBjb3JyZWN0 IGFuc3dlciBpczoNCg0KRXhhbXBsZSAzOiBubyBzdWJ0cmVlIGZpbHRlciBpcyBwcm92aWRlZCwg bWF4LWRlcHRoPTMNCiAgICAgICAgPHRvcCB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVt YS8xLjIvY29uZmlnIj4NCiAgICAgICAgICA8dXNlcnM+DQogICAgICAgICAgICA8dXNlcj4NCiAg ICAgICAgICAgICAgIDxuYW1lPkpvZTwvbmFtZT4NCiAgICAgICAgICAgIDwvdXNlcj4NCiAgICAg ICAgICAgIDx1c2VyPg0KICAgICAgICAgICAgICAgPG5hbWU+QmlsbDwvbmFtZT4NCiAgICAgICAg ICAgIDwvdXNlcj4NCiAgICAgICAgICAgIDx1c2VyPg0KICAgICAgICAgICAgICAgPG5hbWU+QmFs YXpzPC9uYW1lPg0KICAgICAgICAgICAgPC91c2VyPg0KICAgICAgICAgIDwvdXNlcnM+DQogICAg ICAgIDwvdG9wPg0KDQpTbyBldmVuIGlmIHRoZSBrZXkgbmFtZSBpcyBzdHJpY3RseSBzcGVha2lu ZyBvbiBkZXB0aD00IGl0IHNob3VsZCBiZSBpbmNsdWRlZCBpbiBhIGxldmVsIDMgZ2V0IHJlc3Vs dC4NCg0KW01pY2hhZWxdOiBCYXNlZCBvbiBSRkM4MDQwLCBpdCB3aWxsIG9ubHkgb3V0cHV0IHRo ZSA8dXNlcj4gbGlzdCBsZXZlbCAoZGVwdGggNCksIGhvd2V2ZXIsIGZvciBhIGxpc3Qgd2l0aG91 dCBrZXkgYW5kIGFudGhlciBwYXJhbWV0ZXJzLCBpdCBkb2Vzbid0IHNlZW0gdG8gYmUgbWVhbmlu Z2Z1bC4NCg0KcmVnYXJkcyBCYWxhenMNCg0KT24gMjAxOS4gMDMuIDE0LiA5OjUzLCBXaXNvdHpr eSwgU3ZlbiAoTm9raWEgLSBERS9TdHV0dGdhcnQpIHdyb3RlOg0KPiBVbmZvcnR1bmF0ZWx5IHRo ZSBpbmZvIHByb3ZpZGVkIGluIFJGQyA4NTI2IGFib3V0IHRoZSBtYXgtZGVwdGggYXR0cmlidXRl IGlzIG5vdCB2ZXJ5IHByZWNpc2UuDQo+IElzIGl0IGZhaXIgdG8gYXNzdW1lLCB0aGF0IGJlaGF2 aW9yIGlzIGFsaWduZWQgd2l0aCB0aGUgUkVTVENPTkYgImRlcHRoIiBhdHRyaWJ1dGUgZGVzY3Jp YmVkIGluIFJGQyA4MDQwPw0KPg0KPiBMZXQncyB1c2UgdGhlIGZvbGxvd2luZyBzYW1wbGUgZnJv bSBjaGFwdGVyIDMuMS4xLjM6DQo+ICAgICAgICAgPHRvcCB4bWxucz0iaHR0cDovL2V4YW1wbGUu Y29tL3NjaGVtYS8xLjIvY29uZmlnIj4NCj4gICAgICAgICAgIDx1c2Vycz4NCj4gICAgICAgICAg ICAgPHVzZXI+DQo+ICAgICAgICAgICAgICAgPG5hbWU+cm9vdDwvbmFtZT4NCj4gICAgICAgICAg ICAgICA8dHlwZT5zdXBlcnVzZXI8L3R5cGU+DQo+ICAgICAgICAgICAgICAgPGZ1bGwtbmFtZT5D aGFybGllIFJvb3Q8L2Z1bGwtbmFtZT4NCj4gICAgICAgICAgICAgICA8Y29tcGFueS1pbmZvPg0K PiAgICAgICAgICAgICAgICAgPGRlcHQ+MTwvZGVwdD4NCj4gICAgICAgICAgICAgICAgIDxpZD4x PC9pZD4NCj4gICAgICAgICAgICAgICA8L2NvbXBhbnktaW5mbz4NCj4gICAgICAgICAgICAgPC91 c2VyPg0KPiAgICAgICAgICAgICA8IS0tIGFkZGl0aW9uYWwgPHVzZXI+IGVsZW1lbnRzIGFwcGVh ciBoZXJlLi4uIC0tPg0KPiAgICAgICAgICAgPC91c2Vycz4NCj4gICAgICAgICA8L3RvcD4NCj4N Cj4gRXhhbXBsZSAxOiBubyBzdWJ0cmVlIGZpbHRlciBpcyBwcm92aWRlZCwgbWF4LWRlcHRoPTEN Cj4gICAgICAgICA8dG9wIHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hLzEuMi9jb25m aWciPg0KPiAgICAgICAgIDwvdG9wPg0KPg0KPiBFeGFtcGxlIDI6IG5vIHN1YnRyZWUgZmlsdGVy IGlzIHByb3ZpZGVkLCBtYXgtZGVwdGg9Mg0KPiAgICAgICAgIDx0b3AgeG1sbnM9Imh0dHA6Ly9l eGFtcGxlLmNvbS9zY2hlbWEvMS4yL2NvbmZpZyI+DQo+ICAgICAgICAgICA8dXNlcnM+DQo+ICAg ICAgICAgICA8L3VzZXJzPg0KPiAgICAgICAgIDwvdG9wPg0KPiBBc3N1bXB0aW9uIHRoZSBjb250 YWluZXIgPHVzZXJzPiB3b3VsZCBvbmx5IGJlIHByZXNlbnQgaW4gdGhlIHJlc3VsdCwgaWYgdGhp cyBjb250YWluZXIgaGFzIGFueSBleHBsaWNpdCBjaGlsZHJlbiBjb25maWd1cmF0aW9uLiBJZiB0 aGVyZSBpcyBubyBjaGlsZHJlbiBjb25maWcsIGl0IHdvdWxkIG5vdCBiZSBwYXJ0IG9mIHRoZSBv dXRwdXQuDQo+DQo+IEV4YW1wbGUgMzogbm8gc3VidHJlZSBmaWx0ZXIgaXMgcHJvdmlkZWQsIG1h eC1kZXB0aD0zDQo+ICAgICAgICAgPHRvcCB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVt YS8xLjIvY29uZmlnIj4NCj4gICAgICAgICAgIDx1c2Vycz4NCj4gICAgICAgICAgICAgPHVzZXI+ DQo+ICAgICAgICAgICAgIDwvdXNlcj4NCj4gICAgICAgICAgIDwvdXNlcnM+DQo+ICAgICAgICAg PC90b3A+DQo+IFNvbWV3aGF0IGludGVyZXN0aW5nIHNjZW5hcmlvLiBJdCBwcm92aWRlcyB0aGUg bmV0Y29uZiBjbGllbnQgd2l0aCBhIG1ldGhvZCB0byBjaGVjaywgaWYgYSBsaXN0IGNvbnRhaW5z IGFueSBlbnRyaWVzLiBTbyBpZiB0aGUgWE1MIG5vZGUgPHVzZXI+IGlzIGNvbnRhaW5lZCwgd2Ug d291bGQga25vdyB0aGF0IHRoZSBsaXN0ICJ1c2VyIiBoYXMgYXQgbGVhc3Qgb25lIGVudHJ5LiBI b3dldmVyLCB0aGlzIFhNTCBvdXRwdXQgd291bGQgbm90IHZhbGlkYXRlIGFnYWluc3QgdGhlIFlB TkcgbW9kZWwgLSBiZWNhdXNlIGxpc3Qta2V5cyAodXNlci9uYW1lKSBhcmUgbWFuZGF0b3J5LiBJ biBlc3NlbmNlLCB0aGF0IGNsaWVudCByZXF1aXJlcyB0byBiZSBmbGV4aWJsZSB3aGVuIHBhcnNp bmcgc3VjaCByZXN1bHQgYW5kIGNhbm5vdCBiZSByZXN0cmljdGVkIHRvIFlBTkcuDQo+DQo+IEV4 YW1wbGUgNDogbm8gc3VidHJlZSBmaWx0ZXIgaXMgcHJvdmlkZWQsIG1heC1kZXB0aD00DQo+ICAg ICAgICAgPHRvcCB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS8xLjIvY29uZmlnIj4N Cj4gICAgICAgICAgIDx1c2Vycz4NCj4gICAgICAgICAgICAgPHVzZXI+DQo+ICAgICAgICAgICAg ICAgPG5hbWU+cm9vdDwvbmFtZT4NCj4gICAgICAgICAgICAgICA8dHlwZT5zdXBlcnVzZXI8L3R5 cGU+DQo+ICAgICAgICAgICAgICAgPGZ1bGwtbmFtZT5DaGFybGllIFJvb3Q8L2Z1bGwtbmFtZT4N Cj4gICAgICAgICAgICAgICA8Y29tcGFueS1pbmZvPg0KPiAgICAgICAgICAgICAgIDwvY29tcGFu eS1pbmZvPg0KPiAgICAgICAgICAgICA8L3VzZXI+DQo+ICAgICAgICAgICAgIDwhLS0gYWRkaXRp b25hbCA8dXNlcj4gZWxlbWVudHMgYXBwZWFyIGhlcmUuLi4gLS0+DQo+ICAgICAgICAgICA8L3Vz ZXJzPg0KPiAgICAgICAgIDwvdG9wPg0KPiBTaW1pbGFyIHRvIGV4YW1wbGUgMiwgdGhlIGNvbnRh aW5lciA8Y29tcGFueS1pbmZvPiB3b3VsZCBvbmx5IGJlIHByZXNlbnQsIGlmIHRoaXMgY29udGFp bmVyIGhhcyBleHBsaWNpdCBjaGlsZHJlbiBjb25maWd1cmF0aW9uLg0KPg0KPg0KPiBTb21lb25l IHBsZWFzZSB0byBjb25maXJtLCBpZiB0aG9zZSBleGFtcGxlcyBhbmQgYXNzdW1wdGlvbnMgYmVp bmcgbWFkZSBhcmUgY29ycmVjdCENCj4NCj4gL3dpc28NCj4NCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4g bmV0Y29uZkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldGNvbmYNCj4NCi0tIA0KQmFsYXpzIExlbmd5ZWwgICAgICAgICAgICAgICAgICAgICAgIEVy aWNzc29uIEh1bmdhcnkgTHRkLg0KU2VuaW9yIFNwZWNpYWxpc3QNCk1vYmlsZTogKzM2LTcwLTMz MC03OTA5ICAgICAgICAgICAgICBlbWFpbDogQmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tDQoN Cg0K From nobody Mon Mar 18 22:32:30 2019 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 E7ED71310C4 for ; Mon, 18 Mar 2019 22:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_V9NN7nmGSx for ; Mon, 18 Mar 2019 22:32:25 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60108.outbound.protection.outlook.com [40.107.6.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71FEC1277CE for ; Mon, 18 Mar 2019 22:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NKGFHotljysnVPjVlQyYLqCeccLNjSVkqc1VvyxxkU8=; b=YMQYZ3vVdfbqKlacjxcDgyo8zrqyEWxy8lJFDY/1pOT8dl0OMj1EQrMQF7Cagy3L7vfxaBmrLtUqhv8wxYcLuLJKZv1kKLXm3wje022bjuueNPMQafVMEER3jsSQRjVDhAXztzZrHpXMn6JRjcNsJ6he1SsMBj5UaVA8JMnQL2Q= Received: from AM6PR07MB5382.eurprd07.prod.outlook.com (20.178.91.74) by AM6PR07MB5223.eurprd07.prod.outlook.com (20.177.198.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.15; Tue, 19 Mar 2019 05:32:21 +0000 Received: from AM6PR07MB5382.eurprd07.prod.outlook.com ([fe80::8df:27dd:40f:ec82]) by AM6PR07MB5382.eurprd07.prod.outlook.com ([fe80::8df:27dd:40f:ec82%2]) with mapi id 15.20.1709.015; Tue, 19 Mar 2019 05:32:21 +0000 From: "Wisotzky, Sven (Nokia - DE/Stuttgart)" To: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , "netconf@ietf.org" Thread-Topic: [netconf] Usage examples for max-depth (rfc8526) Thread-Index: AQHU2kNT5zRVd6q0aUyVnM8yIqQf4KYRgfEAgAAzcYA= Date: Tue, 19 Mar 2019 05:32:21 +0000 Message-ID: <867EE695-8AC0-4431-9314-5E2B7BD1CB58@nokia.com> References: <0AA9F087-D2FF-42EA-8ACA-FD44FAA57890@nokia.com> <5318827d-5aaf-71cf-203f-ed6d550b0dcd@ericsson.com> In-Reply-To: <5318827d-5aaf-71cf-203f-ed6d550b0dcd@ericsson.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.0.190309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=sven.wisotzky@nokia.com; x-originating-ip: [176.35.138.139] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8733d994-5106-4cb1-1905-08d6ac2c42c6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR07MB5223; x-ms-traffictypediagnostic: AM6PR07MB5223: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0981815F2F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(136003)(396003)(366004)(199004)(189003)(110136005)(53936002)(186003)(26005)(256004)(58126008)(14444005)(6306002)(6512007)(478600001)(229853002)(6436002)(53376002)(82746002)(8936002)(81166006)(316002)(99286004)(6246003)(81156014)(86362001)(102836004)(8676002)(6486002)(36756003)(83716004)(446003)(106356001)(105586002)(14454004)(554214002)(2501003)(305945005)(966005)(7736002)(71190400001)(76176011)(71200400001)(68736007)(33656002)(486006)(2616005)(6116002)(25786009)(2906002)(66574012)(476003)(66066001)(3846002)(11346002)(97736004)(5660300002)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB5223; H:AM6PR07MB5382.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 2IRmPeTy0fp6z6VaYREtxX9DAEGYJWPG/6BwSACLPzhJhrCwYLd+jkOreicOhUVFiYo95cO4LwP4rONLGbtnOFjfypwKu8moQK71R1vVEVRMafKHp+9yFlfsNMiUT6lD/zVZhNd12wCV5RaBtzasE3/CP3oNvF5YrT3nAv4Z1bssJKOPmVBwJPBko5G2XpVY8lidJ1ExmFvDK3St+Oha+EWgwY0NRUNkJf0qornOwJJg2CcxW0661bL4G+XCU109YUwa7PyRAYN7b/PJtN4eukufXyNz/dY/BAGXxhHRvZNljo9ReQ94SOPiE0JPkTGOgPfp0236Q5S8NUu2EEEpiFu+bvmXMiMAxk+x75z4S0/Ff0/kjQ7JtA75uObk+7VGeZ+aZuCHEre1sobeQ1nhOIBMSe1XeyH2Bs2VRyW+n8g= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8733d994-5106-4cb1-1905-08d6ac2c42c6 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2019 05:32:21.7400 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5223 Archived-At: Subject: Re: [netconf] Usage examples for max-depth (rfc8526) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 05:32:28 -0000 SGkgQmFsw6F6cywNCg0KSSBkbyBhZ3JlZSwgdGhhdCBoYXZpbmcgMyBlbXB0eSA8dXNlcj4gY29u dGFpbmVycyB3b3VsZCBzb21ld2hhdCB1c2VsZXNzLiBPcmlnaW5hbGx5IEkgYW0gbG9va2luZyBm b3IgYSBzaW1wbGUgKGluLWV4cGVuc2l2ZSkgd2F5IHRvIGNoZWNrLCBpZiBhIGxpc3QgaGFzIGFu eSBlbGVtZW50cy4gSW4geW91ciBtb2RlbCwgaXQgbWlnaHQgYmUgcmF0aGVyIHNpbXBseSBieSBh c2tpbmcgZm9yIG1heC1kZXB0aD0yLiBJZiA8dXNlcnMvPiBpcyByZXR1cm5lZCBsaXN0IGlzIGNv bnNpZGVyZWQgbm90IGVtcHR5LCBpcyA8dXNlcnMvPiBpcyBOT1QgcmV0dXJuZWQgbGlzdCBpcyBj b25zaWRlcmVkIGVtcHR5Lg0KDQpIb3dldmVyLCBJIGRvbuKAmXQgdGhpbmsgd2UgY2FuIGNsYWlt IGl0IGZvciBndWFyYW50ZWVkIHRoYXQgbGlzdHMgYXJlIGFsd2F5cyBpbXBsZW1lbnRlZCBhcyBj b250YWluZXIgb2YgYSBzaW5nbGUgbGlzdC4gV2hpbGUgbm93IHdlIGNvdWxkIGFyZ3VlLCB0aGF0 IHJldHVybmluZyBhbGwgbGlzdCBlbnRyaWVzIHdpdGgganVzdCB0aGUgbGlzdC1rZXlzIGlzIGVm ZmljaWVudCBlbm91Z2ggLSBJIHN0aWxsIHdvdWxkIGJlIHdvcnJpZWQgYWJvdXQgaHVnZSBsaXN0 cywgd2hpY2ggcG90ZW50aWFsbHkgaGF2ZSAxMDBrKyBlbnRyaWVzLiBTdGlsbCBpbiB0aG9zZSBj YXNlcywgd2UgZnVsbHkgcmVseSBvbiB0aGUgcGVyZm9ybWFuY2Ugb2YgdGhlIE5FVENPTkYgc2Vy dmVyIGFuZCBwZXJmb3JtYW5jZSBvZiB0aGUgY29ubmVjdGlvbiAtIHdoaWxlIHdlIG1pZ2h0IG5v dCBldmVuIGFjdHVhbGx5IGludGVyZXN0ZWQgaW4gdGhlIGRldGFpbHMgb2Ygc3VjaCBsaXN0Lg0K DQpLZXkgdGFrZS1hd2F5czoNCigxKSBJdCBzZWVtcyBhdCBsZWFzdCB0aGUgZGVmaW5pdGlvbiBp biByZmM4NTI2IGlzIG5vdCBwcmVjaXNlIGVub3VnaCBhbmQgbGVhdmVzIHJvb20gZm9yIGludGVy cHJldGF0aW9uL2ltcGxlbWVudGF0aW9uLiBUaGlzIG11c3QgYmUgYXZvaWRlZCwgYXMgYW55IE5F VENPTkYvUkVTVENPTkYgY2xpZW50IGRlcGVuZHMgb24gaGF2aW5nIGEgcmVsaWFibGUgaW50ZXJm YWNlIHRvIHRhbGsgdG8uIFRoZXJlZm9yZSBhbiBhY3Rpb24gc2hhbGwgYmUgdGFrZW4sIHRvIG1h a2UgdGhlIFJGQyBkZWZpbml0aW9uIG1vcmUgcHJlY2lzZSBieSBwcm92aWRpbmcgYSBtb3JlIGRl dGFpbGVkIGRlc2NyaXB0aW9ucyBhbmQgZXhhbXBsZXMuDQooMikgVGhlcmUgaXMgYSBnZW5lcmlj IG5lZWQgdG8gcmV0cmlldmUgbGlzdCBkZXRhaWxzLCB3aXRob3V0IHJldHJpZXZpbmcgdGhlIGVu dGlyZSBsaXN0LiBJdCBzdGFydHMgd2l0aCB0aGUgZWFzeSBjaGVjaywgaWYgYSBsaXN0IGNvbnRh aW5zIGVudHJpZXMgb3IgaXMgZW1wdHkuIFRha2luZyB0aGlzIGlkZWEgb25lIHN0ZXAgZnVydGhl ciB3b3VsZCBiZSwgdG8gYXNrIGhvdyBtYW55IGVudHJpZXMgYSBsaXN0IGN1cnJlbnRseSBoYXMu IEkgYWxzbyByZW1lbWJlciB0aGVyZSB1c2VkIHRvIGJlIElFVEYgRFJBRlRTIHRhbGtpbmcgYWJv dXQgbWV0YS1kYXRhIC0gbGlrZSB3aGVuIGhhcyBhIGxpc3QgdXBkYXRlZCB0aGUgbGFzdCB0aW1l Lg0KDQpNaWdodCBiZSBnb29kIHRvIGhhdmUgc29tZSBmb2xsb3ctdXAgZGlzY3Vzc2lvbiB3aXRo IHRoZSB3aWRlciBjb21tdW5pdHksIG9uIGhvdyB3ZSB3YW50IHRvIGhhdmUgdGhvc2UgMiBpdGVt cyBhZGRyZXNzZWQuDQoNCkNoZWVycw0KL3dpc28NCg0KDQoNCg0KDQoNCu+7v09uIDE4LjAzLjE5 LCAxNjowMCwgIm5ldGNvbmYgb24gYmVoYWxmIG9mIEJhbMOhenMgTGVuZ3llbCIgPG5ldGNvbmYt Ym91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t PiB3cm90ZToNCg0KICAgIEFzIGEgcHJpdmF0ZSBvcGluaW9uOg0KICAgIA0KICAgIFByb3ZpZGlu ZyBhIGxpc3Qgd2l0aG91dCBrZXlzIGlzIGtpbmQgb2YgdXNlbGVzcy4gSU1ITyBrZXlzIHNob3Vs ZCANCiAgICBhbHdheXMgYmUgcHJlc2VudCBpZiB0aGUgbGlzdCBpcyBhbGxvd2VkIGJ5IGRlcHRo LiBJbiBteSB2aWV3IHRoZSANCiAgICBjb3JyZWN0IGFuc3dlciBpczoNCiAgICANCiAgICBFeGFt cGxlIDM6IG5vIHN1YnRyZWUgZmlsdGVyIGlzIHByb3ZpZGVkLCBtYXgtZGVwdGg9Mw0KICAgICAg ICAgICAgPHRvcCB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS8xLjIvY29uZmlnIj4N CiAgICAgICAgICAgICAgPHVzZXJzPg0KICAgICAgICAgICAgICAgIDx1c2VyPg0KICAgICAgICAg ICAgICAgICAgIDxuYW1lPkpvZTwvbmFtZT4NCiAgICAgICAgICAgICAgICA8L3VzZXI+DQogICAg ICAgICAgICAgICAgPHVzZXI+DQogICAgICAgICAgICAgICAgICAgPG5hbWU+QmlsbDwvbmFtZT4N CiAgICAgICAgICAgICAgICA8L3VzZXI+DQogICAgICAgICAgICAgICAgPHVzZXI+DQogICAgICAg ICAgICAgICAgICAgPG5hbWU+QmFsYXpzPC9uYW1lPg0KICAgICAgICAgICAgICAgIDwvdXNlcj4N CiAgICAgICAgICAgICAgPC91c2Vycz4NCiAgICAgICAgICAgIDwvdG9wPg0KICAgIA0KICAgIFNv IGV2ZW4gaWYgdGhlIGtleSBuYW1lIGlzIHN0cmljdGx5IHNwZWFraW5nIG9uIGRlcHRoPTQgaXQg c2hvdWxkIGJlIA0KICAgIGluY2x1ZGVkIGluIGEgbGV2ZWwgMyBnZXQgcmVzdWx0Lg0KICAgIA0K ICAgIHJlZ2FyZHMgQmFsYXpzDQogICAgDQogICAgT24gMjAxOS4gMDMuIDE0LiA5OjUzLCBXaXNv dHpreSwgU3ZlbiAoTm9raWEgLSBERS9TdHV0dGdhcnQpIHdyb3RlOg0KICAgID4gVW5mb3J0dW5h dGVseSB0aGUgaW5mbyBwcm92aWRlZCBpbiBSRkMgODUyNiBhYm91dCB0aGUgbWF4LWRlcHRoIGF0 dHJpYnV0ZSBpcyBub3QgdmVyeSBwcmVjaXNlLg0KICAgID4gSXMgaXQgZmFpciB0byBhc3N1bWUs IHRoYXQgYmVoYXZpb3IgaXMgYWxpZ25lZCB3aXRoIHRoZSBSRVNUQ09ORiAiZGVwdGgiIGF0dHJp YnV0ZSBkZXNjcmliZWQgaW4gUkZDIDgwNDA/DQogICAgPg0KICAgID4gTGV0J3MgdXNlIHRoZSBm b2xsb3dpbmcgc2FtcGxlIGZyb20gY2hhcHRlciAzLjEuMS4zOg0KICAgID4gICAgICAgICA8dG9w IHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hLzEuMi9jb25maWciPg0KICAgID4gICAg ICAgICAgIDx1c2Vycz4NCiAgICA+ICAgICAgICAgICAgIDx1c2VyPg0KICAgID4gICAgICAgICAg ICAgICA8bmFtZT5yb290PC9uYW1lPg0KICAgID4gICAgICAgICAgICAgICA8dHlwZT5zdXBlcnVz ZXI8L3R5cGU+DQogICAgPiAgICAgICAgICAgICAgIDxmdWxsLW5hbWU+Q2hhcmxpZSBSb290PC9m dWxsLW5hbWU+DQogICAgPiAgICAgICAgICAgICAgIDxjb21wYW55LWluZm8+DQogICAgPiAgICAg ICAgICAgICAgICAgPGRlcHQ+MTwvZGVwdD4NCiAgICA+ICAgICAgICAgICAgICAgICA8aWQ+MTwv aWQ+DQogICAgPiAgICAgICAgICAgICAgIDwvY29tcGFueS1pbmZvPg0KICAgID4gICAgICAgICAg ICAgPC91c2VyPg0KICAgID4gICAgICAgICAgICAgPCEtLSBhZGRpdGlvbmFsIDx1c2VyPiBlbGVt ZW50cyBhcHBlYXIgaGVyZS4uLiAtLT4NCiAgICA+ICAgICAgICAgICA8L3VzZXJzPg0KICAgID4g ICAgICAgICA8L3RvcD4NCiAgICA+DQogICAgPiBFeGFtcGxlIDE6IG5vIHN1YnRyZWUgZmlsdGVy IGlzIHByb3ZpZGVkLCBtYXgtZGVwdGg9MQ0KICAgID4gICAgICAgICA8dG9wIHhtbG5zPSJodHRw Oi8vZXhhbXBsZS5jb20vc2NoZW1hLzEuMi9jb25maWciPg0KICAgID4gICAgICAgICA8L3RvcD4N CiAgICA+DQogICAgPiBFeGFtcGxlIDI6IG5vIHN1YnRyZWUgZmlsdGVyIGlzIHByb3ZpZGVkLCBt YXgtZGVwdGg9Mg0KICAgID4gICAgICAgICA8dG9wIHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20v c2NoZW1hLzEuMi9jb25maWciPg0KICAgID4gICAgICAgICAgIDx1c2Vycz4NCiAgICA+ICAgICAg ICAgICA8L3VzZXJzPg0KICAgID4gICAgICAgICA8L3RvcD4NCiAgICA+IEFzc3VtcHRpb24gdGhl IGNvbnRhaW5lciA8dXNlcnM+IHdvdWxkIG9ubHkgYmUgcHJlc2VudCBpbiB0aGUgcmVzdWx0LCBp ZiB0aGlzIGNvbnRhaW5lciBoYXMgYW55IGV4cGxpY2l0IGNoaWxkcmVuIGNvbmZpZ3VyYXRpb24u IElmIHRoZXJlIGlzIG5vIGNoaWxkcmVuIGNvbmZpZywgaXQgd291bGQgbm90IGJlIHBhcnQgb2Yg dGhlIG91dHB1dC4NCiAgICA+DQogICAgPiBFeGFtcGxlIDM6IG5vIHN1YnRyZWUgZmlsdGVyIGlz IHByb3ZpZGVkLCBtYXgtZGVwdGg9Mw0KICAgID4gICAgICAgICA8dG9wIHhtbG5zPSJodHRwOi8v ZXhhbXBsZS5jb20vc2NoZW1hLzEuMi9jb25maWciPg0KICAgID4gICAgICAgICAgIDx1c2Vycz4N CiAgICA+ICAgICAgICAgICAgIDx1c2VyPg0KICAgID4gICAgICAgICAgICAgPC91c2VyPg0KICAg ID4gICAgICAgICAgIDwvdXNlcnM+DQogICAgPiAgICAgICAgIDwvdG9wPg0KICAgID4gU29tZXdo YXQgaW50ZXJlc3Rpbmcgc2NlbmFyaW8uIEl0IHByb3ZpZGVzIHRoZSBuZXRjb25mIGNsaWVudCB3 aXRoIGEgbWV0aG9kIHRvIGNoZWNrLCBpZiBhIGxpc3QgY29udGFpbnMgYW55IGVudHJpZXMuIFNv IGlmIHRoZSBYTUwgbm9kZSA8dXNlcj4gaXMgY29udGFpbmVkLCB3ZSB3b3VsZCBrbm93IHRoYXQg dGhlIGxpc3QgInVzZXIiIGhhcyBhdCBsZWFzdCBvbmUgZW50cnkuIEhvd2V2ZXIsIHRoaXMgWE1M IG91dHB1dCB3b3VsZCBub3QgdmFsaWRhdGUgYWdhaW5zdCB0aGUgWUFORyBtb2RlbCAtIGJlY2F1 c2UgbGlzdC1rZXlzICh1c2VyL25hbWUpIGFyZSBtYW5kYXRvcnkuIEluIGVzc2VuY2UsIHRoYXQg Y2xpZW50IHJlcXVpcmVzIHRvIGJlIGZsZXhpYmxlIHdoZW4gcGFyc2luZyBzdWNoIHJlc3VsdCBh bmQgY2Fubm90IGJlIHJlc3RyaWN0ZWQgdG8gWUFORy4NCiAgICA+DQogICAgPiBFeGFtcGxlIDQ6 IG5vIHN1YnRyZWUgZmlsdGVyIGlzIHByb3ZpZGVkLCBtYXgtZGVwdGg9NA0KICAgID4gICAgICAg ICA8dG9wIHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hLzEuMi9jb25maWciPg0KICAg ID4gICAgICAgICAgIDx1c2Vycz4NCiAgICA+ICAgICAgICAgICAgIDx1c2VyPg0KICAgID4gICAg ICAgICAgICAgICA8bmFtZT5yb290PC9uYW1lPg0KICAgID4gICAgICAgICAgICAgICA8dHlwZT5z dXBlcnVzZXI8L3R5cGU+DQogICAgPiAgICAgICAgICAgICAgIDxmdWxsLW5hbWU+Q2hhcmxpZSBS b290PC9mdWxsLW5hbWU+DQogICAgPiAgICAgICAgICAgICAgIDxjb21wYW55LWluZm8+DQogICAg PiAgICAgICAgICAgICAgIDwvY29tcGFueS1pbmZvPg0KICAgID4gICAgICAgICAgICAgPC91c2Vy Pg0KICAgID4gICAgICAgICAgICAgPCEtLSBhZGRpdGlvbmFsIDx1c2VyPiBlbGVtZW50cyBhcHBl YXIgaGVyZS4uLiAtLT4NCiAgICA+ICAgICAgICAgICA8L3VzZXJzPg0KICAgID4gICAgICAgICA8 L3RvcD4NCiAgICA+IFNpbWlsYXIgdG8gZXhhbXBsZSAyLCB0aGUgY29udGFpbmVyIDxjb21wYW55 LWluZm8+IHdvdWxkIG9ubHkgYmUgcHJlc2VudCwgaWYgdGhpcyBjb250YWluZXIgaGFzIGV4cGxp Y2l0IGNoaWxkcmVuIGNvbmZpZ3VyYXRpb24uDQogICAgPg0KICAgID4NCiAgICA+IFNvbWVvbmUg cGxlYXNlIHRvIGNvbmZpcm0sIGlmIHRob3NlIGV4YW1wbGVzIGFuZCBhc3N1bXB0aW9ucyBiZWlu ZyBtYWRlIGFyZSBjb3JyZWN0IQ0KICAgID4NCiAgICA+IC93aXNvDQogICAgPg0KICAgID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IG5ldGNv bmYgbWFpbGluZyBsaXN0DQogICAgPiBuZXRjb25mQGlldGYub3JnDQogICAgPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCiAgICA+DQogICAgLS0gDQogICAg QmFsYXpzIExlbmd5ZWwgICAgICAgICAgICAgICAgICAgICAgIEVyaWNzc29uIEh1bmdhcnkgTHRk Lg0KICAgIFNlbmlvciBTcGVjaWFsaXN0DQogICAgTW9iaWxlOiArMzYtNzAtMzMwLTc5MDkgICAg ICAgICAgICAgIGVtYWlsOiBCYWxhenMuTGVuZ3llbEBlcmljc3Nvbi5jb20NCiAgICANCiAgICAN CiAgICANCg0K From nobody Mon Mar 18 22:39:45 2019 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 9C2A5130EFA for ; Mon, 18 Mar 2019 22:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mG_O3PO9mi8L for ; Mon, 18 Mar 2019 22:39:40 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40091.outbound.protection.outlook.com [40.107.4.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D6C51277CE for ; Mon, 18 Mar 2019 22:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6LAUh0b3e8Sm8+0IMcLyrmjrXOp8wgSIi9aqXofzhaI=; b=b0KT9rHaUOgWeSOp+Sz7CGWH1OhxUTrM1kuIcImKwSMgO/zaEKRxdrrKlPDrj8QSIHZPDKl7rjlasGS8pJiZYKsLWHBNYvH4F/kCqyFO1Msk7sr+nmyShCwDxv9F8ugr9lE2DMZNzQkBZAH78lTIjwlcfLaV34wRqmGwJ4SkwH4= Received: from AM6PR07MB5382.eurprd07.prod.outlook.com (20.178.91.74) by AM6PR07MB5060.eurprd07.prod.outlook.com (20.177.188.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.15; Tue, 19 Mar 2019 05:39:36 +0000 Received: from AM6PR07MB5382.eurprd07.prod.outlook.com ([fe80::8df:27dd:40f:ec82]) by AM6PR07MB5382.eurprd07.prod.outlook.com ([fe80::8df:27dd:40f:ec82%2]) with mapi id 15.20.1709.015; Tue, 19 Mar 2019 05:39:36 +0000 From: "Wisotzky, Sven (Nokia - DE/Stuttgart)" To: wangzitao , =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= CC: "netconf@ietf.org" Thread-Topic: [netconf] Usage examples for max-depth (rfc8526) Thread-Index: AdTeA8WykGakdwrtSgumgqfLSpkB8wAGr8oA Date: Tue, 19 Mar 2019 05:39:36 +0000 Message-ID: <0A40D464-BAE8-4B80-B06F-2910E14D313C@nokia.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.0.190309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=sven.wisotzky@nokia.com; x-originating-ip: [176.35.138.139] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b608e303-a0ec-49ba-d886-08d6ac2d461c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR07MB5060; x-ms-traffictypediagnostic: AM6PR07MB5060: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0981815F2F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(366004)(376002)(396003)(39860400002)(199004)(189003)(36756003)(446003)(81166006)(53376002)(6246003)(53936002)(105586002)(106356001)(68736007)(5660300002)(97736004)(82746002)(2906002)(8676002)(4326008)(71190400001)(83716004)(71200400001)(6512007)(6306002)(66066001)(33656002)(81156014)(7736002)(186003)(25786009)(66574012)(8936002)(3846002)(229853002)(6116002)(14444005)(102836004)(256004)(478600001)(99286004)(14454004)(486006)(6486002)(305945005)(6436002)(966005)(26005)(6506007)(316002)(86362001)(2616005)(110136005)(11346002)(76176011)(58126008)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB5060; H:AM6PR07MB5382.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: voBBWGRIBdP7U/UQ1ZgGHp27aox/Jmy6Z2IC+x43VbAEIkQlqK3TPs4XSx1V2qRVqYuou8C3FFVNe2z8KUPBO1yx4cfVyeWZyFeFISvIas9VDnZB4otHsFWLsTf1a11VFGLuI/hMFgFy5xVU8ybqqJCWn9k115TdAYLB+GhJhTSj6SVwpaS6JpHJPWnulV/ePscdYoH0QMWoi1ebPiKACFRDO/YNAZssh8EPhIF9ycJl+W1IosC/EqWeQenheClI37MIAc2LuG0ZZYRLWzYMzgSDXUMIX2aB5MKv/xN+Jpehwbw/HSUCaUnBMv5iYqAxzTI+FA2eGXJxsWrPC5M9OBEJFuqAVf84FPq13M9ze0AGHWiqCNlzclqTCl4q5rDUNepYOB5XndHJ5EYT/ju5ICb+4c2AI+aYPYxIzF6X0LQ= Content-Type: text/plain; charset="utf-8" Content-ID: <6470E81ADB16FA4BBCB14AD9EB366613@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: b608e303-a0ec-49ba-d886-08d6ac2d461c X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2019 05:39:36.7794 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5060 Archived-At: Subject: Re: [netconf] Usage examples for max-depth (rfc8526) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 05:39:43 -0000 TWljaGFlbCwNCg0KQWN0dWFsbHkgSSd2ZSBnb3QgYW4gdXNlLWNhc2UsIHdoaWNoIHJlcXVpcmVz IG1lIHRvIHVuZGVyc3RhbmQgaWYgYSBjb250YWluZXIgb3IgbGlzdCBjb250YWlucyBkYXRhL2Vu dHJpZXMgLSB3aGlsZSBJIHdvdWxkIGxpa2UgdG8gYXZvaWQgYXNraW5nIHRoZSBjb21wbGV0ZSBs aXN0cyBhcyBpdCBjb3VsZCBiZSBnaWdhbnRpYy4gSSB3YXMganVzdCB3b25kZXJpbmcgaWYgbWF4 LWRlcHRoIGlzIHRoZSByaWdodCB3YXkgb2YgaW1wbGVtZW50aW5nIG15IHVzZS1jYXNlLiBCdXQg aW4gdGhhdCBjYXNlLCBJIHdvdWxkIGFjdHVhbGx5IHByZWZlciwgaWYganVzdCBhIHNpbmdsZSBp bnN0YW5jZSBvZiA8dXNlci8+IGlzIHJldHVybmVkLiBJZiB3ZSB3b3VsZCByZXR1cm4gdGhlIGVt cHR5IDx1c2VyLz4gZWxlbWVudCBmb3IgYWxsIGxpc3QgZW50cmllcyAtIGl0IHdvdWxkIGJlY29t ZSBhIHdheSB0byB0ZWxsIHRoZSBjbGllbnQgdGhlIG51bWJlciBvZiBsaXN0IGVudHJpZXMsIHdo aWNoIHdvdWxkIGJlIHVzZWZ1bCBmb3IgbWUgYXMgd2VsbCAtIGJ1dCB2ZXJ5IGluZWZmaWNpZW50 Lg0KDQovd2lzbw0KLS0tDQoNCu+7v09uIDE5LjAzLjE5LCAwMzozNiwgIm5ldGNvbmYgb24gYmVo YWxmIG9mIHdhbmd6aXRhbyIgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yg d2FuZ3ppdGFvQGh1YXdlaS5jb20+IHdyb3RlOg0KDQogICAgDQogICAgLS0tLS3pgq7ku7bljp/k u7YtLS0tLQ0KICAgIOWPkeS7tuS6ujogbmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0Bp ZXRmLm9yZ10g5Luj6KGoIEJhbMOhenMgTGVuZ3llbA0KICAgIOWPkemAgeaXtumXtDogMjAxOeW5 tDPmnIgxOOaXpSAyMzowMA0KICAgIOaUtuS7tuS6ujogbmV0Y29uZkBpZXRmLm9yZw0KICAgIOS4 u+mimDogUmU6IFtuZXRjb25mXSBVc2FnZSBleGFtcGxlcyBmb3IgbWF4LWRlcHRoIChyZmM4NTI2 KQ0KICAgIA0KICAgIEFzIGEgcHJpdmF0ZSBvcGluaW9uOg0KICAgIA0KICAgIFByb3ZpZGluZyBh IGxpc3Qgd2l0aG91dCBrZXlzIGlzIGtpbmQgb2YgdXNlbGVzcy4gSU1ITyBrZXlzIHNob3VsZCBh bHdheXMgYmUgcHJlc2VudCBpZiB0aGUgbGlzdCBpcyBhbGxvd2VkIGJ5IGRlcHRoLiBJbiBteSB2 aWV3IHRoZSBjb3JyZWN0IGFuc3dlciBpczoNCiAgICANCiAgICBFeGFtcGxlIDM6IG5vIHN1YnRy ZWUgZmlsdGVyIGlzIHByb3ZpZGVkLCBtYXgtZGVwdGg9Mw0KICAgICAgICAgICAgPHRvcCB4bWxu cz0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS8xLjIvY29uZmlnIj4NCiAgICAgICAgICAgICAg PHVzZXJzPg0KICAgICAgICAgICAgICAgIDx1c2VyPg0KICAgICAgICAgICAgICAgICAgIDxuYW1l PkpvZTwvbmFtZT4NCiAgICAgICAgICAgICAgICA8L3VzZXI+DQogICAgICAgICAgICAgICAgPHVz ZXI+DQogICAgICAgICAgICAgICAgICAgPG5hbWU+QmlsbDwvbmFtZT4NCiAgICAgICAgICAgICAg ICA8L3VzZXI+DQogICAgICAgICAgICAgICAgPHVzZXI+DQogICAgICAgICAgICAgICAgICAgPG5h bWU+QmFsYXpzPC9uYW1lPg0KICAgICAgICAgICAgICAgIDwvdXNlcj4NCiAgICAgICAgICAgICAg PC91c2Vycz4NCiAgICAgICAgICAgIDwvdG9wPg0KICAgIA0KICAgIFNvIGV2ZW4gaWYgdGhlIGtl eSBuYW1lIGlzIHN0cmljdGx5IHNwZWFraW5nIG9uIGRlcHRoPTQgaXQgc2hvdWxkIGJlIGluY2x1 ZGVkIGluIGEgbGV2ZWwgMyBnZXQgcmVzdWx0Lg0KICAgIA0KICAgIFtNaWNoYWVsXTogQmFzZWQg b24gUkZDODA0MCwgaXQgd2lsbCBvbmx5IG91dHB1dCB0aGUgPHVzZXI+IGxpc3QgbGV2ZWwgKGRl cHRoIDQpLCBob3dldmVyLCBmb3IgYSBsaXN0IHdpdGhvdXQga2V5IGFuZCBhbnRoZXIgcGFyYW1l dGVycywgaXQgZG9lc24ndCBzZWVtIHRvIGJlIG1lYW5pbmdmdWwuDQogICAgDQogICAgcmVnYXJk cyBCYWxhenMNCiAgICANCiAgICBPbiAyMDE5LiAwMy4gMTQuIDk6NTMsIFdpc290emt5LCBTdmVu IChOb2tpYSAtIERFL1N0dXR0Z2FydCkgd3JvdGU6DQogICAgPiBVbmZvcnR1bmF0ZWx5IHRoZSBp bmZvIHByb3ZpZGVkIGluIFJGQyA4NTI2IGFib3V0IHRoZSBtYXgtZGVwdGggYXR0cmlidXRlIGlz IG5vdCB2ZXJ5IHByZWNpc2UuDQogICAgPiBJcyBpdCBmYWlyIHRvIGFzc3VtZSwgdGhhdCBiZWhh dmlvciBpcyBhbGlnbmVkIHdpdGggdGhlIFJFU1RDT05GICJkZXB0aCIgYXR0cmlidXRlIGRlc2Ny aWJlZCBpbiBSRkMgODA0MD8NCiAgICA+DQogICAgPiBMZXQncyB1c2UgdGhlIGZvbGxvd2luZyBz YW1wbGUgZnJvbSBjaGFwdGVyIDMuMS4xLjM6DQogICAgPiAgICAgICAgIDx0b3AgeG1sbnM9Imh0 dHA6Ly9leGFtcGxlLmNvbS9zY2hlbWEvMS4yL2NvbmZpZyI+DQogICAgPiAgICAgICAgICAgPHVz ZXJzPg0KICAgID4gICAgICAgICAgICAgPHVzZXI+DQogICAgPiAgICAgICAgICAgICAgIDxuYW1l PnJvb3Q8L25hbWU+DQogICAgPiAgICAgICAgICAgICAgIDx0eXBlPnN1cGVydXNlcjwvdHlwZT4N CiAgICA+ICAgICAgICAgICAgICAgPGZ1bGwtbmFtZT5DaGFybGllIFJvb3Q8L2Z1bGwtbmFtZT4N CiAgICA+ICAgICAgICAgICAgICAgPGNvbXBhbnktaW5mbz4NCiAgICA+ICAgICAgICAgICAgICAg ICA8ZGVwdD4xPC9kZXB0Pg0KICAgID4gICAgICAgICAgICAgICAgIDxpZD4xPC9pZD4NCiAgICA+ ICAgICAgICAgICAgICAgPC9jb21wYW55LWluZm8+DQogICAgPiAgICAgICAgICAgICA8L3VzZXI+ DQogICAgPiAgICAgICAgICAgICA8IS0tIGFkZGl0aW9uYWwgPHVzZXI+IGVsZW1lbnRzIGFwcGVh ciBoZXJlLi4uIC0tPg0KICAgID4gICAgICAgICAgIDwvdXNlcnM+DQogICAgPiAgICAgICAgIDwv dG9wPg0KICAgID4NCiAgICA+IEV4YW1wbGUgMTogbm8gc3VidHJlZSBmaWx0ZXIgaXMgcHJvdmlk ZWQsIG1heC1kZXB0aD0xDQogICAgPiAgICAgICAgIDx0b3AgeG1sbnM9Imh0dHA6Ly9leGFtcGxl LmNvbS9zY2hlbWEvMS4yL2NvbmZpZyI+DQogICAgPiAgICAgICAgIDwvdG9wPg0KICAgID4NCiAg ICA+IEV4YW1wbGUgMjogbm8gc3VidHJlZSBmaWx0ZXIgaXMgcHJvdmlkZWQsIG1heC1kZXB0aD0y DQogICAgPiAgICAgICAgIDx0b3AgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9zY2hlbWEvMS4y L2NvbmZpZyI+DQogICAgPiAgICAgICAgICAgPHVzZXJzPg0KICAgID4gICAgICAgICAgIDwvdXNl cnM+DQogICAgPiAgICAgICAgIDwvdG9wPg0KICAgID4gQXNzdW1wdGlvbiB0aGUgY29udGFpbmVy IDx1c2Vycz4gd291bGQgb25seSBiZSBwcmVzZW50IGluIHRoZSByZXN1bHQsIGlmIHRoaXMgY29u dGFpbmVyIGhhcyBhbnkgZXhwbGljaXQgY2hpbGRyZW4gY29uZmlndXJhdGlvbi4gSWYgdGhlcmUg aXMgbm8gY2hpbGRyZW4gY29uZmlnLCBpdCB3b3VsZCBub3QgYmUgcGFydCBvZiB0aGUgb3V0cHV0 Lg0KICAgID4NCiAgICA+IEV4YW1wbGUgMzogbm8gc3VidHJlZSBmaWx0ZXIgaXMgcHJvdmlkZWQs IG1heC1kZXB0aD0zDQogICAgPiAgICAgICAgIDx0b3AgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNv bS9zY2hlbWEvMS4yL2NvbmZpZyI+DQogICAgPiAgICAgICAgICAgPHVzZXJzPg0KICAgID4gICAg ICAgICAgICAgPHVzZXI+DQogICAgPiAgICAgICAgICAgICA8L3VzZXI+DQogICAgPiAgICAgICAg ICAgPC91c2Vycz4NCiAgICA+ICAgICAgICAgPC90b3A+DQogICAgPiBTb21ld2hhdCBpbnRlcmVz dGluZyBzY2VuYXJpby4gSXQgcHJvdmlkZXMgdGhlIG5ldGNvbmYgY2xpZW50IHdpdGggYSBtZXRo b2QgdG8gY2hlY2ssIGlmIGEgbGlzdCBjb250YWlucyBhbnkgZW50cmllcy4gU28gaWYgdGhlIFhN TCBub2RlIDx1c2VyPiBpcyBjb250YWluZWQsIHdlIHdvdWxkIGtub3cgdGhhdCB0aGUgbGlzdCAi dXNlciIgaGFzIGF0IGxlYXN0IG9uZSBlbnRyeS4gSG93ZXZlciwgdGhpcyBYTUwgb3V0cHV0IHdv dWxkIG5vdCB2YWxpZGF0ZSBhZ2FpbnN0IHRoZSBZQU5HIG1vZGVsIC0gYmVjYXVzZSBsaXN0LWtl eXMgKHVzZXIvbmFtZSkgYXJlIG1hbmRhdG9yeS4gSW4gZXNzZW5jZSwgdGhhdCBjbGllbnQgcmVx dWlyZXMgdG8gYmUgZmxleGlibGUgd2hlbiBwYXJzaW5nIHN1Y2ggcmVzdWx0IGFuZCBjYW5ub3Qg YmUgcmVzdHJpY3RlZCB0byBZQU5HLg0KICAgID4NCiAgICA+IEV4YW1wbGUgNDogbm8gc3VidHJl ZSBmaWx0ZXIgaXMgcHJvdmlkZWQsIG1heC1kZXB0aD00DQogICAgPiAgICAgICAgIDx0b3AgeG1s bnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9zY2hlbWEvMS4yL2NvbmZpZyI+DQogICAgPiAgICAgICAg ICAgPHVzZXJzPg0KICAgID4gICAgICAgICAgICAgPHVzZXI+DQogICAgPiAgICAgICAgICAgICAg IDxuYW1lPnJvb3Q8L25hbWU+DQogICAgPiAgICAgICAgICAgICAgIDx0eXBlPnN1cGVydXNlcjwv dHlwZT4NCiAgICA+ICAgICAgICAgICAgICAgPGZ1bGwtbmFtZT5DaGFybGllIFJvb3Q8L2Z1bGwt bmFtZT4NCiAgICA+ICAgICAgICAgICAgICAgPGNvbXBhbnktaW5mbz4NCiAgICA+ICAgICAgICAg ICAgICAgPC9jb21wYW55LWluZm8+DQogICAgPiAgICAgICAgICAgICA8L3VzZXI+DQogICAgPiAg ICAgICAgICAgICA8IS0tIGFkZGl0aW9uYWwgPHVzZXI+IGVsZW1lbnRzIGFwcGVhciBoZXJlLi4u IC0tPg0KICAgID4gICAgICAgICAgIDwvdXNlcnM+DQogICAgPiAgICAgICAgIDwvdG9wPg0KICAg ID4gU2ltaWxhciB0byBleGFtcGxlIDIsIHRoZSBjb250YWluZXIgPGNvbXBhbnktaW5mbz4gd291 bGQgb25seSBiZSBwcmVzZW50LCBpZiB0aGlzIGNvbnRhaW5lciBoYXMgZXhwbGljaXQgY2hpbGRy ZW4gY29uZmlndXJhdGlvbi4NCiAgICA+DQogICAgPg0KICAgID4gU29tZW9uZSBwbGVhc2UgdG8g Y29uZmlybSwgaWYgdGhvc2UgZXhhbXBsZXMgYW5kIGFzc3VtcHRpb25zIGJlaW5nIG1hZGUgYXJl IGNvcnJlY3QhDQogICAgPg0KICAgID4gL3dpc28NCiAgICA+DQogICAgPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gbmV0Y29uZiBtYWlsaW5n IGxpc3QNCiAgICA+IG5ldGNvbmZAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KICAgID4NCiAgICAtLSANCiAgICBCYWxhenMgTGVu Z3llbCAgICAgICAgICAgICAgICAgICAgICAgRXJpY3Nzb24gSHVuZ2FyeSBMdGQuDQogICAgU2Vu aW9yIFNwZWNpYWxpc3QNCiAgICBNb2JpbGU6ICszNi03MC0zMzAtNzkwOSAgICAgICAgICAgICAg ZW1haWw6IEJhbGF6cy5MZW5neWVsQGVyaWNzc29uLmNvbQ0KICAgIA0KICAgIA0KICAgIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgbmV0Y29uZiBt YWlsaW5nIGxpc3QNCiAgICBuZXRjb25mQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQogICAgDQoNCg== From nobody Thu Mar 21 07:24:39 2019 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 88A0B1310BE for ; Thu, 21 Mar 2019 07:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=GWdSnHEl; dkim=pass (1024-bit key) header.d=ericsson.com header.b=BD30eChl 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 7n8pY78RKcQJ for ; Thu, 21 Mar 2019 07:24:35 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 6B6B713107B for ; Thu, 21 Mar 2019 07:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1553178273; x=1555770273; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=cmnJ0eB4ydJDoCLSP6r7X6dDggXaJ8wlFevmqGCHIrY=; b=GWdSnHEl69ubqRaMZOV9T6huAzUENCt4JpIas7LO8kHHACiNmc5YCStM/PLzKrk2 BUAYiIVnkhFs4KGoWX+TKoEGrzpuyZSZcFtZbGajZ7V8FDgNFLnpTMNf+R9KG6lC NGbFcLxV43y7iUSOR8PK9Xee/UbXZ4JjMHZi9cmKvtk=; X-AuditID: c1b4fb30-777759e000007fec-c1-5c939ea1da50 Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 53.CC.32748.1AE939C5; Thu, 21 Mar 2019 15:24:33 +0100 (CET) Received: from ESESSMR501.ericsson.se (153.88.183.108) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 21 Mar 2019 15:23:44 +0100 Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSMR501.ericsson.se (153.88.183.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 21 Mar 2019 15:23:39 +0100 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Thu, 21 Mar 2019 15:23:38 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cmnJ0eB4ydJDoCLSP6r7X6dDggXaJ8wlFevmqGCHIrY=; b=BD30eChl6zaU+SKUONxF5wogb0jsEXbRArsH0sQdSdF8mADPgdtALGp2qUOUVgcrLBaQpS02a0xYFQlT2xul5pqp671jLdP5NtbkU8zvgBY/JWl1qA4u7ibxZNmYPRrBCmLYqWkra6ZWynm95gBEoHDJ/HhT1mooDDIvKvtPNks= Received: from VI1PR07MB4735.eurprd07.prod.outlook.com (20.177.57.146) by VI1PR07MB4671.eurprd07.prod.outlook.com (20.177.57.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.16; Thu, 21 Mar 2019 14:23:27 +0000 Received: from VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::807b:cd48:c48:cf03]) by VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::807b:cd48:c48:cf03%4]) with mapi id 15.20.1730.013; Thu, 21 Mar 2019 14:23:27 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Kov=E1cs?= To: "netconf@ietf.org" , Kent Watsen Thread-Topic: ietf crypto types - permanently hidden Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpA== Date: Thu, 21 Mar 2019 14:23:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com; x-originating-ip: [2a02:ab88:2cb8:5600:59d2:9436:ebbf:9e59] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 989c158f-3a91-4772-22b0-08d6ae08c8d0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB4671; x-ms-traffictypediagnostic: VI1PR07MB4671: x-microsoft-antispam-prvs: x-forefront-prvs: 0983EAD6B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(396003)(346002)(136003)(366004)(189003)(199004)(7736002)(97736004)(74316002)(33656002)(102836004)(6306002)(81166006)(14444005)(68736007)(256004)(54896002)(106356001)(9686003)(55016002)(110136005)(99286004)(316002)(71190400001)(71200400001)(53936002)(14454004)(186003)(486006)(478600001)(52536014)(25786009)(476003)(5660300002)(46003)(2906002)(6506007)(81156014)(105586002)(7696005)(6436002)(6116002)(9326002)(790700001)(8936002)(8676002)(2501003)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4671; H:VI1PR07MB4735.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 6F2TGZXNYDv+YkWgOSUPOvxTM0/IkJvktp12UQihXpB97DIhxa458Bwd9HKgcddvC9pLDsl477nfEKaZj4u//Y5opSm5yk1nF3YekfDoDcKtWiD/Ai79aHPNCWqQkEQaIKvM8OAh3+12eJC7aSGD6N5HDjynI6BAlaJ6lp4bybrGjHRMTL0kXbsPN2w6Ds2VKu7UVrS0FSPzPkHHiCPeDvywHIactifcnsWxp/xcFM+XIGsAANWkIIbVC+vfnBBN6PpIdYO94NI59hkZwE7R45Mds9LNiI/n+I0zusKn6XKaIdLtxxWZS6WObb3IAo36FRxmAiYwCqqNzw0tjF+HeSw9tJfscsX6ghoty6Gqfeg9tDc0kELGfRgvIAIZfW/wosa+LIMp122aGe/oBuIlb2ev/ZjIwLbxmEQ/1nHAFtw= Content-Type: multipart/alternative; boundary="_000_VI1PR07MB4735863E79020AD84C4FDF9483420VI1PR07MB4735eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 989c158f-3a91-4772-22b0-08d6ae08c8d0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2019 14:23:27.0908 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4671 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTURzHO/febVdxclyaPyzFBoEzfCSGQqkFSYsSJEQiDVt5ceJ78xlJ Ypo6K5ePUou2xVQSe2gjLWfYepBGDAMr1zJF06ZRYGlZc+Z2V/jf5/s453d+cGhS0MXxodOz 8xlZtiRTyHWlWo70Fgdprjckh35f9Ii8aZrkRTb1vOfsIcRa7TIhnnqh4MUTR113pzKZ6YWM LCT6uKt0pWOQyB2JKDZZBzhlSB2qQC404HCYGbbyFMiVFuCnCO7VaylWLCHQTYzz/ouvUxaS FVoCurQDhF1QWEnC5HObs1ZPwFx3o7M2geBDpYFrH8PFsfCpZZlnZ08shonWH5SdN+IQUF9T Ov1wsLV9JFgOhvL2UUeHwtvA3GlECkTTfJwMtW+22m2EN8HP4S5HncTeYJpWEexGGLR6I8my F1imbBy2fwz65s081t8F5WdfOfu+8FpVi1iOg2vWOscygMcQtFWruWwQCKplo5MzwNJ30clb 4M7YDYI90MyBuhq9Y5oAM9Bxq9J5qx90Xpik2JKRhPGeEcQ+OwdWVN1cJRK1rtuidV1kZz72 gKGWaYr1g+FdUyOX5e3QrpknWQ6CZpuBWu+rEa8TeckZ+YmstLCwYEaWflIuz8kOzmbye9Da H3qs+xPahyyzew0I00joxt9/uSFZwJEUykuyDAhoUujJf5i0ZvFTJSWnGFlOiqwgk5Eb0Gaa EnrzrQKPZAFOk+QzGQyTy8j+pQTt4lOGEvweFFaIE8+t3j1tfilK2KdcGJIWnXkSXdbQtghf SgO+xSRt0PjnEe6PTKK4Q7rhXzURVxe1idXPBr2im0srGqpqi5qiRP7xt/W9WVVReqlmdKY6 tir/gO9q3iW3+NmFgvaDbxNEtvvcK7/Pp8ToKpbGV/rnPpt39gd4HnYXlXCElFwq2RFIyuSS vyKuwgc/AwAA Archived-At: Subject: [netconf] ietf crypto types - permanently hidden 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, 21 Mar 2019 14:24:38 -0000 --_000_VI1PR07MB4735863E79020AD84C4FDF9483420VI1PR07MB4735eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The 'generate-hidden-key' action is meant for cases when the key must be ge= nerated in the device and not the operator is configuring it. The 'generate= -hidden-key' is said to produce a 'permanently-hidden' asymmetric key. The = description of 'permanently-hidden' is as follows: "The private key is inaccessible due to being protected by the system (e.g., a cryptographic hardware module). It is not possible to configure a permanently hidden key, as a real private key value must be set. Permanently hidden keys cannot be archived or backed up."; Th second sentence doesn't sound right. I can create a permanently hidden k= ey any time by calling the 'generate-hidden-key' action, or if the device o= r the model allows I could even switch to non-hidden key, I believe, by pro= viding the binary. So I find the second sentence irrelevant in this descrip= tion. More importantly, I find the "Permanently hidden keys cannot be archived or= backed up" statement false. Isn't that implementation specific how archivi= ng is done? If a device puts the hidden keys on some storage, it may still = be possible to back them up. I would prefer to remove this sentence and lea= ve backup considerations to implementations. Could these changes be done? Br, Balazs --_000_VI1PR07MB4735863E79020AD84C4FDF9483420VI1PR07MB4735eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

The ‘generate-hidden-key’ action is mean= t for cases when the key must be generated in the device and not the operat= or is configuring it. The ‘generate-hidden-key’ is said to prod= uce a ‘permanently-hidden’ asymmetric key. The description of ‘permanently-hidden’ is as follows:

 

        &nbs= p;       "The private key is inaccessibl= e due to being

        &nbs= p;         protected by the system = (e.g., a cryptographic

        &nbs= p;         hardware module).  = It is not possible to

        &nbs= p;         configure a permanently = hidden key, as a real

        &nbs= p;         private key value must b= e set.  Permanently

        &nbs= p;         hidden keys cannot be ar= chived or backed up.";

 

Th second sentence doesn’t sound right. I can = create a permanently hidden key any time by calling the ‘generate-hid= den-key’ action, or if the device or the model allows I could even sw= itch to non-hidden key, I believe, by providing the binary. So I find the second sentence irrelevant in this description.=

 

More importantly, I find the “Permanently hidd= en keys cannot be archived or backed up” statement false. Isn’t= that implementation specific how archiving is done? If a device puts the h= idden keys on some storage, it may still be possible to back them up. I would prefer to remove this sentence and leave backup c= onsiderations to implementations.

 

Could these changes be done?

 

Br,

Balazs

--_000_VI1PR07MB4735863E79020AD84C4FDF9483420VI1PR07MB4735eurp_-- From nobody Thu Mar 21 07:54:17 2019 Return-Path: <01000169a0becf2a-5f004be0-a74d-4f9b-b456-f8c3309fac94-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 5EB1A1311FB for ; Thu, 21 Mar 2019 07:54:16 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 Qf9CsYTMx-3P for ; Thu, 21 Mar 2019 07:54:15 -0700 (PDT) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E33761311E3 for ; Thu, 21 Mar 2019 07:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553180053; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:Cc:To:Feedback-ID; bh=OOmGJMj90wREs6dxmHdlbxWv5uaTzuVfDzvZJSUBNwo=; b=i5Ll12ROvJr5IAfzHaP2TC/+eDAhBY0kioTRDXtzbLvmffctldTuiA4ZAYKVxAPj QOYTlqjAMoNSbgE7S7phS3mf3kgwhRWZ+25bkhYYx0jaGmglkBTSX1/bKVg8DOyjxBJ QO3FtMZwRjaRG2Baaq5w84M2tkeWEzaySPw/nlm0= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_CDCAD752-FA91-4BEA-BB82-37A7750E8469" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-ID: <01000169a0becf2a-5f004be0-a74d-4f9b-b456-f8c3309fac94-000000@email.amazonses.com> Date: Thu, 21 Mar 2019 14:54:13 +0000 Cc: "netconf@ietf.org" To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.21-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] why did we breakout the groupings? 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, 21 Mar 2019 14:54:17 -0000 --Apple-Mail=_CDCAD752-FA91-4BEA-BB82-37A7750E8469 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Balazs, I'm in the middle of answering your other question when I was reminded = that I've been meaning to follow up with you on this issue... Can you please help me recall why several months back we made the = decision to redefine the ietf-ssh-[client/server]-grouping statements to = use other groupings? For instance, here's the current definition: grouping ssh-client-grouping { uses client-identity-grouping; uses server-auth-grouping; uses transport-params-grouping; uses keepalives-grouping; } Obviously it was because you (I think it was you) wanted to be able to = "use" the inner grouping in another context, but why? I ask because this strategy is percolating into all of the client/server = models and it seems weird, if not wrong. I currently have it as an = "open issue" in my presentation for Monday, but I'd rather resolve it = offline/now if possible. Kent // contributor --Apple-Mail=_CDCAD752-FA91-4BEA-BB82-37A7750E8469 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Balazs,

I'm in the middle of answering your = other question when I was reminded that I've been meaning to follow up = with you on this issue...

Can you please help me recall why several months back we made = the decision to redefine the ietf-ssh-[client/server]-grouping = statements to use other groupings?  For instance, here's the = current definition:

  =   grouping ssh-client-grouping {
  =      uses client-identity-grouping;
       uses server-auth-grouping;
      =  uses transport-params-grouping;
    =    uses keepalives-grouping;
    =  }

Obviously = it was because you (I think it was you) wanted to be able to "use" the = inner grouping in another context, but why?

I ask because this strategy is percolating into = all of the client/server models and it seems weird, if not wrong. =  I currently have it as an "open issue" in my presentation for = Monday, but I'd rather resolve it offline/now if possible.

Kent // contributor



= --Apple-Mail=_CDCAD752-FA91-4BEA-BB82-37A7750E8469-- From nobody Thu Mar 21 08:12:04 2019 Return-Path: <01000169a0cef427-41bd3e75-23f6-4ce7-831e-81ec4b6b0d6f-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 5F6C21311C4 for ; Thu, 21 Mar 2019 08:11:56 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 iapcjlnHjh2z for ; Thu, 21 Mar 2019 08:11:54 -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 CA47F1311C5 for ; Thu, 21 Mar 2019 08:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553181111; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=hxb7BmYG7aIL7H48wgu6kfgcYZFDjynt6B5zA3LG/Aw=; b=FaD0Ft09nflWhxus7KUMFtP2/Ntxdd6sRXDdruwwL/OTtwKO4jqImxs4HRgwqfPA jTHSCVRfRCANs+1HH1nadMIt1lXchNmkp6bZfRDr9DYj1alBzTx+N1PR1HQW6IJiixp Ygno8OE/2+feGLixn3qSDCeNW+GBXVFkvW70OCwM= From: Kent Watsen Message-ID: <01000169a0cef427-41bd3e75-23f6-4ce7-831e-81ec4b6b0d6f-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_93843DAB-D38C-457B-BFAA-27A6F9B4EC0D" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 21 Mar 2019 15:11:51 +0000 In-Reply-To: Cc: "netconf@ietf.org" , Henk Birkholz To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= References: X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.21-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden 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, 21 Mar 2019 15:12:02 -0000 --Apple-Mail=_93843DAB-D38C-457B-BFAA-27A6F9B4EC0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [CC-ing Henk, who knows a little about TPMs] Hi Balazs, > The =E2=80=98generate-hidden-key=E2=80=99 action is meant for cases = when the key must be generated in the device and not the operator is = configuring it. The =E2=80=98generate-hidden-key=E2=80=99 is said to = produce a =E2=80=98permanently-hidden=E2=80=99 asymmetric key. The = description of =E2=80=98permanently-hidden=E2=80=99 is as follows: > =20 > "The private key is inaccessible due to being > protected by the system (e.g., a cryptographic > hardware module). It is not possible to > configure a permanently hidden key, as a real > private key value must be set. Permanently > hidden keys cannot be archived or backed up."; > =20 > Th second sentence doesn=E2=80=99t sound right. I can create a = permanently hidden key any time by calling the =E2=80=98generate-hidden-ke= y=E2=80=99 action, True, but *when* the action is called is not pertinent, right? > or if the device or the model allows I could even switch to non-hidden = key, I believe, by providing the binary. How would you get the binary? Yes, some implementations, as a hack, = MAY not actually use a cryptographic processor, but that is besides the = point. The intent with this action statement is that a cryptographic = processor IS used and that the private key is forever hidden. > So I find the second sentence irrelevant in this description. > =20 > More importantly, I find the =E2=80=9CPermanently hidden keys cannot = be archived or backed up=E2=80=9D statement false. Isn=E2=80=99t that = implementation specific how archiving is done? If a device puts the = hidden keys on some storage, it may still be possible to back them up. Maybe. I am aware that e.g., TPMs, have the ability to backup a key = but, I think that doing so necessitates that the key is encrypted with = the SRK (storage root key) such that only the same TPM chip can decode = it (Henk, can you check me on this statement?). To this end, I agree = that the last sentence is too strongly worded. > I would prefer to remove this sentence and leave backup considerations = to implementations. Remove or replace, let's keep the conversation going.=20 > Could these changes be done? Sure, pending the outcome of this thread. Kent // contributor --Apple-Mail=_93843DAB-D38C-457B-BFAA-27A6F9B4EC0D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
[CC-ing Henk, who knows a little about TPMs]


Hi = Balazs,

The = =E2=80=98generate-hidden-key=E2=80=99 action is meant for cases when the = key must be generated in the device and not the operator is configuring = it. The =E2=80=98generate-hidden-key=E2=80=99 is said to produce a = =E2=80=98permanently-hidden=E2=80=99 asymmetric key. The description of = =E2=80=98permanently-hidden=E2=80=99 is as follows:
 
          &nb= sp;     "The private key is inaccessible due to = being
          &nb= sp;       protected by the system (e.g., a = cryptographic
          &nb= sp;       hardware module).  It is = not possible to
          &nb= sp;       configure a permanently hidden = key, as a real
          &nb= sp;       private key value must be = set.  Permanently
          &nb= sp;       hidden keys cannot be archived = or backed up.";
 
Th second sentence doesn=E2=80=99t sound right. I can create = a permanently hidden key any time by calling the = =E2=80=98generate-hidden-key=E2=80=99 action, =

True, but = *when* the action is called is not pertinent, right?

or if the = device or the model allows I could even switch to non-hidden key, I = believe, by providing the binary. =

How would = you get the binary?   Yes, some implementations, as a hack, MAY not = actually use a cryptographic processor, but that is besides the point. =   The intent with this action statement is that a cryptographic = processor IS used and that the private key is forever = hidden.


So I find the second = sentence irrelevant in this = description.
 
More = importantly, I find the =E2=80=9CPermanently hidden keys cannot be = archived or backed up=E2=80=9D statement false. Isn=E2=80=99t that = implementation specific how archiving is done? If a device puts the = hidden keys on some storage, it may still be possible to back them up. =

Maybe. =  I am aware that e.g., TPMs, have the ability to backup a key but, = I think that doing so necessitates that the key is encrypted with the = SRK (storage root key) such that only the same TPM chip can decode it = (Henk, can you check me on this statement?).  To this end, I agree = that the last sentence is too strongly worded.

I would = prefer to remove this sentence and leave backup considerations to = implementations.

Remove or replace, let's keep the conversation = going. 


Could these changes be = done?

Sure, = pending the outcome of this thread.


Kent // = contributor




= --Apple-Mail=_93843DAB-D38C-457B-BFAA-27A6F9B4EC0D-- From nobody Thu Mar 21 08:29:29 2019 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 F0C9613123A for ; Thu, 21 Mar 2019 08:29:27 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 2sOLBDNP4heV for ; Thu, 21 Mar 2019 08:29:25 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA90131226 for ; Thu, 21 Mar 2019 08:29:24 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 09B593D; Thu, 21 Mar 2019 16:29:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Tln-RdCrys41; Thu, 21 Mar 2019 16:29:23 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 21 Mar 2019 16:29:22 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7C7A2009D; Thu, 21 Mar 2019 16:29:22 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id 7PE9fjsB65_H; Thu, 21 Mar 2019 16:29:22 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 7373E2009B; Thu, 21 Mar 2019 16:29:22 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Thu, 21 Mar 2019 16:29:21 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 8BD9A300765526; Thu, 21 Mar 2019 16:29:20 +0100 (CET) Date: Thu, 21 Mar 2019 16:29:20 +0100 From: Juergen Schoenwaelder To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= CC: "netconf@ietf.org" , Kent Watsen Message-ID: <20190321152920.jdkny7szk7ik3sp4@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= , "netconf@ietf.org" , Kent Watsen References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden 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, 21 Mar 2019 15:29:28 -0000 I agree, I do not understand the second sentence either. My problem is that I do not know what a 'real' private key is, are hidden keys somewhat unreal? Or is "not hidden" =3D "real"? The last sentence can probably be fixed; I think the intention was to say that you can't backup and restore hidden keys by retrieving configuration and restoring the configuration. In general, I think we need a definition what a hidden key is. Is something not exposed via a YANG interface a hidden key (but it may be a regular key when using other device access methods)? Or do we require that a hidden key is generally protected? I assume some people want to have flexibility here but from the viewpoint of a security administrator it matters a lot whether 'hidden' means 'generally not accessible' or only 'not accessible via YANG protocols'. The description of install-hidden-key seems to indicate a key is already 'hidden' if it only exists in . Is this really a 'hidden' key or more an 'ephemeral' key? /js On Thu, Mar 21, 2019 at 02:23:27PM +0000, Bal=E1zs Kov=E1cs wrote: > Hi, >=20 > The 'generate-hidden-key' action is meant for cases when the key must b= e generated in the device and not the operator is configuring it. The 'ge= nerate-hidden-key' is said to produce a 'permanently-hidden' asymmetric k= ey. The description of 'permanently-hidden' is as follows: >=20 > "The private key is inaccessible due to being > protected by the system (e.g., a cryptographic > hardware module). It is not possible to > configure a permanently hidden key, as a real > private key value must be set. Permanently > hidden keys cannot be archived or backed up."; >=20 > Th second sentence doesn't sound right. I can create a permanently hidd= en key any time by calling the 'generate-hidden-key' action, or if the de= vice or the model allows I could even switch to non-hidden key, I believe= , by providing the binary. So I find the second sentence irrelevant in th= is description. >=20 > More importantly, I find the "Permanently hidden keys cannot be archive= d or backed up" statement false. Isn't that implementation specific how a= rchiving is done? If a device puts the hidden keys on some storage, it ma= y still be possible to back them up. I would prefer to remove this senten= ce and leave backup considerations to implementations. >=20 > Could these changes be done? >=20 > Br, > Balazs > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Mar 22 03:23:19 2019 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 21231126C01; Fri, 22 Mar 2019 03:23:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: ibagdona@gmail.com, draft-ietf-netconf-netconf-event-notifications@ietf.org, netconf@ietf.org, kent+ietf@watsen.net, Kent Watsen , netconf-chairs@ietf.org Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155325019112.23033.12015966071553425961.idtracker@ietfa.amsl.com> Date: Fri, 22 Mar 2019 03:23:11 -0700 Archived-At: Subject: [netconf] Last Call: (Dynamic subscription to YANG Events and Datastores over NETCONF) to Proposed Standard 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, 22 Mar 2019 10:23:12 -0000 The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'Dynamic subscription to YANG Events and Datastores over NETCONF' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-04-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides a NETCONF binding to the dynamic subscription capability of both subscribed notifications and YANG-Push. RFC Editor note: please replace the four references to pre-RFC normative drafts with the actual assigned RFC numbers. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-notifications/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-notifications/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Mar 22 03:25:25 2019 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 E96221315F2; Fri, 22 Mar 2019 03:25:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: ibagdona@gmail.com, draft-ietf-netconf-restconf-notif@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org, kent+ietf@watsen.net, Kent Watsen Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155325031292.23046.10463138647659681368.idtracker@ietfa.amsl.com> Date: Fri, 22 Mar 2019 03:25:12 -0700 Archived-At: Subject: [netconf] Last Call: (Dynamic subscription to YANG Events and Datastores over RESTCONF) to Proposed Standard 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, 22 Mar 2019 10:25:24 -0000 The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'Dynamic subscription to YANG Events and Datastores over RESTCONF' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-04-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides a RESTCONF binding to the dynamic subscription capability of both subscribed notifications and YANG-Push. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-notif/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-notif/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Mar 22 03:42:24 2019 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 24B2F1200B3; Fri, 22 Mar 2019 03:42:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: ibagdona@gmail.com, draft-ietf-netconf-subscribed-notifications@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org, kent+ietf@watsen.net, Kent Watsen Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155325134214.23075.7319268431942605612.idtracker@ietfa.amsl.com> Date: Fri, 22 Mar 2019 03:42:22 -0700 Archived-At: Subject: [netconf] Last Call: (Subscription to YANG Event Notifications) to Proposed Standard 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, 22 Mar 2019 10:42:22 -0000 The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'Subscription to YANG Event Notifications' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-04-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request for and receive a continuous, custom feed of publisher generated information. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Mar 22 03:50:12 2019 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 5A72E130E8B; Fri, 22 Mar 2019 03:50:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: ibagdona@gmail.com, draft-ietf-netconf-yang-push@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org, kent+ietf@watsen.net, Kent Watsen Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155325181135.22969.5226847587166582521.idtracker@ietfa.amsl.com> Date: Fri, 22 Mar 2019 03:50:11 -0700 Archived-At: Subject: [netconf] Last Call: (Subscription to YANG Datastores) to Proposed Standard 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, 22 Mar 2019 10:50:12 -0000 The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'Subscription to YANG Datastores' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-04-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Via the mechanism described in this document, subscriber applications may request a continuous, customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Mar 22 05:42:53 2019 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 60A6A1277C9; Fri, 22 Mar 2019 05:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 nMh_mvN-eVlU; Fri, 22 Mar 2019 05:42:50 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C26D126D00; Fri, 22 Mar 2019 05:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4639; q=dns/txt; s=iport; t=1553258570; x=1554468170; h=from:to:subject:date:message-id:mime-version; bh=16fXKugIl+GfiSQgcYAbomxdQWHvRxZwiFi7NQJKVPQ=; b=YJ3+t7Or5mUlz2uiGYKULUmdt7om9dSqESnyrXRQKUf/J1V9fotPADEz frvzQPlYdX7y4vQhyRZGs6sjbPkETOLoi198NriFxkC1t5dozmMqeWrMz WOVx5O/p9x3X2sZRoE00Moqtej7KH6SWIw6gi+i1npGa+SFM0lssB+wDS w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAABm15Rc/5RdJa1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAIBAQEBCwGBDoECaIEDMZc/lE6Hcg0BAYlqIjcGDQEBAwE?= =?us-ascii?q?BCQEDAm0ohX5eAYEAJgEEARqDG4ERZKsFijKBLwGLMReBQD+BEY11A4o1hlO?= =?us-ascii?q?UBQkCky4hk3yLGJMkAhEVgS41IiiBLnAVgyiQSkGOEoEfAQE?= X-IronPort-AV: E=Sophos;i="5.60,256,1549929600"; d="scan'208,217";a="453476679" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Mar 2019 12:42:48 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x2MCgmO7012903 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Mar 2019 12:42:48 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 22 Mar 2019 07:42:48 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Fri, 22 Mar 2019 07:42:48 -0500 From: "Rob Wilton (rwilton)" To: "core@ietf.org" , "netconf@ietf.org" Thread-Topic: YANG encoding in CBOR Thread-Index: AdTf3q8hCOPNH5o0Q0SJZRQQHN87Vg== Date: Fri, 22 Mar 2019 12:42:47 +0000 Message-ID: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.76.6] Content-Type: multipart/alternative; boundary="_000_6235c6683ff14848a661f8b8cec94280XCHRCD007ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: [netconf] YANG encoding in CBOR 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, 22 Mar 2019 12:42:53 -0000 --_000_6235c6683ff14848a661f8b8cec94280XCHRCD007ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As part of YANG evolution discussion, that was some talk about using a bina= ry encoding of YANG in NETCONF or RESTCONF. CBOR looks like a good fit for this, and obviously CORE WG are working on d= raft-ietf-core-yang-cbor-07, but one comment came up from Andy that the CBO= R encoding of YANG cannot handle all YANG data models. In particular, beca= use of the way that the encoding works there are limitations on how unions = of enums work. Is that still the case? Hence I was wondering whether it would be better to encode enum values in C= BOR using module-qualified names, or also assign them SIDs and use the SIDs= . Has this approach been considered at all? Or, is there an alternative approach to how we could/should consider using = CBOR as a binary encoding for YANG data in NETCONF or RESTCONF? Do you think it would be possible to get interested parties together to dis= cuss this at some point in Prague? Thanks, Rob --_000_6235c6683ff14848a661f8b8cec94280XCHRCD007ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

As part of YANG evolution discussion, that was some = talk about using a binary encoding of YANG in NETCONF or RESTCONF.

 

CBOR looks like a good fit for this, and obviously C= ORE WG are working on draft-ietf-core-yang-cbor-07, but one comment came up= from Andy that the CBOR encoding of YANG cannot handle all YANG data model= s.  In particular, because of the way that the encoding works there are limitations on how unions of enums w= ork.  Is that still the case?

 

Hence I was wondering whether it would be better to = encode enum values in CBOR using module-qualified names, or also assign the= m SIDs and use the SIDs.  Has this approach been considered at all?

 

Or, is there an alternative approach to how we could= /should consider using CBOR as a binary encoding for YANG data in NETCONF o= r RESTCONF?

 

Do you think it would be possible to get interested = parties together to discuss this at some point in Prague?

 

Thanks,
Rob

 

--_000_6235c6683ff14848a661f8b8cec94280XCHRCD007ciscocom_-- From nobody Fri Mar 22 05:44:14 2019 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 5A7A5126D00 for ; Fri, 22 Mar 2019 05:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, RCVD_IN_DNSWL_MED=-2.3, 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=ericsson.com header.b=Hqb46foI; dkim=pass (1024-bit key) header.d=ericsson.com header.b=ivfidMtd 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 Ae2habq2TJJt for ; Fri, 22 Mar 2019 05:44:09 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 745BF12426A for ; Fri, 22 Mar 2019 05:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1553258647; x=1555850647; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Wy8KL9bi5XrSVQLPxxy6cVQRqHpG5PLC0pZFUSMZ/RM=; b=Hqb46foIeNJjp19hdBZpP2fD0ngwryM6f2ysyn5H7kIQ79xqh9oIOnDwsRzX5KGu ip+r/ExTGjND6E2ICmHy2wuj9aA+aOJwkvKZ3jG8hRu0sa0Q0e1BP9RSs4WoFzF6 MyK8ZL0D0BOyoe/MFyrjGSwz4UrrbusAIFWJPlyHV8k=; X-AuditID: c1b4fb2d-fafff70000002218-13-5c94d8976ce3 Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 47.F6.08728.798D49C5; Fri, 22 Mar 2019 13:44:07 +0100 (CET) Received: from ESESSMR503.ericsson.se (153.88.183.112) by ESESSMB504.ericsson.se (153.88.183.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 22 Mar 2019 13:44:06 +0100 Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSMR503.ericsson.se (153.88.183.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 22 Mar 2019 13:44:07 +0100 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Fri, 22 Mar 2019 13:44:06 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Wy8KL9bi5XrSVQLPxxy6cVQRqHpG5PLC0pZFUSMZ/RM=; b=ivfidMtd0kTQNOekYY6CUVsOdYpFFwD1f5s9TN6WUxDCKFCwJG+bNfKMYG3c+wd9FWDdjmLio3/y8B8L5rmLRxCuz63TKStelpBB7nrwg/STfV5/aP36e6kHhmLXljpc8XZN77ry17vIxf9HkyaQll9efUeO4u9YHkhV5oZBFn0= Received: from VI1PR07MB4735.eurprd07.prod.outlook.com (20.177.57.146) by VI1PR07MB4591.eurprd07.prod.outlook.com (20.177.56.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.16; Fri, 22 Mar 2019 12:44:05 +0000 Received: from VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::807b:cd48:c48:cf03]) by VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::807b:cd48:c48:cf03%4]) with mapi id 15.20.1730.013; Fri, 22 Mar 2019 12:44:05 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Kov=E1cs?= To: Juergen Schoenwaelder CC: "netconf@ietf.org" , Kent Watsen Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpAACqnQAACvdhTA= Date: Fri, 22 Mar 2019 12:44:05 +0000 Message-ID: References: <20190321152920.jdkny7szk7ik3sp4@anna.jacobs.jacobs-university.de> In-Reply-To: <20190321152920.jdkny7szk7ik3sp4@anna.jacobs.jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: abc3ac6f-cf2d-4cf6-0150-08d6aec411f8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB4591; x-ms-traffictypediagnostic: VI1PR07MB4591: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 09840A4839 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(136003)(39860400002)(346002)(396003)(13464003)(199004)(189003)(106356001)(99286004)(2906002)(55016002)(4326008)(6306002)(9686003)(105586002)(66066001)(66574012)(6246003)(6116002)(3846002)(53936002)(6916009)(97736004)(68736007)(8676002)(81156014)(81166006)(8936002)(305945005)(7736002)(74316002)(33656002)(25786009)(6436002)(256004)(14444005)(14454004)(478600001)(229853002)(966005)(86362001)(476003)(71190400001)(71200400001)(11346002)(446003)(316002)(53546011)(6506007)(102836004)(76176011)(26005)(5660300002)(52536014)(6346003)(186003)(7696005)(54906003)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4591; H:VI1PR07MB4735.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: OZhYE/cijrVZQOXcrPm6O1kJEx/tHj/eWgLq3JOzM2BXTtcG6C/MC8ZRCg2ohBYhrtdvfOXJ3qZ2ajb9KEoLvWkEhohsF6RThzR1LIcARdfCEec0TUcHab8/RCCbgzzGUgcQc+k9zEJ6d6VJf25A0EVU2ElfQi9tcKXcp427xmCDeDp7alXymOLgIwlgkAqhbZpzm9jcGWOb+3nv2yMmHNcoZ44BfgSo0CRq3dTsb4WknfXxrfG000LVIgH1PKyPz+Ac7STtbkTh8LCKtR3A/WgkEjHCoPFpctvbUm02tfRD4qlEF370m0ibBJn3Fkann9i0DJqJTpyEMBaJnM52/Rt1asY5C0DB6Y+Rd2mUVswPAKWJJ17tbzCrm/jJPS/WHXyCL+5KC9jrwPOPzhrgHwa3dzuDStAY8sTlYavHjEQ= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: abc3ac6f-cf2d-4cf6-0150-08d6aec411f8 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2019 12:44:05.6752 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4591 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA03Se0hTURgA8M69e1ytwXFqfqwHdCGChdrrDzEVhYRZZv0VYaOcelNRp+xO SYtcxqCpoKAjJ+Vz+JwxTbIkwRfk/KOHINjU1KaZSWVTFHFp3s6C/vud7/vOd853OAwtLxMr mAytntNpNVmsxFdkud5bGPx4skp9yjziHzbRtYXC2pzz0jBz95Q4mlZZrVuUyj4Qp3KNlkiv 0om+EalcVkY+pwuNSvJNn7G+p3L7jt75vtkpNaCfQSXIhwF8DiZq2+kS5MvI8QiC4S8OSkjI 8QaCobcJJLHn34NzYpKwUtD+OVSwCFfQMDZaRIoqKfiw/gCRxRyCT7YRJFRJcCwsWrakggNw NJS/KJUIprEKyurL/9ofR8KMrVxMaqLgmamNIg6H6VY3IqcdB2uTaa8Pw8iwGpaN2eRCDQje GGgh7IOvQFVPtBBG+CBsjtkoclIQOBfqKDIxBuvrdzRxICy7dsTELFR/c3p9BMbrShHxZZh9 tCQVxgL8EYFnvNvbSAmWqRavFbDp+iUlzoTapmZv/DAUD1aLyeZdMXy1r3pfkYOWTiOqQCE1 /12QOAQmzVUS4pPQ3LBCC5ZhP3BYFkT1SNSOAnmO57PTzpwN4XQZKTyfow3RcvputPdHBnu2 g1+ijpWYIYQZxB6QJQ1UqeViTT5fkD2EgKHZAFnfjUq1XJaqKSjkdDm3dHlZHD+EDjEiNkjm kfup5ThNo+cyOS6X0/3LUoyPwoBCB4qUHvfwxeWmtSzRWmXPtqLIVtd+rW0n9ry2l32lX2+y TIu2/eIuNZ6IV1qOL87Pe4xPHbPsbVdUR6XBod5vN5uU+QmquzFxef2Jx+7jJ2zrMuqKzo4c f15fXBN/T5MM8fihO0K+L865Yb/pSu73NBo7L7h3U1Z/hC+ZWBGfrjmtpHW85g+ZBOjfHwMA AA== Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden 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, 22 Mar 2019 12:44:13 -0000 Hi, I would really prefer the definition for 'hidden' as 'not accessible via YA= NG protocols'. The explanation is that regardless of what method I use to c= reate/store the private keys, I still might not want the operator to genera= te keys outside of the device or configure binary secret strings. I considered TPM protection for hidden keys is an option or example so far,= which adds limitations or additional complexity for moving keys, but shoul= d not be the only option for hidden keys. The descriptions mention TPM as e= xample, then the rest of the text should align also to keep that as example= . Br, Balazs -----Original Message----- From: Juergen Schoenwaelder =20 Sent: Thursday, March 21, 2019 4:29 PM To: Bal=E1zs Kov=E1cs Cc: netconf@ietf.org; Kent Watsen Subject: Re: [netconf] ietf crypto types - permanently hidden I agree, I do not understand the second sentence either. My problem is that= I do not know what a 'real' private key is, are hidden keys somewhat unrea= l? Or is "not hidden" =3D "real"? The last sentence can probably be fixed; I think the intention was to say t= hat you can't backup and restore hidden keys by retrieving configuration an= d restoring the configuration. In general, I think we need a definition what a hidden key is. Is something= not exposed via a YANG interface a hidden key (but it may be a regular key= when using other device access methods)? Or do we require that a hidden ke= y is generally protected? I assume some people want to have flexibility her= e but from the viewpoint of a security administrator it matters a lot wheth= er 'hidden' means 'generally not accessible' or only 'not accessible via YA= NG protocols'. The description of install-hidden-key seems to indicate a key is already 'h= idden' if it only exists in . Is this really a 'hidden' key or= more an 'ephemeral' key? /js On Thu, Mar 21, 2019 at 02:23:27PM +0000, Bal=E1zs Kov=E1cs wrote: > Hi, >=20 > The 'generate-hidden-key' action is meant for cases when the key must be = generated in the device and not the operator is configuring it. The 'genera= te-hidden-key' is said to produce a 'permanently-hidden' asymmetric key. Th= e description of 'permanently-hidden' is as follows: >=20 > "The private key is inaccessible due to being > protected by the system (e.g., a cryptographic > hardware module). It is not possible to > configure a permanently hidden key, as a real > private key value must be set. Permanently > hidden keys cannot be archived or backed up."; >=20 > Th second sentence doesn't sound right. I can create a permanently hidden= key any time by calling the 'generate-hidden-key' action, or if the device= or the model allows I could even switch to non-hidden key, I believe, by p= roviding the binary. So I find the second sentence irrelevant in this descr= iption. >=20 > More importantly, I find the "Permanently hidden keys cannot be archived = or backed up" statement false. Isn't that implementation specific how archi= ving is done? If a device puts the hidden keys on some storage, it may stil= l be possible to back them up. I would prefer to remove this sentence and l= eave backup considerations to implementations. >=20 > Could these changes be done? >=20 > Br, > Balazs > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Mar 22 06:01:19 2019 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 8BD4E12798E for ; Fri, 22 Mar 2019 06:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=ericsson.com header.b=QJOmwfFd; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=ericsson.com header.b=eh/H6/0B 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 biM_Dn3IdEd2 for ; Fri, 22 Mar 2019 06:01:14 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 1E1FD126D00 for ; Fri, 22 Mar 2019 06:01:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1553259671; x=1555851671; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=doGHDwatR0KQhybPJJTjabfbcnlUEwHHpRbAPomGfe0=; b=QJOmwfFdyZhQ/lVRkabRMXwjrlInGY7I+7coWxFNz+aZst1eQxhAaoVBsxRKPSGD Qv0/gMBngvzCI+v/DKftzTT2/qOaFcn+flKnrVi6Hyme9p/IWsF3Dj4JKyDrksPO CO+dcWugr1J3rU/7iEnmRJQdRiXgGVI0nTj5QRGYmwk=; X-AuditID: c1b4fb30-307ff70000007fec-7c-5c94dc977a32 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6F.1B.32748.79CD49C5; Fri, 22 Mar 2019 14:01:11 +0100 (CET) Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 22 Mar 2019 14:01:10 +0100 Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Fri, 22 Mar 2019 14:01:10 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jotXTweACwBRehfjOC8EclSZ3z9YRIqj2RuJmiFNajo=; b=eh/H6/0BL/02kqtYkJYiw5ovMyn/dQDFFGQD9nD0vO8C4GY7OWud3s16A9htgmgr0gAo3vgaoG35pwA3bdUSE+xBeW3h2YGF5Kp04ZKQRqWz3UnhCsclHBQ/uyvOiyAP+/16ngJUndraJC9+78DuXXJqPiNqZ0VzvoJBNBjUMUM= Received: from VI1PR07MB4735.eurprd07.prod.outlook.com (20.177.57.146) by VI1PR07MB4142.eurprd07.prod.outlook.com (52.134.26.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.16; Fri, 22 Mar 2019 13:01:09 +0000 Received: from VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::807b:cd48:c48:cf03]) by VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::807b:cd48:c48:cf03%4]) with mapi id 15.20.1730.013; Fri, 22 Mar 2019 13:01:09 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Kov=E1cs?= To: Kent Watsen CC: "netconf@ietf.org" Thread-Topic: why did we breakout the groupings? Thread-Index: AQHU3/X4xmErv8wo/EC4fyn8MoXRlKYXmz6w Date: Fri, 22 Mar 2019 13:01:09 +0000 Message-ID: References: <01000169a0becf2a-5f004be0-a74d-4f9b-b456-f8c3309fac94-000000@email.amazonses.com> In-Reply-To: <01000169a0becf2a-5f004be0-a74d-4f9b-b456-f8c3309fac94-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 94cfa7b8-becc-400d-6489-08d6aec67450 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR07MB4142; x-ms-traffictypediagnostic: VI1PR07MB4142: x-microsoft-antispam-prvs: x-forefront-prvs: 09840A4839 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(39860400002)(376002)(396003)(136003)(189003)(199004)(186003)(53546011)(4326008)(102836004)(26005)(476003)(99286004)(99936001)(446003)(486006)(6246003)(66066001)(105586002)(9686003)(53936002)(71190400001)(76176011)(55016002)(54896002)(7696005)(6306002)(316002)(66574012)(2906002)(86362001)(478600001)(229853002)(97736004)(81166006)(8936002)(6506007)(33656002)(11346002)(14454004)(6436002)(106356001)(790700001)(5660300002)(71200400001)(7736002)(3846002)(74316002)(14444005)(256004)(5024004)(25786009)(8676002)(68736007)(6116002)(52536014)(81156014)(9326002)(16333001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4142; H:VI1PR07MB4735.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Lew6a9+h8WxEA4IF/0fPhA0h+mWT65YJN1JabJtke6Ll5lkLnjtK9L1DHb5iXZ1uFoKv78E/HZ5c6t94T1+arU1G78ebBf2cUMfv8reXvsx+/zVqe5qAmfJ2KKVwyo0DfbCzD8RguK/ErNxLzGfIMuD59pCVWpNQ+ycTIbJ9fYclXRhWrCvU1t4d1itemLLC5kmKVmeeUEJzg+CFoSrZc4Jk2ScUCZx/qNyK4N/EIsWIXpc6LpX4Ng9kWpcXsdNRaFcF2+gQlF3sSkli+S1aMs3TbwwvdRWk4XJa1paFuARApuyvOAfnaZZW9U145ROKiFsjb9+U1PwM4M/6YBbMOSm2vyliEStFU54v3S6ys8GRg8KiNSSV506nAbcqm4K+AP1htHkSYBCl7GnLVxW9O4J2WHxY59nfDvyPHJJ+KfY= Content-Type: multipart/mixed; boundary="_004_VI1PR07MB4735B4C1AF014281AB693E5E83430VI1PR07MB4735eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 94cfa7b8-becc-400d-6489-08d6aec67450 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2019 13:01:09.5845 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4142 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA2WTa0xTZxjH855zenpabfJS63iGbJmNU0ApSEyEZEGcLnFB3D74wcyqVD3B BmjNOQynyRIwNOGiCULZaGNHp4ix2uC0BkSJctF4wQCdGqBgLKAVcF5gjji5rD3vcdnl2+88 z/99/8/lPRytHVbGcGZLAS9YTHl6Vs04tjUdSPxx0G5MbvSoU1+MzqPUmgsBRQa1qb7+LbVp 5Fa58mvqG/Vne/k8cyEvJKVnq/d1P83a/6SX/q63ZIguQp2tdDlScYDXwCX7n0w5UnNa3Img aKaViSS0+A8E7lvLSaKegsO/zrORDwZX0nCtNcQSVRUFAz/EE9VjBFOuPinB4i/gieOtMsI6 vByCPR0owjSOB+/sa8l7EU4Cn62aJZpkOFZSpCCcAqeO35HKYPCnUDLdIp3VYCO8C3gQMd4J VR1HJI0K74JgaFjyQvgDmL5zjiJe0TAwWkeRPnUQ7L3LEl4MYyNzCqLfAc0Tg0oS10Pt+ICC 8Efgr6tAhLOg6siYItIk4JFwk/ddsigBLk/6GMK5MHeyWjaIhcNttfKBYhaGui4qSNU8nPba 5Fs/Bs/RIFOJVjr/USxhM1yavKJ0Sk1HwW3HKEPiVngzOyizAfpq7CzhldDw8wRNOBFq59qZ /8dj4WJNGXKGa6KxDUF/8ITCKW1qA3Q/G5GMdXgz+KecUnwRzoQmt+fveFdFMUt4CzwsvRm+ iJO283K6gNSZDcW/zDBO6SU8pOBmqFEyVuF1MPhbGfXfJgFjqL/aTTvlyR8NvJDjZDuEV8PE +DNZkwGzFQGW8Hp4dMUp61MhdPcc9X5A/slp9t+D46RX19iSRCRLwV4RVBKOA9txl9KNlnrQ YpEXd+fnpKQYeMG8RxStFoOFL7iAwn9bm+9dcjMaC61vR5hD+oWa7Ot2o1ZhKhQP5rejZeF7 hs+f7UExjMVq4fU6Tcv2aqNWs9d08BAvWHcJ3+bxYjtawjH6aM2MNsqoxTmmAj6X5/fzwvss xaliilB+uuteL133iXKP9/ueG7aE3N2dQ2KTf5RpW1FpXVB47MS80JEmtsT52Q+ff9ncaAhs PON79dO2AL1s1QbHKZXrq/6N69LdDWm5UbqzGWtSN/tODpkNAUNdYvGKtUL051WGifhxt3Vn 6YMFb2J/1zQ8tnqzEjMcXk2tPjMuc8varXpG3GdanUALoukv/QrHQHUEAAA= Archived-At: Subject: Re: [netconf] why did we breakout the groupings? 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, 22 Mar 2019 13:01:18 -0000 --_004_VI1PR07MB4735B4C1AF014281AB693E5E83430VI1PR07MB4735eurp_ Content-Type: multipart/alternative; boundary="_000_VI1PR07MB4735B4C1AF014281AB693E5E83430VI1PR07MB4735eurp_" --_000_VI1PR07MB4735B4C1AF014281AB693E5E83430VI1PR07MB4735eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Kent, We had the attached conversation. Since we had this change, I admit I refrained from using the client-identit= y-grouping separately from an endpoint configuration (see attached mail). A= llowing the option for interactive selection of client identity did not see= m to be that good idea after all. I cannot say now I have any intention to = use them separately in the close future. >From your feedback I so far understood that these sub-grouping do not harm = much since the client-server models can use the original grouping, such as = the 'ssh-client-grouping'. All in all, I think I do not mind if you collapse this back into a single g= rouping if there is no other need to keep them separate. Br, Balazs From: Kent Watsen Sent: Thursday, March 21, 2019 3:54 PM To: Bal=E1zs Kov=E1cs Cc: netconf@ietf.org Subject: why did we breakout the groupings? Hi Balazs, I'm in the middle of answering your other question when I was reminded that= I've been meaning to follow up with you on this issue... Can you please help me recall why several months back we made the decision = to redefine the ietf-ssh-[client/server]-grouping statements to use other g= roupings? For instance, here's the current definition: grouping ssh-client-grouping { uses client-identity-grouping; uses server-auth-grouping; uses transport-params-grouping; uses keepalives-grouping; } Obviously it was because you (I think it was you) wanted to be able to "use= " the inner grouping in another context, but why? I ask because this strategy is percolating into all of the client/server mo= dels and it seems weird, if not wrong. I currently have it as an "open iss= ue" in my presentation for Monday, but I'd rather resolve it offline/now if= possible. Kent // contributor --_000_VI1PR07MB4735B4C1AF014281AB693E5E83430VI1PR07MB4735eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Kent,

 

We had the attached conversation.

 

Since we had this change, I admit I refrained from u= sing the client-identity-grouping separately from an endpoint configuration= (see attached mail). Allowing the option for interactive selection of clie= nt identity did not seem to be that good idea after all. I cannot say now I have any intention to use them sep= arately in the close future.

 

From your feedback I so far understood that these su= b-grouping do not harm much since the client-server models can use the orig= inal grouping, such as the ‘ssh-client-grouping’.

 

All in all, I think I do not mind if you collapse th= is back into a single grouping if there is no other need to keep them separ= ate.

 

Br,

Balazs

 

 

 

From: Kent Watsen <kent+ietf@watsen.ne= t>
Sent: Thursday, March 21, 2019 3:54 PM
To: Bal=E1zs Kov=E1cs <balazs.kovacs@ericsson.com>
Cc: netconf@ietf.org
Subject: why did we breakout the groupings?

 

Hi Balazs,

 

I'm in the middle of answering your other question w= hen I was reminded that I've been meaning to follow up with you on this iss= ue...

 

Can you please help me recall why several months bac= k we made the decision to redefine the ietf-ssh-[client/server]-grouping st= atements to use other groupings?  For instance, here's the current def= inition:

 

    grouping ssh-client-grouping=  {
       uses client-identity-grouping;
       uses server-auth-grouping;
       uses transport-params-grouping;
       uses keepalives-grouping;
     }

 

Obviously it was because you (I think it was you) wa= nted to be able to "use" the inner grouping in another context, b= ut why?

 

I ask because this strategy is percolating into all = of the client/server models and it seems weird, if not wrong.  I curre= ntly have it as an "open issue" in my presentation for Monday, bu= t I'd rather resolve it offline/now if possible.

 

Kent // contributor

 

 

 

--_000_VI1PR07MB4735B4C1AF014281AB693E5E83430VI1PR07MB4735eurp_-- --_004_VI1PR07MB4735B4C1AF014281AB693E5E83430VI1PR07MB4735eurp_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Fri, 22 Mar 2019 13:01:08 GMT"; modification-date="Fri, 22 Mar 2019 13:01:08 GMT" From: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= To: Kent Watsen , "netconf@ietf.org" Subject: RE: [Netconf] ietf-ssh-client@2018-06-04, issues with the grouping Thread-Topic: [Netconf] ietf-ssh-client@2018-06-04, issues with the grouping Thread-Index: AQHUO/s1CXjlU9QRBEKDDvBt+svnz6TTNyTQgACJxQCAAS0GQIACP3kAgADcQ8A= Date: Thu, 30 Aug 2018 09:11:11 +0000 Message-ID: References: <04D060B8-3B11-468B-A53E-7BF5B600546E@juniper.net> In-Reply-To: Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 x-ms-exchange-organization-originalclientipaddress: 192.176.1.94 x-ms-exchange-organization-originalserveripaddress: 52.135.160.20 x-ms-exchange-organization-submissionquotaskipped: False Content-Type: multipart/alternative; boundary="_000_VI1PR0701MB201644EAA7CBEFFBFCD6381683080VI1PR0701MB2016_" MIME-Version: 1.0 --_000_VI1PR0701MB201644EAA7CBEFFBFCD6381683080VI1PR0701MB2016_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VudCwNCg0KTG9va3MgZ29vZCBhbmQgaXQgaXMgYWxzbyBnb29kIHRoYXQgeW91IGFkZGVk IHRoZSBzYW1lIHN0cnVjdHVyZSB0byBhbGwgZm91ciBvZiB0aG9zZSBzc2gvdGxzIGdyb3VwaW5n cy4NCg0KQnIsDQpCYWxhenMNCg0KRnJvbTogS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5u ZXQ+DQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDMwLCAyMDE4IDE6NTkgQU0NClRvOiBCYWzDoXpz IEtvdsOhY3MgPGJhbGF6cy5rb3ZhY3NAZXJpY3Nzb24uY29tPjsgbmV0Y29uZkBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtOZXRjb25mXSBpZXRmLXNzaC1jbGllbnRAMjAxOC0wNi0wNCwgaXNzdWVz IHdpdGggdGhlIGdyb3VwaW5nDQoNCkhpIEJhbGF6cywgQWxsLA0KDQpJIG1hZGUgdGhlIGNoYW5n ZSBpbiBteSBsb2NhbCBjb3B5LCBidXQgbm90ZSB0aGF0IEkgYWxzbyBzZXBhcmF0ZWQgc2VydmVy LWF1dGgNCmFuZCB0cmFuc3BvcnQtcGFyYW1zLiAgIEJlbG93IGlzIGFuIGV4YW1wbGUsIGlzIGl0 IG9rYXk/DQoNCiAgIGdyb3VwaW5nIHNzaC1jbGllbnQtZ3JvdXBpbmcgew0KICAgICAgZGVzY3Jp cHRpb24NCiAgICAgICAgIkEgcmV1c2FibGUgZ3JvdXBpbmcgZm9yIGNvbmZpZ3VyaW5nIGEgU1NI IGNsaWVudCB3aXRob3V0DQogICAgICAgICBhbnkgY29uc2lkZXJhdGlvbiBmb3IgaG93IGFuIHVu ZGVybHlpbmcgVENQIHNlc3Npb24gaXMNCiAgICAgICAgIGVzdGFibGlzaGVkLiI7DQogICAgIHVz ZXMgY2xpZW50LWlkZW50aXR5LWdyb3VwaW5nOw0KICAgICAgdXNlcyBzZXJ2ZXItYXV0aC1ncm91 cGluZzsNCiAgICAgIHVzZXMgdHJhbnNwb3J0LXBhcmFtcy1ncm91cGluZzsNCiAgICB9DQoNCkkg bWFkZSB0aGUgY2hhbmdlIHRvIGFsbCBmb3VyIG9mIHRoZSBncm91cGluZ3M6IFtzc2h8dGxzXS1b Y2xpZW50fHNlcnZlcl0tZ3JvdXBpbmcuDQoNClBTOiBzb29uIEknbGwgYmUgcG9zdGluZyBhbiB1 cGRhdGUgdG8gYWxsIHRoZXNlIGRyYWZ0cyBzbyBmb2xrcyBjYW4gc2VlIHRoZSB1cGRhdGVzDQog ICAgICAgbWFkZSBzaW5jZSB0aGUgSUVURiAxMDIgcHJlc2VudGF0aW9uLg0KDQpLZW50DQoNCg0K T24gOC8yOC8xOCwgNTo0MiBBTSwgIkJhbMOhenMgS292w6FjcyIgPGJhbGF6cy5rb3ZhY3NAZXJp Y3Nzb24uY29tPG1haWx0bzpiYWxhenMua292YWNzQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KDQpI aSBLZW50LA0KDQpZZXMsIHRoaXMgd291bGQgYmUgbXkgcHJvcG9zYWwuIFdvdWxkIHNpbWlsYXIg Y2hhbmdlIHRvIGlldGYtdGxzLWNsaWVudCB3b3VsZCBiZSBhcHBsaWNhYmxlPyBJIGRvbuKAmXQg aGF2ZSB0aGUgc2FtZSBpbnRlcmFjdGl2ZSB1c2UgY2FzZSBmb3IgVExTLCBidXQgbWF5YmUgaGF2 aW5nIHRoaXMgZmxleGliaWxpdHkgKHRoZSAyIG5ldyBncm91cGluZ3MpIGNvdWxkIGJlIGJlbmVm aWNpYWwgZm9yIFRMUyB0b28uDQoNCkJyLA0KQmFsYXpzDQoNCkZyb206IEtlbnQgV2F0c2VuIDxr d2F0c2VuQGp1bmlwZXIubmV0PG1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0Pj4NClNlbnQ6IE1v bmRheSwgQXVndXN0IDI3LCAyMDE4IDk6NDIgUE0NClRvOiBCYWzDoXpzIEtvdsOhY3MgPGJhbGF6 cy5rb3ZhY3NAZXJpY3Nzb24uY29tPG1haWx0bzpiYWxhenMua292YWNzQGVyaWNzc29uLmNvbT4+ OyBuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtOZXRjb25mXSBpZXRmLXNzaC1jbGllbnRAMjAxOC0wNi0wNCwgaXNzdWVzIHdpdGggdGhlIGdy b3VwaW5nDQoNCkFzc3VtaW5nIHlvdXIgdHdvIGdyb3VwaW5ncyBiZWxvdywgb3Igc29tZXRoaW5n IGNsb3NlIHRvIHRoZW0sIHdlIGNvdWxkIHJlZGVmaW5lIHRoZSBleGlzdGluZyAic3NoLWNsaWVu dC1ncm91cGluZyIgdG8gdGhlIGZvbGxvd2luZzoNCg0KICBncm91cGluZyBzc2gtY2xpZW50LWdy b3VwaW5nIHsNCiAgICB1c2VzIHNzaC1jbGllbnQtY2xpZW50LWlkZW50aXR5LWdyb3VwaW5nOw0K ICAgdXNlcyBzc2gtY2xpZW50LXNlcnZlci1hdXRoLXRyYW5zcG9ydC1wYXJhbXMtZ3JvdXBpbmc7 DQogIH0NCg0KVGhlIG5ldC1yZXN1bHQgaXMgbm8gY2hhbmdlIHRvIHRoZSBtb2RlbCwgYnV0IG5v dyB0aGUgaW5uZXIgZ3JvdXBpbmdzIGNhbiBiZSByZXB1cnBvc2VkLiAgSXMgdGhpcyB5b3VyIHBy b3Bvc2FsPw0KDQpLZW50IC8vIGNvbnRyaWJ1dG9yDQoNCg0KT24gOC8yNy8xOCwgMzo0OSBBTSwg IkJhbMOhenMgS292w6FjcyIgPGJhbGF6cy5rb3ZhY3NAZXJpY3Nzb24uY29tPG1haWx0bzpiYWxh enMua292YWNzQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KDQpIaSBLZW50LA0KDQpJdCBpcyBhcyB5 b3Ugc2F5LCBhbiBhcHAgdGhhdCBjYW4gbGF1bmNoIGFuIGludGVyYWN0aXZlIGNvbm5lY3Rpb24g dXNpbmcgcHJldmlvdXNseSBjb25maWd1cmVkIGNsaWVudCBjcmVkZW50aWFscywgaG9zdCBhdXRo ZW50aWNhdGlvbiwgYW5kIHRyYW5zcG9ydCBwYXJhbXMuDQoNCk15IHJlcXVlc3Qgb3IgcXVlc3Rp b24gd291bGQgYmUgaWYgdGhlIGN1cnJlbnQgc2luZ2xlIGdyb3VwaW5nIGNhbGxlZCDigJhzc2gt Y2xpZW50LWdyb3VwaW5n4oCZIGNvdWxkIGJlIHNwbGl0IGludG8gdHdvOiBvbmUgdGhhdCBvbmx5 IGluY2x1ZGVzIHRoZSDigJhjbGllbnQtaWRlbnRpdHnigJkgZGVmaW5pdGlvbiwgYW5kIGFub3Ro ZXIgd2hpY2ggaW5jbHVkZXMg4oCYc2VydmVyLWF1dGjigJkgYW5kIOKAmHRyYW5zcG9ydC1wYXJh bXPigJkuIEkgdGhpbmsgdGhpcyBjaGFuZ2Ugd291bGQgZW5hYmxlIGJldHRlciBmbGV4aWJpbGl0 eSBmb3IgcmUtdXNlIGluIGNhc2Ugb2YgYW55IFNTSC1iYXNlZCBhcHBsaWNhdGlvbnMsIGFuZCB0 aGUgb25seSBpbXBhY3Qgb24gdGhlIGV4aXN0aW5nIG1vZHVsZXMgdXNpbmcgc3NoLWNsaWVudC1n cm91cGluZyB3b3VsZCBiZSB0byB1c2UgdHdvIGdyb3VwaW5ncyBmcm9tIG5vdyBvbiBpbnN0ZWFk IG9mIG9uZS4NCg0KSnVzdCB0byByZWNhcCB0aGUgdXNlIGNhc2UsIG15IGludGVudGlvbiB3b3Vs ZCBiZSB0byBiZSBhYmxlIHRvIG1vdW50IGEgY2xpZW50IGlkZW50aXR5IGludG8gYSBsaXN0IGFu ZCBpbnRvIGEgY29udGFpbmVyIHRoYXQgaXMgaW5kZXBlbmRlbnQgb2YgdGhlIGFjdHVhbCBlbmRw b2ludCAoZm9yIGV4YW1wbGUsIGFzIGRlZmluZWQgaW4gbmV0Y29uZi1jbGllbnQgL25ldGNvbmYt Y2xpZW50L25ldGNvbmYtc2VydmVyL2VuZHBvaW50cy9lbmRwb2ludCkgYmVpbmcgdXNlZC4gV2hp Y2ggaWRlbnRpdHkgaXMgdG8gYmUgdXNlZCBpcyBzZWxlY3RlZCBieSBpbnRlcmFjdGlvbiB3aXRo IHRoZSBTU0ggY2xpZW50IChlLmcuLCB2aWEgYWN0aW9uIHBhcmFtZXRlcikuDQoNCldoYXQgZG8g eW91IHRoaW5rPw0KDQpCciwNCkJhbGF6cw0KDQpGcm9tOiBLZW50IFdhdHNlbiA8a3dhdHNlbkBq dW5pcGVyLm5ldDxtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldD4+DQpTZW50OiBTYXR1cmRheSwg QXVndXN0IDI1LCAyMDE4IDEyOjM5IEFNDQpUbzogQmFsw6F6cyBLb3bDoWNzIDxiYWxhenMua292 YWNzQGVyaWNzc29uLmNvbTxtYWlsdG86YmFsYXpzLmtvdmFjc0Blcmljc3Nvbi5jb20+PjsgbmV0 Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTmV0 Y29uZl0gaWV0Zi1zc2gtY2xpZW50QDIwMTgtMDYtMDQsIGlzc3VlcyB3aXRoIHRoZSBncm91cGlu Zw0KDQpIaSBCYWxhenMsDQoNCldoeSBoYXZlIGNvbmZpZ3VyYXRpb24gZm9yIGFuICJpbnRlcmFj dGl2ZSBjbGllbnQiIGF0IGFsbD8gICBJcyB0aGlzIGFuIGFwcCB0aGF0IGNhbiBsYXVuY2ggYW4g aW50ZXJhY3RpdmUgY29ubmVjdGlvbiB1c2luZyBwcmV2aW91c2x5IGNvbmZpZ3VyZWQgY2xpZW50 IGNyZWRlbnRpYWxzPyAgSWYgc28sIHRoZW4gSSB0aGluayBJIHVuZGVyc3RhbmQgdGhlIHByb2Js ZW07IHRoZSB1c2UgY2FzZSBzZWVtcyByYXRoZXIgZGlmZmVyZW50IHRoYW4gdGhlIHVzZSBjYXNl IHRoYXQgaXMgY3VycmVudGx5IGJlaW5nIHNvbHZlZC4NCg0KSSB1bmRlcnN0YW5kIHRoZSBkZXNp cmUgdG8gaGF2ZSBhIFlBTkcgbW9kdWxlIHRvIGNhcHR1cmUgeW91ciBjb25maWcsIGFuZCBJIHVu ZGVyc3RhbmQgdGhlIGRlc2lyZSBmb3IgdGhhdCBtb2R1bGUgdG8gYmUgYWJsZSB0byBtYWtlIHVz ZSBvZiBncm91cGluZ3MgZGVmaW5lZCBpbiB0aGUgaWV0Zi1zc2gtY2xpZW50Lg0KDQpJZiB0aGUg cmVxdWVzdCBpcyB0byBleHBvc2UgYSBjb3VwbGUgZ3JvdXBpbmdzLCBidXQgb3RoZXJ3aXNlIGxl YXZlIHRoZSBtb2RlbCB1bmNoYW5nZWQsIHRoZW4gSSBjYW4gc2VlIGhvdyB0aGF0IG1pZ2h0IGJl IGRvbmUuICBCdXQgaWYgdGhlIHJlcXVlc3QgaXMgdG8gY2hhbmdlIGUuZy4sIHNzaC1jbGllbnQt Z3JvdXBpbmcsIHRvIHN1cHBvcnQgYSBkZWNvdXBsaW5nIG9mIGNsaWVudCBjcmVkZW50aWFscywg dGhlbiBJIGRvbid0IHNlZSBob3cgdG8gZG8gdGhhdC4NCg0KS2VudCAvLyBjb250cmlidXRvcg0K DQoNCk9uIDgvMjQvMTgsIDEwOjE0IEFNLCAiTmV0Y29uZiBvbiBiZWhhbGYgb2YgQmFsw6F6cyBL b3bDoWNzIiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRjb25mLWJvdW5jZXNA aWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBiYWxhenMua292YWNzQGVyaWNzc29uLmNvbTxtYWlsdG86 YmFsYXpzLmtvdmFjc0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCg0KSGkgQWxsLA0KDQpJIG1hZGUg YW4gYXR0ZW1wdCB0byBtYWtlIHVzZSBvZiB0aGUgaWV0Zi1zc2gtY2xpZW50QDIwMTgtMDYtMDQg bW9kdWxlIHRvIGNvbmZpZ3VyZSBhbiBpbnRlcmFjdGl2ZSBzc2ggY2xpZW50LCBhbmQgSSBmb3Vu ZCBzb21lIG9ic3RhY2xlcy4gVGhlIGN1cnJlbnQgaWV0Zi1zc2gtY2xpZW50IG1vZGVsIGhhcyB0 aGUgZm9sbG93aW5nIHN0cnVjdHVyZToNCg0KbW9kdWxlOiBpZXRmLXNzaC1jbGllbnQNCiAgKy0t cncgY2xpZW50DQogICAgICstLXJ3IGNsaWVudC1pZGVudGl0eQ0KICAgICB8ICArLS1ydyB1c2Vy bmFtZT8gICAgICAgICAgICBzdHJpbmcNCiAgICAgfCAgKy0tcncgKGF1dGgtdHlwZSkNCiAgICAg fCAgICAgKy0tOihwYXNzd29yZCkNCiAgICAgfCAgICAgfCAgKy0tcncgcGFzc3dvcmQ/ICAgICAg c3RyaW5nDQogICAgIHwgICAgICstLToocHVibGljLWtleSkNCiAgICAgfCAgICAgfCAgKy0tcncg cHVibGljLWtleQ0KICAgICB8ICAgICArLS06KGNlcnRpZmljYXRlKQ0KICAgICB8ICAgICAgICAr LS1ydyBjZXJ0aWZpY2F0ZSB7c3NoY21uOnNzaC14NTA5LWNlcnRzfT8NCiAgICAgKy0tcncgc2Vy dmVyLWF1dGgNCiAgICAgfCAgKy0tcncgcGlubmVkLXNzaC1ob3N0LWtleXM/ICAgdGE6cGlubmVk LWhvc3Qta2V5cy1yZWYNCiAgICAgfCAgKy0tcncgcGlubmVkLWNhLWNlcnRzPyAgICAgICAgdGE6 cGlubmVkLWNlcnRpZmljYXRlcy1yZWYge3NzaGNtbjpzc2gteDUwOS1jZXJ0c30/DQogICAgIHwg ICstLXJ3IHBpbm5lZC1zZXJ2ZXItY2VydHM/ICAgIHRhOnBpbm5lZC1jZXJ0aWZpY2F0ZXMtcmVm IHtzc2hjbW46c3NoLXg1MDktY2VydHN9Pw0KICAgICArLS1ydyB0cmFuc3BvcnQtcGFyYW1zIHtz c2gtY2xpZW50LXRyYW5zcG9ydC1wYXJhbXMtY29uZmlnfT8NCg0KSW4gdGhlIG5ldGNvbmYtY2xp ZW50IG1vZHVsZSwgd2hpY2ggSSB0b29rIGFzIGV4YW1wbGUgaXQgaXMgbW91bnRlZCB0byB0aGUg 4oCYc3No4oCZIGNvbnRhaW5lciBhbmQgcHJlY2VkZWQgYnk6DQoNCiAgIG1vZHVsZTogaWV0Zi1u ZXRjb25mLWNsaWVudA0KICAgICArLS1ydyBuZXRjb25mLWNsaWVudA0KICAgICAgICArLS1ydyBp bml0aWF0ZSEge2luaXRpYXRlfT8NCiAgICAgICAgfCAgKy0tcncgbmV0Y29uZi1zZXJ2ZXIqIFtu YW1lXQ0KICAgICAgICB8ICAgICArLS1ydyBuYW1lICAgICAgICAgICAgICAgICAgc3RyaW5nDQog ICAgICAgIHwgICAgICstLXJ3IGVuZHBvaW50cw0KICAgICAgICB8ICAgICB8ICArLS1ydyBlbmRw b2ludCogW25hbWVdDQogICAgICAgIHwgICAgIHwgICAgICstLXJ3IG5hbWUgICAgICAgICBzdHJp bmcNCiAgICAgICAgfCAgICAgfCAgICAgKy0tcncgKHRyYW5zcG9ydCkNCiAgICAgICAgfCAgICAg fCAgICAgICAgKy0tOihzc2gpIHtzc2gtaW5pdGlhdGV9Pw0KICAgICAgICB8ICAgICB8ICAgICAg ICB8ICArLS1ydyBzc2gNCiAgICAgICAgfCAgICAgfCAgICAgICAgfCAgICAgKy0tcncgYWRkcmVz cz8gICAgICAgICAgICBpbmV0Omhvc3QNCiAgICAgICAgfCAgICAgfCAgICAgICAgfCAgICAgKy0t cncgcG9ydD8gICAgICAgICAgICAgICBpbmV0OnBvcnQtbnVtYmVyXA0KDQpJbiB0aGUgY2FzZSBv ZiB0aGUgaW50ZXJhY3RpdmUgY2xpZW50LCBJIHdhbnQgc29tZSBsaW1pdGVkIHBhcmFtZXRlcnMg dG8gYmUgcHJvdmlkZWQgYnkgdGhlIGludm9raW5nIHVzZXIsIHdoaWNoIGlzIGF0IGxlYXN0IHRo ZSB0YXJnZXQgdXNlciwgdGFyZ2V0IGFkZHJlc3MsIGFuZCB0YXJnZXQgcG9ydCwgc28gIEkgd291 bGQgbm90IG5lZWQgYWxsIHRoZSBkYXRhIG5vZGVzIHByZXNlbnQgaW4gdGhlIG5ldGNvbmYtY2xp ZW50LCBidXQgSSBuZWVkIGEgc3Vic2V0IG9mIHRoZW0sIGluY2x1ZGluZyB0aGUgdXNlciBjcmVk ZW50aWFscy4gVGhlIHByb2JsZW0gSSBmYWNlLCBpcyB0aGF0IGZvciBvbmUgdGFyZ2V0IGFkZHJl c3MsIHRoZSB1c2VyIGNhbiBzZWxlY3QgbXVsdGlwbGUgdGFyZ2V0IHVzZXJzLCBhbmQgZm9yIG9u ZSB0YXJnZXQgdXNlciwgaXQgc2hvdWxkIGJlIGFibGUgdG8gc2VsZWN0IG11bHRpcGxlIHRhcmdl dCBhZGRyZXNzZXMuIFdpdGggdGhlIGFib3ZlIG1vZGVsLCBpZiBJIHdhbnQgdG8gc2V0IHVwIGEg c2Vjb25kIGNsaWVudCBpZGVudGl0eSwgSSB3b3VsZCBiYXNpY2FsbHkgbmVlZCB0byBjcmVhdGUg YSBjb21wbGV0ZSBlbmRwb2ludCB3aXRoIHRoZSBzYW1lIGRhdGEgaW4gYWxsIHRoZSByZXN0IG9m IHRoZSBkYXRhIG5vZGVzLiBFcXVhbGx5LCBpZiBJIHdhbnQgdG8gc2V0IHVwIGEgZGlmZmVyZW50 IGVuZHBvaW50LCBJIG5lZWQgdG8gY29weSBhbGwgdGhlIHBvc3NpYmxlIGNsaWVudCBpZGVudGl0 aWVzIHRvIGJlIGFibGUgdG8gdXNlIHRoZW0gYXQgb3RoZXIgdGFyZ2V0IGFkZHJlc3Nlcy4NCg0K TXkgdGhpbmtpbmcgaXMgdGhhdCB0aGUgZW5kcG9pbnQgcmVsYXRlZCBjb25maWd1cmF0aW9uIChh ZGRyZXNzLCBwb3J0LCBzZXJ2ZXItYXV0aCwgdHJhbnNwb3J0LXBhcmFtcykgc2hvdWxkIGJlIGRl Y291cGxlZCBmcm9tIGNsaWVudCBpZGVudGl0aWVzLCBzbyBJIGNhbiBzZXQgdGhlbSB1cCBhbmQg bW91bnQgdGhlbSBpbmRlcGVuZGVudGx5LiAgSG93ZXZlciwgSSB0aGluayB0aGlzIHdvdWxkIGVm ZmVjdCB0aGUgc3NoLWNsaWVudCBncm91cGluZyBhIGJpdCBoZWF2aWx5LCBiYXNpY2FsbHkgYnJl YWtpbmcgaXQgdXAgaW50byB0d28gcGllY2VzLiBPbmUgdGhhdCBjYXRlcnMgZm9yIHRoZSBjbGll bnQgaWRlbnRpdHksIGFuZCBhbm90aGVyIGZvciB0aGUgZW5kcG9pbnQvc2VydmVyIHNlY3VyaXR5 Lg0KDQpPbmUgbG9va2luZyBsaWtlIHRoaXMgKHRlbXAgbmFtZSDigJhzc2gtY2xpZW50LWNsaWVu dC1pZGVudGl0eS1ncm91cGluZ+KAmSk6DQoNCg0KICAgICBncm91cGluZyBzc2gtY2xpZW50LWNs aWVudC1pZGVudGl0eS1ncm91cGluZw0KDQogICAgICAgKy0tIGNsaWVudC1pZGVudGl0eQ0KDQog ICAgICAgICAgKy0tIHVzZXJuYW1lPyAgICAgICAgICAgIHN0cmluZw0KDQogICAgICAgICAgKy0t IChhdXRoLXR5cGUpDQoNCiAgICAgICAgICAgICArLS06KHBhc3N3b3JkKQ0KDQogICAgICAgICAg ICAgfCAgKy0tIHBhc3N3b3JkPyAgICAgIHN0cmluZw0KDQogICAgICAgICAgICAgKy0tOihwdWJs aWMta2V5KQ0KDQogICAgICAgICAgICAgfCAgKy0tIHB1YmxpYy1rZXkNCg0KICAgICAgICAgICAg IHwgICAgICstLS11IGtzOmxvY2FsLW9yLWtleXN0b3JlLWFzeW1tZXRyaWMta2V5LWdyb3VwaW5n DQoNCiAgICAgICAgICAgICArLS06KGNlcnRpZmljYXRlKQ0KDQogICAgICAgICAgICAgICAgKy0t IGNlcnRpZmljYXRlIHtzc2hjbW46c3NoLXg1MDktY2VydHN9Pw0KDQogICAgICAgICAgICAgICAg ICAgKy0tLXUga3M6bG9jYWwtb3Ita2V5c3RvcmUtZW5kLWVudGl0eS1jZXJ0aWZpY2F0ZS1ncm91 cGluZw0KDQoNCkFuZCBhbm90aGVyICh0ZW1wIG5hbWUg4oCYc3NoLXNlcnZlci1hdXRoLXRyYW5z cG9ydC1wYXJhbXMtZ3JvdXBpbmfigJkpOg0KDQoNCg0KDQoNCiAgICAgZ3JvdXBpbmcgc3NoLWNs aWVudC1zZXJ2ZXItYXV0aC10cmFuc3BvcnQtcGFyYW1zLWdyb3VwaW5nDQoNCiAgICAgICArLS0g c2VydmVyLWF1dGgNCg0KICAgICAgIHwgICstLSBwaW5uZWQtc3NoLWhvc3Qta2V5cz8gICB0YTpw aW5uZWQtaG9zdC1rZXlzLXJlZg0KDQogICAgICAgfCAgKy0tIHBpbm5lZC1jYS1jZXJ0cz8gICAg ICAgIHRhOnBpbm5lZC1jZXJ0aWZpY2F0ZXMtcmVmDQoNCiAgICAgICB8ICB8ICAgICAgIHtzc2hj bW46c3NoLXg1MDktY2VydHN9Pw0KDQogICAgICAgfCAgKy0tIHBpbm5lZC1zZXJ2ZXItY2VydHM/ ICAgIHRhOnBpbm5lZC1jZXJ0aWZpY2F0ZXMtcmVmDQoNCiAgICAgICB8ICAgICAgICAgIHtzc2hj bW46c3NoLXg1MDktY2VydHN9Pw0KDQogICAgICAgKy0tIHRyYW5zcG9ydC1wYXJhbXMge3NzaC1j bGllbnQtdHJhbnNwb3J0LXBhcmFtcy1jb25maWd9Pw0KDQogICAgICAgICAgKy0tLXUgc3NoY21u OnRyYW5zcG9ydC1wYXJhbXMtZ3JvdXBpbmcNCg0KDQoNCkkgYWxzbyB3b25kZXIgaWYgdGhpcyB3 b3VsZCBlZmZlY3QgdGhlIHNpbWlsYXIgbW9kdWxlIG9mIHRscy1jbGllbnQuIEluIFRMUyBjYXNl LCB0aGUgY2xpZW50IGlkZW50aXR5IHVzZWQgaXMgbW9yZSBib3VuZCB0byBhY3R1YWwgc2VydmVy IGFuZCBpcyByYXJlbHkgc2VsZWN0YWJsZSBieSBpbnRlcmFjdGlvbiwgYnV0IHNwbGl0dGluZyB0 aGUgY3VycmVudCBzaW5nbGUgZ3JvdXBpbmcgaW50byB0d28gbWF5IHByb2JhYmx5IG5vdCBoYXJt IGVpdGhlci4NCg0KQmVzdCBSZWdhcmRzLA0KQmFsYXpzDQoNCg== --_000_VI1PR0701MB201644EAA7CBEFFBFCD6381683080VI1PR0701MB2016_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWZvbnQtdmFyaWFudDpub3Jt YWwgIWltcG9ydGFudDsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7 DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1h aWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xv cjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5v bmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLkVtYWlsU3R5bGUyNA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWZv bnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQt dHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1h bGlnbjpiYXNlbGluZTt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9Indo aXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEtlbnQsPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkxvb2tzIGdvb2QgYW5kIGl0IGlzIGFsc28gZ29vZCB0aGF0IHlv dSBhZGRlZCB0aGUgc2FtZSBzdHJ1Y3R1cmUgdG8gYWxsIGZvdXIgb2YgdGhvc2Ugc3NoL3RscyBn cm91cGluZ3MuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJyLDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QmFsYXpzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gS2VudCBXYXRzZW4gJmx0O2t3 YXRzZW5AanVuaXBlci5uZXQmZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXVndXN0 IDMwLCAyMDE4IDE6NTkgQU08YnI+DQo8Yj5Ubzo8L2I+IEJhbMOhenMgS292w6FjcyAmbHQ7YmFs YXpzLmtvdmFjc0Blcmljc3Nvbi5jb20mZ3Q7OyBuZXRjb25mQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbTmV0Y29uZl0gaWV0Zi1zc2gtY2xpZW50QDIwMTgtMDYtMDQsIGlzc3Vl cyB3aXRoIHRoZSBncm91cGluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkhpIEJhbGF6cywgQWxsLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SSBtYWRlIHRoZSBjaGFuZ2UgaW4g bXkgbG9jYWwgY29weSwgYnV0IG5vdGUgdGhhdCBJIGFsc28gc2VwYXJhdGVkIHNlcnZlci1hdXRo DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+YW5kIHRyYW5zcG9ydC1wYXJhbXMuJm5ic3A7ICZuYnNwO0Jl bG93IGlzIGFuIGV4YW1wbGUsIGlzIGl0IG9rYXk/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDtncm91cGluZyBzc2gtY2xpZW50LWdy b3VwaW5nIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O2Rlc2NyaXB0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmcXVvdDtBIHJldXNhYmxlIGdyb3VwaW5nIGZvciBjb25maWd1cmlu ZyBhIFNTSCBjbGllbnQgd2l0aG91dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsgJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YW55IGNvbnNpZGVyYXRpb24gZm9yIGhv dyBhbiB1bmRlcmx5aW5nIFRDUCBzZXNzaW9uIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtlc3RhYmxpc2hlZC4mcXVv dDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3VzZXMg Y2xpZW50LWlkZW50aXR5LWdyb3VwaW5nOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7dXNlcyBzZXJ2ZXItYXV0aC1ncm91cGluZzs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3VzZXMgdHJhbnNwb3J0LXBhcmFt cy1ncm91cGluZzsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt9 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5JIG1hZGUgdGhlIGNo YW5nZSB0byBhbGwgZm91ciBvZiB0aGUgZ3JvdXBpbmdzOiBbc3NofHRsc10tW2NsaWVudHxzZXJ2 ZXJdLWdyb3VwaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ UFM6IHNvb24gSSdsbCBiZSBwb3N0aW5nIGFuIHVwZGF0ZSB0byBhbGwgdGhlc2UgZHJhZnRzIHNv IGZvbGtzIGNhbiBzZWUgdGhlIHVwZGF0ZXMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDttYWRlIHNpbmNlIHRoZSBJRVRGIDEwMiBw cmVzZW50YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5L ZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IDgvMjgvMTgsIDU6NDIgQU0sICZxdW90O0JhbMOhenMgS292w6FjcyZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmJhbGF6cy5rb3ZhY3NAZXJpY3Nzb24uY29tIj5iYWxhenMua292YWNzQGVyaWNz c29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IaSBLZW50LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIHRoaXMgd291bGQgYmUgbXkg cHJvcG9zYWwuIFdvdWxkIHNpbWlsYXIgY2hhbmdlIHRvIGlldGYtdGxzLWNsaWVudCB3b3VsZCBi ZSBhcHBsaWNhYmxlPyBJIGRvbuKAmXQgaGF2ZSB0aGUgc2FtZSBpbnRlcmFjdGl2ZSB1c2UgY2Fz ZSBmb3IgVExTLCBidXQgbWF5YmUgaGF2aW5nIHRoaXMgZmxleGliaWxpdHkgKHRoZSAyIG5ldyBn cm91cGluZ3MpIGNvdWxkIGJlIGJlbmVmaWNpYWwgZm9yIFRMUyB0b28uPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkJyLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFsYXpz IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+RnJvbTo8L2I+IEtlbnQgV2F0c2VuICZsdDs8YSBocmVmPSJtYWlsdG86a3dhdHNlbkBq dW5pcGVyLm5ldCI+a3dhdHNlbkBqdW5pcGVyLm5ldDwvYT4mZ3Q7DQo8YnI+DQo8Yj5TZW50Ojwv Yj4gTW9uZGF5LCBBdWd1c3QgMjcsIDIwMTggOTo0MiBQTTxicj4NCjxiPlRvOjwvYj4gQmFsw6F6 cyBLb3bDoWNzICZsdDs8YSBocmVmPSJtYWlsdG86YmFsYXpzLmtvdmFjc0Blcmljc3Nvbi5jb20i PmJhbGF6cy5rb3ZhY3NAZXJpY3Nzb24uY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86bmV0 Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtOZXRjb25mXSBpZXRmLXNzaC1jbGllbnRAMjAxOC0wNi0wNCwgaXNzdWVzIHdpdGggdGhl IGdyb3VwaW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QXNzdW1pbmcgeW91ciB0d28gZ3JvdXBpbmdzIGJlbG93 LCBvciBzb21ldGhpbmcgY2xvc2UgdG8gdGhlbSwgd2UgY291bGQgcmVkZWZpbmUgdGhlIGV4aXN0 aW5nICZxdW90O3NzaC1jbGllbnQtZ3JvdXBpbmcmcXVvdDsgdG8gdGhlIGZvbGxvd2luZzo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyBncm91cGluZyBz c2gtY2xpZW50LWdyb3VwaW5nIHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7ICZuYnNwOyZuYnNw O3VzZXMgc3NoLWNsaWVudC1jbGllbnQtaWRlbnRpdHktZ3JvdXBpbmc7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPiZuYnNwOyZuYnNwOyZuYnNwO3VzZXMgc3NoLWNsaWVudC1zZXJ2ZXItYXV0aC10cmFuc3Bv cnQtcGFyYW1zLWdyb3VwaW5nOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsgfTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+VGhlIG5ldC1yZXN1bHQgaXMgbm8gY2hh bmdlIHRvIHRoZSBtb2RlbCwgYnV0IG5vdyB0aGUgaW5uZXIgZ3JvdXBpbmdzIGNhbiBiZSByZXB1 cnBvc2VkLiZuYnNwOyBJcyB0aGlzIHlvdXIgcHJvcG9zYWw/PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij5LZW50IC8vIGNvbnRyaWJ1dG9yPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDgvMjcvMTgsIDM6NDkgQU0s ICZxdW90O0JhbMOhenMgS292w6FjcyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJhbGF6cy5r b3ZhY3NAZXJpY3Nzb24uY29tIj5iYWxhenMua292YWNzQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGkgS2VudCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXMgYXMgeW91IHNheSwgYW4g YXBwIHRoYXQgY2FuIGxhdW5jaCBhbiBpbnRlcmFjdGl2ZSBjb25uZWN0aW9uIHVzaW5nIHByZXZp b3VzbHkgY29uZmlndXJlZCBjbGllbnQgY3JlZGVudGlhbHMsIGhvc3QgYXV0aGVudGljYXRpb24s IGFuZCB0cmFuc3BvcnQgcGFyYW1zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSByZXF1ZXN0 IG9yIHF1ZXN0aW9uIHdvdWxkIGJlIGlmIHRoZSBjdXJyZW50IHNpbmdsZSBncm91cGluZyBjYWxs ZWQg4oCYc3NoLWNsaWVudC1ncm91cGluZ+KAmSBjb3VsZCBiZSBzcGxpdCBpbnRvIHR3bzogb25l IHRoYXQgb25seSBpbmNsdWRlcyB0aGUg4oCYY2xpZW50LWlkZW50aXR54oCZIGRlZmluaXRpb24s IGFuZCBhbm90aGVyIHdoaWNoIGluY2x1ZGVzIOKAmHNlcnZlci1hdXRo4oCZIGFuZCDigJh0cmFu c3BvcnQtcGFyYW1z4oCZLg0KIEkgdGhpbmsgdGhpcyBjaGFuZ2Ugd291bGQgZW5hYmxlIGJldHRl ciBmbGV4aWJpbGl0eSBmb3IgcmUtdXNlIGluIGNhc2Ugb2YgYW55IFNTSC1iYXNlZCBhcHBsaWNh dGlvbnMsIGFuZCB0aGUgb25seSBpbXBhY3Qgb24gdGhlIGV4aXN0aW5nIG1vZHVsZXMgdXNpbmcg c3NoLWNsaWVudC1ncm91cGluZyB3b3VsZCBiZSB0byB1c2UgdHdvIGdyb3VwaW5ncyBmcm9tIG5v dyBvbiBpbnN0ZWFkIG9mIG9uZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCB0byByZWNh cCB0aGUgdXNlIGNhc2UsIG15IGludGVudGlvbiB3b3VsZCBiZSB0byBiZSBhYmxlIHRvIG1vdW50 IGEgY2xpZW50IGlkZW50aXR5IGludG8gYSBsaXN0IGFuZCBpbnRvIGEgY29udGFpbmVyIHRoYXQg aXMgaW5kZXBlbmRlbnQgb2YgdGhlIGFjdHVhbCBlbmRwb2ludCAoZm9yIGV4YW1wbGUsIGFzIGRl ZmluZWQgaW4gbmV0Y29uZi1jbGllbnQgL25ldGNvbmYtY2xpZW50L25ldGNvbmYtc2VydmVyL2Vu ZHBvaW50cy9lbmRwb2ludCkNCiBiZWluZyB1c2VkLiBXaGljaCBpZGVudGl0eSBpcyB0byBiZSB1 c2VkIGlzIHNlbGVjdGVkIGJ5IGludGVyYWN0aW9uIHdpdGggdGhlIFNTSCBjbGllbnQgKGUuZy4s IHZpYSBhY3Rpb24gcGFyYW1ldGVyKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBkbyB5 b3UgdGhpbms/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJyLDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QmFsYXpzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gS2VudCBXYXRzZW4gJmx0Ozxh IGhyZWY9Im1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0Ij5rd2F0c2VuQGp1bmlwZXIubmV0PC9h PiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgQXVndXN0IDI1LCAyMDE4IDEyOjM5 IEFNPGJyPg0KPGI+VG86PC9iPiBCYWzDoXpzIEtvdsOhY3MgJmx0OzxhIGhyZWY9Im1haWx0bzpi YWxhenMua292YWNzQGVyaWNzc29uLmNvbSI+YmFsYXpzLmtvdmFjc0Blcmljc3Nvbi5jb208L2E+ Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3Jn PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIGlldGYtc3NoLWNsaWVudEAy MDE4LTA2LTA0LCBpc3N1ZXMgd2l0aCB0aGUgZ3JvdXBpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5IaSBCYWxh enMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5XaHkgaGF2ZSBj b25maWd1cmF0aW9uIGZvciBhbiAmcXVvdDtpbnRlcmFjdGl2ZSBjbGllbnQmcXVvdDsgYXQgYWxs PyZuYnNwOyZuYnNwOyBJcyB0aGlzIGFuIGFwcCB0aGF0IGNhbiBsYXVuY2ggYW4gaW50ZXJhY3Rp dmUgY29ubmVjdGlvbiB1c2luZyBwcmV2aW91c2x5IGNvbmZpZ3VyZWQgY2xpZW50IGNyZWRlbnRp YWxzPyZuYnNwOyBJZiBzbywgdGhlbiBJIHRoaW5rIEkgdW5kZXJzdGFuZCB0aGUgcHJvYmxlbTsN CiB0aGUgdXNlIGNhc2Ugc2VlbXMgcmF0aGVyIGRpZmZlcmVudCB0aGFuIHRoZSB1c2UgY2FzZSB0 aGF0IGlzIGN1cnJlbnRseSBiZWluZyBzb2x2ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij5JIHVuZGVyc3RhbmQgdGhlIGRlc2lyZSB0byBoYXZlIGEgWUFORyBt b2R1bGUgdG8gY2FwdHVyZSB5b3VyIGNvbmZpZywgYW5kIEkgdW5kZXJzdGFuZCB0aGUgZGVzaXJl IGZvciB0aGF0IG1vZHVsZSB0byBiZSBhYmxlIHRvIG1ha2UgdXNlIG9mIGdyb3VwaW5ncyBkZWZp bmVkIGluIHRoZSBpZXRmLXNzaC1jbGllbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5JZiB0aGUgcmVxdWVzdCBpcyB0byBleHBvc2UgYSBjb3VwbGUgZ3JvdXBp bmdzLCBidXQgb3RoZXJ3aXNlIGxlYXZlIHRoZSBtb2RlbCB1bmNoYW5nZWQsIHRoZW4gSSBjYW4g c2VlIGhvdyB0aGF0IG1pZ2h0IGJlIGRvbmUuJm5ic3A7IEJ1dCBpZiB0aGUgcmVxdWVzdCBpcyB0 byBjaGFuZ2UgZS5nLiwgc3NoLWNsaWVudC1ncm91cGluZywgdG8gc3VwcG9ydCBhIGRlY291cGxp bmcNCiBvZiBjbGllbnQgY3JlZGVudGlhbHMsIHRoZW4gSSBkb24ndCBzZWUgaG93IHRvIGRvIHRo YXQuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+S2VudCAvLyBj b250cmlidXRvcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiA4LzI0LzE4LCAxMDoxNCBBTSwgJnF1b3Q7TmV0Y29uZiBvbiBiZWhhbGYgb2YgQmFs w6F6cyBLb3bDoWNzJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGll dGYub3JnIj5uZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJl Zj0ibWFpbHRvOmJhbGF6cy5rb3ZhY3NAZXJpY3Nzb24uY29tIj5iYWxhenMua292YWNzQGVyaWNz c29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQWxsLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIG1h ZGUgYW4gYXR0ZW1wdCB0byBtYWtlIHVzZSBvZiB0aGUgaWV0Zi1zc2gtY2xpZW50QDIwMTgtMDYt MDQgbW9kdWxlIHRvIGNvbmZpZ3VyZSBhbiBpbnRlcmFjdGl2ZSBzc2ggY2xpZW50LCBhbmQgSSBm b3VuZCBzb21lIG9ic3RhY2xlcy4gVGhlIGN1cnJlbnQgaWV0Zi1zc2gtY2xpZW50IG1vZGVsIGhh cyB0aGUgZm9sbG93aW5nIHN0cnVjdHVyZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+bW9kdWxlOiBpZXRmLXNzaC1jbGllbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJiM0MzstLXJ3IGNsaWVudDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmIzQzOy0tcncgY2xpZW50LWlkZW50aXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsgJiM0MzstLXJ3IHVzZXJuYW1lPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdHJpbmc8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgKGF1dGgtdHlwZSk8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tOihwYXNzd29yZCk8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBw YXNzd29yZD8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3RyaW5nPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLToocHVibGljLWtleSk8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYj NDM7LS1ydyBwdWJsaWMta2V5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJiM0MzstLTooY2VydGlmaWNhdGUpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGNlcnRpZmlj YXRlIHtzc2hjbW46c3NoLXg1MDktY2VydHN9Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0t cncgc2VydmVyLWF1dGg8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgcGlu bmVkLXNzaC1ob3N0LWtleXM/Jm5ic3A7Jm5ic3A7IHRhOnBpbm5lZC1ob3N0LWtleXMtcmVmPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IHBpbm5lZC1jYS1jZXJ0cz8mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGE6cGlubmVkLWNlcnRpZmlj YXRlcy1yZWYge3NzaGNtbjpzc2gteDUwOS1jZXJ0c30/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsgJiM0MzstLXJ3IHBpbm5lZC1zZXJ2ZXItY2VydHM/Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRh OnBpbm5lZC1jZXJ0aWZpY2F0ZXMtcmVmIHtzc2hjbW46c3NoLXg1MDktY2VydHN9Pzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgdHJhbnNwb3J0LXBhcmFtcyB7c3NoLWNsaWVudC10cmFu c3BvcnQtcGFyYW1zLWNvbmZpZ30/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0 aGUgbmV0Y29uZi1jbGllbnQgbW9kdWxlLCB3aGljaCBJIHRvb2sgYXMgZXhhbXBsZSBpdCBpcyBt b3VudGVkIHRvIHRoZSDigJhzc2jigJkgY29udGFpbmVyIGFuZCBwcmVjZWRlZCBieTo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IG1vZHVsZTogaWV0Zi1uZXRj b25mLWNsaWVudDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgbmV0Y29uZi1jbGllbnQ8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGluaXRpYXRl ISB7aW5pdGlhdGV9Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7ICYjNDM7LS1ydyBuZXRjb25mLXNlcnZlciogW25hbWVdPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IG5h bWUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3RyaW5nPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJiM0MzstLXJ3IGVuZHBvaW50czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGVuZHBv aW50KiBbbmFtZV08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBu YW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN0cmlu Zzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3ICh0cmFuc3BvcnQp PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQz Oy0tOihzc2gpIHtzc2gtaW5pdGlhdGV9Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgc3NoPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICYjNDM7LS1ydyBhZGRyZXNzPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbmV0Omhvc3Q8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJiM0MzstLXJ3IHBvcnQ/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZXQ6 cG9ydC1udW1iZXJcPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgY2FzZSBv ZiB0aGUgaW50ZXJhY3RpdmUgY2xpZW50LCBJIHdhbnQgc29tZSBsaW1pdGVkIHBhcmFtZXRlcnMg dG8gYmUgcHJvdmlkZWQgYnkgdGhlIGludm9raW5nIHVzZXIsIHdoaWNoIGlzIGF0IGxlYXN0IHRo ZSB0YXJnZXQgdXNlciwgdGFyZ2V0IGFkZHJlc3MsIGFuZCB0YXJnZXQgcG9ydCwgc28mbmJzcDsg SSB3b3VsZCBub3QgbmVlZCBhbGwgdGhlIGRhdGEgbm9kZXMgcHJlc2VudCBpbiB0aGUgbmV0Y29u Zi1jbGllbnQsDQogYnV0IEkgbmVlZCBhIHN1YnNldCBvZiB0aGVtLCBpbmNsdWRpbmcgdGhlIHVz ZXIgY3JlZGVudGlhbHMuIFRoZSBwcm9ibGVtIEkgZmFjZSwgaXMgdGhhdCBmb3Igb25lIHRhcmdl dCBhZGRyZXNzLCB0aGUgdXNlciBjYW4gc2VsZWN0IG11bHRpcGxlIHRhcmdldCB1c2VycywgYW5k IGZvciBvbmUgdGFyZ2V0IHVzZXIsIGl0IHNob3VsZCBiZSBhYmxlIHRvIHNlbGVjdCBtdWx0aXBs ZSB0YXJnZXQgYWRkcmVzc2VzLiBXaXRoIHRoZSBhYm92ZSBtb2RlbCwNCiBpZiBJIHdhbnQgdG8g c2V0IHVwIGEgc2Vjb25kIGNsaWVudCBpZGVudGl0eSwgSSB3b3VsZCBiYXNpY2FsbHkgbmVlZCB0 byBjcmVhdGUgYSBjb21wbGV0ZSBlbmRwb2ludCB3aXRoIHRoZSBzYW1lIGRhdGEgaW4gYWxsIHRo ZSByZXN0IG9mIHRoZSBkYXRhIG5vZGVzLiBFcXVhbGx5LCBpZiBJIHdhbnQgdG8gc2V0IHVwIGEg ZGlmZmVyZW50IGVuZHBvaW50LCBJIG5lZWQgdG8gY29weSBhbGwgdGhlIHBvc3NpYmxlIGNsaWVu dCBpZGVudGl0aWVzIHRvDQogYmUgYWJsZSB0byB1c2UgdGhlbSBhdCBvdGhlciB0YXJnZXQgYWRk cmVzc2VzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSB0aGlua2luZyBpcyB0aGF0IHRoZSBl bmRwb2ludCByZWxhdGVkIGNvbmZpZ3VyYXRpb24gKGFkZHJlc3MsIHBvcnQsIHNlcnZlci1hdXRo LCB0cmFuc3BvcnQtcGFyYW1zKSBzaG91bGQgYmUgZGVjb3VwbGVkIGZyb20gY2xpZW50IGlkZW50 aXRpZXMsIHNvIEkgY2FuIHNldCB0aGVtIHVwIGFuZCBtb3VudCB0aGVtIGluZGVwZW5kZW50bHku ICZuYnNwO0hvd2V2ZXIsIEkgdGhpbmsgdGhpcyB3b3VsZCBlZmZlY3QgdGhlDQogc3NoLWNsaWVu dCBncm91cGluZyBhIGJpdCBoZWF2aWx5LCBiYXNpY2FsbHkgYnJlYWtpbmcgaXQgdXAgaW50byB0 d28gcGllY2VzLiBPbmUgdGhhdCBjYXRlcnMgZm9yIHRoZSBjbGllbnQgaWRlbnRpdHksIGFuZCBh bm90aGVyIGZvciB0aGUgZW5kcG9pbnQvc2VydmVyIHNlY3VyaXR5LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbmUgbG9va2luZyBsaWtlIHRoaXMgKHRlbXAgbmFtZSDigJhzc2gtY2xpZW50LWNs aWVudC1pZGVudGl0eS1ncm91cGluZ+KAmSk6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdyb3VwaW5nIHNzaC1jbGllbnQtY2xp ZW50LWlkZW50aXR5LWdyb3VwaW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmIzQzOy0tIGNsaWVudC1pZGVudGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7JiM0MzstLSB1c2VybmFtZT8mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg c3RyaW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz cDsmbmJzcDsmIzQzOy0tIChhdXRoLXR5cGUpPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOy0tOihw YXNzd29yZCk8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsgJiM0MzstLSBwYXNzd29yZD8mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3RyaW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQz Oy0tOihwdWJsaWMta2V5KTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjguMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyAmIzQzOy0tIHB1Ymxp Yy1rZXk8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0Mzst LS11IGtzOmxvY2FsLW9yLWtleXN0b3JlLWFzeW1tZXRyaWMta2V5LWdyb3VwaW5nPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmIzQzOy0tOihjZXJ0aWZpY2F0ZSk8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyYjNDM7LS0gY2VydGlmaWNhdGUge3NzaGNtbjpzc2gteDUwOS1jZXJ0c30/ PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm IzQzOy0tLXUga3M6bG9jYWwtb3Ita2V5c3RvcmUtZW5kLWVudGl0eS1jZXJ0aWZpY2F0ZS1ncm91 cGluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFuZCBhbm90aGVyICh0ZW1wIG5hbWUg4oCYc3NoLXNlcnZlci1hdXRoLXRyYW5zcG9ydC1w YXJhbXMtZ3JvdXBpbmfigJkpOjxvOnA+PC9vOnA+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjguMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBncm91cGluZyBzc2gtY2xpZW50LXNlcnZlci1hdXRoLXRyYW5zcG9ydC1wYXJhbXMtZ3JvdXBp bmc8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0gc2VydmVy LWF1dGg8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0 MzstLSBwaW5uZWQtc3NoLWhvc3Qta2V5cz8mbmJzcDsmbmJzcDsgdGE6cGlubmVkLWhvc3Qta2V5 cy1yZWY8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0 MzstLSBwaW5uZWQtY2EtY2VydHM/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHRhOnBpbm5lZC1jZXJ0aWZpY2F0ZXMtcmVmPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsge3NzaGNtbjpzc2gteDUwOS1jZXJ0c30/PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS0gcGlubmVkLXNlcnZlci1jZXJ0cz8mbmJzcDsm bmJzcDsmbmJzcDsgdGE6cGlubmVkLWNlcnRpZmljYXRlcy1yZWY8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsge3NzaGNtbjpzc2gteDUwOS1jZXJ0c30/PC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tIHRyYW5zcG9ydC1wYXJhbXMge3Nz aC1jbGllbnQtdHJhbnNwb3J0LXBhcmFtcy1jb25maWd9Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS11IHNzaGNtbjp0cmFu c3BvcnQtcGFyYW1zLWdyb3VwaW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGFsc28gd29uZGVyIGlmIHRoaXMgd291bGQgZWZmZWN0IHRoZSBzaW1pbGFyIG1v ZHVsZSBvZiB0bHMtY2xpZW50LiBJbiBUTFMgY2FzZSwgdGhlIGNsaWVudCBpZGVudGl0eSB1c2Vk IGlzIG1vcmUgYm91bmQgdG8gYWN0dWFsIHNlcnZlciBhbmQgaXMgcmFyZWx5IHNlbGVjdGFibGUg YnkgaW50ZXJhY3Rpb24sIGJ1dCBzcGxpdHRpbmcgdGhlIGN1cnJlbnQgc2luZ2xlIGdyb3VwaW5n IGludG8gdHdvIG1heSBwcm9iYWJseQ0KIG5vdCBoYXJtIGVpdGhlci48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QmVzdCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QmFsYXpzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_VI1PR0701MB201644EAA7CBEFFBFCD6381683080VI1PR0701MB2016_-- --_004_VI1PR07MB4735B4C1AF014281AB693E5E83430VI1PR07MB4735eurp_-- From nobody Fri Mar 22 06:07:08 2019 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 AD27C127964 for ; Fri, 22 Mar 2019 06:07:06 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 56_Nktq0OYlI for ; Fri, 22 Mar 2019 06:07:03 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7775412798E for ; Fri, 22 Mar 2019 06:07:03 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 8DFC64C1; Fri, 22 Mar 2019 14:07:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id xZZc5CarGgDu; Fri, 22 Mar 2019 14:07:01 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 22 Mar 2019 14:07:01 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 50D7D200A5; Fri, 22 Mar 2019 14:07:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id wt-OR_o0M742; Fri, 22 Mar 2019 14:07:00 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id BE68E200A6; Fri, 22 Mar 2019 14:07:00 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Fri, 22 Mar 2019 14:07:00 +0100 Received: by anna.localdomain (Postfix, from userid 501) id E792C300778D25; Fri, 22 Mar 2019 14:06:59 +0100 (CET) Date: Fri, 22 Mar 2019 14:06:59 +0100 From: Juergen Schoenwaelder To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= CC: "netconf@ietf.org" , Kent Watsen Message-ID: <20190322130659.jvofwwzcxzy5etql@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= , "netconf@ietf.org" , Kent Watsen References: <20190321152920.jdkny7szk7ik3sp4@anna.jacobs.jacobs-university.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden 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, 22 Mar 2019 13:07:07 -0000 I think we should make sure that it is clear to the client how a device handles 'hidden' keys, i.e., via a capability (if this is a system wide property) or via additional knobs that tell the client the details on a per key basis. It makes a big difference whether a key is generally protected or only via the NC/RC/.. interface. /js On Fri, Mar 22, 2019 at 12:44:05PM +0000, Bal=E1zs Kov=E1cs wrote: > Hi, >=20 > I would really prefer the definition for 'hidden' as 'not accessible vi= a YANG protocols'. The explanation is that regardless of what method I us= e to create/store the private keys, I still might not want the operator t= o generate keys outside of the device or configure binary secret strings. >=20 > I considered TPM protection for hidden keys is an option or example so = far, which adds limitations or additional complexity for moving keys, but= should not be the only option for hidden keys. The descriptions mention = TPM as example, then the rest of the text should align also to keep that = as example. >=20 > Br, > Balazs >=20 > -----Original Message----- > From: Juergen Schoenwaelder =20 > Sent: Thursday, March 21, 2019 4:29 PM > To: Bal=E1zs Kov=E1cs > Cc: netconf@ietf.org; Kent Watsen > Subject: Re: [netconf] ietf crypto types - permanently hidden >=20 > I agree, I do not understand the second sentence either. My problem is = that I do not know what a 'real' private key is, are hidden keys somewhat= unreal? Or is "not hidden" =3D "real"? >=20 > The last sentence can probably be fixed; I think the intention was to s= ay that you can't backup and restore hidden keys by retrieving configurat= ion and restoring the configuration. >=20 > In general, I think we need a definition what a hidden key is. Is somet= hing not exposed via a YANG interface a hidden key (but it may be a regul= ar key when using other device access methods)? Or do we require that a h= idden key is generally protected? I assume some people want to have flexi= bility here but from the viewpoint of a security administrator it matters= a lot whether 'hidden' means 'generally not accessible' or only 'not acc= essible via YANG protocols'. >=20 > The description of install-hidden-key seems to indicate a key is alread= y 'hidden' if it only exists in . Is this really a 'hidden' = key or more an 'ephemeral' key? >=20 > /js >=20 > On Thu, Mar 21, 2019 at 02:23:27PM +0000, Bal=E1zs Kov=E1cs wrote: > > Hi, > >=20 > > The 'generate-hidden-key' action is meant for cases when the key must= be generated in the device and not the operator is configuring it. The '= generate-hidden-key' is said to produce a 'permanently-hidden' asymmetric= key. The description of 'permanently-hidden' is as follows: > >=20 > > "The private key is inaccessible due to being > > protected by the system (e.g., a cryptographic > > hardware module). It is not possible to > > configure a permanently hidden key, as a real > > private key value must be set. Permanently > > hidden keys cannot be archived or backed up."; > >=20 > > Th second sentence doesn't sound right. I can create a permanently hi= dden key any time by calling the 'generate-hidden-key' action, or if the = device or the model allows I could even switch to non-hidden key, I belie= ve, by providing the binary. So I find the second sentence irrelevant in = this description. > >=20 > > More importantly, I find the "Permanently hidden keys cannot be archi= ved or backed up" statement false. Isn't that implementation specific how= archiving is done? If a device puts the hidden keys on some storage, it = may still be possible to back them up. I would prefer to remove this sent= ence and leave backup considerations to implementations. > >=20 > > Could these changes be done? > >=20 > > Br, > > Balazs >=20 > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf >=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Mar 22 08:45:46 2019 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 07CB31310A8; Fri, 22 Mar 2019 08:45: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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.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 WRyd6FD68k0y; Fri, 22 Mar 2019 08:45:34 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820118.outbound.protection.outlook.com [40.107.82.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 402D01310AE; Fri, 22 Mar 2019 08:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zpDojyMD0CmH4rudlXA9iwXvS2DJbH/e6EwbjArTXSA=; b=xX8mBn0R5+7ThCAX6UV/rsF8x8IyWqNKAPovOdPHfRWa1qqCK3VHQjj0vkNF5hWeovPa8tSm3FFYeZp7XM8jKl4RyV/bqVd/LX/Mg735BIP1rVTp4HGmSgha6XwSQ/fqaZU1DoJ+Izi4mqvCucezf8mH7ZnPHbuwfr7Syf169Is= Received: from BL0PR06MB5042.namprd06.prod.outlook.com (10.167.240.31) by BL0PR06MB4609.namprd06.prod.outlook.com (20.177.145.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.14; Fri, 22 Mar 2019 15:45:27 +0000 Received: from BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::d5:e11c:db10:639d]) by BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::d5:e11c:db10:639d%3]) with mapi id 15.20.1730.017; Fri, 22 Mar 2019 15:45:27 +0000 From: Michel Veillette To: "Rob Wilton (rwilton)" , "core@ietf.org" , "netconf@ietf.org" Thread-Topic: YANG encoding in CBOR Thread-Index: AdTf3q8hCOPNH5o0Q0SJZRQQHN87VgA3tcGQ Date: Fri, 22 Mar 2019 15:45:27 +0000 Message-ID: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> In-Reply-To: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 26a46e2e-c34c-40cb-35fc-08d6aedd6837 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4609; x-ms-traffictypediagnostic: BL0PR06MB4609: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 09840A4839 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(396003)(39850400004)(376002)(366004)(199004)(189003)(110136005)(68736007)(9686003)(2906002)(606006)(6246003)(71200400001)(99286004)(53936002)(476003)(26005)(71190400001)(316002)(11346002)(7696005)(5660300002)(3846002)(478600001)(446003)(6116002)(53546011)(97736004)(186003)(76176011)(6506007)(790700001)(102836004)(8936002)(486006)(7736002)(74316002)(25786009)(86362001)(52536014)(33656002)(2201001)(81166006)(6306002)(229853002)(72206003)(966005)(2501003)(55016002)(8676002)(6436002)(106356001)(54896002)(256004)(66066001)(3480700005)(105586002)(236005)(14454004)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4609; H:BL0PR06MB5042.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: HK6m1mIEdcft0HAw/nxyNQDgKkPCj8ZfYjTSIn7v6X2XsMrrqxFTA2x8DI8eue0XQdwmdSCZfb8ythShE1bJkgxxkJ9kzvWDBoTRX7mlAavn1qCbRCG4m2ISbaU0U/Aune/7jaE2KrHbHCBLSfqfpVIi7FD8LIPLwkBg4/OjMT3w2AxD+Z7e17AY9QkyncOiuYlTaWpGTCbZqAV7t4MOivM26bCabCp4XFa7Y7BJA8fqBOvT1B5OfRaOJ3m0oP/6lGVN+AHNkvRZSK/t+REC5oz63o4ri6wYgmVv9gM3ScP+HcrCoPBaUTaSR4aae3Dlf80lhfsqwcVv/P1+6lOi2tCzdSl0RTfUaMSO5NymSZxeSt+sFgLjpmuCsoeuAfFIzpRp912/0im7Gm5Puq3yVvSHHrdR8W+8TSMzIKxI8oE= Content-Type: multipart/alternative; boundary="_000_BL0PR06MB5042823429DB7CDA0F33408B9A430BL0PR06MB5042namp_" MIME-Version: 1.0 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: 26a46e2e-c34c-40cb-35fc-08d6aedd6837 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2019 15:45:27.7216 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4609 Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 22 Mar 2019 15:45:37 -0000 --_000_BL0PR06MB5042823429DB7CDA0F33408B9A430BL0PR06MB5042namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rob =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=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D About "I was wondering whether it would be better to encode enum values ...= " YANG assigns either explicitly or implicitly to each enumeration, a unique = integer value, see https://tools.ietf.org/html/rfc7950#section-9.6.4.2. In CBOR, these values are used, see https://tools.ietf.org/html/draft-ietf-= core-yang-cbor-07#section-6.6 When used outside of a union, I don't see any issues with those values. Andy, do you have a specific example for which, the current encoding is amb= iguous? =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=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The encoding of union is defined in: https://tools.ietf.org/html/draft-ietf-core-yang-cbor-07#section-6.12 Currently, each YANG datatype in a union is encoded differently to avoid an= y ambiguities between them. For example, integer 4 is encoded as: 04 # unsigned(4) enumerator value 4 is encoded as (assuming the allocated tag is 99): D8 63 # tag(99) 04 # unsigned(4) The list of these encoding is shown below: - unsigned integer --> CBOR unsigned integer - integer --> CBOR unsigned integer, CBOR negative integer - enumeration --> CBOR tag - identityref as SID --> CBOR tag - string --> CBOR text string - identityref as name --> CBOR tag - bits --> CBOR tag - binary --> CBOR byte string - decimal64 --> CBOR tag 4 - boolean --> CBOR simple value The only potential problem I aware is when multiple enumerations are part o= f the same union. Value 4 from enumeration A will be encoded the same way as Value 4 from enu= meration B. Is it a real problem is proactive? If so, how this can be resolved? I won't be present at the Prague meeting, but I'm certainly available to di= scuss this topic by email. I will be present at the Montreal meeting for any remaining discussions on = this draft. Note: I'm currently updating the draft to remove any dependencies with RFC = 7951, to resolve a comment sent by Andy. Regards Michel From: core On Behalf Of Rob Wilton (rwilton) Sent: Friday, March 22, 2019 8:43 AM To: core@ietf.org; netconf@ietf.org Subject: [core] YANG encoding in CBOR Hi, As part of YANG evolution discussion, that was some talk about using a bina= ry encoding of YANG in NETCONF or RESTCONF. CBOR looks like a good fit for this, and obviously CORE WG are working on d= raft-ietf-core-yang-cbor-07, but one comment came up from Andy that the CBO= R encoding of YANG cannot handle all YANG data models. In particular, beca= use of the way that the encoding works there are limitations on how unions = of enums work. Is that still the case? Hence I was wondering whether it would be better to encode enum values in C= BOR using module-qualified names, or also assign them SIDs and use the SIDs= . Has this approach been considered at all? Or, is there an alternative approach to how we could/should consider using = CBOR as a binary encoding for YANG data in NETCONF or RESTCONF? Do you think it would be possible to get interested parties together to dis= cuss this at some point in Prague? Thanks, Rob --_000_BL0PR06MB5042823429DB7CDA0F33408B9A430BL0PR06MB5042namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rob

 

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

About "I was wondering whether it would be better to encode enum values= …"

 

YANG assigns either explicitly or implicitly to each= enumeration, a unique integer value, see https://tools.ietf.org/html/rfc7950#section-= 9.6.4.2.

In CBOR, these values are used, see https://tools.ietf.org/html/draft-ietf-core-yang-cbor-07#section= -6.6

When used outside of a union, I don't see any issues= with those values.

Andy, do you have a specific example for which, the = current encoding is ambiguous?

 

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The encoding of union is defined in:

https://tools.ietf.org/html/draft-ietf-core-y= ang-cbor-07#section-6.12

 

Currently, each YANG datatype in a union is encoded = differently to avoid any ambiguities between  them.

For example, integer 4 is encoded as:

 

04 # unsigned(4)

 

enumerator value 4 is encoded as (assuming the alloc= ated tag is 99):

 

D8 63 # tag(99)

   04 # unsigned(4)

 

The list of these encoding is shown below:

- unsigned integer --> CBOR unsigned integer=

- integer --> CBOR unsigned integer, CBOR negativ= e integer

- enumeration --> CBOR tag <TBD>=

- identityref as SID --> CBOR tag <TBD>

- string --> CBOR text string

- identityref as name --> CBOR tag <TBD>

- bits --> CBOR tag <TBD>

- binary --> CBOR byte string

- decimal64 --> CBOR tag 4

- boolean --> CBOR simple value

 

The only potential problem I aware is when multiple = enumerations are part of the same union.

Value 4 from enumeration A will be encoded the same = way as Value 4 from enumeration B.

 

Is it a real problem is proactive?

If so, how this can be resolved?

 

I won't be present at the Prague meeting, but I'm ce= rtainly available to discuss this topic by email.

I will be present at the Montreal meeting for any re= maining discussions on this draft.

 

Note: I'm currently updating the draft to remove any= dependencies with RFC 7951, to resolve a comment sent by Andy.<= /p>

 

Regards

Michel

 

 

From: core <core-bounces@ietf.org> O= n Behalf Of Rob Wilton (rwilton)
Sent: Friday, March 22, 2019 8:43 AM
To: core@ietf.org; netconf@ietf.org
Subject: [core] YANG encoding in CBOR

 

Hi,

 

As part of YANG evolution discu= ssion, that was some talk about using a binary encoding of YANG in NETCONF = or RESTCONF.

 

CBOR looks like a good fit for = this, and obviously CORE WG are working on draft-ietf-core-yang-cbor-07, bu= t one comment came up from Andy that the CBOR encoding of YANG cannot handl= e all YANG data models.  In particular, because of the way that the encoding works there are limitations on how un= ions of enums work.  Is that still the case?

 

Hence I was wondering whether i= t would be better to encode enum values in CBOR using module-qualified name= s, or also assign them SIDs and use the SIDs.  Has this approach been = considered at all?

 

Or, is there an alternative app= roach to how we could/should consider using CBOR as a binary encoding for Y= ANG data in NETCONF or RESTCONF?

 

Do you think it would be possib= le to get interested parties together to discuss this at some point in Prag= ue?

 

Thanks,
Rob

 

--_000_BL0PR06MB5042823429DB7CDA0F33408B9A430BL0PR06MB5042namp_-- From nobody Fri Mar 22 09:08:34 2019 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 DF05B13119A; Fri, 22 Mar 2019 09:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 kmk-N-Jis68w; Fri, 22 Mar 2019 09:08:25 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECB1413117D; Fri, 22 Mar 2019 09:08:24 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44QpVG4gXKzyqr; Fri, 22 Mar 2019 17:08:22 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Fri, 22 Mar 2019 17:08:20 +0100 Cc: "Rob Wilton (rwilton)" , "core@ietf.org" , "netconf@ietf.org" X-Mao-Original-Outgoing-Id: 574963698.633944-551f0089e61a74a3cc3522d0d5977c73 Content-Transfer-Encoding: quoted-printable Message-Id: <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> To: Michel Veillette X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 22 Mar 2019 16:08:27 -0000 On Mar 22, 2019, at 16:45, Michel Veillette = wrote: >=20 > The only potential problem I aware is when multiple enumerations are = part of the same union. > Value 4 from enumeration A will be encoded the same way as Value 4 = from enumeration B. =E2=80=A6 and that is not a problem for the XML version, because the = string is being used instead of the value. (But then if two = enumerations share a string, you have the equivalent problem in the XML = serialization.) Anyway, I haven=E2=80=99t seen a piece of real-world YANG that actually = has this problem, so I would be a bit reluctant to make CBOR-based = implementations more complex (and less efficient) so solve this = (non-?)problem. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Mar 22 09:28:25 2019 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 927FB13121E for ; Fri, 22 Mar 2019 09:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.247 X-Spam-Level: X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 S2vASyFDk0Pe for ; Fri, 22 Mar 2019 09:28:21 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30093.outbound.protection.outlook.com [40.107.3.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B56521311AA for ; Fri, 22 Mar 2019 09:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+wOX6aP93Zc3QVcJtqlogPAO1sQiIlptPS+Hg5ukGeg=; b=REBtJcp+ygAE6Aoeb4hZV0KrM6Jena+tAbhbeLX5Ssd03i7m9tE6yXOc8ARx+LjSeP/8f2L9K1A0o+MxTC3C+phQ52ka/6w59ybo4qHSg+3QGqXjo2LKe3/AMVmfucRzhmOnfD3EqrpxQ2h4me+cw3ZP2tvo/j2G5yGZpLvouhY= Received: from VI1PR07MB5744.eurprd07.prod.outlook.com (20.177.202.24) by VI1PR07MB4893.eurprd07.prod.outlook.com (20.177.200.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.14; Fri, 22 Mar 2019 16:28:15 +0000 Received: from VI1PR07MB5744.eurprd07.prod.outlook.com ([fe80::4532:1dbd:fc8e:9bad]) by VI1PR07MB5744.eurprd07.prod.outlook.com ([fe80::4532:1dbd:fc8e:9bad%6]) with mapi id 15.20.1750.010; Fri, 22 Mar 2019 16:28:15 +0000 From: tom petch To: =?iso-8859-1?Q?Bal=E1zs_Kov=E1cs?= , Juergen Schoenwaelder CC: Kent Watsen , "netconf@ietf.org" Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AQHU4MxAQ+h2g0iALUGyp0wBm3vjjQ== Date: Fri, 22 Mar 2019 16:28:15 +0000 Message-ID: <00b701d4e0cb$e79e9660$4001a8c0@gateway.2wire.net> References: <20190321152920.jdkny7szk7ik3sp4@anna.jacobs.jacobs-university.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0467.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a2::23) To VI1PR07MB5744.eurprd07.prod.outlook.com (2603:10a6:803:98::24) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.215.234] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 51b586be-5faf-4847-14da-08d6aee3627e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB4893; x-ms-traffictypediagnostic: VI1PR07MB4893: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 09840A4839 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(136003)(366004)(376002)(346002)(199004)(189003)(13464003)(51444003)(6306002)(86152003)(7736002)(50226002)(8936002)(61296003)(106356001)(105586002)(53936002)(81156014)(81166006)(6436002)(6512007)(9686003)(8676002)(6246003)(229853002)(966005)(4720700003)(478600001)(14454004)(110136005)(54906003)(316002)(1556002)(44736005)(2906002)(6486002)(5660300002)(68736007)(6116002)(3846002)(66066001)(305945005)(62236002)(44716002)(66574012)(84392002)(52116002)(86362001)(446003)(476003)(14496001)(81686011)(81816011)(76176011)(26005)(186003)(25786009)(99286004)(486006)(14444005)(256004)(4326008)(71200400001)(71190400001)(53546011)(6506007)(102836004)(386003)(97736004)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4893; H:VI1PR07MB5744.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4sazlXp6oJsoyMtUMWWnS0XqmEFwSj5GrAeXMvJEhdI28vGzGn/xdocxRxv0kH3yupH2DWhMw1eYSHMN2Dnwry5FUGZyMi1cjZmZy4G8vSYexrrFA+fjwTuj3sJ/Wmbx34/cv5aPDgUtEvgalcgxlKia8aVrfOiFZR6xH3OszD/LJtO2pTqN2isrRqiGcYLybyo59BP7Emk9Zt7sLweT+Dw5N9o9PDkY47scuojbBSi4Fm2b1g7OQc1ROKb7Xd9obZLDZd+KTkUzMuX+mC+qjxYcjpLswnzgn1UEh+TnZTG+c1UZwnK8LYPVXXPLudFWR8pRqsWd3EtnMqM5QJ5jFlgJnoqouOkpovDN7bc3Gci9oEgWNapdxsIMttfsSrGWhcXYdHV6cBmrq/7gXbFDdWzB/kVNWZ85nFcSqRFY75w= Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 51b586be-5faf-4847-14da-08d6aee3627e X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2019 16:28:15.6545 (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-Transport-CrossTenantHeadersStamped: VI1PR07MB4893 Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden 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, 22 Mar 2019 16:28:24 -0000 ----- Original Message ----- From: "Bal=E1zs Kov=E1cs" Sent: Friday, March 22, 2019 12:44 PM Hi, I would really prefer the definition for 'hidden' as 'not accessible via YANG protocols'. The explanation is that regardless of what method I use to create/store the private keys, I still might not want the operator to generate keys outside of the device or configure binary secret strings. I think that the meaning of the term 'hidden' varies depending on which part of the I-D you are reading. The term is absent from the referenced RFC, 8017 and 5915, which is probably not a coincidence. Rather, the terminology of the literature is of a key pair, made up of a public and private key so the action generate-hidden-key { probably means generate-key-pair; but, in other places, the word 'hidden' clearly has different semantics and would probably best be replaced by something else, such as inaccessible. Tom Petch I considered TPM protection for hidden keys is an option or example so far, which adds limitations or additional complexity for moving keys, but should not be the only option for hidden keys. The descriptions mention TPM as example, then the rest of the text should align also to keep that as example. Br, Balazs -----Original Message----- From: Juergen Schoenwaelder Sent: Thursday, March 21, 2019 4:29 PM To: Bal=E1zs Kov=E1cs Cc: netconf@ietf.org; Kent Watsen Subject: Re: [netconf] ietf crypto types - permanently hidden I agree, I do not understand the second sentence either. My problem is that I do not know what a 'real' private key is, are hidden keys somewhat unreal? Or is "not hidden" =3D "real"? The last sentence can probably be fixed; I think the intention was to say that you can't backup and restore hidden keys by retrieving configuration and restoring the configuration. In general, I think we need a definition what a hidden key is. Is something not exposed via a YANG interface a hidden key (but it may be a regular key when using other device access methods)? Or do we require that a hidden key is generally protected? I assume some people want to have flexibility here but from the viewpoint of a security administrator it matters a lot whether 'hidden' means 'generally not accessible' or only 'not accessible via YANG protocols'. The description of install-hidden-key seems to indicate a key is already 'hidden' if it only exists in . Is this really a 'hidden' key or more an 'ephemeral' key? /js On Thu, Mar 21, 2019 at 02:23:27PM +0000, Bal=E1zs Kov=E1cs wrote: > Hi, > > The 'generate-hidden-key' action is meant for cases when the key must be generated in the device and not the operator is configuring it. The 'generate-hidden-key' is said to produce a 'permanently-hidden' asymmetric key. The description of 'permanently-hidden' is as follows: > > "The private key is inaccessible due to being > protected by the system (e.g., a cryptographic > hardware module). It is not possible to > configure a permanently hidden key, as a real > private key value must be set. Permanently > hidden keys cannot be archived or backed up."; > > Th second sentence doesn't sound right. I can create a permanently hidden key any time by calling the 'generate-hidden-key' action, or if the device or the model allows I could even switch to non-hidden key, I believe, by providing the binary. So I find the second sentence irrelevant in this description. > > More importantly, I find the "Permanently hidden keys cannot be archived or backed up" statement false. Isn't that implementation specific how archiving is done? If a device puts the hidden keys on some storage, it may still be possible to back them up. I would prefer to remove this sentence and leave backup considerations to implementations. > > Could these changes be done? > > Br, > Balazs > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Fri Mar 22 09:38:08 2019 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 BC877131272 for ; Fri, 22 Mar 2019 09:38:05 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 9pFnQJI6nSNi for ; Fri, 22 Mar 2019 09:38:02 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 7A33613126B for ; Fri, 22 Mar 2019 09:38:02 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id y6so2564819ljd.12 for ; Fri, 22 Mar 2019 09:38:02 -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=XbV+v0F4IWhHYrZLR1LxIz8hjL3gK1t4DnGZMzQqnlE=; b=ueOc43Hxjwr37UTVgJNCeWc7guqlZN6yFMaho0H5iVHYiX2ghbGZFYQMzYcuwjElha VsX80ebkxAK6Zgc0Vgd08+77JILTBImMHZL75omvo1gHs+SmivWKOldr+ec5j51Ja4HR jO06Pc7gkSRT/8yAxUIjIuxByoxeGoTg1CaPEDk1xPccqX0MpwPjS8OSpXRUgJWtA9cD Va3JWtXYRHMb0Z0FI6adlsphWderhEHHXC4bc6Zn3bC6znFSJVGUw/TkzLK5VGM71/Sv HSPq5KOZ1MnNr+MNs//+tqJCLbjQYOWpTuCnMQNCYc62qyy4d+mzk6BcTPbQS04vpW+d KLfQ== 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=XbV+v0F4IWhHYrZLR1LxIz8hjL3gK1t4DnGZMzQqnlE=; b=rMTrf8trRJBdyY0nIJlbepGi1WGSzMrE6OcxpQTAWR+uYWHMW1HuOi3l4FQmd+h8og 1UYMhr9oKI36j6+3G29eRvLTehnymRUzItkocy9/00r3xRpYEwu7wydjWZJ6Z/T2qf24 9339HcNbSC7qIGB0AMHLGb5dHIy3xqRbA8oJtvsaLiO25BRUovyQvOVW1ciRgYbUnrnn aEOwXD7bnNY4OBch/HmFnTt+fPkNgm+kqi5Fvt7KSHkR2wxevVv33/bZqeHhyQFMcM5q QW7TscdGsBHlLGgGQ7Ck0BS5vqKRu2IjLxm5bEfPFpkaYUYLg+e08kKfjpP2mZuYu2UT cy4Q== X-Gm-Message-State: APjAAAVWffN7Rag+QqRCGWP2KqW/qhjCVWOE0UcTXNUiftecuakbmHVe eaoj4z0kHLN29o3PuQ2rCWhFEgYJBJADyIXxB2lTtQ== X-Google-Smtp-Source: APXvYqzCr9/jMoeCv8dXiX02K4OTjQrk8e/Em+9FLIeQ4jD7B8JMRgFq0F2TAwiXcfObI7b39tyMS9ndwaof6W9vry4= X-Received: by 2002:a2e:551d:: with SMTP id j29mr3704471ljb.180.1553272680645; Fri, 22 Mar 2019 09:38:00 -0700 (PDT) MIME-Version: 1.0 References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> In-Reply-To: <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> From: Andy Bierman Date: Fri, 22 Mar 2019 09:37:49 -0700 Message-ID: To: Carsten Bormann Cc: Michel Veillette , "netconf@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005ea0a50584b17ad4" Archived-At: Subject: Re: [netconf] [core] YANG encoding in CBOR 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, 22 Mar 2019 16:38:06 -0000 --0000000000005ea0a50584b17ad4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 22, 2019 at 9:08 AM Carsten Bormann wrote: > On Mar 22, 2019, at 16:45, Michel Veillette < > Michel.Veillette@trilliant.com> wrote: > > > > The only potential problem I aware is when multiple enumerations are > part of the same union. > > Value 4 from enumeration A will be encoded the same way as Value 4 from > enumeration B. > > =E2=80=A6 and that is not a problem for the XML version, because the stri= ng is > being used instead of the value. (But then if two enumerations share a > string, you have the equivalent problem in the XML serialization.) > > The union data type has similar issues with JSON encoding, where the JSON encoding can influence the YANG decoding. This is not possible with XML since all values are strings. Anyway, I haven=E2=80=99t seen a piece of real-world YANG that actually has= this > problem, so I would be a bit reluctant to make CBOR-based implementations > more complex (and less efficient) so solve this (non-?)problem. > > I agree, but tools still need to identify the problem if it exists and flag the object for different processing or no processing at all (draft says YANG with these conflicts are not allowed). IMO a string encoding should be used. All YANG union types are position-dependent. The parser goes through the member types in order, and first one that accepts the value given wins. (e.g, ip-address, or any union with 2 of the same base type). We discussed this issue during the NETMOD WG virtual interim this week, and wanted clarification on the scope of the problem. It seems to be limited to just multiple enumerations in a union. The rest of the corner-cases are just position-dependent, same as before. Gr=C3=BC=C3=9Fe, Carsten > > Andy > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --0000000000005ea0a50584b17ad4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Mar 22, 2019 at 9:08 AM Carst= en Bormann <cabo@tzi.o= rg> wrote:
Michel.Veillette@trilliant.com> wrote:
>
> The only potential problem I aware is when multiple enumerations are p= art of the same union.
> Value 4 from enumeration A will be encoded the same way as Value 4 fro= m enumeration B.

=E2=80=A6 and that is not a problem for the XML version, because the string= is being used instead of the value.=C2=A0 (But then if two enumerations sh= are a string, you have the equivalent problem in the XML serialization.)


The union data type has= similar issues with JSON encoding, where the JSON encoding can
i= nfluence the YANG decoding. This is not possible with XML since all values = are strings.


Anyway, I haven=E2=80=99t seen a piece of real-world YANG that actually has= this problem, so I would be a bit reluctant to make CBOR-based implementat= ions more complex (and less efficient) so solve this (non-?)problem.


I agree, but tools still need to ident= ify the problem if it exists and flag the object for different processing
or no processing at all (draft says YANG with these conflicts are = not allowed). IMO a string encoding
should be used.
All YANG union types are position-dependent.
The pars= er goes through the member types in order, and first one that accepts the v= alue given wins.
(e.g, ip-address, or any union with 2 of the sam= e base type).

We discussed this issue during the N= ETMOD WG virtual interim this week, and wanted clarification
on t= he scope of the problem. It seems to be limited to just multiple enumeratio= ns in a union.
The rest of the corner-cases are just position-dep= endent, same as before.


Gr=C3=BC=C3=9Fe, Carsten


Andy
=C2=A0
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--0000000000005ea0a50584b17ad4-- From nobody Fri Mar 22 09:41:15 2019 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 0428213128A; Fri, 22 Mar 2019 09:41:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 uPcg3SvLSjYZ; Fri, 22 Mar 2019 09:41:06 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11A1213127F; Fri, 22 Mar 2019 09:41:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id B3B5D24; Fri, 22 Mar 2019 17:41:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id SDykB8CYOjRq; Fri, 22 Mar 2019 17:41:04 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 22 Mar 2019 17:41:04 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 769A6200A6; Fri, 22 Mar 2019 17:41:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id GfnybAc6SZlS; Fri, 22 Mar 2019 17:41:04 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 36BA1200A5; Fri, 22 Mar 2019 17:41:04 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Fri, 22 Mar 2019 17:41:03 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 47BCD300779637; Fri, 22 Mar 2019 17:41:03 +0100 (CET) Date: Fri, 22 Mar 2019 17:41:02 +0100 From: Juergen Schoenwaelder To: Carsten Bormann CC: Michel Veillette , "netconf@ietf.org" , "core@ietf.org" Message-ID: <20190322164102.pa6xl5elsavqrk6q@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Carsten Bormann , Michel Veillette , "netconf@ietf.org" , "core@ietf.org" References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] [core] YANG encoding in CBOR 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, 22 Mar 2019 16:41:09 -0000 On Fri, Mar 22, 2019 at 05:08:20PM +0100, Carsten Bormann wrote: >=20 > Anyway, I haven=E2=80=99t seen a piece of real-world YANG that actually= has this problem, so I would be a bit reluctant to make CBOR-based imple= mentations more complex (and less efficient) so solve this (non-?)problem= . > I think we need to make sure that the interpretation of yang-defined data is _always_ the same and does not depend on the encoding negotiated between a client and a server. Efficiency is nice, avoiding ambiguity is a must. Avoiding ambiguity can be achieved in different ways, such as making sure all encodings are designed to not allow different interpretations (even if that means a loss of efficiency in some cases) or by changing YANG (or YANG usage guidelines) such that constructs that may lead to ambiguities are impossible or at least flagged and then avoided. I guess this is why this topic pops up in the context of YANG next and we need to figure out which road to take. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Mar 22 10:30:30 2019 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 9BE3A131351; Fri, 22 Mar 2019 10:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 AQH4D6Wphttm; Fri, 22 Mar 2019 10:30:12 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99180131350; Fri, 22 Mar 2019 10:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1832; q=dns/txt; s=iport; t=1553275812; x=1554485412; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HUMyYHwwn7vEgR9EnhHmJD5dtpUju1yHshbww2VzeyM=; b=NsYVSkkJqBufihbkA1xcqHRH6e2n17Iu3knME3wi9EGxv/YAZtEayNbp ocA9spdDrxJXP+RBuhj+J2Tv6roCtiFtMyK/zUc0LudQJlg6Q+DeBWALZ +3pqXfL0zdf/5fD5np1RCuuoLxxyT53vixKkbGc7UC6DYTR5nSJRvsBbO s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADKGpVc/51dJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBghCBaycKhASIHI0tmDiBew0BAYRsAhe?= =?us-ascii?q?EZSI0CQ0BAQMBAQkBAwJtKIVKAQEBBCMRRQwEAgEGAg4DBAEBAQICJgICAjA?= =?us-ascii?q?VCAgBAQQBDQUIhRCNZZtmgS+KL4ELJAGLMReBQD+BEYMSPoRLM4JQglcDjG2?= =?us-ascii?q?YIAkCky4hk3yLGJMkAhEVgS4fOIFWcBWDJ5BLQTGNY4EfAQE?= X-IronPort-AV: E=Sophos;i="5.60,256,1549929600"; d="scan'208";a="248849769" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Mar 2019 17:30:11 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x2MHU6GQ021002 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Mar 2019 17:30:10 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 22 Mar 2019 12:30:09 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Fri, 22 Mar 2019 12:30:09 -0500 From: "Rob Wilton (rwilton)" To: Carsten Bormann , Michel Veillette CC: "core@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] YANG encoding in CBOR Thread-Index: AdTf3q8hCOPNH5o0Q0SJZRQQHN87VgA3tcGQAA12kQAAB/hI0A== Date: Fri, 22 Mar 2019 17:30:09 +0000 Message-ID: <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> In-Reply-To: <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.76.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 22 Mar 2019 17:30:15 -0000 SSBndWVzcyB0aGF0IHRoZSBjb25jZXJuIGlzIHRoYXQgdGhpcyBpbnRyb2R1Y2VzIG1vcmUgdmFy aWF0aW9uIGluIGhvdyBkYXRhIGlzIGludGVycHJldGVkIGJldHdlZW4gdGhlIGRpZmZlcmVudCBY TUwvSlNPTi9DQk9SIGVuY29kaW5ncy4NCg0KRS5nLiBpZiBzb21lb25lIHN3aXRjaGVkIGZyb20g WE1MIHRvIENCT1IsIHN1ZGRlbmx5IHRoZSBjb25maWd1cmF0aW9uIG9yIHN0YXRlIGRhdGEgbWF5 IGhhdmUgYSBkaWZmZXJlbnQgbWVhbmluZy4NCg0KVGhhbmtzLA0KUm9iDQoNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9y Zz4NCj4gU2VudDogMjIgTWFyY2ggMjAxOSAxNjowOA0KPiBUbzogTWljaGVsIFZlaWxsZXR0ZSA8 TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQuY29tPg0KPiBDYzogUm9iIFdpbHRvbiAocndpbHRv bikgPHJ3aWx0b25AY2lzY28uY29tPjsgY29yZUBpZXRmLm9yZzsNCj4gbmV0Y29uZkBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSZTogW25ldGNvbmZdIFlBTkcgZW5jb2RpbmcgaW4gQ0JPUg0KPiANCj4g T24gTWFyIDIyLCAyMDE5LCBhdCAxNjo0NSwgTWljaGVsIFZlaWxsZXR0ZSA8TWljaGVsLlZlaWxs ZXR0ZUB0cmlsbGlhbnQuY29tPg0KPiB3cm90ZToNCj4gPg0KPiA+IFRoZSBvbmx5IHBvdGVudGlh bCBwcm9ibGVtIEkgYXdhcmUgaXMgd2hlbiBtdWx0aXBsZSBlbnVtZXJhdGlvbnMgYXJlIHBhcnQg b2YNCj4gdGhlIHNhbWUgdW5pb24uDQo+ID4gVmFsdWUgNCBmcm9tIGVudW1lcmF0aW9uIEEgd2ls bCBiZSBlbmNvZGVkIHRoZSBzYW1lIHdheSBhcyBWYWx1ZSA0IGZyb20NCj4gZW51bWVyYXRpb24g Qi4NCj4gDQo+IOKApiBhbmQgdGhhdCBpcyBub3QgYSBwcm9ibGVtIGZvciB0aGUgWE1MIHZlcnNp b24sIGJlY2F1c2UgdGhlIHN0cmluZyBpcyBiZWluZyB1c2VkDQo+IGluc3RlYWQgb2YgdGhlIHZh bHVlLiAgKEJ1dCB0aGVuIGlmIHR3byBlbnVtZXJhdGlvbnMgc2hhcmUgYSBzdHJpbmcsIHlvdSBo YXZlIHRoZQ0KPiBlcXVpdmFsZW50IHByb2JsZW0gaW4gdGhlIFhNTCBzZXJpYWxpemF0aW9uLikN Cj4gDQo+IEFueXdheSwgSSBoYXZlbuKAmXQgc2VlbiBhIHBpZWNlIG9mIHJlYWwtd29ybGQgWUFO RyB0aGF0IGFjdHVhbGx5IGhhcyB0aGlzDQo+IHByb2JsZW0sIHNvIEkgd291bGQgYmUgYSBiaXQg cmVsdWN0YW50IHRvIG1ha2UgQ0JPUi1iYXNlZCBpbXBsZW1lbnRhdGlvbnMNCj4gbW9yZSBjb21w bGV4IChhbmQgbGVzcyBlZmZpY2llbnQpIHNvIHNvbHZlIHRoaXMgKG5vbi0/KXByb2JsZW0uDQo+ IA0KPiBHcsO8w59lLCBDYXJzdGVuDQoNCg== From nobody Fri Mar 22 10:32:46 2019 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 002E113124D; Fri, 22 Mar 2019 10:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 kESfwdQ52kJy; Fri, 22 Mar 2019 10:32:42 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1AC3131362; Fri, 22 Mar 2019 10:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16959; q=dns/txt; s=iport; t=1553275962; x=1554485562; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=cAZv961zRktHDt5LV5+eOjxytb5d77os58Lam1lZSr8=; b=RjbQzFNepV1HAo4KrNprMgo9z6YF/jfwH4jHMZvXHoJfd36ifZdZZ0iT 2lr1bPlEZ6Iv6Lz87U7o2zhxKvktij+EWXDXc/qsODXG6exO0kdERp5wN 0yl97/x2ba+pNlJFaZW5HBfefbQ1TvEs8gKBhNlMWlPGuYQNp8KkXYrlI U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAC4G5Vc/4kNJK1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDoECaIEDJwqMIIsggg2SQYV3FIFnDQEBI4R?= =?us-ascii?q?JAoR8IjQJDQEBAwEBCQEDAm0cDIVKAQEBBCcGXAIBCBEEAQEoBzIUCQgBAQQ?= =?us-ascii?q?BEgiDG4ERZA+qPjOKKQWBLwGLMReBQD+BEYMSPoJhAQECAYErARIBLSiFKwO?= =?us-ascii?q?KFSCGUx6TB2AJAodhi00hk3yLGIYCjSICERWBLh84KD1xcBU7gmyCFheIX4U?= =?us-ascii?q?/QTEBAQGMQYEfgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.60,256,1549929600"; d="scan'208,217";a="251126838" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Mar 2019 17:32:37 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x2MHWbbi001478 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Mar 2019 17:32:37 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 22 Mar 2019 12:32:36 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Fri, 22 Mar 2019 12:32:36 -0500 From: "Rob Wilton (rwilton)" To: Michel Veillette , "core@ietf.org" , "netconf@ietf.org" Thread-Topic: YANG encoding in CBOR Thread-Index: AdTf3q8hCOPNH5o0Q0SJZRQQHN87VgA3tcGQAAXew9A= Date: Fri, 22 Mar 2019 17:32:36 +0000 Message-ID: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.76.6] Content-Type: multipart/alternative; boundary="_000_edbd00c68ad2440684d61160be263e9cXCHRCD007ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 22 Mar 2019 17:32:45 -0000 --_000_edbd00c68ad2440684d61160be263e9cXCHRCD007ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Michael, Indeed, it was the encoding of unions containing more than one enum that wa= s the concern raised in the meeting. Thanks, Rob From: Michel Veillette Sent: 22 March 2019 15:45 To: Rob Wilton (rwilton) ; core@ietf.org; netconf@ietf.o= rg Subject: RE: YANG encoding in CBOR Hi Rob =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=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D About "I was wondering whether it would be better to encode enum values ...= " YANG assigns either explicitly or implicitly to each enumeration, a unique = integer value, see https://tools.ietf.org/html/rfc7950#section-9.6.4.2. In CBOR, these values are used, see https://tools.ietf.org/html/draft-ietf-= core-yang-cbor-07#section-6.6 When used outside of a union, I don't see any issues with those values. Andy, do you have a specific example for which, the current encoding is amb= iguous? =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=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The encoding of union is defined in: https://tools.ietf.org/html/draft-ietf-core-yang-cbor-07#section-6.12 Currently, each YANG datatype in a union is encoded differently to avoid an= y ambiguities between them. For example, integer 4 is encoded as: 04 # unsigned(4) enumerator value 4 is encoded as (assuming the allocated tag is 99): D8 63 # tag(99) 04 # unsigned(4) The list of these encoding is shown below: - unsigned integer --> CBOR unsigned integer - integer --> CBOR unsigned integer, CBOR negative integer - enumeration --> CBOR tag - identityref as SID --> CBOR tag - string --> CBOR text string - identityref as name --> CBOR tag - bits --> CBOR tag - binary --> CBOR byte string - decimal64 --> CBOR tag 4 - boolean --> CBOR simple value The only potential problem I aware is when multiple enumerations are part o= f the same union. Value 4 from enumeration A will be encoded the same way as Value 4 from enu= meration B. Is it a real problem is proactive? If so, how this can be resolved? I won't be present at the Prague meeting, but I'm certainly available to di= scuss this topic by email. I will be present at the Montreal meeting for any remaining discussions on = this draft. Note: I'm currently updating the draft to remove any dependencies with RFC = 7951, to resolve a comment sent by Andy. Regards Michel From: core > On Behalf = Of Rob Wilton (rwilton) Sent: Friday, March 22, 2019 8:43 AM To: core@ietf.org; netconf@ietf.org Subject: [core] YANG encoding in CBOR Hi, As part of YANG evolution discussion, that was some talk about using a bina= ry encoding of YANG in NETCONF or RESTCONF. CBOR looks like a good fit for this, and obviously CORE WG are working on d= raft-ietf-core-yang-cbor-07, but one comment came up from Andy that the CBO= R encoding of YANG cannot handle all YANG data models. In particular, beca= use of the way that the encoding works there are limitations on how unions = of enums work. Is that still the case? Hence I was wondering whether it would be better to encode enum values in C= BOR using module-qualified names, or also assign them SIDs and use the SIDs= . Has this approach been considered at all? Or, is there an alternative approach to how we could/should consider using = CBOR as a binary encoding for YANG data in NETCONF or RESTCONF? Do you think it would be possible to get interested parties together to dis= cuss this at some point in Prague? Thanks, Rob --_000_edbd00c68ad2440684d61160be263e9cXCHRCD007ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Michael,

 

Indeed, it was the encoding of unions containing more than one enum th= at was the concern raised in the meeting.

 

Thanks,

Rob

 

 

From: Michel Veillette <Michel.Veillette@trilliant.com>
Sent: 22 March 2019 15:45
To: Rob Wilton (rwilton) <rwilton@cisco.com>; core@ietf.org; n= etconf@ietf.org
Subject: RE: YANG encoding in CBOR

 

Hi Rob

 

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

About "I was wonder= ing whether it would be better to encode enum values …"

 

YANG assigns either explicitly = or implicitly to each enumeration, a unique integer value, see https://tools.ietf.org/html/rfc7950#s= ection-9.6.4.2.

In CBOR, these values are used,= see https://tools.ietf.org/html/draft-ietf-core-yang= -cbor-07#section-6.6

When used outside of a union, I= don't see any issues with those values.

Andy, do you have a specific ex= ample for which, the current encoding is ambiguous?

 

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

The encoding of union is define= d in:

https://tools.ietf.org/h= tml/draft-ietf-core-yang-cbor-07#section-6.12

 

Currently, each YANG datatype i= n a union is encoded differently to avoid any ambiguities between  the= m.

For example, integer 4 is encod= ed as:

 

04 # unsigned(4)

 

enumerator value 4 is encoded a= s (assuming the allocated tag is 99):

 

D8 63 # tag(99)

   04 # unsigned(4)

 

The list of these encoding is s= hown below:

- unsigned integer --> CBOR = unsigned integer

- integer --> CBOR unsigned = integer, CBOR negative integer

- enumeration --> CBOR tag &= lt;TBD>

- identityref as SID --> CBO= R tag <TBD>

- string --> CBOR text strin= g

- identityref as name --> CB= OR tag <TBD>

- bits --> CBOR tag <TBD&= gt;

- binary --> CBOR byte strin= g

- decimal64 --> CBOR tag 4

- boolean --> CBOR simple va= lue

 

The only potential problem I aw= are is when multiple enumerations are part of the same union.

Value 4 from enumeration A will= be encoded the same way as Value 4 from enumeration B.

 

Is it a real problem is proacti= ve?

If so, how this can be resolved= ?

 

I won't be present at the Pragu= e meeting, but I'm certainly available to discuss this topic by email.=

I will be present at the Montre= al meeting for any remaining discussions on this draft.

 

Note: I'm currently updating th= e draft to remove any dependencies with RFC 7951, to resolve a comment sent= by Andy.

 

Regards

Michel

 

 

From: core <core-bounces@= ietf.org> On Behalf Of Rob Wilton (rwilton)
Sent: Friday, March 22, 2019 8:43 AM
To: core@ietf.org; netconf@ietf.org
Subject: [core] YANG encoding in CBOR

 

Hi,

 

As part of YANG evolution discussion, that was some = talk about using a binary encoding of YANG in NETCONF or RESTCONF.

 

CBOR looks like a good fit for this, and obviously C= ORE WG are working on draft-ietf-core-yang-cbor-07, but one comment came up= from Andy that the CBOR encoding of YANG cannot handle all YANG data model= s.  In particular, because of the way that the encoding works there are limitations on how unions of enums w= ork.  Is that still the case?

 

Hence I was wondering whether it would be better to = encode enum values in CBOR using module-qualified names, or also assign the= m SIDs and use the SIDs.  Has this approach been considered at all?

 

Or, is there an alternative approach to how we could= /should consider using CBOR as a binary encoding for YANG data in NETCONF o= r RESTCONF?

 

Do you think it would be possible to get interested = parties together to discuss this at some point in Prague?

 

Thanks,
Rob

 

--_000_edbd00c68ad2440684d61160be263e9cXCHRCD007ciscocom_-- From nobody Fri Mar 22 11:34:10 2019 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 A4E39131430; Fri, 22 Mar 2019 11:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.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 NDGIHNZsZS_m; Fri, 22 Mar 2019 11:34:04 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680123.outbound.protection.outlook.com [40.107.68.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1860413142E; Fri, 22 Mar 2019 11:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2I3cDsw5K7wkdV7T5zOjGmfE/lybhT6U1fv4k+FFHns=; b=qmhObOpBhvVF9GYOZBEYOZognvUAGrZPMD4eXQDxG/4Kkqrrp+j44m0RN7qPAPexrJqnhM6uDHuhGSpO9qWzTFPy6LB7f0k/Vi85DvJo8Rctn++4tGVjPF1OdIbl/fk3GlNkjdrvi4YKqhD+IvAVKyZKdPtHHyc/8rHh2VxHNcA= Received: from DM6PR06MB5049.namprd06.prod.outlook.com (20.176.122.224) by DM6PR06MB5946.namprd06.prod.outlook.com (20.179.163.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.15; Fri, 22 Mar 2019 18:34:00 +0000 Received: from DM6PR06MB5049.namprd06.prod.outlook.com ([fe80::1cf7:3307:9831:558e]) by DM6PR06MB5049.namprd06.prod.outlook.com ([fe80::1cf7:3307:9831:558e%4]) with mapi id 15.20.1709.015; Fri, 22 Mar 2019 18:34:00 +0000 From: Michel Veillette To: "Rob Wilton (rwilton)" , "core@ietf.org" , "netconf@ietf.org" Thread-Topic: YANG encoding in CBOR Thread-Index: AdTf3q8hCOPNH5o0Q0SJZRQQHN87VgA3tcGQAAXew9AAAeuD8A== Date: Fri, 22 Mar 2019 18:34:00 +0000 Message-ID: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 547e9d3f-3261-4656-fede-08d6aef4f3ee x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM6PR06MB5946; x-ms-traffictypediagnostic: DM6PR06MB5946: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 09840A4839 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(39830400003)(396003)(366004)(376002)(199004)(189003)(478600001)(6116002)(81156014)(6436002)(6246003)(9686003)(6306002)(54896002)(72206003)(14454004)(229853002)(8676002)(55016002)(7696005)(2501003)(3846002)(99286004)(68736007)(25786009)(5660300002)(966005)(74316002)(236005)(790700001)(105586002)(110136005)(53936002)(8936002)(86362001)(486006)(2906002)(71200400001)(52536014)(11346002)(446003)(106356001)(2201001)(97736004)(7736002)(476003)(71190400001)(3480700005)(26005)(102836004)(6506007)(66066001)(53546011)(81166006)(76176011)(606006)(186003)(33656002)(256004)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR06MB5946; H:DM6PR06MB5049.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: HcLxRl3D0FCsq/IsL7EX4ihOBgQZWyhWODV0EVpXjrQ2q79JkmiWgqq2zeNvhJp3aKYbvKoJHA+NIQJZPRJgqrMAVeoERV3K9Nda94IZSeW6b37h/82u216Eb2J05HtOE03TE4kL0EP9+GNL6cxaMN7Gyb2P9QPmepx9Bjzo0H8Kr35IYyqJQziJRIGRmwzkWvwi1bxLOn8cgWtiHefvMtSC+IZ10dkNckwRhwJ8DwjU5O5N+rVKTxhEPSIgF2I6GYxqRzn5q4CN8wfZh+QN66jqgVgo0evibdK4IV0ehQ+t65IPqul4hVO5AmJAz/M0XOBPf6jkkJTkAi453Sl+hzbEjruriTN9OAQPtVTWvBo+OUB1E5utWGa9R0O4DkiT0Q+tZWBKPxZO3qsJtzsIzYQ8A7G+unX7mUeLk83jYgk= Content-Type: multipart/alternative; boundary="_000_DM6PR06MB50497E9F418DF2F9EEA2E5469A430DM6PR06MB5049namp_" MIME-Version: 1.0 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: 547e9d3f-3261-4656-fede-08d6aef4f3ee X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2019 18:34:00.5221 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB5946 Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 22 Mar 2019 18:34:08 -0000 --_000_DM6PR06MB50497E9F418DF2F9EEA2E5469A430DM6PR06MB5049namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rob Any solutions have been discussed or proposed? Encoding enumerators part of a union as CBOR text string might be the simpl= es solution. Would you please discuss this proposed solution with any and any other inte= rested parties in Prague. Regards Michel From: Rob Wilton (rwilton) Sent: Friday, March 22, 2019 1:33 PM To: Michel Veillette ; core@ietf.org; netco= nf@ietf.org Subject: RE: YANG encoding in CBOR Hi Michael, Indeed, it was the encoding of unions containing more than one enum that wa= s the concern raised in the meeting. Thanks, Rob From: Michel Veillette > Sent: 22 March 2019 15:45 To: Rob Wilton (rwilton) >; cor= e@ietf.org; netconf@ietf.org Subject: RE: YANG encoding in CBOR Hi Rob =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=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D About "I was wondering whether it would be better to encode enum values ...= " YANG assigns either explicitly or implicitly to each enumeration, a unique = integer value, see https://tools.ietf.org/html/rfc7950#section-9.6.4.2. In CBOR, these values are used, see https://tools.ietf.org/html/draft-ietf-= core-yang-cbor-07#section-6.6 When used outside of a union, I don't see any issues with those values. Andy, do you have a specific example for which, the current encoding is amb= iguous? =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=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The encoding of union is defined in: https://tools.ietf.org/html/draft-ietf-core-yang-cbor-07#section-6.12 Currently, each YANG datatype in a union is encoded differently to avoid an= y ambiguities between them. For example, integer 4 is encoded as: 04 # unsigned(4) enumerator value 4 is encoded as (assuming the allocated tag is 99): D8 63 # tag(99) 04 # unsigned(4) The list of these encoding is shown below: - unsigned integer --> CBOR unsigned integer - integer --> CBOR unsigned integer, CBOR negative integer - enumeration --> CBOR tag - identityref as SID --> CBOR tag - string --> CBOR text string - identityref as name --> CBOR tag - bits --> CBOR tag - binary --> CBOR byte string - decimal64 --> CBOR tag 4 - boolean --> CBOR simple value The only potential problem I aware is when multiple enumerations are part o= f the same union. Value 4 from enumeration A will be encoded the same way as Value 4 from enu= meration B. Is it a real problem is real life? If so, how this can be resolved? I won't be present at the Prague meeting, but I'm certainly available to di= scuss this topic by email. I will be present at the Montreal meeting for any remaining discussions on = this draft. Note: I'm currently updating the draft to remove any dependencies with RFC = 7951, to resolve a comment sent by Andy. Regards Michel From: core > On Behalf = Of Rob Wilton (rwilton) Sent: Friday, March 22, 2019 8:43 AM To: core@ietf.org; netconf@ietf.org Subject: [core] YANG encoding in CBOR Hi, As part of YANG evolution discussion, that was some talk about using a bina= ry encoding of YANG in NETCONF or RESTCONF. CBOR looks like a good fit for this, and obviously CORE WG are working on d= raft-ietf-core-yang-cbor-07, but one comment came up from Andy that the CBO= R encoding of YANG cannot handle all YANG data models. In particular, beca= use of the way that the encoding works there are limitations on how unions = of enums work. Is that still the case? Hence I was wondering whether it would be better to encode enum values in C= BOR using module-qualified names, or also assign them SIDs and use the SIDs= . Has this approach been considered at all? Or, is there an alternative approach to how we could/should consider using = CBOR as a binary encoding for YANG data in NETCONF or RESTCONF? Do you think it would be possible to get interested parties together to dis= cuss this at some point in Prague? Thanks, Rob --_000_DM6PR06MB50497E9F418DF2F9EEA2E5469A430DM6PR06MB5049namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rob

 

Any solutions have been discuss= ed or proposed?

 

Encoding enumerators part of a = union as CBOR text string might be the simples solution.<= /p>

Would you please discuss this p= roposed solution with any and any other interested parties in Prague.<= /o:p>

 

Regards

Michel

 

From: Rob Wilton (rwilton) <rwilton@cisco.= com>
Sent: Friday, March 22, 2019 1:33 PM
To: Michel Veillette <Michel.Veillette@trilliant.com>; core@ie= tf.org; netconf@ietf.org
Subject: RE: YANG encoding in CBOR

 

Hi Mich= ael,

&n= bsp;

Indeed,= it was the encoding of unions containing more than one enum that was the c= oncern raised in the meeting.

&n= bsp;

Thanks,=

Rob

&n= bsp;

&n= bsp;

From: Michel Veillette <Michel.Veillette@trilliant.com>
Sent: 22 March 2019 15:45
To: Rob Wilton (rwilton) <rw= ilton@cisco.com>; core@ietf.org; netconf@ietf.org
Subject: RE: YANG encoding in CBOR

 

Hi Rob

 

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

About "I was wondering whether it would be better to encode enum values= …"

 

YANG assigns either explicitly or implicitly to each= enumeration, a unique integer value, see = https://tools.ietf.org/html/rfc7950#section-9.6.4.2.=

In CBOR, these values are used, see https://tools.ietf.org/h= tml/draft-ietf-core-yang-cbor-07#section-6.6

When used outside of a union, I don't see any issues= with those values.

Andy, do you have a specific example for which, the = current encoding is ambiguous?

 

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The encoding of union is defined in:

https= ://tools.ietf.org/html/draft-ietf-core-yang-cbor-07#section-6.12

 

Currently, each YANG datatype in a union is encoded = differently to avoid any ambiguities between  them.

For example, integer 4 is encoded as:

 

04 # unsigned(4)

 

enumerator value 4 is encoded as (assuming the alloc= ated tag is 99):

 

D8 63 # tag(99)

   04 # unsigned(4)

 

The list of these encoding is shown below:

- unsigned integer --> CBOR unsigned integer=

- integer --> CBOR unsigned integer, CBOR negativ= e integer

- enumeration --> CBOR tag <TBD>=

- identityref as SID --> CBOR tag <TBD>

- string --> CBOR text string

- identityref as name --> CBOR tag <TBD>

- bits --> CBOR tag <TBD>

- binary --> CBOR byte string

- decimal64 --> CBOR tag 4

- boolean --> CBOR simple value

 

The only potential problem I aware is when multiple = enumerations are part of the same union.

Value 4 from enumeration A will be encoded the same = way as Value 4 from enumeration B.

 

Is it a real problem is real life?

If so, how this can be resolved?

 

I won't be present at the Prague meeting, but I'm ce= rtainly available to discuss this topic by email.

I will be present at the Montreal meeting for any re= maining discussions on this draft.

 

Note: I'm currently updating the draft to remove any= dependencies with RFC 7951, to resolve a comment sent by Andy.<= /p>

 

Regards

Michel

 

 

From: core <core-bounces@ietf.org> On Behalf Of Rob Wilton (rwilton)
Sent: Friday, March 22, 2019 8:43 AM
To: core@ietf.org; netconf@ietf.org
Subject: [core] YANG encoding in CBOR

 

Hi,

 

As part of YANG evolution discu= ssion, that was some talk about using a binary encoding of YANG in NETCONF = or RESTCONF.

 

CBOR looks like a good fit for = this, and obviously CORE WG are working on draft-ietf-core-yang-cbor-07, bu= t one comment came up from Andy that the CBOR encoding of YANG cannot handl= e all YANG data models.  In particular, because of the way that the encoding works there are limitations on how un= ions of enums work.  Is that still the case?

 

Hence I was wondering whether i= t would be better to encode enum values in CBOR using module-qualified name= s, or also assign them SIDs and use the SIDs.  Has this approach been = considered at all?

 

Or, is there an alternative app= roach to how we could/should consider using CBOR as a binary encoding for Y= ANG data in NETCONF or RESTCONF?

 

Do you think it would be possib= le to get interested parties together to discuss this at some point in Prag= ue?

 

Thanks,
Rob

 

--_000_DM6PR06MB50497E9F418DF2F9EEA2E5469A430DM6PR06MB5049namp_-- From nobody Fri Mar 22 15:28:12 2019 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 0D76512D4E8; Fri, 22 Mar 2019 15:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 0Ca-hAQAPwUw; Fri, 22 Mar 2019 15:28:07 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 ADD19124408; Fri, 22 Mar 2019 15:28:07 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id t21so2459049pfe.2; Fri, 22 Mar 2019 15:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gFRIngBuYgl9Ql4a9Gk1Ub0wHWwpq2eEtxVBgkZBfzo=; b=td/Ws7FeXnNZ+Eh3jv6d0h/hHrkdb5jkVjG4dmMp5m0mbK3+baHU5QiwOdqvxfpuoT oKnVhnpWG8i8OPFINHuq9I3coPYlgGfEu8QFIZi73/J1ePeWFFNPYTNlCITAEhA/uJIR Z34NEM7KYDeIzsSkLw1rtFtqQgkYY+gySImKn0ZWaAUTVKxMz4EDs3zeSUG9QGBEOnpV 2ea4clYtYxECgOsESBOUYnEBzNAuifFaWMKZkNURrVBqe/LLGa7jND6E5zYOQmlUTBT4 prezI1dxD14K1G/IUuICYGZ1mTe35e0lMHsfnajfVS7O3GexJQ2R78GqjznSikMfWGHS lJpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gFRIngBuYgl9Ql4a9Gk1Ub0wHWwpq2eEtxVBgkZBfzo=; b=f0sQpx6ZVTB9SW7YhMVEWkdDqIxsfYRqZV6DXWDPSbI8VlDSmvKMeXd+Z7rrZpoQrr eUnjpiI196rVIuqnznbE/2qdpuC7QUX5q28u2NtjM33wsRZNsBR9loSseUTsBKzC7nu9 t9ZEDqztSYDwx0iDg/lwIxzQL/SHYzAt3pQ3uFYOfd6FYywoHg6H6iZmmg0WYJdCRDff TCE4jQ8ZgFMWeuizRJRkgjzdnP9Ee0Fre5otCtigFrs/WkuJWMAkukdcRyxQr7IyDhMs NIe5QJSC8uyQt1/y9UwCMqBBHdkEf7UPKFFslf5niS9aAsggkZN207oW7YuvKz+wtW08 t1CA== X-Gm-Message-State: APjAAAWCIKfjNfZQRZLLUDf4ZkdB1cB61O1hW1BaILk2x1q4Ci/80RV0 uBNUN7hgEnFHqGeib3deFFiz7pbOWHg= X-Google-Smtp-Source: APXvYqx/yc4pEnVuw4avsn9xqk4wSuvrORQ/a4qwWB94quUlHzzFqJYkRRV4UxOUYrc8ABfOb1mvIw== X-Received: by 2002:a62:5797:: with SMTP id i23mr11584075pfj.12.1553293687029; Fri, 22 Mar 2019 15:28:07 -0700 (PDT) Received: from ?IPv6:2601:647:4700:1280:cd73:1288:edf2:de9f? ([2601:647:4700:1280:cd73:1288:edf2:de9f]) by smtp.gmail.com with ESMTPSA id d130sm19822253pfg.49.2019.03.22.15.28.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Mar 2019 15:28:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mahesh Jethanandani In-Reply-To: <0100016992df3dee-810edfad-751d-4cc9-92b5-76496bdb52bf-000000@email.amazonses.com> Date: Fri, 22 Mar 2019 15:28:05 -0700 Cc: NETCONF Chairs , Kent Watsen Content-Transfer-Encoding: 7bit Message-Id: <05816A54-5F0E-4755-8024-F6C03710C8F4@gmail.com> References: <0100016992df3dee-810edfad-751d-4cc9-92b5-76496bdb52bf-000000@email.amazonses.com> To: Netconf X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netconf] 104 Presenters: please send your slides 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, 22 Mar 2019 22:28:10 -0000 Just a reminder. Draft version of the slides are due today. > On Mar 18, 2019, at 3:14 PM, Kent Watsen wrote: > > > Dear NETCONF 104 Presenters, > > Please send your slides to the chairs alias (CC-ed) by this Friday. > > Thanks you! > Kent and Mahesh > > Mahesh Jethanandani mjethanandani@gmail.com From nobody Sat Mar 23 02:03:40 2019 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 0BBDD1279B2; Sat, 23 Mar 2019 02:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 w58uE-mG-bvx; Sat, 23 Mar 2019 02:03:36 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9776127985; Sat, 23 Mar 2019 02:03:35 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44RF1d3ZKszyvb; Sat, 23 Mar 2019 10:03:33 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> Date: Sat, 23 Mar 2019 10:03:32 +0100 Cc: "core@ietf.org" , "netconf@ietf.org" , "Rob Wilton (rwilton)" X-Mao-Original-Outgoing-Id: 575024610.781531-fa120bcd936fa8f445d28822f35fb82a Content-Transfer-Encoding: quoted-printable Message-Id: <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> To: Michel Veillette X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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: Sat, 23 Mar 2019 09:03:38 -0000 Well, if that is a problem, we can go for a longer representation within = unions (section 6.12). Theoretically, we could do that only of there is = more than one enum in the union type (so things stay efficient if there = is only one), but that might pose difficulties with model evolution. Going for a string representation repeats the feature of XML YANG (which = was ported over to JSON YANG): typedef foo { type union { type enumeration { enum red { value 1; } enum breen { value 2; } enum glue { value 3; } } type enumeration { enum tacks { value 1; } enum nails { value 2; } enum glue { value 3; } } } } If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of the = enumerations are being used. Using SIDs, we can do better. So what do we have to do to get the SID tool to allocate SIDs for enum = values? We could then define the CBOR tag for enums in unions to take the usual = SID difference (delta relative to the environment, I=E2=80=99d think), = not an integer value. Several of us are at the hackathon and could make something happen today = and tomorrow. Gr=C3=BC=C3=9Fe, Carsten > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) = wrote: >=20 > I guess that the concern is that this introduces more variation in how = data is interpreted between the different XML/JSON/CBOR encodings. >=20 > E.g. if someone switched from XML to CBOR, suddenly the configuration = or state data may have a different meaning. >=20 > Thanks, > Rob >=20 >=20 >> -----Original Message----- >> From: Carsten Bormann >> Sent: 22 March 2019 16:08 >> To: Michel Veillette >> Cc: Rob Wilton (rwilton) ; core@ietf.org; >> netconf@ietf.org >> Subject: Re: [netconf] YANG encoding in CBOR >>=20 >> On Mar 22, 2019, at 16:45, Michel Veillette = >> wrote: >>>=20 >>> The only potential problem I aware is when multiple enumerations are = part of >> the same union. >>> Value 4 from enumeration A will be encoded the same way as Value 4 = from >> enumeration B. >>=20 >> =E2=80=A6 and that is not a problem for the XML version, because the = string is being used >> instead of the value. (But then if two enumerations share a string, = you have the >> equivalent problem in the XML serialization.) >>=20 >> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that = actually has this >> problem, so I would be a bit reluctant to make CBOR-based = implementations >> more complex (and less efficient) so solve this (non-?)problem. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >=20 From nobody Sat Mar 23 03:10:19 2019 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 0F10D130E6D; Sat, 23 Mar 2019 03:10:11 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 0BoL83C6vWdl; Sat, 23 Mar 2019 03:10:07 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B1E1293B1; Sat, 23 Mar 2019 03:10:07 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id CE8866F4; Sat, 23 Mar 2019 11:10:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Q_4hyp3vGCha; Sat, 23 Mar 2019 11:10:05 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Sat, 23 Mar 2019 11:10:05 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8EF04200A6; Sat, 23 Mar 2019 11:10:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id YRAKQ_jvn_vC; Sat, 23 Mar 2019 11:10:05 +0100 (CET) Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 06C30200A5; Sat, 23 Mar 2019 11:10:05 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Sat, 23 Mar 2019 11:10:04 +0100 Received: by anna.localdomain (Postfix, from userid 501) id D700A30077A954; Sat, 23 Mar 2019 11:10:03 +0100 (CET) Date: Sat, 23 Mar 2019 11:10:03 +0100 From: Juergen Schoenwaelder To: Carsten Bormann CC: Michel Veillette , "netconf@ietf.org" , "core@ietf.org" Message-ID: <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Carsten Bormann , Michel Veillette , "netconf@ietf.org" , "core@ietf.org" References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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: Sat, 23 Mar 2019 10:10:11 -0000 I think we need to look at the whole picture and in which direction we want to go. In the longer term, I would prefer a solution where the values of a union are discriminated. The current XML encoding behaviour of 'first match wins' is fragile (for example, if someone adds an enum to a type, the interpretation of data can change). Look at this: typedef bar { type union { type enumeration { enum "1"; value 2; enum "2"; value 1; } type uint8; } } We have some encodings that send the string representations of the values and some encodings that prefer to send numeric representations where possible. In order to have a robust solution, encodings should likely indicate to which type the value belongs. /js On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > Well, if that is a problem, we can go for a longer representation withi= n unions (section 6.12). Theoretically, we could do that only of there i= s more than one enum in the union type (so things stay efficient if there= is only one), but that might pose difficulties with model evolution. >=20 > Going for a string representation repeats the feature of XML YANG (whic= h was ported over to JSON YANG): >=20 > typedef foo { > type union { > type enumeration { > enum red { value 1; } > enum breen { value 2; } > enum glue { value 3; } > } > type enumeration { > enum tacks { value 1; } > enum nails { value 2; } > enum glue { value 3; } > } > } > } >=20 > If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of the = enumerations are being used. >=20 > Using SIDs, we can do better. >=20 > So what do we have to do to get the SID tool to allocate SIDs for enum = values? >=20 > We could then define the CBOR tag for enums in unions to take the usual= SID difference (delta relative to the environment, I=E2=80=99d think), n= ot an integer value. >=20 > Several of us are at the hackathon and could make something happen toda= y and tomorrow. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) w= rote: > >=20 > > I guess that the concern is that this introduces more variation in ho= w data is interpreted between the different XML/JSON/CBOR encodings. > >=20 > > E.g. if someone switched from XML to CBOR, suddenly the configuration= or state data may have a different meaning. > >=20 > > Thanks, > > Rob > >=20 > >=20 > >> -----Original Message----- > >> From: Carsten Bormann > >> Sent: 22 March 2019 16:08 > >> To: Michel Veillette > >> Cc: Rob Wilton (rwilton) ; core@ietf.org; > >> netconf@ietf.org > >> Subject: Re: [netconf] YANG encoding in CBOR > >>=20 > >> On Mar 22, 2019, at 16:45, Michel Veillette > >> wrote: > >>>=20 > >>> The only potential problem I aware is when multiple enumerations ar= e part of > >> the same union. > >>> Value 4 from enumeration A will be encoded the same way as Value 4 = from > >> enumeration B. > >>=20 > >> =E2=80=A6 and that is not a problem for the XML version, because the= string is being used > >> instead of the value. (But then if two enumerations share a string,= you have the > >> equivalent problem in the XML serialization.) > >>=20 > >> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that actua= lly has this > >> problem, so I would be a bit reluctant to make CBOR-based implementa= tions > >> more complex (and less efficient) so solve this (non-?)problem. > >>=20 > >> Gr=C3=BC=C3=9Fe, Carsten > >=20 > >=20 > >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > Well, if that is a problem, we can go for a longer representation withi= n unions (section 6.12). Theoretically, we could do that only of there i= s more than one enum in the union type (so things stay efficient if there= is only one), but that might pose difficulties with model evolution. >=20 > Going for a string representation repeats the feature of XML YANG (whic= h was ported over to JSON YANG): >=20 > typedef foo { > type union { > type enumeration { > enum red { value 1; } > enum breen { value 2; } > enum glue { value 3; } > } > type enumeration { > enum tacks { value 1; } > enum nails { value 2; } > enum glue { value 3; } > } > } > } >=20 > If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of the = enumerations are being used. >=20 > Using SIDs, we can do better. >=20 > So what do we have to do to get the SID tool to allocate SIDs for enum = values? >=20 > We could then define the CBOR tag for enums in unions to take the usual= SID difference (delta relative to the environment, I=E2=80=99d think), n= ot an integer value. >=20 > Several of us are at the hackathon and could make something happen toda= y and tomorrow. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) w= rote: > >=20 > > I guess that the concern is that this introduces more variation in ho= w data is interpreted between the different XML/JSON/CBOR encodings. > >=20 > > E.g. if someone switched from XML to CBOR, suddenly the configuration= or state data may have a different meaning. > >=20 > > Thanks, > > Rob > >=20 > >=20 > >> -----Original Message----- > >> From: Carsten Bormann > >> Sent: 22 March 2019 16:08 > >> To: Michel Veillette > >> Cc: Rob Wilton (rwilton) ; core@ietf.org; > >> netconf@ietf.org > >> Subject: Re: [netconf] YANG encoding in CBOR > >>=20 > >> On Mar 22, 2019, at 16:45, Michel Veillette > >> wrote: > >>>=20 > >>> The only potential problem I aware is when multiple enumerations ar= e part of > >> the same union. > >>> Value 4 from enumeration A will be encoded the same way as Value 4 = from > >> enumeration B. > >>=20 > >> =E2=80=A6 and that is not a problem for the XML version, because the= string is being used > >> instead of the value. (But then if two enumerations share a string,= you have the > >> equivalent problem in the XML serialization.) > >>=20 > >> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that actua= lly has this > >> problem, so I would be a bit reluctant to make CBOR-based implementa= tions > >> more complex (and less efficient) so solve this (non-?)problem. > >>=20 > >> Gr=C3=BC=C3=9Fe, Carsten > >=20 > >=20 > >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sat Mar 23 03:27:19 2019 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 6295612D84C; Sat, 23 Mar 2019 03:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 QiGe99i_Qcwl; Sat, 23 Mar 2019 03:27:11 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA2E612D4F2; Sat, 23 Mar 2019 03:27:10 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44RGt44Q06zyw5; Sat, 23 Mar 2019 11:27:08 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> Date: Sat, 23 Mar 2019 11:27:08 +0100 Cc: Michel Veillette , "netconf@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 575029626.264401-255d07e5b71704ba7c6158fb07a891bf Content-Transfer-Encoding: quoted-printable Message-Id: <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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: Sat, 23 Mar 2019 10:27:14 -0000 On Mar 23, 2019, at 11:10, Juergen Schoenwaelder = wrote: >=20 > I think we need to look at the whole picture and in which direction we > want to go. In the longer term, I would prefer a solution where the > values of a union are discriminated. The current XML encoding > behaviour of =E2=80=98first match wins' Can you point to chapter and verse? > is fragile (for example, if someone > adds an enum to a type, the interpretation of data can change). >=20 > Look at this: >=20 > typedef bar { > type union { > type enumeration { enum "1"; value 2; enum "2"; value 1; } > type uint8; > } > } >=20 > We have some encodings that send the string representations of the > values and some encodings that prefer to send numeric representations > where possible. In order to have a robust solution, encodings should > likely indicate to which type the value belongs. In a serialization that has more type information (such as yang-cbor), = you can reliably distinguish any usage of the uint8 from the usage of = the enumerations. We put in the CBOR tags to enable that even though = enumeration values are normally represented by their =E2=80=9Cvalue=E2=80=9D= field. The part that I don=E2=80=99t understand is what is the plan with = handling conflicts between the enumerations. I=E2=80=99m not sure what = the equivalence model is, here =E2=80=94 do YANG enums employ structural = equivalence? There is no name up there, so it can=E2=80=99t really be = name equivalence, unless there is an implicit name being inferred from = the schema tree. Gr=C3=BC=C3=9Fe, Carsten >=20 > /js >=20 > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: >> Well, if that is a problem, we can go for a longer representation = within unions (section 6.12). Theoretically, we could do that only of = there is more than one enum in the union type (so things stay efficient = if there is only one), but that might pose difficulties with model = evolution. >>=20 >> Going for a string representation repeats the feature of XML YANG = (which was ported over to JSON YANG): >>=20 >> typedef foo { >> type union { >> type enumeration { >> enum red { value 1; } >> enum breen { value 2; } >> enum glue { value 3; } >> } >> type enumeration { >> enum tacks { value 1; } >> enum nails { value 2; } >> enum glue { value 3; } >> } >> } >> } >>=20 >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of = the enumerations are being used. >>=20 >> Using SIDs, we can do better. >>=20 >> So what do we have to do to get the SID tool to allocate SIDs for = enum values? >>=20 >> We could then define the CBOR tag for enums in unions to take the = usual SID difference (delta relative to the environment, I=E2=80=99d = think), not an integer value. >>=20 >> Several of us are at the hackathon and could make something happen = today and tomorrow. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >>> On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) = wrote: >>>=20 >>> I guess that the concern is that this introduces more variation in = how data is interpreted between the different XML/JSON/CBOR encodings. >>>=20 >>> E.g. if someone switched from XML to CBOR, suddenly the = configuration or state data may have a different meaning. >>>=20 >>> Thanks, >>> Rob >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Carsten Bormann >>>> Sent: 22 March 2019 16:08 >>>> To: Michel Veillette >>>> Cc: Rob Wilton (rwilton) ; core@ietf.org; >>>> netconf@ietf.org >>>> Subject: Re: [netconf] YANG encoding in CBOR >>>>=20 >>>> On Mar 22, 2019, at 16:45, Michel Veillette = >>>> wrote: >>>>>=20 >>>>> The only potential problem I aware is when multiple enumerations = are part of >>>> the same union. >>>>> Value 4 from enumeration A will be encoded the same way as Value 4 = from >>>> enumeration B. >>>>=20 >>>> =E2=80=A6 and that is not a problem for the XML version, because = the string is being used >>>> instead of the value. (But then if two enumerations share a = string, you have the >>>> equivalent problem in the XML serialization.) >>>>=20 >>>> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that = actually has this >>>> problem, so I would be a bit reluctant to make CBOR-based = implementations >>>> more complex (and less efficient) so solve this (non-?)problem. >>>>=20 >>>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 >=20 > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: >> Well, if that is a problem, we can go for a longer representation = within unions (section 6.12). Theoretically, we could do that only of = there is more than one enum in the union type (so things stay efficient = if there is only one), but that might pose difficulties with model = evolution. >>=20 >> Going for a string representation repeats the feature of XML YANG = (which was ported over to JSON YANG): >>=20 >> typedef foo { >> type union { >> type enumeration { >> enum red { value 1; } >> enum breen { value 2; } >> enum glue { value 3; } >> } >> type enumeration { >> enum tacks { value 1; } >> enum nails { value 2; } >> enum glue { value 3; } >> } >> } >> } >>=20 >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of = the enumerations are being used. >>=20 >> Using SIDs, we can do better. >>=20 >> So what do we have to do to get the SID tool to allocate SIDs for = enum values? >>=20 >> We could then define the CBOR tag for enums in unions to take the = usual SID difference (delta relative to the environment, I=E2=80=99d = think), not an integer value. >>=20 >> Several of us are at the hackathon and could make something happen = today and tomorrow. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >>> On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) = wrote: >>>=20 >>> I guess that the concern is that this introduces more variation in = how data is interpreted between the different XML/JSON/CBOR encodings. >>>=20 >>> E.g. if someone switched from XML to CBOR, suddenly the = configuration or state data may have a different meaning. >>>=20 >>> Thanks, >>> Rob >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Carsten Bormann >>>> Sent: 22 March 2019 16:08 >>>> To: Michel Veillette >>>> Cc: Rob Wilton (rwilton) ; core@ietf.org; >>>> netconf@ietf.org >>>> Subject: Re: [netconf] YANG encoding in CBOR >>>>=20 >>>> On Mar 22, 2019, at 16:45, Michel Veillette = >>>> wrote: >>>>>=20 >>>>> The only potential problem I aware is when multiple enumerations = are part of >>>> the same union. >>>>> Value 4 from enumeration A will be encoded the same way as Value 4 = from >>>> enumeration B. >>>>=20 >>>> =E2=80=A6 and that is not a problem for the XML version, because = the string is being used >>>> instead of the value. (But then if two enumerations share a = string, you have the >>>> equivalent problem in the XML serialization.) >>>>=20 >>>> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that = actually has this >>>> problem, so I would be a bit reluctant to make CBOR-based = implementations >>>> more complex (and less efficient) so solve this (non-?)problem. >>>>=20 >>>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 >=20 From nobody Sat Mar 23 06:35:27 2019 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 5971012795E; Sat, 23 Mar 2019 06:35:26 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 jvr6EQVbYalG; Sat, 23 Mar 2019 06:35:23 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D18E9128664; Sat, 23 Mar 2019 06:35:22 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 4B0278B2; Sat, 23 Mar 2019 14:35:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 9Fk1rxaIeq-w; Sat, 23 Mar 2019 14:35:21 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Sat, 23 Mar 2019 14:35:21 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E213200A6; Sat, 23 Mar 2019 14:35:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id MsqfPOtV-UwO; Sat, 23 Mar 2019 14:35:20 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 5F566200A5; Sat, 23 Mar 2019 14:35:20 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Sat, 23 Mar 2019 14:35:19 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 6C88530077AB2F; Sat, 23 Mar 2019 14:35:19 +0100 (CET) Date: Sat, 23 Mar 2019 14:35:19 +0100 From: Juergen Schoenwaelder To: Carsten Bormann CC: Michel Veillette , "netconf@ietf.org" , "core@ietf.org" Message-ID: <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Carsten Bormann , Michel Veillette , "netconf@ietf.org" , "core@ietf.org" References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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: Sat, 23 Mar 2019 13:35:26 -0000 On Sat, Mar 23, 2019 at 11:27:08AM +0100, Carsten Bormann wrote: > On Mar 23, 2019, at 11:10, Juergen Schoenwaelder wrote: > >=20 > > I think we need to look at the whole picture and in which direction w= e > > want to go. In the longer term, I would prefer a solution where the > > values of a union are discriminated. The current XML encoding > > behaviour of =E2=80=98first match wins' >=20 > Can you point to chapter and verse? RFC 7950 section 9.12: When generating an XML encoding, a value is encoded according to the rules of the member type to which the value belongs. When interpreting an XML encoding, a value is validated consecutively against each member type, in the order they are specified in the "type" statement, until a match is found. The type that matched will be the type of the value for the node that was validated, and the encoding is interpreted according to the rules for that type. =20 > > is fragile (for example, if someone > > adds an enum to a type, the interpretation of data can change). > >=20 > > Look at this: > >=20 > > typedef bar { > > type union { > > type enumeration { enum "1"; value 2; enum "2"; value 1; } > > type uint8; > > } > > } > >=20 > > We have some encodings that send the string representations of the > > values and some encodings that prefer to send numeric representations > > where possible. In order to have a robust solution, encodings should > > likely indicate to which type the value belongs. >=20 > In a serialization that has more type information (such as yang-cbor), = you can reliably distinguish any usage of the uint8 from the usage of the= enumerations. We put in the CBOR tags to enable that even though enumer= ation values are normally represented by their =E2=80=9Cvalue=E2=80=9D fi= eld. The JSON encoding (RFC 7951 section 6.10) also can distinguish between the enum and the uint8 but it can't distinguish between other types that all map to a JSON string. Can the CBOR encoding distinguish between two uint8 values (or two string values) in a union? typedef temperature { type union { type fahrenheit; // an int16 type celsius; // an int16 } } > The part that I don=E2=80=99t understand is what is the plan with handl= ing conflicts between the enumerations. Depends on what you consider a conflict. My problem is that I see three encodings that all appear to do something slightly different and the problem seems to be that YANG kind of defers the interpretation of unions to encodings. Things would be robust if even the above case would be unambiguous in all encodings, i.e., the union would be a discriminated or tagged union. /js > I=E2=80=99m not sure what the equivalence model is, here =E2=80=94 do Y= ANG enums employ structural equivalence? There is no name up there, so i= t can=E2=80=99t really be name equivalence, unless there is an implicit n= ame being inferred from the schema tree. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >=20 >=20 > >=20 > > /js > >=20 > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > >> Well, if that is a problem, we can go for a longer representation wi= thin unions (section 6.12). Theoretically, we could do that only of ther= e is more than one enum in the union type (so things stay efficient if th= ere is only one), but that might pose difficulties with model evolution. > >>=20 > >> Going for a string representation repeats the feature of XML YANG (w= hich was ported over to JSON YANG): > >>=20 > >> typedef foo { > >> type union { > >> type enumeration { > >> enum red { value 1; } > >> enum breen { value 2; } > >> enum glue { value 3; } > >> } > >> type enumeration { > >> enum tacks { value 1; } > >> enum nails { value 2; } > >> enum glue { value 3; } > >> } > >> } > >> } > >>=20 > >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of t= he enumerations are being used. > >>=20 > >> Using SIDs, we can do better. > >>=20 > >> So what do we have to do to get the SID tool to allocate SIDs for en= um values? > >>=20 > >> We could then define the CBOR tag for enums in unions to take the us= ual SID difference (delta relative to the environment, I=E2=80=99d think)= , not an integer value. > >>=20 > >> Several of us are at the hackathon and could make something happen t= oday and tomorrow. > >>=20 > >> Gr=C3=BC=C3=9Fe, Carsten > >>=20 > >>=20 > >>> On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) = wrote: > >>>=20 > >>> I guess that the concern is that this introduces more variation in = how data is interpreted between the different XML/JSON/CBOR encodings. > >>>=20 > >>> E.g. if someone switched from XML to CBOR, suddenly the configurati= on or state data may have a different meaning. > >>>=20 > >>> Thanks, > >>> Rob > >>>=20 > >>>=20 > >>>> -----Original Message----- > >>>> From: Carsten Bormann > >>>> Sent: 22 March 2019 16:08 > >>>> To: Michel Veillette > >>>> Cc: Rob Wilton (rwilton) ; core@ietf.org; > >>>> netconf@ietf.org > >>>> Subject: Re: [netconf] YANG encoding in CBOR > >>>>=20 > >>>> On Mar 22, 2019, at 16:45, Michel Veillette > >>>> wrote: > >>>>>=20 > >>>>> The only potential problem I aware is when multiple enumerations = are part of > >>>> the same union. > >>>>> Value 4 from enumeration A will be encoded the same way as Value = 4 from > >>>> enumeration B. > >>>>=20 > >>>> =E2=80=A6 and that is not a problem for the XML version, because t= he string is being used > >>>> instead of the value. (But then if two enumerations share a strin= g, you have the > >>>> equivalent problem in the XML serialization.) > >>>>=20 > >>>> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that act= ually has this > >>>> problem, so I would be a bit reluctant to make CBOR-based implemen= tations > >>>> more complex (and less efficient) so solve this (non-?)problem. > >>>>=20 > >>>> Gr=C3=BC=C3=9Fe, Carsten > >>>=20 > >>>=20 > >>>=20 > >>=20 > >> _______________________________________________ > >> netconf mailing list > >> netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > >=20 > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > Fax: +49 421 200 3103 > >=20 > >=20 > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > >> Well, if that is a problem, we can go for a longer representation wi= thin unions (section 6.12). Theoretically, we could do that only of ther= e is more than one enum in the union type (so things stay efficient if th= ere is only one), but that might pose difficulties with model evolution. > >>=20 > >> Going for a string representation repeats the feature of XML YANG (w= hich was ported over to JSON YANG): > >>=20 > >> typedef foo { > >> type union { > >> type enumeration { > >> enum red { value 1; } > >> enum breen { value 2; } > >> enum glue { value 3; } > >> } > >> type enumeration { > >> enum tacks { value 1; } > >> enum nails { value 2; } > >> enum glue { value 3; } > >> } > >> } > >> } > >>=20 > >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of t= he enumerations are being used. > >>=20 > >> Using SIDs, we can do better. > >>=20 > >> So what do we have to do to get the SID tool to allocate SIDs for en= um values? > >>=20 > >> We could then define the CBOR tag for enums in unions to take the us= ual SID difference (delta relative to the environment, I=E2=80=99d think)= , not an integer value. > >>=20 > >> Several of us are at the hackathon and could make something happen t= oday and tomorrow. > >>=20 > >> Gr=C3=BC=C3=9Fe, Carsten > >>=20 > >>=20 > >>> On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) = wrote: > >>>=20 > >>> I guess that the concern is that this introduces more variation in = how data is interpreted between the different XML/JSON/CBOR encodings. > >>>=20 > >>> E.g. if someone switched from XML to CBOR, suddenly the configurati= on or state data may have a different meaning. > >>>=20 > >>> Thanks, > >>> Rob > >>>=20 > >>>=20 > >>>> -----Original Message----- > >>>> From: Carsten Bormann > >>>> Sent: 22 March 2019 16:08 > >>>> To: Michel Veillette > >>>> Cc: Rob Wilton (rwilton) ; core@ietf.org; > >>>> netconf@ietf.org > >>>> Subject: Re: [netconf] YANG encoding in CBOR > >>>>=20 > >>>> On Mar 22, 2019, at 16:45, Michel Veillette > >>>> wrote: > >>>>>=20 > >>>>> The only potential problem I aware is when multiple enumerations = are part of > >>>> the same union. > >>>>> Value 4 from enumeration A will be encoded the same way as Value = 4 from > >>>> enumeration B. > >>>>=20 > >>>> =E2=80=A6 and that is not a problem for the XML version, because t= he string is being used > >>>> instead of the value. (But then if two enumerations share a strin= g, you have the > >>>> equivalent problem in the XML serialization.) > >>>>=20 > >>>> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that act= ually has this > >>>> problem, so I would be a bit reluctant to make CBOR-based implemen= tations > >>>> more complex (and less efficient) so solve this (non-?)problem. > >>>>=20 > >>>> Gr=C3=BC=C3=9Fe, Carsten > >>>=20 > >>>=20 > >>>=20 > >>=20 > >> _______________________________________________ > >> netconf mailing list > >> netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > >=20 > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > Fax: +49 421 200 3103 > >=20 > >=20 >=20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sat Mar 23 11:35:26 2019 Return-Path: <01000169abd5f928-cf7dab92-f351-4eb7-a9b4-90d1ee7477d3-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 28660128766 for ; Sat, 23 Mar 2019 11:35:24 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 Ghw9VK0CzwTS for ; Sat, 23 Mar 2019 11:35:22 -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 31AB1128D0B for ; Sat, 23 Mar 2019 11:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553366120; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=Yfg3XBjlRsBQxEFsgehdoa8kD9F747lA3GiTwulQjnQ=; b=lrEWIw+lcFASiwVEqA96mdW52kpQ4ZsRJzQEEW1XZgeZAmAY9DO5tmQ0i5Gy6uR8 1z9+L46+VspFeV9IPFrUhrg3xN2FEc9ag76D5eCvCaksQPuCxLayTEAhiV/sv8p8Rrq bVvbRN+9OrVEbRgYYL4fZcZtbAkwXVc5dNhEOMwQ= Content-Type: multipart/alternative; boundary=Apple-Mail-6BD8924F-2179-4095-A066-AD9FBCC85CF3 Mime-Version: 1.0 (1.0) From: Kent Watsen X-Mailer: iPad Mail (16D57) In-Reply-To: Date: Sat, 23 Mar 2019 18:35:20 +0000 Cc: "netconf@ietf.org" Content-Transfer-Encoding: 7bit Message-ID: <01000169abd5f928-cf7dab92-f351-4eb7-a9b4-90d1ee7477d3-000000@email.amazonses.com> References: <01000169a0becf2a-5f004be0-a74d-4f9b-b456-f8c3309fac94-000000@email.amazonses.com> To: =?utf-8?Q?Bal=C3=A1zs_Kov=C3=A1cs?= X-SES-Outgoing: 2019.03.23-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] why did we breakout the groupings? 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: Sat, 23 Mar 2019 18:35:24 -0000 --Apple-Mail-6BD8924F-2179-4095-A066-AD9FBCC85CF3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Balazs, Thank you for including the thread from before. I lost my old inbox and had= n=E2=80=99t gotten around to searching the archives. Upon re-reading the thread, I see again that the intent was to support inter= active SSH clients with partial configuration. That is, you wished to persi= st some aspects while allowing other aspects be bound more dynamically. This being the case, I=E2=80=99m wondering if an alternate solution may have= been to persist dummy values to be replaced by variable substitution (e.g. r= emote-address =3D =E2=80=9CREMOTE-ADDRESS=E2=80=9D, username =3D =E2=80=9CUS= ERNAME=E2=80=9D, etc.)? Being interactive, the code is not autonomously ru= nning in the background and thus can be instrumented to inject user-specifie= d values. Thoughts? Since =E2=80=9Cport=E2=80=9D is a number, the value =E2= =80=9CPORT=E2=80=9D cannot be persisted, but maybe MAX port value could be r= eserved for this purpose, or an =E2=80=9Coverlay=E2=80=9D schema could be us= ed to provide an alternate hook? You=E2=80=99re correct that the breakouts seem to do no harm, but I learned a= long time back that groupings SHOULD NOT be made indiscriminately. Given t= hat you say that you=E2=80=99re no longer using these breakout groupings, an= d the previous paragraph suggests workarounds are possible (agreed?), I beli= eve we should revert to the previous approach with no breakout groupings, if= there are no objections, of course (do you?). PS: there is a bullet point in my presentation on this; I plan to refer to t= his thread and ask again if there are any objections. Kent // contributor > On Mar 22, 2019, at 2:01 PM, Bal=C3=A1zs Kov=C3=A1cs wrote: >=20 > Hi Kent, > =20 > We had the attached conversation. > =20 > Since we had this change, I admit I refrained from using the client-identi= ty-grouping separately from an endpoint configuration (see attached mail). A= llowing the option for interactive selection of client identity did not seem= to be that good idea after all. I cannot say now I have any intention to us= e them separately in the close future. > =20 > =46rom your feedback I so far understood that these sub-grouping do not ha= rm much since the client-server models can use the original grouping, such a= s the =E2=80=98ssh-client-grouping=E2=80=99. > =20 > All in all, I think I do not mind if you collapse this back into a single g= rouping if there is no other need to keep them separate. > =20 > Br, > Balazs > =20 > =20 > =20 > From: Kent Watsen =20 > Sent: Thursday, March 21, 2019 3:54 PM > To: Bal=C3=A1zs Kov=C3=A1cs > Cc: netconf@ietf.org > Subject: why did we breakout the groupings? > =20 > Hi Balazs, > =20 > I'm in the middle of answering your other question when I was reminded tha= t I've been meaning to follow up with you on this issue... > =20 > Can you please help me recall why several months back we made the decision= to redefine the ietf-ssh-[client/server]-grouping statements to use other g= roupings? For instance, here's the current definition: > =20 > grouping ssh-client-grouping { > uses client-identity-grouping; > uses server-auth-grouping; > uses transport-params-grouping; > uses keepalives-grouping; > } > =20 > Obviously it was because you (I think it was you) wanted to be able to "us= e" the inner grouping in another context, but why? > =20 > I ask because this strategy is percolating into all of the client/server m= odels and it seems weird, if not wrong. I currently have it as an "open iss= ue" in my presentation for Monday, but I'd rather resolve it offline/now if p= ossible. > =20 > Kent // contributor > =20 > =20 > =20 > --Apple-Mail-6BD8924F-2179-4095-A066-AD9FBCC85CF3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Balazs,

Thank you for including the thread from before.  = I lost my old inbox and hadn=E2=80=99t gotten around to searching the archiv= es.

Upon re-reading the thread, I see again that the intent was to suppor= t interactive SSH clients with partial configuration.  That is, you wis= hed to persist some aspects while allowing other aspects be bound more dynam= ically.

This being the case, I=E2=80=99m wondering if an alternate soluti= on may have been to persist dummy values to be replaced by variable substitu= tion (e.g. remote-address =3D =E2=80=9CREMOTE-ADDRESS=E2=80=9D, username =3D= =E2=80=9CUSERNAME=E2=80=9D, etc.)?   Being interactive, the code is no= t autonomously running in the background and thus can be instrumented to inj= ect user-specified values.  Thoughts?    Since =E2=80=9Cport=E2= =80=9D is a number, the value =E2=80=9CPORT=E2=80=9D cannot be persisted, bu= t maybe MAX port value could be reserved for this purpose, or an =E2=80=9Cov= erlay=E2=80=9D schema could be used to provide an alternate hook?

=
You=E2=80= =99re correct that the breakouts seem to do no harm, but I learned a long ti= me back that groupings SHOULD NOT be made indiscriminately.   Given tha= t you say that you=E2=80=99re no longer using these breakout groupings, and t= he previous paragraph suggests workarounds are possible (agreed?), I believe= we should revert to the previous approach with no breakout groupings, if there are no o= bjections, of course (do you?).

PS: there is a bullet point in my presentation on this; I plan to= refer to this thread and ask again if there are any objections.

Kent // contributor


On Mar 22, 2019, at 2:01 PM, Bal=C3=A1zs K= ov=C3=A1cs <balazs.kovacs@e= ricsson.com> wrote:

Hi Kent,

 

We had the attached conversation.

 

Since we had this change, I admit I refrained from us= ing the client-identity-grouping separately from an endpoint configuration (= see attached mail). Allowing the option for interactive selection of client i= dentity did not seem to be that good idea after all. I cannot say now I have any intention to use them sepa= rately in the close future.

 

=46rom your feedback I so far understood that these s= ub-grouping do not harm much since the client-server models can use the orig= inal grouping, such as the =E2=80=98ssh-client-grouping=E2=80=99.

 

All in all, I think I do not mind if you collapse thi= s back into a single grouping if there is no other need to keep them separat= e.

 

Br,

Balazs

 

 

 

From: Kent Watsen <kent+ietf@watsen.net>
Sent: Thursday, March 21, 2019 3:54 PM
To: Bal=C3=A1zs Kov=C3=A1cs <balazs.kovacs@ericsson.com>
Cc: netconf@ietf.org
Subject: why did we breakout the groupings?

 

Hi Balazs,

 

I'm in the middle of answering your other question wh= en I was reminded that I've been meaning to follow up with you on this issue= ...

 

Can you please help me recall why several months back= we made the decision to redefine the ietf-ssh-[client/server]-grouping stat= ements to use other groupings?  For instance, here's the current defini= tion:

 

    grouping ssh-client-grouping&= nbsp;{
       uses client-identity-grouping;
       uses server-auth-grouping;
       uses transport-params-grouping;
       uses keepalives-grouping;
     }

 

Obviously it was because you (I think it was you) wan= ted to be able to "use" the inner grouping in another context, but why?=

 

I ask because this strategy is percolating into all o= f the client/server models and it seems weird, if not wrong.  I current= ly have it as an "open issue" in my presentation for Monday, but I'd rather r= esolve it offline/now if possible.

 

Kent // contributor

 

 

 

<mime-attac= hment>
= --Apple-Mail-6BD8924F-2179-4095-A066-AD9FBCC85CF3-- From nobody Sat Mar 23 12:23:34 2019 Return-Path: <01000169ac01ff08-27f75526-1e78-461a-be8e-9737cf762edf-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 ADAD7130ED8 for ; Sat, 23 Mar 2019 12:23:30 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 odBdVgTKDjAN for ; Sat, 23 Mar 2019 12:23:28 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D29F1277D9 for ; Sat, 23 Mar 2019 12:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553369005; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=V2O1K8vMv1YCsgecysS7nIyL23EFN3CKM6Gu+gqh7rg=; b=ALvL8tF1KwvklmqbYDJyBjbidI524NxgxMbFx60HHm0Ot1I2f4i0FXAVxQwXIFDQ ZhIvM2ufvuUtDqghzDk4e1OWP9Qpj+A+/P4nd7ZNy7n0F16SuasIszEFhxkZ1k3Xq0Q 99YsLP0BSCY9TsrBJswbgst3RsWypMZlFt/Zi7NY= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Kent Watsen X-Mailer: iPad Mail (16D57) In-Reply-To: <00b701d4e0cb$e79e9660$4001a8c0@gateway.2wire.net> Date: Sat, 23 Mar 2019 19:23:25 +0000 Cc: =?utf-8?Q?Bal=C3=A1zs_Kov=C3=A1cs?= , Juergen Schoenwaelder , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000169ac01ff08-27f75526-1e78-461a-be8e-9737cf762edf-000000@email.amazonses.com> References: <20190321152920.jdkny7szk7ik3sp4@anna.jacobs.jacobs-university.de> <00b701d4e0cb$e79e9660$4001a8c0@gateway.2wire.net> To: tom petch X-SES-Outgoing: 2019.03.23-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden 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: Sat, 23 Mar 2019 19:23:33 -0000 [top-posting for convenience] At first we had an RPC to create a key-pair (protected or not) so as to supp= ort the best practice of the private key never leaving a device. But backup= /restore became an issue, and Martin made a persuasive argument that the pri= vate key SHOULD be configuration (not operational state). Thusly, we relega= ted the RPC (now called =E2=80=9Cgenerate-hidden-key=E2=80=9D) to the specia= l case where the system generates a key that is operational-state and inacce= ssible (at least, not in its raw form; it may be accessible in a shrouded fo= rm) and, for all other cases, the client MUST configure the key pair (transm= itted over the wire, not best practice, oh well). Currently there are only these two options, based on the accessibility of th= e private key. Is the request to introduce a third option, but isn=E2=80=99t= the intent better supported by access-control? [the =E2=80=9Cprivate-key=E2= =80=9D leaf is nacm:default-deny-all].=20 Renaming =E2=80=9Chidden=E2=80=9D to =E2=80=9Cinaccessible=E2=80=9D seems ok= ay albeit, in both cases, it=E2=80=99s the unspecified subject (client vs sy= stem) that matters (i.e., hidden/inaccessible to whom?). =20 Kent // contributor Sent from my iPad > On Mar 22, 2019, at 5:28 PM, tom petch wrote: >=20 > ----- Original Message ----- > From: "Bal=C3=A1zs Kov=C3=A1cs" > Sent: Friday, March 22, 2019 12:44 PM >=20 > Hi, >=20 > I would really prefer the definition for 'hidden' as 'not accessible via > YANG protocols'. The explanation is that regardless of what method I use > to create/store the private keys, I still might not want the operator to > generate keys outside of the device or configure binary secret strings. >=20 > >=20 > I think that the meaning of the term 'hidden' varies depending on which > part of the I-D you are reading. The term is absent from the referenced > RFC, 8017 and 5915, which is probably not a coincidence. Rather, the > terminology of the literature is of a key pair, made up of a public and > private key so the action > generate-hidden-key { > probably means generate-key-pair; but, in other places, the word > 'hidden' clearly has different semantics and would probably best be > replaced by something else, such as inaccessible. >=20 > Tom Petch >=20 > I considered TPM protection for hidden keys is an option or example so > far, which adds limitations or additional complexity for moving keys, > but should not be the only option for hidden keys. The descriptions > mention TPM as example, then the rest of the text should align also to > keep that as example. >=20 > Br, > Balazs >=20 > -----Original Message----- > From: Juergen Schoenwaelder > Sent: Thursday, March 21, 2019 4:29 PM > To: Bal=C3=A1zs Kov=C3=A1cs > Cc: netconf@ietf.org; Kent Watsen > Subject: Re: [netconf] ietf crypto types - permanently hidden >=20 > I agree, I do not understand the second sentence either. My problem is > that I do not know what a 'real' private key is, are hidden keys > somewhat unreal? Or is "not hidden" =3D "real"? >=20 > The last sentence can probably be fixed; I think the intention was to > say that you can't backup and restore hidden keys by retrieving > configuration and restoring the configuration. >=20 > In general, I think we need a definition what a hidden key is. Is > something not exposed via a YANG interface a hidden key (but it may be a > regular key when using other device access methods)? Or do we require > that a hidden key is generally protected? I assume some people want to > have flexibility here but from the viewpoint of a security administrator > it matters a lot whether 'hidden' means 'generally not accessible' or > only 'not accessible via YANG protocols'. >=20 > The description of install-hidden-key seems to indicate a key is already > 'hidden' if it only exists in . Is this really a 'hidden' > key or more an 'ephemeral' key? >=20 > /js >=20 >> On Thu, Mar 21, 2019 at 02:23:27PM +0000, Bal=C3=A1zs Kov=C3=A1cs wrote: >> Hi, >>=20 >> The 'generate-hidden-key' action is meant for cases when the key must > be generated in the device and not the operator is configuring it. The > 'generate-hidden-key' is said to produce a 'permanently-hidden' > asymmetric key. The description of 'permanently-hidden' is as follows: >>=20 >> "The private key is inaccessible due to being >> protected by the system (e.g., a cryptographic >> hardware module). It is not possible to >> configure a permanently hidden key, as a real >> private key value must be set. Permanently >> hidden keys cannot be archived or backed up."; >>=20 >> Th second sentence doesn't sound right. I can create a permanently > hidden key any time by calling the 'generate-hidden-key' action, or if > the device or the model allows I could even switch to non-hidden key, I > believe, by providing the binary. So I find the second sentence > irrelevant in this description. >>=20 >> More importantly, I find the "Permanently hidden keys cannot be > archived or backed up" statement false. Isn't that implementation > specific how archiving is done? If a device puts the hidden keys on some > storage, it may still be possible to back them up. I would prefer to > remove this sentence and leave backup considerations to implementations. >>=20 >> Could these changes be done? >>=20 >> Br, >> Balazs >=20 >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >=20 >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From nobody Sat Mar 23 13:14:29 2019 Return-Path: <01000169ac30ab0b-b03463e4-12ca-4cb9-9e39-a5fd89bbf71a-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 50566130D7A for ; Sat, 23 Mar 2019 13:14:27 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 FFpRC2qGTr40 for ; Sat, 23 Mar 2019 13:14:26 -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 D386C12D84C for ; Sat, 23 Mar 2019 13:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553372064; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Date:Subject:Message-Id:References:In-Reply-To:To:Feedback-ID; bh=TYuUyPR72SXMRDorMfSoT3mkPSe4gCeZLdVxFJK29Vw=; b=IIQSmRZ+lYAwG2+qOs18eybXC2wT+UDhnbMnhBxUWWsg3Qxsh0NFMO7uhVA29pZX EbQub86BRTx3waDvi2zj6S7YIsnAiRjFdUPwwbCqrqHkiusQAtN7vEkhwPtbz/lHMOg P8cQVtD7qfFqtQY4QvB8MNuNSgTB5yEEgNYA9H54= From: Kent Watsen Content-Type: multipart/alternative; boundary=Apple-Mail-5DE61AA9-BF26-4446-B08A-4E6AB51E65BE Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Sat, 23 Mar 2019 20:14:24 +0000 Message-ID: <01000169ac30ab0b-b03463e4-12ca-4cb9-9e39-a5fd89bbf71a-000000@email.amazonses.com> References: <0100016979939b1b-3ddaf119-fd79-4b38-b80b-2be09d10fc3c-000000@email.amazonses.com> <010001697ca6f106-1e69b94e-9037-4846-afae-5a95b7063620-000000@email.amazonses.com> In-Reply-To: <010001697ca6f106-1e69b94e-9037-4846-afae-5a95b7063620-000000@email.amazonses.com> To: Netconf X-Mailer: iPad Mail (16D57) X-SES-Outgoing: 2019.03.23-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] NETCONF 104 Draft Agenda 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: Sat, 23 Mar 2019 20:14:27 -0000 --Apple-Mail-5DE61AA9-BF26-4446-B08A-4E6AB51E65BE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The agenda has been updated. Andy=E2=80=99s presentation on module tag oper= ations has been cancelled. https://datatracker.ietf.org/doc/agenda-104-netconf/ Kent= --Apple-Mail-5DE61AA9-BF26-4446-B08A-4E6AB51E65BE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

The agenda has been updated.=  Andy=E2=80=99s presentation on module tag operations has been cancell= ed.

= --Apple-Mail-5DE61AA9-BF26-4446-B08A-4E6AB51E65BE-- From nobody Sat Mar 23 13:19:49 2019 Return-Path: <01000169ac358cd3-c93a7003-7596-4f74-bbd6-d73cb5e71dca-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 7BD4C12D84C for ; Sat, 23 Mar 2019 13:19:47 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 jwiNGNcsMn5H for ; Sat, 23 Mar 2019 13:19:46 -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 C6B2A1200B3 for ; Sat, 23 Mar 2019 13:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553372384; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Date:Subject:Message-Id:References:In-Reply-To:To:Feedback-ID; bh=84wLyYuz19MhfVQs0sTPYht4RLftufUAhM7aTati/dY=; b=T0dwFZ8hemlPCy1WggYranp4zEU4nfZTtE4G22q9bUtjR5+xNxp6WBFitV1EK1Jj bu0RZH8TgasRY7v9kLDXaV/LgTj3XT6lDjGJSGdZJbiQa6fheKfDUPWSYU95JZ/o3qI fAcwgb6ejD1EE/YRz8lGVZWa31f9ebTdyaDugkZQ= From: Kent Watsen Content-Type: multipart/alternative; boundary=Apple-Mail-5E3C3890-79B7-4D4F-A426-88FE33E48176 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Sat, 23 Mar 2019 20:19:44 +0000 Message-ID: <01000169ac358cd3-c93a7003-7596-4f74-bbd6-d73cb5e71dca-000000@email.amazonses.com> References: <01000169ab3af34a-4fc5e609-6777-4017-808c-5ee23dd2158d-000000@email.amazonses.com> In-Reply-To: To: netconf@ietf.org X-Mailer: iPad Mail (16D57) X-SES-Outgoing: 2019.03.23-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] module tag ops presentation 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: Sat, 23 Mar 2019 20:19:48 -0000 --Apple-Mail-5E3C3890-79B7-4D4F-A426-88FE33E48176 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable [just us] Hi Mahesh, I updated the agenda, can you update the chair slides? Kent > On Mar 23, 2019, at 4:55 PM, Andy Bierman wrote: >=20 > Hi, >=20 > That is gmail doing that. > I will try to delete it. > I just type netconf-chairs@ietf.org >=20 >=20 > Andy >=20 >=20 >> On Sat, Mar 23, 2019 at 8:46 AM Kent Watsen wrote: >> BTW, is your =E2=80=9Cchairs=E2=80=9D alias messed up? >>=20 >> I see =E2=80=9CNETCONF Working Group=E2=80=9D, which isn=E2=80=99t right.= .. >>=20 >> K. >>=20 >>=20 >> > On Mar 23, 2019, at 4:44 PM, Kent Watsen wrote: >> >=20 >> > Okay. >> >=20 >> > We could setup meetecho but 1) it=E2=80=99s never that great, 2) it=E2=80= =99s a -00 I-D, and 3) we=E2=80=99re a little crunched on time... >> >=20 >> > That said, if you *want* to present remote, please say so, we can make i= t happen. >> >=20 >> > Kent >> >=20 >> >=20 >> >> On Mar 23, 2019, at 4:37 PM, Andy Bierman wrote: >> >>=20 >> >> Hi, >> >>=20 >> >> I will not be in Prague for the meeting so you should cancel >> >> the Module Tag Operations discussion. The WG does not seem >> >> interested in this topic anyway. >> >>=20 >> >>=20 >> >> Andy >> >>=20 >>=20 --Apple-Mail-5E3C3890-79B7-4D4F-A426-88FE33E48176 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable [just us]

Hi Mahesh,

<= div>I updated the agenda, can you update the chair slides?

Kent


On Mar 23, 2019, at 4:55 PM, Andy Bierman <andy@yumaworks.com> wrote:

Hi,

That= is gmail doing that.
I will try to delete it.
I just ty= pe netconf-chairs@ietf.org


Andy


On Sat, Mar 23= , 2019 at 8:46 AM Kent Watsen <kent@wa= tsen.net> wrote:
BTW, is your =E2=80=9Cchairs=E2=80=9D alias messed up?

I see =E2=80=9CNETCONF Working Group=E2=80=9D, which isn=E2=80=99t right...<= br>
K.


> On Mar 23, 2019, at 4:44 PM, Kent Watsen <kent@watsen.net> wrote:
>
> Okay.
>
> We could setup meetecho but 1) it=E2=80=99s never that great, 2) it=E2=80= =99s a -00 I-D, and 3) we=E2=80=99re a little crunched on time...
>
> That said, if you *want* to present remote, please say so, we can make i= t happen.
>
> Kent
>
>
>> On Mar 23, 2019, at 4:37 PM, Andy Bierman <andy@yumaworks.com> wrote:
>>
>> Hi,
>>
>> I will not be in Prague for the meeting so you should cancel
>> the Module Tag Operations discussion. The WG does not seem
>> interested in this topic anyway.
>>
>>
>> Andy
>>

= --Apple-Mail-5E3C3890-79B7-4D4F-A426-88FE33E48176-- From nobody Sat Mar 23 13:21:18 2019 Return-Path: <01000169ac36e935-db19b2f0-bcfe-4c81-ad53-1ceba542b11b-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 3FA4B130D7A for ; Sat, 23 Mar 2019 13:21:16 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 CccEniKaEkqA for ; Sat, 23 Mar 2019 13:21:15 -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 D87001200B3 for ; Sat, 23 Mar 2019 13:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553372473; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Date:Subject:Message-Id:References:In-Reply-To:To:Feedback-ID; bh=/3gVWX4qi8UroACofIc6l7ae1idCuy5nL0YNp7Z/aQA=; b=KwCUucvoTNLehwYRrpRY1V6IMc93MHag1Bw/LFZv36NQ4F94alXYHkdNiupNEV23 D+OK5mcd99EPKg3wTgQTRfGck18wx1hcyO0uZSpo3xFU4THaEx54vhJd6OaaU1sPYHM /YbWoif5UtL/aPeEpMP6RvP2y49M2ePYpK86P4YA= From: Kent Watsen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Sat, 23 Mar 2019 20:21:13 +0000 Message-ID: <01000169ac36e935-db19b2f0-bcfe-4c81-ad53-1ceba542b11b-000000@email.amazonses.com> References: <01000169ab3af34a-4fc5e609-6777-4017-808c-5ee23dd2158d-000000@email.amazonses.com> <01000169ac358cd3-c93a7003-7596-4f74-bbd6-d73cb5e71dca-000000@email.amazonses.com> In-Reply-To: <01000169ac358cd3-c93a7003-7596-4f74-bbd6-d73cb5e71dca-000000@email.amazonses.com> To: netconf@ietf.org X-Mailer: iPad Mail (16D57) X-SES-Outgoing: 2019.03.23-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] module tag ops presentation 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: Sat, 23 Mar 2019 20:21:16 -0000 Ha, so much for being =E2=80=9Cjust us=E2=80=9D ;) K. Sent from my iPad > On Mar 23, 2019, at 9:19 PM, Kent Watsen wrote: >=20 > [just us] >=20 > Hi Mahesh, >=20 > I updated the agenda, can you update the chair slides? >=20 > Kent From nobody Sun Mar 24 02:47:52 2019 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 97455127979; Sun, 24 Mar 2019 02:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 LBsRUhASQU8W; Sun, 24 Mar 2019 02:47:40 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF83312785F; Sun, 24 Mar 2019 02:47:39 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44Rsy15ShKzyWC; Sun, 24 Mar 2019 10:47:37 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> Date: Sun, 24 Mar 2019 10:47:36 +0100 Cc: Michel Veillette , "netconf@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 575113655.050311-985b8fd567a067a29b90e8ebdddf768f Content-Transfer-Encoding: quoted-printable Message-Id: <3D7C33C9-CB86-4965-899D-93C4B7343DF7@tzi.org> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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: Sun, 24 Mar 2019 09:47:42 -0000 On Mar 23, 2019, at 14:35, Juergen Schoenwaelder = wrote: >=20 > RFC 7950 section 9.12: Thank you, this is very useful. Let me try to ask my other question in a very concrete way: If I have > typedef foo { > type union { > type enumeration { > enum red { value 1; } > enum breen { value 2; } > enum glue { value 3; } > } > type enumeration { > enum tacks { value 1; } > enum nails { value 2; } > enum glue { value 3; } > } > } > } in one place, and > typedef bar { > type union { > type enumeration { > enum red { value 1; } > enum breen { value 2; } > enum glue { value 3; } > } > type enumeration { > enum sparkling { value 1; } > enum blinking { value 2; } > enum steady { value 3; } > } > } > } in another place, is the value =E2=80=9Cred=E2=80=9D between the two = types referring to the =E2=80=9Csame thing=E2=80=9D? If there were a typedef for the two anonymous enumerations that both = look the same, as in typedef color { > type enumeration { > enum red { value 1; } > enum breen { value 2; } > enum glue { value 3; } > } } and that typedef being referenced from both unions instead of = copy-pasting it, would that change the answer? Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Mar 24 04:30:08 2019 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 E4EB8128BE6 for ; Sun, 24 Mar 2019 04:30:00 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 YY6z1QESDe6F for ; Sun, 24 Mar 2019 04:29:59 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 973DB1279AF for ; Sun, 24 Mar 2019 04:29:58 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id v14so4210377lfi.0 for ; Sun, 24 Mar 2019 04:29:58 -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=86u4rCtozzj8VkUZGpOwDr1VvmXXNVeMmeKVB4jZp0Y=; b=ed+RnGxUruuJ5yZMRXzBODo9flZKHhCQEf6zB25R2PpEujTh4BgwyzfbJ4nMsmVWoQ lu+gVzClXcfmqlVxmaMJdw1Dsw+R+VtbomLkX0PHeWN/oBCMHyDmQDLw7YJZwerWoMND Nx38i39gY7YFId7Yfdue1mg1b4+JujpWfF2j0/XDADm6XFmEH2JMr0RVFn6m3TCy3sQJ Nuz6+4qXg5xaY97Y1YW4EAVpRtLToC6qNrgeI4vaEIxm2iLWnDNr5u7esHXt0i3HUBqn 9WO4TkOndg3yubMqYRu76Ex5GHoukBO9aQRw4lhuFhN5hb6PM/mgspxPSVFz/TJNT+C1 ynYg== 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=86u4rCtozzj8VkUZGpOwDr1VvmXXNVeMmeKVB4jZp0Y=; b=AGrDnTCbQfUiUOeUA1uaZl9vCZgvqLEJqHsVhmrSl5buT/FfA0ezYnPw01mqjLEJwR cIt32UyPCPHcZ7XyTn5dFdamCalCXtpYx/vujidGmZUbLDIR/Ox2DxxGSYUfnNPWyuHm k3Fo94iuygwJVJn5BYLRQirboQWbC8D1PbaB2+SsBr6K/7ezflvudWCU+fU0mFb1Nlwo qt3Dp/8ZTDM15lnxeclOfJT/OpJFOyHJGuxFsy2yHmIWhlAEDN5D0gnBvUMK66ZLFSOl ANRcLsBS+c5RlCFXFfb7aObLJI4uRJCA/WWZ3bP0hs7vp1RosHRJ+hO+zwxsBySzmw7N 3+iA== X-Gm-Message-State: APjAAAVDympBcZManw9lNXkpnxOSzgPLUia1ROqW5BcE45a0kWAtXtQz CEcfb0xQ3vB3Kb/SXFK9AkHy4UHVWbnakKm0nMPkKA== X-Google-Smtp-Source: APXvYqxXyt4mZu+8LXD+16/Omjo/DtPZNlwK9g9seEjVPHxQCvDmFIzNinkW7LdjCkr64k37KqBmwQNo80yYwQbZAC8= X-Received: by 2002:ac2:569b:: with SMTP id 27mr10336213lfr.24.1553426996571; Sun, 24 Mar 2019 04:29:56 -0700 (PDT) MIME-Version: 1.0 References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> <3D7C33C9-CB86-4965-899D-93C4B7343DF7@tzi.org> In-Reply-To: <3D7C33C9-CB86-4965-899D-93C4B7343DF7@tzi.org> From: Andy Bierman Date: Sun, 24 Mar 2019 04:29:45 -0700 Message-ID: To: Carsten Bormann Cc: Juergen Schoenwaelder , "netconf@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="00000000000050d1ab0584d56848" Archived-At: Subject: Re: [netconf] [core] YANG encoding in CBOR 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: Sun, 24 Mar 2019 11:30:01 -0000 --00000000000050d1ab0584d56848 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Mar 24, 2019 at 2:47 AM Carsten Bormann wrote: > On Mar 23, 2019, at 14:35, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > > RFC 7950 section 9.12: > > Thank you, this is very useful. > > Let me try to ask my other question in a very concrete way: > > If I have > > > typedef foo { > > type union { > > type enumeration { > > enum red { value 1; } > > enum breen { value 2; } > > enum glue { value 3; } > > } > > type enumeration { > > enum tacks { value 1; } > > enum nails { value 2; } > > enum glue { value 3; } > > } > > } > > } > > in one place, and > > > typedef bar { > > type union { > > type enumeration { > > enum red { value 1; } > > enum breen { value 2; } > > enum glue { value 3; } > > } > > type enumeration { > > enum sparkling { value 1; } > > enum blinking { value 2; } > > enum steady { value 3; } > > } > > } > > } > > in another place, is the value =E2=80=9Cred=E2=80=9D between the two type= s referring to > the =E2=80=9Csame thing=E2=80=9D? > > no -- and this is not an error, although it is position-dependent: typedef baz { type union { type foo; type bar; } } The issue for CBOR applies to both bits and enumerations. The probability of 2 enum names clashing is almost zero. The probability of 2 value-stmts clashing is almost 100% The answer seems to be simple but inefficient: Always encode bits or enumeration as a string, if this is within a union type. There are not many of these -- more likely to find strings with different patterns where first-match-wins is no different than before (for XML) > If there were a typedef for the two anonymous enumerations that both look > the same, as in > > typedef color { > > type enumeration { > > enum red { value 1; } > > enum breen { value 2; } > > enum glue { value 3; } > > } > } > > and that typedef being referenced from both unions instead of copy-pastin= g > it, would that change the answer? > > I think first-match-wins still dictates the result. The JSON issue (and maybe CBOR) is what Juergen is talking about: typedef maybe-first { type union { type string; type int32; } } Use 42 as an example... The XML encoding 42 will always match string. The JSON (or CBOR) encoding { "foo": 42 } will always match int32 We want YANG data to maintain fidelity and still be encoding-independent, but this is broken for union types. Gr=C3=BC=C3=9Fe, Carsten > > Andy > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --00000000000050d1ab0584d56848 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Mar 24, 2019 at 2:47 AM Carst= en Bormann <cabo@tzi.org> wrote:<= br>
On Mar 23, 2019,= at 14:35, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>
> RFC 7950 section 9.12:

Thank you, this is very useful.

Let me try to ask my other question in a very concrete way:

If I have

> typedef foo {
>=C2=A0 type union {
>=C2=A0 =C2=A0 type enumeration {
>=C2=A0 =C2=A0 =C2=A0 enum red { value 1; }
>=C2=A0 =C2=A0 =C2=A0 enum breen { value 2; }
>=C2=A0 =C2=A0 =C2=A0 enum glue { value 3; }
>=C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 type enumeration {
>=C2=A0 =C2=A0 =C2=A0 enum tacks { value 1; }
>=C2=A0 =C2=A0 =C2=A0 enum nails { value 2; }
>=C2=A0 =C2=A0 =C2=A0 enum glue { value 3; }
>=C2=A0 =C2=A0 }
>=C2=A0 }
> }

in one place, and

> typedef bar {
>=C2=A0 type union {
>=C2=A0 =C2=A0 type enumeration {
>=C2=A0 =C2=A0 =C2=A0 enum red { value 1; }
>=C2=A0 =C2=A0 =C2=A0 enum breen { value 2; }
>=C2=A0 =C2=A0 =C2=A0 enum glue { value 3; }
>=C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 type enumeration {
>=C2=A0 =C2=A0 =C2=A0 enum sparkling { value 1; }
>=C2=A0 =C2=A0 =C2=A0 enum blinking { value 2; }
>=C2=A0 =C2=A0 =C2=A0 enum steady { value 3; }
>=C2=A0 =C2=A0 }
>=C2=A0 }
> }

in another place, is the value =E2=80=9Cred=E2=80=9D between the two types = referring to the =E2=80=9Csame thing=E2=80=9D?






where first-match-wins is no different than before (for XML)
If there were a typedef for the two anonymous enumerations that both look t= he same, as in

=C2=A0 typedef color {
>=C2=A0 =C2=A0 type enumeration {
>=C2=A0 =C2=A0 =C2=A0 enum red { value 1; }
>=C2=A0 =C2=A0 =C2=A0 enum breen { value 2; }
>=C2=A0 =C2=A0 =C2=A0 enum glue { value 3; }
>=C2=A0 =C2=A0 }
=C2=A0 }

and that typedef being referenced from both unions instead of copy-pasting = it, would that change the answer?





--00000000000050d1ab0584d56848-- From nobody Sun Mar 24 07:41:02 2019 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 3EBAC129619; Sun, 24 Mar 2019 07:40:53 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 1CBn5dZGZMGD; Sun, 24 Mar 2019 07:40:51 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C2C71294B6; Sun, 24 Mar 2019 07:40:51 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id DF52D3D; Sun, 24 Mar 2019 15:40:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id WSV4IvdO_E7T; Sun, 24 Mar 2019 15:40:49 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Sun, 24 Mar 2019 15:40:49 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id C80AB200A7; Sun, 24 Mar 2019 15:40:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id B8S7xlLUImxj; Sun, 24 Mar 2019 15:40:49 +0100 (CET) Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 6B02B200A6; Sun, 24 Mar 2019 15:40:49 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Sun, 24 Mar 2019 15:40:48 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 8781230077BEFE; Sun, 24 Mar 2019 15:40:48 +0100 (CET) Date: Sun, 24 Mar 2019 15:40:48 +0100 From: Juergen Schoenwaelder To: Andy Bierman CC: Carsten Bormann , "netconf@ietf.org" , "core@ietf.org" Message-ID: <20190324144048.xz3ovvuyqaygoimy@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , Carsten Bormann , "netconf@ietf.org" , "core@ietf.org" References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> <3D7C33C9-CB86-4965-899D-93C4B7343DF7@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] [core] YANG encoding in CBOR 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: Sun, 24 Mar 2019 14:40:53 -0000 On Sun, Mar 24, 2019 at 04:29:45AM -0700, Andy Bierman wrote: > On Sun, Mar 24, 2019 at 2:47 AM Carsten Bormann wrote: >=20 > > On Mar 23, 2019, at 14:35, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > RFC 7950 section 9.12: > > > > Thank you, this is very useful. > > > > Let me try to ask my other question in a very concrete way: > > > > If I have > > > > > typedef foo { > > > type union { > > > type enumeration { > > > enum red { value 1; } > > > enum breen { value 2; } > > > enum glue { value 3; } > > > } > > > type enumeration { > > > enum tacks { value 1; } > > > enum nails { value 2; } > > > enum glue { value 3; } > > > } > > > } > > > } > > > > in one place, and > > > > > typedef bar { > > > type union { > > > type enumeration { > > > enum red { value 1; } > > > enum breen { value 2; } > > > enum glue { value 3; } > > > } > > > type enumeration { > > > enum sparkling { value 1; } > > > enum blinking { value 2; } > > > enum steady { value 3; } > > > } > > > } > > > } > > > > in another place, is the value =E2=80=9Cred=E2=80=9D between the two = types referring to > > the =E2=80=9Csame thing=E2=80=9D? > > > > >=20 > no -- and this is not an error, although it is position-dependent: >=20 > typedef baz { > type union { > type foo; > type bar; > } > } >=20 > The issue for CBOR applies to both bits and enumerations. > The probability of 2 enum names clashing is almost zero. > The probability of 2 value-stmts clashing is almost 100% Enum names like 'unknown' do have a probability to clash that is larger than 0%. =20 > The answer seems to be simple but inefficient: > Always encode bits or enumeration as a string, if this is within a unio= n > type. > There are not many of these -- more likely to find strings with differe= nt > patterns > where first-match-wins is no different than before (for XML) The first match wins rule is debatable. Someone adds an enum to an enumeration that you import and suddenly the interpretation of config changes. Not very robust. > > If there were a typedef for the two anonymous enumerations that both = look > > the same, as in > > > > typedef color { > > > type enumeration { > > > enum red { value 1; } > > > enum breen { value 2; } > > > enum glue { value 3; } > > > } > > } > > > > and that typedef being referenced from both unions instead of copy-pa= sting > > it, would that change the answer? > > > > >=20 > I think first-match-wins still dictates the result. >=20 > The JSON issue (and maybe CBOR) is what Juergen is talking about: >=20 > typedef maybe-first { > type union { > type string; > type int32; > } > } >=20 > Use 42 as an example... > The XML encoding 42 will always match string. > The JSON (or CBOR) encoding { "foo": 42 } will always match int32 > We want YANG data to maintain fidelity and still be encoding-independen= t, > but this is broken for union types. If we plan to improve things we have we should improve the union construct by turning it into a tagged union (and do away with the 'first match wins' rule but leave it for backwards compatibility for untagged unions as long as they are used). /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Mar 24 09:55:36 2019 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 521491200D7 for ; Sun, 24 Mar 2019 09:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Hyoi_yJt5i7Y for ; Sun, 24 Mar 2019 09:55:30 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24D20126C15 for ; Sun, 24 Mar 2019 09:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12172; q=dns/txt; s=iport; t=1553446530; x=1554656130; h=to:cc:from:subject:message-id:date:mime-version; bh=mOGH9/dbbiL0fbPky+OxfBJ0d3NpRnkOlnJO9atSAyA=; b=CrXzm2GQjfIG4jbdi01D6f6TceNlUtkRbaymotvYMa1w6duC6IYMtUpY Lw+HBgLQmogAq0yScOPc5mDn1foW8mdxaXLZHgyGYgOst/Z4kUXJp6f94 vm80vA+jhqnKtNe3Jgr4E4H4lXT981nil4Varf7K5bK0S3p7knaPSC0Kv k=; X-IronPort-AV: E=Sophos; i="5.60,256,1549929600"; d="scan'208,217"; a="10881273" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Mar 2019 16:55:27 +0000 Received: from [10.61.80.17] (ams3-vpn-dhcp4114.cisco.com [10.61.80.17]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id x2OGtRJX012014; Sun, 24 Mar 2019 16:55:27 GMT To: NETCONF From: Benoit Claise Message-ID: Date: Sun, 24 Mar 2019 17:55:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------F4DC043C21F1B5A1F9018B21" Content-Language: en-US X-Outbound-SMTP-Client: 10.61.80.17, ams3-vpn-dhcp4114.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [netconf] draft-ietf-netconf-notification-capabilities feedback 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: Sun, 24 Mar 2019 16:55:34 -0000 This is a multi-part message in MIME format. --------------F4DC043C21F1B5A1F9018B21 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, Here is my feedback on draft-ietf-netconf-notification-capabilities , which I gave verbally to Balasz today. - we need the on-change capabilities for     1. per datastore     2. per YANG object(s), i.e. schema specifig     3. per YANG instance - We really would some nacm:node-instance-identifier examples (of the 3 different use cases) - happy to see that it applies to config and oper data. - the only leaves I care about are: +--ro on-change-notification-capability* [node-selector] +--ro node-selector nacm:node-instance-identifier +--ro on-change-notification-sent boolean And because I need the default: +--ro notification-sent-for-config-default? boolean +--ro notification-sent-for-state-default? boolean The rest below seems to be implementation specific (limitations): +--ro minimum-dampening-period? uint32 +--ro (update-period)? | +--:(minimum-update-period) | | +--ro minimum-update-period? uint32 | +--:(supported-update-period) | +--ro supported-update-period* uint32 +--ro max-objects-per-update? uint32 - The choice default values should be discussed. They implementation-specific. leaf notification-sent-for-config-default { type boolean; default true; description "Specifies the default value for top level configuration data nodes for the on-change-notification-sent capability."; } leaf notification-sent-for-state-default { type boolean; default false; description "Specifies the default value top level state data nodes for the on-change-notification-sent capability."; Initially, I was thinking that both should be false, so that only on-change true must be present in the list. - Not sure why the draft tries to go in the compliance statement of you MUST support both options The information SHALL be provided in two ways both following the ietf-notification-capabilities module: o It SHALL be provided by the implementer as YANG instance data file complying to the [I-D.lengyel-netmod-yang-instance-data ]. The file SHALL be available already in implementation time retrievable in a way that does not depend on a live network node. E.g. download from product Website. o It SHALL be available via NETCONF or RESTCONF from the live YANG server during runtime. The specifications should document: If you want this info off-line, then use draft-ietf-netmod-yang-instance-file-format If you want this info on-line, implement the module in the server, potentially as an extension to the IETF-YANG-LIBRARY MUST implement one of the two. EDITORIAL - When I see "instance", I always wonder if you mean an instantation or the instance-file-format If the information is not available early in some document, but only as instance data from the network node, the NMS implementation will be delayed, because it has to wait for the network node to be ready. - This explanation could be improved (read it multiple times) On-change notifications SHALL be sent for a config=true data node if one of the following is true: - if it is a top level data-node and is not specified in the on-change-notification-capability list and the notification-sent-for-config-default is true; or - notifications are sent for its parent data node and it is not specified in the on-change-notification-capability list; or - it is specified in the on-change-notification-capability list and has a on-change-notification-sent value true. On-change notifications SHALL be sent for a config=false data node if one of the following is true: - if it is a top level data-node or has a config=true parent data node and is not specified in the on-change-notification-capability list and the notification-sent-for-state-default is true; or - notifications are sent for its parent data node which is also config=false and it is not specified in the on-change-notification-capability list; or - it is specified in the on-change-notification-capability list and has an on-change-notification-sent value true or "; - why don't you just mention "on-change streaming capability discovery" Run-time information is needed o for any "purely model driven" client, e.g. a NETCONF-browser. As long as it has a valid model to read the capability information, it does not care which data nodes send notification, it will just handle what is available. o in case the capability might change during run-time e.g. due to licensing, HW constraints etc. o to check that early, implementation time capability information about the capabilities is indeed what the server implements (is the supplied documentation correct?) - The terminology seems to focus on NETCONF, however it should stress the generic streaming capabilities Regards, Benoit --------------F4DC043C21F1B5A1F9018B21 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

Here is my feedback on draft-ietf-netconf-notification-capabilities, which I gave verbally to Balasz today.

- we need the on-change capabilities for
    1. per datastore
    2. per YANG object(s), i.e. schema specifig
    3. per YANG instance

- We really would some nacm:node-instance-identifier examples (of the 3 different use cases)

- happy to see that it applies to config and oper data.

- the only leaves I care about are: 
      +--ro on-change-notification-capability* [node-selector]
         +--ro node-selector               nacm:node-instance-identifier
         +--ro on-change-notification-sent    boolean
And because I need the default:
      +--ro notification-sent-for-config-default?   boolean
      +--ro notification-sent-for-state-default?    boolean
The rest below seems to be implementation specific (limitations):
      +--ro minimum-dampening-period?               uint32
      +--ro (update-period)?
      |  +--:(minimum-update-period)
      |  |  +--ro minimum-update-period?                  uint32
      |  +--:(supported-update-period)
      |     +--ro supported-update-period*                uint32
      +--ro max-objects-per-update?                 uint32

- The choice default values should be discussed. They implementation-specific. 
     leaf notification-sent-for-config-default {
       type boolean;
       default true;
       description "Specifies the default value for
         top level configuration data nodes for the
         on-change-notification-sent capability.";
     }

     leaf notification-sent-for-state-default {
       type boolean;
       default false;
       description "Specifies the default value
         top level state data nodes for the
         on-change-notification-sent capability.";
Initially, I was thinking that both should be false, so that only on-change true must be present in the list.

- Not sure why the draft tries to go in the compliance statement of you MUST support both options
 The information SHALL be provided in two ways both following the
   ietf-notification-capabilities module:

   o  It SHALL be provided by the implementer as YANG instance data file
      complying to the [I-D.lengyel-netmod-yang-instance-data].  The
      file SHALL be available already in implementation time retrievable
      in a way that does not depend on a live network node.  E.g.
      download from product Website.

   o  It SHALL be available via NETCONF or RESTCONF from the live YANG
      server during runtime.
The specifications should document:
If you want this info off-line, then use draft-ietf-netmod-yang-instance-file-format
If you want this info on-line, implement the module in the server, potentially as an extension to the IETF-YANG-LIBRARY
MUST implement one of the two.


EDITORIAL
- When I see "instance", I always wonder if you mean an instantation or the instance-file-format
   If the information is
   not available early in some document, but only as instance data from
   the network node, the NMS implementation will be delayed, because it
   has to wait for the network node to be ready.
- This explanation could be improved (read it multiple times)
     On-change notifications SHALL be sent for a config=true
     data node if one of the following is true:
     - if it is a top level data-node and is not specified in the
     on-change-notification-capability list and the
     notification-sent-for-config-default is true; or
     - notifications are sent for its parent data node and it is
     not specified in the on-change-notification-capability list; or
     - it is specified in the on-change-notification-capability
     list and has a on-change-notification-sent value true.

     On-change notifications SHALL be sent for a config=false
     data node if one of the following is true:
     - if it is a top level data-node or has a config=true parent
     data node and is not specified in the
     on-change-notification-capability list and the
     notification-sent-for-state-default is true; or
     - notifications are sent for its parent data node
     which is also config=false and it is
     not specified in the on-change-notification-capability list; or
     - it is specified in the on-change-notification-capability
     list and has an on-change-notification-sent value true or
     ";
- why don't you just mention "on-change streaming capability discovery"

   Run-time information is needed

   o  for any "purely model driven" client, e.g. a NETCONF-browser.  As
      long as it has a valid model to read the capability information,
      it does not care which data nodes send notification, it will just
      handle what is available.

   o  in case the capability might change during run-time e.g. due to
      licensing, HW constraints etc.

   o  to check that early, implementation time capability information
      about the capabilities is indeed what the server implements (is
      the supplied documentation correct?)
- The terminology seems to focus on NETCONF, however it should stress the generic streaming capabilities

Regards, Benoit
--------------F4DC043C21F1B5A1F9018B21-- From nobody Sun Mar 24 15:24:20 2019 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 40F29120162; Sun, 24 Mar 2019 15:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 F7QfvduC11dU; Sun, 24 Mar 2019 15:24:16 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CA6D120161; Sun, 24 Mar 2019 15:24:16 -0700 (PDT) Received: from surfer-172-30-2-245-hotspot.internet-for-guests.com (107.223.broadband2.iol.cz [83.208.223.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44SBl20Pwlzyhl; Sun, 24 Mar 2019 23:24:13 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Sun, 24 Mar 2019 23:24:12 +0100 Cc: Juergen Schoenwaelder , "netconf@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 575159051.249061-d1cd3989a1f1a6d61b43376ae4697251 Content-Transfer-Encoding: quoted-printable Message-Id: <640708E8-F80E-49EE-9AEF-DA8DAEE3AA57@tzi.org> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> <3D7C33C9-CB86-4965-899D-93C4B7343DF7@tzi.org> To: Andy Bierman X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netconf] [core] YANG encoding in CBOR 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: Sun, 24 Mar 2019 22:24:18 -0000 On Mar 24, 2019, at 12:29, Andy Bierman wrote: >=20 > The answer seems to be simple but inefficient: > Always encode bits or enumeration as a string, if this is within a = union type. For enum values within unions (which are already handled specially by = giving them a CBOR tag) we could simply use a SID (that we then would = have to generate for each enum value) instead of a string. We could = also extend this to enums outside unions; but here the recurrence to the = (outside unions unambiguous) value sounds better to me. Bits. Oh. Same procedure, I=E2=80=99d say. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Mar 24 15:52:44 2019 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 80322120196 for ; Sun, 24 Mar 2019 15:52: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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 i_UqsmylTiAZ for ; Sun, 24 Mar 2019 15:52:34 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 438D3120183 for ; Sun, 24 Mar 2019 15:52:34 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id l7so6144031ljg.6 for ; Sun, 24 Mar 2019 15:52:34 -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=TM8maVfyZAVSpKur4uiZMSzyyF02YYyriq21lI9lGow=; b=qxjA3Z7guLGI6LpkeuJlD4JEWg1GP4zrwVTo7sVzjbkW9DxzlSjY63+ffncfS9grjK 4gK/ryfxX8M6HumwZtliDJlakUWeD54jcoWAzPNhnR9XfZd1j2O1T2ixa0QcZzROd1nM Kw3tsfI21Y0wJcxZLxCXTUiJIn62AfJXeCZ6wHld3y4ojiF4Ie6qGi/5y9V7o8PNUFTR Jwct3DMpogLQCLkd0OJf0FyXCxgDID87BAJ3nm3/CeeCjL5yjQuh1iOhGGGRaUlrQ/KC nel9gTfH11wPe06vgC8/OXeIPIXHgiRQfrGYVHhdWnm+Be1JyW3JXWl9TOUrND5Ultga 04cQ== 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=TM8maVfyZAVSpKur4uiZMSzyyF02YYyriq21lI9lGow=; b=A9ETWQFLLJrY2QDkRaqCV5gD0qKixfPat+NTrmhpA25+BvwU0bil/Og0mgXIPJJBau QfshwKcB83QNROflQFgL+N+KdOCfiSaQ/WisaGM4jee5U8nYYF+EJdzCSpoUA+A34l8i yGEi8Cig7Ib148e0/zFVIFcw/09mV3LYdvFq8VbMuLgd3gHp9utn7bb+FY7WK8OakYtr FrIMzdvdbwaCqqSXvLfSAxbVQR9ZsaFBSBL+iJZrmzKagfX10OUyJ/9jeaQzQhGufq4L zDwSkIzF31hoQaETWAh4Igtx6DJLN6XwvGKu/p/eg1V6g15v3iHKogVi3CJyrhui6Qgp ODaw== X-Gm-Message-State: APjAAAUTZWF4h4d7q+L78R+xsgPZgIabl+07kAlEe2WlzTpWj02HB+C7 0bUGfBRrOWXDfehpozrVveND8jMv2D+WfHYRDKyppQ== X-Google-Smtp-Source: APXvYqwj/ToUFdKyV1COGhFT29ws1WklEsfeixiu3jAcWWj3j7txvY8oVcGIrxPOfWUX1heOV6HU1CaICcVYCjAFbNM= X-Received: by 2002:a2e:8616:: with SMTP id a22mr11493244lji.173.1553467952179; Sun, 24 Mar 2019 15:52:32 -0700 (PDT) MIME-Version: 1.0 References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> <3D7C33C9-CB86-4965-899D-93C4B7343DF7@tzi.org> <640708E8-F80E-49EE-9AEF-DA8DAEE3AA57@tzi.org> In-Reply-To: <640708E8-F80E-49EE-9AEF-DA8DAEE3AA57@tzi.org> From: Andy Bierman Date: Sun, 24 Mar 2019 15:52:21 -0700 Message-ID: To: Carsten Bormann Cc: Juergen Schoenwaelder , "netconf@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="00000000000075be580584def1ba" Archived-At: Subject: Re: [netconf] [core] YANG encoding in CBOR 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: Sun, 24 Mar 2019 22:52:38 -0000 --00000000000075be580584def1ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Mar 24, 2019 at 3:24 PM Carsten Bormann wrote: > On Mar 24, 2019, at 12:29, Andy Bierman wrote: > > > > The answer seems to be simple but inefficient: > > Always encode bits or enumeration as a string, if this is within a unio= n > type. > > For enum values within unions (which are already handled specially by > giving them a CBOR tag) we could simply use a SID (that we then would hav= e > to generate for each enum value) instead of a string. We could also exte= nd > this to enums outside unions; but here the recurrence to the (outside > unions unambiguous) value sounds better to me. > > Bits. Oh. Same procedure, I=E2=80=99d say. > > This seems like it would make the SID file very complicated. Not sure it would work since leaf/leaf-list can define their own types. Plus, all the enum typedefs would have to be numbered this way. Maybe the SID authors can comment on how this would be done. > Gr=C3=BC=C3=9Fe, Carsten > > Andy --00000000000075be580584def1ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Mar 24, 2019 at 3:24 PM Carst= en Bormann <cabo@tzi.org> wrote:<= br>
On Mar 24, 2019,= at 12:29, Andy Bierman <andy@yumaworks.com> wrote:
>
> The answer seems to be simple but inefficient:
> Always encode bits or enumeration as a string, if this is within a uni= on type.

For enum values within unions (which are already handled specially by givin= g them a CBOR tag) we could simply use a SID (that we then would have to ge= nerate for each enum value) instead of a string.=C2=A0 We could also extend= this to enums outside unions; but here the recurrence to the (outside unio= ns unambiguous) value sounds better to me.

Bits.=C2=A0 Oh.=C2=A0 Same procedure, I=E2=80=99d say.


This seems like it would make the SID = file very complicated.
Not sure it would work since leaf/leaf-lis= t can define their own types.
Plus, all the enum typedefs would h= ave to be numbered this way.
Maybe the SID authors can comment on= how this would be done.


=C2=A0
Gr=C3=BC=C3=9Fe, Carsten


Andy
=C2=A0
--00000000000075be580584def1ba-- From nobody Sun Mar 24 22:29:15 2019 Return-Path: <01000169b352ec89-29aef326-0d11-4cf2-af02-c7ecd64aa4ef-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 8714612034F for ; Sun, 24 Mar 2019 22:29:13 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 W3Myb91OHccn for ; Sun, 24 Mar 2019 22:29:11 -0700 (PDT) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63EAD12034E for ; Sun, 24 Mar 2019 22:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553491750; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Date:Subject:Message-Id:To:Feedback-ID; bh=bhBi1oyTgoUySVMiMg6S45mOwG33kptPxnZ69v8IxEs=; b=diI2tKiZXA4PQz/i/RElktsslh30hqgeJb3VOdHrKpJ2XY+9h00uN74I86NGnWvX 0fy446acbO8kElf/Ccb6p0dfUFaAaM8W4E6qdLygJ/kjMGx735TQ5l5JtqPFgzFX5sk R2Jf7iVK1xTQOmMh4mKVIyTWd5wIck/QnyFzH1gA= From: Kent Watsen Content-Type: multipart/alternative; boundary=Apple-Mail-D39BE5B3-0A2D-469D-84D8-BEB5C1ACE441 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Mon, 25 Mar 2019 05:29:10 +0000 Message-ID: <01000169b352ec89-29aef326-0d11-4cf2-af02-c7ecd64aa4ef-000000@email.amazonses.com> To: netconf@ietf.org X-Mailer: iPhone Mail (16D57) X-SES-Outgoing: 2019.03.25-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] kw review of draft-wu-netconf-nmda-compatibility-01 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, 25 Mar 2019 05:29:13 -0000 --Apple-Mail-D39BE5B3-0A2D-469D-84D8-BEB5C1ACE441 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I started reading this document, but struggled with this sentence in the Int= roduction: =E2=80=9CNMDA Transition Guidelines in section 4.23.3 of [RFC8407] d= oesn't provide guidelines on whether existing NETCONF protocol operations su= ch as get/get-config/edit-config change semantics when they are exchanged be= tween the non NMDA client and the NMDA aware server.=E2=80=9D Correct, no statements are made (here or in RFC 8526), because no changes ex= ist. RFC 6241 is unchanged by RFC 8526.=20 The draft also has this statement in the Problems section: =E2=80=9CWhen a server is upgraded to NMDA aware server and needs to support= both NMDA client and non-NMDA clients, there is no standards-based way for t= he server to know whether the client supports NMDA.=E2=80=9D True, but it doesn=E2=80=99t matter, as the server only cares if the client u= ses the RPC from RFC 6241 or RFC 8526. =20 In order to maintain backwards compatibility, there are *no* changes to RFC 6= 241. It is an implementation issue for the NMDA-aware server to maintain s= upport for the non-NMDA aware RPCs. =20 FWIW, the draft also has suggestions for clarifying NMDA behavior (e.g., wit= h-defaults), which may be needed, but I didn=E2=80=99t dig into these sugges= tions as I want to first ensure my understanding of the problem statement.=20= Thanks,=20 Kent // contributor --Apple-Mail-D39BE5B3-0A2D-469D-84D8-BEB5C1ACE441 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I started reading this docum= ent, but struggled with this sentence in the Introduction:

=E2=80=9CNMDA Transi=
tion Guidelines in section 4.23.3 of [RFC8407] <snip/> doesn't provide gui=
delines on whether existing
   NETCONF protocol operations such as get/get-config/edit-config change
   semantics when they are exchanged between the non NMDA client and the
   NMDA aware &nbs=
p;server.=E2=80=9D

Correct, no statements are made (here or in RFC 8526), because no=
 changes exist.  RFC 6241 is unchanged by RFC 8526. =


The draft also=
 has this statement in the Problems section:
<= br>
=E2=80=9CWhen a server is upgraded to NMDA aware server and needs to support
   both NMDA client a=
nd non-NMDA clients, there is no standards-based
   way for the server to know whether the client supports NMDA.=E2=80=9D

True, but it doesn=E2=80=99t matter, as the se=
rver only cares if the client uses the RPC from RFC 6241 or RFC 8526.  =


In order to maintain backwards compatibilit=
y, there are *no* changes t=
o RFC 6241.   It is an implementation issue fo=
r the NMDA-aware server to maintain support for the non-NMDA aware RPCs. &nb=
sp;

FWIW, the dr=
aft also has suggestions for clarifying NMDA behavior (e.g., with-defaults),=
 which may be needed, but I didn=E2=80=99t dig into these suggestions as I w=
ant to first ensure my understanding of the problem statement. <=
/font>


Thanks, 
Kent // contributor

= --Apple-Mail-D39BE5B3-0A2D-469D-84D8-BEB5C1ACE441-- From nobody Sun Mar 24 23:24:29 2019 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 3F96E120360; Sun, 24 Mar 2019 23:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 F3wgb2uN70ua; Sun, 24 Mar 2019 23:23:47 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4DEE12035F; Sun, 24 Mar 2019 23:23:46 -0700 (PDT) Received: from surfer-172-30-2-245-hotspot.internet-for-guests.com (107.223.broadband2.iol.cz [83.208.223.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44SPNJ5BnRz10Q6; Mon, 25 Mar 2019 07:23:44 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Mon, 25 Mar 2019 07:23:44 +0100 Cc: Juergen Schoenwaelder , "netconf@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 575187822.01148-4f3da4270b3f661c3b433a83b313ed81 Content-Transfer-Encoding: quoted-printable Message-Id: <5D0AEDAC-4AD2-4DFD-BF19-EA210773EF66@tzi.org> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> <3D7C33C9-CB86-4965-899D-93C4B7343DF7@tzi.org> <640708E8-F80E-49EE-9AEF-DA8DAEE3AA57@tzi.org> To: Andy Bierman X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netconf] [core] YANG encoding in CBOR 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, 25 Mar 2019 06:23:49 -0000 Hi Andy, > On Sun, Mar 24, 2019 at 3:24 PM Carsten Bormann wrote: > On Mar 24, 2019, at 12:29, Andy Bierman wrote: > >=20 > > The answer seems to be simple but inefficient: > > Always encode bits or enumeration as a string, if this is within a = union type. >=20 > For enum values within unions (which are already handled specially by = giving them a CBOR tag) we could simply use a SID (that we then would = have to generate for each enum value) instead of a string. We could = also extend this to enums outside unions; but here the recurrence to the = (outside unions unambiguous) value sounds better to me. >=20 > Bits. Oh. Same procedure, I=E2=80=99d say. > On Mar 24, 2019, at 23:52, Andy Bierman wrote: >=20 > This seems like it would make the SID file very complicated. Not necessarily: > Not sure it would work since leaf/leaf-list can define their own = types. > Plus, all the enum typedefs would have to be numbered this way. Right! It would amount to defining an identifier scheme for all the so far = anonymous enums (and bits defs, I gather). > Maybe the SID authors can comment on how this would be done. Well, such an identifier scheme would benefit the whole YANG ecosystem, = so you can have a transition from =E2=80=9Cfirst match wins=E2=80=9D to = proper name equivalence. So we would need to do it in a way that over = time it can become part of the core YANG definition. We can maybe cheat: Use strings for enums inside unions for now, and = values only outside. But it would be good if the SID files generated (and registered) for a = YANG module already had those enum/bits type identifiers so we only have = to do the SID generation once, so I=E2=80=99m not sure if I like = cheating; doing the SIDs for those identifiers right from the outset = would win so much more. So does anyone have an idea how such an identifier scheme might look = like? Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Mar 24 23:53:22 2019 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 C0E0D120364 for ; Sun, 24 Mar 2019 23:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.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 cuHlmLFZrQ5a for ; Sun, 24 Mar 2019 23:53:16 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 8307F12025C for ; Sun, 24 Mar 2019 23:53:16 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id f3so7623543wmj.4 for ; Sun, 24 Mar 2019 23:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6EMXkItCK0kpVrtZFSfnBdseXv0IoyzlCNFV9Uoc6Cg=; b=pTHtEd+lvTFdjvSH5N5XqRhTMEM/KVNAhBSvwc48SJJwx3GicVu0V4wcSBTePmY7iW sM2WEvzwjAR1szLEX0x055M4ooel3u0AeI0qBZ+Ulo9/07o/SqtaY6s7k1wrqNXDAgl4 06VaYsXNl6631FUiSq4RSEuk+SxmPi+Fuk7o+45xCz2kVf/RUqpdHilkkoqzqqo0gFXv OX+ELoz2e6xP57kPKhobnIS0J2WD7a5sziyldNXxhrbZq12O4Q0ovTYUJala3TSk51CT diYVzDX6qQOKCvvHH+54JsWkZDfX5BgvdUdEke5rhElQcmJWONKPUUVC3iFCLYEi1e3l Z8uA== 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=6EMXkItCK0kpVrtZFSfnBdseXv0IoyzlCNFV9Uoc6Cg=; b=J90ZJk6vAaWDbR1Cs+RdEnFHRc4qw1N2nm1EQycxu9BX04OGNdz9ez7VE2c7/xjFI+ ZDSjGNUlfoFOWsx7FczXmLE8Us6LZs9f1M4Xq/6WNGv3DL/Tpoh+dvRsEXG/R+TWwT/w n5Nu/mtcqeeqxAzfThvELgO9DnvGbxSswje1s+WhZ5RCVBdEFZs9oWN6krsyixWdwFMX 2jFnylJeSxVGmjGCQ7zWAUc9fZRPO749PS0vQYfuyQ8R6pZWy1z/sSKAkqUGfsTVVFLf mngMbkJfl6DxcM90XTAqh+HtjBfYCVbdwc5dyRSfYGQ/6D5RPK+XpJ/SB+FXgSAaZzNJ 43dA== X-Gm-Message-State: APjAAAUP/722i2+5dJq5bE2RJOd3ByY0K03jf+7WwTWqpsOL8zQu+OzR 2aewZUghxt7ENRCh110sLqp9RHXP0qtAkgajV43IH8gkh30= X-Google-Smtp-Source: APXvYqyKqaozDkTQNmsPN1bMjWMucG7NQz1/PLpk/fDj/uryl40yjeXrsDu+uDVKKtovtJ56nPA/12JjWslMDCtDe40= X-Received: by 2002:a1c:7008:: with SMTP id l8mr9927014wmc.63.1553496794858; Sun, 24 Mar 2019 23:53:14 -0700 (PDT) MIME-Version: 1.0 References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> <3D7C33C9-CB86-4965-899D-93C4B7343DF7@tzi.org> <640708E8-F80E-49EE-9AEF-DA8DAEE3AA57@tzi.org> <5D0AEDAC-4AD2-4DFD-BF19-EA210773EF66@tzi.org> In-Reply-To: <5D0AEDAC-4AD2-4DFD-BF19-EA210773EF66@tzi.org> From: ivaylo petrov Date: Mon, 25 Mar 2019 07:52:47 +0100 Message-ID: To: Carsten Bormann Cc: Andy Bierman , "netconf@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009e17290584e5a821" Archived-At: Subject: Re: [netconf] [core] YANG encoding in CBOR 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, 25 Mar 2019 06:53:20 -0000 --0000000000009e17290584e5a821 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, On Mon, Mar 25, 2019 at 7:23 AM Carsten Bormann wrote: > Hi Andy, > > > On Sun, Mar 24, 2019 at 3:24 PM Carsten Bormann wrote: > > On Mar 24, 2019, at 12:29, Andy Bierman wrote: > > > > > > The answer seems to be simple but inefficient: > > > Always encode bits or enumeration as a string, if this is within a > union type. > > > > For enum values within unions (which are already handled specially by > giving them a CBOR tag) we could simply use a SID (that we then would hav= e > to generate for each enum value) instead of a string. We could also exte= nd > this to enums outside unions; but here the recurrence to the (outside > unions unambiguous) value sounds better to me. > > > > Bits. Oh. Same procedure, I=E2=80=99d say. > > > > On Mar 24, 2019, at 23:52, Andy Bierman wrote: > > > > This seems like it would make the SID file very complicated. > > Not necessarily: > > > Not sure it would work since leaf/leaf-list can define their own types. > > Plus, all the enum typedefs would have to be numbered this way. > > Right! > It would amount to defining an identifier scheme for all the so far > anonymous enums (and bits defs, I gather). > > > Maybe the SID authors can comment on how this would be done. > > Well, such an identifier scheme would benefit the whole YANG ecosystem, s= o > you can have a transition from =E2=80=9Cfirst match wins=E2=80=9D to prop= er name > equivalence. So we would need to do it in a way that over time it can > become part of the core YANG definition. > > We can maybe cheat: Use strings for enums inside unions for now, and > values only outside. > But it would be good if the SID files generated (and registered) for a > YANG module already had those enum/bits type identifiers so we only have = to > do the SID generation once, so I=E2=80=99m not sure if I like cheating; d= oing the > SIDs for those identifiers right from the outset would win so much more. > > [IP]: Carsten, your idea for the good solution would be to keep the way enum values are sent now outside of unions and only send the SIDs inside unions, is that correct? If so, this sounds as a very good solution to me. It might add a bit of complexity in the SID generation, but I would expect it to be rather small. > So does anyone have an idea how such an identifier scheme might look like= ? > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core Best regards, Ivaylo Petrov --0000000000009e17290584e5a821 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

<= div class=3D"gmail_default" style=3D"font-family:verdana,sans-serif;color:#= 0b5394">On Mon, Mar 25, 2019 at 7:23 AM Carsten Bormann <cabo@tzi.org> wrote:
Hi And= y,

> On Sun, Mar 24, 2019 at 3:24 PM Carsten Bormann <cabo@tzi.org> wrote:
> On Mar 24, 2019, at 12:29, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > The answer seems to be simple but inefficient:
> > Always encode bits or enumeration as a string, if this is within = a union type.
>
> For enum values within unions (which are already handled specially by = giving them a CBOR tag) we could simply use a SID (that we then would have = to generate for each enum value) instead of a string.=C2=A0 We could also e= xtend this to enums outside unions; but here the recurrence to the (outside= unions unambiguous) value sounds better to me.
>
> Bits.=C2=A0 Oh.=C2=A0 Same procedure, I=E2=80=99d say.


> On Mar 24, 2019, at 23:52, Andy Bierman <andy@yumaworks.com> wrote:
>
> This seems like it would make the SID file very complicated.

Not necessarily:

> Not sure it would work since leaf/leaf-list can define their own types= .
> Plus, all the enum typedefs would have to be numbered this way.

Right!
It would amount to defining an identifier scheme for all the so far anonymo= us enums (and bits defs, I gather).

> Maybe the SID authors can comment on how this would be done.

Well, such an identifier scheme would benefit the whole YANG ecosystem, so = you can have a transition from =E2=80=9Cfirst match wins=E2=80=9D to proper= name equivalence.=C2=A0 So we would need to do it in a way that over time = it can become part of the core YANG definition.

We can maybe cheat:=C2=A0 Use strings for enums inside unions for now, and = values only outside.
But it would be good if the SID files generated (and registered) for a YANG= module already had those enum/bits type identifiers so we only have to do = the SID generation once, so I=E2=80=99m not sure if I like cheating; doing = the SIDs for those identifiers right from the outset would win so much more= .


[IP]: Carst= en, your idea for the good solution would be to keep the way enum values ar= e sent now outside of unions and only send the SIDs inside unions, is that = correct? If so, this sounds as a very good solution to me. It might add a b= it of complexity in the SID generation, but I would expect it to be rather = small.
=C2=A0
So does anyone have an idea how such an identifier scheme might look like?<= br>
Gr=C3=BC=C3=9Fe, Carsten

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

Best regards,
Ivaylo P= etrov
--0000000000009e17290584e5a821-- From nobody Mon Mar 25 00:31:40 2019 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 64AC1120365 for ; Mon, 25 Mar 2019 00:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3sU2cHaf5oA for ; Mon, 25 Mar 2019 00:31:37 -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 7E5A3120353 for ; Mon, 25 Mar 2019 00:31:37 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 97D6FB444FFBBA857B38 for ; Mon, 25 Mar 2019 07:31:35 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 25 Mar 2019 07:31:34 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0415.000; Mon, 25 Mar 2019 15:31:28 +0800 From: Qin Wu To: Kent Watsen , "netconf@ietf.org" Thread-Topic: [netconf] kw review of draft-wu-netconf-nmda-compatibility-01 Thread-Index: AdTi2WPmHoXJG37JTtqNbXFc5cXG9A== Date: Mon, 25 Mar 2019 07:31: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.220.69.235] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA4874F81nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] kw review of draft-wu-netconf-nmda-compatibility-01 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, 25 Mar 2019 07:31:39 -0000 --_000_B8F9A780D330094D99AF023C5877DABAA4874F81nkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 5Y+R5Lu25Lq6OiBuZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSDku6Po oaggS2VudCBXYXRzZW4NCuWPkemAgeaXtumXtDogMjAxOeW5tDPmnIgyNeaXpSAxMzoyOQ0K5pS2 5Lu25Lq6OiBuZXRjb25mQGlldGYub3JnDQrkuLvpopg6IFtuZXRjb25mXSBrdyByZXZpZXcgb2Yg ZHJhZnQtd3UtbmV0Y29uZi1ubWRhLWNvbXBhdGliaWxpdHktMDENCg0KDQpJIHN0YXJ0ZWQgcmVh ZGluZyB0aGlzIGRvY3VtZW50LCBidXQgc3RydWdnbGVkIHdpdGggdGhpcyBzZW50ZW5jZSBpbiB0 aGUgSW50cm9kdWN0aW9uOg0KDQoNCuKAnE5NREEgVHJhbnNpdGlvbiBHdWlkZWxpbmVzIGluIHNl Y3Rpb24gNC4yMy4zIG9mIFtSRkM4NDA3XTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj ODQwNyNzZWN0aW9uLTQuMjMuMz4gPHNuaXAvPiBkb2Vzbid0IHByb3ZpZGUgZ3VpZGVsaW5lcyBv biB3aGV0aGVyIGV4aXN0aW5nIE5FVENPTkYgcHJvdG9jb2wgb3BlcmF0aW9ucyBzdWNoIGFzIGdl dC9nZXQtY29uZmlnL2VkaXQtY29uZmlnIGNoYW5nZSBzZW1hbnRpY3Mgd2hlbiB0aGV5IGFyZSBl eGNoYW5nZWQgYmV0d2VlbiB0aGUgbm9uIE5NREEgY2xpZW50IGFuZCB0aGUgTk1EQSBhd2FyZSAg c2VydmVyLuKAnQ0KDQoNCg0KQ29ycmVjdCwgbm8gc3RhdGVtZW50cyBhcmUgbWFkZSAoaGVyZSBv ciBpbiBSRkMgODUyNiksIGJlY2F1c2Ugbm8gY2hhbmdlcyBleGlzdC4gIFJGQyA2MjQxIGlzIHVu Y2hhbmdlZCBieSBSRkMgODUyNi4NCg0KW1Fpbl06IE5vIGludGVudGlvbiB0byBjaGFuZ2UgZXhp c3RpbmcgcHJvdG9jb2wgb3BlcmF0aW9uLCBidXQgd2UgYmVsaWV2ZSBjbGFyaWZpY2F0aW9uIG9u IHByb3RvY29sIGJlaGF2aW9yIGlzIG5lZWRlZCBvciBhZGRpdGlvbmFsIGJlaGF2aW9yIG5lZWRz IHRvIGJlIGNvbnNpZGVyZWQgc2luY2UgY29leGlzdGluZyBOTURBIGNsaWVudCBhbmQgTm9uLU5N REEgY2xpZW50IHRvIGNvbW11bmljYXRlIHdpdGggTk1EQSBzZXJ2ZXIgZG9lcyBleGlzdC4NCg0K DQpUaGUgZHJhZnQgYWxzbyBoYXMgdGhpcyBzdGF0ZW1lbnQgaW4gdGhlIFByb2JsZW1zIHNlY3Rp b246DQoNCuKAnFdoZW4gYSBzZXJ2ZXIgaXMgdXBncmFkZWQgdG8gTk1EQSBhd2FyZSBzZXJ2ZXIg YW5kIG5lZWRzIHRvIHN1cHBvcnQNCg0KYm90aCBOTURBIGNsaWVudCBhbmQgbm9uLU5NREEgY2xp ZW50cywgdGhlcmUgaXMgbm8gc3RhbmRhcmRzLWJhc2VkIHdheSBmb3IgdGhlIHNlcnZlciB0byBr bm93IHdoZXRoZXIgdGhlIGNsaWVudCBzdXBwb3J0cyBOTURBLuKAnQ0KDQoNCg0KVHJ1ZSwgYnV0 IGl0IGRvZXNu4oCZdCBtYXR0ZXIsIGFzIHRoZSBzZXJ2ZXIgb25seSBjYXJlcyBpZiB0aGUgY2xp ZW50IHVzZXMgdGhlIFJQQyBmcm9tIFJGQyA2MjQxIG9yIFJGQyA4NTI2Lg0KDQpbUWluXTpFeGFj dGx5LCB3ZSBiZWxpZXZlIHdlIGNhbiB1c2UgUlBDIGZyb20gUkZDNjI0MSBvciBSRkM4NTI2IHRv IGRpc3Rpbmd1aXNoIHRoZSBSUEMgcmVxdWVzdCBpcyBzZW50IGZyb20gTk1EQSBjbGllbnQgb3Ig bm9uLU5NREEgY2xpZW50Lg0KDQpJbiBvcmRlciB0byBtYWludGFpbiBiYWNrd2FyZHMgY29tcGF0 aWJpbGl0eSwgdGhlcmUgYXJlICpubyogY2hhbmdlcyB0byBSRkMgNjI0MS4gICBJdCBpcyBhbiBp bXBsZW1lbnRhdGlvbiBpc3N1ZSBmb3IgdGhlIE5NREEtYXdhcmUgc2VydmVyIHRvIG1haW50YWlu IHN1cHBvcnQgZm9yIHRoZSBub24tTk1EQSBhd2FyZSBSUENzLg0KDQpbUWluXTogSSBzdGlsbCBo YXZlIG1pc2NvbmNlcHRpb24gdG8gbWFpbnRhaW4gcHJvdG9jb2wgYmFja3dhcmQgY29tcGF0aWJp bGl0eSwgZS5nLiwgZGVmYXVsdCBjb25maWcsIHN5c3RlbSBjb25maWcsIHdoZXJlIGRvZXMgdGhl c2UgY29uZmlnIGRhdGEgc2F2ZWQ/IDxydW5uaW5nPj8NCg0KQWZ0ZXIgTk1EQSBpcyBpbnRyb2R1 Y2VkLCB0aGVzZSBjb25maWcgZGF0YSBzZWVtcyB0byBtb3ZlZCB0byA8b3BlcmF0aW9uYWw+PyBD b3JyZWN0LCBiYXNlZCBvbiBSRkM2MjQxLCBpdCBzZWVtcyB0byBpbmRpY2F0ZSBkZWZhdWx0IGNv bmZpZyBpcyBwYXJ0IG9mIDxydW5uaW5nPiwgYnV0IGZvciBzeXN0ZW0gY29uZmlnLCB3aGljaCBk YXRhc3RvcmUgIGlzIGl0IHNhdmVkIHdpdGhpbiBORVRDT05GIHNlcnZlcj8gSXQgaXMgdW5zcGVj aWZpZWQuIGlmIHRoaXMgaXMgdHJ1ZSwgdG8gbWFpbnRhaW4gYmFja3dhcmQgY29tcGF0aWJpbGl0 eSwgdGhlIGN1cnJlbnQgTk1EQSBOQyBzcGVjIGRvZXNu4oCZdCB0ZWxsIHVzIGhvdyB0byBoYW5k bGUgdGhlc2UgY29uZmlnIGRhdGEgcmVsb2NhdGlvbiwNCg0KU2hvdWxkIHRoaXMgY29uZmlnIGRh dGEgcmVsb2NhdGlvbiBiZSBhd2FyZSBvZiBOb24gTk1EQSBDbGllbnQgb3Igbm90Pw0KDQpGV0lX LCB0aGUgZHJhZnQgYWxzbyBoYXMgc3VnZ2VzdGlvbnMgZm9yIGNsYXJpZnlpbmcgTk1EQSBiZWhh dmlvciAoZS5nLiwgd2l0aC1kZWZhdWx0cyksIHdoaWNoIG1heSBiZSBuZWVkZWQsIGJ1dCBJIGRp ZG7igJl0IGRpZyBpbnRvIHRoZXNlIHN1Z2dlc3Rpb25zIGFzIEkgd2FudCB0byBmaXJzdCBlbnN1 cmUgbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQuDQoNCltRaW5dOlll cywgdGhpcyBpcyBpbnRlbnRpb24uIFdlIHdhbnQgdG8gYWRkcmVzcyBOTURBIGltcGxlbWVudGF0 aW9uIGFtYmlndWl0eSBpc3N1ZXMuDQoNCg0KDQpUaGFua3MsDQoNCktlbnQgLy8gY29udHJpYnV0 b3INCg0KDQo= --_000_B8F9A780D330094D99AF023C5877DABAA4874F81nkgeml513mbxchi_ 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 aWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMgMiAyIDQgMiAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAg MyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpVSUNURm9udFRleHRTdHls ZUJvZHk7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw cmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiu vuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkhUTUxDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+ 5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v 6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPiBuZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2Vz QGlldGYub3JnXQ0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7ku6PooaggPC9zcGFu Pg0KPC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+S2VudCBXYXRzZW48YnI+ DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9 IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNl cmlmIj4gMjAxOTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5bm0PHNwYW4gbGFuZz0iRU4t VVMiPjM8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjI1PC9zcGFuPuaXpTxzcGFuIGxhbmc9 IkVOLVVTIj4NCiAxMzoyOTxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1V UyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBuZXRjb25mQGlldGYub3JnPGJyPg0K PC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyI+IFtuZXRjb25mXSBrdyByZXZpZXcgb2YgZHJhZnQtd3UtbmV0Y29uZi1ubWRhLWNv bXBhdGliaWxpdHktMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+SSBzdGFydGVkIHJlYWRpbmcgdGhpcyBkb2N1bWVudCwgYnV0IHN0cnVnZ2xl ZCB3aXRoIHRoaXMgc2VudGVuY2UgaW4gdGhlIEludHJvZHVjdGlvbjo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9ImJy ZWFrLWJlZm9yZTogcGFnZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssc2VyaWYiPuKAnE5NREEgVHJhbnNpdGlv biBHdWlkZWxpbmVzIGluIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4 NDA3I3NlY3Rpb24tNC4yMy4zIj5zZWN0aW9uJm5ic3A7NC4yMy4zIG9mIFtSRkM4NDA3XTwvYT4g Jmx0O3NuaXAvJmd0OyBkb2Vzbid0IHByb3ZpZGUgZ3VpZGVsaW5lcyBvbiB3aGV0aGVyIGV4aXN0 aW5nIE5FVENPTkYgcHJvdG9jb2wgb3BlcmF0aW9ucyBzdWNoIGFzIGdldC9nZXQtY29uZmlnL2Vk aXQtY29uZmlnIGNoYW5nZSBzZW1hbnRpY3Mgd2hlbiB0aGV5IGFyZSBleGNoYW5nZWQgYmV0d2Vl biB0aGUgbm9uIE5NREEgY2xpZW50IGFuZCB0aGUgTk1EQSBhd2FyZSZuYnNwOyZuYnNwO3NlcnZl ci7igJ08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOiBwYWdlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OyxzZXJpZiI+PGJy Pjxicj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssc2VyaWYiPkNvcnJlY3Qs IG5vIHN0YXRlbWVudHMgYXJlIG1hZGUgKGhlcmUgb3IgaW4gUkZDIDg1MjYpLCBiZWNhdXNlIG5v IGNoYW5nZXMgZXhpc3QuICZuYnNwO1JGQyA2MjQxIGlzIHVuY2hhbmdlZCBieSBSRkMgODUyNi4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOiBwYWdlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPltRaW5dOiBObyBpbnRlbnRpb24gdG8gY2hhbmdlIGV4aXN0aW5nIHBy b3RvY29sIG9wZXJhdGlvbiwgYnV0IHdlIGJlbGlldmUgY2xhcmlmaWNhdGlvbiBvbiBwcm90b2Nv bCBiZWhhdmlvciBpcyBuZWVkZWQgb3IgYWRkaXRpb25hbCBiZWhhdmlvciBuZWVkcyB0byBiZSBj b25zaWRlcmVkIHNpbmNlIGNvZXhpc3RpbmcgTk1EQSBjbGllbnQgYW5kIE5vbi1OTURBIGNsaWVu dCB0byBjb21tdW5pY2F0ZSB3aXRoIE5NREEgc2VydmVyIGRvZXMgZXhpc3QuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVC b2R5JnF1b3Q7LHNlcmlmIj48YnI+PGJyPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6IHBhZ2UiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVC b2R5JnF1b3Q7LHNlcmlmIj5UaGUgZHJhZnQgYWxzbyBoYXMgdGhpcyBzdGF0ZW1lbnQgaW4gdGhl IFByb2JsZW1zIHNlY3Rpb246PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+4oCcV2hlbiBhIHNlcnZlciBp cyB1cGdyYWRlZCB0byBOTURBIGF3YXJlIHNlcnZlciBhbmQgbmVlZHMgdG8gc3VwcG9ydDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssc2VyaWYiPmJvdGggTk1EQSBj bGllbnQgYW5kIG5vbi1OTURBIGNsaWVudHMsIHRoZXJlIGlzIG5vIHN0YW5kYXJkcy1iYXNlZCB3 YXkgZm9yIHRoZSBzZXJ2ZXIgdG8ga25vdyB3aGV0aGVyIHRoZSBjbGllbnQgc3VwcG9ydHMgTk1E QS7igJ08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOiBwYWdlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OyxzZXJpZiI+PGJy Pjxicj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOiBwYWdlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OyxzZXJpZiI+VHJ1 ZSwgYnV0IGl0IGRvZXNu4oCZdCBtYXR0ZXIsIGFzIHRoZSBzZXJ2ZXIgb25seSBjYXJlcyBpZiB0 aGUgY2xpZW50IHVzZXMgdGhlIFJQQyBmcm9tIFJGQyA2MjQxIG9yIFJGQyA4NTI2LiAmbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBz dHlsZT0iYnJlYWstYmVmb3JlOiBwYWdlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPltRaW5dOkV4YWN0bHksIHdlIGJlbGlldmUgd2UgY2FuIHVzZSBSUEMgZnJvbSBS RkM2MjQxIG9yIFJGQzg1MjYgdG8gZGlzdGluZ3Vpc2ggdGhlIFJQQyByZXF1ZXN0IGlzIHNlbnQg ZnJvbSBOTURBIGNsaWVudCBvciBub24tTk1EQSBjbGllbnQuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTog cGFnZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNURm9u dFRleHRTdHlsZUJvZHkmcXVvdDssc2VyaWYiPkluIG9yZGVyIHRvIG1haW50YWluIGJhY2t3YXJk cyBjb21wYXRpYmlsaXR5LCZuYnNwO3RoZXJlIGFyZSAqbm8qIGNoYW5nZXMgdG8gUkZDIDYyNDEu ICZuYnNwOyZuYnNwO0l0IGlzIGFuIGltcGxlbWVudGF0aW9uIGlzc3VlIGZvciB0aGUgTk1EQS1h d2FyZSBzZXJ2ZXIgdG8gbWFpbnRhaW4gc3VwcG9ydCBmb3IgdGhlIG5vbi1OTURBIGF3YXJlIFJQ Q3MuICZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6IHBhZ2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+W1Fpbl06IEkgc3RpbGwgaGF2ZSBtaXNjb25jZXB0aW9uIHRv IG1haW50YWluIHByb3RvY29sIGJhY2t3YXJkIGNvbXBhdGliaWxpdHksIGUuZy4sIGRlZmF1bHQg Y29uZmlnLCBzeXN0ZW0gY29uZmlnLCB3aGVyZSBkb2VzIHRoZXNlIGNvbmZpZyBkYXRhIHNhdmVk PyAmbHQ7cnVubmluZyZndDs/PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QWZ0ZXIgTk1EQSBpcyBpbnRyb2R1 Y2VkLCB0aGVzZSBjb25maWcgZGF0YSBzZWVtcyB0byBtb3ZlZCB0byAmbHQ7b3BlcmF0aW9uYWwm Z3Q7PyBDb3JyZWN0LCBiYXNlZCBvbiBSRkM2MjQxLCBpdCBzZWVtcyB0byBpbmRpY2F0ZSBkZWZh dWx0IGNvbmZpZyBpcyBwYXJ0IG9mICZsdDtydW5uaW5nJmd0OywgYnV0IGZvciBzeXN0ZW0gY29u ZmlnLCB3aGljaCBkYXRhc3RvcmUgJm5ic3A7aXMgaXQgc2F2ZWQgd2l0aGluIE5FVENPTkYgc2Vy dmVyPyBJdCBpcyB1bnNwZWNpZmllZC4gaWYgdGhpcyBpcyB0cnVlLCB0byBtYWludGFpbiBiYWNr d2FyZCBjb21wYXRpYmlsaXR5LCB0aGUgY3VycmVudCBOTURBIE5DIHNwZWMgZG9lc27igJl0IHRl bGwgdXMgaG93IHRvIGhhbmRsZSB0aGVzZSBjb25maWcgZGF0YSByZWxvY2F0aW9uLDxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlNob3VsZCB0aGlzIGNvbmZpZyBkYXRhIHJlbG9jYXRpb24gYmUgYXdhcmUgb2Yg Tm9uIE5NREEgQ2xpZW50IG9yIG5vdD88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5 bGU9ImJyZWFrLWJlZm9yZTogcGFnZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssc2VyaWYiPkZXSVcsIHRoZSBk cmFmdCBhbHNvIGhhcyBzdWdnZXN0aW9ucyBmb3IgY2xhcmlmeWluZyBOTURBIGJlaGF2aW9yIChl LmcuLCB3aXRoLWRlZmF1bHRzKSwgd2hpY2ggbWF5IGJlIG5lZWRlZCwgYnV0IEkgZGlkbuKAmXQg ZGlnIGludG8gdGhlc2Ugc3VnZ2VzdGlvbnMgYXMgSSB3YW50IHRvIGZpcnN0IGVuc3VyZSBteSB1 bmRlcnN0YW5kaW5nIG9mIHRoZSBwcm9ibGVtIHN0YXRlbWVudC4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iYnJlYWst YmVmb3JlOiBwYWdlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltR aW5dOlllcywgdGhpcyBpcyBpbnRlbnRpb24uIFdlIHdhbnQgdG8gYWRkcmVzcyBOTURBIGltcGxl bWVudGF0aW9uIGFtYmlndWl0eSBpc3N1ZXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTogcGFnZSI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls ZT0iYnJlYWstYmVmb3JlOiBwYWdlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OyxzZXJpZiI+VGhhbmtzLCZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJicmVhay1iZWZvcmU6IHBhZ2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LHNlcmlmIj5LZW50IC8v IGNvbnRyaWJ1dG9yPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTogcGFnZSI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_B8F9A780D330094D99AF023C5877DABAA4874F81nkgeml513mbxchi_-- From nobody Mon Mar 25 00:53:47 2019 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 34575120373; Mon, 25 Mar 2019 00:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 RlRFp4zCH9JS; Mon, 25 Mar 2019 00:53:33 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 081D81203C5; Mon, 25 Mar 2019 00:53:33 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44SRMt6wVtz10fS; Mon, 25 Mar 2019 08:53:30 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <5D0AEDAC-4AD2-4DFD-BF19-EA210773EF66@tzi.org> Date: Mon, 25 Mar 2019 08:53:35 +0100 Cc: "netconf@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 575193213.31462-92804bf67652a0f2903a58c87e29ee27 Content-Transfer-Encoding: quoted-printable Message-Id: <5774A58B-6CEC-4969-8C31-D4BDAE600D69@tzi.org> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> <3D7C33C9-CB86-4965-899D-93C4B7343DF7@tzi.org> <640708E8-F80E-49EE-9AEF-DA8DAEE3AA57@tzi.org> <5D0AEDAC-4AD2-4DFD-BF19-EA210773EF66@tzi.org> To: Andy Bierman X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netconf] [core] YANG encoding in CBOR 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, 25 Mar 2019 07:53:40 -0000 On Mar 25, 2019, at 07:23, Carsten Bormann wrote: >=20 > We can maybe cheat: Use strings for enums inside unions for now, and = values only outside. Or, if it takes too long to do the identifier scheme: We could define SIDs for each module for the enum and bits strings used = in that module. That would mean we=E2=80=99d have multiple SIDs for the same strings all = over the YANG universe, but it is something we don=E2=80=99t have to = wait for and can do locally. So a decoder knowing the module at all would also know what string to = imagine (it never has to be reified!) for that SID. An encoder has a = slightly harder time, as it has to use a SID from a module the decoder = will know; I=E2=80=99d imagine that won=E2=80=99t be too hard to glean = from the context though. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Mar 25 00:58:02 2019 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 6FF2F12025C; Mon, 25 Mar 2019 00:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 e2lZBHeSW-h1; Mon, 25 Mar 2019 00:57:58 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC3D120370; Mon, 25 Mar 2019 00:57:57 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44SRT01N79z13cY; Mon, 25 Mar 2019 08:57:56 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Mon, 25 Mar 2019 08:57:55 +0100 Cc: Andy Bierman , "netconf@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 575193472.169531-a1e767f94b0f600a97b0c3815ca0b763 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> <3D7C33C9-CB86-4965-899D-93C4B7343DF7@tzi.org> <640708E8-F80E-49EE-9AEF-DA8DAEE3AA57@tzi.org> <5D0AEDAC-4AD2-4DFD-BF19-EA210773EF66@tzi.org> To: ivaylo petrov X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netconf] [core] YANG encoding in CBOR 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, 25 Mar 2019 07:58:00 -0000 On Mar 25, 2019, at 07:52, ivaylo petrov wrote: >=20 > [IP]: Carsten, your idea for the good solution would be to keep the = way enum values are sent now outside of unions and only send the SIDs = inside unions, is that correct? Yes, as most enums occur outside unions, so good design principles say = the cost of the feature of unions of enums should only be paid by those = who actually use them. > If so, this sounds as a very good solution to me. It might add a bit = of complexity in the SID generation, but I would expect it to be rather = small. I think we need to make a few examples to check out how that would look = like. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Mar 25 01:07:04 2019 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 B9979120370; Mon, 25 Mar 2019 01:06:56 -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] 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 8ymlrML5U9rm; Mon, 25 Mar 2019 01:06:54 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8D41D120365; Mon, 25 Mar 2019 01:06:53 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 903AF18204C5; Mon, 25 Mar 2019 09:06:35 +0100 (CET) Received: from localhost (dhcp-82e3.meeting.ietf.org [31.133.130.227]) by trail.lhotka.name (Postfix) with ESMTPSA id E58671820047; Mon, 25 Mar 2019 09:06:18 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder , Carsten Bormann Cc: Michel Veillette , "netconf\@ietf.org" , "core\@ietf.org" In-Reply-To: <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> Date: Mon, 25 Mar 2019 09:06:33 +0100 Message-ID: <871s2vqsxi.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 25 Mar 2019 08:06:57 -0000 Juergen Schoenwaelder writes: > I think we need to look at the whole picture and in which direction we > want to go. In the longer term, I would prefer a solution where the > values of a union are discriminated. The current XML encoding > behaviour of 'first match wins' is fragile (for example, if someone > adds an enum to a type, the interpretation of data can change). > > Look at this: > > typedef bar { > type union { > type enumeration { enum "1"; value 2; enum "2"; value 1; } > type uint8; > } > } > > We have some encodings that send the string representations of the > values and some encodings that prefer to send numeric representations > where possible. In order to have a robust solution, encodings should > likely indicate to which type the value belongs. Perhaps the easiest way would be to use (optional) annotation that specifies, using an ordinal number, which of the member types is used for the particular instance. But since there can be unions inside unions, a list of numbers would be needed in general. Lada > > /js > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: >> Well, if that is a problem, we can go for a longer representation within= unions (section 6.12). Theoretically, we could do that only of there is m= ore than one enum in the union type (so things stay efficient if there is o= nly one), but that might pose difficulties with model evolution. >>=20 >> Going for a string representation repeats the feature of XML YANG (which= was ported over to JSON YANG): >>=20 >> typedef foo { >> type union { >> type enumeration { >> enum red { value 1; } >> enum breen { value 2; } >> enum glue { value 3; } >> } >> type enumeration { >> enum tacks { value 1; } >> enum nails { value 2; } >> enum glue { value 3; } >> } >> } >> } >>=20 >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of the e= numerations are being used. >>=20 >> Using SIDs, we can do better. >>=20 >> So what do we have to do to get the SID tool to allocate SIDs for enum v= alues? >>=20 >> We could then define the CBOR tag for enums in unions to take the usual = SID difference (delta relative to the environment, I=E2=80=99d think), not = an integer value. >>=20 >> Several of us are at the hackathon and could make something happen today= and tomorrow. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >> > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) wr= ote: >> >=20 >> > I guess that the concern is that this introduces more variation in how= data is interpreted between the different XML/JSON/CBOR encodings. >> >=20 >> > E.g. if someone switched from XML to CBOR, suddenly the configuration = or state data may have a different meaning. >> >=20 >> > Thanks, >> > Rob >> >=20 >> >=20 >> >> -----Original Message----- >> >> From: Carsten Bormann >> >> Sent: 22 March 2019 16:08 >> >> To: Michel Veillette >> >> Cc: Rob Wilton (rwilton) ; core@ietf.org; >> >> netconf@ietf.org >> >> Subject: Re: [netconf] YANG encoding in CBOR >> >>=20 >> >> On Mar 22, 2019, at 16:45, Michel Veillette >> >> wrote: >> >>>=20 >> >>> The only potential problem I aware is when multiple enumerations are= part of >> >> the same union. >> >>> Value 4 from enumeration A will be encoded the same way as Value 4 f= rom >> >> enumeration B. >> >>=20 >> >> =E2=80=A6 and that is not a problem for the XML version, because the = string is being used >> >> instead of the value. (But then if two enumerations share a string, = you have the >> >> equivalent problem in the XML serialization.) >> >>=20 >> >> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that actual= ly has this >> >> problem, so I would be a bit reluctant to make CBOR-based implementat= ions >> >> more complex (and less efficient) so solve this (non-?)problem. >> >>=20 >> >> Gr=C3=BC=C3=9Fe, Carsten >> >=20 >> >=20 >> >=20 >>=20 >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: >> Well, if that is a problem, we can go for a longer representation within= unions (section 6.12). Theoretically, we could do that only of there is m= ore than one enum in the union type (so things stay efficient if there is o= nly one), but that might pose difficulties with model evolution. >>=20 >> Going for a string representation repeats the feature of XML YANG (which= was ported over to JSON YANG): >>=20 >> typedef foo { >> type union { >> type enumeration { >> enum red { value 1; } >> enum breen { value 2; } >> enum glue { value 3; } >> } >> type enumeration { >> enum tacks { value 1; } >> enum nails { value 2; } >> enum glue { value 3; } >> } >> } >> } >>=20 >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of the e= numerations are being used. >>=20 >> Using SIDs, we can do better. >>=20 >> So what do we have to do to get the SID tool to allocate SIDs for enum v= alues? >>=20 >> We could then define the CBOR tag for enums in unions to take the usual = SID difference (delta relative to the environment, I=E2=80=99d think), not = an integer value. >>=20 >> Several of us are at the hackathon and could make something happen today= and tomorrow. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >> > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) wr= ote: >> >=20 >> > I guess that the concern is that this introduces more variation in how= data is interpreted between the different XML/JSON/CBOR encodings. >> >=20 >> > E.g. if someone switched from XML to CBOR, suddenly the configuration = or state data may have a different meaning. >> >=20 >> > Thanks, >> > Rob >> >=20 >> >=20 >> >> -----Original Message----- >> >> From: Carsten Bormann >> >> Sent: 22 March 2019 16:08 >> >> To: Michel Veillette >> >> Cc: Rob Wilton (rwilton) ; core@ietf.org; >> >> netconf@ietf.org >> >> Subject: Re: [netconf] YANG encoding in CBOR >> >>=20 >> >> On Mar 22, 2019, at 16:45, Michel Veillette >> >> wrote: >> >>>=20 >> >>> The only potential problem I aware is when multiple enumerations are= part of >> >> the same union. >> >>> Value 4 from enumeration A will be encoded the same way as Value 4 f= rom >> >> enumeration B. >> >>=20 >> >> =E2=80=A6 and that is not a problem for the XML version, because the = string is being used >> >> instead of the value. (But then if two enumerations share a string, = you have the >> >> equivalent problem in the XML serialization.) >> >>=20 >> >> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that actual= ly has this >> >> problem, so I would be a bit reluctant to make CBOR-based implementat= ions >> >> more complex (and less efficient) so solve this (non-?)problem. >> >>=20 >> >> Gr=C3=BC=C3=9Fe, Carsten >> >=20 >> >=20 >> >=20 >>=20 >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Mar 25 01:13:05 2019 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 6C5EF120379; Mon, 25 Mar 2019 01:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 Fg4uzpY_qQOm; Mon, 25 Mar 2019 01:12:56 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BFB912039D; Mon, 25 Mar 2019 01:12:56 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44SRpG2JvHzybw; Mon, 25 Mar 2019 09:12:54 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <871s2vqsxi.fsf@nic.cz> Date: Mon, 25 Mar 2019 09:12:53 +0100 Cc: Juergen Schoenwaelder , Michel Veillette , "netconf@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 575194371.287631-8b6bceeb2497f787752a48fea9763ca6 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 25 Mar 2019 08:13:04 -0000 On Mar 25, 2019, at 09:06, Ladislav Lhotka wrote: >=20 > Perhaps the easiest way would be to use (optional) annotation that > specifies, using an ordinal number, which of the member types is used > for the particular instance. But since there can be unions inside > unions, a list of numbers would be needed in general. Is the sequential number of the alternative supposed to be =E2=80=9Cstable= =E2=80=9D? (I.e., would there be confusion if an alternative is inserted in the = middle? Which you may want to do while we still do =E2=80=9Cfirst match = wins=E2=80=9D.) If yes, a list of those numbers may indeed be sufficient to always stay = with values for CBOR. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Mar 25 01:23:06 2019 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 493C5120372 for ; Mon, 25 Mar 2019 01:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 yaZ48Xngrcq2 for ; Mon, 25 Mar 2019 01:23:02 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 18B9B120368 for ; Mon, 25 Mar 2019 01:23:02 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id w10so8981846wrm.4 for ; Mon, 25 Mar 2019 01:23:01 -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=jBc7uCLfYETXRvDR3x0uwVXGePqXXnHslwEUONVbkoY=; b=Cyp2IHcjHQgl2vFFuLdSwsAhXmBejXScEsRMjYGHoc/oekFMQeEDPopQTYm10c2dDS V3w/A2H0V4pzsu4SRxXOxH1tSP6xPipjGg3gscv5knr9Ywmsh/qZlbGkOUwbvTpXWmYI 20pyB1t4LFU54rdn30cd4m1X7B4fdw9J63PFPTraccqqR3ARyr/KjyyEbJUQnVFk/bEH okh2jpK21FxmkYybK4YqH+oSIjx3gBsj/aPx2HxJcZA603Qqr61AR+291K9BVpFYGaip atpAKo/jl7dhTA9aUgsQydHOauoqp4rOhua3fHcI5FwSY6ODwVPKXJkRqNawyh1U5A8X gkJA== 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=jBc7uCLfYETXRvDR3x0uwVXGePqXXnHslwEUONVbkoY=; b=NFkvCjfLd7vHXw1HPn4aKOQiqdJ+YYZHzj14VSROD+RRsPaEY72xx82f47yQP8CHqD y82p7by1bt5jaANOt3K0nekz0AnD0iriox75t2HaRxZUn9o8903WtodIDysfF+I9HxD7 XheyScW73EkfrU/t1STBvAqyKsIszoeNMHUxmSSk5Ebu3QAjhOfGloCaky0jH+Tslx8y 9tDKnNLJ9KbbeXkOh3qBUyEUngyru7EnRDDVzYL5+AMNgN/MfqvrFk2VlNr9BJSRzvh0 kdcKPtnJK3SOoYF7nyFJU4NBkN9KiLglzZA+RxRSuUyra8krFRQ9Id3JQ5/jiQq0UV1B 7pXw== X-Gm-Message-State: APjAAAXUIOeoFSBcizFG7mz6tD7+ZQal0KRXmJo9Ui5kRXX6tN/qbt41 xl93SPMEtdTfaCxqC5StNf/6/QyvCY0= X-Google-Smtp-Source: APXvYqyYkmI549gZaLcbT34fFGbQddvLdNX1ENpFQDz9v2H1UfD+Uke91ywnhDWylVRMmF/yw0fAKA== X-Received: by 2002:adf:ea45:: with SMTP id j5mr7429031wrn.89.1553502180345; Mon, 25 Mar 2019 01:23:00 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:8091:dda6:91cc:a802? ([2001:67c:370:128:8091:dda6:91cc:a802]) by smtp.gmail.com with ESMTPSA id a9sm16690911wmb.30.2019.03.25.01.22.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Mar 2019 01:22:59 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_047016C8-1A8C-424A-931B-15DD79904CF8" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <172E9438-FB80-413B-B4FD-49A288978CF0@gmail.com> Date: Mon, 25 Mar 2019 09:22:58 +0100 To: Netconf X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [netconf] Link to etherpad 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, 25 Mar 2019 08:23:04 -0000 --Apple-Mail=_047016C8-1A8C-424A-931B-15DD79904CF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The link to etherpad in the agenda leads you to a new page creation. = Instead use the following link: https://etherpad.tools.ietf.org/p/notes-ietf-104-netconf = Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_047016C8-1A8C-424A-931B-15DD79904CF8 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii The link to etherpad in the agenda leads you to a new page creation. Instead use the following link:



Mahesh Jethanandani



--Apple-Mail=_047016C8-1A8C-424A-931B-15DD79904CF8-- From nobody Mon Mar 25 01:33:00 2019 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 00F4D1203C8; Mon, 25 Mar 2019 01:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 jOiLA_o0pfze; Mon, 25 Mar 2019 01:32:46 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 68B34120395; Mon, 25 Mar 2019 01:30:41 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:67c:370:128:e0e6:7446:b50f:deb9]) by mail.nic.cz (Postfix) with ESMTPSA id A2A2E633D3; Mon, 25 Mar 2019 09:30:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1553502639; bh=MbVdsq8Dbpd2AO3RlZhKCq0R2aLD9/ds8hAH6B0tC/k=; h=From:To:Date; b=RNkD8J+9s1QmrY/hk1aVV5B1OsKrRSStVrQKpNIHlP5mCdQ/XOzWwnNkFyjGYC9c4 m4QfmxOIDWKAd9LwpDCynBCwnz3o25J8c3yrHSIDENUJWAgJoBdAGr933iN9pFKrCO FmtFQmHtQiYgFN04ybdCFVtnDe89MuimgfTQENvY= Message-ID: <44a564649dd1d9b8947483e8a7b94d71ddcbaa51.camel@nic.cz> From: Ladislav Lhotka To: Carsten Bormann Cc: Juergen Schoenwaelder , Michel Veillette , "netconf@ietf.org" , "core@ietf.org" Date: Mon, 25 Mar 2019 09:30:39 +0100 In-Reply-To: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 25 Mar 2019 08:32:54 -0000 Carsten Bormann píše v Po 25. 03. 2019 v 09:12 +0100: > On Mar 25, 2019, at 09:06, Ladislav Lhotka wrote: > > Perhaps the easiest way would be to use (optional) annotation that > > specifies, using an ordinal number, which of the member types is used > > for the particular instance. But since there can be unions inside > > unions, a list of numbers would be needed in general. > > Is the sequential number of the alternative supposed to be “stable”? > (I.e., would there be confusion if an alternative is inserted in the middle? > Which you may want to do while we still do “first match wins”.) Inserting a new member type in the middle also affects the current algorithm for union type resolution, so it is not permitted by the module update rules (sec. 11 in RFC 7950). > > If yes, a list of those numbers may indeed be sufficient to always stay with > values for CBOR. And it is also a solution that works the same for any data representation, as long as it can encode annotations. Lada > > Grüße, Carsten > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Mar 25 01:42:33 2019 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 B7462120365; Mon, 25 Mar 2019 01:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 mXjtyBVnORT3; Mon, 25 Mar 2019 01:42:29 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA91120375; Mon, 25 Mar 2019 01:42:29 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44SSSM3qdSzyVT; Mon, 25 Mar 2019 09:42:27 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <871s2vqsxi.fsf@nic.cz> Date: Mon, 25 Mar 2019 09:42:27 +0100 Cc: Juergen Schoenwaelder , Michel Veillette , "netconf@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 575196145.1692851-255ae6164aeae56d13124db86e6e1293 Content-Transfer-Encoding: quoted-printable Message-Id: <552AC13F-A862-4F72-A6BB-2385A2089194@tzi.org> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 25 Mar 2019 08:42:32 -0000 On Mar 25, 2019, at 09:06, Ladislav Lhotka wrote: >=20 > use (optional) annotation What do I have to read to learn more about YANG annotations? Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Mar 25 01:46:08 2019 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 D91B41203E9; Mon, 25 Mar 2019 01:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 jOy_BQ96vBwi; Mon, 25 Mar 2019 01:45:58 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 890921203C0; Mon, 25 Mar 2019 01:45:57 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:67c:370:128:e0e6:7446:b50f:deb9]) by mail.nic.cz (Postfix) with ESMTPSA id 5D09C6055E; Mon, 25 Mar 2019 09:45:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1553503555; bh=R0tKRbeEg+G13yGNu1lCTmH7wRcfRKgo5GLxfIuFNjE=; h=From:To:Date; b=xYjzkZb1rXK9QkN+E1cpa2cmdbsYMGRGMnqedtGQ4qSL9EK1lFp8EdkB1sVdp7U7t bEfSTErr744erNRvxLRcIbVERJLZTlckf4wX+XlYv9ksyVKAVZeYMm/l0kD15gFrog m6ZOoErnYGmbKZPW1beQ9VgPTjagwb0d9KtwUQKI= Message-ID: <07e6c05a708ed1b8010f3fc69b6dc45da8de83ea.camel@nic.cz> From: Ladislav Lhotka To: Carsten Bormann Cc: Juergen Schoenwaelder , Michel Veillette , "netconf@ietf.org" , "core@ietf.org" Date: Mon, 25 Mar 2019 09:45:55 +0100 In-Reply-To: <552AC13F-A862-4F72-A6BB-2385A2089194@tzi.org> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <552AC13F-A862-4F72-A6BB-2385A2089194@tzi.org> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 25 Mar 2019 08:46:04 -0000 Carsten Bormann píše v Po 25. 03. 2019 v 09:42 +0100: > On Mar 25, 2019, at 09:06, Ladislav Lhotka wrote: > > use (optional) annotation > > What do I have to read to learn more about YANG annotations? RFC 7952. Lada > > Grüße, Carsten > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Mar 25 06:00:56 2019 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 0A9071203EF for ; Mon, 25 Mar 2019 06:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 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, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 MgOZHtx39x1Y for ; Mon, 25 Mar 2019 06:00:52 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on0628.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::628]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 119BE1203E7 for ; Mon, 25 Mar 2019 06:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8LJKPuiK2mVaOn6bh2l/HBhnTt5bu+YEPWw2gw3/V9A=; b=jOqgd2QiruwXcmFKXqg2iviLlbsYXZoapu3NA5faHo9e7+MqRBIwI/kl5d7Q/TjzWt8XYkz9st3TrtDCJoDgSDwcggjXTV3cHaGzuojyGx6zL9b7/vkjvsc/gPTEp/lFVODStR74hu6Jh+BzFuTk+HRhOo0gCFk1eiRhj0mQVRI= Received: from VI1PR07MB4735.eurprd07.prod.outlook.com (20.177.57.146) by VI1PR07MB6176.eurprd07.prod.outlook.com (20.178.9.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.14; Mon, 25 Mar 2019 13:00:49 +0000 Received: from VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::807b:cd48:c48:cf03]) by VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::807b:cd48:c48:cf03%4]) with mapi id 15.20.1750.014; Mon, 25 Mar 2019 13:00:49 +0000 From: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= To: Kent Watsen , tom petch CC: Juergen Schoenwaelder , "netconf@ietf.org" Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpABvbIeAAFYG6nA= Date: Mon, 25 Mar 2019 13:00:49 +0000 Message-ID: References: <20190321152920.jdkny7szk7ik3sp4@anna.jacobs.jacobs-university.de> <00b701d4e0cb$e79e9660$4001a8c0@gateway.2wire.net> <01000169ac01ff08-27f75526-1e78-461a-be8e-9737cf762edf-000000@email.amazonses.com> In-Reply-To: <01000169ac01ff08-27f75526-1e78-461a-be8e-9737cf762edf-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2a02:ab88:2cb8:5600:7166:7f58:c11f:5c24] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8ebdecd8-63fa-41be-7040-08d6b121e7a5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB6176; x-ms-traffictypediagnostic: VI1PR07MB6176: x-ms-exchange-purlcount: 2 authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com; x-microsoft-antispam-prvs: x-forefront-prvs: 0987ACA2E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(346002)(376002)(136003)(396003)(13464003)(51444003)(199004)(189003)(8936002)(14454004)(186003)(53546011)(6506007)(102836004)(966005)(8676002)(76176011)(6116002)(85182001)(81166006)(81156014)(6436002)(25786009)(478600001)(105586002)(7696005)(85202003)(106356001)(6246003)(99286004)(316002)(54906003)(110136005)(52536014)(74316002)(55016002)(7736002)(305945005)(53936002)(5660300002)(33656002)(6306002)(9686003)(229853002)(68736007)(2906002)(93886005)(4326008)(256004)(14444005)(97736004)(46003)(71200400001)(486006)(71190400001)(446003)(66574012)(11346002)(476003)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB6176; H:VI1PR07MB4735.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: WvlOKabOS1yjX7A7rdFEd+MZoSAJi+qvF8/8mK5a70JdFhG3/v6SbAAbv5Of0t/eLzmdh+Az1Aehls2+W8DfCfMO6DWMAZJor26uAYjItgwf8c8MwvJYs8izJbyprv6jk92UOIQGcYfrx5tYkjvDSRVoP0WBQ9QdnywJ0Ws3+Ml5JQg9GTCaMIAtjsb9dxXm8f6tJ4oUI+eNVbWdmK1flMvDoJYgoCCoGiS2Bg7PjIQvaxZ1xI8G4IzdvgpfRJOWy0LTYEHt4B66YHdA76lIJZzhchFafzdWjOcEE2iDAcgAbmLUYk9cU151UnLr0DCKC+HzdwzAs7mcKqjrUgdb6rlq7ZYg3aHtLxjYKW9I4D/0K2RnkcJSnAk4c46Bv10ASIbhI6V8DbjGSCvqfIqyqXKOcWBDTNQ4RZ/4D0Ug/yU= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8ebdecd8-63fa-41be-7040-08d6b121e7a5 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2019 13:00:49.5918 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6176 Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden 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, 25 Mar 2019 13:00:56 -0000 SGksDQoNCkluIHNvbWUgaW1wbGVtZW50YXRpb25zIEkgY2FuIHVuZGVyc3RhbmQgdGhhdCBiYWNr dXAvcmVzdG9yZSBpcyB2aWEgWUFORyBpbnRlcmZhY2UsIGJ1dCBiYWNrdXAvcmVzdG9yZSBpcyBw b3NzaWJsZSBieSBvdGhlciBtZXRob2RzIHRvby4gT24gdGhlIG90aGVyIGhhbmQsIHRoZSBwcml2 YXRlIGtleSBtYXRlcmlhbCBzaG91bGQgYmUgY3JlYXRlZCBhbmQga2VwdCBvbiB0aGUgb3duZXIg ZGV2aWNlIGFjY29yZGluZyB0byBiZXN0IHNlY3VyaXR5IHByYWN0aWNlcyBhbmQgY2VydGlmaWNh dGlvbiBkb25lIGJ5IGZvciBleGFtcGxlIGEgY2VydGlmaWNhdGUgc2lnbmluZyByZXF1ZXN0Lg0K DQpJbiB0aGF0IHNlbnNlIHRoZSBnZW5lcmF0ZS1oaWRkZW4ta2V5IGFjdGlvbiBhbmQgdGhlIENT UiBjcmVhdGlvbiBhY3Rpb24gYXJlIHNvbHZpbmcgdGhlIG1vc3QgY29tbW9uIG5lZWQgZm9yIGhh bmRsaW5nIGtleXMsIGFuZCB0aGF0IGlzIHJlYWxseSByZWdhcmRsZXNzIGlmIHRoZSBrZXkgaXMg c3RvcmVkIGluIGEgVFBNLCBhIGZpbGUgc3lzdGVtLCBvciBjZW50cmFsaXplZCBLTVMuDQoNCkkg cGVyc29uYWxseSB3YXMgZmluZSB3aXRoICdoaWRkZW4nIGFuZCBJIHdhcyBhbHNvIG9rIHdpdGgg dGhlIGN1cnJlbnQgYWN0aW9ucywgaXQgd2FzIG9ubHkgdGhlIGRlc2NyaXB0aW9ucyB0aGF0IHNl ZW1lZCB0byBiZSByZXN0cmljdGl2ZSB0byBUUE0gdXNhZ2UsIHRodXMgSSB3YXMgYXNraW5nIHNv bWUgY2xhcmlmaWNhdGlvbi4gSG93ZXZlciwgaWYgJ2hpZGRlbicgaXMgbm90IHRydWUgdGhpcyB3 YXksIHRoZW4ganVzdCBjYWxsIGl0ICdnZW5lcmF0ZS1rZXknLiBXb3VsZCB0aGF0IHRoZW4gY3Jl YXRlIGEgYmluYXJ5IHN0cmluZyBmb3IgdGhlICdwcml2YXRlLWtleScgaW4gb3BlcmF0aW9uYWwg dG9vIGluc3RlYWQgb2YgJ3Blcm1hbmVudGx5LWhpZGRlbicgdGh1cyB5b3UgYXJlIHJlZmVycmlu ZyB0byBhIDNyZCBvcHRpb24/DQoNCkJyLA0KQmFsYXpzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ+IA0KU2VudDog U2F0dXJkYXksIE1hcmNoIDIzLCAyMDE5IDg6MjMgUE0NClRvOiB0b20gcGV0Y2ggPGlldGZjQGJ0 Y29ubmVjdC5jb20+DQpDYzogQmFsw6F6cyBLb3bDoWNzIDxiYWxhenMua292YWNzQGVyaWNzc29u LmNvbT47IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2 ZXJzaXR5LmRlPjsgbmV0Y29uZkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRjb25mXSBpZXRm IGNyeXB0byB0eXBlcyAtIHBlcm1hbmVudGx5IGhpZGRlbg0KDQoNClt0b3AtcG9zdGluZyBmb3Ig Y29udmVuaWVuY2VdDQoNCkF0IGZpcnN0IHdlIGhhZCBhbiBSUEMgdG8gY3JlYXRlIGEga2V5LXBh aXIgKHByb3RlY3RlZCBvciBub3QpIHNvIGFzIHRvIHN1cHBvcnQgdGhlIGJlc3QgcHJhY3RpY2Ug b2YgdGhlIHByaXZhdGUga2V5IG5ldmVyIGxlYXZpbmcgYSBkZXZpY2UuICBCdXQgYmFja3VwL3Jl c3RvcmUgYmVjYW1lIGFuIGlzc3VlLCBhbmQgTWFydGluIG1hZGUgYSBwZXJzdWFzaXZlIGFyZ3Vt ZW50IHRoYXQgdGhlIHByaXZhdGUga2V5IFNIT1VMRCBiZSBjb25maWd1cmF0aW9uIChub3Qgb3Bl cmF0aW9uYWwgc3RhdGUpLiAgVGh1c2x5LCB3ZSByZWxlZ2F0ZWQgdGhlIFJQQyAobm93IGNhbGxl ZCDigJxnZW5lcmF0ZS1oaWRkZW4ta2V54oCdKSB0byB0aGUgc3BlY2lhbCBjYXNlIHdoZXJlIHRo ZSBzeXN0ZW0gZ2VuZXJhdGVzIGEga2V5IHRoYXQgaXMgb3BlcmF0aW9uYWwtc3RhdGUgYW5kIGlu YWNjZXNzaWJsZSAoYXQgbGVhc3QsIG5vdCBpbiBpdHMgcmF3IGZvcm07IGl0IG1heSBiZSBhY2Nl c3NpYmxlIGluIGEgc2hyb3VkZWQgZm9ybSkgYW5kLCBmb3IgYWxsIG90aGVyIGNhc2VzLCB0aGUg Y2xpZW50IE1VU1QgY29uZmlndXJlIHRoZSBrZXkgcGFpciAodHJhbnNtaXR0ZWQgb3ZlciB0aGUg d2lyZSwgbm90IGJlc3QgcHJhY3RpY2UsIG9oIHdlbGwpLg0KDQpDdXJyZW50bHkgdGhlcmUgYXJl IG9ubHkgdGhlc2UgdHdvIG9wdGlvbnMsIGJhc2VkIG9uIHRoZSBhY2Nlc3NpYmlsaXR5IG9mIHRo ZSBwcml2YXRlIGtleS4gSXMgdGhlIHJlcXVlc3QgdG8gaW50cm9kdWNlIGEgdGhpcmQgb3B0aW9u LCBidXQgaXNu4oCZdCB0aGUgaW50ZW50IGJldHRlciBzdXBwb3J0ZWQgYnkgYWNjZXNzLWNvbnRy b2w/ICBbdGhlIOKAnHByaXZhdGUta2V54oCdIGxlYWYgaXMgbmFjbTpkZWZhdWx0LWRlbnktYWxs XS4gDQoNClJlbmFtaW5nIOKAnGhpZGRlbuKAnSB0byDigJxpbmFjY2Vzc2libGXigJ0gc2VlbXMg b2theSBhbGJlaXQsIGluIGJvdGggY2FzZXMsIGl04oCZcyB0aGUgdW5zcGVjaWZpZWQgc3ViamVj dCAoY2xpZW50IHZzIHN5c3RlbSkgdGhhdCBtYXR0ZXJzIChpLmUuLCBoaWRkZW4vaW5hY2Nlc3Np YmxlIHRvIHdob20/KS4gIA0KDQpLZW50IC8vIGNvbnRyaWJ1dG9yDQoNCg0KDQpTZW50IGZyb20g bXkgaVBhZA0KPiBPbiBNYXIgMjIsIDIwMTksIGF0IDU6MjggUE0sIHRvbSBwZXRjaCA8aWV0ZmNA YnRjb25uZWN0LmNvbT4gd3JvdGU6DQo+IA0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t DQo+IEZyb206ICJCYWzDoXpzIEtvdsOhY3MiIDxiYWxhenMua292YWNzQGVyaWNzc29uLmNvbT4N Cj4gU2VudDogRnJpZGF5LCBNYXJjaCAyMiwgMjAxOSAxMjo0NCBQTQ0KPiANCj4gSGksDQo+IA0K PiBJIHdvdWxkIHJlYWxseSBwcmVmZXIgdGhlIGRlZmluaXRpb24gZm9yICdoaWRkZW4nIGFzICdu b3QgYWNjZXNzaWJsZSANCj4gdmlhIFlBTkcgcHJvdG9jb2xzJy4gVGhlIGV4cGxhbmF0aW9uIGlz IHRoYXQgcmVnYXJkbGVzcyBvZiB3aGF0IG1ldGhvZCANCj4gSSB1c2UgdG8gY3JlYXRlL3N0b3Jl IHRoZSBwcml2YXRlIGtleXMsIEkgc3RpbGwgbWlnaHQgbm90IHdhbnQgdGhlIA0KPiBvcGVyYXRv ciB0byBnZW5lcmF0ZSBrZXlzIG91dHNpZGUgb2YgdGhlIGRldmljZSBvciBjb25maWd1cmUgYmlu YXJ5IHNlY3JldCBzdHJpbmdzLg0KPiANCj4gPHRwPg0KPiANCj4gSSB0aGluayB0aGF0IHRoZSBt ZWFuaW5nIG9mIHRoZSB0ZXJtICdoaWRkZW4nIHZhcmllcyBkZXBlbmRpbmcgb24gDQo+IHdoaWNo IHBhcnQgb2YgdGhlIEktRCB5b3UgYXJlIHJlYWRpbmcuICBUaGUgdGVybSBpcyBhYnNlbnQgZnJv bSB0aGUgDQo+IHJlZmVyZW5jZWQgUkZDLCA4MDE3IGFuZCA1OTE1LCB3aGljaCBpcyBwcm9iYWJs eSBub3QgYSBjb2luY2lkZW5jZS4gIA0KPiBSYXRoZXIsIHRoZSB0ZXJtaW5vbG9neSBvZiB0aGUg bGl0ZXJhdHVyZSBpcyBvZiBhIGtleSBwYWlyLCBtYWRlIHVwIG9mIA0KPiBhIHB1YmxpYyBhbmQg cHJpdmF0ZSBrZXkgc28gdGhlIGFjdGlvbiBnZW5lcmF0ZS1oaWRkZW4ta2V5IHsgcHJvYmFibHkg DQo+IG1lYW5zIGdlbmVyYXRlLWtleS1wYWlyOyBidXQsIGluIG90aGVyIHBsYWNlcywgdGhlIHdv cmQgJ2hpZGRlbicgDQo+IGNsZWFybHkgaGFzIGRpZmZlcmVudCBzZW1hbnRpY3MgYW5kIHdvdWxk IHByb2JhYmx5IGJlc3QgYmUgcmVwbGFjZWQgYnkgDQo+IHNvbWV0aGluZyBlbHNlLCBzdWNoIGFz IGluYWNjZXNzaWJsZS4NCj4gDQo+IFRvbSBQZXRjaA0KPiANCj4gSSBjb25zaWRlcmVkIFRQTSBw cm90ZWN0aW9uIGZvciBoaWRkZW4ga2V5cyBpcyBhbiBvcHRpb24gb3IgZXhhbXBsZSBzbyANCj4g ZmFyLCB3aGljaCBhZGRzIGxpbWl0YXRpb25zIG9yIGFkZGl0aW9uYWwgY29tcGxleGl0eSBmb3Ig bW92aW5nIGtleXMsIA0KPiBidXQgc2hvdWxkIG5vdCBiZSB0aGUgb25seSBvcHRpb24gZm9yIGhp ZGRlbiBrZXlzLiBUaGUgZGVzY3JpcHRpb25zIA0KPiBtZW50aW9uIFRQTSBhcyBleGFtcGxlLCB0 aGVuIHRoZSByZXN0IG9mIHRoZSB0ZXh0IHNob3VsZCBhbGlnbiBhbHNvIHRvIA0KPiBrZWVwIHRo YXQgYXMgZXhhbXBsZS4NCj4gDQo+IEJyLA0KPiBCYWxhenMNCj4gDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVs ZGVyQGphY29icy11bml2ZXJzaXR5LmRlPg0KPiBTZW50OiBUaHVyc2RheSwgTWFyY2ggMjEsIDIw MTkgNDoyOSBQTQ0KPiBUbzogQmFsw6F6cyBLb3bDoWNzIDxiYWxhenMua292YWNzQGVyaWNzc29u LmNvbT4NCj4gQ2M6IG5ldGNvbmZAaWV0Zi5vcmc7IEtlbnQgV2F0c2VuIDxrZW50QHdhdHNlbi5u ZXQ+DQo+IFN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gaWV0ZiBjcnlwdG8gdHlwZXMgLSBwZXJtYW5l bnRseSBoaWRkZW4NCj4gDQo+IEkgYWdyZWUsIEkgZG8gbm90IHVuZGVyc3RhbmQgdGhlIHNlY29u ZCBzZW50ZW5jZSBlaXRoZXIuIE15IHByb2JsZW0gaXMgDQo+IHRoYXQgSSBkbyBub3Qga25vdyB3 aGF0IGEgJ3JlYWwnIHByaXZhdGUga2V5IGlzLCBhcmUgaGlkZGVuIGtleXMgDQo+IHNvbWV3aGF0 IHVucmVhbD8gT3IgaXMgIm5vdCBoaWRkZW4iID0gInJlYWwiPw0KPiANCj4gVGhlIGxhc3Qgc2Vu dGVuY2UgY2FuIHByb2JhYmx5IGJlIGZpeGVkOyBJIHRoaW5rIHRoZSBpbnRlbnRpb24gd2FzIHRv IA0KPiBzYXkgdGhhdCB5b3UgY2FuJ3QgYmFja3VwIGFuZCByZXN0b3JlIGhpZGRlbiBrZXlzIGJ5 IHJldHJpZXZpbmcgDQo+IGNvbmZpZ3VyYXRpb24gYW5kIHJlc3RvcmluZyB0aGUgY29uZmlndXJh dGlvbi4NCj4gDQo+IEluIGdlbmVyYWwsIEkgdGhpbmsgd2UgbmVlZCBhIGRlZmluaXRpb24gd2hh dCBhIGhpZGRlbiBrZXkgaXMuIElzIA0KPiBzb21ldGhpbmcgbm90IGV4cG9zZWQgdmlhIGEgWUFO RyBpbnRlcmZhY2UgYSBoaWRkZW4ga2V5IChidXQgaXQgbWF5IGJlIA0KPiBhIHJlZ3VsYXIga2V5 IHdoZW4gdXNpbmcgb3RoZXIgZGV2aWNlIGFjY2VzcyBtZXRob2RzKT8gT3IgZG8gd2UgDQo+IHJl cXVpcmUgdGhhdCBhIGhpZGRlbiBrZXkgaXMgZ2VuZXJhbGx5IHByb3RlY3RlZD8gSSBhc3N1bWUg c29tZSBwZW9wbGUgDQo+IHdhbnQgdG8gaGF2ZSBmbGV4aWJpbGl0eSBoZXJlIGJ1dCBmcm9tIHRo ZSB2aWV3cG9pbnQgb2YgYSBzZWN1cml0eSANCj4gYWRtaW5pc3RyYXRvciBpdCBtYXR0ZXJzIGEg bG90IHdoZXRoZXIgJ2hpZGRlbicgbWVhbnMgJ2dlbmVyYWxseSBub3QgDQo+IGFjY2Vzc2libGUn IG9yIG9ubHkgJ25vdCBhY2Nlc3NpYmxlIHZpYSBZQU5HIHByb3RvY29scycuDQo+IA0KPiBUaGUg ZGVzY3JpcHRpb24gb2YgaW5zdGFsbC1oaWRkZW4ta2V5IHNlZW1zIHRvIGluZGljYXRlIGEga2V5 IGlzIA0KPiBhbHJlYWR5ICdoaWRkZW4nIGlmIGl0IG9ubHkgZXhpc3RzIGluIDxvcGVyYXRpb25h bD4uIElzIHRoaXMgcmVhbGx5IGEgJ2hpZGRlbicNCj4ga2V5IG9yIG1vcmUgYW4gJ2VwaGVtZXJh bCcga2V5Pw0KPiANCj4gL2pzDQo+IA0KPj4gT24gVGh1LCBNYXIgMjEsIDIwMTkgYXQgMDI6MjM6 MjdQTSArMDAwMCwgQmFsw6F6cyBLb3bDoWNzIHdyb3RlOg0KPj4gSGksDQo+PiANCj4+IFRoZSAn Z2VuZXJhdGUtaGlkZGVuLWtleScgYWN0aW9uIGlzIG1lYW50IGZvciBjYXNlcyB3aGVuIHRoZSBr ZXkgbXVzdA0KPiBiZSBnZW5lcmF0ZWQgaW4gdGhlIGRldmljZSBhbmQgbm90IHRoZSBvcGVyYXRv ciBpcyBjb25maWd1cmluZyBpdC4gVGhlIA0KPiAnZ2VuZXJhdGUtaGlkZGVuLWtleScgaXMgc2Fp ZCB0byBwcm9kdWNlIGEgJ3Blcm1hbmVudGx5LWhpZGRlbicNCj4gYXN5bW1ldHJpYyBrZXkuIFRo ZSBkZXNjcmlwdGlvbiBvZiAncGVybWFuZW50bHktaGlkZGVuJyBpcyBhcyBmb2xsb3dzOg0KPj4g DQo+PiAgICAgICAgICAgICAgICAiVGhlIHByaXZhdGUga2V5IGlzIGluYWNjZXNzaWJsZSBkdWUg dG8gYmVpbmcNCj4+ICAgICAgICAgICAgICAgICAgcHJvdGVjdGVkIGJ5IHRoZSBzeXN0ZW0gKGUu Zy4sIGEgY3J5cHRvZ3JhcGhpYw0KPj4gICAgICAgICAgICAgICAgICBoYXJkd2FyZSBtb2R1bGUp LiAgSXQgaXMgbm90IHBvc3NpYmxlIHRvDQo+PiAgICAgICAgICAgICAgICAgIGNvbmZpZ3VyZSBh IHBlcm1hbmVudGx5IGhpZGRlbiBrZXksIGFzIGEgcmVhbA0KPj4gICAgICAgICAgICAgICAgICBw cml2YXRlIGtleSB2YWx1ZSBtdXN0IGJlIHNldC4gIFBlcm1hbmVudGx5DQo+PiAgICAgICAgICAg ICAgICAgIGhpZGRlbiBrZXlzIGNhbm5vdCBiZSBhcmNoaXZlZCBvciBiYWNrZWQgdXAuIjsNCj4+ IA0KPj4gVGggc2Vjb25kIHNlbnRlbmNlIGRvZXNuJ3Qgc291bmQgcmlnaHQuIEkgY2FuIGNyZWF0 ZSBhIHBlcm1hbmVudGx5DQo+IGhpZGRlbiBrZXkgYW55IHRpbWUgYnkgY2FsbGluZyB0aGUgJ2dl bmVyYXRlLWhpZGRlbi1rZXknIGFjdGlvbiwgb3IgaWYgDQo+IHRoZSBkZXZpY2Ugb3IgdGhlIG1v ZGVsIGFsbG93cyBJIGNvdWxkIGV2ZW4gc3dpdGNoIHRvIG5vbi1oaWRkZW4ga2V5LCANCj4gSSBi ZWxpZXZlLCBieSBwcm92aWRpbmcgdGhlIGJpbmFyeS4gU28gSSBmaW5kIHRoZSBzZWNvbmQgc2Vu dGVuY2UgDQo+IGlycmVsZXZhbnQgaW4gdGhpcyBkZXNjcmlwdGlvbi4NCj4+IA0KPj4gTW9yZSBp bXBvcnRhbnRseSwgSSBmaW5kIHRoZSAiUGVybWFuZW50bHkgaGlkZGVuIGtleXMgY2Fubm90IGJl DQo+IGFyY2hpdmVkIG9yIGJhY2tlZCB1cCIgc3RhdGVtZW50IGZhbHNlLiBJc24ndCB0aGF0IGlt cGxlbWVudGF0aW9uIA0KPiBzcGVjaWZpYyBob3cgYXJjaGl2aW5nIGlzIGRvbmU/IElmIGEgZGV2 aWNlIHB1dHMgdGhlIGhpZGRlbiBrZXlzIG9uIA0KPiBzb21lIHN0b3JhZ2UsIGl0IG1heSBzdGls bCBiZSBwb3NzaWJsZSB0byBiYWNrIHRoZW0gdXAuIEkgd291bGQgcHJlZmVyIA0KPiB0byByZW1v dmUgdGhpcyBzZW50ZW5jZSBhbmQgbGVhdmUgYmFja3VwIGNvbnNpZGVyYXRpb25zIHRvIGltcGxl bWVudGF0aW9ucy4NCj4+IA0KPj4gQ291bGQgdGhlc2UgY2hhbmdlcyBiZSBkb25lPw0KPj4gDQo+ PiBCciwNCj4+IEJhbGF6cw0KPiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+PiBuZXRjb25mIG1haWxpbmcgbGlzdA0KPj4gbmV0Y29uZkBpZXRm Lm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo+ IA0KPiANCj4gLS0NCj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5p dmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBD YW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPiBGYXg6ICAgKzQ5IDQyMSAy MDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRj b25mIG1haWxpbmcgbGlzdA0KPiBuZXRjb25mQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPiANCg0K From nobody Mon Mar 25 13:56:49 2019 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 A2A2212085C for ; Mon, 25 Mar 2019 13:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9q7X6MgyZ9Y for ; Mon, 25 Mar 2019 13:56:40 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB99120863 for ; Mon, 25 Mar 2019 13:56:39 -0700 (PDT) Received: from localhost (dhcp-9545.meeting.ietf.org [31.133.149.69]) by mail.tail-f.com (Postfix) with ESMTPSA id 725441AE00A0 for ; Mon, 25 Mar 2019 21:56:37 +0100 (CET) Date: Mon, 25 Mar 2019 21:56:37 +0100 (CET) Message-Id: <20190325.215637.1342845104682793774.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [netconf] mbj review of draft-ietf-netconf-notification-capabilities-01 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, 25 Mar 2019 20:56:48 -0000 Hi, Here are my (mostly minor) comments on draft-ietf-netconf-notification-capabilities-01 o Terminology 1. The term that is used in th YP draft is "YANG-Push". Please import that and use it consistently. (I see at least "YangPush" and "Yang-Push"). 2. This document uses the terms "YANG server" and "Yang server". I suggest you change this to "server", and import that from RFC 8342. o Abstract The abstract mentions YANG Instance Data, but it doesn't mention run-time. I think it should. o Section 1 s/Rutime/Runtime/ o Section 1 s/protocol/management protocol/ Should you really list HTTPS here? + add references to NETCONF and RESTCONF. o Section 3 Editorial: remove the text within the parentheses. o General We need to be able to specify on-change support per datastore. With support per datastore, it is not quite clear if notification-sent-for-config-default and notification-sent-for-state-default are needed, and/or how they should be interpreted. o General In YP, support for on-change is optional. There is a feature called "on-change". I think this document should state explicitly that this module is intended for servers that implement that feature. o Section 3.2 Editorial: We no longer list the WG Chairs in the description. Since you use 2119 language in the model, please include the boilerplate in the module description. The module description doesn't contain the proper copyright text, The module should be formatted similar to the rest of the IETF-published modules. I suggest you run pyang -f yang --keep-comments --yang-line-length 69 and then ensure that any additions are consistent with that. o Section 3.2 The top-level container is currently called "yangpush-notification-capabilities". This doesn't really match the naming in the YP document. I suggest it is called "datastore-subscription-capabilities", so that we use a word that can be related to the the nodes YP defines, such as in "establish-subscription" ... "datastore" "datastore-subtree-filter" o Section 3.2 You have: units msec; units centiseconds; I think you probably should do s/msec/milliseconds/ o Section 3.2 minimum-dampening-period is optional. It should be stated what it means if this leaf is not present. (or should the default be 0?) o Section 3.2 The choice update-period is not mandatory, and doesn't have a default. What does it mean if this is not reported? o Section 3.2 The leaf max-objects-per-update is not mandatory. What does it mean if this is not reported? It can have the value 0. What does that mean? Perhaps make a union of uint32 0..max and the enum "infinite" and make that the default? (of course "infinite" is not really correct...) o General I missed some examples, perhaps in an Appendix. /martin From nobody Mon Mar 25 16:21:37 2019 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 A043312014D for ; Mon, 25 Mar 2019 16:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.036 X-Spam-Level: *** X-Spam-Status: No, score=3.036 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, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 EfWDtNdcIyug for ; Mon, 25 Mar 2019 16:21:33 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00056.outbound.protection.outlook.com [40.107.0.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9669212014C for ; Mon, 25 Mar 2019 16:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z6OB8gNGcCjB+KCnzXDqfssSfKnl5C+s9XU6GzyXj3c=; b=EQcea/riY2yCqTaf7XCIymqk55kv39KhrZQ5fkShSIDDEVnIaovHNTWE9ynyezWOEqHncLbb5+taxkEQmg9ceVm1brlUaESzZ1X0NM0xtkYb5bMpvWtZJ1Kb0CDGG0N9PyrLERKS8cqG5I8rR0Ob6sVr4arMuO7JEuS7PkKvuII= Received: from AM6PR07MB3847.eurprd07.prod.outlook.com (52.134.115.144) by AM6PR07MB5829.eurprd07.prod.outlook.com (20.178.93.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.13; Mon, 25 Mar 2019 23:21:30 +0000 Received: from AM6PR07MB3847.eurprd07.prod.outlook.com ([fe80::39a5:6b6d:a86f:721c]) by AM6PR07MB3847.eurprd07.prod.outlook.com ([fe80::39a5:6b6d:a86f:721c%2]) with mapi id 15.20.1730.013; Mon, 25 Mar 2019 23:21:30 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Benoit Claise , NETCONF Thread-Topic: draft-ietf-netconf-notification-capabilities feedback Thread-Index: AQHU42F6NBoLcEaFCk2J84+UwiK7dQ== Date: Mon, 25 Mar 2019 23:21:30 +0000 Message-ID: <43865c67-7950-c617-ea1d-12622a007d34@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.93] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 x-clientproxiedby: HE1PR0502CA0023.eurprd05.prod.outlook.com (2603:10a6:3:e3::33) To AM6PR07MB3847.eurprd07.prod.outlook.com (2603:10a6:209:31::16) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d578ecd0-0842-4274-53bb-08d6b1789c7c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:AM6PR07MB5829; x-ms-traffictypediagnostic: AM6PR07MB5829: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-microsoft-antispam-prvs: x-forefront-prvs: 0987ACA2E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(346002)(366004)(39860400002)(396003)(199004)(189003)(51914003)(65826007)(14444005)(31696002)(256004)(316002)(66574012)(486006)(36756003)(186003)(3846002)(2616005)(6116002)(31686004)(476003)(52116002)(26005)(65956001)(65806001)(85202003)(11346002)(66066001)(478600001)(413944005)(7736002)(606006)(97736004)(14454004)(68736007)(86362001)(446003)(76176011)(105586002)(71200400001)(110136005)(25786009)(71190400001)(6246003)(85182001)(106356001)(99936001)(81156014)(64126003)(58126008)(8936002)(53936002)(6506007)(6436002)(386003)(102836004)(99286004)(6306002)(6486002)(15650500001)(236005)(2906002)(8676002)(6512007)(54896002)(229853002)(5660300002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5829; H:AM6PR07MB3847.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 8rFYsPADHvwTCm1ttBE7DNq5D8B5FxmvyQwR17SSpLR7zcvCjzL1zdO7JhDK2GHDxfmX1H3JYpDuoj6QDnornu1ML0pJpoXAukZOlTP6fTs0jzPhv48tnowHFIKMcKfP7gp7s5gQV0PcOS3I36qOC2aJNDY+V4n2pIV+Au+cWcogDqAz7s1FLKJuUoJ+Z9IFdaJrqg+XT9J6WBnGm7FFGBxgXVJ1QZ04ZKf4IxeZYHSopQjfbgugeJ0TelUmlLnTZO8AH0Rhm27cl/lw5SOfRRuyNKgHI+Ozk1LJ9BgjPWBOy8wzIx1eSLeUPFWHhJXK6+x84F7tGsa5Cui2wo16J8jFzz+l5bzvG5s0XuxN0ryJDSHeBPBfvrT3iJa7a8GdJg/cfvKthGq1jjs6UROREWQInubBv7hA8kHSk/rEIIQ= Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000908030802090306060707" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: d578ecd0-0842-4274-53bb-08d6b1789c7c X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2019 23:21:30.2531 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5829 Archived-At: Subject: Re: [netconf] draft-ietf-netconf-notification-capabilities feedback 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, 25 Mar 2019 23:21:36 -0000 --------------ms000908030802090306060707 Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable

Thanks for the comments, See below. Balazs

On 2019. 03. 24. 17:55, Benoit Claise wrote:
Dear all,

Here is my feedback on draft-ietf-netconf-notification-capabilities, which I gave verbally to Balasz today.

- we need the on-change capabilities for
=C2=A0=C2=A0=C2=A0 1. per datastore
=C2=A0=C2=A0=C2=A0 2. per YANG object(s), i.e. schema specifig
=C2=A0=C2=A0=C2=A0 3. per YANG instance
BALAZS: per datastore to be added. per instance is possible=C2=A0 in the on-line data; while it is also possible in the off-line instance data files, it won't really work as usually the instance keys are not know that early.

- We really would some nacm:node-instance-identifier examples (of the 3 different use cases)
BALAZS: will be provided

The rest below seems to be implementation specific (limitations): 
      +--ro minimum-dampening-period?       =
        uint32
      +--ro (update-period)?
      |  +--:(minimum-update-period)
      |  |  +--ro minimum-update-period?                  uint32
      |  +--:(supported-update-period)
      |     +--ro supported-update-period*                uint32
      +--ro max-objects-per-update?                 uint32
BALAZS: They are optional, you don't have to provide them. I was specifically asked to include them. I think it is useful, and it does no harm.

- The choice default values should be discussed. They implementation-specific. 
     leaf notification-sent-for-config-defau=
lt {
       type boolean;
       default true;
       description "Specifies the default value for
         top level configuration data nodes for the
         on-change-notification-sent capability.";
     }

     leaf notification-sent-for-state-default {
       type boolean;
       default false;
       description "Specifies the default value
         top level state data nodes for the
         on-change-notification-sent capability.";
Initially, I was thinking that both should be false, so that only on-change true must be present in the list.
BALAZS: I chose the defaults because in my view is that implementing config updates centrally is easy, while implementing state updates is a distributed task, thus complicated. The defaults can be changed by a deviation. If the WG has a strong opinion I can change them,

- Not sure why the draft tries to go in the compliance statement of you MUST support both options
 The information SHALL be provided in two wa=
ys both following the
   ietf-notification-capabilities module:

   o  It SHALL be provided by the implementer as YANG instance data file
      complying to the [I-D.lengyel-netmod-yang-instance-data].  The
      file SHALL be available already in implementation time retrievable
      in a way that does not depend on a live network node.  E.g.
      download from product Website.

   o  It SHALL be available via NETCONF or RESTCONF from the live YANG
      server during runtime.
BALAZS: I will change=C2=A0 this to say: The information SHOULD be provided in implementation time, but one of the above MUST be done.
The specifications should document:
If you want this info off-line, then use draft-ietf-netmod-yang-instance-file-format
If you want this info on-line, implement the module in the server, potentially as an extension to the IETF-YANG-LIBRARY
MUST implement one of the two.

EDITORIAL
- When I see "instance", I always wonder if you mean an instantation or the instance-file-format
   If the information is
   not available early in some document, but only as instance data from
   the network node, the NMS implementation will be delayed, because it
   has to wait for the network node to be ready.
BALAZS: I will use instance-data-set=C2=A0 or= on-line for live data.
- This= explanation could be improved (read it multiple times)
     On-change notifications SHALL be sent f=
or a config=3Dtrue
     data node if one of the following is true:
     - if it is a top level data-node and is not specified in the
     on-change-notification-capability list and the
     notification-sent-for-config-default is true; or
     - notifications are sent for its parent data node and it is
     not specified in the on-change-notification-capability list; or
     - it is specified in the on-change-notification-capability
     list and has a on-change-notification-sent value true.

     On-change notifications SHALL be sent for a config=3Dfalse
     data node if one of the following is true:
     - if it is a top level data-node or has a config=3Dtrue parent
     data node and is not specified in the
     on-change-notification-capability list and the
     notification-sent-for-state-default is true; or
     - notifications are sent for its parent data node
     which is also config=3Dfalse and it is
     not specified in the on-change-notification-capability list; or
     - it is specified in the on-change-notification-capability
     list and has an on-change-notification-sent value true or
     ";
BALAZS: will try. Providing examples will help.
- why don't you just mention "on-change streaming capability discovery" 
   Run-time information is needed

   o  for any "purely model driven" client, e.g. a NETCONF-browser.  As
      long as it has a valid model to read the capability information,
      it does not care which data nodes send notification, it will just
      handle what is available.

   o  in case the capability might change during run-time e.g. due to
      licensing, HW constraints etc.

   o  to check that early, implementation time capability information
      about the capabilities is indeed what the server implements (is
      the supplied documentation correct?)
- The terminology seems to focus on NETCONF, however it should stress the generic streaming capabilities
BALAZS: configuring on-change subscription is= netconf (and restconf) related even if the transport of notifications may use different transports. Will clarify.

Regards, Benoit
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20
--------------ms000908030802090306060707 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20 wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4 ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9 ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9 YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF 1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6 EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0 NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA 7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+ MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0 LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9 2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa 49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDMyNTIzMjEyNlow LwYJKoZIhvcNAQkEMSIEIBFwwhv82Vzo1a5AOYUGAk4z3pTSCoGVRgC/QPGdfim3MGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBAJ7p+vRwGo/PiM4TAnbf37E3Tu71lSiCgBveeTRYlFyqIGKZ Y1BvbY5W7YfbHTIsS1/XaGOZLMjRvM3tUmtb6RDdRQYv7MHbIUyjN8j8NKS7wLmieHf134MD wrO4TTLXlHglJBYpv5oET6+WrTcrMHBoDw/3KTBBf2xgOysL/ndrLUwOZR7dRuENUnwLE4g5 LhoDzrrOitgP+Xvk1ZXY8C6EetWf/1MsD/9lccSmWR0CyftP8i7BywUXhqFTR0e9CMRpjGSa k7FCwOR5op6jCNDlJUoFL7H96VmkBxOqwxRdXpxQTZQv8gy7VK+nDLdIoV5BPo33CLFEeADY pk3ybykAAAAAAAA= --------------ms000908030802090306060707-- From nobody Mon Mar 25 16:41:20 2019 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 7700F1201AA for ; Mon, 25 Mar 2019 16:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.036 X-Spam-Level: *** X-Spam-Status: No, score=3.036 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, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 E0I0u9duUOnE for ; Mon, 25 Mar 2019 16:41:01 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70045.outbound.protection.outlook.com [40.107.7.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B048120194 for ; Mon, 25 Mar 2019 16:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qmAAW76dtsKeQT/Wys7l2hINOlL48Qv56eKAOb9foMg=; b=Un1F/24N0mTRvcx8Y6OffR2acklIX9FX529Y6MGAkgEJu5zT9X8KmyQYmqAROvHboVJo4rr/AsQwRKThS2vX9vJdBTU+/vZtlYWLALqtPtU7MPbYz/2zl765STgd/H9K0kUZZIKd+53nAoCPANN+8o7vzHlHroJpu+RqXeV3X3c= Received: from DB7PR07MB3850.eurprd07.prod.outlook.com (52.134.99.143) by DB7PR07MB5260.eurprd07.prod.outlook.com (20.178.43.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.14; Mon, 25 Mar 2019 23:40:56 +0000 Received: from DB7PR07MB3850.eurprd07.prod.outlook.com ([fe80::6c96:5ffd:d461:9f5e]) by DB7PR07MB3850.eurprd07.prod.outlook.com ([fe80::6c96:5ffd:d461:9f5e%3]) with mapi id 15.20.1750.014; Mon, 25 Mar 2019 23:40:56 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Martin Bjorklund , "netconf@ietf.org" Thread-Topic: [netconf] mbj review of draft-ietf-netconf-notification-capabilities-01 Thread-Index: AQHU42Qxrrq0rsMFj06W2FbjkiSDuQ== Date: Mon, 25 Mar 2019 23:40:56 +0000 Message-ID: References: <20190325.215637.1342845104682793774.mbj@tail-f.com> In-Reply-To: <20190325.215637.1342845104682793774.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.93] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 x-clientproxiedby: HE1PR0902CA0017.eurprd09.prod.outlook.com (2603:10a6:3:e5::27) To DB7PR07MB3850.eurprd07.prod.outlook.com (2603:10a6:5:7::15) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f501b662-7e54-4d6b-fc3b-08d6b17b535a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:DB7PR07MB5260; x-ms-traffictypediagnostic: DB7PR07MB5260: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-microsoft-antispam-prvs: x-forefront-prvs: 0987ACA2E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(136003)(39860400002)(396003)(366004)(199004)(189003)(51914003)(99286004)(31696002)(2501003)(64126003)(486006)(85202003)(8936002)(446003)(102836004)(54896002)(65826007)(6486002)(36756003)(86362001)(476003)(8676002)(110136005)(71190400001)(81156014)(81166006)(2616005)(11346002)(14444005)(58126008)(5660300002)(85182001)(316002)(71200400001)(7736002)(6116002)(14454004)(65956001)(65806001)(66066001)(26005)(52116002)(606006)(6246003)(105586002)(478600001)(25786009)(2906002)(256004)(386003)(3846002)(76176011)(229853002)(31686004)(6506007)(6436002)(186003)(15650500001)(68736007)(53936002)(99936001)(966005)(106356001)(236005)(97736004)(6512007)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5260; H:DB7PR07MB3850.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: W3Bqul3PR5nsvEp/7ErryZ7zthfLKFmfQrQvK9CrfWd9BjWzV6Ea5qcDdj3z6FDjNGK1IqMqXGAKnZs/eF68hQ4D70Ql0bDC1koTW2PtkKuvYDnhGHoIdjOORHMViCBkY/7esZh/dP4rry4kUON9IgiHaFN42l9NcnLY+qmxSqkdDlfwhRQ3C8f+f20uXuagD3bTF41AwjZXf33kpDERNhAWk2+0lTT89nSbvmSYOrmGLKVTqNXKMLPNCGzY8pP5ON+M/YIPfQALodSuMXOFvG4gjlNcH7RQszpzpE6iAk7U2jLgQZVFW6u148Ok/daGuSL2k34XUzPsSVz6I0d9vd2qDLpagWz0tX8vG9oHq7Qzvm/Dl5D825fiZG5keA3nYPLjkgvkY5q1DO5yW3IFr683pNY1Z0F1LJ/+R1L0lag= Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030106050200090904070900" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: f501b662-7e54-4d6b-fc3b-08d6b17b535a X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2019 23:40:56.5195 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5260 Archived-At: Subject: Re: [netconf] mbj review of draft-ietf-netconf-notification-capabilities-01 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, 25 Mar 2019 23:41:17 -0000 --------------ms030106050200090904070900 Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable

Thanks for the comments, See below. Balazs

On 2019. 03. 25. 21:56, Martin Bjorklund wrote:
Hi,

Here are my (mostly minor) comments on
draft-ietf-netconf-notification-capabilities-01



o  Terminology

  1. The term that is used in th YP draft is "YANG-Push".  Please
     import that and use it consistently.  (I see at least "YangPush"
     and "Yang-Push").
BALAZS: OK 
  2. This document uses the =
terms "YANG server" and "Yang server".  I
     suggest you change this to "server", and import that from RFC
     8342.
BALAZS: OK 
o  Abstract

  The abstract mentions YANG Instance Data, but it doesn't mention
  run-time.  I think it should.
BALAZS: OK 
o  Section 1

  s/Rutime/Runtime/
BALAZS: OK 
o  Section 1

  s/protocol/management protocol/

  Should you really list HTTPS here?   + add references to NETCONF and
  RESTCONF.
BALAZS: OK 
o  Section 3

  Editorial: remove the text within the parentheses.


o  General

  We need to be able to specify on-change support per datastore.

  With support per datastore, it is not quite clear if
  notification-sent-for-config-default and
  notification-sent-for-state-default are needed, and/or how they
  should be interpreted.
BALAZS: The defaults will also be per datastore. For datastores that do support them, they have no meaning. E.g. state data in intended. They could be removed formally with when statements in the YANG, but IMHO its enough to state it in text:
- default for state is anyway false
- For new datastores we would not know how to set up the when condition 
o  General

  In YP, support for on-change is optional.   There is a feature
  called "on-change".  I think this document should state explicitly
  that this module is intended for servers that implement that
  feature.
BALAZS: OK, but some other capacity related proerties are still valid. 
o  Section 3.2

  Editorial:

    We no longer list the WG Chairs in the description.

    Since you use 2119 language in the model, please include the
    boilerplate in the module description.

    The module description doesn't contain the proper copyright text,

    The module should be formatted similar to the rest of the
    IETF-published modules.  I suggest you run

      pyang -f yang --keep-comments --yang-line-length 69 <FILE>

    and then ensure that any additions are consistent with that.
BALAZS: OK 
o  Section 3.2

  The top-level container is currently called
  "yangpush-notification-capabilities".

  This doesn't really match the naming in the YP document.

  I suggest it is called "datastore-subscription-capabilities", so
  that we use a word that can be related to the the nodes YP defines,
  such as in "establish-subscription" ... "datastore"
  "datastore-subtree-filter"
BALAZS: OK 
o  Section 3.2

  You have:

         units msec;

         units centiseconds;

  I think you probably should do s/msec/milliseconds/
BALAZS: OK, probably change all to centiseconds. Is there a general rule not to use the official abbreviations? 
o  Section 3.2

  minimum-dampening-period is optional.  It should be stated what it
  means if this leaf is not present.   (or should the default be 0?)
BALAZS: If not present it means that the system does not tell you what it is. No special meaning. I do not see a reasonable minimum value (eventhough 0 would look strange). IMHO it is the responsibility of the server to provide a meaningful value. If it says zero, that's obviously crazy, just ignore it. I don't thing we need to have rules, like: do not provide stupid state data. 
o  Section 3.2

  The choice update-period is not mandatory, and doesn't have a
  default.  What does it mean if this is not reported?
BALAZS: If not present it means that the system does not tell you what it is.=C2=A0 No special meaning. 
o  Section 3.2

  The leaf max-objects-per-update is not mandatory.  What does it mean
  if this is not reported?  It can have the value 0.  What does that
  mean?
BALAZS: If not present it means that the system does not tell you what it is. No special meaning. I do not see a reasonable minimum value (eventhough 0 would look strange). IMHO it is the responsibility of the server to provide a meaningful value. If it says zero, that's obviously crazy, just ignore it. 
  Perhaps make a union of ui=
nt32 0..max and the enum "infinite" and
  make that the default?  (of course "infinite" is not really
  correct...)
BALAZS: IMHO infinite is unreasonable. If the= server doesn't know the real limit, it should just not provide a value. 
o  General

  I missed some examples, perhaps in an Appendix.
BALAZS: Will be provided. 
____________________________=
___________________
netconf mailing list
ne=
tconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20
--------------ms030106050200090904070900 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20 wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4 ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9 ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9 YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF 1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6 EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0 NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA 7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+ MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0 LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9 2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa 49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDMyNTIzNDA1Mlow LwYJKoZIhvcNAQkEMSIEIAQl9us8cWHNMk1XjPifwQ2rSa59QqilDl1HClEs8uD+MGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBABQaRQSgTU83lloHp03ClGMDAKURs81ATvdvYg4HYjyB/r2b fk+VZZ2OZv3VIEDRLQfQf1Jc5lTWgB71aDKrKr509YgpfOb6hqpsDKXkLjaooRMmkRmV7t6x AHBLEo2F6UC58zvfcR84O6I9DtSTIywKPMY/ETZQT/6d+eiwugVa9/AzN3REEJtqpALbYuyZ dxrbJiNu+Eb3QcFAf7PIRCHyi2HWrXyMEKWP9fh3EAPuSrhmhFcjOc/SFhhldYcB/2qOirfG FgpVL1SkXW9ZwOhWttDUZtQIS3L/qbphdJhJvsLJ7nM1PnRFE4dcXS8+CusxpCxJHFPdqQYX 4BLVi7oAAAAAAAA= --------------ms030106050200090904070900-- From nobody Tue Mar 26 04:12:38 2019 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 092421202DB for ; Tue, 26 Mar 2019 04:12:36 -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, 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 qs__hi402mkd for ; Tue, 26 Mar 2019 04:12:34 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 216281202D1 for ; Tue, 26 Mar 2019 04:12:34 -0700 (PDT) Received: from localhost (dhcp-97ad.meeting.ietf.org [31.133.151.173]) by mail.tail-f.com (Postfix) with ESMTPSA id BA23D1AE02BD; Tue, 26 Mar 2019 12:12:31 +0100 (CET) Date: Tue, 26 Mar 2019 12:12:31 +0100 (CET) Message-Id: <20190326.121231.1546381642017000114.mbj@tail-f.com> To: balazs.lengyel@ericsson.com Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <20190325.215637.1342845104682793774.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] mbj review of draft-ietf-netconf-notification-capabilities-01 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, 26 Mar 2019 11:12:36 -0000 Hi, Pruning... Bal=E1zs Lengyel wrote: > Thanks for the comments, See below. Balazs > = > On 2019. 03. 25. 21:56, Martin Bjorklund wrote: > = > Hi, > = > Here are my (mostly minor) comments on > draft-ietf-netconf-notification-capabilities-01 [...] > o General > = > In YP, support for on-change is optional. There is a feature > called "on-change". I think this document should state explicitly > that this module is intended for servers that implement that > feature. > = > BALAZS: OK, but some other capacity related proerties are still valid= .= What other capacity related properties do you mean? > o Section 3.2 > = > You have: > = > units msec; > = > units centiseconds; > = > I think you probably should do s/msec/milliseconds/ > = > BALAZS: OK, probably change all to centiseconds. Is there a general > rule not to use the official abbreviations? What is the official abbrevation? According to wikipedia, the SI name is "millisecond" and "centisecond", and the corresponding symbols are "ms" and "cs". I briefly scanned the SI spec, but didn't really come to any conclusion... My point was just that it is probably best to be consistent and not use an abbreviation in one place and the full word in the other. > o Section 3.2 > = > minimum-dampening-period is optional. It should be stated what it > means if this leaf is not present. (or should the default be 0?) > = > BALAZS: If not present it means that the system does not tell you wha= t > it is. No special meaning. I do not see a reasonable minimum value > (eventhough 0 would look strange). IMHO it is the responsibility of > the server to provide a meaningful value. If it says zero, that's > obviously crazy, just ignore it. I don't thing we need to have rules,= > like: do not provide stupid state data. Note that 0 is the default in YP, so I don't know why you think it is crazy. I suggest you add default "0" to this. > o Section 3.2 > = > The choice update-period is not mandatory, and doesn't have a > default. What does it mean if this is not reported? > = > BALAZS: If not present it means that the system does not tell you wha= t > it is. No special meaning. I think this should be clarified in the description. > o Section 3.2 > = > The leaf max-objects-per-update is not mandatory. What does it mea= n > if this is not reported? It can have the value 0. What does that > mean? > = > BALAZS: If not present it means that the system does not tell you wha= t > it is. No special meaning. > > I do not see a reasonable minimum value > (eventhough 0 would look strange). IMHO it is the responsibility of > the server to provide a meaningful value. If it says zero, that's > obviously crazy, just ignore it. I suggest you add a range "1..max" to the type. > Perhaps make a union of uint32 0..max and the enum "infinite" a= nd > make that the default? (of course "infinite" is not really > correct...) > = > BALAZS: IMHO infinite is unreasonable. If the server doesn't know the= > real limit, it should just not provide a value. Ok, makes sense. I think this should be clarified in the description. /martin From nobody Tue Mar 26 04:17:33 2019 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 A5CF31202FB for ; Tue, 26 Mar 2019 04:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 CwooWtl0CYzE for ; Tue, 26 Mar 2019 04:17:19 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 B41FA1202C6 for ; Tue, 26 Mar 2019 04:17:18 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id y7so9724119wrn.11 for ; Tue, 26 Mar 2019 04:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=olWt1wN2oguYf9ej1FzT5pKCcWTm9r/sjJd5zAKLjHs=; b=e8ZEn3IbGvPRAePrNkZAAyZq3VMsQ8EmdRxZ2PNE+zscQ1S3qOQtEzUBVUzkUit2wp muI926ddctHB1Ar0kcaoyFomPnINJ2Y0CC3FXuhfptlC8Sdk8XdcOvWIDVC1oko2Qw9B HuK5rsiB5aP7/9nX7HaRf1UMhkOREuV78CmLuJ66t6+AbYD8SFEzUM0vY1+BE201LWSI 8semFsDuSK4p9XOSv5AD9DIR2KMOJzybutOMg0DaXuK8UUnfawdkf9nxgnd5Cc/y+TZD K8TJ9QTVL8DFKXXJyOMV+0n+uHI+piSaETnPeOPwTKe+zkwVkuQ51yfu3AFhbwrffqJz FhaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=olWt1wN2oguYf9ej1FzT5pKCcWTm9r/sjJd5zAKLjHs=; b=eEih2k6MAOuMFoMh0HXtKSktyBebZ1mrymwIbZNxuaEN5zQU6Jxuj4KF1S6CZf0dT0 zfbxZZQlF+WnPVrDUja4shdVu5IaYVmD0ZW17EmUZstKlg/rCsR3fFXlbZ8UiD2vH5ve 5V023uHmyKfjwko+OJEcUa5zRI2ErdroW3T18+/qmcT0nqlNpTyoRBwm6DBT1ouKyGVy +lpETeYjFTFZw3ax0a/sVw5KVdgLbcrZukfe9sauK6pg+w/UbYMkr16rmtj2tEH7xWwI dYF7ohnr/r5ueOK5oX/dB+0xpJNMJzEY/WeqIalNHfq/EHrS2/uUhFU2FgwMChIppNM0 cSXg== X-Gm-Message-State: APjAAAU+K9Ffte0HYoazTuf4jUmCgFupIdVuBODjTOfUmdSP5AuvPnIf uXjBuchIe/gfczQHesO4qSplBEdA08xuJQ== X-Google-Smtp-Source: APXvYqxzFwiHoSTH3c/q6iCD+lJafwaSvrBchNHmUm5t1IMYWXnCGe296EB1RLm3GnXzgQhQVb1kQg== X-Received: by 2002:a5d:5111:: with SMTP id s17mr18272742wrt.159.1553599036881; Tue, 26 Mar 2019 04:17:16 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:3927:702f:fbe5:4d9e? ([2001:67c:1232:144:3927:702f:fbe5:4d9e]) by smtp.gmail.com with ESMTPSA id b204sm31295339wmh.29.2019.03.26.04.17.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Mar 2019 04:17:16 -0700 (PDT) From: Mahesh Jethanandani Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Tue, 26 Mar 2019 12:17:15 +0100 To: Netconf X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [netconf] Adoption poll for tcp-client-server and http-client-server draft 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, 26 Mar 2019 11:17:31 -0000 This is the start of a two week poll for WG adoption of the two drafts: https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00 https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-00 Please indicate your support for or any objections you might have for = adopting the two drafts as WG items by April 9. Mahesh Jethanandani mjethanandani@gmail.com From nobody Tue Mar 26 04:55:55 2019 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 35F9C1202DB for ; Tue, 26 Mar 2019 04:55:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 pIBLIXWI75bt for ; Tue, 26 Mar 2019 04:55:51 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E18081202BC for ; Tue, 26 Mar 2019 04:55:50 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 8C59824; Tue, 26 Mar 2019 12:55:29 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id qw5G8Ax4zQ_4; Tue, 26 Mar 2019 12:55:29 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 26 Mar 2019 12:55:29 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C809200A8; Tue, 26 Mar 2019 12:55:29 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id 76ao6gh4JghD; Tue, 26 Mar 2019 12:55:29 +0100 (CET) Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 0081D200A7; Tue, 26 Mar 2019 12:55:29 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Tue, 26 Mar 2019 12:55:28 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 3597B30078FBD0; Tue, 26 Mar 2019 12:55:27 +0100 (CET) Date: Tue, 26 Mar 2019 12:55:27 +0100 From: Juergen Schoenwaelder To: Mahesh Jethanandani CC: Netconf Message-ID: <20190326115527.wssyesioa5oghy5t@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Mahesh Jethanandani , Netconf References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft 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, 26 Mar 2019 11:55:54 -0000 On Tue, Mar 26, 2019 at 12:17:15PM +0100, Mahesh Jethanandani wrote: > This is the start of a two week poll for WG adoption of the two drafts: > > https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00 > https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-00 > > Please indicate your support for or any objections you might have for adopting the two drafts as WG items by April 9. > I am seeing several grouping definitions spread out over a growing set of documents but there is a lack of explanation how all this fits together. For example, why do we really need tcp-client-grouping and ip-params-grouping and keepalives-grouping? Same question for tcp-server-grouping and ip-params-grouping and keepalives-grouping. Perhaps they can be collapsed into just one? A similar question could be asked for http-client-grouping and the helpers (?) http-client-identity-grouping and http-keepalives-grouping and the same for the server groupings. Is it really useful to define a grouping that only uses another grouping? It is also unclear to me what HTTP level keep alive messages are that a server sends to a client to check whether the client is still alive. Does it make sense to support a long list of client auth schemes or are we better supporting only basic ones and we add stuff later once we have experience with these models? HTTP servers usually have tons of other things you can configure that we do not cover and given the complexity we already have reached, perhaps it is fine to limit functionality in order to get something finished that can be used and then there is a time for a -bis to add what is missing. I support this work and the adoption of these drafts but we should set a clear target to get this work finished. I do very much appreciate Kent's continued work on this over the years in order to develop models for the relatively complex infrastructure needed to configure servers. But it may also be time to be pragmatic and to wrap this up, leaving things that can be added in later for future revisions and/or augmentations. The original WG document, draft-ietf-netconf-server-model-00, was posted in May 2014. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 26 05:44:29 2019 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 C3B5F12002F for ; Tue, 26 Mar 2019 05:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 cHZHmbT-b6Bw for ; Tue, 26 Mar 2019 05:44:25 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB6BC12000F for ; Tue, 26 Mar 2019 05:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2826; q=dns/txt; s=iport; t=1553604265; x=1554813865; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QI4bJXoOAwoqrbmGwoTZhS3XFqBkuoBwgvwP+WpN1CA=; b=O9Ff0cwRdCnjwdFaboBfa2b5EM1AA9gigePsG8RfAw/G+eVITw8QBCQr ggf+2/plgO8kkYIIdQzGcPZBANWAXHIs7uw+iK39jhOBDIV8AUDI1PtdW 81tz32fx8Qx9Dk9eswyz6CE0vOirDozeRRsqeTCWyg7I+I1oS/YUe8LYG A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAADpHZpc/5pdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBghBogQMnCplSmjYNAQEYC4QDRgKFIiI?= =?us-ascii?q?3Bg0BAQMBAQkBAwJtHAyFSgEBAQMBAQE4NAkCEAIBCA4oECcLJQIEAQ0FCIM?= =?us-ascii?q?bgW0ID645ii8FgS8BizEXgUA/gRGDEj6CYQEBgTsQhXcDmFiMQQkCkzEhggK?= =?us-ascii?q?SAIsdgReSGwIRFYEuNSKBVnAVO4JsiwyFP0ExjXCBLYEfAQE?= X-IronPort-AV: E=Sophos;i="5.60,271,1549929600"; d="scan'208";a="537831085" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 12:44:24 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x2QCiNIV016184 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Mar 2019 12:44:24 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 08:44:23 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Tue, 26 Mar 2019 08:44:23 -0400 From: "Eric Voit (evoit)" To: Martin Bjorklund , "balazs.lengyel@ericsson.com" CC: "netconf@ietf.org" Thread-Topic: [netconf] mbj review of draft-ietf-netconf-notification-capabilities-01 Thread-Index: AQHU48Tgf0toYk97E02xs+aQtFnAKKYd0l7w Date: Tue, 26 Mar 2019 12:44:23 +0000 Message-ID: References: <20190325.215637.1342845104682793774.mbj@tail-f.com> <20190326.121231.1546381642017000114.mbj@tail-f.com> In-Reply-To: <20190326.121231.1546381642017000114.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.163.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.154, xch-rtp-014.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [netconf] mbj review of draft-ietf-netconf-notification-capabilities-01 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, 26 Mar 2019 12:44:28 -0000 > > o General > > > > In YP, support for on-change is optional. There is a feature > > called "on-change". I think this document should state explicitly > > that this module is intended for servers that implement that > > feature. > > > > BALAZS: OK, but some other capacity related proerties are still valid. >=20 > What other capacity related properties do you mean? The latest draft allows minimum periodic reporting intervals to be set. ... > > o Section 3.2 > > > > minimum-dampening-period is optional. It should be stated what it > > means if this leaf is not present. (or should the default be 0?) > > > > BALAZS: If not present it means that the system does not tell you what > > it is. No special meaning. I do not see a reasonable minimum value > > (eventhough 0 would look strange). IMHO it is the responsibility of > > the server to provide a meaningful value. If it says zero, that's > > obviously crazy, just ignore it. I don't thing we need to have rules, > > like: do not provide stupid state data. >=20 > Note that 0 is the default in YP, so I don't know why you think it is cra= zy. >=20 > I suggest you add default "0" to this. I agree. > > o Section 3.2 > > > > The choice update-period is not mandatory, and doesn't have a > > default. What does it mean if this is not reported? > > > > BALAZS: If not present it means that the system does not tell you what > > it is. No special meaning. >=20 > I think this should be clarified in the description. >=20 > > o Section 3.2 > > > > The leaf max-objects-per-update is not mandatory. What does it mean > > if this is not reported? It can have the value 0. What does that > > mean? > > > > BALAZS: If not present it means that the system does not tell you what > > it is. No special meaning. > > > > I do not see a reasonable minimum value (eventhough 0 would look > > strange). IMHO it is the responsibility of the server to provide a > > meaningful value. If it says zero, that's obviously crazy, just ignore > > it. >=20 > I suggest you add a range "1..max" to the type. Is max necessary? I would assume that when this is not populated, it is = by default max (per below). Eric =20 > > Perhaps make a union of uint32 0..max and the enum "infinite" and > > make that the default? (of course "infinite" is not really > > correct...) > > > > BALAZS: IMHO infinite is unreasonable. If the server doesn't know the > > real limit, it should just not provide a value. >=20 > Ok, makes sense. I think this should be clarified in the description. >=20 >=20 > /martin >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Mar 26 06:01:11 2019 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 0B94C120043 for ; Tue, 26 Mar 2019 06:01:10 -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, 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 QU9nJVFZ0U4Y for ; Tue, 26 Mar 2019 06:01:07 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 81986120003 for ; Tue, 26 Mar 2019 06:01:07 -0700 (PDT) Received: from localhost (dhcp-97ad.meeting.ietf.org [31.133.151.173]) by mail.tail-f.com (Postfix) with ESMTPSA id 505E01AE08F1; Tue, 26 Mar 2019 14:01:05 +0100 (CET) Date: Tue, 26 Mar 2019 14:01:02 +0100 (CET) Message-Id: <20190326.140102.310852457337101560.mbj@tail-f.com> To: evoit@cisco.com Cc: balazs.lengyel@ericsson.com, netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <20190326.121231.1546381642017000114.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] mbj review of draft-ietf-netconf-notification-capabilities-01 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, 26 Mar 2019 13:01:10 -0000 "Eric Voit (evoit)" wrote: > > > o General > > > > > > In YP, support for on-change is optional. There is a feature > > > called "on-change". I think this document should state explicitly > > > that this module is intended for servers that implement that > > > feature. > > > > > > BALAZS: OK, but some other capacity related proerties are still valid. > > > > What other capacity related properties do you mean? > > The latest draft allows minimum periodic reporting intervals to be set. Ok. Then perhaps the nodes that are specific to on-change should have a if-feature "yp:on-change". > > > o Section 3.2 > > > > > > minimum-dampening-period is optional. It should be stated what it > > > means if this leaf is not present. (or should the default be 0?) > > > > > > BALAZS: If not present it means that the system does not tell you what > > > it is. No special meaning. I do not see a reasonable minimum value > > > (eventhough 0 would look strange). IMHO it is the responsibility of > > > the server to provide a meaningful value. If it says zero, that's > > > obviously crazy, just ignore it. I don't thing we need to have rules, > > > like: do not provide stupid state data. > > > > Note that 0 is the default in YP, so I don't know why you think it is crazy. > > > > I suggest you add default "0" to this. > > I agree. > > > > o Section 3.2 > > > > > > The choice update-period is not mandatory, and doesn't have a > > > default. What does it mean if this is not reported? > > > > > > BALAZS: If not present it means that the system does not tell you what > > > it is. No special meaning. > > > > I think this should be clarified in the description. > > > > > o Section 3.2 > > > > > > The leaf max-objects-per-update is not mandatory. What does it mean > > > if this is not reported? It can have the value 0. What does that > > > mean? > > > > > > BALAZS: If not present it means that the system does not tell you what > > > it is. No special meaning. > > > > > > I do not see a reasonable minimum value (eventhough 0 would look > > > strange). IMHO it is the responsibility of the server to provide a > > > meaningful value. If it says zero, that's obviously crazy, just ignore > > > it. > > > > I suggest you add a range "1..max" to the type. > > Is max necessary? I would assume that when this is not populated, > it is by default max (per below). Currently the type is just a uint32. I think we should limit the range so that 0 is not a valid value. The way to do that in YANG is: type uint32 { range "1..max"; } /martin > > Eric > > > > Perhaps make a union of uint32 0..max and the enum "infinite" and > > > make that the default? (of course "infinite" is not really > > > correct...) > > > > > > BALAZS: IMHO infinite is unreasonable. If the server doesn't know the > > > real limit, it should just not provide a value. > > > > Ok, makes sense. I think this should be clarified in the description. > > > > > > /martin > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > From nobody Tue Mar 26 06:03:10 2019 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 C2BAA120004; Tue, 26 Mar 2019 06:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de 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 8BnINJ2jB7hn; Tue, 26 Mar 2019 06:02:56 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D2E120003; Tue, 26 Mar 2019 06:02:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id B29EE25A22; Tue, 26 Mar 2019 14:02:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1553605374; bh=jQKirudCDBmxrjcpH5KNUiGIjjG5LPut39AqeV/ZSzw=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=SoWZCg4k1g2sG1/hWXfvotdN/nHpgnu4o0IMu3SFaAsnniB5TU15dF7xdjX9foy5n l29crN7eRBwlSEQ9QSZxvnt1ukenAKr3SUmTR1I1KEu0WkSS2yOKl8nvNXEvjNE5U1 cigZFk0cKATjYgJiebke4BTRuKk/aW7TqOPirtJk= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QHBOvI5q8Fr; Tue, 26 Mar 2019 14:02:49 +0100 (CET) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 26 Mar 2019 14:02:49 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.111]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Tue, 26 Mar 2019 14:02:49 +0100 From: "Scharf, Michael" To: Mahesh Jethanandani , Netconf CC: "tcpm@ietf.org" Thread-Topic: [netconf] Adoption poll for tcp-client-server and http-client-server draft Thread-Index: AQHU48WN++elmQAJ10utC4WVEX8JVqYd0z1Q Date: Tue, 26 Mar 2019 13:02:49 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D282BBC@rznt8114.rznt.rzdir.fht-esslingen.de> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft 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, 26 Mar 2019 13:03:02 -0000 Hi Mahesh, As chair of the TCPM working group, I believe that the document draft-kwats= en-netconf-tcp-client-server-00 belongs into the TCPM working group. The do= cument is about a generic YANG model for an interface for TCP "for an SSH, = TLS, or HTTP based application". I fail to see a reason why such a generic = TCP model should be done in NETCONF. Thus, as a chair of TCPM, I object to adoption in NETCONF. I also want to note that it would have been possible to send a note to the = TCPM list prior to starting an adoption call, as the TCPM list is monitored= by many TCP implementers who could be affected by such a YANG model. YANG = models can be used in different use cases. TCPM has a tradition of being ve= ry open to presentations from other working groups if they relate to TCP. I= have added the TCPM list in CC. As an individual contributor to the IETF, I happen to be an author of draft= -scharf-tcpm-yang-tcp, which actually was submitted last year. Given that d= ifferent working groups seem to be involved, I believe that it would make s= ense to join efforts. Shouldn't we have a chat on the best next steps? Thanks Michael > -----Original Message----- > From: netconf On Behalf Of Mahesh > Jethanandani > Sent: Tuesday, March 26, 2019 12:17 PM > To: Netconf > Subject: [netconf] Adoption poll for tcp-client-server and http-client-se= rver > draft >=20 > This is the start of a two week poll for WG adoption of the two drafts: >=20 > https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00 > https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-00 >=20 > Please indicate your support for or any objections you might have for > adopting the two drafts as WG items by April 9. >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Mar 26 07:19:19 2019 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 B060C1202F0; Tue, 26 Mar 2019 07:19:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 I4aEgRYXF76d; Tue, 26 Mar 2019 07:19:09 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC4C11202EE; Tue, 26 Mar 2019 07:19:08 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A8C826F4; Tue, 26 Mar 2019 15:19:07 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id a4S9LElk9ezY; Tue, 26 Mar 2019 15:19:07 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 26 Mar 2019 15:19:07 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 91952200A8; Tue, 26 Mar 2019 15:19:07 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id M2PdasdmXJoP; Tue, 26 Mar 2019 15:19:07 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 37839200A7; Tue, 26 Mar 2019 15:19:07 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Tue, 26 Mar 2019 15:19:06 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 2FB9730079D370; Tue, 26 Mar 2019 15:19:05 +0100 (CET) Date: Tue, 26 Mar 2019 15:19:05 +0100 From: Juergen Schoenwaelder To: "Scharf, Michael" CC: Mahesh Jethanandani , Netconf , "tcpm@ietf.org" Message-ID: <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Scharf, Michael" , Mahesh Jethanandani , Netconf , "tcpm@ietf.org" References: <6EC6417807D9754DA64F3087E2E2E03E2D282BBC@rznt8114.rznt.rzdir.fht-esslingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D282BBC@rznt8114.rznt.rzdir.fht-esslingen.de> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft 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, 26 Mar 2019 14:19:12 -0000 Dear Michael, please note that a configuration model for NETCONF is on the NETCONF charter for ~5 years. To establish NETCONF session, we obviously need to establish TCP connections. This is what this work does. It is entirely orthogonal to draft-scharf-tcpm-yang-tcp, which talks about TCP protocol engine internals. If the TCPM chair has an issue with a generic solution to establish TCP connection not being done in TCPM, we should perhaps just hardcode how to establish TCP connections for NETCONF and RESTCONF and call it the day and then TCPM can pick up the pieces and start work on a generic solution. /js On Tue, Mar 26, 2019 at 01:02:49PM +0000, Scharf, Michael wrote: > Hi Mahesh, > > As chair of the TCPM working group, I believe that the document draft-kwatsen-netconf-tcp-client-server-00 belongs into the TCPM working group. The document is about a generic YANG model for an interface for TCP "for an SSH, TLS, or HTTP based application". I fail to see a reason why such a generic TCP model should be done in NETCONF. > > Thus, as a chair of TCPM, I object to adoption in NETCONF. > > I also want to note that it would have been possible to send a note to the TCPM list prior to starting an adoption call, as the TCPM list is monitored by many TCP implementers who could be affected by such a YANG model. YANG models can be used in different use cases. TCPM has a tradition of being very open to presentations from other working groups if they relate to TCP. I have added the TCPM list in CC. > > As an individual contributor to the IETF, I happen to be an author of draft-scharf-tcpm-yang-tcp, which actually was submitted last year. Given that different working groups seem to be involved, I believe that it would make sense to join efforts. Shouldn't we have a chat on the best next steps? > > Thanks > > Michael > > > > -----Original Message----- > > From: netconf On Behalf Of Mahesh > > Jethanandani > > Sent: Tuesday, March 26, 2019 12:17 PM > > To: Netconf > > Subject: [netconf] Adoption poll for tcp-client-server and http-client-server > > draft > > > > This is the start of a two week poll for WG adoption of the two drafts: > > > > https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00 > > https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-00 > > > > Please indicate your support for or any objections you might have for > > adopting the two drafts as WG items by April 9. > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 26 07:20:52 2019 Return-Path: <01000169ba5f9050-5d5f75b7-3aef-4803-9d62-85b3c207c254-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 CB166120341 for ; Tue, 26 Mar 2019 07:20:45 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 aSCrJXLLd-fI for ; Tue, 26 Mar 2019 07:20:43 -0700 (PDT) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CB6412030B for ; Tue, 26 Mar 2019 07:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553610019; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=mYW9fSCc80IegpY2U/hLWVDZOjm6TrTyA+Bs/7wIbfw=; b=YxqvyYDqBGIf5YLzMbrAP/gPi2kfXWhfLU47fi2O7dkiVQZ3IWKf1tMwv2Fvdm+1 gtoc/tj4piZSqZK4CBXOnqmdOpky6iAR3pO1v3WajumN7n9B24emcp4GpSMJUU4wxtj SE9YUQuHwCO8yZgSvWsEdps5o/6XnVN1MWrCS528= Content-Type: multipart/alternative; boundary=Apple-Mail-F1121915-964E-40AA-951E-809E41640D7D Mime-Version: 1.0 (1.0) From: Kent Watsen X-Mailer: iPad Mail (16D57) In-Reply-To: <20190326115527.wssyesioa5oghy5t@anna.jacobs.jacobs-university.de> Date: Tue, 26 Mar 2019 14:20:18 +0000 Cc: Mahesh Jethanandani , Netconf Content-Transfer-Encoding: 7bit Message-ID: <01000169ba5f9050-5d5f75b7-3aef-4803-9d62-85b3c207c254-000000@email.amazonses.com> References: <20190326115527.wssyesioa5oghy5t@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-SES-Outgoing: 2019.03.26-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft 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, 26 Mar 2019 14:20:46 -0000 --Apple-Mail-F1121915-964E-40AA-951E-809E41640D7D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Juergen, > I am seeing several grouping definitions spread out over a growing set > of documents but there is a lack of explanation how all this fits > together. For example, why do we really need tcp-client-grouping and > ip-params-grouping and keepalives-grouping? Same question for > tcp-server-grouping and ip-params-grouping and keepalives-grouping. > Perhaps they can be collapsed into just one? >=20 > A similar question could be asked for http-client-grouping and the > helpers (?) http-client-identity-grouping and http-keepalives-grouping > and the same for the server groupings. Is it really useful to define a > grouping that only uses another grouping? It is also unclear to me > what HTTP level keep alive messages are that a server sends to a > client to check whether the client is still alive. Agreed. This was issue #6 on slide 16 here [1] as well on-list here [2]. T= he TL;DR; is that these breakout-groupings will be collapsed. [1] https://datatracker.ietf.org/meeting/104/materials/slides-104-netconf-cr= ypto-types-clientserver-suite-of-drafts-00.pdf [2] https://mailarchive.ietf.org/arch/msg/netconf/4IqxP5kZAqQjP6BFmiHOTuPQJa= o > Does it make sense to support a long list of client auth schemes or > are we better supporting only basic ones and we add stuff later once > we have experience with these models? HTTP servers usually have tons > of other things you can configure that we do not cover and given the > complexity we already have reached, perhaps it is fine to limit > functionality in order to get something finished that can be used and > then there is a time for a -bis to add what is missing. This was issue #5 also on slide 16 [1] (link above). =20 RFC 8040, Section 2.5 says =E2=80=9C...one of the HTTP authentication scheme= s defined in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme R= egistry" (Section 5.1 in [RFC7235]) MUST be used.=E2=80=9D Following the po= inter, that section says: The "Hypertext Transfer Protocol (HTTP) Authentication Scheme=20 Registry" defines the namespace for the authentication schemes in challenges and credentials. It has been created and is now maintained at . Going to the IANA site, you=E2=80=99ll find the complete list of HTTP auth s= chemes listed in the ietf-http-client module. I=E2=80=99m only explaining h= ow the list came to be. =20 =46rom the presentation yesterday, you know that the configuration for some o= f these schemes is TBD. I started filling them in, but I didn=E2=80=99t hav= e the time to figure them out. Yesterday=E2=80=99s presentation was really a= call for help (please, co-authors are welcomed!). Another way to resolve t= he issue is to do as you say, just support the most popular auth schemes, th= ough 1) is that okay given RFC 8040 and 2) I don=E2=80=99t know which auth s= chemes are most popular. I agree that we only want to do the bare minimum to have a viable release, b= ut I=E2=80=99m of the opinion that, if you do something, do it right. For H= TTP, the only things I think we need to consider are: client auth, keepalive= s, and HTTP proxy. I do not think we should attempt to cover any other para= meters common with HHTP servers. Note: this was issue #4 on slide 16 in [1]= (link above) > I support this work and the adoption of these drafts but we should set > a clear target to get this work finished. I do very much appreciate > Kent's continued work on this over the years in order to develop > models for the relatively complex infrastructure needed to configure > servers. But it may also be time to be pragmatic and to wrap this up, > leaving things that can be added in later for future revisions and/or > augmentations. Absolutely, let=E2=80=99s get this done. As mentioned in the meeting yester= day, we hope to get these to LC in a couple month=E2=80=99s time (though the= TCPM issue just raised might cause delay). Kent // contributor > The original WG document, draft-ietf-netconf-server-model-00, was > posted in May 2014. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail-F1121915-964E-40AA-951E-809E41640D7D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Juergen,

I am seeing several grouping definitions spread ou= t over a growing set
of documents but there is a lack of exp= lanation how all this fits
together. For example, why do we r= eally need tcp-client-grouping and
ip-params-grouping and ke= epalives-grouping? Same question for
tcp-server-grouping and= ip-params-grouping and keepalives-grouping.
Perhaps they ca= n be collapsed into just one?

A similar que= stion could be asked for http-client-grouping and the
helper= s (?) http-client-identity-grouping and http-keepalives-grouping
<= span>and the same for the server groupings. Is it really useful to define a<= /span>
grouping that only uses another grouping? It is also unclear= to me
what HTTP level keep alive messages are that a server= sends to a
client to check whether the client is still aliv= e.

Agreed.  This was i= ssue #6 on slide 16 here [1] as well on-list here [2].  The TL;DR; is t= hat these breakout-groupings will be collapsed.


Does it make sense to support a long list of client auth schemes or<= /span>
are we better supporting only basic ones and we add stuff la= ter once
we have experience with these models? HTTP servers u= sually have tons
of other things you can configure that we d= o not cover and given the
complexity we already have reached= , perhaps it is fine to limit
functionality in order to get s= omething finished that can be used and
then there is a time f= or a -bis to add what is missing.

This was issue #5 also on slide 16 [1] (link above).  

RFC 8040, Section 2.5 says =E2=80=9C...one of the HTTP authentication schemes define= d in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" (Section 5.1 in [RFC7235]) MUST be used.=E2=80=9D  Following the pointer, that section says:
    The "Hypertext Transfer Protocol (HTTP) Authentication Scheme=
 
    Registry" defines the namespace for the authentication schemes =
in
    challenges and credentials.  It has bee=
n created and is now
   maintained
    at  <http://www.iana.org/assignments/http-aut=
hschemes>.

Going to the IANA site, you=E2=80=99ll find the complete l=
ist of HTTP auth schemes listed in the ietf-http-client module.  I=E2=80=99m only explaining how the list came to be.    

=46rom the p=
resentation yesterday, you know that the configuration for some of these sch=
emes is TBD.  I started filling them in, but I didn=E2=80=99t have the t=
ime to figure them out.  Yesterday=E2=80=99s presentation was really a c=
all for help (please, co-authors are welcomed!).  Another way to resolv=
e the issue is to do as you say, just support the most popular auth schemes,=
 though 1) is that okay given RFC 8040 and 2) I don=E2=80=99t know which aut=
h schemes are most popular.

I agree that we only want to do the bare minimum to h=
ave a viable release, but I=E2=80=99m of the opinion that, if you do somethi=
ng, do it right.  For HTTP, the only things I think we need to consider=
 are: client auth, keepalives, and HTTP proxy.  I do not think we shoul=
d attempt to cover any other parameters common with HHTP servers.  Note=
: this was issue #4 on slide 16 in [1] (link above)

=

I su= pport this work and the adoption of these drafts but we should seta clear target to get this work finished. I do very much appreciate
Kent's continued work on this over the years in order to deve= lop
models for the relatively complex infrastructure needed t= o configure
servers. But it may also be time to be pragmatic= and to wrap this up,
leaving things that can be added in la= ter for future revisions and/or
augmentations.

Absolutely, let=E2=80=99s get this done.=  As mentioned in the meeting yesterday, we hope to get these to LC in a= couple month=E2=80=99s time (though the TCPM issue just raised might cause d= elay).

Kent // contributor


The original WG docu= ment, draft-ietf-netconf-server-model-00, was
posted in May 2= 014.

/js

-= -
Juergen Schoenwaelder       = ;    Jacobs University Bremen gGmbH
Phon= e: +49 421 200 3587         Campus R= ing 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3= 103         <https://www.jacobs-university.de/>
_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
= --Apple-Mail-F1121915-964E-40AA-951E-809E41640D7D-- From nobody Tue Mar 26 07:30:43 2019 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 CAC601202CC for ; Tue, 26 Mar 2019 07:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 wacgNu9O5Flr for ; Tue, 26 Mar 2019 07:30:38 -0700 (PDT) Received: from us-smtp-delivery-128.mimecast.com (us-smtp-delivery-128.mimecast.com [63.128.21.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385021202F1 for ; Tue, 26 Mar 2019 07:30:36 -0700 (PDT) Received: from ex-hc3.corp.adtran.com (ex-hc2.adtran.com [76.164.174.82]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-324-ODgt68_jMkevmUcIIX5bZQ-1; Tue, 26 Mar 2019 10:30:33 -0400 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc3.corp.adtran.com ([fe80::3892:20fa:600f:75c6%15]) with mapi id 14.03.0382.000; Tue, 26 Mar 2019 09:30:32 -0500 From: NICK HANCOCK To: Mahesh Jethanandani , Netconf Thread-Topic: [netconf] Adoption poll for tcp-client-server and http-client-server draft Thread-Index: AQHU48WK88pkUu3tWEqeuFS0y837C6Yd+NxQ Date: Tue, 26 Mar 2019 14:30:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.48.41] MIME-Version: 1.0 X-MC-Unique: ODgt68_jMkevmUcIIX5bZQ-1 X-Mimecast-Spam-Score: 0 Content-Type: multipart/alternative; boundary="_000_BD6D193629F47C479266C0985F16AAC7011EA6336Bexmb1corpadtr_" Archived-At: Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft 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, 26 Mar 2019 14:30:42 -0000 --_000_BD6D193629F47C479266C0985F16AAC7011EA6336Bexmb1corpadtr_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable I support this work to provide the ability to configure TCP keepalives for = NETCONF connections as we need this support in our implementations and supp= ort the adoption of these drafts. I also have the following comments on the actual YANG implementation and us= age within the client/server model. The leafs within the "tcp-keepalives" container are optional. Given that a = server supports the feature "tcp-client-keepalives", TCP keepalives would b= e disabled per default through missing configuration, which I believe is de= sirable behavior. However, there is currently nothing to prevent a client c= onfiguring, say, just 'max-probes' only resulting in an incomplete but vali= d configuration. Would not adding a 'presence' statement to the container "= tcp-keepalives" and making its child nodes mandatory or adding default valu= es be a more practical solution that defines a predictable behavior? Since TCP is a layer below the security layer and independent of the choice= of security protocol, I was wondering what the motivation was for locating= the TCP keepalives configuration within the SSH/TLS configuration. Wouldn'= t this be better located as a sibling nod to the choice "transport"? Nick From: netconf On Behalf Of Mahesh Jethanandani Sent: 26 March 2019 12:17 To: Netconf Subject: [netconf] Adoption poll for tcp-client-server and http-client-serv= er draft This is the start of a two week poll for WG adoption of the two drafts: https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00 https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-00 Please indicate your support for or any objections you might have for adopt= ing the two drafts as WG items by April 9. Mahesh Jethanandani mjethanandani@gmail.com _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_BD6D193629F47C479266C0985F16AAC7011EA6336Bexmb1corpadtr_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

I support this work to provide the ab= ility to configure TCP keepalives for NETCONF connections as we need this s= upport in our implementations and support the adoption of these drafts.

 

I also have the following comments on= the actual YANG implementation and usage within the client/server model.

 

The leafs within the “tcp-keepa= lives” container are optional. Given that a server supports the featu= re “tcp-client-keepalives”, TCP keepalives would be disabled per default through missing configuration, which I believe is desirable be= havior. However, there is currently nothing to prevent a client configuring= , say, just ‘max-probes’ only resulting in an incomplete but va= lid configuration. Would not adding a ‘presence’ statement to the container “tcp-keepalives” and making its chi= ld nodes mandatory or adding default values be a more practical solution th= at defines a predictable behavior?

 

Since TCP is a layer below the securi= ty layer and independent of the choice of security protocol, I was wonderin= g what the motivation was for locating the TCP keepalives configuration within the SSH/TLS configuration. Wouldn’t = this be better located as a sibling nod to the choice “transport̶= 1;?

 

Nick=

 

From: netconf <netconf-bounces@ietf.org> On Behalf Of Mahesh Jethanandani
Sent: 26 March 2019 12:17
To: Netconf <netconf@ietf.org>
Subject: [netconf] Adoption poll for tcp-client-server and http-clie= nt-server draft

 

This is the start of a two week poll for WG adoption= of the two drafts:

https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server= -00
https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-serv= er-00

Please indicate your support for or any objections you might have for adopt= ing the two drafts as WG items by April 9.

Mahesh Jethanandani
mjethanandani@gmail.com



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

--_000_BD6D193629F47C479266C0985F16AAC7011EA6336Bexmb1corpadtr_-- From nobody Tue Mar 26 07:52:55 2019 Return-Path: <01000169ba7d39d8-b3f6bfca-17a6-4c01-bd1c-81f5270f1476-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 6A10B12032C; Tue, 26 Mar 2019 07:52:47 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 iFTnC3cu4Dxs; Tue, 26 Mar 2019 07:52:45 -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 AD3BC120306; Tue, 26 Mar 2019 07:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553611963; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=BTaMq4uUMWPT9AwwnpydH7oJmQvO+zFFPzIjkYU/N/o=; b=NInVSQCDwp3js///NQRb5ZIthyKXoqKNfAQHs8tMWBVgNhaI7G8HE/eJfbpDHKFi 8Fw2OdNiG72y2splnJAXjYKbztIoPnZf2V+OV71ggwFPSkvNI1/sUcZmf/WtLFBQPtY J/1OlzGAJmkVPW5rm5+H7vPwbORYZ+gRrABhB+o8= Content-Type: multipart/alternative; boundary=Apple-Mail-DA4BF792-9E39-444C-9302-15471121A18E Mime-Version: 1.0 (1.0) From: Kent Watsen X-Mailer: iPad Mail (16D57) In-Reply-To: <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de> Date: Tue, 26 Mar 2019 14:52:42 +0000 Cc: "Scharf, Michael" , "tcpm@ietf.org" , Netconf Content-Transfer-Encoding: 7bit Message-ID: <01000169ba7d39d8-b3f6bfca-17a6-4c01-bd1c-81f5270f1476-000000@email.amazonses.com> References: <6EC6417807D9754DA64F3087E2E2E03E2D282BBC@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-SES-Outgoing: 2019.03.26-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft 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, 26 Mar 2019 14:52:47 -0000 --Apple-Mail-DA4BF792-9E39-444C-9302-15471121A18E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Wait, I don=E2=80=99t think we need to do anything drastic here. Michael, please note that the TCP modules here are intended to be very limit= ed in scope, just the bare minimum necessary to support the NETCONF/RESTCONF= that (in case you don=E2=80=99t know) are layered on top of SSH and TLS, an= d hence TCP. The bare minimum appears to be just addresses, ports, and keep= -alives. The NETCONF WG has NO interest in extending this module beyond th= is minimal amount. Additionally, please see Slide 9 here [1] and note that this module is part o= f a rather large eco-system of interrelated modules. The point being is tha= t the reason for it being structured the way it is (e.g., as groupings) is p= retty well justified. My proposal is as follows: 1) Let=E2=80=99s (as co-authors) get the draft-kwatsen-netconf-tcp-client-= server-00 with it=E2=80=99s current scope to RFC status ASAP (a couple months), s= o that this five-year NETCONF project can end. Happy to tweak it as you see fit. = =20 Which WG does this is not important, but for a time-expediency perspec= tive, I recommend the NETCONF WG due to the heavy interlinking mentioned before. 2) TCPM takes over the RFC, publishing a bis with all the extra parameters= that are in draft-scharf-tcpm-yang-tcp. TCPM could even do this work= in parallel, so as to not cause any scheduling delays. Thoughts? Can we have a short-term collaboration and then let TCPM take ove= r? [1] https://datatracker.ietf.org/meeting/104/materials/slides-104-netconf-cr= ypto-types-clientserver-suite-of-drafts-00.pdf PS: Let=E2=80=99s (+ co-chairs) meet up today/tomorrow. Kent // contributor=20 > On Mar 26, 2019, at 3:19 PM, Juergen Schoenwaelder wrote: >=20 > Dear Michael, >=20 > please note that a configuration model for NETCONF is on the NETCONF > charter for ~5 years. To establish NETCONF session, we obviously need > to establish TCP connections. This is what this work does. It is > entirely orthogonal to draft-scharf-tcpm-yang-tcp, which talks about > TCP protocol engine internals. If the TCPM chair has an issue with a > generic solution to establish TCP connection not being done in TCPM, > we should perhaps just hardcode how to establish TCP connections for > NETCONF and RESTCONF and call it the day and then TCPM can pick up the > pieces and start work on a generic solution. >=20 > /js >=20 >> On Tue, Mar 26, 2019 at 01:02:49PM +0000, Scharf, Michael wrote: >> Hi Mahesh, >>=20 >> As chair of the TCPM working group, I believe that the document draft-kwa= tsen-netconf-tcp-client-server-00 belongs into the TCPM working group. The d= ocument is about a generic YANG model for an interface for TCP "for an SSH, T= LS, or HTTP based application". I fail to see a reason why such a generic TC= P model should be done in NETCONF. >>=20 >> Thus, as a chair of TCPM, I object to adoption in NETCONF. >>=20 >> I also want to note that it would have been possible to send a note to th= e TCPM list prior to starting an adoption call, as the TCPM list is monitore= d by many TCP implementers who could be affected by such a YANG model. YANG m= odels can be used in different use cases. TCPM has a tradition of being very= open to presentations from other working groups if they relate to TCP. I ha= ve added the TCPM list in CC. >>=20 >> As an individual contributor to the IETF, I happen to be an author of dra= ft-scharf-tcpm-yang-tcp, which actually was submitted last year. Given that d= ifferent working groups seem to be involved, I believe that it would make se= nse to join efforts. Shouldn't we have a chat on the best next steps? >>=20 >> Thanks >>=20 >> Michael >>=20 >>=20 >>> -----Original Message----- >>> From: netconf On Behalf Of Mahesh >>> Jethanandani >>> Sent: Tuesday, March 26, 2019 12:17 PM >>> To: Netconf >>> Subject: [netconf] Adoption poll for tcp-client-server and http-client-s= erver >>> draft >>>=20 >>> This is the start of a two week poll for WG adoption of the two drafts: >>>=20 >>> https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00 >>> https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-00 >>>=20 >>> Please indicate your support for or any objections you might have for >>> adopting the two drafts as WG items by April 9. >>>=20 >>> Mahesh Jethanandani >>> mjethanandani@gmail.com >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> netconf mailing list >>> netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>=20 >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail-DA4BF792-9E39-444C-9302-15471121A18E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Wait, I don=E2=80=99t think w= e need to do anything drastic here.

Michael, please note t= hat the TCP modules here are intended to be very limited in scope, just the b= are minimum necessary to support the NETCONF/RESTCONF that (in case you don=E2= =80=99t know) are layered on top of SSH and TLS, and hence TCP.  The ba= re minimum appears to be just addresses, ports, and keep-alives.   The N= ETCONF WG has NO interest in extending this module beyond this minimal amoun= t.

Additionally, please see Slide 9 here [1] and no= te that this module is part of a rather large eco-system of interrelated mod= ules.  The point being is that the reason for it being  structured= the way it is (e.g., as groupings) is pretty well justified.

=
My proposal is as follows:

  1) Let= =E2=80=99s (as co-authors) get the draft-kwatsen-netconf-tcp-client-server-00
    &nb= sp; with it=E2=80=99s current scope to RFC status ASAP (a couple months), so= that this
      five-year NETCONF project can end.  Happy to tw= eak it as you see fit.  
      Which WG does this is = ;not import= ant, but for a time-expediency perspective,
      I recommend t= he NET= CONF WG due to the heavy interlinking mentioned
      before.<= /span>
<= br>
  2) TCPM takes over the RFC, publishing a bis with all the extra pa= rameters
       that are in draft-scharf-tcpm-yang-tcp.  T= CPM could even do this work
       in parallel, so as to n= ot cause any scheduling delays.

Thoughts? &n= bsp;Can we have a short-term collaboration and then let TCPM take over?


=

PS: Let=E2=80=99s (+ co-chairs) meet up today/tomorrow.<= /div>

Kent // contributor 


On Mar 26, 2019, at 3:19 PM, Juergen Sc= hoenwaelder <j.sc= hoenwaelder@jacobs-university.de> wrote:

Dear Michael,

<= span>please note that a configuration model for NETCONF is on the NETCONF
charter for ~5 years. To establish NETCONF session, we obvious= ly need
to establish TCP connections. This is what this work= does. It is
entirely orthogonal to draft-scharf-tcpm-yang-t= cp, which talks about
TCP protocol engine internals. If the T= CPM chair has an issue with a
generic solution to establish T= CP connection not being done in TCPM,
we should perhaps just= hardcode how to establish TCP connections for
NETCONF and R= ESTCONF and call it the day and then TCPM can pick up the
pi= eces and start work on a generic solution.

= /js

On Tue, Mar 26, 2019 at 01:02:49PM +000= 0, Scharf, Michael wrote:
Hi Mahes= h,

As chair of the TCPM working group, I b= elieve that the document draft-kwatsen-netconf-tcp-client-server-00 belongs i= nto the TCPM working group. The document is about a generic YANG model for a= n interface for TCP "for an SSH, TLS, or HTTP based application". I fail to s= ee a reason why such a generic TCP model should be done in NETCONF.

Thus, as a chair of TCPM, I object to adoption in= NETCONF.

=
I also want to note that it wou= ld have been possible to send a note to the TCPM list prior to starting an a= doption call, as the TCPM list is monitored by many TCP implementers who cou= ld be affected by such a YANG model. YANG models can be used in different us= e cases. TCPM has a tradition of being very open to presentations from other= working groups if they relate to TCP. I have added the TCPM list in CC.

=
As an individual contributor to the IETF, I h= appen to be an author of draft-scharf-tcpm-yang-tcp, which actually was subm= itted last year. Given that different working groups seem to be involved, I b= elieve that it would make sense to join efforts. Shouldn't we have a chat on= the best next steps?

Thanks

Michael

----= -Original Message-----
From: netconf <netconf-bounces@ietf.org> On Behalf Of Mahes= h
Jethanandani
Sent: Tuesday, March 26, 2= 019 12:17 PM
<= blockquote type=3D"cite">To: Netconf <netconf@ietf.org>
Subject: [netconf] Adoptio= n poll for tcp-client-server and http-client-server
<= /blockquote>
draft<= /span>

This is the start of a two week poll fo= r WG adoption of the two drafts:

<= /blockquote>
https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00<= /span>
https://tools.ietf.org/html/draft-kwatsen-netconf-= http-client-server-00

Please indica= te your support for or any objections you might have for
a= dopting the two drafts as WG items by April 9.

=
Mahesh Jethanandani
mjethanandani@gmail.com
=



______________________________________= _________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/= listinfo/netconf

_______= ________________________________________
netconf mailing list
netconf@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/n= etconf

--
Juergen Schoenwaelder          = ; Jacobs University Bremen gGmbH
Phone: +49 421 200 358= 7         Campus Ring 1 | 28759 Brem= en | Germany
Fax:   +49 421 200 3103   &= nbsp;     <https://www.jacobs-university.de/>
_______________________________________________
netc= onf mailing list
netconf= @ietf.org
https://www.ietf.org/mailman/listinfo/netconf
= --Apple-Mail-DA4BF792-9E39-444C-9302-15471121A18E-- From nobody Tue Mar 26 07:54:44 2019 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 37D4D120369; Tue, 26 Mar 2019 07:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de 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 SuYpFmGn6fAY; Tue, 26 Mar 2019 07:54:41 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96D8120306; Tue, 26 Mar 2019 07:54:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 1C28B25A13; Tue, 26 Mar 2019 15:54:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1553612079; bh=lS6RMbEAoVEk6UYXkFnHWgMAF+uIpwl/U0N70B25sgo=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=X6RtOWcICsrTa/ltkV7frNcV67K4xps2+mBC9yVEKCgSDLn4SVzqLtynqT7RDOkib RsH6yLscscAMMSri0lQrQk7tj8hO9CUWoQtbDnpOzC8UDKxQRfBhmhlIvseqoeADn6 mQOjs+qclTyGRFL5iT9u5cd2XSMBREHdPOxdGEJ0= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlLl1GRGtFZd; Tue, 26 Mar 2019 15:54:37 +0100 (CET) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 26 Mar 2019 15:54:37 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.111]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Tue, 26 Mar 2019 15:54:37 +0100 From: "Scharf, Michael" To: Juergen Schoenwaelder CC: Mahesh Jethanandani , Netconf , "tcpm@ietf.org" Thread-Topic: [netconf] Adoption poll for tcp-client-server and http-client-server draft Thread-Index: AQHU48WN++elmQAJ10utC4WVEX8JVqYd0z1QgAASMICAABHsoA== Date: Tue, 26 Mar 2019 14:54:36 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D28349A@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D282BBC@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de> In-Reply-To: <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft 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, 26 Mar 2019 14:54:44 -0000 Hi Juergen, The document includes TCP keepalives configuration and this is actually abo= ut TCP protocol engine internals, no? And I fail to see the benefit of doing TCP YANG modeling specific to NETCON= F or RESTCONF. For instance, on a router, I believe that NETCONF, RESTCONF,= BGP and LDP could use the same TCP stack, as well as possibly all other TC= P-based protocols running on the NE. And if HTTP is included, YANG models h= ave a pretty broad applicability beyond routers. So what makes NETCONF or R= ESTCONF so special that NETCONF needs its own model? As I mentioned, in the last years TCPM has been extremely open to TCP-relat= ed needs in other working groups and we have quite successful cross-area wo= rk.=20 Michael > -----Original Message----- > From: Juergen Schoenwaelder > Sent: Tuesday, March 26, 2019 3:19 PM > To: Scharf, Michael > Cc: Mahesh Jethanandani ; Netconf > ; tcpm@ietf.org > Subject: Re: [netconf] Adoption poll for tcp-client-server and http-clien= t- > server draft >=20 > Dear Michael, >=20 > please note that a configuration model for NETCONF is on the NETCONF > charter for ~5 years. To establish NETCONF session, we obviously need > to establish TCP connections. This is what this work does. It is > entirely orthogonal to draft-scharf-tcpm-yang-tcp, which talks about > TCP protocol engine internals. If the TCPM chair has an issue with a > generic solution to establish TCP connection not being done in TCPM, > we should perhaps just hardcode how to establish TCP connections for > NETCONF and RESTCONF and call it the day and then TCPM can pick up the > pieces and start work on a generic solution. >=20 > /js >=20 > On Tue, Mar 26, 2019 at 01:02:49PM +0000, Scharf, Michael wrote: > > Hi Mahesh, > > > > As chair of the TCPM working group, I believe that the document draft- > kwatsen-netconf-tcp-client-server-00 belongs into the TCPM working group. > The document is about a generic YANG model for an interface for TCP "for = an > SSH, TLS, or HTTP based application". I fail to see a reason why such a g= eneric > TCP model should be done in NETCONF. > > > > Thus, as a chair of TCPM, I object to adoption in NETCONF. > > > > I also want to note that it would have been possible to send a note to = the > TCPM list prior to starting an adoption call, as the TCPM list is monitor= ed by > many TCP implementers who could be affected by such a YANG model. > YANG models can be used in different use cases. TCPM has a tradition of > being very open to presentations from other working groups if they relate= to > TCP. I have added the TCPM list in CC. > > > > As an individual contributor to the IETF, I happen to be an author of d= raft- > scharf-tcpm-yang-tcp, which actually was submitted last year. Given that > different working groups seem to be involved, I believe that it would mak= e > sense to join efforts. Shouldn't we have a chat on the best next steps? > > > > Thanks > > > > Michael > > > > > > > -----Original Message----- > > > From: netconf On Behalf Of Mahesh > > > Jethanandani > > > Sent: Tuesday, March 26, 2019 12:17 PM > > > To: Netconf > > > Subject: [netconf] Adoption poll for tcp-client-server and http-clien= t- > server > > > draft > > > > > > This is the start of a two week poll for WG adoption of the two draft= s: > > > > > > https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-0= 0 > > > https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-= 00 > > > > > > Please indicate your support for or any objections you might have for > > > adopting the two drafts as WG items by April 9. > > > > > > Mahesh Jethanandani > > > mjethanandani@gmail.com > > > > > > > > > > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Tue Mar 26 08:34:17 2019 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 844231203FB; Tue, 26 Mar 2019 08:34:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 5c74ZK4NytZd; Tue, 26 Mar 2019 08:34:06 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708ED120435; Tue, 26 Mar 2019 08:34:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 04AA840; Tue, 26 Mar 2019 16:34:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id TfI6pCJ5pcyb; Tue, 26 Mar 2019 16:34:04 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 26 Mar 2019 16:34:04 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id BDD4A200A8; Tue, 26 Mar 2019 16:34:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id solL5DBM57iF; Tue, 26 Mar 2019 16:34:04 +0100 (CET) Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 7DCE0200A7; Tue, 26 Mar 2019 16:34:04 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Tue, 26 Mar 2019 16:34:03 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 925F530079D64E; Tue, 26 Mar 2019 16:34:03 +0100 (CET) Date: Tue, 26 Mar 2019 16:34:03 +0100 From: Juergen Schoenwaelder To: "Scharf, Michael" CC: Mahesh Jethanandani , Netconf , "tcpm@ietf.org" Message-ID: <20190326153403.sb4dzynlv2fxhvym@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Scharf, Michael" , Mahesh Jethanandani , Netconf , "tcpm@ietf.org" References: <6EC6417807D9754DA64F3087E2E2E03E2D282BBC@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de> <6EC6417807D9754DA64F3087E2E2E03E2D28349A@rznt8114.rznt.rzdir.fht-esslingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D28349A@rznt8114.rznt.rzdir.fht-esslingen.de> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft 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, 26 Mar 2019 15:34:10 -0000 On Tue, Mar 26, 2019 at 02:54:36PM +0000, Scharf, Michael wrote: > Hi Juergen, > > The document includes TCP keepalives configuration and this is actually about TCP protocol engine internals, no? I think we are talking about a client or server using setsockopt() calls. This is not about globally changing TCP engine behavior. > And I fail to see the benefit of doing TCP YANG modeling specific to NETCONF or RESTCONF. For instance, on a router, I believe that NETCONF, RESTCONF, BGP and LDP could use the same TCP stack, as well as possibly all other TCP-based protocols running on the NE. And if HTTP is included, YANG models have a pretty broad applicability beyond routers. So what makes NETCONF or RESTCONF so special that NETCONF needs its own model? > > As I mentioned, in the last years TCPM has been extremely open to TCP-related needs in other working groups and we have quite successful cross-area work. > The models are not NETCONF/RESTCONF specific unless process forces us to make them NETCONF/RESTCONF specific. What makes NETCONF/RESTCONF special is that we started this 5 years ago. I do not care at the end who owns the document as long as process does not bring us more delay. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 26 08:53:47 2019 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 4E037120494; Tue, 26 Mar 2019 08:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de 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 7e99S7tO0Xxb; Tue, 26 Mar 2019 08:53:43 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2C01204A6; Tue, 26 Mar 2019 08:53:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 363E625A15; Tue, 26 Mar 2019 16:53:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1553615621; bh=dscI/wWifN4+KJ1F4gIraW40RhkoAOGb6fpym7rLxAs=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=JqX2J6w7XKxjUydLt4vNDVwbYPjDzkgA178V/sbGPnEd6ElE7UDdlZ3F6IkoSZCyI 52SfclhlwsEddKR3i1jgGdTEyN2gRRR+1l1DvNAleHv3aRw7satADkUG8Wm8PfF5hs 5pvpc/3JabXBjGaudgQSHUq9+bK/jCQR6yx1dqhk= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Doe80OWyQiH9; Tue, 26 Mar 2019 16:53:40 +0100 (CET) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 26 Mar 2019 16:53:40 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.111]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Tue, 26 Mar 2019 16:53:40 +0100 From: "Scharf, Michael" To: Juergen Schoenwaelder CC: Mahesh Jethanandani , Netconf , "tcpm@ietf.org" Thread-Topic: [netconf] Adoption poll for tcp-client-server and http-client-server draft Thread-Index: AQHU48WN++elmQAJ10utC4WVEX8JVqYd0z1QgAASMICAABHsoIAAAwaAgAARMKA= Date: Tue, 26 Mar 2019 15:53:39 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D28398B@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D282BBC@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de> <6EC6417807D9754DA64F3087E2E2E03E2D28349A@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326153403.sb4dzynlv2fxhvym@anna.jacobs.jacobs-university.de> In-Reply-To: <20190326153403.sb4dzynlv2fxhvym@anna.jacobs.jacobs-university.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft 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, 26 Mar 2019 15:53:45 -0000 > -----Original Message----- > From: Juergen Schoenwaelder > Sent: Tuesday, March 26, 2019 4:34 PM > To: Scharf, Michael > Cc: Mahesh Jethanandani ; Netconf > ; tcpm@ietf.org > Subject: Re: [netconf] Adoption poll for tcp-client-server and http-clien= t- > server draft >=20 > On Tue, Mar 26, 2019 at 02:54:36PM +0000, Scharf, Michael wrote: > > Hi Juergen, > > > > The document includes TCP keepalives configuration and this is actually > about TCP protocol engine internals, no? >=20 > I think we are talking about a client or server using setsockopt() > calls. This is not about globally changing TCP engine behavior. There is a grey area between setsockopt() style configuration and TCP stack= configuration. And one can easily end up in the question if other paramete= rs of the TCP stack need to be optimized in an actual NETCONF/RESTCONF impl= ementation for some reason, possibly on a per-connection basis. Then one ge= ts into details of the TCP stack. =20 > > And I fail to see the benefit of doing TCP YANG modeling specific to > NETCONF or RESTCONF. For instance, on a router, I believe that NETCONF, > RESTCONF, BGP and LDP could use the same TCP stack, as well as possibly a= ll > other TCP-based protocols running on the NE. And if HTTP is included, YAN= G > models have a pretty broad applicability beyond routers. So what makes > NETCONF or RESTCONF so special that NETCONF needs its own model? > > > > As I mentioned, in the last years TCPM has been extremely open to TCP- > related needs in other working groups and we have quite successful cross- > area work. > > >=20 > The models are not NETCONF/RESTCONF specific unless process forces us > to make them NETCONF/RESTCONF specific. What makes > NETCONF/RESTCONF > special is that we started this 5 years ago. I do not care at the end > who owns the document as long as process does not bring us more delay. It is reasonable to ask for a fast solution. And, well, a solution will be = actually be faster if there are no "surprises" late in the publication proc= ess. So it may be better to discuss early what the best approach would be, = and where to home what. Michael From nobody Tue Mar 26 09:10:47 2019 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 9431F120551; Tue, 26 Mar 2019 09:10:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 nPELAb-I4ah1; Tue, 26 Mar 2019 09:10:43 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29C6120548; Tue, 26 Mar 2019 09:10:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 1C0876F4; Tue, 26 Mar 2019 17:10:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id bIY-OCMmnclm; Tue, 26 Mar 2019 17:10:41 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 26 Mar 2019 17:10:41 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 03E9E200A8; Tue, 26 Mar 2019 17:10:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id b9mSItQ50v-2; Tue, 26 Mar 2019 17:10:40 +0100 (CET) Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 7C641200A7; Tue, 26 Mar 2019 17:10:40 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Tue, 26 Mar 2019 17:10:39 +0100 Received: by anna.localdomain (Postfix, from userid 501) id A166130079D818; Tue, 26 Mar 2019 17:10:39 +0100 (CET) Date: Tue, 26 Mar 2019 17:10:39 +0100 From: Juergen Schoenwaelder To: "Scharf, Michael" CC: Mahesh Jethanandani , Netconf , "tcpm@ietf.org" Message-ID: <20190326161039.og3ylq7fenoffvpi@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Scharf, Michael" , Mahesh Jethanandani , Netconf , "tcpm@ietf.org" References: <6EC6417807D9754DA64F3087E2E2E03E2D282BBC@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de> <6EC6417807D9754DA64F3087E2E2E03E2D28349A@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326153403.sb4dzynlv2fxhvym@anna.jacobs.jacobs-university.de> <6EC6417807D9754DA64F3087E2E2E03E2D28398B@rznt8114.rznt.rzdir.fht-esslingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D28398B@rznt8114.rznt.rzdir.fht-esslingen.de> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft 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, 26 Mar 2019 16:10:46 -0000 On Tue, Mar 26, 2019 at 03:53:39PM +0000, Scharf, Michael wrote: > > -----Original Message----- > > From: Juergen Schoenwaelder > > Sent: Tuesday, March 26, 2019 4:34 PM > > To: Scharf, Michael > > Cc: Mahesh Jethanandani ; Netconf > > ; tcpm@ietf.org > > Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client- > > server draft > > > > On Tue, Mar 26, 2019 at 02:54:36PM +0000, Scharf, Michael wrote: > > > Hi Juergen, > > > > > > The document includes TCP keepalives configuration and this is actually > > about TCP protocol engine internals, no? > > > > I think we are talking about a client or server using setsockopt() > > calls. This is not about globally changing TCP engine behavior. > > There is a grey area between setsockopt() style configuration and TCP stack configuration. And one can easily end up in the question if other parameters of the TCP stack need to be optimized in an actual NETCONF/RESTCONF implementation for some reason, possibly on a per-connection basis. Then one gets into details of the TCP stack. > > > > And I fail to see the benefit of doing TCP YANG modeling specific to > > NETCONF or RESTCONF. For instance, on a router, I believe that NETCONF, > > RESTCONF, BGP and LDP could use the same TCP stack, as well as possibly all > > other TCP-based protocols running on the NE. And if HTTP is included, YANG > > models have a pretty broad applicability beyond routers. So what makes > > NETCONF or RESTCONF so special that NETCONF needs its own model? > > > > > > As I mentioned, in the last years TCPM has been extremely open to TCP- > > related needs in other working groups and we have quite successful cross- > > area work. > > > > > > > The models are not NETCONF/RESTCONF specific unless process forces us > > to make them NETCONF/RESTCONF specific. What makes > > NETCONF/RESTCONF > > special is that we started this 5 years ago. I do not care at the end > > who owns the document as long as process does not bring us more delay. > > It is reasonable to ask for a fast solution. And, well, a solution will be actually be faster if there are no "surprises" late in the publication process. So it may be better to discuss early what the best approach would be, and where to home what. > We had objects to configure TCP connections over which we run TLS and SSH over which we run RESTCONF and NETCONF in the making for ~5 years. And I also know RFCs that include YANG objects to establish TCP connections. Is the keep alive the reason for TCPM to claim control of this? Or the fact that we moved to more generic groupings? Anyway, I am just saying you should be aware of the history and scope of this work and then the WG chairs can settle this somehow. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 26 09:21:20 2019 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 23D14120598; Tue, 26 Mar 2019 09:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de 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 eTJLNnpS7svt; Tue, 26 Mar 2019 09:21:09 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D145D120582; Tue, 26 Mar 2019 09:21:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 8D89D25A13; Tue, 26 Mar 2019 17:21:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1553617266; bh=gL7mQybliCPIsetwd/vPs8p9LoKnyjTY32lT03TCc18=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ZIyJa/U8QohJzZeTy2l/gZNa1SgIrZQTV9IacWQtZyqjjwuypDJUiDP1fkg3EcmZr qzpshzCnl5pSIbiJ0UE/v8yn+oAP2K01SqohEF24/oMDKDdBZ/wu8nb6YQoLv+M+Ig ddJymdFixqyUIp5okOTDLuMrj1iwZzvOfcNNs7wU= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yvr5KA60tPPa; Tue, 26 Mar 2019 17:21:05 +0100 (CET) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 26 Mar 2019 17:21:05 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.111]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Tue, 26 Mar 2019 17:21:04 +0100 From: "Scharf, Michael" To: Juergen Schoenwaelder CC: Mahesh Jethanandani , Netconf , "tcpm@ietf.org" Thread-Topic: [netconf] Adoption poll for tcp-client-server and http-client-server draft Thread-Index: AQHU48WN++elmQAJ10utC4WVEX8JVqYd0z1QgAASMICAABHsoIAAAwaAgAARMKD///kKgIAAETOQ Date: Tue, 26 Mar 2019 16:21:04 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D283B33@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D282BBC@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de> <6EC6417807D9754DA64F3087E2E2E03E2D28349A@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326153403.sb4dzynlv2fxhvym@anna.jacobs.jacobs-university.de> <6EC6417807D9754DA64F3087E2E2E03E2D28398B@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326161039.og3ylq7fenoffvpi@anna.jacobs.jacobs-university.de> In-Reply-To: <20190326161039.og3ylq7fenoffvpi@anna.jacobs.jacobs-university.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft 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, 26 Mar 2019 16:21:12 -0000 > -----Original Message----- > From: Juergen Schoenwaelder > Sent: Tuesday, March 26, 2019 5:11 PM > To: Scharf, Michael > Cc: Mahesh Jethanandani ; Netconf > ; tcpm@ietf.org > Subject: Re: [netconf] Adoption poll for tcp-client-server and http-clien= t- > server draft >=20 > On Tue, Mar 26, 2019 at 03:53:39PM +0000, Scharf, Michael wrote: > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > Sent: Tuesday, March 26, 2019 4:34 PM > > > To: Scharf, Michael > > > Cc: Mahesh Jethanandani ; Netconf > > > ; tcpm@ietf.org > > > Subject: Re: [netconf] Adoption poll for tcp-client-server and http-c= lient- > > > server draft > > > > > > On Tue, Mar 26, 2019 at 02:54:36PM +0000, Scharf, Michael wrote: > > > > Hi Juergen, > > > > > > > > The document includes TCP keepalives configuration and this is actu= ally > > > about TCP protocol engine internals, no? > > > > > > I think we are talking about a client or server using setsockopt() > > > calls. This is not about globally changing TCP engine behavior. > > > > There is a grey area between setsockopt() style configuration and TCP s= tack > configuration. And one can easily end up in the question if other paramet= ers > of the TCP stack need to be optimized in an actual NETCONF/RESTCONF > implementation for some reason, possibly on a per-connection basis. Then > one gets into details of the TCP stack. > > > > > > And I fail to see the benefit of doing TCP YANG modeling specific t= o > > > NETCONF or RESTCONF. For instance, on a router, I believe that > NETCONF, > > > RESTCONF, BGP and LDP could use the same TCP stack, as well as possib= ly > all > > > other TCP-based protocols running on the NE. And if HTTP is included, > YANG > > > models have a pretty broad applicability beyond routers. So what make= s > > > NETCONF or RESTCONF so special that NETCONF needs its own model? > > > > > > > > As I mentioned, in the last years TCPM has been extremely open to > TCP- > > > related needs in other working groups and we have quite successful > cross- > > > area work. > > > > > > > > > > The models are not NETCONF/RESTCONF specific unless process forces us > > > to make them NETCONF/RESTCONF specific. What makes > > > NETCONF/RESTCONF > > > special is that we started this 5 years ago. I do not care at the end > > > who owns the document as long as process does not bring us more delay= . > > > > It is reasonable to ask for a fast solution. And, well, a solution will= be > actually be faster if there are no "surprises" late in the publication pr= ocess. So > it may be better to discuss early what the best approach would be, and > where to home what. > > >=20 > We had objects to configure TCP connections over which we run TLS and > SSH over which we run RESTCONF and NETCONF in the making for ~5 years. > And I also know RFCs that include YANG objects to establish TCP connectio= ns. > Is the keep alive the reason for TCPM to claim control of this? Or the > fact that we moved to more generic groupings? Standardizing generic groupings including protocol-specific configuration w= ithout talking to the working group owning the protocol is probably not the= right approach - no matter what the protocol is and where it is homed in t= he IETF. As a TCPM chair, I speak up because I believe such a document needs to be r= eviewed by TCP implementers early. That expertise can be found in TCPM. Note that it is perfectly possible that the TCPM working group decides that= the specific problem at hand does not have to be solved in TCPM. We could = have discussed that yesterday in TCPM. Michael =20 > Anyway, I am just saying you should be aware of the history and scope > of this work and then the WG chairs can settle this somehow. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Tue Mar 26 18:13:05 2019 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 AF65C120165; Tue, 26 Mar 2019 18:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.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 Ut0f4SB4HCqG; Tue, 26 Mar 2019 18:12:55 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760091.outbound.protection.outlook.com [40.107.76.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73F0A12010E; Tue, 26 Mar 2019 18:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9u5WYVgClj6tJnHYMfY9F6TezUFZDpNTJkXqaVkH99Q=; b=h+Hc/VwmXxOchz6tO6LcW9MxRUzM6Bti/e1ksIrgbI8q6XN0FD2zoQvb6YxU9huTV+MqldPImRGyal4e/4LF8G57MY4sdHIx7svxqu+jsPxgNmsdQfiVQ++4tRHej0qeFk7hOFsXHxrE2axt331uYbiWpxwqwT9mwoEkpVAKvik= Received: from BL0PR06MB5042.namprd06.prod.outlook.com (10.167.240.31) by BL0PR06MB4193.namprd06.prod.outlook.com (10.167.179.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.18; Wed, 27 Mar 2019 01:12:52 +0000 Received: from BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::d5:e11c:db10:639d]) by BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::d5:e11c:db10:639d%3]) with mapi id 15.20.1730.019; Wed, 27 Mar 2019 01:12:52 +0000 From: Michel Veillette To: Ladislav Lhotka , Juergen Schoenwaelder , Carsten Bormann CC: "netconf@ietf.org" , "core@ietf.org" Thread-Topic: [netconf] YANG encoding in CBOR Thread-Index: AdTf3q8hCOPNH5o0Q0SJZRQQHN87VgA3tcGQAAL8XAAAAtt/gAAgmRkAAAJStYAAYEUIgABUqX2Q Date: Wed, 27 Mar 2019 01:12:52 +0000 Message-ID: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> In-Reply-To: <871s2vqsxi.fsf@nic.cz> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com; x-originating-ip: [184.162.192.248] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ac3ded06-5667-4074-e904-08d6b251562a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:BL0PR06MB4193; x-ms-traffictypediagnostic: BL0PR06MB4193: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 0989A7979C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(366004)(136003)(39850400004)(199004)(189003)(13464003)(52314003)(6246003)(71200400001)(52536014)(97736004)(7696005)(53546011)(76176011)(106356001)(105586002)(71190400001)(6506007)(30864003)(14454004)(99286004)(966005)(8936002)(86362001)(53936002)(102836004)(2906002)(72206003)(5660300002)(45080400002)(14444005)(3846002)(5024004)(81156014)(186003)(229853002)(8676002)(6116002)(81166006)(305945005)(9686003)(55016002)(68736007)(478600001)(25786009)(316002)(7736002)(114624004)(33656002)(486006)(6436002)(93886005)(54906003)(99936001)(4326008)(110136005)(66066001)(74316002)(476003)(26005)(11346002)(446003)(6306002)(256004); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4193; H:BL0PR06MB5042.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: m7Pa1E4i5yKeBbcgbOXLdPk1G9NiZmSoRiR2kmnr/L5nBqTbsDw2h/DxouWydU2PGjdCseuatF3LfLdWkTiPa8aSRODpk7rUGTJx/R5idv2+uemOTqkffaf/rHqN0xdZqrw8sHMwO02YfHNBqzSKtDAxPrsGkKytVq9jkoljjcQwq07JN80mBxICiChmt65Q6H7DO1IGYWR7/0MT8CtzBLcCDL0Z9Xl+zdMHWMuvMmVqUeQiEonIRiZEsdp6zqoriqvh0Ee+ZNXSgLeTwW/kZ7OHLNDYY2/BSHcg/bPLGGRK2zsTWMlij7uMtJ2MrlY+Q3qtSfPh6++QQN/zXZjV42i4A++zoDG/dxVsrRqr74zjpxuRvNmsLC9MfpY4SRCIIV9wmYuR1bO5EO0LTLUa1fn6AOrHt8RRLg/SShL4kA4= Content-Type: multipart/mixed; boundary="_002_BL0PR06MB5042C9AA6B4A0CCD913F50D89A580BL0PR06MB5042namp_" MIME-Version: 1.0 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: ac3ded06-5667-4074-e904-08d6b251562a X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2019 01:12:52.5250 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4193 Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 27 Mar 2019 01:12:59 -0000 --_002_BL0PR06MB5042C9AA6B4A0CCD913F50D89A580BL0PR06MB5042namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTGFkaXNsYXYNCg0KSWYgSSBzdW1tYXJpemUgdGhpcyBpc3N1ZSBvZiBtdWx0aXBsZSBlbnVt ZXJhdGlvbnMgb3IgYml0cyBpbiBhIHVuaW9uLCB0aGlzIHByb2JsZW0gY2FuIGJlIHNvbHZlIGJ5 IHRoZSBmb2xsb3dpbmcgYXBwcm9hY2hlczoNCg0KLSBUbyBub3QgYWxsb3dzIHRoZXNlIGR1cGxp Y2F0ZSB2YWx1ZXMgb3IgcG9zaXRpb25zIHRvIGhhcHBlbiBpbiBZQU5HDQotIFRvIGVuY29kZSBl bnVtZXJhdGlvbnMgYW5kIGJpdHMgYXMgc3RyaW5nIChpbiBhbGwgdW5pb25zIG9yIG9ubHkgd2hl biBtdWx0aXBsZSBlbnVtZXJhdGlvbnMgb3IgYml0cyBhcmUgZGVmaW5lZCkNCi0gVG8gZW5jb2Rl IGVudW1lcmF0aW9ucyBhbmQgYml0cyBhcyBTSUQgKGluIGFsbCB1bmlvbnMgb3Igb25seSB3aGVu IG11bHRpcGxlIGVudW1lcmF0aW9ucyBvciBiaXRzIGFyZSBkZWZpbmVkKQ0KLSBUbyBlbmNvZGUg ZW51bWVyYXRpb25zIGFuZCBiaXRzIGFzIGRlbHRhIGJldHdlZW4gdGhlIHZhbHVlIFNJRCBhbmQg dGhlIGxlYWYgU0lEIChpbiBhbGwgdW5pb25zIG9yIG9ubHkgd2hlbiBtdWx0aXBsZSBlbnVtZXJh dGlvbnMgb3IgYml0cyBhcmUgZGVmaW5lZCkNCg0KSW4gdGhpcyBlbWFpbCwgSSB3aWxsIGxpa2Ug dG8gZm9jdXMgb24gdGhlIGZpcnN0IG9wdGlvbiwgZml4aW5nIHRoZSBwcm9ibGVtIGRpcmVjdGx5 IGluIFlBTkcgaW5zdGVhZCBvZiBmaXhpbmcgdGhlIGNvbnNlcXVlbmNlcy4NCg0KV2l0aG91dCBh bnkgY2hhbmdlcyBpbiBZQU5HLCBhIHVuaW9uIHdpdGggbXVsdGlwbGUgZW51bWVyYXRpb24gb3Ig Yml0cyBjYW4gYmUgY29uc3RydWN0ZWQgd2l0aG91dCB2YWx1ZSBvciBwb3NpdGlvbiBvdmVybGFw cy4NCkZvciBleGFtcGxlOg0KDQogIGxlYWYgbXVsdGlwbGUtZW51bWVyYXRpb25zLXRlc3QtMSB7 DQogICAgdHlwZSB1bmlvbiB7DQogICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCiAgICAgICAgZW51 bSAiTW9uZGF5IiB7IHZhbHVlIDA7IH0NCiAgICAgICAgZW51bSAiVHVlc2RheSIgeyB2YWx1ZSAx OyB9DQogICAgICAgIGVudW0gIldlZG5lc2RheSIgeyB2YWx1ZSAyOyB9DQogICAgICAgIGVudW0g IlRodXJzZGF5IiB7IHZhbHVlIDM7IH0NCiAgICAgICAgZW51bSAiRnJpZGF5IiB7IHZhbHVlIDQ7 IH0NCg0KICAgICAgfQ0KICAgICAgdHlwZSBlbnVtZXJhdGlvbiB7DQogICAgICAgIGVudW0gIlNh dHVyZGF5IiB7IHZhbHVlIDU7IH0NCiAgICAgICAgZW51bSAiU3VuZGF5IiB7IHZhbHVlIDY7IH0N CiAgICAgIH0NCiAgICB9DQogIH0NCg0KICBsZWFmIG11bHRpcGxlLWJpdHMtdGVzdC0xIHsNCiAg ICB0eXBlIHVuaW9uIHsNCiAgICAgIHR5cGUgYml0cyB7DQogICAgICAgIGJpdCAgIk1vbmRheSIg eyBwb3NpdGlvbiAgMDsgfQ0KICAgICAgICBiaXQgIlR1ZXNkYXkiIHsgcG9zaXRpb24gIDE7IH0N CiAgICAgICAgYml0ICJXZWRuZXNkYXkiIHsgcG9zaXRpb24gIDI7IH0NCiAgICAgICAgYml0ICJU aHVyc2RheSIgeyBwb3NpdGlvbiAgMzsgfQ0KICAgICAgICBiaXQgIkZyaWRheSIgeyBwb3NpdGlv biAgNDsgfQ0KDQogICAgICB9DQogICAgICB0eXBlIGJpdHMgew0KICAgICAgICBiaXQgIlNhdHVy ZGF5IiB7IHBvc2l0aW9uIDU7IH0NCiAgICAgICAgYml0ICJTdW5kYXkiIHsgcG9zaXRpb24gNjsg fQ0KICAgICAgfQ0KICAgIH0NCiAgfQ0KDQpXaGVuIHVzaW5nIGFscmVhZHkgZGVmaW5lZCB0eXBl ZGVmLCBhdm9pZGluZyBvdmVybGFwIGlzIGxlc3Mgb2J2aW91cyB3aXRob3V0IHNvbWUgaGVscC4N ClRvIGhlbHAgYnVpbGRpbmcgdW5pb25zIHdpdGggYWxyZWFkeSBkZWZpbmVkIHR5cGVkZWZzLCBJ IHByb3Bvc2UgdG8gaW50cm9kdWNlIHR3byBleHRlbnNpb25zLiANCg0KICBleHRlbnNpb24gdmFs dWUtb2Zmc2V0IHsNCiAgICBhcmd1bWVudCBvZmZzZXQgew0KICAgICAgeWluLWVsZW1lbnQgdHJ1 ZTsNCiAgICB9DQogICAgZGVzY3JpcHRpb24NCiAgICAgICJPZmZzZXQgYWRkZWQgdG8gZWFjaCBl bnVtIHZhbHVlIG9mIHRoZSBhc3NvY2lhdGVkIGVudW1lcmF0aW9uLiI7DQogIH0NCiAgDQogIGV4 dGVuc2lvbiBwb3NpdGlvbi1vZmZzZXQgew0KICAgIGFyZ3VtZW50IG9mZnNldCB7DQogICAgICB5 aW4tZWxlbWVudCB0cnVlOw0KICAgIH0NCiAgICBkZXNjcmlwdGlvbg0KICAgICAgIk9mZnNldCB2 YWx1ZSBhZGRlZCB0byBlYWNoIGJpdCBwb3NpdGlvbiBvZiB0aGUgYXNzb2NpYXRlZCBiaXRzLiI7 DQogIH0NCg0KVGhlIHZhbHVlLW9mZnNldCBleHRlbnNpb24gY2FuIGJlIHVzZWQgYXMgZm9sbG93 Og0KDQogICAgdHlwZSBlbnVtZXJhdGlvbiB7DQogICAgICBlbnVtICJNb25kYXkiOw0KICAgICAg ZW51bSAiVHVlc2RheSI7DQogICAgICBlbnVtICJXZWRuZXNkYXkiOw0KICAgICAgZW51bSAiVGh1 cnNkYXkiOw0KICAgICAgZW51bSAiRnJpZGF5IjsNCiAgICB9DQogIH0NCg0KICB0eXBlZGVmIHdl ZWtlbmQgew0KICAgIHR5cGUgZW51bWVyYXRpb24gew0KICAgICAgZW51bSAiU2F0dXJkYXkiOw0K ICAgICAgZW51bSAiU3VuZGF5IjsNCiAgICB9DQogIH0NCiAgDQogIGxlYWYgbXVsdGlwbGUtZW51 bWVyYXRpb25zLXRlc3QtMyB7DQogICAgdHlwZSB1bmlvbiB7DQogICAgICB0eXBlIHdlZWtkYXlz Ow0KICAgICAgdHlwZSB3ZWVrZW5kIHsNCiAgICAgICAgZXh0OnZhbHVlLW9mZnNldCA1Ow0KICAg ICAgfQ0KICAgIH0NCiAgfQ0KDQpUaGUgcG9zaXRpb24tb2Zmc2V0IGV4dGVuc2lvbiBjYW4gYmUg dXNlZCBhcyBmb2xsb3c6DQoNCiAgdHlwZWRlZiB3ZWVrZGF5cy1mbGFncyB7DQogICAgdHlwZSBi aXRzIHsNCiAgICAgIGJpdCAiTW9uZGF5IjsNCiAgICAgIGJpdCAiVHVlc2RheSI7DQogICAgICBi aXQgIldlZG5lc2RheSI7DQogICAgICBiaXQgIlRodXJzZGF5IjsNCiAgICAgIGJpdCAiRnJpZGF5 IjsNCiAgICB9DQogIH0NCg0KICB0eXBlZGVmIHdlZWtlbmQtZmxhZ3Mgew0KICAgIHR5cGUgYml0 cyB7DQogICAgICBiaXQgIlNhdHVyZGF5IjsNCiAgICAgIGJpdCAiU3VuZGF5IjsNCiAgICB9DQog IH0NCiAgDQogIGxlYWYgbXVsdGlwbGUtYml0cy10ZXN0LTMgew0KICAgIHR5cGUgdW5pb24gew0K ICAgICAgdHlwZSB3ZWVrZGF5cy1mbGFnczsNCiAgICAgIHR5cGUgd2Vla2VuZC1mbGFncyB7DQog ICAgICAgIGV4dDpwb3NpdGlvbi1vZmZzZXQgNTsNCiAgICAgIH0NCiAgICB9DQogIH0NCg0KVGhl IHlhbmcgZmlsZSBpbiBhdHRhY2htZW50IHNob3cgZGlmZmVyZW50IGV4YW1wbGVzIGJhc2VkIG9u IHRoaXMgYXBwcm9hY2guDQpUaGlzIG1vZHVsZSBoYXZlIGJlZW4gdmFsaWRhdGVkIHVzaW5nIGh0 dHA6Ly93d3cueWFuZ3ZhbGlkYXRvci5jb20vdmFsaWRhdG9yIA0KSWYgdGhpcyBhcHByb2FjaCBp cyBhY2NlcHRlZCwgdG9vbHMgbGlrZSBweWFuZyBzaG91bGQgYmUgdXBkYXRlZCB0byBwcm9kdWNl IGFuIGVycm9yIGlmIG11bHRpcGxlIGVudW1lcmF0aW9ucyBvciBiaXRzIGFyZSBkZWZpbmVkIHdp dGggdmFsdWUgb3IgcG9zaXRpb24gb3ZlcmxlYXBzLg0KDQpQbGVhc2UgY29tbWVudCwNCk1pY2hl bA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTGFkaXNsYXYgTGhvdGthIDxs aG90a2FAbmljLmN6PiANClNlbnQ6IE1vbmRheSwgTWFyY2ggMjUsIDIwMTkgNDowNyBBTQ0KVG86 IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5 LmRlPjsgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+DQpDYzogTWljaGVsIFZlaWxsZXR0 ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQuY29tPjsgbmV0Y29uZkBpZXRmLm9yZzsgY29y ZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRjb25mXSBZQU5HIGVuY29kaW5nIGluIENCT1IN Cg0KSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNp dHkuZGU+IHdyaXRlczoNCg0KPiBJIHRoaW5rIHdlIG5lZWQgdG8gbG9vayBhdCB0aGUgd2hvbGUg cGljdHVyZSBhbmQgaW4gd2hpY2ggZGlyZWN0aW9uIHdlIA0KPiB3YW50IHRvIGdvLiBJbiB0aGUg bG9uZ2VyIHRlcm0sIEkgd291bGQgcHJlZmVyIGEgc29sdXRpb24gd2hlcmUgdGhlIA0KPiB2YWx1 ZXMgb2YgYSB1bmlvbiBhcmUgZGlzY3JpbWluYXRlZC4gVGhlIGN1cnJlbnQgWE1MIGVuY29kaW5n IA0KPiBiZWhhdmlvdXIgb2YgJ2ZpcnN0IG1hdGNoIHdpbnMnIGlzIGZyYWdpbGUgKGZvciBleGFt cGxlLCBpZiBzb21lb25lIA0KPiBhZGRzIGFuIGVudW0gdG8gYSB0eXBlLCB0aGUgaW50ZXJwcmV0 YXRpb24gb2YgZGF0YSBjYW4gY2hhbmdlKS4NCj4NCj4gTG9vayBhdCB0aGlzOg0KPg0KPiB0eXBl ZGVmIGJhciB7DQo+ICAgdHlwZSB1bmlvbiB7DQo+ICAgICB0eXBlIGVudW1lcmF0aW9uIHsgZW51 bSAiMSI7IHZhbHVlIDI7IGVudW0gIjIiOyB2YWx1ZSAxOyB9DQo+ICAgICB0eXBlIHVpbnQ4Ow0K PiAgIH0NCj4gfQ0KPg0KPiBXZSBoYXZlIHNvbWUgZW5jb2RpbmdzIHRoYXQgc2VuZCB0aGUgc3Ry aW5nIHJlcHJlc2VudGF0aW9ucyBvZiB0aGUgDQo+IHZhbHVlcyBhbmQgc29tZSBlbmNvZGluZ3Mg dGhhdCBwcmVmZXIgdG8gc2VuZCBudW1lcmljIHJlcHJlc2VudGF0aW9ucyANCj4gd2hlcmUgcG9z c2libGUuIEluIG9yZGVyIHRvIGhhdmUgYSByb2J1c3Qgc29sdXRpb24sIGVuY29kaW5ncyBzaG91 bGQgDQo+IGxpa2VseSBpbmRpY2F0ZSB0byB3aGljaCB0eXBlIHRoZSB2YWx1ZSBiZWxvbmdzLg0K DQpQZXJoYXBzIHRoZSBlYXNpZXN0IHdheSB3b3VsZCBiZSB0byB1c2UgKG9wdGlvbmFsKSBhbm5v dGF0aW9uIHRoYXQgc3BlY2lmaWVzLCB1c2luZyBhbiBvcmRpbmFsIG51bWJlciwgd2hpY2ggb2Yg dGhlIG1lbWJlciB0eXBlcyBpcyB1c2VkIGZvciB0aGUgcGFydGljdWxhciBpbnN0YW5jZS4gQnV0 IHNpbmNlIHRoZXJlIGNhbiBiZSB1bmlvbnMgaW5zaWRlIHVuaW9ucywgYSBsaXN0IG9mIG51bWJl cnMgd291bGQgYmUgbmVlZGVkIGluIGdlbmVyYWwuDQoNCkxhZGENCg0KPg0KPiAvanMNCj4NCj4g T24gU2F0LCBNYXIgMjMsIDIwMTkgYXQgMTA6MDM6MzJBTSArMDEwMCwgQ2Fyc3RlbiBCb3JtYW5u IHdyb3RlOg0KPj4gV2VsbCwgaWYgdGhhdCBpcyBhIHByb2JsZW0sIHdlIGNhbiBnbyBmb3IgYSBs b25nZXIgcmVwcmVzZW50YXRpb24gd2l0aGluIHVuaW9ucyAoc2VjdGlvbiA2LjEyKS4gIFRoZW9y ZXRpY2FsbHksIHdlIGNvdWxkIGRvIHRoYXQgb25seSBvZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25l IGVudW0gaW4gdGhlIHVuaW9uIHR5cGUgKHNvIHRoaW5ncyBzdGF5IGVmZmljaWVudCBpZiB0aGVy ZSBpcyBvbmx5IG9uZSksIGJ1dCB0aGF0IG1pZ2h0IHBvc2UgZGlmZmljdWx0aWVzIHdpdGggbW9k ZWwgZXZvbHV0aW9uLg0KPj4gDQo+PiBHb2luZyBmb3IgYSBzdHJpbmcgcmVwcmVzZW50YXRpb24g cmVwZWF0cyB0aGUgZmVhdHVyZSBvZiBYTUwgWUFORyAod2hpY2ggd2FzIHBvcnRlZCBvdmVyIHRv IEpTT04gWUFORyk6DQo+PiANCj4+IHR5cGVkZWYgZm9vIHsNCj4+ICAgdHlwZSB1bmlvbiB7DQo+ PiAgICAgdHlwZSBlbnVtZXJhdGlvbiB7DQo+PiAgICAgICBlbnVtIHJlZCB7IHZhbHVlIDE7IH0N Cj4+ICAgICAgIGVudW0gYnJlZW4geyB2YWx1ZSAyOyB9DQo+PiAgICAgICBlbnVtIGdsdWUgeyB2 YWx1ZSAzOyB9DQo+PiAgICAgfQ0KPj4gICAgIHR5cGUgZW51bWVyYXRpb24gew0KPj4gICAgICAg ZW51bSB0YWNrcyB7IHZhbHVlIDE7IH0NCj4+ICAgICAgIGVudW0gbmFpbHMgeyB2YWx1ZSAyOyB9 DQo+PiAgICAgICBlbnVtIGdsdWUgeyB2YWx1ZSAzOyB9DQo+PiAgICAgfQ0KPj4gICB9DQo+PiB9 DQo+PiANCj4+IElmIHlvdSB1c2Ug4oCcZ2x1ZeKAnSwgeW91IGRvbuKAmXQga25vdyB3aGljaCBv ZiB0aGUgZW51bWVyYXRpb25zIGFyZSBiZWluZyB1c2VkLg0KPj4gDQo+PiBVc2luZyBTSURzLCB3 ZSBjYW4gZG8gYmV0dGVyLg0KPj4gDQo+PiBTbyB3aGF0IGRvIHdlIGhhdmUgdG8gZG8gdG8gZ2V0 IHRoZSBTSUQgdG9vbCB0byBhbGxvY2F0ZSBTSURzIGZvciBlbnVtIHZhbHVlcz8NCj4+IA0KPj4g V2UgY291bGQgdGhlbiBkZWZpbmUgdGhlIENCT1IgdGFnIGZvciBlbnVtcyBpbiB1bmlvbnMgdG8g dGFrZSB0aGUgdXN1YWwgU0lEIGRpZmZlcmVuY2UgKGRlbHRhIHJlbGF0aXZlIHRvIHRoZSBlbnZp cm9ubWVudCwgSeKAmWQgdGhpbmspLCBub3QgYW4gaW50ZWdlciB2YWx1ZS4NCj4+IA0KPj4gU2V2 ZXJhbCBvZiB1cyBhcmUgYXQgdGhlIGhhY2thdGhvbiBhbmQgY291bGQgbWFrZSBzb21ldGhpbmcg aGFwcGVuIHRvZGF5IGFuZCB0b21vcnJvdy4NCj4+IA0KPj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPj4g DQo+PiANCj4+ID4gT24gTWFyIDIyLCAyMDE5LCBhdCAxODozMCwgUm9iIFdpbHRvbiAocndpbHRv bikgPHJ3aWx0b25AY2lzY28uY29tPiB3cm90ZToNCj4+ID4gDQo+PiA+IEkgZ3Vlc3MgdGhhdCB0 aGUgY29uY2VybiBpcyB0aGF0IHRoaXMgaW50cm9kdWNlcyBtb3JlIHZhcmlhdGlvbiBpbiBob3cg ZGF0YSBpcyBpbnRlcnByZXRlZCBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQgWE1ML0pTT04vQ0JPUiBl bmNvZGluZ3MuDQo+PiA+IA0KPj4gPiBFLmcuIGlmIHNvbWVvbmUgc3dpdGNoZWQgZnJvbSBYTUwg dG8gQ0JPUiwgc3VkZGVubHkgdGhlIGNvbmZpZ3VyYXRpb24gb3Igc3RhdGUgZGF0YSBtYXkgaGF2 ZSBhIGRpZmZlcmVudCBtZWFuaW5nLg0KPj4gPiANCj4+ID4gVGhhbmtzLA0KPj4gPiBSb2INCj4+ ID4gDQo+PiA+IA0KPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+IEZyb206 IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPg0KPj4gPj4gU2VudDogMjIgTWFyY2ggMjAx OSAxNjowOA0KPj4gPj4gVG86IE1pY2hlbCBWZWlsbGV0dGUgPE1pY2hlbC5WZWlsbGV0dGVAdHJp bGxpYW50LmNvbT4NCj4+ID4+IENjOiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNj by5jb20+OyBjb3JlQGlldGYub3JnOyANCj4+ID4+IG5ldGNvbmZAaWV0Zi5vcmcNCj4+ID4+IFN1 YmplY3Q6IFJlOiBbbmV0Y29uZl0gWUFORyBlbmNvZGluZyBpbiBDQk9SDQo+PiA+PiANCj4+ID4+ IE9uIE1hciAyMiwgMjAxOSwgYXQgMTY6NDUsIE1pY2hlbCBWZWlsbGV0dGUgDQo+PiA+PiA8TWlj aGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQuY29tPg0KPj4gPj4gd3JvdGU6DQo+PiA+Pj4gDQo+PiA+ Pj4gVGhlIG9ubHkgcG90ZW50aWFsIHByb2JsZW0gSSBhd2FyZSBpcyB3aGVuIG11bHRpcGxlIGVu dW1lcmF0aW9ucyANCj4+ID4+PiBhcmUgcGFydCBvZg0KPj4gPj4gdGhlIHNhbWUgdW5pb24uDQo+ PiA+Pj4gVmFsdWUgNCBmcm9tIGVudW1lcmF0aW9uIEEgd2lsbCBiZSBlbmNvZGVkIHRoZSBzYW1l IHdheSBhcyBWYWx1ZSANCj4+ID4+PiA0IGZyb20NCj4+ID4+IGVudW1lcmF0aW9uIEIuDQo+PiA+ PiANCj4+ID4+IOKApiBhbmQgdGhhdCBpcyBub3QgYSBwcm9ibGVtIGZvciB0aGUgWE1MIHZlcnNp b24sIGJlY2F1c2UgdGhlIA0KPj4gPj4gc3RyaW5nIGlzIGJlaW5nIHVzZWQgaW5zdGVhZCBvZiB0 aGUgdmFsdWUuICAoQnV0IHRoZW4gaWYgdHdvIA0KPj4gPj4gZW51bWVyYXRpb25zIHNoYXJlIGEg c3RyaW5nLCB5b3UgaGF2ZSB0aGUgZXF1aXZhbGVudCBwcm9ibGVtIGluIA0KPj4gPj4gdGhlIFhN TCBzZXJpYWxpemF0aW9uLikNCj4+ID4+IA0KPj4gPj4gQW55d2F5LCBJIGhhdmVu4oCZdCBzZWVu IGEgcGllY2Ugb2YgcmVhbC13b3JsZCBZQU5HIHRoYXQgYWN0dWFsbHkgDQo+PiA+PiBoYXMgdGhp cyBwcm9ibGVtLCBzbyBJIHdvdWxkIGJlIGEgYml0IHJlbHVjdGFudCB0byBtYWtlIENCT1ItYmFz ZWQgDQo+PiA+PiBpbXBsZW1lbnRhdGlvbnMgbW9yZSBjb21wbGV4IChhbmQgbGVzcyBlZmZpY2ll bnQpIHNvIHNvbHZlIHRoaXMgKG5vbi0/KXByb2JsZW0uDQo+PiA+PiANCj4+ID4+IEdyw7zDn2Us IENhcnN0ZW4NCj4+ID4gDQo+PiA+IA0KPj4gPiANCj4+IA0KPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ PiBuZXRjb25mQGlldGYub3JnDQo+PiBodHRwczovL2NhbjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cNCj4+IC5pZXRmLm9yZyUyRm1haWxt YW4lMkZsaXN0aW5mbyUyRm5ldGNvbmYmYW1wO2RhdGE9MDIlN0MwMSU3QyU3QzM0M2VhOA0KPj4g ZDFjZjhmNGUzOWFmYzcwOGQ2YjBmOGQ4NzQlN0M0ZjZmYmQxMzBkZmI0MTUwODVjM2Q0MzI2MGMw NDMwOSU3QzAlN0MxDQo+PiAlN0M2MzY4OTA5ODAxODI1NTM0MDAmYW1wO3NkYXRhPXUxS0ZBWUF1 czE2QjhhN3Nnc0JmUGZJcXVPcHRNbGFPYiUyQjANCj4+IGt2UFpncjRvJTNEJmFtcDtyZXNlcnZl ZD0wDQo+DQo+IC0tIA0KPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBV bml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAg IENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQo+IEZheDogICArNDkgNDIx IDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vY2FuMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZSUyRiZh bXA7ZGF0YT0wMiU3QzAxJTdDJTdDMzQzZWE4ZDFjZjhmNGUzOWFmYzcwOGQ2YjBmOGQ4NzQlN0M0 ZjZmYmQxMzBkZmI0MTUwODVjM2Q0MzI2MGMwNDMwOSU3QzAlN0MxJTdDNjM2ODkwOTgwMTgyNTUz NDAwJmFtcDtzZGF0YT1UclcyaUwzblVEbFolMkJWdmhQeFdlcWRVMVglMkJxdkZDblh5b2RYNkJ1 MWU5NCUzRCZhbXA7cmVzZXJ2ZWQ9MD4NCj4NCj4NCj4gT24gU2F0LCBNYXIgMjMsIDIwMTkgYXQg MTA6MDM6MzJBTSArMDEwMCwgQ2Fyc3RlbiBCb3JtYW5uIHdyb3RlOg0KPj4gV2VsbCwgaWYgdGhh dCBpcyBhIHByb2JsZW0sIHdlIGNhbiBnbyBmb3IgYSBsb25nZXIgcmVwcmVzZW50YXRpb24gd2l0 aGluIHVuaW9ucyAoc2VjdGlvbiA2LjEyKS4gIFRoZW9yZXRpY2FsbHksIHdlIGNvdWxkIGRvIHRo YXQgb25seSBvZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25lIGVudW0gaW4gdGhlIHVuaW9uIHR5cGUg KHNvIHRoaW5ncyBzdGF5IGVmZmljaWVudCBpZiB0aGVyZSBpcyBvbmx5IG9uZSksIGJ1dCB0aGF0 IG1pZ2h0IHBvc2UgZGlmZmljdWx0aWVzIHdpdGggbW9kZWwgZXZvbHV0aW9uLg0KPj4gDQo+PiBH b2luZyBmb3IgYSBzdHJpbmcgcmVwcmVzZW50YXRpb24gcmVwZWF0cyB0aGUgZmVhdHVyZSBvZiBY TUwgWUFORyAod2hpY2ggd2FzIHBvcnRlZCBvdmVyIHRvIEpTT04gWUFORyk6DQo+PiANCj4+IHR5 cGVkZWYgZm9vIHsNCj4+ICAgdHlwZSB1bmlvbiB7DQo+PiAgICAgdHlwZSBlbnVtZXJhdGlvbiB7 DQo+PiAgICAgICBlbnVtIHJlZCB7IHZhbHVlIDE7IH0NCj4+ICAgICAgIGVudW0gYnJlZW4geyB2 YWx1ZSAyOyB9DQo+PiAgICAgICBlbnVtIGdsdWUgeyB2YWx1ZSAzOyB9DQo+PiAgICAgfQ0KPj4g ICAgIHR5cGUgZW51bWVyYXRpb24gew0KPj4gICAgICAgZW51bSB0YWNrcyB7IHZhbHVlIDE7IH0N Cj4+ICAgICAgIGVudW0gbmFpbHMgeyB2YWx1ZSAyOyB9DQo+PiAgICAgICBlbnVtIGdsdWUgeyB2 YWx1ZSAzOyB9DQo+PiAgICAgfQ0KPj4gICB9DQo+PiB9DQo+PiANCj4+IElmIHlvdSB1c2Ug4oCc Z2x1ZeKAnSwgeW91IGRvbuKAmXQga25vdyB3aGljaCBvZiB0aGUgZW51bWVyYXRpb25zIGFyZSBi ZWluZyB1c2VkLg0KPj4gDQo+PiBVc2luZyBTSURzLCB3ZSBjYW4gZG8gYmV0dGVyLg0KPj4gDQo+ PiBTbyB3aGF0IGRvIHdlIGhhdmUgdG8gZG8gdG8gZ2V0IHRoZSBTSUQgdG9vbCB0byBhbGxvY2F0 ZSBTSURzIGZvciBlbnVtIHZhbHVlcz8NCj4+IA0KPj4gV2UgY291bGQgdGhlbiBkZWZpbmUgdGhl IENCT1IgdGFnIGZvciBlbnVtcyBpbiB1bmlvbnMgdG8gdGFrZSB0aGUgdXN1YWwgU0lEIGRpZmZl cmVuY2UgKGRlbHRhIHJlbGF0aXZlIHRvIHRoZSBlbnZpcm9ubWVudCwgSeKAmWQgdGhpbmspLCBu b3QgYW4gaW50ZWdlciB2YWx1ZS4NCj4+IA0KPj4gU2V2ZXJhbCBvZiB1cyBhcmUgYXQgdGhlIGhh Y2thdGhvbiBhbmQgY291bGQgbWFrZSBzb21ldGhpbmcgaGFwcGVuIHRvZGF5IGFuZCB0b21vcnJv dy4NCj4+IA0KPj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPj4gDQo+PiANCj4+ID4gT24gTWFyIDIyLCAy MDE5LCBhdCAxODozMCwgUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPiB3 cm90ZToNCj4+ID4gDQo+PiA+IEkgZ3Vlc3MgdGhhdCB0aGUgY29uY2VybiBpcyB0aGF0IHRoaXMg aW50cm9kdWNlcyBtb3JlIHZhcmlhdGlvbiBpbiBob3cgZGF0YSBpcyBpbnRlcnByZXRlZCBiZXR3 ZWVuIHRoZSBkaWZmZXJlbnQgWE1ML0pTT04vQ0JPUiBlbmNvZGluZ3MuDQo+PiA+IA0KPj4gPiBF LmcuIGlmIHNvbWVvbmUgc3dpdGNoZWQgZnJvbSBYTUwgdG8gQ0JPUiwgc3VkZGVubHkgdGhlIGNv bmZpZ3VyYXRpb24gb3Igc3RhdGUgZGF0YSBtYXkgaGF2ZSBhIGRpZmZlcmVudCBtZWFuaW5nLg0K Pj4gPiANCj4+ID4gVGhhbmtzLA0KPj4gPiBSb2INCj4+ID4gDQo+PiA+IA0KPj4gPj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+IEZyb206IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0 emkub3JnPg0KPj4gPj4gU2VudDogMjIgTWFyY2ggMjAxOSAxNjowOA0KPj4gPj4gVG86IE1pY2hl bCBWZWlsbGV0dGUgPE1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50LmNvbT4NCj4+ID4+IENjOiBS b2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+OyBjb3JlQGlldGYub3JnOyAN Cj4+ID4+IG5ldGNvbmZAaWV0Zi5vcmcNCj4+ID4+IFN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gWUFO RyBlbmNvZGluZyBpbiBDQk9SDQo+PiA+PiANCj4+ID4+IE9uIE1hciAyMiwgMjAxOSwgYXQgMTY6 NDUsIE1pY2hlbCBWZWlsbGV0dGUgDQo+PiA+PiA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQu Y29tPg0KPj4gPj4gd3JvdGU6DQo+PiA+Pj4gDQo+PiA+Pj4gVGhlIG9ubHkgcG90ZW50aWFsIHBy b2JsZW0gSSBhd2FyZSBpcyB3aGVuIG11bHRpcGxlIGVudW1lcmF0aW9ucyANCj4+ID4+PiBhcmUg cGFydCBvZg0KPj4gPj4gdGhlIHNhbWUgdW5pb24uDQo+PiA+Pj4gVmFsdWUgNCBmcm9tIGVudW1l cmF0aW9uIEEgd2lsbCBiZSBlbmNvZGVkIHRoZSBzYW1lIHdheSBhcyBWYWx1ZSANCj4+ID4+PiA0 IGZyb20NCj4+ID4+IGVudW1lcmF0aW9uIEIuDQo+PiA+PiANCj4+ID4+IOKApiBhbmQgdGhhdCBp cyBub3QgYSBwcm9ibGVtIGZvciB0aGUgWE1MIHZlcnNpb24sIGJlY2F1c2UgdGhlIA0KPj4gPj4g c3RyaW5nIGlzIGJlaW5nIHVzZWQgaW5zdGVhZCBvZiB0aGUgdmFsdWUuICAoQnV0IHRoZW4gaWYg dHdvIA0KPj4gPj4gZW51bWVyYXRpb25zIHNoYXJlIGEgc3RyaW5nLCB5b3UgaGF2ZSB0aGUgZXF1 aXZhbGVudCBwcm9ibGVtIGluIA0KPj4gPj4gdGhlIFhNTCBzZXJpYWxpemF0aW9uLikNCj4+ID4+ IA0KPj4gPj4gQW55d2F5LCBJIGhhdmVu4oCZdCBzZWVuIGEgcGllY2Ugb2YgcmVhbC13b3JsZCBZ QU5HIHRoYXQgYWN0dWFsbHkgDQo+PiA+PiBoYXMgdGhpcyBwcm9ibGVtLCBzbyBJIHdvdWxkIGJl IGEgYml0IHJlbHVjdGFudCB0byBtYWtlIENCT1ItYmFzZWQgDQo+PiA+PiBpbXBsZW1lbnRhdGlv bnMgbW9yZSBjb21wbGV4IChhbmQgbGVzcyBlZmZpY2llbnQpIHNvIHNvbHZlIHRoaXMgKG5vbi0/ KXByb2JsZW0uDQo+PiA+PiANCj4+ID4+IEdyw7zDn2UsIENhcnN0ZW4NCj4+ID4gDQo+PiA+IA0K Pj4gPiANCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+IG5ldGNvbmYgbWFpbGluZyBsaXN0DQo+PiBuZXRjb25mQGlldGYub3JnDQo+PiBo dHRwczovL2NhbjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZ3d3cNCj4+IC5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRm5ldGNvbmYm YW1wO2RhdGE9MDIlN0MwMSU3QyU3QzM0M2VhOA0KPj4gZDFjZjhmNGUzOWFmYzcwOGQ2YjBmOGQ4 NzQlN0M0ZjZmYmQxMzBkZmI0MTUwODVjM2Q0MzI2MGMwNDMwOSU3QzAlN0MxDQo+PiAlN0M2MzY4 OTA5ODAxODI1NTM0MDAmYW1wO3NkYXRhPXUxS0ZBWUF1czE2QjhhN3Nnc0JmUGZJcXVPcHRNbGFP YiUyQjANCj4+IGt2UFpncjRvJTNEJmFtcDtyZXNlcnZlZD0wDQo+DQo+IC0tIA0KPiBKdWVyZ2Vu IFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0K PiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBC cmVtZW4gfCBHZXJtYW55DQo+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBz Oi8vY2FuMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUy RiUyRnd3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZSUyRiZhbXA7ZGF0YT0wMiU3QzAxJTdDJTdDMzQz ZWE4ZDFjZjhmNGUzOWFmYzcwOGQ2YjBmOGQ4NzQlN0M0ZjZmYmQxMzBkZmI0MTUwODVjM2Q0MzI2 MGMwNDMwOSU3QzAlN0MxJTdDNjM2ODkwOTgwMTgyNTUzNDAwJmFtcDtzZGF0YT1UclcyaUwzblVE bFolMkJWdmhQeFdlcWRVMVglMkJxdkZDblh5b2RYNkJ1MWU5NCUzRCZhbXA7cmVzZXJ2ZWQ9MD4N Cj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g bmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gbmV0Y29uZkBpZXRmLm9yZw0KPiBodHRwczovL2NhbjAx LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cu DQo+IGlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGbmV0Y29uZiZhbXA7ZGF0YT0wMiU3 QzAxJTdDJTdDMzQzZWE4ZDENCj4gY2Y4ZjRlMzlhZmM3MDhkNmIwZjhkODc0JTdDNGY2ZmJkMTMw ZGZiNDE1MDg1YzNkNDMyNjBjMDQzMDklN0MwJTdDMSU3Qw0KPiA2MzY4OTA5ODAxODI1NTM0MDAm YW1wO3NkYXRhPXUxS0ZBWUF1czE2QjhhN3Nnc0JmUGZJcXVPcHRNbGFPYiUyQjBrdlBaDQo+IGdy NG8lM0QmYW1wO3Jlc2VydmVkPTANCg0KLS0NCkxhZGlzbGF2IExob3RrYQ0KSGVhZCwgQ1ouTklD IExhYnMNClBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nw0K --_002_BL0PR06MB5042C9AA6B4A0CCD913F50D89A580BL0PR06MB5042namp_ Content-Type: application/octet-stream; name="test-union@2019-03-25.yang" Content-Description: test-union@2019-03-25.yang Content-Disposition: attachment; filename="test-union@2019-03-25.yang"; size=3144; creation-date="Wed, 27 Mar 2019 01:08:54 GMT"; modification-date="Wed, 27 Mar 2019 01:08:54 GMT" Content-Transfer-Encoding: base64 bW9kdWxlIHRlc3QtdW5pb24gew0KICBuYW1lc3BhY2UgInVybjppZXRmOnBhcmFtczp4bWw6bnM6 eWFuZzp0ZXN0LXVuaW9uIjsNCiAgcHJlZml4IGV4dDsNCiAgDQogIHJldmlzaW9uIDIwMTktMDMt MjUgew0KICAgICAgZGVzY3JpcHRpb24gIkRyYWZ0LiI7DQogIH0NCg0KICAvLyAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAvLyBQcm9wb3NlZCBl eHRlbnNpb25zDQogIA0KICBleHRlbnNpb24gdmFsdWUtb2Zmc2V0IHsNCiAgICBhcmd1bWVudCBv ZmZzZXQgew0KICAgICAgeWluLWVsZW1lbnQgdHJ1ZTsNCiAgICB9DQogICAgZGVzY3JpcHRpb24N CiAgICAgICJPZmZzZXQgYWRkZWQgdG8gZWFjaCBlbnVtIHZhbHVlIG9mIHRoZSBhc3NvY2lhdGVk IGVudW1lcmF0aW9uLiI7DQogIH0NCiAgDQogIGV4dGVuc2lvbiBwb3NpdGlvbi1vZmZzZXQgew0K ICAgIGFyZ3VtZW50IG9mZnNldCB7DQogICAgICB5aW4tZWxlbWVudCB0cnVlOw0KICAgIH0NCiAg ICBkZXNjcmlwdGlvbg0KICAgICAgIk9mZnNldCB2YWx1ZSBhZGRlZCB0byBlYWNoIGJpdCBwb3Np dGlvbiBvZiB0aGUgYXNzb2NpYXRlZCBiaXRzLiI7DQogIH0NCg0KICAvLyAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAvLyBNdWx0aXBsZSBlbnVt ZXJhdGlvbnMgaW4gYSB1bmlvbg0KICANCiAgbGVhZiBtdWx0aXBsZS1lbnVtZXJhdGlvbnMtdGVz dC0xIHsNCiAgICB0eXBlIHVuaW9uIHsNCiAgICAgIHR5cGUgZW51bWVyYXRpb24gew0KICAgICAg ICBlbnVtICJNb25kYXkiIHsgdmFsdWUgMDsgfQ0KICAgICAgICBlbnVtICJUdWVzZGF5IiB7IHZh bHVlIDE7IH0NCiAgICAgICAgZW51bSAiV2VkbmVzZGF5IiB7IHZhbHVlIDI7IH0NCiAgICAgICAg ZW51bSAiVGh1cnNkYXkiIHsgdmFsdWUgMzsgfQ0KICAgICAgICBlbnVtICJGcmlkYXkiIHsgdmFs dWUgNDsgfQ0KDQogICAgICB9DQogICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCiAgICAgICAgZW51 bSAiU2F0dXJkYXkiIHsgdmFsdWUgNTsgfQ0KICAgICAgICBlbnVtICJTdW5kYXkiIHsgdmFsdWUg NjsgfQ0KICAgICAgfQ0KICAgIH0NCiAgfQ0KDQogIGxlYWYgbXVsdGlwbGUtZW51bWVyYXRpb25z LXRlc3QtMiB7DQogICAgdHlwZSB1bmlvbiB7DQogICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCiAg ICAgICAgZW51bSAiTW9uZGF5IjsNCiAgICAgICAgZW51bSAiVHVlc2RheSI7DQogICAgICAgIGVu dW0gIldlZG5lc2RheSI7DQogICAgICAgIGVudW0gIlRodXJzZGF5IjsNCiAgICAgICAgZW51bSAi RnJpZGF5IjsNCiAgICAgIH0NCiAgICAgIHR5cGUgZW51bWVyYXRpb24gew0KICAgICAgICBleHQ6 dmFsdWUtb2Zmc2V0IDU7DQogICAgICAgIGVudW0gIlNhdHVyZGF5IjsNCiAgICAgICAgZW51bSAi U3VuZGF5IjsNCiAgICAgIH0NCiAgICB9DQogIH0NCg0KICB0eXBlZGVmIHdlZWtkYXlzIHsNCiAg ICB0eXBlIGVudW1lcmF0aW9uIHsNCiAgICAgIGVudW0gIk1vbmRheSI7DQogICAgICBlbnVtICJU dWVzZGF5IjsNCiAgICAgIGVudW0gIldlZG5lc2RheSI7DQogICAgICBlbnVtICJUaHVyc2RheSI7 DQogICAgICBlbnVtICJGcmlkYXkiOw0KICAgIH0NCiAgfQ0KDQogIHR5cGVkZWYgd2Vla2VuZCB7 DQogICAgdHlwZSBlbnVtZXJhdGlvbiB7DQogICAgICBlbnVtICJTYXR1cmRheSI7DQogICAgICBl bnVtICJTdW5kYXkiOw0KICAgIH0NCiAgfQ0KICANCiAgbGVhZiBtdWx0aXBsZS1lbnVtZXJhdGlv bnMtdGVzdC0zIHsNCiAgICB0eXBlIHVuaW9uIHsNCiAgICAgIHR5cGUgd2Vla2RheXM7DQogICAg ICB0eXBlIHdlZWtlbmQgew0KICAgICAgICBleHQ6dmFsdWUtb2Zmc2V0IDU7DQogICAgICB9DQog ICAgfQ0KICB9DQogIA0KICAvLyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KICAvLyBNdWx0aXBsZSBiaXRzIGluIGEgdW5pb24NCiAgDQogIGxlYWYg bXVsdGlwbGUtYml0cy10ZXN0LTEgew0KICAgIHR5cGUgdW5pb24gew0KICAgICAgdHlwZSBiaXRz IHsNCiAgICAgICAgYml0ICAiTW9uZGF5IiB7IHBvc2l0aW9uICAwOyB9DQogICAgICAgIGJpdCAi VHVlc2RheSIgeyBwb3NpdGlvbiAgMTsgfQ0KICAgICAgICBiaXQgIldlZG5lc2RheSIgeyBwb3Np dGlvbiAgMjsgfQ0KICAgICAgICBiaXQgIlRodXJzZGF5IiB7IHBvc2l0aW9uICAzOyB9DQogICAg ICAgIGJpdCAiRnJpZGF5IiB7IHBvc2l0aW9uICA0OyB9DQoNCiAgICAgIH0NCiAgICAgIHR5cGUg Yml0cyB7DQogICAgICAgIGJpdCAiU2F0dXJkYXkiIHsgcG9zaXRpb24gNTsgfQ0KICAgICAgICBi aXQgIlN1bmRheSIgeyBwb3NpdGlvbiA2OyB9DQogICAgICB9DQogICAgfQ0KICB9DQogIA0KICBs ZWFmIG11bHRpcGxlLWJpdHMtdGVzdC0yIHsNCiAgICB0eXBlIHVuaW9uIHsNCiAgICAgIHR5cGUg Yml0cyB7DQogICAgICAgIGJpdCAiTW9uZGF5IjsNCiAgICAgICAgYml0ICJUdWVzZGF5IjsNCiAg ICAgICAgYml0ICJXZWRuZXNkYXkiOw0KICAgICAgICBiaXQgIlRodXJzZGF5IjsNCiAgICAgICAg Yml0ICJGcmlkYXkiOw0KICAgICAgfQ0KICAgICAgdHlwZSBiaXRzIHsNCiAgICAgICAgZXh0OnBv c2l0aW9uLW9mZnNldCA1Ow0KICAgICAgICBiaXQgIlNhdHVyZGF5IjsNCiAgICAgICAgYml0ICJT dW5kYXkiOw0KICAgICAgfQ0KICAgIH0NCiAgfQ0KDQogIHR5cGVkZWYgd2Vla2RheXMtZmxhZ3Mg ew0KICAgIHR5cGUgYml0cyB7DQogICAgICBiaXQgIk1vbmRheSI7DQogICAgICBiaXQgIlR1ZXNk YXkiOw0KICAgICAgYml0ICJXZWRuZXNkYXkiOw0KICAgICAgYml0ICJUaHVyc2RheSI7DQogICAg ICBiaXQgIkZyaWRheSI7DQogICAgfQ0KICB9DQoNCiAgdHlwZWRlZiB3ZWVrZW5kLWZsYWdzIHsN CiAgICB0eXBlIGJpdHMgew0KICAgICAgYml0ICJTYXR1cmRheSI7DQogICAgICBiaXQgIlN1bmRh eSI7DQogICAgfQ0KICB9DQogIA0KICBsZWFmIG11bHRpcGxlLWJpdHMtdGVzdC0zIHsNCiAgICB0 eXBlIHVuaW9uIHsNCiAgICAgIHR5cGUgd2Vla2RheXMtZmxhZ3M7DQogICAgICB0eXBlIHdlZWtl bmQtZmxhZ3Mgew0KICAgICAgICBleHQ6cG9zaXRpb24tb2Zmc2V0IDU7DQogICAgICB9DQogICAg fQ0KICB9DQp9 --_002_BL0PR06MB5042C9AA6B4A0CCD913F50D89A580BL0PR06MB5042namp_-- From nobody Tue Mar 26 23:17:37 2019 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 D632A12024B; Tue, 26 Mar 2019 23:16:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 5J7JaTXq-3Qw; Tue, 26 Mar 2019 23:16:42 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE0E120164; Tue, 26 Mar 2019 23:16:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id EDC06B47; Wed, 27 Mar 2019 07:16:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id puvlUwt_mRJO; Wed, 27 Mar 2019 07:16:39 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 27 Mar 2019 07:16:39 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2A37200A8; Wed, 27 Mar 2019 07:16:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id LjiqpOUwji-L; Wed, 27 Mar 2019 07:16:39 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id F15AF200A7; Wed, 27 Mar 2019 07:16:38 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Wed, 27 Mar 2019 07:16:38 +0100 Received: by anna.localdomain (Postfix, from userid 501) id DD88E30079E3AE; Wed, 27 Mar 2019 07:16:37 +0100 (CET) Date: Wed, 27 Mar 2019 07:16:37 +0100 From: Juergen Schoenwaelder To: Michel Veillette CC: Ladislav Lhotka , Carsten Bormann , "netconf@ietf.org" , "core@ietf.org" Message-ID: <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Michel Veillette , Ladislav Lhotka , Carsten Bormann , "netconf@ietf.org" , "core@ietf.org" References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 27 Mar 2019 06:16:47 -0000 Hi, a union can be formed by using member types that are imported and not under change control of a single author/organization and ideally this should work without complex coordination of name and number spaces. Duplicate enum/bits values are legal in YANG today so an encoding has to deal with this aspect of life. A robust fix to all these problems will be to tag the type members in order to discriminate the values in the encodings. This, however, will take some time to specify and we will need to preserve backwards compatibility with unions without a tag (but compilers can encourage people to add tags whenever modules are updated). /js On Wed, Mar 27, 2019 at 01:12:52AM +0000, Michel Veillette wrote: > Hi Ladislav >=20 > If I summarize this issue of multiple enumerations or bits in a union, = this problem can be solve by the following approaches: >=20 > - To not allows these duplicate values or positions to happen in YANG > - To encode enumerations and bits as string (in all unions or only when= multiple enumerations or bits are defined) > - To encode enumerations and bits as SID (in all unions or only when mu= ltiple enumerations or bits are defined) > - To encode enumerations and bits as delta between the value SID and th= e leaf SID (in all unions or only when multiple enumerations or bits are = defined) >=20 > In this email, I will like to focus on the first option, fixing the pro= blem directly in YANG instead of fixing the consequences. >=20 > Without any changes in YANG, a union with multiple enumeration or bits = can be constructed without value or position overlaps. > For example: >=20 > leaf multiple-enumerations-test-1 { > type union { > type enumeration { > enum "Monday" { value 0; } > enum "Tuesday" { value 1; } > enum "Wednesday" { value 2; } > enum "Thursday" { value 3; } > enum "Friday" { value 4; } >=20 > } > type enumeration { > enum "Saturday" { value 5; } > enum "Sunday" { value 6; } > } > } > } >=20 > leaf multiple-bits-test-1 { > type union { > type bits { > bit "Monday" { position 0; } > bit "Tuesday" { position 1; } > bit "Wednesday" { position 2; } > bit "Thursday" { position 3; } > bit "Friday" { position 4; } >=20 > } > type bits { > bit "Saturday" { position 5; } > bit "Sunday" { position 6; } > } > } > } >=20 > When using already defined typedef, avoiding overlap is less obvious wi= thout some help. > To help building unions with already defined typedefs, I propose to int= roduce two extensions.=20 >=20 > extension value-offset { > argument offset { > yin-element true; > } > description > "Offset added to each enum value of the associated enumeration."; > } > =20 > extension position-offset { > argument offset { > yin-element true; > } > description > "Offset value added to each bit position of the associated bits."= ; > } >=20 > The value-offset extension can be used as follow: >=20 > type enumeration { > enum "Monday"; > enum "Tuesday"; > enum "Wednesday"; > enum "Thursday"; > enum "Friday"; > } > } >=20 > typedef weekend { > type enumeration { > enum "Saturday"; > enum "Sunday"; > } > } > =20 > leaf multiple-enumerations-test-3 { > type union { > type weekdays; > type weekend { > ext:value-offset 5; > } > } > } >=20 > The position-offset extension can be used as follow: >=20 > typedef weekdays-flags { > type bits { > bit "Monday"; > bit "Tuesday"; > bit "Wednesday"; > bit "Thursday"; > bit "Friday"; > } > } >=20 > typedef weekend-flags { > type bits { > bit "Saturday"; > bit "Sunday"; > } > } > =20 > leaf multiple-bits-test-3 { > type union { > type weekdays-flags; > type weekend-flags { > ext:position-offset 5; > } > } > } >=20 > The yang file in attachment show different examples based on this appro= ach. > This module have been validated using http://www.yangvalidator.com/vali= dator=20 > If this approach is accepted, tools like pyang should be updated to pro= duce an error if multiple enumerations or bits are defined with value or = position overleaps. >=20 > Please comment, > Michel >=20 > -----Original Message----- > From: Ladislav Lhotka =20 > Sent: Monday, March 25, 2019 4:07 AM > To: Juergen Schoenwaelder ; Carst= en Bormann > Cc: Michel Veillette ; netconf@ietf.org= ; core@ietf.org > Subject: Re: [netconf] YANG encoding in CBOR >=20 > Juergen Schoenwaelder writes: >=20 > > I think we need to look at the whole picture and in which direction w= e=20 > > want to go. In the longer term, I would prefer a solution where the=20 > > values of a union are discriminated. The current XML encoding=20 > > behaviour of 'first match wins' is fragile (for example, if someone=20 > > adds an enum to a type, the interpretation of data can change). > > > > Look at this: > > > > typedef bar { > > type union { > > type enumeration { enum "1"; value 2; enum "2"; value 1; } > > type uint8; > > } > > } > > > > We have some encodings that send the string representations of the=20 > > values and some encodings that prefer to send numeric representations= =20 > > where possible. In order to have a robust solution, encodings should=20 > > likely indicate to which type the value belongs. >=20 > Perhaps the easiest way would be to use (optional) annotation that spec= ifies, using an ordinal number, which of the member types is used for the= particular instance. But since there can be unions inside unions, a list= of numbers would be needed in general. >=20 > Lada >=20 > > > > /js > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > >> Well, if that is a problem, we can go for a longer representation wi= thin unions (section 6.12). Theoretically, we could do that only of ther= e is more than one enum in the union type (so things stay efficient if th= ere is only one), but that might pose difficulties with model evolution. > >>=20 > >> Going for a string representation repeats the feature of XML YANG (w= hich was ported over to JSON YANG): > >>=20 > >> typedef foo { > >> type union { > >> type enumeration { > >> enum red { value 1; } > >> enum breen { value 2; } > >> enum glue { value 3; } > >> } > >> type enumeration { > >> enum tacks { value 1; } > >> enum nails { value 2; } > >> enum glue { value 3; } > >> } > >> } > >> } > >>=20 > >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of t= he enumerations are being used. > >>=20 > >> Using SIDs, we can do better. > >>=20 > >> So what do we have to do to get the SID tool to allocate SIDs for en= um values? > >>=20 > >> We could then define the CBOR tag for enums in unions to take the us= ual SID difference (delta relative to the environment, I=E2=80=99d think)= , not an integer value. > >>=20 > >> Several of us are at the hackathon and could make something happen t= oday and tomorrow. > >>=20 > >> Gr=C3=BC=C3=9Fe, Carsten > >>=20 > >>=20 > >> > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) wrote: > >> >=20 > >> > I guess that the concern is that this introduces more variation in= how data is interpreted between the different XML/JSON/CBOR encodings. > >> >=20 > >> > E.g. if someone switched from XML to CBOR, suddenly the configurat= ion or state data may have a different meaning. > >> >=20 > >> > Thanks, > >> > Rob > >> >=20 > >> >=20 > >> >> -----Original Message----- > >> >> From: Carsten Bormann > >> >> Sent: 22 March 2019 16:08 > >> >> To: Michel Veillette > >> >> Cc: Rob Wilton (rwilton) ; core@ietf.org;=20 > >> >> netconf@ietf.org > >> >> Subject: Re: [netconf] YANG encoding in CBOR > >> >>=20 > >> >> On Mar 22, 2019, at 16:45, Michel Veillette=20 > >> >> > >> >> wrote: > >> >>>=20 > >> >>> The only potential problem I aware is when multiple enumerations= =20 > >> >>> are part of > >> >> the same union. > >> >>> Value 4 from enumeration A will be encoded the same way as Value= =20 > >> >>> 4 from > >> >> enumeration B. > >> >>=20 > >> >> =E2=80=A6 and that is not a problem for the XML version, because = the=20 > >> >> string is being used instead of the value. (But then if two=20 > >> >> enumerations share a string, you have the equivalent problem in=20 > >> >> the XML serialization.) > >> >>=20 > >> >> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that ac= tually=20 > >> >> has this problem, so I would be a bit reluctant to make CBOR-base= d=20 > >> >> implementations more complex (and less efficient) so solve this (= non-?)problem. > >> >>=20 > >> >> Gr=C3=BC=C3=9Fe, Carsten > >> >=20 > >> >=20 > >> >=20 > >>=20 > >> _______________________________________________ > >> netconf mailing list > >> netconf@ietf.org > >> https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= www > >> .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343= ea8 > >> d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C= 1 > >> %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%= 2B0 > >> kvPZgr4o%3D&reserved=3D0 > > > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > Fax: +49 421 200 3103 > > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > >> Well, if that is a problem, we can go for a longer representation wi= thin unions (section 6.12). Theoretically, we could do that only of ther= e is more than one enum in the union type (so things stay efficient if th= ere is only one), but that might pose difficulties with model evolution. > >>=20 > >> Going for a string representation repeats the feature of XML YANG (w= hich was ported over to JSON YANG): > >>=20 > >> typedef foo { > >> type union { > >> type enumeration { > >> enum red { value 1; } > >> enum breen { value 2; } > >> enum glue { value 3; } > >> } > >> type enumeration { > >> enum tacks { value 1; } > >> enum nails { value 2; } > >> enum glue { value 3; } > >> } > >> } > >> } > >>=20 > >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of t= he enumerations are being used. > >>=20 > >> Using SIDs, we can do better. > >>=20 > >> So what do we have to do to get the SID tool to allocate SIDs for en= um values? > >>=20 > >> We could then define the CBOR tag for enums in unions to take the us= ual SID difference (delta relative to the environment, I=E2=80=99d think)= , not an integer value. > >>=20 > >> Several of us are at the hackathon and could make something happen t= oday and tomorrow. > >>=20 > >> Gr=C3=BC=C3=9Fe, Carsten > >>=20 > >>=20 > >> > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) wrote: > >> >=20 > >> > I guess that the concern is that this introduces more variation in= how data is interpreted between the different XML/JSON/CBOR encodings. > >> >=20 > >> > E.g. if someone switched from XML to CBOR, suddenly the configurat= ion or state data may have a different meaning. > >> >=20 > >> > Thanks, > >> > Rob > >> >=20 > >> >=20 > >> >> -----Original Message----- > >> >> From: Carsten Bormann > >> >> Sent: 22 March 2019 16:08 > >> >> To: Michel Veillette > >> >> Cc: Rob Wilton (rwilton) ; core@ietf.org;=20 > >> >> netconf@ietf.org > >> >> Subject: Re: [netconf] YANG encoding in CBOR > >> >>=20 > >> >> On Mar 22, 2019, at 16:45, Michel Veillette=20 > >> >> > >> >> wrote: > >> >>>=20 > >> >>> The only potential problem I aware is when multiple enumerations= =20 > >> >>> are part of > >> >> the same union. > >> >>> Value 4 from enumeration A will be encoded the same way as Value= =20 > >> >>> 4 from > >> >> enumeration B. > >> >>=20 > >> >> =E2=80=A6 and that is not a problem for the XML version, because = the=20 > >> >> string is being used instead of the value. (But then if two=20 > >> >> enumerations share a string, you have the equivalent problem in=20 > >> >> the XML serialization.) > >> >>=20 > >> >> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that ac= tually=20 > >> >> has this problem, so I would be a bit reluctant to make CBOR-base= d=20 > >> >> implementations more complex (and less efficient) so solve this (= non-?)problem. > >> >>=20 > >> >> Gr=C3=BC=C3=9Fe, Carsten > >> >=20 > >> >=20 > >> >=20 > >>=20 > >> _______________________________________________ > >> netconf mailing list > >> netconf@ietf.org > >> https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= www > >> .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343= ea8 > >> d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C= 1 > >> %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%= 2B0 > >> kvPZgr4o%3D&reserved=3D0 > > > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww. > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343ea= 8d1 > > cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7= C > > 636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0k= vPZ > > gr4o%3D&reserved=3D0 >=20 > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Mar 27 01:25:47 2019 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 392D6120274; Wed, 27 Mar 2019 01:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 00i_fhlNbhj1; Wed, 27 Mar 2019 01:25:44 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCBD9120273; Wed, 27 Mar 2019 01:25:44 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44Th066RkVzyct; Wed, 27 Mar 2019 09:25:42 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> Date: Wed, 27 Mar 2019 09:25:42 +0100 Cc: Michel Veillette , Ladislav Lhotka , "netconf@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 575367940.6541671-11d0d25c658c030fed37d5d31691a56a Content-Transfer-Encoding: quoted-printable Message-Id: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 27 Mar 2019 08:25:46 -0000 On Mar 27, 2019, at 07:16, Juergen Schoenwaelder = wrote: >=20 > A robust fix to all these problems will be to tag the type members in > order to discriminate the values in the encodings. This, however, will > take some time to specify and we will need to preserve backwards > compatibility with unions without a tag (but compilers can encourage > people to add tags whenever modules are updated). And that may be the way forward: As XML and JSON already differ in handling =E2=80=9Cfirst-match wins=E2=80= =9D (as Andy has demonstrated), there is probably not a lot of damage in = CBOR being different again in handling this arcane case, so we can = mostly ship as is (but see below). We then develop the YANG-wide fix together. We=E2=80=99ll make sure = that the CBOR union representation has the right placeholders to put = that in. For that, it would be nice to have a direction about where = exactly that information would be in the instance tree. And, more = importantly, if something needs to be included in the SID files, it = would be good to nail that down now. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 27 01:40:29 2019 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 632FF120277; Wed, 27 Mar 2019 01:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 DiSctlJq6m8R; Wed, 27 Mar 2019 01:40:11 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 6FEEA120276; Wed, 27 Mar 2019 01:40:10 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 4AD6D605FC; Wed, 27 Mar 2019 09:40:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1553676008; bh=BxpabmPoA5pcWTCBlPBgkrOdUdACty8/51V6MLJCgQU=; h=From:To:Date; b=cNvIN8s5FQTYn0gKDxlM1u/LAgooaULY7U1VpCx7F/qTYxGwarspVwsBLHABNhbrG +L2HM1rfbmMBLUjeH4bte/1DxbPsF6tutDv/R0F1A2LlndF0M2zc4bAKh0VBTe3KKY YCp9hJ3VFxVdj6L5LuPD6R/wQTzNOHHLEuMIo6Po= Message-ID: <1f8b326e0e05b400457b9446d52a7b0f6c90e05b.camel@nic.cz> From: Ladislav Lhotka To: Juergen Schoenwaelder , Michel Veillette Cc: Carsten Bormann , "netconf@ietf.org" , "core@ietf.org" Date: Wed, 27 Mar 2019 09:40:08 +0100 In-Reply-To: <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 27 Mar 2019 08:40:17 -0000 On Wed, 2019-03-27 at 07:16 +0100, Juergen Schoenwaelder wrote: > Hi, > > a union can be formed by using member types that are imported and not > under change control of a single author/organization and ideally this > should work without complex coordination of name and number spaces. > Duplicate enum/bits values are legal in YANG today so an encoding has > to deal with this aspect of life. > > A robust fix to all these problems will be to tag the type members in > order to discriminate the values in the encodings. This, however, will > take some time to specify and we will need to preserve backwards > compatibility with unions without a tag (but compilers can encourage > people to add tags whenever modules are updated). I already opened a new issue for this in yang-next: https://github.com/netmod-wg/yang-next/issues/72 Lada > > /js > > On Wed, Mar 27, 2019 at 01:12:52AM +0000, Michel Veillette wrote: > > Hi Ladislav > > > > If I summarize this issue of multiple enumerations or bits in a union, this > > problem can be solve by the following approaches: > > > > - To not allows these duplicate values or positions to happen in YANG > > - To encode enumerations and bits as string (in all unions or only when > > multiple enumerations or bits are defined) > > - To encode enumerations and bits as SID (in all unions or only when > > multiple enumerations or bits are defined) > > - To encode enumerations and bits as delta between the value SID and the > > leaf SID (in all unions or only when multiple enumerations or bits are > > defined) > > > > In this email, I will like to focus on the first option, fixing the problem > > directly in YANG instead of fixing the consequences. > > > > Without any changes in YANG, a union with multiple enumeration or bits can > > be constructed without value or position overlaps. > > For example: > > > > leaf multiple-enumerations-test-1 { > > type union { > > type enumeration { > > enum "Monday" { value 0; } > > enum "Tuesday" { value 1; } > > enum "Wednesday" { value 2; } > > enum "Thursday" { value 3; } > > enum "Friday" { value 4; } > > > > } > > type enumeration { > > enum "Saturday" { value 5; } > > enum "Sunday" { value 6; } > > } > > } > > } > > > > leaf multiple-bits-test-1 { > > type union { > > type bits { > > bit "Monday" { position 0; } > > bit "Tuesday" { position 1; } > > bit "Wednesday" { position 2; } > > bit "Thursday" { position 3; } > > bit "Friday" { position 4; } > > > > } > > type bits { > > bit "Saturday" { position 5; } > > bit "Sunday" { position 6; } > > } > > } > > } > > > > When using already defined typedef, avoiding overlap is less obvious without > > some help. > > To help building unions with already defined typedefs, I propose to > > introduce two extensions. > > > > extension value-offset { > > argument offset { > > yin-element true; > > } > > description > > "Offset added to each enum value of the associated enumeration."; > > } > > > > extension position-offset { > > argument offset { > > yin-element true; > > } > > description > > "Offset value added to each bit position of the associated bits."; > > } > > > > The value-offset extension can be used as follow: > > > > type enumeration { > > enum "Monday"; > > enum "Tuesday"; > > enum "Wednesday"; > > enum "Thursday"; > > enum "Friday"; > > } > > } > > > > typedef weekend { > > type enumeration { > > enum "Saturday"; > > enum "Sunday"; > > } > > } > > > > leaf multiple-enumerations-test-3 { > > type union { > > type weekdays; > > type weekend { > > ext:value-offset 5; > > } > > } > > } > > > > The position-offset extension can be used as follow: > > > > typedef weekdays-flags { > > type bits { > > bit "Monday"; > > bit "Tuesday"; > > bit "Wednesday"; > > bit "Thursday"; > > bit "Friday"; > > } > > } > > > > typedef weekend-flags { > > type bits { > > bit "Saturday"; > > bit "Sunday"; > > } > > } > > > > leaf multiple-bits-test-3 { > > type union { > > type weekdays-flags; > > type weekend-flags { > > ext:position-offset 5; > > } > > } > > } > > > > The yang file in attachment show different examples based on this approach. > > This module have been validated using http://www.yangvalidator.com/validator > > > > If this approach is accepted, tools like pyang should be updated to produce > > an error if multiple enumerations or bits are defined with value or position > > overleaps. > > > > Please comment, > > Michel > > > > -----Original Message----- > > From: Ladislav Lhotka > > Sent: Monday, March 25, 2019 4:07 AM > > To: Juergen Schoenwaelder ; Carsten > > Bormann > > Cc: Michel Veillette ; netconf@ietf.org; > > core@ietf.org > > Subject: Re: [netconf] YANG encoding in CBOR > > > > Juergen Schoenwaelder writes: > > > > > I think we need to look at the whole picture and in which direction we > > > want to go. In the longer term, I would prefer a solution where the > > > values of a union are discriminated. The current XML encoding > > > behaviour of 'first match wins' is fragile (for example, if someone > > > adds an enum to a type, the interpretation of data can change). > > > > > > Look at this: > > > > > > typedef bar { > > > type union { > > > type enumeration { enum "1"; value 2; enum "2"; value 1; } > > > type uint8; > > > } > > > } > > > > > > We have some encodings that send the string representations of the > > > values and some encodings that prefer to send numeric representations > > > where possible. In order to have a robust solution, encodings should > > > likely indicate to which type the value belongs. > > > > Perhaps the easiest way would be to use (optional) annotation that > > specifies, using an ordinal number, which of the member types is used for > > the particular instance. But since there can be unions inside unions, a list > > of numbers would be needed in general. > > > > Lada > > > > > /js > > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > > > > Well, if that is a problem, we can go for a longer representation within > > > > unions (section 6.12). Theoretically, we could do that only of there is > > > > more than one enum in the union type (so things stay efficient if there > > > > is only one), but that might pose difficulties with model evolution. > > > > > > > > Going for a string representation repeats the feature of XML YANG (which > > > > was ported over to JSON YANG): > > > > > > > > typedef foo { > > > > type union { > > > > type enumeration { > > > > enum red { value 1; } > > > > enum breen { value 2; } > > > > enum glue { value 3; } > > > > } > > > > type enumeration { > > > > enum tacks { value 1; } > > > > enum nails { value 2; } > > > > enum glue { value 3; } > > > > } > > > > } > > > > } > > > > > > > > If you use “glue”, you don’t know which of the enumerations are being > > > > used. > > > > > > > > Using SIDs, we can do better. > > > > > > > > So what do we have to do to get the SID tool to allocate SIDs for enum > > > > values? > > > > > > > > We could then define the CBOR tag for enums in unions to take the usual > > > > SID difference (delta relative to the environment, I’d think), not an > > > > integer value. > > > > > > > > Several of us are at the hackathon and could make something happen today > > > > and tomorrow. > > > > > > > > Grüße, Carsten > > > > > > > > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) > > > > > wrote: > > > > > > > > > > I guess that the concern is that this introduces more variation in how > > > > > data is interpreted between the different XML/JSON/CBOR encodings. > > > > > > > > > > E.g. if someone switched from XML to CBOR, suddenly the configuration > > > > > or state data may have a different meaning. > > > > > > > > > > Thanks, > > > > > Rob > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Carsten Bormann > > > > > > Sent: 22 March 2019 16:08 > > > > > > To: Michel Veillette > > > > > > Cc: Rob Wilton (rwilton) ; core@ietf.org; > > > > > > netconf@ietf.org > > > > > > Subject: Re: [netconf] YANG encoding in CBOR > > > > > > > > > > > > On Mar 22, 2019, at 16:45, Michel Veillette > > > > > > > > > > > > wrote: > > > > > > > The only potential problem I aware is when multiple enumerations > > > > > > > are part of > > > > > > the same union. > > > > > > > Value 4 from enumeration A will be encoded the same way as Value > > > > > > > 4 from > > > > > > enumeration B. > > > > > > > > > > > > … and that is not a problem for the XML version, because the > > > > > > string is being used instead of the value. (But then if two > > > > > > enumerations share a string, you have the equivalent problem in > > > > > > the XML serialization.) > > > > > > > > > > > > Anyway, I haven’t seen a piece of real-world YANG that actually > > > > > > has this problem, so I would be a bit reluctant to make CBOR-based > > > > > > implementations more complex (and less efficient) so solve this > > > > > > (non-?)problem. > > > > > > > > > > > > Grüße, Carsten > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > netconf mailing list > > > > netconf@ietf.org > > > > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > > > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=02%7C01%7C%7C343ea8 > > > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1 > > > > %7C636890980182553400&sdata=u1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0 > > > > kvPZgr4o%3D&reserved=0 > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 < > > > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jacobs-university.de%2F&data=02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&sdata=TrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&reserved=0 > > > > > > > > > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > > > > Well, if that is a problem, we can go for a longer representation within > > > > unions (section 6.12). Theoretically, we could do that only of there is > > > > more than one enum in the union type (so things stay efficient if there > > > > is only one), but that might pose difficulties with model evolution. > > > > > > > > Going for a string representation repeats the feature of XML YANG (which > > > > was ported over to JSON YANG): > > > > > > > > typedef foo { > > > > type union { > > > > type enumeration { > > > > enum red { value 1; } > > > > enum breen { value 2; } > > > > enum glue { value 3; } > > > > } > > > > type enumeration { > > > > enum tacks { value 1; } > > > > enum nails { value 2; } > > > > enum glue { value 3; } > > > > } > > > > } > > > > } > > > > > > > > If you use “glue”, you don’t know which of the enumerations are being > > > > used. > > > > > > > > Using SIDs, we can do better. > > > > > > > > So what do we have to do to get the SID tool to allocate SIDs for enum > > > > values? > > > > > > > > We could then define the CBOR tag for enums in unions to take the usual > > > > SID difference (delta relative to the environment, I’d think), not an > > > > integer value. > > > > > > > > Several of us are at the hackathon and could make something happen today > > > > and tomorrow. > > > > > > > > Grüße, Carsten > > > > > > > > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) > > > > > wrote: > > > > > > > > > > I guess that the concern is that this introduces more variation in how > > > > > data is interpreted between the different XML/JSON/CBOR encodings. > > > > > > > > > > E.g. if someone switched from XML to CBOR, suddenly the configuration > > > > > or state data may have a different meaning. > > > > > > > > > > Thanks, > > > > > Rob > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Carsten Bormann > > > > > > Sent: 22 March 2019 16:08 > > > > > > To: Michel Veillette > > > > > > Cc: Rob Wilton (rwilton) ; core@ietf.org; > > > > > > netconf@ietf.org > > > > > > Subject: Re: [netconf] YANG encoding in CBOR > > > > > > > > > > > > On Mar 22, 2019, at 16:45, Michel Veillette > > > > > > > > > > > > wrote: > > > > > > > The only potential problem I aware is when multiple enumerations > > > > > > > are part of > > > > > > the same union. > > > > > > > Value 4 from enumeration A will be encoded the same way as Value > > > > > > > 4 from > > > > > > enumeration B. > > > > > > > > > > > > … and that is not a problem for the XML version, because the > > > > > > string is being used instead of the value. (But then if two > > > > > > enumerations share a string, you have the equivalent problem in > > > > > > the XML serialization.) > > > > > > > > > > > > Anyway, I haven’t seen a piece of real-world YANG that actually > > > > > > has this problem, so I would be a bit reluctant to make CBOR-based > > > > > > implementations more complex (and less efficient) so solve this > > > > > > (non-?)problem. > > > > > > > > > > > > Grüße, Carsten > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > netconf mailing list > > > > netconf@ietf.org > > > > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > > > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=02%7C01%7C%7C343ea8 > > > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1 > > > > %7C636890980182553400&sdata=u1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0 > > > > kvPZgr4o%3D&reserved=0 > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 < > > > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jacobs-university.de%2F&data=02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&sdata=TrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&reserved=0 > > > > > > > > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=02%7C01%7C%7C343ea8d1 > > > cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C > > > 636890980182553400&sdata=u1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0kvPZ > > > gr4o%3D&reserved=0 > > > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Mar 27 09:01:30 2019 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 76FE712031B; Wed, 27 Mar 2019 09:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.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 WGnGhSLABl4m; Wed, 27 Mar 2019 09:01:16 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750095.outbound.protection.outlook.com [40.107.75.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4611202F9; Wed, 27 Mar 2019 09:00:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+ELtGtVNoXMPMLQoXI3XME3VYbOHfPwIT1r4GIP5+74=; b=Y45W4hOWwIU3KBn7+ZcqFZFefaTjamnKNHw4NFx8l19+wMZIAuXecZRKsutaHBVmrF9KB3kcLFD7cHNEndIAGIcGSZ803PKv+kJTXLRRhhpQhUrbKYPCDBDvQBfH6/laojzpG04yG93IBdWFVB700NH6G+B+ZDeskD3y92JNFK4= Received: from BL0PR06MB5042.namprd06.prod.outlook.com (10.167.240.31) by BL0PR06MB4963.namprd06.prod.outlook.com (10.167.235.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.15; Wed, 27 Mar 2019 16:00:42 +0000 Received: from BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::d5:e11c:db10:639d]) by BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::d5:e11c:db10:639d%3]) with mapi id 15.20.1730.019; Wed, 27 Mar 2019 16:00:42 +0000 From: Michel Veillette To: Juergen Schoenwaelder CC: Ladislav Lhotka , Carsten Bormann , "netconf@ietf.org" , "core@ietf.org" Thread-Topic: [netconf] YANG encoding in CBOR Thread-Index: AdTf3q8hCOPNH5o0Q0SJZRQQHN87VgA3tcGQAAL8XAAAAtt/gAAgmRkAAAJStYAAYEUIgABUqX2QAAwU1oAAE3mQoA== Date: Wed, 27 Mar 2019 16:00:42 +0000 Message-ID: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> In-Reply-To: <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3abeafcf-7d5a-4ae2-22f9-08d6b2cd5d72 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4963; x-ms-traffictypediagnostic: BL0PR06MB4963: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 0989A7979C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(366004)(136003)(396003)(376002)(346002)(52314003)(199004)(189003)(13464003)(26005)(7696005)(97736004)(256004)(76176011)(8936002)(316002)(9686003)(186003)(53946003)(54906003)(5024004)(476003)(14444005)(6436002)(486006)(5660300002)(229853002)(86362001)(114624004)(11346002)(6506007)(71190400001)(99286004)(53546011)(45080400002)(68736007)(102836004)(71200400001)(446003)(2906002)(6916009)(25786009)(3846002)(6116002)(93886005)(4326008)(8676002)(30864003)(105586002)(14454004)(33656002)(305945005)(72206003)(53936002)(7736002)(478600001)(6246003)(74316002)(106356001)(6306002)(66066001)(55016002)(966005)(81156014)(52536014)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4963; H:BL0PR06MB5042.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: bknsQaFVkTNWNtH/Z6HhyRUWeQdCLV+vvZqm4ILPJFnj5pmTi6p7wLg6hZwhBeuSWj+348aJyYipF6Qg3dYpYmBEBdp/xXKYZjxkOtK+MT8mLCBg2HHKjh0tX8WGCXnH97TbU5U8wa12JAwSbYVP2+MzdW65VNeLelgJfJCbQLRK6cWqJ4oKnJiXdc78S/i2sUVcojGgTbHKhcoO0iMZfIgUCyJ6n3XjR8fSznCfPatqIFNQShE0fX4FBydSOkBmlyyIxd9Z6fRyrv1BdMlvbKK1xkMDwSqBryFbRcF8oXT02kO87l+ZPVt4PrmJBWcY6mrzPzFZe1UFkvJBOzKsAB5b/QtgIWSyL2arRlXXNrxL0GdhNOc9wSdoMOaJwC/xQAL+OXnx5zbR6Y3uL5sAN1tyZHOr8AjSwMJhcHFAWGo= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3abeafcf-7d5a-4ae2-22f9-08d6b2cd5d72 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2019 16:00:42.2482 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4963 Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 27 Mar 2019 16:01:21 -0000 SGkgSnVlcmdlbg0KDQpZb3Ugd2lsbCBmaW5kIGluIGF0dGFjaG1lbnQgdGhlIHVwZGF0ZWQgdmVy c2lvbiBvZiAndGVzdC11bmlvbkAyMDE5LTAzLTI1LnlhbmcnIGJhc2VkIG9uIHlvdXIgcHJvcG9z ZWQgc29sdXRpb24sIHR5cGUgdGFnZ2luZy4NClRoaXMgbW9kdWxlIGRlZmluZXMgYW4gZXh0ZW5z aW9uIGNhbGxlZCB1bmlvbi10YWcgYXMgZm9sbG93Og0KDQogIGV4dGVuc2lvbiB1bmlvbi10YWcg ew0KICAgIGFyZ3VtZW50IHRhZyB7DQogICAgICB5aW4tZWxlbWVudCB0cnVlOw0KICAgIH0NCiAg ICBkZXNjcmlwdGlvbg0KICAgICAgIkluIHNvbWUgY2FzZXMsIHRoZSBpbnRlcnByZXRhdGlvbiBv ZiBhIHZhbHVlIG9mIGEgdW5pb24gdHlwZSBjYW4gZGlmZmVyDQogICAgICB3aGVuIGVuY29kZWQg dXNpbmcgdGhlIGRpZmZlcmVudCBkYXRhIGZvcm1hdC4gVGhpcyBkaWZmZXJlbmNlIGNvbWVzIGZy b20NCiAgICAgIHRoZSBsZXZlbCBvZiB0eXBlIGluZm9ybWF0aW9uIHN1cHBvcnRlZCBieSB0aGUg ZGlmZmVyZW50IGRhdGEgZm9ybWF0cy4NCiAgICAgIEluIHRoZSBjYXNlIG9mIFhNTCwgYWxsIGVs ZW1lbnRzIGFuZCBhdHRyaWJ1dGVzIGFyZSBlbmNvZGVkIGFzIHN0cmluZw0KICAgICAgYW5kIG5v IHR5cGUgaW5mb3JtYXRpb24gYXJlIGluY2x1ZGVkLiBKU09OIHN1cHBvcnRzIHN0cmluZywgbnVt YmVyIGFuZA0KICAgICAgYm9vbGVhbi4gRmluYWxseSwgQ0JPUiBzdXBwb3J0cyBhbGwgWUFORyBi YXNpYyB0eXBlcy4NCg0KICAgICAgVGhpcyBleHRlbnNpb24gY2FuIGJlIHVzZWQgdG8gYWRkIGEg dGFnIHRvIGEgdHlwZSB3aXRoaW4gYSB1bmlvbiB0bw0KICAgICAgZ3VhcmFudGVlIGl0cyBwcm9w ZXIgaW50ZXJwcmV0YXRpb24gd2hlbiBkZWNvZGVkLiI7DQogIH0NCg0KVGhpcyBleHRlbnNpb24g Y2FuIGJlIHVzZWQgYXMgZm9sbG93Og0KDQogIGxlYWYgbXVsdGlwbGUtZW51bWVyYXRpb25zLXRl c3QtMiB7DQogICAgdHlwZSB1bmlvbiB7DQogICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCiAgICAg ICAgZXh0OnVuaW9uLXRhZyB3ZWVrZGF5czsNCiAgICAgICAgZW51bSAiTW9uZGF5IjsNCiAgICAg ICAgZW51bSAiVHVlc2RheSI7DQogICAgICAgIGVudW0gIldlZG5lc2RheSI7DQogICAgICAgIGVu dW0gIlRodXJzZGF5IjsNCiAgICAgICAgZW51bSAiRnJpZGF5IjsNCiAgICAgIH0NCiAgICAgIHR5 cGUgZW51bWVyYXRpb24gew0KICAgICAgICBleHQ6dW5pb24tdGFnIHdlZWtlbmQ7DQogICAgICAg IGVudW0gIlNhdHVyZGF5IjsNCiAgICAgICAgZW51bSAiU3VuZGF5IjsNCiAgICAgIH0NCiAgICB9 DQogIH0NCg0KSWYgSSBhc3N1bWUgdGhpcyBzb2x1dGlvbiBvciBzaW1pbGFyIHNvbHV0aW9uIGlz IGltcGxlbWVudGVkLCB0aGUgbmV4dCBxdWVzdGlvbiBpcyBob3cgdGhpcyB0YWcgaXMgZW5jb2Rl ZCBpbiBDQk9SLg0KTGV0IGFzc3VtZSB0aGF0IHRoZSBkYXRhIG5vZGUgU0lEIGlzIDE4MjAgYW5k IHRoZSBTSUQgYXNzaWduZWQgdG8gIndlZWtkYXlzIiB0YWcgaXMgIDE4MjEuDQoNCldoZW4gc2V0 IHRvICJUdWVzZGF5IiwgdGhpcyBkYXRhIG5vZGUgY2FuIGJlIGVuY29kZWQgdXNpbmcgYSBDQk9S IG1hcCBhcyBmb2xsb3dzOg0KDQp7DQogICAxODIwIDogeyAid2Vla2RheXMiLCAxfQ0KfQ0KDQpE byB3ZSBuZWVkIHRvIGFkZCBhIENCT1IgdGFnIHRvIHRoaXMgZW5jb2RpbmcgdG8gc3BlY2lmeSB0 aGUgdXNlIG9mIGEgdW5pb24gdGFnPyAoOTkgaW4gdGhpcyBleGFtcGxlKQ0KSSBwZXJzb25hbGx5 IGRvbid0IHRoaW5rIHNvIHNpbmNlIHRoZSB1c2Ugb2YgYSBDQk9SIG1hcCBmb3IgYSB1bmlvbiBk YXRhIG5vZGUgaXMgbm90IGN1cnJlbnRseSBwb3NzaWJsZS4NCg0Kew0KICAgMTgyMCA6ICg5OSkg eyAid2Vla2RheXMiLCAxfQ0KfQ0KDQpTaG91bGQgd2UgdXNlIGEgU0lEIGluc3RlYWQgb2YgdGhl IHRhZz8gDQoNCnsNCiAgIDE4MjAgOiB7IDE4MjEsIDF9DQp9DQoNClNob3VsZCB3ZSB1c2UgYSBk ZWx0YSBiZXR3ZWVuIHRoZSBkYXRhIG5vZGUgU0lEIGFuZCB0aGUgdW5pb24gdGFnIFNJRD8NClRo ZSBkcmF3YmFjayBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgdGhlIHNhbWUgdmFsdWUgYXNzaWdu ZWQgdG8gZGlmZmVyZW50IGRhdGEgbm9kZXMgaXMgZW5jb2RlZCBkaWZmZXJlbnRseS4NCkkgd29u J3QgcGVyc29uYWxseSByZWNvbW1lbmQgdGhpcyBhcHByb2FjaC4NCg0Kew0KICAgMTgyMCA6IHsg MSwgMX0NCn0NCg0KSSBob3BlIHRoaXMgZW1haWwgd2lsbCBoZWxwIG1vdmluZyB0aGUgZGlzY3Vz c2lvbiBjbG9zZXIgdG8gdGhlIGZpbmFsIHNvbHV0aW9uLg0KDQpQbGVhc2UgY29tbWVudHMNCk1p Y2hlbA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSnVlcmdlbiBTY2hvZW53 YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IA0KU2VudDogV2Vk bmVzZGF5LCBNYXJjaCAyNywgMjAxOSAyOjE3IEFNDQpUbzogTWljaGVsIFZlaWxsZXR0ZSA8TWlj aGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQuY29tPg0KQ2M6IExhZGlzbGF2IExob3RrYSA8bGhvdGth QG5pYy5jej47IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPjsgbmV0Y29uZkBpZXRmLm9y ZzsgY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRjb25mXSBZQU5HIGVuY29kaW5nIGlu IENCT1INCg0KSGksDQoNCmEgdW5pb24gY2FuIGJlIGZvcm1lZCBieSB1c2luZyBtZW1iZXIgdHlw ZXMgdGhhdCBhcmUgaW1wb3J0ZWQgYW5kIG5vdCB1bmRlciBjaGFuZ2UgY29udHJvbCBvZiBhIHNp bmdsZSBhdXRob3Ivb3JnYW5pemF0aW9uIGFuZCBpZGVhbGx5IHRoaXMgc2hvdWxkIHdvcmsgd2l0 aG91dCBjb21wbGV4IGNvb3JkaW5hdGlvbiBvZiBuYW1lIGFuZCBudW1iZXIgc3BhY2VzLg0KRHVw bGljYXRlIGVudW0vYml0cyB2YWx1ZXMgYXJlIGxlZ2FsIGluIFlBTkcgdG9kYXkgc28gYW4gZW5j b2RpbmcgaGFzIHRvIGRlYWwgd2l0aCB0aGlzIGFzcGVjdCBvZiBsaWZlLg0KDQpBIHJvYnVzdCBm aXggdG8gYWxsIHRoZXNlIHByb2JsZW1zIHdpbGwgYmUgdG8gdGFnIHRoZSB0eXBlIG1lbWJlcnMg aW4gb3JkZXIgdG8gZGlzY3JpbWluYXRlIHRoZSB2YWx1ZXMgaW4gdGhlIGVuY29kaW5ncy4gVGhp cywgaG93ZXZlciwgd2lsbCB0YWtlIHNvbWUgdGltZSB0byBzcGVjaWZ5IGFuZCB3ZSB3aWxsIG5l ZWQgdG8gcHJlc2VydmUgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgd2l0aCB1bmlvbnMgd2l0aG91 dCBhIHRhZyAoYnV0IGNvbXBpbGVycyBjYW4gZW5jb3VyYWdlIHBlb3BsZSB0byBhZGQgdGFncyB3 aGVuZXZlciBtb2R1bGVzIGFyZSB1cGRhdGVkKS4NCg0KL2pzDQoNCk9uIFdlZCwgTWFyIDI3LCAy MDE5IGF0IDAxOjEyOjUyQU0gKzAwMDAsIE1pY2hlbCBWZWlsbGV0dGUgd3JvdGU6DQo+IEhpIExh ZGlzbGF2DQo+IA0KPiBJZiBJIHN1bW1hcml6ZSB0aGlzIGlzc3VlIG9mIG11bHRpcGxlIGVudW1l cmF0aW9ucyBvciBiaXRzIGluIGEgdW5pb24sIHRoaXMgcHJvYmxlbSBjYW4gYmUgc29sdmUgYnkg dGhlIGZvbGxvd2luZyBhcHByb2FjaGVzOg0KPiANCj4gLSBUbyBub3QgYWxsb3dzIHRoZXNlIGR1 cGxpY2F0ZSB2YWx1ZXMgb3IgcG9zaXRpb25zIHRvIGhhcHBlbiBpbiBZQU5HDQo+IC0gVG8gZW5j b2RlIGVudW1lcmF0aW9ucyBhbmQgYml0cyBhcyBzdHJpbmcgKGluIGFsbCB1bmlvbnMgb3Igb25s eSANCj4gd2hlbiBtdWx0aXBsZSBlbnVtZXJhdGlvbnMgb3IgYml0cyBhcmUgZGVmaW5lZCkNCj4g LSBUbyBlbmNvZGUgZW51bWVyYXRpb25zIGFuZCBiaXRzIGFzIFNJRCAoaW4gYWxsIHVuaW9ucyBv ciBvbmx5IHdoZW4gDQo+IG11bHRpcGxlIGVudW1lcmF0aW9ucyBvciBiaXRzIGFyZSBkZWZpbmVk KQ0KPiAtIFRvIGVuY29kZSBlbnVtZXJhdGlvbnMgYW5kIGJpdHMgYXMgZGVsdGEgYmV0d2VlbiB0 aGUgdmFsdWUgU0lEIGFuZCANCj4gdGhlIGxlYWYgU0lEIChpbiBhbGwgdW5pb25zIG9yIG9ubHkg d2hlbiBtdWx0aXBsZSBlbnVtZXJhdGlvbnMgb3IgYml0cyANCj4gYXJlIGRlZmluZWQpDQo+IA0K PiBJbiB0aGlzIGVtYWlsLCBJIHdpbGwgbGlrZSB0byBmb2N1cyBvbiB0aGUgZmlyc3Qgb3B0aW9u LCBmaXhpbmcgdGhlIHByb2JsZW0gZGlyZWN0bHkgaW4gWUFORyBpbnN0ZWFkIG9mIGZpeGluZyB0 aGUgY29uc2VxdWVuY2VzLg0KPiANCj4gV2l0aG91dCBhbnkgY2hhbmdlcyBpbiBZQU5HLCBhIHVu aW9uIHdpdGggbXVsdGlwbGUgZW51bWVyYXRpb24gb3IgYml0cyBjYW4gYmUgY29uc3RydWN0ZWQg d2l0aG91dCB2YWx1ZSBvciBwb3NpdGlvbiBvdmVybGFwcy4NCj4gRm9yIGV4YW1wbGU6DQo+IA0K PiAgIGxlYWYgbXVsdGlwbGUtZW51bWVyYXRpb25zLXRlc3QtMSB7DQo+ICAgICB0eXBlIHVuaW9u IHsNCj4gICAgICAgdHlwZSBlbnVtZXJhdGlvbiB7DQo+ICAgICAgICAgZW51bSAiTW9uZGF5IiB7 IHZhbHVlIDA7IH0NCj4gICAgICAgICBlbnVtICJUdWVzZGF5IiB7IHZhbHVlIDE7IH0NCj4gICAg ICAgICBlbnVtICJXZWRuZXNkYXkiIHsgdmFsdWUgMjsgfQ0KPiAgICAgICAgIGVudW0gIlRodXJz ZGF5IiB7IHZhbHVlIDM7IH0NCj4gICAgICAgICBlbnVtICJGcmlkYXkiIHsgdmFsdWUgNDsgfQ0K PiANCj4gICAgICAgfQ0KPiAgICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCj4gICAgICAgICBlbnVt ICJTYXR1cmRheSIgeyB2YWx1ZSA1OyB9DQo+ICAgICAgICAgZW51bSAiU3VuZGF5IiB7IHZhbHVl IDY7IH0NCj4gICAgICAgfQ0KPiAgICAgfQ0KPiAgIH0NCj4gDQo+ICAgbGVhZiBtdWx0aXBsZS1i aXRzLXRlc3QtMSB7DQo+ICAgICB0eXBlIHVuaW9uIHsNCj4gICAgICAgdHlwZSBiaXRzIHsNCj4g ICAgICAgICBiaXQgICJNb25kYXkiIHsgcG9zaXRpb24gIDA7IH0NCj4gICAgICAgICBiaXQgIlR1 ZXNkYXkiIHsgcG9zaXRpb24gIDE7IH0NCj4gICAgICAgICBiaXQgIldlZG5lc2RheSIgeyBwb3Np dGlvbiAgMjsgfQ0KPiAgICAgICAgIGJpdCAiVGh1cnNkYXkiIHsgcG9zaXRpb24gIDM7IH0NCj4g ICAgICAgICBiaXQgIkZyaWRheSIgeyBwb3NpdGlvbiAgNDsgfQ0KPiANCj4gICAgICAgfQ0KPiAg ICAgICB0eXBlIGJpdHMgew0KPiAgICAgICAgIGJpdCAiU2F0dXJkYXkiIHsgcG9zaXRpb24gNTsg fQ0KPiAgICAgICAgIGJpdCAiU3VuZGF5IiB7IHBvc2l0aW9uIDY7IH0NCj4gICAgICAgfQ0KPiAg ICAgfQ0KPiAgIH0NCj4gDQo+IFdoZW4gdXNpbmcgYWxyZWFkeSBkZWZpbmVkIHR5cGVkZWYsIGF2 b2lkaW5nIG92ZXJsYXAgaXMgbGVzcyBvYnZpb3VzIHdpdGhvdXQgc29tZSBoZWxwLg0KPiBUbyBo ZWxwIGJ1aWxkaW5nIHVuaW9ucyB3aXRoIGFscmVhZHkgZGVmaW5lZCB0eXBlZGVmcywgSSBwcm9w b3NlIHRvIGludHJvZHVjZSB0d28gZXh0ZW5zaW9ucy4gDQo+IA0KPiAgIGV4dGVuc2lvbiB2YWx1 ZS1vZmZzZXQgew0KPiAgICAgYXJndW1lbnQgb2Zmc2V0IHsNCj4gICAgICAgeWluLWVsZW1lbnQg dHJ1ZTsNCj4gICAgIH0NCj4gICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICJPZmZzZXQgYWRkZWQg dG8gZWFjaCBlbnVtIHZhbHVlIG9mIHRoZSBhc3NvY2lhdGVkIGVudW1lcmF0aW9uLiI7DQo+ICAg fQ0KPiAgIA0KPiAgIGV4dGVuc2lvbiBwb3NpdGlvbi1vZmZzZXQgew0KPiAgICAgYXJndW1lbnQg b2Zmc2V0IHsNCj4gICAgICAgeWluLWVsZW1lbnQgdHJ1ZTsNCj4gICAgIH0NCj4gICAgIGRlc2Ny aXB0aW9uDQo+ICAgICAgICJPZmZzZXQgdmFsdWUgYWRkZWQgdG8gZWFjaCBiaXQgcG9zaXRpb24g b2YgdGhlIGFzc29jaWF0ZWQgYml0cy4iOw0KPiAgIH0NCj4gDQo+IFRoZSB2YWx1ZS1vZmZzZXQg ZXh0ZW5zaW9uIGNhbiBiZSB1c2VkIGFzIGZvbGxvdzoNCj4gDQo+ICAgICB0eXBlIGVudW1lcmF0 aW9uIHsNCj4gICAgICAgZW51bSAiTW9uZGF5IjsNCj4gICAgICAgZW51bSAiVHVlc2RheSI7DQo+ ICAgICAgIGVudW0gIldlZG5lc2RheSI7DQo+ICAgICAgIGVudW0gIlRodXJzZGF5IjsNCj4gICAg ICAgZW51bSAiRnJpZGF5IjsNCj4gICAgIH0NCj4gICB9DQo+IA0KPiAgIHR5cGVkZWYgd2Vla2Vu ZCB7DQo+ICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCj4gICAgICAgZW51bSAiU2F0dXJkYXkiOw0K PiAgICAgICBlbnVtICJTdW5kYXkiOw0KPiAgICAgfQ0KPiAgIH0NCj4gICANCj4gICBsZWFmIG11 bHRpcGxlLWVudW1lcmF0aW9ucy10ZXN0LTMgew0KPiAgICAgdHlwZSB1bmlvbiB7DQo+ICAgICAg IHR5cGUgd2Vla2RheXM7DQo+ICAgICAgIHR5cGUgd2Vla2VuZCB7DQo+ICAgICAgICAgZXh0OnZh bHVlLW9mZnNldCA1Ow0KPiAgICAgICB9DQo+ICAgICB9DQo+ICAgfQ0KPiANCj4gVGhlIHBvc2l0 aW9uLW9mZnNldCBleHRlbnNpb24gY2FuIGJlIHVzZWQgYXMgZm9sbG93Og0KPiANCj4gICB0eXBl ZGVmIHdlZWtkYXlzLWZsYWdzIHsNCj4gICAgIHR5cGUgYml0cyB7DQo+ICAgICAgIGJpdCAiTW9u ZGF5IjsNCj4gICAgICAgYml0ICJUdWVzZGF5IjsNCj4gICAgICAgYml0ICJXZWRuZXNkYXkiOw0K PiAgICAgICBiaXQgIlRodXJzZGF5IjsNCj4gICAgICAgYml0ICJGcmlkYXkiOw0KPiAgICAgfQ0K PiAgIH0NCj4gDQo+ICAgdHlwZWRlZiB3ZWVrZW5kLWZsYWdzIHsNCj4gICAgIHR5cGUgYml0cyB7 DQo+ICAgICAgIGJpdCAiU2F0dXJkYXkiOw0KPiAgICAgICBiaXQgIlN1bmRheSI7DQo+ICAgICB9 DQo+ICAgfQ0KPiAgIA0KPiAgIGxlYWYgbXVsdGlwbGUtYml0cy10ZXN0LTMgew0KPiAgICAgdHlw ZSB1bmlvbiB7DQo+ICAgICAgIHR5cGUgd2Vla2RheXMtZmxhZ3M7DQo+ICAgICAgIHR5cGUgd2Vl a2VuZC1mbGFncyB7DQo+ICAgICAgICAgZXh0OnBvc2l0aW9uLW9mZnNldCA1Ow0KPiAgICAgICB9 DQo+ICAgICB9DQo+ICAgfQ0KPiANCj4gVGhlIHlhbmcgZmlsZSBpbiBhdHRhY2htZW50IHNob3cg ZGlmZmVyZW50IGV4YW1wbGVzIGJhc2VkIG9uIHRoaXMgYXBwcm9hY2guDQo+IFRoaXMgbW9kdWxl IGhhdmUgYmVlbiB2YWxpZGF0ZWQgdXNpbmcgDQo+IGh0dHBzOi8vY2FuMDEuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGd3d3LnkNCj4gYW5ndmFsaWRh dG9yLmNvbSUyRnZhbGlkYXRvciZhbXA7ZGF0YT0wMiU3QzAxJTdDJTdDYzY5NDI2ZGNhYWY4NDQ4 ZTFkNA0KPiA3MDhkNmIyN2JjNzM1JTdDNGY2ZmJkMTMwZGZiNDE1MDg1YzNkNDMyNjBjMDQzMDkl N0MwJTdDMCU3QzYzNjg5MjY0MjA3DQo+IDMyNTc2NjAmYW1wO3NkYXRhPVhxbzQwbHpCaklOVkZa aElaWkkxTEVrdEFkcTVtZWUyQWR4ZVlxZWZuc0ElM0QmYW1wO3INCj4gZXNlcnZlZD0wIElmIHRo aXMgYXBwcm9hY2ggaXMgYWNjZXB0ZWQsIHRvb2xzIGxpa2UgcHlhbmcgc2hvdWxkIGJlIA0KPiB1 cGRhdGVkIHRvIHByb2R1Y2UgYW4gZXJyb3IgaWYgbXVsdGlwbGUgZW51bWVyYXRpb25zIG9yIGJp dHMgYXJlIGRlZmluZWQgd2l0aCB2YWx1ZSBvciBwb3NpdGlvbiBvdmVybGVhcHMuDQo+IA0KPiBQ bGVhc2UgY29tbWVudCwNCj4gTWljaGVsDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+DQo+IFNlbnQ6IE1vbmRh eSwgTWFyY2ggMjUsIDIwMTkgNDowNyBBTQ0KPiBUbzogSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxq LnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+OyANCj4gQ2Fyc3RlbiBCb3JtYW5u IDxjYWJvQHR6aS5vcmc+DQo+IENjOiBNaWNoZWwgVmVpbGxldHRlIDxNaWNoZWwuVmVpbGxldHRl QHRyaWxsaWFudC5jb20+OyANCj4gbmV0Y29uZkBpZXRmLm9yZzsgY29yZUBpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW25ldGNvbmZdIFlBTkcgZW5jb2RpbmcgaW4gQ0JPUg0KPiANCj4gSnVlcmdl biBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdy aXRlczoNCj4gDQo+ID4gSSB0aGluayB3ZSBuZWVkIHRvIGxvb2sgYXQgdGhlIHdob2xlIHBpY3R1 cmUgYW5kIGluIHdoaWNoIGRpcmVjdGlvbiANCj4gPiB3ZSB3YW50IHRvIGdvLiBJbiB0aGUgbG9u Z2VyIHRlcm0sIEkgd291bGQgcHJlZmVyIGEgc29sdXRpb24gd2hlcmUgDQo+ID4gdGhlIHZhbHVl cyBvZiBhIHVuaW9uIGFyZSBkaXNjcmltaW5hdGVkLiBUaGUgY3VycmVudCBYTUwgZW5jb2Rpbmcg DQo+ID4gYmVoYXZpb3VyIG9mICdmaXJzdCBtYXRjaCB3aW5zJyBpcyBmcmFnaWxlIChmb3IgZXhh bXBsZSwgaWYgc29tZW9uZSANCj4gPiBhZGRzIGFuIGVudW0gdG8gYSB0eXBlLCB0aGUgaW50ZXJw cmV0YXRpb24gb2YgZGF0YSBjYW4gY2hhbmdlKS4NCj4gPg0KPiA+IExvb2sgYXQgdGhpczoNCj4g Pg0KPiA+IHR5cGVkZWYgYmFyIHsNCj4gPiAgIHR5cGUgdW5pb24gew0KPiA+ICAgICB0eXBlIGVu dW1lcmF0aW9uIHsgZW51bSAiMSI7IHZhbHVlIDI7IGVudW0gIjIiOyB2YWx1ZSAxOyB9DQo+ID4g ICAgIHR5cGUgdWludDg7DQo+ID4gICB9DQo+ID4gfQ0KPiA+DQo+ID4gV2UgaGF2ZSBzb21lIGVu Y29kaW5ncyB0aGF0IHNlbmQgdGhlIHN0cmluZyByZXByZXNlbnRhdGlvbnMgb2YgdGhlIA0KPiA+ IHZhbHVlcyBhbmQgc29tZSBlbmNvZGluZ3MgdGhhdCBwcmVmZXIgdG8gc2VuZCBudW1lcmljIA0K PiA+IHJlcHJlc2VudGF0aW9ucyB3aGVyZSBwb3NzaWJsZS4gSW4gb3JkZXIgdG8gaGF2ZSBhIHJv YnVzdCBzb2x1dGlvbiwgDQo+ID4gZW5jb2RpbmdzIHNob3VsZCBsaWtlbHkgaW5kaWNhdGUgdG8g d2hpY2ggdHlwZSB0aGUgdmFsdWUgYmVsb25ncy4NCj4gDQo+IFBlcmhhcHMgdGhlIGVhc2llc3Qg d2F5IHdvdWxkIGJlIHRvIHVzZSAob3B0aW9uYWwpIGFubm90YXRpb24gdGhhdCBzcGVjaWZpZXMs IHVzaW5nIGFuIG9yZGluYWwgbnVtYmVyLCB3aGljaCBvZiB0aGUgbWVtYmVyIHR5cGVzIGlzIHVz ZWQgZm9yIHRoZSBwYXJ0aWN1bGFyIGluc3RhbmNlLiBCdXQgc2luY2UgdGhlcmUgY2FuIGJlIHVu aW9ucyBpbnNpZGUgdW5pb25zLCBhIGxpc3Qgb2YgbnVtYmVycyB3b3VsZCBiZSBuZWVkZWQgaW4g Z2VuZXJhbC4NCj4gDQo+IExhZGENCj4gDQo+ID4NCj4gPiAvanMNCj4gPg0KPiA+IE9uIFNhdCwg TWFyIDIzLCAyMDE5IGF0IDEwOjAzOjMyQU0gKzAxMDAsIENhcnN0ZW4gQm9ybWFubiB3cm90ZToN Cj4gPj4gV2VsbCwgaWYgdGhhdCBpcyBhIHByb2JsZW0sIHdlIGNhbiBnbyBmb3IgYSBsb25nZXIg cmVwcmVzZW50YXRpb24gd2l0aGluIHVuaW9ucyAoc2VjdGlvbiA2LjEyKS4gIFRoZW9yZXRpY2Fs bHksIHdlIGNvdWxkIGRvIHRoYXQgb25seSBvZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25lIGVudW0g aW4gdGhlIHVuaW9uIHR5cGUgKHNvIHRoaW5ncyBzdGF5IGVmZmljaWVudCBpZiB0aGVyZSBpcyBv bmx5IG9uZSksIGJ1dCB0aGF0IG1pZ2h0IHBvc2UgZGlmZmljdWx0aWVzIHdpdGggbW9kZWwgZXZv bHV0aW9uLg0KPiA+PiANCj4gPj4gR29pbmcgZm9yIGEgc3RyaW5nIHJlcHJlc2VudGF0aW9uIHJl cGVhdHMgdGhlIGZlYXR1cmUgb2YgWE1MIFlBTkcgKHdoaWNoIHdhcyBwb3J0ZWQgb3ZlciB0byBK U09OIFlBTkcpOg0KPiA+PiANCj4gPj4gdHlwZWRlZiBmb28gew0KPiA+PiAgIHR5cGUgdW5pb24g ew0KPiA+PiAgICAgdHlwZSBlbnVtZXJhdGlvbiB7DQo+ID4+ICAgICAgIGVudW0gcmVkIHsgdmFs dWUgMTsgfQ0KPiA+PiAgICAgICBlbnVtIGJyZWVuIHsgdmFsdWUgMjsgfQ0KPiA+PiAgICAgICBl bnVtIGdsdWUgeyB2YWx1ZSAzOyB9DQo+ID4+ICAgICB9DQo+ID4+ICAgICB0eXBlIGVudW1lcmF0 aW9uIHsNCj4gPj4gICAgICAgZW51bSB0YWNrcyB7IHZhbHVlIDE7IH0NCj4gPj4gICAgICAgZW51 bSBuYWlscyB7IHZhbHVlIDI7IH0NCj4gPj4gICAgICAgZW51bSBnbHVlIHsgdmFsdWUgMzsgfQ0K PiA+PiAgICAgfQ0KPiA+PiAgIH0NCj4gPj4gfQ0KPiA+PiANCj4gPj4gSWYgeW91IHVzZSDigJxn bHVl4oCdLCB5b3UgZG9u4oCZdCBrbm93IHdoaWNoIG9mIHRoZSBlbnVtZXJhdGlvbnMgYXJlIGJl aW5nIHVzZWQuDQo+ID4+IA0KPiA+PiBVc2luZyBTSURzLCB3ZSBjYW4gZG8gYmV0dGVyLg0KPiA+ PiANCj4gPj4gU28gd2hhdCBkbyB3ZSBoYXZlIHRvIGRvIHRvIGdldCB0aGUgU0lEIHRvb2wgdG8g YWxsb2NhdGUgU0lEcyBmb3IgZW51bSB2YWx1ZXM/DQo+ID4+IA0KPiA+PiBXZSBjb3VsZCB0aGVu IGRlZmluZSB0aGUgQ0JPUiB0YWcgZm9yIGVudW1zIGluIHVuaW9ucyB0byB0YWtlIHRoZSB1c3Vh bCBTSUQgZGlmZmVyZW5jZSAoZGVsdGEgcmVsYXRpdmUgdG8gdGhlIGVudmlyb25tZW50LCBJ4oCZ ZCB0aGluayksIG5vdCBhbiBpbnRlZ2VyIHZhbHVlLg0KPiA+PiANCj4gPj4gU2V2ZXJhbCBvZiB1 cyBhcmUgYXQgdGhlIGhhY2thdGhvbiBhbmQgY291bGQgbWFrZSBzb21ldGhpbmcgaGFwcGVuIHRv ZGF5IGFuZCB0b21vcnJvdy4NCj4gPj4gDQo+ID4+IEdyw7zDn2UsIENhcnN0ZW4NCj4gPj4gDQo+ ID4+IA0KPiA+PiA+IE9uIE1hciAyMiwgMjAxOSwgYXQgMTg6MzAsIFJvYiBXaWx0b24gKHJ3aWx0 b24pIDxyd2lsdG9uQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4+ID4gDQo+ID4+ID4gSSBndWVzcyB0 aGF0IHRoZSBjb25jZXJuIGlzIHRoYXQgdGhpcyBpbnRyb2R1Y2VzIG1vcmUgdmFyaWF0aW9uIGlu IGhvdyBkYXRhIGlzIGludGVycHJldGVkIGJldHdlZW4gdGhlIGRpZmZlcmVudCBYTUwvSlNPTi9D Qk9SIGVuY29kaW5ncy4NCj4gPj4gPiANCj4gPj4gPiBFLmcuIGlmIHNvbWVvbmUgc3dpdGNoZWQg ZnJvbSBYTUwgdG8gQ0JPUiwgc3VkZGVubHkgdGhlIGNvbmZpZ3VyYXRpb24gb3Igc3RhdGUgZGF0 YSBtYXkgaGF2ZSBhIGRpZmZlcmVudCBtZWFuaW5nLg0KPiA+PiA+IA0KPiA+PiA+IFRoYW5rcywN Cj4gPj4gPiBSb2INCj4gPj4gPiANCj4gPj4gPiANCj4gPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPj4gPj4gRnJvbTogQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+DQo+ ID4+ID4+IFNlbnQ6IDIyIE1hcmNoIDIwMTkgMTY6MDgNCj4gPj4gPj4gVG86IE1pY2hlbCBWZWls bGV0dGUgPE1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50LmNvbT4NCj4gPj4gPj4gQ2M6IFJvYiBX aWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT47IGNvcmVAaWV0Zi5vcmc7IA0KPiA+ PiA+PiBuZXRjb25mQGlldGYub3JnDQo+ID4+ID4+IFN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gWUFO RyBlbmNvZGluZyBpbiBDQk9SDQo+ID4+ID4+IA0KPiA+PiA+PiBPbiBNYXIgMjIsIDIwMTksIGF0 IDE2OjQ1LCBNaWNoZWwgVmVpbGxldHRlIA0KPiA+PiA+PiA8TWljaGVsLlZlaWxsZXR0ZUB0cmls bGlhbnQuY29tPg0KPiA+PiA+PiB3cm90ZToNCj4gPj4gPj4+IA0KPiA+PiA+Pj4gVGhlIG9ubHkg cG90ZW50aWFsIHByb2JsZW0gSSBhd2FyZSBpcyB3aGVuIG11bHRpcGxlIA0KPiA+PiA+Pj4gZW51 bWVyYXRpb25zIGFyZSBwYXJ0IG9mDQo+ID4+ID4+IHRoZSBzYW1lIHVuaW9uLg0KPiA+PiA+Pj4g VmFsdWUgNCBmcm9tIGVudW1lcmF0aW9uIEEgd2lsbCBiZSBlbmNvZGVkIHRoZSBzYW1lIHdheSBh cyANCj4gPj4gPj4+IFZhbHVlDQo+ID4+ID4+PiA0IGZyb20NCj4gPj4gPj4gZW51bWVyYXRpb24g Qi4NCj4gPj4gPj4gDQo+ID4+ID4+IOKApiBhbmQgdGhhdCBpcyBub3QgYSBwcm9ibGVtIGZvciB0 aGUgWE1MIHZlcnNpb24sIGJlY2F1c2UgdGhlIA0KPiA+PiA+PiBzdHJpbmcgaXMgYmVpbmcgdXNl ZCBpbnN0ZWFkIG9mIHRoZSB2YWx1ZS4gIChCdXQgdGhlbiBpZiB0d28gDQo+ID4+ID4+IGVudW1l cmF0aW9ucyBzaGFyZSBhIHN0cmluZywgeW91IGhhdmUgdGhlIGVxdWl2YWxlbnQgcHJvYmxlbSBp biANCj4gPj4gPj4gdGhlIFhNTCBzZXJpYWxpemF0aW9uLikNCj4gPj4gPj4gDQo+ID4+ID4+IEFu eXdheSwgSSBoYXZlbuKAmXQgc2VlbiBhIHBpZWNlIG9mIHJlYWwtd29ybGQgWUFORyB0aGF0IGFj dHVhbGx5IA0KPiA+PiA+PiBoYXMgdGhpcyBwcm9ibGVtLCBzbyBJIHdvdWxkIGJlIGEgYml0IHJl bHVjdGFudCB0byBtYWtlIA0KPiA+PiA+PiBDQk9SLWJhc2VkIGltcGxlbWVudGF0aW9ucyBtb3Jl IGNvbXBsZXggKGFuZCBsZXNzIGVmZmljaWVudCkgc28gc29sdmUgdGhpcyAobm9uLT8pcHJvYmxl bS4NCj4gPj4gPj4gDQo+ID4+ID4+IEdyw7zDn2UsIENhcnN0ZW4NCj4gPj4gPiANCj4gPj4gPiAN Cj4gPj4gPiANCj4gPj4gDQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4+IG5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4+IG5ldGNvbmZAaWV0 Zi5vcmcNCj4gPj4gaHR0cHM6Ly9jYW4wMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGdw0KPiA+PiB3dw0KPiA+PiAuaWV0Zi5vcmclMkZtYWlsbWFu JTJGbGlzdGluZm8lMkZuZXRjb25mJmFtcDtkYXRhPTAyJTdDMDElN0MlN0MzNDNlDQo+ID4+IGE4 DQo+ID4+IGQxY2Y4ZjRlMzlhZmM3MDhkNmIwZjhkODc0JTdDNGY2ZmJkMTMwZGZiNDE1MDg1YzNk NDMyNjBjMDQzMDklN0MwJTcNCj4gPj4gQzENCj4gPj4gJTdDNjM2ODkwOTgwMTgyNTUzNDAwJmFt cDtzZGF0YT11MUtGQVlBdXMxNkI4YTdzZ3NCZlBmSXF1T3B0TWxhT2IlMg0KPiA+PiBCMA0KPiA+ PiBrdlBaZ3I0byUzRCZhbXA7cmVzZXJ2ZWQ9MA0KPiA+DQo+ID4gLS0gDQo+ID4gSnVlcmdlbiBT Y2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4g PiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBC cmVtZW4gfCBHZXJtYW55DQo+ID4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0 cHM6Ly9jYW4wMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB JTJGJTJGd3d3LmphY29icy11bml2ZXJzaXR5LmRlJTJGJmFtcDtkYXRhPTAyJTdDMDElN0MlN0Nj Njk0MjZkY2FhZjg0NDhlMWQ0NzA4ZDZiMjdiYzczNSU3QzRmNmZiZDEzMGRmYjQxNTA4NWMzZDQz MjYwYzA0MzA5JTdDMCU3QzAlN0M2MzY4OTI2NDIwNzMyNTc2NjAmYW1wO3NkYXRhPVJxU1l1TnBs UzRrT0xVMFIzZXRSenJSJTJGVTJjY3dsamtFWmtqSEhEVTFIQSUzRCZhbXA7cmVzZXJ2ZWQ9MD4N Cj4gPg0KPiA+DQo+ID4gT24gU2F0LCBNYXIgMjMsIDIwMTkgYXQgMTA6MDM6MzJBTSArMDEwMCwg Q2Fyc3RlbiBCb3JtYW5uIHdyb3RlOg0KPiA+PiBXZWxsLCBpZiB0aGF0IGlzIGEgcHJvYmxlbSwg d2UgY2FuIGdvIGZvciBhIGxvbmdlciByZXByZXNlbnRhdGlvbiB3aXRoaW4gdW5pb25zIChzZWN0 aW9uIDYuMTIpLiAgVGhlb3JldGljYWxseSwgd2UgY291bGQgZG8gdGhhdCBvbmx5IG9mIHRoZXJl IGlzIG1vcmUgdGhhbiBvbmUgZW51bSBpbiB0aGUgdW5pb24gdHlwZSAoc28gdGhpbmdzIHN0YXkg ZWZmaWNpZW50IGlmIHRoZXJlIGlzIG9ubHkgb25lKSwgYnV0IHRoYXQgbWlnaHQgcG9zZSBkaWZm aWN1bHRpZXMgd2l0aCBtb2RlbCBldm9sdXRpb24uDQo+ID4+IA0KPiA+PiBHb2luZyBmb3IgYSBz dHJpbmcgcmVwcmVzZW50YXRpb24gcmVwZWF0cyB0aGUgZmVhdHVyZSBvZiBYTUwgWUFORyAod2hp Y2ggd2FzIHBvcnRlZCBvdmVyIHRvIEpTT04gWUFORyk6DQo+ID4+IA0KPiA+PiB0eXBlZGVmIGZv byB7DQo+ID4+ICAgdHlwZSB1bmlvbiB7DQo+ID4+ICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCj4g Pj4gICAgICAgZW51bSByZWQgeyB2YWx1ZSAxOyB9DQo+ID4+ICAgICAgIGVudW0gYnJlZW4geyB2 YWx1ZSAyOyB9DQo+ID4+ICAgICAgIGVudW0gZ2x1ZSB7IHZhbHVlIDM7IH0NCj4gPj4gICAgIH0N Cj4gPj4gICAgIHR5cGUgZW51bWVyYXRpb24gew0KPiA+PiAgICAgICBlbnVtIHRhY2tzIHsgdmFs dWUgMTsgfQ0KPiA+PiAgICAgICBlbnVtIG5haWxzIHsgdmFsdWUgMjsgfQ0KPiA+PiAgICAgICBl bnVtIGdsdWUgeyB2YWx1ZSAzOyB9DQo+ID4+ICAgICB9DQo+ID4+ICAgfQ0KPiA+PiB9DQo+ID4+ IA0KPiA+PiBJZiB5b3UgdXNlIOKAnGdsdWXigJ0sIHlvdSBkb27igJl0IGtub3cgd2hpY2ggb2Yg dGhlIGVudW1lcmF0aW9ucyBhcmUgYmVpbmcgdXNlZC4NCj4gPj4gDQo+ID4+IFVzaW5nIFNJRHMs IHdlIGNhbiBkbyBiZXR0ZXIuDQo+ID4+IA0KPiA+PiBTbyB3aGF0IGRvIHdlIGhhdmUgdG8gZG8g dG8gZ2V0IHRoZSBTSUQgdG9vbCB0byBhbGxvY2F0ZSBTSURzIGZvciBlbnVtIHZhbHVlcz8NCj4g Pj4gDQo+ID4+IFdlIGNvdWxkIHRoZW4gZGVmaW5lIHRoZSBDQk9SIHRhZyBmb3IgZW51bXMgaW4g dW5pb25zIHRvIHRha2UgdGhlIHVzdWFsIFNJRCBkaWZmZXJlbmNlIChkZWx0YSByZWxhdGl2ZSB0 byB0aGUgZW52aXJvbm1lbnQsIEnigJlkIHRoaW5rKSwgbm90IGFuIGludGVnZXIgdmFsdWUuDQo+ ID4+IA0KPiA+PiBTZXZlcmFsIG9mIHVzIGFyZSBhdCB0aGUgaGFja2F0aG9uIGFuZCBjb3VsZCBt YWtlIHNvbWV0aGluZyBoYXBwZW4gdG9kYXkgYW5kIHRvbW9ycm93Lg0KPiA+PiANCj4gPj4gR3LD vMOfZSwgQ2Fyc3Rlbg0KPiA+PiANCj4gPj4gDQo+ID4+ID4gT24gTWFyIDIyLCAyMDE5LCBhdCAx ODozMCwgUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPiB3cm90ZToNCj4g Pj4gPiANCj4gPj4gPiBJIGd1ZXNzIHRoYXQgdGhlIGNvbmNlcm4gaXMgdGhhdCB0aGlzIGludHJv ZHVjZXMgbW9yZSB2YXJpYXRpb24gaW4gaG93IGRhdGEgaXMgaW50ZXJwcmV0ZWQgYmV0d2VlbiB0 aGUgZGlmZmVyZW50IFhNTC9KU09OL0NCT1IgZW5jb2RpbmdzLg0KPiA+PiA+IA0KPiA+PiA+IEUu Zy4gaWYgc29tZW9uZSBzd2l0Y2hlZCBmcm9tIFhNTCB0byBDQk9SLCBzdWRkZW5seSB0aGUgY29u ZmlndXJhdGlvbiBvciBzdGF0ZSBkYXRhIG1heSBoYXZlIGEgZGlmZmVyZW50IG1lYW5pbmcuDQo+ ID4+ID4gDQo+ID4+ID4gVGhhbmtzLA0KPiA+PiA+IFJvYg0KPiA+PiA+IA0KPiA+PiA+IA0KPiA+ PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiA+PiBGcm9tOiBDYXJzdGVuIEJv cm1hbm4gPGNhYm9AdHppLm9yZz4NCj4gPj4gPj4gU2VudDogMjIgTWFyY2ggMjAxOSAxNjowOA0K PiA+PiA+PiBUbzogTWljaGVsIFZlaWxsZXR0ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQu Y29tPg0KPiA+PiA+PiBDYzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29t PjsgY29yZUBpZXRmLm9yZzsgDQo+ID4+ID4+IG5ldGNvbmZAaWV0Zi5vcmcNCj4gPj4gPj4gU3Vi amVjdDogUmU6IFtuZXRjb25mXSBZQU5HIGVuY29kaW5nIGluIENCT1INCj4gPj4gPj4gDQo+ID4+ ID4+IE9uIE1hciAyMiwgMjAxOSwgYXQgMTY6NDUsIE1pY2hlbCBWZWlsbGV0dGUgDQo+ID4+ID4+ IDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudC5jb20+DQo+ID4+ID4+IHdyb3RlOg0KPiA+PiA+ Pj4gDQo+ID4+ID4+PiBUaGUgb25seSBwb3RlbnRpYWwgcHJvYmxlbSBJIGF3YXJlIGlzIHdoZW4g bXVsdGlwbGUgDQo+ID4+ID4+PiBlbnVtZXJhdGlvbnMgYXJlIHBhcnQgb2YNCj4gPj4gPj4gdGhl IHNhbWUgdW5pb24uDQo+ID4+ID4+PiBWYWx1ZSA0IGZyb20gZW51bWVyYXRpb24gQSB3aWxsIGJl IGVuY29kZWQgdGhlIHNhbWUgd2F5IGFzIA0KPiA+PiA+Pj4gVmFsdWUNCj4gPj4gPj4+IDQgZnJv bQ0KPiA+PiA+PiBlbnVtZXJhdGlvbiBCLg0KPiA+PiA+PiANCj4gPj4gPj4g4oCmIGFuZCB0aGF0 IGlzIG5vdCBhIHByb2JsZW0gZm9yIHRoZSBYTUwgdmVyc2lvbiwgYmVjYXVzZSB0aGUgDQo+ID4+ ID4+IHN0cmluZyBpcyBiZWluZyB1c2VkIGluc3RlYWQgb2YgdGhlIHZhbHVlLiAgKEJ1dCB0aGVu IGlmIHR3byANCj4gPj4gPj4gZW51bWVyYXRpb25zIHNoYXJlIGEgc3RyaW5nLCB5b3UgaGF2ZSB0 aGUgZXF1aXZhbGVudCBwcm9ibGVtIGluIA0KPiA+PiA+PiB0aGUgWE1MIHNlcmlhbGl6YXRpb24u KQ0KPiA+PiA+PiANCj4gPj4gPj4gQW55d2F5LCBJIGhhdmVu4oCZdCBzZWVuIGEgcGllY2Ugb2Yg cmVhbC13b3JsZCBZQU5HIHRoYXQgYWN0dWFsbHkgDQo+ID4+ID4+IGhhcyB0aGlzIHByb2JsZW0s IHNvIEkgd291bGQgYmUgYSBiaXQgcmVsdWN0YW50IHRvIG1ha2UgDQo+ID4+ID4+IENCT1ItYmFz ZWQgaW1wbGVtZW50YXRpb25zIG1vcmUgY29tcGxleCAoYW5kIGxlc3MgZWZmaWNpZW50KSBzbyBz b2x2ZSB0aGlzIChub24tPylwcm9ibGVtLg0KPiA+PiA+PiANCj4gPj4gPj4gR3LDvMOfZSwgQ2Fy c3Rlbg0KPiA+PiA+IA0KPiA+PiA+IA0KPiA+PiA+IA0KPiA+PiANCj4gPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gbmV0Y29uZiBtYWlsaW5n IGxpc3QNCj4gPj4gbmV0Y29uZkBpZXRmLm9yZw0KPiA+PiBodHRwczovL2NhbjAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3DQo+ID4+IHd3DQo+ ID4+IC5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRm5ldGNvbmYmYW1wO2RhdGE9MDIl N0MwMSU3QyU3QzM0M2UNCj4gPj4gYTgNCj4gPj4gZDFjZjhmNGUzOWFmYzcwOGQ2YjBmOGQ4NzQl N0M0ZjZmYmQxMzBkZmI0MTUwODVjM2Q0MzI2MGMwNDMwOSU3QzAlNw0KPiA+PiBDMQ0KPiA+PiAl N0M2MzY4OTA5ODAxODI1NTM0MDAmYW1wO3NkYXRhPXUxS0ZBWUF1czE2QjhhN3Nnc0JmUGZJcXVP cHRNbGFPYiUyDQo+ID4+IEIwDQo+ID4+IGt2UFpncjRvJTNEJmFtcDtyZXNlcnZlZD0wDQo+ID4N Cj4gPiAtLSANCj4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2 ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiA+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAg Q2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4gPiBGYXg6ICAgKzQ5IDQy MSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL2NhbjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUlMkYm YW1wO2RhdGE9MDIlN0MwMSU3QyU3Q2M2OTQyNmRjYWFmODQ0OGUxZDQ3MDhkNmIyN2JjNzM1JTdD NGY2ZmJkMTMwZGZiNDE1MDg1YzNkNDMyNjBjMDQzMDklN0MwJTdDMCU3QzYzNjg5MjY0MjA3MzI1 NzY2MCZhbXA7c2RhdGE9UnFTWXVOcGxTNGtPTFUwUjNldFJ6clIlMkZVMmNjd2xqa0Vaa2pISERV MUhBJTNEJmFtcDtyZXNlcnZlZD0wPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+IG5l dGNvbmZAaWV0Zi5vcmcNCj4gPiBodHRwczovL2NhbjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuDQo+ID4gaWV0Zi5vcmclMkZtYWlsbWFu JTJGbGlzdGluZm8lMkZuZXRjb25mJmFtcDtkYXRhPTAyJTdDMDElN0MlN0MzNDNlYTgNCj4gPiBk MSANCj4gPiBjZjhmNGUzOWFmYzcwOGQ2YjBmOGQ4NzQlN0M0ZjZmYmQxMzBkZmI0MTUwODVjM2Q0 MzI2MGMwNDMwOSU3QzAlN0MxJQ0KPiA+IDdDIA0KPiA+IDYzNjg5MDk4MDE4MjU1MzQwMCZhbXA7 c2RhdGE9dTFLRkFZQXVzMTZCOGE3c2dzQmZQZklxdU9wdE1sYU9iJTJCMGt2DQo+ID4gUFoNCj4g PiBncjRvJTNEJmFtcDtyZXNlcnZlZD0wDQo+IA0KPiAtLQ0KPiBMYWRpc2xhdiBMaG90a2ENCj4g SGVhZCwgQ1ouTklDIExhYnMNCj4gUEdQIEtleSBJRDogMHhCOEY5MkIwOEE5Rjc2QzY3DQoNCg0K DQotLSANCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkg QnJlbWVuIGdHbWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5n IDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAg ICAgIDxodHRwczovL2NhbjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM0ElMkYlMkZ3d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUlMkYmYW1wO2RhdGE9MDIlN0Mw MSU3QyU3Q2M2OTQyNmRjYWFmODQ0OGUxZDQ3MDhkNmIyN2JjNzM1JTdDNGY2ZmJkMTMwZGZiNDE1 MDg1YzNkNDMyNjBjMDQzMDklN0MwJTdDMCU3QzYzNjg5MjY0MjA3MzI2NzY2MCZhbXA7c2RhdGE9 emNRdjRoUjh5a0pGZGh2c2QycW5UUFEzRVBkRVppakRjNGVUJTJCRG1zcXUwJTNEJmFtcDtyZXNl cnZlZD0wPg0K From nobody Wed Mar 27 09:02:39 2019 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 F312C1202F4; Wed, 27 Mar 2019 09:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=trilliant.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 LrBaLDRP0VPa; Wed, 27 Mar 2019 09:02:26 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-sn1nam04on071b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe4c::71b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D880120305; Wed, 27 Mar 2019 09:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W9xD9XUrtmdMzI/YcrFAfwj4/4hPRSN6CPG9FyxMceM=; b=FhKd4Mudwwvo2HgeaLObdEFEAzC+ZLsuye5cAWLo8iL10/x8N05zSaT6uhrr+2uBUVhxkR7z/SRVpURIjHrzW+sSY+ppvG6umMShnp3k5Rpa57aHZth0A+CqoT1D3SQ4HiBtSV6ILxE6D4Xc07itkDHzv29HaTGZURlhDnfQBbE= Received: from BL0PR06MB5042.namprd06.prod.outlook.com (10.167.240.31) by BL0PR06MB4914.namprd06.prod.outlook.com (10.167.234.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.15; Wed, 27 Mar 2019 16:01:56 +0000 Received: from BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::d5:e11c:db10:639d]) by BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::d5:e11c:db10:639d%3]) with mapi id 15.20.1730.019; Wed, 27 Mar 2019 16:01:56 +0000 From: Michel Veillette To: Juergen Schoenwaelder CC: Ladislav Lhotka , Carsten Bormann , "netconf@ietf.org" , "core@ietf.org" Thread-Topic: [netconf] YANG encoding in CBOR Thread-Index: AdTf3q8hCOPNH5o0Q0SJZRQQHN87VgA3tcGQAAL8XAAAAtt/gAAgmRkAAAJStYAAYEUIgABUqX2QAAwU1oAAE3mQoAAA8H+g Date: Wed, 27 Mar 2019 16:01:56 +0000 Message-ID: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5af4bcc4-6a92-49f2-8f2e-08d6b2cd898b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:BL0PR06MB4914; x-ms-traffictypediagnostic: BL0PR06MB4914: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 0989A7979C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39850400004)(366004)(376002)(346002)(136003)(199004)(189003)(13464003)(52314003)(2906002)(52536014)(4326008)(25786009)(6116002)(114624004)(66066001)(93156006)(3846002)(30864003)(14454004)(53936002)(72206003)(8676002)(81166006)(5024004)(14444005)(33656002)(45080400002)(966005)(76176011)(478600001)(2940100002)(6246003)(71190400001)(5660300002)(26005)(81156014)(86362001)(7696005)(71200400001)(6506007)(102836004)(7736002)(53546011)(316002)(93886005)(99286004)(105586002)(106356001)(6916009)(9686003)(55016002)(54906003)(6306002)(53946003)(446003)(486006)(6436002)(476003)(11346002)(256004)(99936001)(68736007)(74316002)(8936002)(97736004)(186003)(229853002)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4914; H:BL0PR06MB5042.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 0NvUeGnEFeZPawFzjRbRtLaUlMhXYzCoY3RfI5W3jLTVK/JkMlka/RcCrkZBGFSP2607PaZde8Yvg8RpSSVyMKeyd3/XGLN6+wp1DpXR+Y5Xuyc4MgB3TKFqExOZJUiYG45ENGpbtCuda+lNfSo69zu24ek1ew+omOewfkv/lgaaerZsa8z8/h6k8qq64yj8G0W9l8KgIeKCCkRNv8geceUT0dQv/dy6mWxH467QCIcdrHZB0+prr1BRQz8G7VJeQDrQAa35qek8uGyVhlzUtePuVI5vuzk7ibNTG6/f94/CcNIPYC0g2Ed3q4bCLbRVUFISw1XsTPXp5nMPGc3O43rqZ3Lqtltqbj7W8AoXyV2VatqZszQkgB85a/pE20cyzputbQcY+eDwp4SN+p6NwPVcnh6sY8LFP3H9YbzLybs= Content-Type: multipart/mixed; boundary="_002_BL0PR06MB504264D081B40ACBE22CF6C69A580BL0PR06MB5042namp_" MIME-Version: 1.0 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5af4bcc4-6a92-49f2-8f2e-08d6b2cd898b X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2019 16:01:56.3327 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4914 Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 27 Mar 2019 16:02:31 -0000 --_002_BL0PR06MB504264D081B40ACBE22CF6C69A580BL0PR06MB5042namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnkgZm9yIHRoaXMgZHVwbGljYXRlIGVtYWlsLCBJIGZvcmdvdCB0aGUgYXR0YWNobWVudC4N Cg0KUmVnYXJkcywNCk1pY2hlbA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog TWljaGVsIFZlaWxsZXR0ZSANClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMjcsIDIwMTkgMTI6MDEg UE0NClRvOiAnSnVlcmdlbiBTY2hvZW53YWVsZGVyJyA8ai5zY2hvZW53YWVsZGVyQGphY29icy11 bml2ZXJzaXR5LmRlPg0KQ2M6IExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej47IENhcnN0 ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPjsgbmV0Y29uZkBpZXRmLm9yZzsgY29yZUBpZXRmLm9y Zw0KU3ViamVjdDogUkU6IFtuZXRjb25mXSBZQU5HIGVuY29kaW5nIGluIENCT1INCg0KSGkgSnVl cmdlbg0KDQpZb3Ugd2lsbCBmaW5kIGluIGF0dGFjaG1lbnQgdGhlIHVwZGF0ZWQgdmVyc2lvbiBv ZiAndGVzdC11bmlvbkAyMDE5LTAzLTI1LnlhbmcnIGJhc2VkIG9uIHlvdXIgcHJvcG9zZWQgc29s dXRpb24sIHR5cGUgdGFnZ2luZy4NClRoaXMgbW9kdWxlIGRlZmluZXMgYW4gZXh0ZW5zaW9uIGNh bGxlZCB1bmlvbi10YWcgYXMgZm9sbG93Og0KDQogIGV4dGVuc2lvbiB1bmlvbi10YWcgew0KICAg IGFyZ3VtZW50IHRhZyB7DQogICAgICB5aW4tZWxlbWVudCB0cnVlOw0KICAgIH0NCiAgICBkZXNj cmlwdGlvbg0KICAgICAgIkluIHNvbWUgY2FzZXMsIHRoZSBpbnRlcnByZXRhdGlvbiBvZiBhIHZh bHVlIG9mIGEgdW5pb24gdHlwZSBjYW4gZGlmZmVyDQogICAgICB3aGVuIGVuY29kZWQgdXNpbmcg dGhlIGRpZmZlcmVudCBkYXRhIGZvcm1hdC4gVGhpcyBkaWZmZXJlbmNlIGNvbWVzIGZyb20NCiAg ICAgIHRoZSBsZXZlbCBvZiB0eXBlIGluZm9ybWF0aW9uIHN1cHBvcnRlZCBieSB0aGUgZGlmZmVy ZW50IGRhdGEgZm9ybWF0cy4NCiAgICAgIEluIHRoZSBjYXNlIG9mIFhNTCwgYWxsIGVsZW1lbnRz IGFuZCBhdHRyaWJ1dGVzIGFyZSBlbmNvZGVkIGFzIHN0cmluZw0KICAgICAgYW5kIG5vIHR5cGUg aW5mb3JtYXRpb24gYXJlIGluY2x1ZGVkLiBKU09OIHN1cHBvcnRzIHN0cmluZywgbnVtYmVyIGFu ZA0KICAgICAgYm9vbGVhbi4gRmluYWxseSwgQ0JPUiBzdXBwb3J0cyBhbGwgWUFORyBiYXNpYyB0 eXBlcy4NCg0KICAgICAgVGhpcyBleHRlbnNpb24gY2FuIGJlIHVzZWQgdG8gYWRkIGEgdGFnIHRv IGEgdHlwZSB3aXRoaW4gYSB1bmlvbiB0bw0KICAgICAgZ3VhcmFudGVlIGl0cyBwcm9wZXIgaW50 ZXJwcmV0YXRpb24gd2hlbiBkZWNvZGVkLiI7DQogIH0NCg0KVGhpcyBleHRlbnNpb24gY2FuIGJl IHVzZWQgYXMgZm9sbG93Og0KDQogIGxlYWYgbXVsdGlwbGUtZW51bWVyYXRpb25zLXRlc3QtMiB7 DQogICAgdHlwZSB1bmlvbiB7DQogICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCiAgICAgICAgZXh0 OnVuaW9uLXRhZyB3ZWVrZGF5czsNCiAgICAgICAgZW51bSAiTW9uZGF5IjsNCiAgICAgICAgZW51 bSAiVHVlc2RheSI7DQogICAgICAgIGVudW0gIldlZG5lc2RheSI7DQogICAgICAgIGVudW0gIlRo dXJzZGF5IjsNCiAgICAgICAgZW51bSAiRnJpZGF5IjsNCiAgICAgIH0NCiAgICAgIHR5cGUgZW51 bWVyYXRpb24gew0KICAgICAgICBleHQ6dW5pb24tdGFnIHdlZWtlbmQ7DQogICAgICAgIGVudW0g IlNhdHVyZGF5IjsNCiAgICAgICAgZW51bSAiU3VuZGF5IjsNCiAgICAgIH0NCiAgICB9DQogIH0N Cg0KSWYgSSBhc3N1bWUgdGhpcyBzb2x1dGlvbiBvciBzaW1pbGFyIHNvbHV0aW9uIGlzIGltcGxl bWVudGVkLCB0aGUgbmV4dCBxdWVzdGlvbiBpcyBob3cgdGhpcyB0YWcgaXMgZW5jb2RlZCBpbiBD Qk9SLg0KTGV0IGFzc3VtZSB0aGF0IHRoZSBkYXRhIG5vZGUgU0lEIGlzIDE4MjAgYW5kIHRoZSBT SUQgYXNzaWduZWQgdG8gIndlZWtkYXlzIiB0YWcgaXMgIDE4MjEuDQoNCldoZW4gc2V0IHRvICJU dWVzZGF5IiwgdGhpcyBkYXRhIG5vZGUgY2FuIGJlIGVuY29kZWQgdXNpbmcgYSBDQk9SIG1hcCBh cyBmb2xsb3dzOg0KDQp7DQogICAxODIwIDogeyAid2Vla2RheXMiLCAxfQ0KfQ0KDQpEbyB3ZSBu ZWVkIHRvIGFkZCBhIENCT1IgdGFnIHRvIHRoaXMgZW5jb2RpbmcgdG8gc3BlY2lmeSB0aGUgdXNl IG9mIGEgdW5pb24gdGFnPyAoOTkgaW4gdGhpcyBleGFtcGxlKSBJIHBlcnNvbmFsbHkgZG9uJ3Qg dGhpbmsgc28gc2luY2UgdGhlIHVzZSBvZiBhIENCT1IgbWFwIGZvciBhIHVuaW9uIGRhdGEgbm9k ZSBpcyBub3QgY3VycmVudGx5IHBvc3NpYmxlLg0KDQp7DQogICAxODIwIDogKDk5KSB7ICJ3ZWVr ZGF5cyIsIDF9DQp9DQoNClNob3VsZCB3ZSB1c2UgYSBTSUQgaW5zdGVhZCBvZiB0aGUgdGFnPyAN Cg0Kew0KICAgMTgyMCA6IHsgMTgyMSwgMX0NCn0NCg0KU2hvdWxkIHdlIHVzZSBhIGRlbHRhIGJl dHdlZW4gdGhlIGRhdGEgbm9kZSBTSUQgYW5kIHRoZSB1bmlvbiB0YWcgU0lEPw0KVGhlIGRyYXdi YWNrIG9mIHRoaXMgYXBwcm9hY2ggaXMgdGhhdCB0aGUgc2FtZSB2YWx1ZSBhc3NpZ25lZCB0byBk aWZmZXJlbnQgZGF0YSBub2RlcyBpcyBlbmNvZGVkIGRpZmZlcmVudGx5Lg0KSSB3b24ndCBwZXJz b25hbGx5IHJlY29tbWVuZCB0aGlzIGFwcHJvYWNoLg0KDQp7DQogICAxODIwIDogeyAxLCAxfQ0K fQ0KDQpJIGhvcGUgdGhpcyBlbWFpbCB3aWxsIGhlbHAgbW92aW5nIHRoZSBkaXNjdXNzaW9uIGNs b3NlciB0byB0aGUgZmluYWwgc29sdXRpb24uDQoNClBsZWFzZSBjb21tZW50cw0KTWljaGVsDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIg PGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4NClNlbnQ6IFdlZG5lc2RheSwg TWFyY2ggMjcsIDIwMTkgMjoxNyBBTQ0KVG86IE1pY2hlbCBWZWlsbGV0dGUgPE1pY2hlbC5WZWls bGV0dGVAdHJpbGxpYW50LmNvbT4NCkNjOiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+ OyBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz47IG5ldGNvbmZAaWV0Zi5vcmc7IGNvcmVA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gWUFORyBlbmNvZGluZyBpbiBDQk9SDQoN CkhpLA0KDQphIHVuaW9uIGNhbiBiZSBmb3JtZWQgYnkgdXNpbmcgbWVtYmVyIHR5cGVzIHRoYXQg YXJlIGltcG9ydGVkIGFuZCBub3QgdW5kZXIgY2hhbmdlIGNvbnRyb2wgb2YgYSBzaW5nbGUgYXV0 aG9yL29yZ2FuaXphdGlvbiBhbmQgaWRlYWxseSB0aGlzIHNob3VsZCB3b3JrIHdpdGhvdXQgY29t cGxleCBjb29yZGluYXRpb24gb2YgbmFtZSBhbmQgbnVtYmVyIHNwYWNlcy4NCkR1cGxpY2F0ZSBl bnVtL2JpdHMgdmFsdWVzIGFyZSBsZWdhbCBpbiBZQU5HIHRvZGF5IHNvIGFuIGVuY29kaW5nIGhh cyB0byBkZWFsIHdpdGggdGhpcyBhc3BlY3Qgb2YgbGlmZS4NCg0KQSByb2J1c3QgZml4IHRvIGFs bCB0aGVzZSBwcm9ibGVtcyB3aWxsIGJlIHRvIHRhZyB0aGUgdHlwZSBtZW1iZXJzIGluIG9yZGVy IHRvIGRpc2NyaW1pbmF0ZSB0aGUgdmFsdWVzIGluIHRoZSBlbmNvZGluZ3MuIFRoaXMsIGhvd2V2 ZXIsIHdpbGwgdGFrZSBzb21lIHRpbWUgdG8gc3BlY2lmeSBhbmQgd2Ugd2lsbCBuZWVkIHRvIHBy ZXNlcnZlIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IHdpdGggdW5pb25zIHdpdGhvdXQgYSB0YWcg KGJ1dCBjb21waWxlcnMgY2FuIGVuY291cmFnZSBwZW9wbGUgdG8gYWRkIHRhZ3Mgd2hlbmV2ZXIg bW9kdWxlcyBhcmUgdXBkYXRlZCkuDQoNCi9qcw0KDQpPbiBXZWQsIE1hciAyNywgMjAxOSBhdCAw MToxMjo1MkFNICswMDAwLCBNaWNoZWwgVmVpbGxldHRlIHdyb3RlOg0KPiBIaSBMYWRpc2xhdg0K PiANCj4gSWYgSSBzdW1tYXJpemUgdGhpcyBpc3N1ZSBvZiBtdWx0aXBsZSBlbnVtZXJhdGlvbnMg b3IgYml0cyBpbiBhIHVuaW9uLCB0aGlzIHByb2JsZW0gY2FuIGJlIHNvbHZlIGJ5IHRoZSBmb2xs b3dpbmcgYXBwcm9hY2hlczoNCj4gDQo+IC0gVG8gbm90IGFsbG93cyB0aGVzZSBkdXBsaWNhdGUg dmFsdWVzIG9yIHBvc2l0aW9ucyB0byBoYXBwZW4gaW4gWUFORw0KPiAtIFRvIGVuY29kZSBlbnVt ZXJhdGlvbnMgYW5kIGJpdHMgYXMgc3RyaW5nIChpbiBhbGwgdW5pb25zIG9yIG9ubHkgDQo+IHdo ZW4gbXVsdGlwbGUgZW51bWVyYXRpb25zIG9yIGJpdHMgYXJlIGRlZmluZWQpDQo+IC0gVG8gZW5j b2RlIGVudW1lcmF0aW9ucyBhbmQgYml0cyBhcyBTSUQgKGluIGFsbCB1bmlvbnMgb3Igb25seSB3 aGVuIA0KPiBtdWx0aXBsZSBlbnVtZXJhdGlvbnMgb3IgYml0cyBhcmUgZGVmaW5lZCkNCj4gLSBU byBlbmNvZGUgZW51bWVyYXRpb25zIGFuZCBiaXRzIGFzIGRlbHRhIGJldHdlZW4gdGhlIHZhbHVl IFNJRCBhbmQgDQo+IHRoZSBsZWFmIFNJRCAoaW4gYWxsIHVuaW9ucyBvciBvbmx5IHdoZW4gbXVs dGlwbGUgZW51bWVyYXRpb25zIG9yIGJpdHMgDQo+IGFyZSBkZWZpbmVkKQ0KPiANCj4gSW4gdGhp cyBlbWFpbCwgSSB3aWxsIGxpa2UgdG8gZm9jdXMgb24gdGhlIGZpcnN0IG9wdGlvbiwgZml4aW5n IHRoZSBwcm9ibGVtIGRpcmVjdGx5IGluIFlBTkcgaW5zdGVhZCBvZiBmaXhpbmcgdGhlIGNvbnNl cXVlbmNlcy4NCj4gDQo+IFdpdGhvdXQgYW55IGNoYW5nZXMgaW4gWUFORywgYSB1bmlvbiB3aXRo IG11bHRpcGxlIGVudW1lcmF0aW9uIG9yIGJpdHMgY2FuIGJlIGNvbnN0cnVjdGVkIHdpdGhvdXQg dmFsdWUgb3IgcG9zaXRpb24gb3ZlcmxhcHMuDQo+IEZvciBleGFtcGxlOg0KPiANCj4gICBsZWFm IG11bHRpcGxlLWVudW1lcmF0aW9ucy10ZXN0LTEgew0KPiAgICAgdHlwZSB1bmlvbiB7DQo+ICAg ICAgIHR5cGUgZW51bWVyYXRpb24gew0KPiAgICAgICAgIGVudW0gIk1vbmRheSIgeyB2YWx1ZSAw OyB9DQo+ICAgICAgICAgZW51bSAiVHVlc2RheSIgeyB2YWx1ZSAxOyB9DQo+ICAgICAgICAgZW51 bSAiV2VkbmVzZGF5IiB7IHZhbHVlIDI7IH0NCj4gICAgICAgICBlbnVtICJUaHVyc2RheSIgeyB2 YWx1ZSAzOyB9DQo+ICAgICAgICAgZW51bSAiRnJpZGF5IiB7IHZhbHVlIDQ7IH0NCj4gDQo+ICAg ICAgIH0NCj4gICAgICAgdHlwZSBlbnVtZXJhdGlvbiB7DQo+ICAgICAgICAgZW51bSAiU2F0dXJk YXkiIHsgdmFsdWUgNTsgfQ0KPiAgICAgICAgIGVudW0gIlN1bmRheSIgeyB2YWx1ZSA2OyB9DQo+ ICAgICAgIH0NCj4gICAgIH0NCj4gICB9DQo+IA0KPiAgIGxlYWYgbXVsdGlwbGUtYml0cy10ZXN0 LTEgew0KPiAgICAgdHlwZSB1bmlvbiB7DQo+ICAgICAgIHR5cGUgYml0cyB7DQo+ICAgICAgICAg Yml0ICAiTW9uZGF5IiB7IHBvc2l0aW9uICAwOyB9DQo+ICAgICAgICAgYml0ICJUdWVzZGF5IiB7 IHBvc2l0aW9uICAxOyB9DQo+ICAgICAgICAgYml0ICJXZWRuZXNkYXkiIHsgcG9zaXRpb24gIDI7 IH0NCj4gICAgICAgICBiaXQgIlRodXJzZGF5IiB7IHBvc2l0aW9uICAzOyB9DQo+ICAgICAgICAg Yml0ICJGcmlkYXkiIHsgcG9zaXRpb24gIDQ7IH0NCj4gDQo+ICAgICAgIH0NCj4gICAgICAgdHlw ZSBiaXRzIHsNCj4gICAgICAgICBiaXQgIlNhdHVyZGF5IiB7IHBvc2l0aW9uIDU7IH0NCj4gICAg ICAgICBiaXQgIlN1bmRheSIgeyBwb3NpdGlvbiA2OyB9DQo+ICAgICAgIH0NCj4gICAgIH0NCj4g ICB9DQo+IA0KPiBXaGVuIHVzaW5nIGFscmVhZHkgZGVmaW5lZCB0eXBlZGVmLCBhdm9pZGluZyBv dmVybGFwIGlzIGxlc3Mgb2J2aW91cyB3aXRob3V0IHNvbWUgaGVscC4NCj4gVG8gaGVscCBidWls ZGluZyB1bmlvbnMgd2l0aCBhbHJlYWR5IGRlZmluZWQgdHlwZWRlZnMsIEkgcHJvcG9zZSB0byBp bnRyb2R1Y2UgdHdvIGV4dGVuc2lvbnMuIA0KPiANCj4gICBleHRlbnNpb24gdmFsdWUtb2Zmc2V0 IHsNCj4gICAgIGFyZ3VtZW50IG9mZnNldCB7DQo+ICAgICAgIHlpbi1lbGVtZW50IHRydWU7DQo+ ICAgICB9DQo+ICAgICBkZXNjcmlwdGlvbg0KPiAgICAgICAiT2Zmc2V0IGFkZGVkIHRvIGVhY2gg ZW51bSB2YWx1ZSBvZiB0aGUgYXNzb2NpYXRlZCBlbnVtZXJhdGlvbi4iOw0KPiAgIH0NCj4gICAN Cj4gICBleHRlbnNpb24gcG9zaXRpb24tb2Zmc2V0IHsNCj4gICAgIGFyZ3VtZW50IG9mZnNldCB7 DQo+ICAgICAgIHlpbi1lbGVtZW50IHRydWU7DQo+ICAgICB9DQo+ICAgICBkZXNjcmlwdGlvbg0K PiAgICAgICAiT2Zmc2V0IHZhbHVlIGFkZGVkIHRvIGVhY2ggYml0IHBvc2l0aW9uIG9mIHRoZSBh c3NvY2lhdGVkIGJpdHMuIjsNCj4gICB9DQo+IA0KPiBUaGUgdmFsdWUtb2Zmc2V0IGV4dGVuc2lv biBjYW4gYmUgdXNlZCBhcyBmb2xsb3c6DQo+IA0KPiAgICAgdHlwZSBlbnVtZXJhdGlvbiB7DQo+ ICAgICAgIGVudW0gIk1vbmRheSI7DQo+ICAgICAgIGVudW0gIlR1ZXNkYXkiOw0KPiAgICAgICBl bnVtICJXZWRuZXNkYXkiOw0KPiAgICAgICBlbnVtICJUaHVyc2RheSI7DQo+ICAgICAgIGVudW0g IkZyaWRheSI7DQo+ICAgICB9DQo+ICAgfQ0KPiANCj4gICB0eXBlZGVmIHdlZWtlbmQgew0KPiAg ICAgdHlwZSBlbnVtZXJhdGlvbiB7DQo+ICAgICAgIGVudW0gIlNhdHVyZGF5IjsNCj4gICAgICAg ZW51bSAiU3VuZGF5IjsNCj4gICAgIH0NCj4gICB9DQo+ICAgDQo+ICAgbGVhZiBtdWx0aXBsZS1l bnVtZXJhdGlvbnMtdGVzdC0zIHsNCj4gICAgIHR5cGUgdW5pb24gew0KPiAgICAgICB0eXBlIHdl ZWtkYXlzOw0KPiAgICAgICB0eXBlIHdlZWtlbmQgew0KPiAgICAgICAgIGV4dDp2YWx1ZS1vZmZz ZXQgNTsNCj4gICAgICAgfQ0KPiAgICAgfQ0KPiAgIH0NCj4gDQo+IFRoZSBwb3NpdGlvbi1vZmZz ZXQgZXh0ZW5zaW9uIGNhbiBiZSB1c2VkIGFzIGZvbGxvdzoNCj4gDQo+ICAgdHlwZWRlZiB3ZWVr ZGF5cy1mbGFncyB7DQo+ICAgICB0eXBlIGJpdHMgew0KPiAgICAgICBiaXQgIk1vbmRheSI7DQo+ ICAgICAgIGJpdCAiVHVlc2RheSI7DQo+ICAgICAgIGJpdCAiV2VkbmVzZGF5IjsNCj4gICAgICAg Yml0ICJUaHVyc2RheSI7DQo+ICAgICAgIGJpdCAiRnJpZGF5IjsNCj4gICAgIH0NCj4gICB9DQo+ IA0KPiAgIHR5cGVkZWYgd2Vla2VuZC1mbGFncyB7DQo+ICAgICB0eXBlIGJpdHMgew0KPiAgICAg ICBiaXQgIlNhdHVyZGF5IjsNCj4gICAgICAgYml0ICJTdW5kYXkiOw0KPiAgICAgfQ0KPiAgIH0N Cj4gICANCj4gICBsZWFmIG11bHRpcGxlLWJpdHMtdGVzdC0zIHsNCj4gICAgIHR5cGUgdW5pb24g ew0KPiAgICAgICB0eXBlIHdlZWtkYXlzLWZsYWdzOw0KPiAgICAgICB0eXBlIHdlZWtlbmQtZmxh Z3Mgew0KPiAgICAgICAgIGV4dDpwb3NpdGlvbi1vZmZzZXQgNTsNCj4gICAgICAgfQ0KPiAgICAg fQ0KPiAgIH0NCj4gDQo+IFRoZSB5YW5nIGZpbGUgaW4gYXR0YWNobWVudCBzaG93IGRpZmZlcmVu dCBleGFtcGxlcyBiYXNlZCBvbiB0aGlzIGFwcHJvYWNoLg0KPiBUaGlzIG1vZHVsZSBoYXZlIGJl ZW4gdmFsaWRhdGVkIHVzaW5nIA0KPiBodHRwczovL2NhbjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRnd3dy55DQo+IGFuZ3ZhbGlkYXRvci5jb20l MkZ2YWxpZGF0b3ImYW1wO2RhdGE9MDIlN0MwMSU3QyU3Q2M2OTQyNmRjYWFmODQ0OGUxZDQNCj4g NzA4ZDZiMjdiYzczNSU3QzRmNmZiZDEzMGRmYjQxNTA4NWMzZDQzMjYwYzA0MzA5JTdDMCU3QzAl N0M2MzY4OTI2NDIwNw0KPiAzMjU3NjYwJmFtcDtzZGF0YT1YcW80MGx6QmpJTlZGWmhJWlpJMUxF a3RBZHE1bWVlMkFkeGVZcWVmbnNBJTNEJmFtcDtyDQo+IGVzZXJ2ZWQ9MCBJZiB0aGlzIGFwcHJv YWNoIGlzIGFjY2VwdGVkLCB0b29scyBsaWtlIHB5YW5nIHNob3VsZCBiZSANCj4gdXBkYXRlZCB0 byBwcm9kdWNlIGFuIGVycm9yIGlmIG11bHRpcGxlIGVudW1lcmF0aW9ucyBvciBiaXRzIGFyZSBk ZWZpbmVkIHdpdGggdmFsdWUgb3IgcG9zaXRpb24gb3ZlcmxlYXBzLg0KPiANCj4gUGxlYXNlIGNv bW1lbnQsDQo+IE1pY2hlbA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6Pg0KPiBTZW50OiBNb25kYXksIE1hcmNo IDI1LCAyMDE5IDQ6MDcgQU0NCj4gVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53 YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPjsNCj4gQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6 aS5vcmc+DQo+IENjOiBNaWNoZWwgVmVpbGxldHRlIDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFu dC5jb20+OyANCj4gbmV0Y29uZkBpZXRmLm9yZzsgY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBS ZTogW25ldGNvbmZdIFlBTkcgZW5jb2RpbmcgaW4gQ0JPUg0KPiANCj4gSnVlcmdlbiBTY2hvZW53 YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyaXRlczoNCj4g DQo+ID4gSSB0aGluayB3ZSBuZWVkIHRvIGxvb2sgYXQgdGhlIHdob2xlIHBpY3R1cmUgYW5kIGlu IHdoaWNoIGRpcmVjdGlvbiANCj4gPiB3ZSB3YW50IHRvIGdvLiBJbiB0aGUgbG9uZ2VyIHRlcm0s IEkgd291bGQgcHJlZmVyIGEgc29sdXRpb24gd2hlcmUgDQo+ID4gdGhlIHZhbHVlcyBvZiBhIHVu aW9uIGFyZSBkaXNjcmltaW5hdGVkLiBUaGUgY3VycmVudCBYTUwgZW5jb2RpbmcgDQo+ID4gYmVo YXZpb3VyIG9mICdmaXJzdCBtYXRjaCB3aW5zJyBpcyBmcmFnaWxlIChmb3IgZXhhbXBsZSwgaWYg c29tZW9uZSANCj4gPiBhZGRzIGFuIGVudW0gdG8gYSB0eXBlLCB0aGUgaW50ZXJwcmV0YXRpb24g b2YgZGF0YSBjYW4gY2hhbmdlKS4NCj4gPg0KPiA+IExvb2sgYXQgdGhpczoNCj4gPg0KPiA+IHR5 cGVkZWYgYmFyIHsNCj4gPiAgIHR5cGUgdW5pb24gew0KPiA+ICAgICB0eXBlIGVudW1lcmF0aW9u IHsgZW51bSAiMSI7IHZhbHVlIDI7IGVudW0gIjIiOyB2YWx1ZSAxOyB9DQo+ID4gICAgIHR5cGUg dWludDg7DQo+ID4gICB9DQo+ID4gfQ0KPiA+DQo+ID4gV2UgaGF2ZSBzb21lIGVuY29kaW5ncyB0 aGF0IHNlbmQgdGhlIHN0cmluZyByZXByZXNlbnRhdGlvbnMgb2YgdGhlIA0KPiA+IHZhbHVlcyBh bmQgc29tZSBlbmNvZGluZ3MgdGhhdCBwcmVmZXIgdG8gc2VuZCBudW1lcmljIA0KPiA+IHJlcHJl c2VudGF0aW9ucyB3aGVyZSBwb3NzaWJsZS4gSW4gb3JkZXIgdG8gaGF2ZSBhIHJvYnVzdCBzb2x1 dGlvbiwgDQo+ID4gZW5jb2RpbmdzIHNob3VsZCBsaWtlbHkgaW5kaWNhdGUgdG8gd2hpY2ggdHlw ZSB0aGUgdmFsdWUgYmVsb25ncy4NCj4gDQo+IFBlcmhhcHMgdGhlIGVhc2llc3Qgd2F5IHdvdWxk IGJlIHRvIHVzZSAob3B0aW9uYWwpIGFubm90YXRpb24gdGhhdCBzcGVjaWZpZXMsIHVzaW5nIGFu IG9yZGluYWwgbnVtYmVyLCB3aGljaCBvZiB0aGUgbWVtYmVyIHR5cGVzIGlzIHVzZWQgZm9yIHRo ZSBwYXJ0aWN1bGFyIGluc3RhbmNlLiBCdXQgc2luY2UgdGhlcmUgY2FuIGJlIHVuaW9ucyBpbnNp ZGUgdW5pb25zLCBhIGxpc3Qgb2YgbnVtYmVycyB3b3VsZCBiZSBuZWVkZWQgaW4gZ2VuZXJhbC4N Cj4gDQo+IExhZGENCj4gDQo+ID4NCj4gPiAvanMNCj4gPg0KPiA+IE9uIFNhdCwgTWFyIDIzLCAy MDE5IGF0IDEwOjAzOjMyQU0gKzAxMDAsIENhcnN0ZW4gQm9ybWFubiB3cm90ZToNCj4gPj4gV2Vs bCwgaWYgdGhhdCBpcyBhIHByb2JsZW0sIHdlIGNhbiBnbyBmb3IgYSBsb25nZXIgcmVwcmVzZW50 YXRpb24gd2l0aGluIHVuaW9ucyAoc2VjdGlvbiA2LjEyKS4gIFRoZW9yZXRpY2FsbHksIHdlIGNv dWxkIGRvIHRoYXQgb25seSBvZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25lIGVudW0gaW4gdGhlIHVu aW9uIHR5cGUgKHNvIHRoaW5ncyBzdGF5IGVmZmljaWVudCBpZiB0aGVyZSBpcyBvbmx5IG9uZSks IGJ1dCB0aGF0IG1pZ2h0IHBvc2UgZGlmZmljdWx0aWVzIHdpdGggbW9kZWwgZXZvbHV0aW9uLg0K PiA+PiANCj4gPj4gR29pbmcgZm9yIGEgc3RyaW5nIHJlcHJlc2VudGF0aW9uIHJlcGVhdHMgdGhl IGZlYXR1cmUgb2YgWE1MIFlBTkcgKHdoaWNoIHdhcyBwb3J0ZWQgb3ZlciB0byBKU09OIFlBTkcp Og0KPiA+PiANCj4gPj4gdHlwZWRlZiBmb28gew0KPiA+PiAgIHR5cGUgdW5pb24gew0KPiA+PiAg ICAgdHlwZSBlbnVtZXJhdGlvbiB7DQo+ID4+ICAgICAgIGVudW0gcmVkIHsgdmFsdWUgMTsgfQ0K PiA+PiAgICAgICBlbnVtIGJyZWVuIHsgdmFsdWUgMjsgfQ0KPiA+PiAgICAgICBlbnVtIGdsdWUg eyB2YWx1ZSAzOyB9DQo+ID4+ICAgICB9DQo+ID4+ICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCj4g Pj4gICAgICAgZW51bSB0YWNrcyB7IHZhbHVlIDE7IH0NCj4gPj4gICAgICAgZW51bSBuYWlscyB7 IHZhbHVlIDI7IH0NCj4gPj4gICAgICAgZW51bSBnbHVlIHsgdmFsdWUgMzsgfQ0KPiA+PiAgICAg fQ0KPiA+PiAgIH0NCj4gPj4gfQ0KPiA+PiANCj4gPj4gSWYgeW91IHVzZSDigJxnbHVl4oCdLCB5 b3UgZG9u4oCZdCBrbm93IHdoaWNoIG9mIHRoZSBlbnVtZXJhdGlvbnMgYXJlIGJlaW5nIHVzZWQu DQo+ID4+IA0KPiA+PiBVc2luZyBTSURzLCB3ZSBjYW4gZG8gYmV0dGVyLg0KPiA+PiANCj4gPj4g U28gd2hhdCBkbyB3ZSBoYXZlIHRvIGRvIHRvIGdldCB0aGUgU0lEIHRvb2wgdG8gYWxsb2NhdGUg U0lEcyBmb3IgZW51bSB2YWx1ZXM/DQo+ID4+IA0KPiA+PiBXZSBjb3VsZCB0aGVuIGRlZmluZSB0 aGUgQ0JPUiB0YWcgZm9yIGVudW1zIGluIHVuaW9ucyB0byB0YWtlIHRoZSB1c3VhbCBTSUQgZGlm ZmVyZW5jZSAoZGVsdGEgcmVsYXRpdmUgdG8gdGhlIGVudmlyb25tZW50LCBJ4oCZZCB0aGluayks IG5vdCBhbiBpbnRlZ2VyIHZhbHVlLg0KPiA+PiANCj4gPj4gU2V2ZXJhbCBvZiB1cyBhcmUgYXQg dGhlIGhhY2thdGhvbiBhbmQgY291bGQgbWFrZSBzb21ldGhpbmcgaGFwcGVuIHRvZGF5IGFuZCB0 b21vcnJvdy4NCj4gPj4gDQo+ID4+IEdyw7zDn2UsIENhcnN0ZW4NCj4gPj4gDQo+ID4+IA0KPiA+ PiA+IE9uIE1hciAyMiwgMjAxOSwgYXQgMTg6MzAsIFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2ls dG9uQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4+ID4gDQo+ID4+ID4gSSBndWVzcyB0aGF0IHRoZSBj b25jZXJuIGlzIHRoYXQgdGhpcyBpbnRyb2R1Y2VzIG1vcmUgdmFyaWF0aW9uIGluIGhvdyBkYXRh IGlzIGludGVycHJldGVkIGJldHdlZW4gdGhlIGRpZmZlcmVudCBYTUwvSlNPTi9DQk9SIGVuY29k aW5ncy4NCj4gPj4gPiANCj4gPj4gPiBFLmcuIGlmIHNvbWVvbmUgc3dpdGNoZWQgZnJvbSBYTUwg dG8gQ0JPUiwgc3VkZGVubHkgdGhlIGNvbmZpZ3VyYXRpb24gb3Igc3RhdGUgZGF0YSBtYXkgaGF2 ZSBhIGRpZmZlcmVudCBtZWFuaW5nLg0KPiA+PiA+IA0KPiA+PiA+IFRoYW5rcywNCj4gPj4gPiBS b2INCj4gPj4gPiANCj4gPj4gPiANCj4gPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPj4gPj4gRnJvbTogQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+DQo+ID4+ID4+IFNl bnQ6IDIyIE1hcmNoIDIwMTkgMTY6MDgNCj4gPj4gPj4gVG86IE1pY2hlbCBWZWlsbGV0dGUgPE1p Y2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50LmNvbT4NCj4gPj4gPj4gQ2M6IFJvYiBXaWx0b24gKHJ3 aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT47IGNvcmVAaWV0Zi5vcmc7IA0KPiA+PiA+PiBuZXRj b25mQGlldGYub3JnDQo+ID4+ID4+IFN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gWUFORyBlbmNvZGlu ZyBpbiBDQk9SDQo+ID4+ID4+IA0KPiA+PiA+PiBPbiBNYXIgMjIsIDIwMTksIGF0IDE2OjQ1LCBN aWNoZWwgVmVpbGxldHRlIA0KPiA+PiA+PiA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQuY29t Pg0KPiA+PiA+PiB3cm90ZToNCj4gPj4gPj4+IA0KPiA+PiA+Pj4gVGhlIG9ubHkgcG90ZW50aWFs IHByb2JsZW0gSSBhd2FyZSBpcyB3aGVuIG11bHRpcGxlIA0KPiA+PiA+Pj4gZW51bWVyYXRpb25z IGFyZSBwYXJ0IG9mDQo+ID4+ID4+IHRoZSBzYW1lIHVuaW9uLg0KPiA+PiA+Pj4gVmFsdWUgNCBm cm9tIGVudW1lcmF0aW9uIEEgd2lsbCBiZSBlbmNvZGVkIHRoZSBzYW1lIHdheSBhcyANCj4gPj4g Pj4+IFZhbHVlDQo+ID4+ID4+PiA0IGZyb20NCj4gPj4gPj4gZW51bWVyYXRpb24gQi4NCj4gPj4g Pj4gDQo+ID4+ID4+IOKApiBhbmQgdGhhdCBpcyBub3QgYSBwcm9ibGVtIGZvciB0aGUgWE1MIHZl cnNpb24sIGJlY2F1c2UgdGhlIA0KPiA+PiA+PiBzdHJpbmcgaXMgYmVpbmcgdXNlZCBpbnN0ZWFk IG9mIHRoZSB2YWx1ZS4gIChCdXQgdGhlbiBpZiB0d28gDQo+ID4+ID4+IGVudW1lcmF0aW9ucyBz aGFyZSBhIHN0cmluZywgeW91IGhhdmUgdGhlIGVxdWl2YWxlbnQgcHJvYmxlbSBpbiANCj4gPj4g Pj4gdGhlIFhNTCBzZXJpYWxpemF0aW9uLikNCj4gPj4gPj4gDQo+ID4+ID4+IEFueXdheSwgSSBo YXZlbuKAmXQgc2VlbiBhIHBpZWNlIG9mIHJlYWwtd29ybGQgWUFORyB0aGF0IGFjdHVhbGx5IA0K PiA+PiA+PiBoYXMgdGhpcyBwcm9ibGVtLCBzbyBJIHdvdWxkIGJlIGEgYml0IHJlbHVjdGFudCB0 byBtYWtlIA0KPiA+PiA+PiBDQk9SLWJhc2VkIGltcGxlbWVudGF0aW9ucyBtb3JlIGNvbXBsZXgg KGFuZCBsZXNzIGVmZmljaWVudCkgc28gc29sdmUgdGhpcyAobm9uLT8pcHJvYmxlbS4NCj4gPj4g Pj4gDQo+ID4+ID4+IEdyw7zDn2UsIENhcnN0ZW4NCj4gPj4gPiANCj4gPj4gPiANCj4gPj4gPiAN Cj4gPj4gDQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4+IG5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4+IG5ldGNvbmZAaWV0Zi5vcmcNCj4g Pj4gaHR0cHM6Ly9jYW4wMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHBzJTNBJTJGJTJGdw0KPiA+PiB3dw0KPiA+PiAuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGlu Zm8lMkZuZXRjb25mJmFtcDtkYXRhPTAyJTdDMDElN0MlN0MzNDNlDQo+ID4+IGE4DQo+ID4+IGQx Y2Y4ZjRlMzlhZmM3MDhkNmIwZjhkODc0JTdDNGY2ZmJkMTMwZGZiNDE1MDg1YzNkNDMyNjBjMDQz MDklN0MwJTcNCj4gPj4gQzENCj4gPj4gJTdDNjM2ODkwOTgwMTgyNTUzNDAwJmFtcDtzZGF0YT11 MUtGQVlBdXMxNkI4YTdzZ3NCZlBmSXF1T3B0TWxhT2IlMg0KPiA+PiBCMA0KPiA+PiBrdlBaZ3I0 byUzRCZhbXA7cmVzZXJ2ZWQ9MA0KPiA+DQo+ID4gLS0gDQo+ID4gSnVlcmdlbiBTY2hvZW53YWVs ZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gPiBQaG9uZTog KzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBH ZXJtYW55DQo+ID4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly9jYW4w MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3 LmphY29icy11bml2ZXJzaXR5LmRlJTJGJmFtcDtkYXRhPTAyJTdDMDElN0MlN0NjNjk0MjZkY2Fh Zjg0NDhlMWQ0NzA4ZDZiMjdiYzczNSU3QzRmNmZiZDEzMGRmYjQxNTA4NWMzZDQzMjYwYzA0MzA5 JTdDMCU3QzAlN0M2MzY4OTI2NDIwNzMyNTc2NjAmYW1wO3NkYXRhPVJxU1l1TnBsUzRrT0xVMFIz ZXRSenJSJTJGVTJjY3dsamtFWmtqSEhEVTFIQSUzRCZhbXA7cmVzZXJ2ZWQ9MD4NCj4gPg0KPiA+ DQo+ID4gT24gU2F0LCBNYXIgMjMsIDIwMTkgYXQgMTA6MDM6MzJBTSArMDEwMCwgQ2Fyc3RlbiBC b3JtYW5uIHdyb3RlOg0KPiA+PiBXZWxsLCBpZiB0aGF0IGlzIGEgcHJvYmxlbSwgd2UgY2FuIGdv IGZvciBhIGxvbmdlciByZXByZXNlbnRhdGlvbiB3aXRoaW4gdW5pb25zIChzZWN0aW9uIDYuMTIp LiAgVGhlb3JldGljYWxseSwgd2UgY291bGQgZG8gdGhhdCBvbmx5IG9mIHRoZXJlIGlzIG1vcmUg dGhhbiBvbmUgZW51bSBpbiB0aGUgdW5pb24gdHlwZSAoc28gdGhpbmdzIHN0YXkgZWZmaWNpZW50 IGlmIHRoZXJlIGlzIG9ubHkgb25lKSwgYnV0IHRoYXQgbWlnaHQgcG9zZSBkaWZmaWN1bHRpZXMg d2l0aCBtb2RlbCBldm9sdXRpb24uDQo+ID4+IA0KPiA+PiBHb2luZyBmb3IgYSBzdHJpbmcgcmVw cmVzZW50YXRpb24gcmVwZWF0cyB0aGUgZmVhdHVyZSBvZiBYTUwgWUFORyAod2hpY2ggd2FzIHBv cnRlZCBvdmVyIHRvIEpTT04gWUFORyk6DQo+ID4+IA0KPiA+PiB0eXBlZGVmIGZvbyB7DQo+ID4+ ICAgdHlwZSB1bmlvbiB7DQo+ID4+ICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCj4gPj4gICAgICAg ZW51bSByZWQgeyB2YWx1ZSAxOyB9DQo+ID4+ICAgICAgIGVudW0gYnJlZW4geyB2YWx1ZSAyOyB9 DQo+ID4+ICAgICAgIGVudW0gZ2x1ZSB7IHZhbHVlIDM7IH0NCj4gPj4gICAgIH0NCj4gPj4gICAg IHR5cGUgZW51bWVyYXRpb24gew0KPiA+PiAgICAgICBlbnVtIHRhY2tzIHsgdmFsdWUgMTsgfQ0K PiA+PiAgICAgICBlbnVtIG5haWxzIHsgdmFsdWUgMjsgfQ0KPiA+PiAgICAgICBlbnVtIGdsdWUg eyB2YWx1ZSAzOyB9DQo+ID4+ICAgICB9DQo+ID4+ICAgfQ0KPiA+PiB9DQo+ID4+IA0KPiA+PiBJ ZiB5b3UgdXNlIOKAnGdsdWXigJ0sIHlvdSBkb27igJl0IGtub3cgd2hpY2ggb2YgdGhlIGVudW1l cmF0aW9ucyBhcmUgYmVpbmcgdXNlZC4NCj4gPj4gDQo+ID4+IFVzaW5nIFNJRHMsIHdlIGNhbiBk byBiZXR0ZXIuDQo+ID4+IA0KPiA+PiBTbyB3aGF0IGRvIHdlIGhhdmUgdG8gZG8gdG8gZ2V0IHRo ZSBTSUQgdG9vbCB0byBhbGxvY2F0ZSBTSURzIGZvciBlbnVtIHZhbHVlcz8NCj4gPj4gDQo+ID4+ IFdlIGNvdWxkIHRoZW4gZGVmaW5lIHRoZSBDQk9SIHRhZyBmb3IgZW51bXMgaW4gdW5pb25zIHRv IHRha2UgdGhlIHVzdWFsIFNJRCBkaWZmZXJlbmNlIChkZWx0YSByZWxhdGl2ZSB0byB0aGUgZW52 aXJvbm1lbnQsIEnigJlkIHRoaW5rKSwgbm90IGFuIGludGVnZXIgdmFsdWUuDQo+ID4+IA0KPiA+ PiBTZXZlcmFsIG9mIHVzIGFyZSBhdCB0aGUgaGFja2F0aG9uIGFuZCBjb3VsZCBtYWtlIHNvbWV0 aGluZyBoYXBwZW4gdG9kYXkgYW5kIHRvbW9ycm93Lg0KPiA+PiANCj4gPj4gR3LDvMOfZSwgQ2Fy c3Rlbg0KPiA+PiANCj4gPj4gDQo+ID4+ID4gT24gTWFyIDIyLCAyMDE5LCBhdCAxODozMCwgUm9i IFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPiB3cm90ZToNCj4gPj4gPiANCj4g Pj4gPiBJIGd1ZXNzIHRoYXQgdGhlIGNvbmNlcm4gaXMgdGhhdCB0aGlzIGludHJvZHVjZXMgbW9y ZSB2YXJpYXRpb24gaW4gaG93IGRhdGEgaXMgaW50ZXJwcmV0ZWQgYmV0d2VlbiB0aGUgZGlmZmVy ZW50IFhNTC9KU09OL0NCT1IgZW5jb2RpbmdzLg0KPiA+PiA+IA0KPiA+PiA+IEUuZy4gaWYgc29t ZW9uZSBzd2l0Y2hlZCBmcm9tIFhNTCB0byBDQk9SLCBzdWRkZW5seSB0aGUgY29uZmlndXJhdGlv biBvciBzdGF0ZSBkYXRhIG1heSBoYXZlIGEgZGlmZmVyZW50IG1lYW5pbmcuDQo+ID4+ID4gDQo+ ID4+ID4gVGhhbmtzLA0KPiA+PiA+IFJvYg0KPiA+PiA+IA0KPiA+PiA+IA0KPiA+PiA+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiA+PiBGcm9tOiBDYXJzdGVuIEJvcm1hbm4gPGNh Ym9AdHppLm9yZz4NCj4gPj4gPj4gU2VudDogMjIgTWFyY2ggMjAxOSAxNjowOA0KPiA+PiA+PiBU bzogTWljaGVsIFZlaWxsZXR0ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQuY29tPg0KPiA+ PiA+PiBDYzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPjsgY29yZUBp ZXRmLm9yZzsgDQo+ID4+ID4+IG5ldGNvbmZAaWV0Zi5vcmcNCj4gPj4gPj4gU3ViamVjdDogUmU6 IFtuZXRjb25mXSBZQU5HIGVuY29kaW5nIGluIENCT1INCj4gPj4gPj4gDQo+ID4+ID4+IE9uIE1h ciAyMiwgMjAxOSwgYXQgMTY6NDUsIE1pY2hlbCBWZWlsbGV0dGUgDQo+ID4+ID4+IDxNaWNoZWwu VmVpbGxldHRlQHRyaWxsaWFudC5jb20+DQo+ID4+ID4+IHdyb3RlOg0KPiA+PiA+Pj4gDQo+ID4+ ID4+PiBUaGUgb25seSBwb3RlbnRpYWwgcHJvYmxlbSBJIGF3YXJlIGlzIHdoZW4gbXVsdGlwbGUg DQo+ID4+ID4+PiBlbnVtZXJhdGlvbnMgYXJlIHBhcnQgb2YNCj4gPj4gPj4gdGhlIHNhbWUgdW5p b24uDQo+ID4+ID4+PiBWYWx1ZSA0IGZyb20gZW51bWVyYXRpb24gQSB3aWxsIGJlIGVuY29kZWQg dGhlIHNhbWUgd2F5IGFzIA0KPiA+PiA+Pj4gVmFsdWUNCj4gPj4gPj4+IDQgZnJvbQ0KPiA+PiA+ PiBlbnVtZXJhdGlvbiBCLg0KPiA+PiA+PiANCj4gPj4gPj4g4oCmIGFuZCB0aGF0IGlzIG5vdCBh IHByb2JsZW0gZm9yIHRoZSBYTUwgdmVyc2lvbiwgYmVjYXVzZSB0aGUgDQo+ID4+ID4+IHN0cmlu ZyBpcyBiZWluZyB1c2VkIGluc3RlYWQgb2YgdGhlIHZhbHVlLiAgKEJ1dCB0aGVuIGlmIHR3byAN Cj4gPj4gPj4gZW51bWVyYXRpb25zIHNoYXJlIGEgc3RyaW5nLCB5b3UgaGF2ZSB0aGUgZXF1aXZh bGVudCBwcm9ibGVtIGluIA0KPiA+PiA+PiB0aGUgWE1MIHNlcmlhbGl6YXRpb24uKQ0KPiA+PiA+ PiANCj4gPj4gPj4gQW55d2F5LCBJIGhhdmVu4oCZdCBzZWVuIGEgcGllY2Ugb2YgcmVhbC13b3Js ZCBZQU5HIHRoYXQgYWN0dWFsbHkgDQo+ID4+ID4+IGhhcyB0aGlzIHByb2JsZW0sIHNvIEkgd291 bGQgYmUgYSBiaXQgcmVsdWN0YW50IHRvIG1ha2UgDQo+ID4+ID4+IENCT1ItYmFzZWQgaW1wbGVt ZW50YXRpb25zIG1vcmUgY29tcGxleCAoYW5kIGxlc3MgZWZmaWNpZW50KSBzbyBzb2x2ZSB0aGlz IChub24tPylwcm9ibGVtLg0KPiA+PiA+PiANCj4gPj4gPj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPiA+ PiA+IA0KPiA+PiA+IA0KPiA+PiA+IA0KPiA+PiANCj4gPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gbmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4g Pj4gbmV0Y29uZkBpZXRmLm9yZw0KPiA+PiBodHRwczovL2NhbjAxLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3DQo+ID4+IHd3DQo+ID4+IC5pZXRm Lm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRm5ldGNvbmYmYW1wO2RhdGE9MDIlN0MwMSU3QyU3 QzM0M2UNCj4gPj4gYTgNCj4gPj4gZDFjZjhmNGUzOWFmYzcwOGQ2YjBmOGQ4NzQlN0M0ZjZmYmQx MzBkZmI0MTUwODVjM2Q0MzI2MGMwNDMwOSU3QzAlNw0KPiA+PiBDMQ0KPiA+PiAlN0M2MzY4OTA5 ODAxODI1NTM0MDAmYW1wO3NkYXRhPXUxS0ZBWUF1czE2QjhhN3Nnc0JmUGZJcXVPcHRNbGFPYiUy DQo+ID4+IEIwDQo+ID4+IGt2UFpncjRvJTNEJmFtcDtyZXNlcnZlZD0wDQo+ID4NCj4gPiAtLSAN Cj4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJy ZW1lbiBnR21iSA0KPiA+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJp bmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4gPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEw MyAgICAgICAgIDxodHRwczovL2NhbjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUlMkYmYW1wO2RhdGE9 MDIlN0MwMSU3QyU3Q2M2OTQyNmRjYWFmODQ0OGUxZDQ3MDhkNmIyN2JjNzM1JTdDNGY2ZmJkMTMw ZGZiNDE1MDg1YzNkNDMyNjBjMDQzMDklN0MwJTdDMCU3QzYzNjg5MjY0MjA3MzI1NzY2MCZhbXA7 c2RhdGE9UnFTWXVOcGxTNGtPTFUwUjNldFJ6clIlMkZVMmNjd2xqa0Vaa2pISERVMUhBJTNEJmFt cDtyZXNlcnZlZD0wPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiBuZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+IG5ldGNvbmZAaWV0 Zi5vcmcNCj4gPiBodHRwczovL2NhbjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuDQo+ID4gaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGlu Zm8lMkZuZXRjb25mJmFtcDtkYXRhPTAyJTdDMDElN0MlN0MzNDNlYTgNCj4gPiBkMQ0KPiA+IGNm OGY0ZTM5YWZjNzA4ZDZiMGY4ZDg3NCU3QzRmNmZiZDEzMGRmYjQxNTA4NWMzZDQzMjYwYzA0MzA5 JTdDMCU3QzElDQo+ID4gN0MNCj4gPiA2MzY4OTA5ODAxODI1NTM0MDAmYW1wO3NkYXRhPXUxS0ZB WUF1czE2QjhhN3Nnc0JmUGZJcXVPcHRNbGFPYiUyQjBrdg0KPiA+IFBaDQo+ID4gZ3I0byUzRCZh bXA7cmVzZXJ2ZWQ9MA0KPiANCj4gLS0NCj4gTGFkaXNsYXYgTGhvdGthDQo+IEhlYWQsIENaLk5J QyBMYWJzDQo+IFBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nw0KDQoNCg0KLS0gDQpKdWVy Z2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21i SA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkg QnJlbWVuIHwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6 Ly9jYW4wMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGd3d3LmphY29icy11bml2ZXJzaXR5LmRlJTJGJmFtcDtkYXRhPTAyJTdDMDElN0MlN0NjNjk0 MjZkY2FhZjg0NDhlMWQ0NzA4ZDZiMjdiYzczNSU3QzRmNmZiZDEzMGRmYjQxNTA4NWMzZDQzMjYw YzA0MzA5JTdDMCU3QzAlN0M2MzY4OTI2NDIwNzMyNjc2NjAmYW1wO3NkYXRhPXpjUXY0aFI4eWtK RmRodnNkMnFuVFBRM0VQZEVaaWpEYzRlVCUyQkRtc3F1MCUzRCZhbXA7cmVzZXJ2ZWQ9MD4NCg== --_002_BL0PR06MB504264D081B40ACBE22CF6C69A580BL0PR06MB5042namp_ Content-Type: application/octet-stream; name="test-union@2019-03-25.yang" Content-Description: test-union@2019-03-25.yang Content-Disposition: attachment; filename="test-union@2019-03-25.yang"; size=4193; creation-date="Wed, 27 Mar 2019 16:01:44 GMT"; modification-date="Wed, 27 Mar 2019 16:01:44 GMT" Content-Transfer-Encoding: base64 bW9kdWxlIHRlc3QtdW5pb24gew0KICBuYW1lc3BhY2UgInVybjppZXRmOnBhcmFtczp4bWw6bnM6 eWFuZzp0ZXN0LXVuaW9uIjsNCiAgcHJlZml4IGV4dDsNCiAgDQogIHJldmlzaW9uIDIwMTktMDMt MjUgew0KICAgICAgZGVzY3JpcHRpb24gIkRyYWZ0LiI7DQogIH0NCg0KICAvLyAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAvLyBQcm9wb3NlZCBl eHRlbnNpb25zDQogIA0KICBleHRlbnNpb24gdW5pb24tdGFnIHsNCiAgICBhcmd1bWVudCB0YWcg ew0KICAgICAgeWluLWVsZW1lbnQgdHJ1ZTsNCiAgICB9DQogICAgZGVzY3JpcHRpb24NCiAgICAg ICJJbiBzb21lIGNhc2VzLCB0aGUgaW50ZXJwcmV0YXRpb24gb2YgYSB2YWx1ZSBvZiBhIHVuaW9u IHR5cGUgY2FuIGRpZmZlcg0KICAgICAgd2hlbiBlbmNvZGVkIHVzaW5nIHRoZSBkaWZmZXJlbnQg ZGF0YSBmb3JtYXQuIFRoaXMgZGlmZmVyZW5jZSBjb21lcyBmcm9tDQogICAgICB0aGUgbGV2ZWwg b2YgdHlwZSBpbmZvcm1hdGlvbiBzdXBwb3J0ZWQgYnkgdGhlIGRpZmZlcmVudCBkYXRhIGZvcm1h dHMuDQogICAgICBJbiB0aGUgY2FzZSBvZiBYTUwsIGFsbCBlbGVtZW50cyBhbmQgYXR0cmlidXRl cyBhcmUgZW5jb2RlZCBhcyBzdHJpbmcNCiAgICAgIGFuZCBubyB0eXBlIGluZm9ybWF0aW9uIGFy ZSBpbmNsdWRlZC4gSlNPTiBzdXBwb3J0cyBzdHJpbmcsIG51bWJlciBhbmQNCiAgICAgIGJvb2xl YW4uIEZpbmFsbHksIENCT1Igc3VwcG9ydHMgYWxsIFlBTkcgYmFzaWMgdHlwZXMuDQoNCiAgICAg IFRoaXMgZXh0ZW5zaW9uIGNhbiBiZSB1c2VkIHRvIGFkZCBhIHRhZyB0byBhIHR5cGUgd2l0aGlu IGEgdW5pb24gdG8NCiAgICAgIGd1YXJhbnRlZSBpdHMgcHJvcGVyIGludGVycHJldGF0aW9uIHdo ZW4gZGVjb2RlZC4iOw0KICB9DQoNCiAgLy8gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgLy8gVGhpcyBleGFtcGxlIHNob3dzIGEgY2FzZSBmb3Ig d2hpY2ggYSB0YWcgaXMgbm90IHJlcXVpcmVkDQogIA0KICBsZWFmIG11bHRpcGxlLWVudW1lcmF0 aW9ucy10ZXN0LTEgew0KICAgIHR5cGUgdW5pb24gew0KICAgICAgdHlwZSBlbnVtZXJhdGlvbiB7 DQogICAgICAgIGVudW0gIk1vbmRheSIgeyB2YWx1ZSAwOyB9DQogICAgICAgIGVudW0gIlR1ZXNk YXkiIHsgdmFsdWUgMTsgfQ0KICAgICAgICBlbnVtICJXZWRuZXNkYXkiIHsgdmFsdWUgMjsgfQ0K ICAgICAgICBlbnVtICJUaHVyc2RheSIgeyB2YWx1ZSAzOyB9DQogICAgICAgIGVudW0gIkZyaWRh eSIgeyB2YWx1ZSA0OyB9DQoNCiAgICAgIH0NCiAgICAgIHR5cGUgZW51bWVyYXRpb24gew0KICAg ICAgICBlbnVtICJTYXR1cmRheSIgeyB2YWx1ZSA1OyB9DQogICAgICAgIGVudW0gIlN1bmRheSIg eyB2YWx1ZSA2OyB9DQogICAgICB9DQogICAgfQ0KICB9DQoNCiAgLy8gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgLy8gVGhlIGZvbGxvd2luZyB0 d28gZXhhbXBsZXMgcmVxdWlyZSB0aGUgdXNlIG9mIGF0IGxlYXN0IG9uZQ0KICAvLyB1bmlvbiB0 YWcgdG8gZ3VhcmFudGVlIHRoZSBwcm9wZXIgaW50ZXJwcmV0YXRpb24gb2YgdGhvc2UgdHdvDQog IC8vIGVudW1lcmF0aW9ucy4gVGhpcyBhYmlsaXR5IHRvIHRhZyBvbmx5IG9uZSBlbnVtZXJhdGlv biBjYW4gYmUNCiAgLy8gdXNlZCB0byBrZWVwIHRoZSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdo ZW4gdXBkYXRpbmcgYSBtb2R1bGUNCiAgLy8gd2l0aCBhIHNlY29uZCBlbnVtZXJhdGlvbiwgc2Vl IHNlY29uZCBleGFtcGxlLg0KDQogIGxlYWYgbXVsdGlwbGUtZW51bWVyYXRpb25zLXRlc3QtMiB7 DQogICAgdHlwZSB1bmlvbiB7DQogICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCiAgICAgICAgZXh0 OnVuaW9uLXRhZyB3ZWVrZGF5czsNCiAgICAgICAgZW51bSAiTW9uZGF5IjsNCiAgICAgICAgZW51 bSAiVHVlc2RheSI7DQogICAgICAgIGVudW0gIldlZG5lc2RheSI7DQogICAgICAgIGVudW0gIlRo dXJzZGF5IjsNCiAgICAgICAgZW51bSAiRnJpZGF5IjsNCiAgICAgIH0NCiAgICAgIHR5cGUgZW51 bWVyYXRpb24gew0KICAgICAgICBleHQ6dW5pb24tdGFnIHdlZWtlbmQ7DQogICAgICAgIGVudW0g IlNhdHVyZGF5IjsNCiAgICAgICAgZW51bSAiU3VuZGF5IjsNCiAgICAgIH0NCiAgICB9DQogIH0N Cg0KICB0eXBlZGVmIHdlZWtkYXlzIHsNCiAgICB0eXBlIGVudW1lcmF0aW9uIHsNCiAgICAgIGVu dW0gIk1vbmRheSI7DQogICAgICBlbnVtICJUdWVzZGF5IjsNCiAgICAgIGVudW0gIldlZG5lc2Rh eSI7DQogICAgICBlbnVtICJUaHVyc2RheSI7DQogICAgICBlbnVtICJGcmlkYXkiOw0KICAgIH0N CiAgfQ0KDQogIHR5cGVkZWYgd2Vla2VuZCB7DQogICAgdHlwZSBlbnVtZXJhdGlvbiB7DQogICAg ICBlbnVtICJTYXR1cmRheSI7DQogICAgICBlbnVtICJTdW5kYXkiOw0KICAgIH0NCiAgfQ0KICAN CiAgbGVhZiBtdWx0aXBsZS1lbnVtZXJhdGlvbnMtdGVzdC0zIHsNCiAgICB0eXBlIHVuaW9uIHsN CiAgICAgIHR5cGUgd2Vla2RheXM7DQogICAgICB0eXBlIHdlZWtlbmQgew0KICAgICAgICBleHQ6 dW5pb24tdGFnIHdlZWtlbmQ7DQogICAgICB9DQogICAgfQ0KICB9DQogIA0KICAvLyAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAvLyBUaGlzIGV4 YW1wbGUgc2hvd3MgYSBjYXNlIGZvciB3aGljaCBhIHRhZyBpcyBub3QgcmVxdWlyZWQNCiAgDQog IGxlYWYgbXVsdGlwbGUtYml0cy10ZXN0LTEgew0KICAgIHR5cGUgdW5pb24gew0KICAgICAgdHlw ZSBiaXRzIHsNCiAgICAgICAgYml0ICAiTW9uZGF5IiB7IHBvc2l0aW9uICAwOyB9DQogICAgICAg IGJpdCAiVHVlc2RheSIgeyBwb3NpdGlvbiAgMTsgfQ0KICAgICAgICBiaXQgIldlZG5lc2RheSIg eyBwb3NpdGlvbiAgMjsgfQ0KICAgICAgICBiaXQgIlRodXJzZGF5IiB7IHBvc2l0aW9uICAzOyB9 DQogICAgICAgIGJpdCAiRnJpZGF5IiB7IHBvc2l0aW9uICA0OyB9DQoNCiAgICAgIH0NCiAgICAg IHR5cGUgYml0cyB7DQogICAgICAgIGJpdCAiU2F0dXJkYXkiIHsgcG9zaXRpb24gNTsgfQ0KICAg ICAgICBiaXQgIlN1bmRheSIgeyBwb3NpdGlvbiA2OyB9DQogICAgICB9DQogICAgfQ0KICB9DQoN CiAgLy8gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CiAgLy8gVGhlIGZvbGxvd2luZyB0d28gZXhhbXBsZXMgcmVxdWlyZSB0aGUgdXNlIG9mIGF0IGxl YXN0IG9uZQ0KICAvLyB1bmlvbiB0YWcgdG8gZ3VhcmFudGVlIHRoZSBwcm9wZXIgaW50ZXJwcmV0 YXRpb24gb2YgdGhvc2UgdHdvDQogIC8vIGVudW1lcmF0aW9ucy4NCiAgDQogIGxlYWYgbXVsdGlw bGUtYml0cy10ZXN0LTIgew0KICAgIHR5cGUgdW5pb24gew0KICAgICAgdHlwZSBiaXRzIHsNCiAg ICAgICAgZXh0OnVuaW9uLXRhZyB3ZWVrZGF5czsNCiAgICAgICAgYml0ICJNb25kYXkiOw0KICAg ICAgICBiaXQgIlR1ZXNkYXkiOw0KICAgICAgICBiaXQgIldlZG5lc2RheSI7DQogICAgICAgIGJp dCAiVGh1cnNkYXkiOw0KICAgICAgICBiaXQgIkZyaWRheSI7DQogICAgICB9DQogICAgICB0eXBl IGJpdHMgew0KICAgICAgICBleHQ6dW5pb24tdGFnIHdlZWtlbmQ7DQogICAgICAgIGJpdCAiU2F0 dXJkYXkiOw0KICAgICAgICBiaXQgIlN1bmRheSI7DQogICAgICB9DQogICAgfQ0KICB9DQoNCiAg dHlwZWRlZiB3ZWVrZGF5cy1mbGFncyB7DQogICAgdHlwZSBiaXRzIHsNCiAgICAgIGJpdCAiTW9u ZGF5IjsNCiAgICAgIGJpdCAiVHVlc2RheSI7DQogICAgICBiaXQgIldlZG5lc2RheSI7DQogICAg ICBiaXQgIlRodXJzZGF5IjsNCiAgICAgIGJpdCAiRnJpZGF5IjsNCiAgICB9DQogIH0NCg0KICB0 eXBlZGVmIHdlZWtlbmQtZmxhZ3Mgew0KICAgIHR5cGUgYml0cyB7DQogICAgICBiaXQgIlNhdHVy ZGF5IjsNCiAgICAgIGJpdCAiU3VuZGF5IjsNCiAgICB9DQogIH0NCiAgDQogIGxlYWYgbXVsdGlw bGUtYml0cy10ZXN0LTMgew0KICAgIHR5cGUgdW5pb24gew0KICAgICAgdHlwZSB3ZWVrZGF5cy1m bGFnczsNCiAgICAgIHR5cGUgd2Vla2VuZC1mbGFncyB7DQogICAgICAgIGV4dDp1bmlvbi10YWcg d2Vla2VuZDsNCiAgICAgIH0NCiAgICB9DQogIH0NCn0= --_002_BL0PR06MB504264D081B40ACBE22CF6C69A580BL0PR06MB5042namp_-- From nobody Wed Mar 27 09:14:09 2019 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 5520512027E for ; Wed, 27 Mar 2019 09:14:02 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 SxejsTWjyE_X for ; Wed, 27 Mar 2019 09:13:58 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 65EA81202FF for ; Wed, 27 Mar 2019 09:13:57 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id v14so11896818lfi.0 for ; Wed, 27 Mar 2019 09:13:57 -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=jIqIzCDcz6AlsqV2oeQkiEJGGG4zS039EE0DiRtEghU=; b=wLXypH3VNRGMsX3uN0FIlhFz6IFBlRSlLRv9vwZM4f8y3bwrqTKmeC2rMuirwPfVoo rDo/Gz82mwbLqvZ7PR/eLOMFD7O+jBkb6NWeta2IsbsIXRDF5U72OxgSDdYJy8rGWcqp /TBy/uL1YM9oJvpx/7mB3+oqrXCd+MvEETk8U+8Qp1uwoaJy5CWYPRQI6zOkPXRVH8e3 /pD0ipOfzkI4NOWB26dQSyq1StnnlEbeFEvzMzZr/mhpGdvYUuCXmfdxCWMg6DaoBGnc rtgMcjoBmVyQQoPr5cYU4GYLtHrLqZT6EHJi1caJr1rqM8Di4rh18fap3dWnGSMu8wdp 97yw== 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=jIqIzCDcz6AlsqV2oeQkiEJGGG4zS039EE0DiRtEghU=; b=fwbP622Mpizfj7pd+8oJSGWYguxtYUxhE9KZmhCT6xAGh9OS4v/YORxUaNQIlEj2uk 75qVEZJwXMtB0S0fietEMqsB2AR/tstGuxf2dwnJyoOaep+3S/XhmYAr9wAYxwANwZpl zP/brg67RENu5sWY3g9J5XWT6LBIKxdGoDbgLUZ3wplXC6xy+uxxs0qpBjWofMBiTMT9 jfNMOCpE7JHAjDN95HNtgTHQqKAGg5G8I1wHorKM/bq99+OCnOrQMMBJDIopp2a3tB7l FRxm73YCAefFIdE7od8PFi3IG8jSddTcSBqm97QYtFG0z41MGYulyCouh05ybVi+wB/C YHzg== X-Gm-Message-State: APjAAAVB4x8g3Ryzk6KnM3K/0p52BQ36HjY5RUEL8W3YgDtIUYdul4ZA 9rIyWHj7g/PuKd0K+xM9dctW7UGRPy+1r1E9wGIvhA== X-Google-Smtp-Source: APXvYqxErEw/GrBdRyTJOQJV2Unom9aXZu3m3a8VHw+MtId+QR4MU8G+gieGMD+7Srb4SqSgVTWmFWe6EDob65XInng= X-Received: by 2002:ac2:52a6:: with SMTP id r6mr20160975lfm.27.1553703235362; Wed, 27 Mar 2019 09:13:55 -0700 (PDT) MIME-Version: 1.0 References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <1f8b326e0e05b400457b9446d52a7b0f6c90e05b.camel@nic.cz> In-Reply-To: <1f8b326e0e05b400457b9446d52a7b0f6c90e05b.camel@nic.cz> From: Andy Bierman Date: Wed, 27 Mar 2019 09:13:44 -0700 Message-ID: To: Ladislav Lhotka Cc: Juergen Schoenwaelder , Michel Veillette , "netconf@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006e38e2058515b90a" Archived-At: Subject: Re: [netconf] [core] YANG encoding in CBOR 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, 27 Mar 2019 16:14:02 -0000 --0000000000006e38e2058515b90a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 27, 2019 at 1:40 AM Ladislav Lhotka wrote: > On Wed, 2019-03-27 at 07:16 +0100, Juergen Schoenwaelder wrote: > > Hi, > > > > a union can be formed by using member types that are imported and not > > under change control of a single author/organization and ideally this > > should work without complex coordination of name and number spaces. > > Duplicate enum/bits values are legal in YANG today so an encoding has > > to deal with this aspect of life. > > > > A robust fix to all these problems will be to tag the type members in > > order to discriminate the values in the encodings. This, however, will > > take some time to specify and we will need to preserve backwards > > compatibility with unions without a tag (but compilers can encourage > > people to add tags whenever modules are updated). > > I already opened a new issue for this in yang-next: > > https://github.com/netmod-wg/yang-next/issues/72 > > We already explored the solution of giving the member types numbers so they could be used in CBOR but this was rejected because it is so complex to implement. Consider when union is within union, and the types are named types from other modules. Union types can be legally updated in new versions of the module, but the position assignments for SID can never change. Even without this complexity this solution would cause the encoder/decoder to be very schema-aware. BTW, creating SIDs for enums and bits will break if the server uses 'deviate replace type'. There is no way to number the deviated type since this is server-specific not part of the original module and the deviation is not actually a data-def-stmt. Lada > > Andy > > > > /js > > > > On Wed, Mar 27, 2019 at 01:12:52AM +0000, Michel Veillette wrote: > > > Hi Ladislav > > > > > > If I summarize this issue of multiple enumerations or bits in a union= , > this > > > problem can be solve by the following approaches: > > > > > > - To not allows these duplicate values or positions to happen in YANG > > > - To encode enumerations and bits as string (in all unions or only wh= en > > > multiple enumerations or bits are defined) > > > - To encode enumerations and bits as SID (in all unions or only when > > > multiple enumerations or bits are defined) > > > - To encode enumerations and bits as delta between the value SID and > the > > > leaf SID (in all unions or only when multiple enumerations or bits ar= e > > > defined) > > > > > > In this email, I will like to focus on the first option, fixing the > problem > > > directly in YANG instead of fixing the consequences. > > > > > > Without any changes in YANG, a union with multiple enumeration or bit= s > can > > > be constructed without value or position overlaps. > > > For example: > > > > > > leaf multiple-enumerations-test-1 { > > > type union { > > > type enumeration { > > > enum "Monday" { value 0; } > > > enum "Tuesday" { value 1; } > > > enum "Wednesday" { value 2; } > > > enum "Thursday" { value 3; } > > > enum "Friday" { value 4; } > > > > > > } > > > type enumeration { > > > enum "Saturday" { value 5; } > > > enum "Sunday" { value 6; } > > > } > > > } > > > } > > > > > > leaf multiple-bits-test-1 { > > > type union { > > > type bits { > > > bit "Monday" { position 0; } > > > bit "Tuesday" { position 1; } > > > bit "Wednesday" { position 2; } > > > bit "Thursday" { position 3; } > > > bit "Friday" { position 4; } > > > > > > } > > > type bits { > > > bit "Saturday" { position 5; } > > > bit "Sunday" { position 6; } > > > } > > > } > > > } > > > > > > When using already defined typedef, avoiding overlap is less obvious > without > > > some help. > > > To help building unions with already defined typedefs, I propose to > > > introduce two extensions. > > > > > > extension value-offset { > > > argument offset { > > > yin-element true; > > > } > > > description > > > "Offset added to each enum value of the associated enumeration.= "; > > > } > > > > > > extension position-offset { > > > argument offset { > > > yin-element true; > > > } > > > description > > > "Offset value added to each bit position of the associated > bits."; > > > } > > > > > > The value-offset extension can be used as follow: > > > > > > type enumeration { > > > enum "Monday"; > > > enum "Tuesday"; > > > enum "Wednesday"; > > > enum "Thursday"; > > > enum "Friday"; > > > } > > > } > > > > > > typedef weekend { > > > type enumeration { > > > enum "Saturday"; > > > enum "Sunday"; > > > } > > > } > > > > > > leaf multiple-enumerations-test-3 { > > > type union { > > > type weekdays; > > > type weekend { > > > ext:value-offset 5; > > > } > > > } > > > } > > > > > > The position-offset extension can be used as follow: > > > > > > typedef weekdays-flags { > > > type bits { > > > bit "Monday"; > > > bit "Tuesday"; > > > bit "Wednesday"; > > > bit "Thursday"; > > > bit "Friday"; > > > } > > > } > > > > > > typedef weekend-flags { > > > type bits { > > > bit "Saturday"; > > > bit "Sunday"; > > > } > > > } > > > > > > leaf multiple-bits-test-3 { > > > type union { > > > type weekdays-flags; > > > type weekend-flags { > > > ext:position-offset 5; > > > } > > > } > > > } > > > > > > The yang file in attachment show different examples based on this > approach. > > > This module have been validated using > http://www.yangvalidator.com/validator > > > > > > If this approach is accepted, tools like pyang should be updated to > produce > > > an error if multiple enumerations or bits are defined with value or > position > > > overleaps. > > > > > > Please comment, > > > Michel > > > > > > -----Original Message----- > > > From: Ladislav Lhotka > > > Sent: Monday, March 25, 2019 4:07 AM > > > To: Juergen Schoenwaelder ; > Carsten > > > Bormann > > > Cc: Michel Veillette ; > netconf@ietf.org; > > > core@ietf.org > > > Subject: Re: [netconf] YANG encoding in CBOR > > > > > > Juergen Schoenwaelder writes: > > > > > > > I think we need to look at the whole picture and in which direction > we > > > > want to go. In the longer term, I would prefer a solution where the > > > > values of a union are discriminated. The current XML encoding > > > > behaviour of 'first match wins' is fragile (for example, if someone > > > > adds an enum to a type, the interpretation of data can change). > > > > > > > > Look at this: > > > > > > > > typedef bar { > > > > type union { > > > > type enumeration { enum "1"; value 2; enum "2"; value 1; } > > > > type uint8; > > > > } > > > > } > > > > > > > > We have some encodings that send the string representations of the > > > > values and some encodings that prefer to send numeric > representations > > > > where possible. In order to have a robust solution, encodings shoul= d > > > > likely indicate to which type the value belongs. > > > > > > Perhaps the easiest way would be to use (optional) annotation that > > > specifies, using an ordinal number, which of the member types is used > for > > > the particular instance. But since there can be unions inside unions, > a list > > > of numbers would be needed in general. > > > > > > Lada > > > > > > > /js > > > > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > > > > > Well, if that is a problem, we can go for a longer representation > within > > > > > unions (section 6.12). Theoretically, we could do that only of > there is > > > > > more than one enum in the union type (so things stay efficient if > there > > > > > is only one), but that might pose difficulties with model > evolution. > > > > > > > > > > Going for a string representation repeats the feature of XML YANG > (which > > > > > was ported over to JSON YANG): > > > > > > > > > > typedef foo { > > > > > type union { > > > > > type enumeration { > > > > > enum red { value 1; } > > > > > enum breen { value 2; } > > > > > enum glue { value 3; } > > > > > } > > > > > type enumeration { > > > > > enum tacks { value 1; } > > > > > enum nails { value 2; } > > > > > enum glue { value 3; } > > > > > } > > > > > } > > > > > } > > > > > > > > > > If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which o= f the enumerations are > being > > > > > used. > > > > > > > > > > Using SIDs, we can do better. > > > > > > > > > > So what do we have to do to get the SID tool to allocate SIDs for > enum > > > > > values? > > > > > > > > > > We could then define the CBOR tag for enums in unions to take the > usual > > > > > SID difference (delta relative to the environment, I=E2=80=99d th= ink), not > an > > > > > integer value. > > > > > > > > > > Several of us are at the hackathon and could make something happe= n > today > > > > > and tomorrow. > > > > > > > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > > > > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) < > rwilton@cisco.com> > > > > > > wrote: > > > > > > > > > > > > I guess that the concern is that this introduces more variation > in how > > > > > > data is interpreted between the different XML/JSON/CBOR > encodings. > > > > > > > > > > > > E.g. if someone switched from XML to CBOR, suddenly the > configuration > > > > > > or state data may have a different meaning. > > > > > > > > > > > > Thanks, > > > > > > Rob > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Carsten Bormann > > > > > > > Sent: 22 March 2019 16:08 > > > > > > > To: Michel Veillette > > > > > > > Cc: Rob Wilton (rwilton) ; core@ietf.org; > > > > > > > netconf@ietf.org > > > > > > > Subject: Re: [netconf] YANG encoding in CBOR > > > > > > > > > > > > > > On Mar 22, 2019, at 16:45, Michel Veillette > > > > > > > > > > > > > > wrote: > > > > > > > > The only potential problem I aware is when multiple > enumerations > > > > > > > > are part of > > > > > > > the same union. > > > > > > > > Value 4 from enumeration A will be encoded the same way as > Value > > > > > > > > 4 from > > > > > > > enumeration B. > > > > > > > > > > > > > > =E2=80=A6 and that is not a problem for the XML version, beca= use the > > > > > > > string is being used instead of the value. (But then if two > > > > > > > enumerations share a string, you have the equivalent problem > in > > > > > > > the XML serialization.) > > > > > > > > > > > > > > Anyway, I haven=E2=80=99t seen a piece of real-world YANG tha= t > actually > > > > > > > has this problem, so I would be a bit reluctant to make > CBOR-based > > > > > > > implementations more complex (and less efficient) so solve th= is > > > > > > > (non-?)problem. > > > > > > > > > > > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > netconf mailing list > > > > > netconf@ietf.org > > > > > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww > > > > > .ietf.org > %2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343ea8 > > > > > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1 > > > > > > %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0 > > > > > kvPZgr4o%3D&reserved=3D0 > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > > Fax: +49 421 200 3103 < > > > > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.j= acobs-university.de%2F&data=3D02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8= d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&sd= ata=3DTrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&reserved=3D0 > > > > > > > > > > > > > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > > > > > Well, if that is a problem, we can go for a longer representation > within > > > > > unions (section 6.12). Theoretically, we could do that only of > there is > > > > > more than one enum in the union type (so things stay efficient if > there > > > > > is only one), but that might pose difficulties with model > evolution. > > > > > > > > > > Going for a string representation repeats the feature of XML YANG > (which > > > > > was ported over to JSON YANG): > > > > > > > > > > typedef foo { > > > > > type union { > > > > > type enumeration { > > > > > enum red { value 1; } > > > > > enum breen { value 2; } > > > > > enum glue { value 3; } > > > > > } > > > > > type enumeration { > > > > > enum tacks { value 1; } > > > > > enum nails { value 2; } > > > > > enum glue { value 3; } > > > > > } > > > > > } > > > > > } > > > > > > > > > > If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which o= f the enumerations are > being > > > > > used. > > > > > > > > > > Using SIDs, we can do better. > > > > > > > > > > So what do we have to do to get the SID tool to allocate SIDs for > enum > > > > > values? > > > > > > > > > > We could then define the CBOR tag for enums in unions to take the > usual > > > > > SID difference (delta relative to the environment, I=E2=80=99d th= ink), not > an > > > > > integer value. > > > > > > > > > > Several of us are at the hackathon and could make something happe= n > today > > > > > and tomorrow. > > > > > > > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > > > > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) < > rwilton@cisco.com> > > > > > > wrote: > > > > > > > > > > > > I guess that the concern is that this introduces more variation > in how > > > > > > data is interpreted between the different XML/JSON/CBOR > encodings. > > > > > > > > > > > > E.g. if someone switched from XML to CBOR, suddenly the > configuration > > > > > > or state data may have a different meaning. > > > > > > > > > > > > Thanks, > > > > > > Rob > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Carsten Bormann > > > > > > > Sent: 22 March 2019 16:08 > > > > > > > To: Michel Veillette > > > > > > > Cc: Rob Wilton (rwilton) ; core@ietf.org; > > > > > > > netconf@ietf.org > > > > > > > Subject: Re: [netconf] YANG encoding in CBOR > > > > > > > > > > > > > > On Mar 22, 2019, at 16:45, Michel Veillette > > > > > > > > > > > > > > wrote: > > > > > > > > The only potential problem I aware is when multiple > enumerations > > > > > > > > are part of > > > > > > > the same union. > > > > > > > > Value 4 from enumeration A will be encoded the same way as > Value > > > > > > > > 4 from > > > > > > > enumeration B. > > > > > > > > > > > > > > =E2=80=A6 and that is not a problem for the XML version, beca= use the > > > > > > > string is being used instead of the value. (But then if two > > > > > > > enumerations share a string, you have the equivalent problem > in > > > > > > > the XML serialization.) > > > > > > > > > > > > > > Anyway, I haven=E2=80=99t seen a piece of real-world YANG tha= t > actually > > > > > > > has this problem, so I would be a bit reluctant to make > CBOR-based > > > > > > > implementations more complex (and less efficient) so solve th= is > > > > > > > (non-?)problem. > > > > > > > > > > > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > netconf mailing list > > > > > netconf@ietf.org > > > > > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww > > > > > .ietf.org > %2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343ea8 > > > > > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1 > > > > > > %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0 > > > > > kvPZgr4o%3D&reserved=3D0 > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > > Fax: +49 421 200 3103 < > > > > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.j= acobs-university.de%2F&data=3D02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8= d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&sd= ata=3DTrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&reserved=3D0 > > > > > > > > > > > > > _______________________________________________ > > > > netconf mailing list > > > > netconf@ietf.org > > > > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > > > > ietf.org > %2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343ea8d1 > > > > > cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C > > > > > 636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0kvPZ > > > > gr4o%3D&reserved=3D0 > > > > > > -- > > > Ladislav Lhotka > > > Head, CZ.NIC Labs > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --0000000000006e38e2058515b90a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 27, 2019 at 1:40 AM Ladis= lav Lhotka <lhotka@nic.cz> wrote= :
On Wed, 2019-0= 3-27 at 07:16 +0100, Juergen Schoenwaelder wrote:
> Hi,
>
> a union can be formed by using member types that are imported and not<= br> > under change control of a single author/organization and ideally this<= br> > should work without complex coordination of name and number spaces. > Duplicate enum/bits values are legal in YANG today so an encoding has<= br> > to deal with this aspect of life.
>
> A robust fix to all these problems will be to tag the type members in<= br> > order to discriminate the values in the encodings. This, however, will=
> take some time to specify and we will need to preserve backwards
> compatibility with unions without a tag (but compilers can encourage > people to add tags whenever modules are updated).

I already opened a new issue for this in yang-next:

https://github.com/netmod-wg/yang-next/issues/72=


We already explored the solution of gi= ving the member types numbers
so they could be used in CBOR but t= his was rejected because it is so complex to implement.

Consider when union is within union, and the types are named types fr= om
other modules. Union types can be legally updated in new versi= ons of the module,
but the position assignments for SID can never= change.

Even without this complexity this solutio= n would cause the encoder/decoder to
be very schema-aware.=C2=A0<= /div>

BTW, creating SIDs for enums and bits will break i= f the server uses 'deviate replace type'.
There is no way= to number the deviated type since this is server-specific not part of the = original module
and the deviation is not actually a data-def-stmt= .


Lada


Andy
=C2=A0
>
> /js
>
> On Wed, Mar 27, 2019 at 01:12:52AM +0000, Michel Veillette wrote:
> > Hi Ladislav
> >
> > If I summarize this issue of multiple enumerations or bits in a u= nion, this
> > problem can be solve by the following approaches:
> >
> > - To not allows these duplicate values or positions to happen in = YANG
> > - To encode enumerations and bits as string (in all unions or onl= y when
> > multiple enumerations or bits are defined)
> > - To encode enumerations and bits as SID (in all unions or only w= hen
> > multiple enumerations or bits are defined)
> > - To encode enumerations and bits as delta between the value SID = and the
> > leaf SID (in all unions or only when multiple enumerations or bit= s are
> > defined)
> >
> > In this email, I will like to focus on the first option, fixing t= he problem
> > directly in YANG instead of fixing the consequences.
> >
> > Without any changes in YANG, a union with multiple enumeration or= bits can
> > be constructed without value or position overlaps.
> > For example:
> >
> >=C2=A0 =C2=A0leaf multiple-enumerations-test-1 {
> >=C2=A0 =C2=A0 =C2=A0type union {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type enumeration {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Monday" { value = 0; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Tuesday" { value= 1; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Wednesday" { val= ue 2; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Thursday" { valu= e 3; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Friday" { value = 4; }
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type enumeration {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Saturday" { valu= e 5; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Sunday" { value = 6; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0leaf multiple-bits-test-1 {
> >=C2=A0 =C2=A0 =C2=A0type union {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type bits {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit=C2=A0 "Monday" { p= osition=C2=A0 0; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Tuesday" { positi= on=C2=A0 1; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Wednesday" { posi= tion=C2=A0 2; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Thursday" { posit= ion=C2=A0 3; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Friday" { positio= n=C2=A0 4; }
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type bits {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Saturday" { posit= ion 5; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Sunday" { positio= n 6; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> > When using already defined typedef, avoiding overlap is less obvi= ous without
> > some help.
> > To help building unions with already defined typedefs, I propose = to
> > introduce two extensions.
> >
> >=C2=A0 =C2=A0extension value-offset {
> >=C2=A0 =C2=A0 =C2=A0argument offset {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0yin-element true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Offset added to each enum value o= f the associated enumeration.";
> >=C2=A0 =C2=A0}
> >=C2=A0 =C2=A0
> >=C2=A0 =C2=A0extension position-offset {
> >=C2=A0 =C2=A0 =C2=A0argument offset {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0yin-element true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Offset value added to each bit po= sition of the associated bits.";
> >=C2=A0 =C2=A0}
> >
> > The value-offset extension can be used as follow:
> >
> >=C2=A0 =C2=A0 =C2=A0type enumeration {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Monday";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Tuesday";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Wednesday";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Thursday";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Friday";
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0typedef weekend {
> >=C2=A0 =C2=A0 =C2=A0type enumeration {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Saturday";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Sunday";
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >=C2=A0 =C2=A0
> >=C2=A0 =C2=A0leaf multiple-enumerations-test-3 {
> >=C2=A0 =C2=A0 =C2=A0type union {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type weekdays;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type weekend {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ext:value-offset 5;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> > The position-offset extension can be used as follow:
> >
> >=C2=A0 =C2=A0typedef weekdays-flags {
> >=C2=A0 =C2=A0 =C2=A0type bits {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Monday";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Tuesday";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Wednesday";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Thursday";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Friday";
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0typedef weekend-flags {
> >=C2=A0 =C2=A0 =C2=A0type bits {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Saturday";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Sunday";
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >=C2=A0 =C2=A0
> >=C2=A0 =C2=A0leaf multiple-bits-test-3 {
> >=C2=A0 =C2=A0 =C2=A0type union {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type weekdays-flags;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type weekend-flags {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ext:position-offset 5;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> > The yang file in attachment show different examples based on this= approach.
> > This module have been validated using http://www.yan= gvalidator.com/validator
> >=C2=A0
> > If this approach is accepted, tools like pyang should be updated = to produce
> > an error if multiple enumerations or bits are defined with value = or position
> > overleaps.
> >
> > Please comment,
> > Michel
> >
> > -----Original Message-----
> > From: Ladislav Lhotka <lhotka@nic.cz>
> > Sent: Monday, March 25, 2019 4:07 AM
> > To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de= >; Carsten
> > Bormann <cab= o@tzi.org>
> > Cc: Michel Veillette <Michel.Veillette@trilliant.com>; netconf@ietf.org;
> > core@ietf.org<= /a>
> > Subject: Re: [netconf] YANG encoding in CBOR
> >
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de= > writes:
> >
> > > I think we need to look at the whole picture and in which di= rection we
> > > want to go. In the longer term, I would prefer a solution wh= ere the
> > > values of a union are discriminated. The current XML encodin= g
> > > behaviour of 'first match wins' is fragile (for exam= ple, if someone
> > > adds an enum to a type, the interpretation of data can chang= e).
> > >
> > > Look at this:
> > >
> > > typedef bar {
> > >=C2=A0 =C2=A0type union {
> > >=C2=A0 =C2=A0 =C2=A0type enumeration { enum "1"; va= lue 2; enum "2"; value 1; }
> > >=C2=A0 =C2=A0 =C2=A0type uint8;
> > >=C2=A0 =C2=A0}
> > > }
> > >
> > > We have some encodings that send the string representations = of the
> > > values and some encodings that prefer to send numeric repres= entations
> > > where possible. In order to have a robust solution, encoding= s should
> > > likely indicate to which type the value belongs.
> >
> > Perhaps the easiest way would be to use (optional) annotation tha= t
> > specifies, using an ordinal number, which of the member types is = used for
> > the particular instance. But since there can be unions inside uni= ons, a list
> > of numbers would be needed in general.
> >
> > Lada
> >
> > > /js
> > >
> > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wr= ote:
> > > > Well, if that is a problem, we can go for a longer repr= esentation within
> > > > unions (section 6.12).=C2=A0 Theoretically, we could do= that only of there is
> > > > more than one enum in the union type (so things stay ef= ficient if there
> > > > is only one), but that might pose difficulties with mod= el evolution.
> > > >
> > > > Going for a string representation repeats the feature o= f XML YANG (which
> > > > was ported over to JSON YANG):
> > > >
> > > > typedef foo {
> > > >=C2=A0 =C2=A0type union {
> > > >=C2=A0 =C2=A0 =C2=A0type enumeration {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum red { value 1; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum breen { value 2; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum glue { value 3; }
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0type enumeration {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum tacks { value 1; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum nails { value 2; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum glue { value 3; }
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > > }
> > > >
> > > > If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t kn= ow which of the enumerations are being
> > > > used.
> > > >
> > > > Using SIDs, we can do better.
> > > >
> > > > So what do we have to do to get the SID tool to allocat= e SIDs for enum
> > > > values?
> > > >
> > > > We could then define the CBOR tag for enums in unions t= o take the usual
> > > > SID difference (delta relative to the environment, I=E2= =80=99d think), not an
> > > > integer value.
> > > >
> > > > Several of us are at the hackathon and could make somet= hing happen today
> > > > and tomorrow.
> > > >
> > > > Gr=C3=BC=C3=9Fe, Carsten
> > > >
> > > >
> > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) &l= t;rwilton@cisco.com<= /a>>
> > > > > wrote:
> > > > >
> > > > > I guess that the concern is that this introduces m= ore variation in how
> > > > > data is interpreted between the different XML/JSON= /CBOR encodings.
> > > > >
> > > > > E.g. if someone switched from XML to CBOR, suddenl= y the configuration
> > > > > or state data may have a different meaning.
> > > > >
> > > > > Thanks,
> > > > > Rob
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Carsten Bormann <cabo@tzi.org>
> > > > > > Sent: 22 March 2019 16:08
> > > > > > To: Michel Veillette <Michel.Veillette@trilliant.= com>
> > > > > > Cc: Rob Wilton (rwilton) <rwilton@cisco.com>; core@ietf.org;
> > > > > > netconf@ietf.org
> > > > > > Subject: Re: [netconf] YANG encoding in CBOR<= br> > > > > > >
> > > > > > On Mar 22, 2019, at 16:45, Michel Veillette <= br> > > > > > > <Michel.Veillette@trilliant.com>
> > > > > > wrote:
> > > > > > > The only potential problem I aware is wh= en multiple enumerations
> > > > > > > are part of
> > > > > > the same union.
> > > > > > > Value 4 from enumeration A will be encod= ed the same way as Value
> > > > > > > 4 from
> > > > > > enumeration B.
> > > > > >
> > > > > > =E2=80=A6 and that is not a problem for the X= ML version, because the
> > > > > > string is being used instead of the value.=C2= =A0 (But then if two
> > > > > > enumerations share a string, you have the equ= ivalent problem in
> > > > > > the XML serialization.)
> > > > > >
> > > > > > Anyway, I haven=E2=80=99t seen a piece of rea= l-world YANG that actually
> > > > > > has this problem, so I would be a bit relucta= nt to make CBOR-based
> > > > > > implementations more complex (and less effici= ent) so solve this
> > > > > > (non-?)problem.
> > > > > >
> > > > > > Gr=C3=BC=C3=9Fe, Carsten
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > netconf mailing list
> > > > n= etconf@ietf.org
> > > > https://c= an01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
> > > > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&amp;data=3D02%7= C01%7C%7C343ea8
> > > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260= c04309%7C0%7C1
> > > > %7C636890980182553400&amp;sdata=3Du1KFAYAus16B8a7sg= sBfPfIquOptMlaOb%2B0
> > > > kvPZgr4o%3D&amp;reserved=3D0
> > >
> > > --
> > > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cam= pus Ring 1 | 28759 Bremen | Germany
> > > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0<
> > > ht= tps://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.jacob= s-university.de%2F&amp;data=3D02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8= d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&am= p;sdata=3DTrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&amp;reserv= ed=3D0
> > > >
> > >
> > >
> > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wr= ote:
> > > > Well, if that is a problem, we can go for a longer repr= esentation within
> > > > unions (section 6.12).=C2=A0 Theoretically, we could do= that only of there is
> > > > more than one enum in the union type (so things stay ef= ficient if there
> > > > is only one), but that might pose difficulties with mod= el evolution.
> > > >
> > > > Going for a string representation repeats the feature o= f XML YANG (which
> > > > was ported over to JSON YANG):
> > > >
> > > > typedef foo {
> > > >=C2=A0 =C2=A0type union {
> > > >=C2=A0 =C2=A0 =C2=A0type enumeration {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum red { value 1; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum breen { value 2; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum glue { value 3; }
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0type enumeration {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum tacks { value 1; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum nails { value 2; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum glue { value 3; }
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > > }
> > > >
> > > > If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t kn= ow which of the enumerations are being
> > > > used.
> > > >
> > > > Using SIDs, we can do better.
> > > >
> > > > So what do we have to do to get the SID tool to allocat= e SIDs for enum
> > > > values?
> > > >
> > > > We could then define the CBOR tag for enums in unions t= o take the usual
> > > > SID difference (delta relative to the environment, I=E2= =80=99d think), not an
> > > > integer value.
> > > >
> > > > Several of us are at the hackathon and could make somet= hing happen today
> > > > and tomorrow.
> > > >
> > > > Gr=C3=BC=C3=9Fe, Carsten
> > > >
> > > >
> > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) &l= t;rwilton@cisco.com<= /a>>
> > > > > wrote:
> > > > >
> > > > > I guess that the concern is that this introduces m= ore variation in how
> > > > > data is interpreted between the different XML/JSON= /CBOR encodings.
> > > > >
> > > > > E.g. if someone switched from XML to CBOR, suddenl= y the configuration
> > > > > or state data may have a different meaning.
> > > > >
> > > > > Thanks,
> > > > > Rob
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Carsten Bormann <cabo@tzi.org>
> > > > > > Sent: 22 March 2019 16:08
> > > > > > To: Michel Veillette <Michel.Veillette@trilliant.= com>
> > > > > > Cc: Rob Wilton (rwilton) <rwilton@cisco.com>; core@ietf.org;
> > > > > > netconf@ietf.org
> > > > > > Subject: Re: [netconf] YANG encoding in CBOR<= br> > > > > > >
> > > > > > On Mar 22, 2019, at 16:45, Michel Veillette <= br> > > > > > > <Michel.Veillette@trilliant.com>
> > > > > > wrote:
> > > > > > > The only potential problem I aware is wh= en multiple enumerations
> > > > > > > are part of
> > > > > > the same union.
> > > > > > > Value 4 from enumeration A will be encod= ed the same way as Value
> > > > > > > 4 from
> > > > > > enumeration B.
> > > > > >
> > > > > > =E2=80=A6 and that is not a problem for the X= ML version, because the
> > > > > > string is being used instead of the value.=C2= =A0 (But then if two
> > > > > > enumerations share a string, you have the equ= ivalent problem in
> > > > > > the XML serialization.)
> > > > > >
> > > > > > Anyway, I haven=E2=80=99t seen a piece of rea= l-world YANG that actually
> > > > > > has this problem, so I would be a bit relucta= nt to make CBOR-based
> > > > > > implementations more complex (and less effici= ent) so solve this
> > > > > > (non-?)problem.
> > > > > >
> > > > > > Gr=C3=BC=C3=9Fe, Carsten
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > netconf mailing list
> > > > n= etconf@ietf.org
> > > > https://c= an01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
> > > > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&amp;data=3D02%7= C01%7C%7C343ea8
> > > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260= c04309%7C0%7C1
> > > > %7C636890980182553400&amp;sdata=3Du1KFAYAus16B8a7sg= sBfPfIquOptMlaOb%2B0
> > > > kvPZgr4o%3D&amp;reserved=3D0
> > >
> > > --
> > > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cam= pus Ring 1 | 28759 Bremen | Germany
> > > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0<
> > > ht= tps://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.jacob= s-university.de%2F&amp;data=3D02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8= d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&am= p;sdata=3DTrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&amp;reserv= ed=3D0
> > > >
> > >
> > > _______________________________________________
> > > netconf mailing list
> > > netcon= f@ietf.org
> > > https://can01.= safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
> > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&amp;data=3D02%7C01%7C%= 7C343ea8d1
> > > cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%= 7C0%7C1%7C
> > > 636890980182553400&amp;sdata=3Du1KFAYAus16B8a7sgsBfPfIqu= OptMlaOb%2B0kvPZ
> > > gr4o%3D&amp;reserved=3D0
> >
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
>
>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--0000000000006e38e2058515b90a-- From nobody Wed Mar 27 12:54:15 2019 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 2FE5C120287; Wed, 27 Mar 2019 12:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 qm55voh0iDFu; Wed, 27 Mar 2019 12:54:10 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 C868E120281; Wed, 27 Mar 2019 12:54:09 -0700 (PDT) Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id A00B260898; Wed, 27 Mar 2019 20:54:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1553716447; bh=H4HMDJ54o02EDEIwUM6ZJjBNSI9ooKoSS+AqZl7fsQQ=; h=From:To:Date; b=QorjJM1i7nATsvbEKRWBnPH0hmlPf4m0yfsOZHD/T2xQ5sN3GAP/sjw+s9kFFFL1W g4AFCa5BPLPiL6io/NUh3BUBhk7/4CVFGQWGldyLEeRD2+G5EnZoNOZhTm7Obn4Amy FGa1F/VuSpMhM0yxeeWvzAS3EXN9T1T2RZ5sVhsI= Message-ID: From: Ladislav Lhotka To: Andy Bierman Cc: Juergen Schoenwaelder , Michel Veillette , "netconf@ietf.org" , "core@ietf.org" Date: Wed, 27 Mar 2019 20:54:07 +0100 In-Reply-To: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <1f8b326e0e05b400457b9446d52a7b0f6c90e05b.camel@nic.cz> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netconf] [core] YANG encoding in CBOR 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, 27 Mar 2019 19:54:14 -0000 Andy Bierman píše v St 27. 03. 2019 v 09:13 -0700: > > > On Wed, Mar 27, 2019 at 1:40 AM Ladislav Lhotka wrote: > > On Wed, 2019-03-27 at 07:16 +0100, Juergen Schoenwaelder wrote: > > > Hi, > > > > > > a union can be formed by using member types that are imported and not > > > under change control of a single author/organization and ideally this > > > should work without complex coordination of name and number spaces. > > > Duplicate enum/bits values are legal in YANG today so an encoding has > > > to deal with this aspect of life. > > > > > > A robust fix to all these problems will be to tag the type members in > > > order to discriminate the values in the encodings. This, however, will > > > take some time to specify and we will need to preserve backwards > > > compatibility with unions without a tag (but compilers can encourage > > > people to add tags whenever modules are updated). > > > > I already opened a new issue for this in yang-next: > > > > https://github.com/netmod-wg/yang-next/issues/72 > > > > We already explored the solution of giving the member types numbers > so they could be used in CBOR but this was rejected because it is so complex > to implement. I don't think it is too complex. Get the type in the schema, get the member, that's all. It is much easier and more robust than the current algorithm. > > Consider when union is within union, and the types are named types from Union within union is no problem: it jut requires a sequence of numbers. > other modules. Union types can be legally updated in new versions of the > module, Again, I don't agree. Sec. 11 in RFC 7950 says: o A "type" statement may be replaced with another "type" statement that does not change the syntax or semantics of the type. ... Adding a new member clearly changes the semantics of the type, if not syntax. > but the position assignments for SID can never change. The annotation would also help resolve the differences between JSON and XML. SID is only available in CBOR. > > Even without this complexity this solution would cause the encoder/decoder to > be very schema-aware. The current method of resolving unions is totally schema-aware (somewhat less so in JSON). Lada > > > BTW, creating SIDs for enums and bits will break if the server uses 'deviate > replace type'. > There is no way to number the deviated type since this is server-specific not > part of the original module > and the deviation is not actually a data-def-stmt. > > > > Lada > > > > Andy > > > > > > > /js > > > > > > On Wed, Mar 27, 2019 at 01:12:52AM +0000, Michel Veillette wrote: > > > > Hi Ladislav > > > > > > > > If I summarize this issue of multiple enumerations or bits in a union, > > this > > > > problem can be solve by the following approaches: > > > > > > > > - To not allows these duplicate values or positions to happen in YANG > > > > - To encode enumerations and bits as string (in all unions or only when > > > > multiple enumerations or bits are defined) > > > > - To encode enumerations and bits as SID (in all unions or only when > > > > multiple enumerations or bits are defined) > > > > - To encode enumerations and bits as delta between the value SID and the > > > > leaf SID (in all unions or only when multiple enumerations or bits are > > > > defined) > > > > > > > > In this email, I will like to focus on the first option, fixing the > > problem > > > > directly in YANG instead of fixing the consequences. > > > > > > > > Without any changes in YANG, a union with multiple enumeration or bits > > can > > > > be constructed without value or position overlaps. > > > > For example: > > > > > > > > leaf multiple-enumerations-test-1 { > > > > type union { > > > > type enumeration { > > > > enum "Monday" { value 0; } > > > > enum "Tuesday" { value 1; } > > > > enum "Wednesday" { value 2; } > > > > enum "Thursday" { value 3; } > > > > enum "Friday" { value 4; } > > > > > > > > } > > > > type enumeration { > > > > enum "Saturday" { value 5; } > > > > enum "Sunday" { value 6; } > > > > } > > > > } > > > > } > > > > > > > > leaf multiple-bits-test-1 { > > > > type union { > > > > type bits { > > > > bit "Monday" { position 0; } > > > > bit "Tuesday" { position 1; } > > > > bit "Wednesday" { position 2; } > > > > bit "Thursday" { position 3; } > > > > bit "Friday" { position 4; } > > > > > > > > } > > > > type bits { > > > > bit "Saturday" { position 5; } > > > > bit "Sunday" { position 6; } > > > > } > > > > } > > > > } > > > > > > > > When using already defined typedef, avoiding overlap is less obvious > > without > > > > some help. > > > > To help building unions with already defined typedefs, I propose to > > > > introduce two extensions. > > > > > > > > extension value-offset { > > > > argument offset { > > > > yin-element true; > > > > } > > > > description > > > > "Offset added to each enum value of the associated enumeration."; > > > > } > > > > > > > > extension position-offset { > > > > argument offset { > > > > yin-element true; > > > > } > > > > description > > > > "Offset value added to each bit position of the associated bits."; > > > > } > > > > > > > > The value-offset extension can be used as follow: > > > > > > > > type enumeration { > > > > enum "Monday"; > > > > enum "Tuesday"; > > > > enum "Wednesday"; > > > > enum "Thursday"; > > > > enum "Friday"; > > > > } > > > > } > > > > > > > > typedef weekend { > > > > type enumeration { > > > > enum "Saturday"; > > > > enum "Sunday"; > > > > } > > > > } > > > > > > > > leaf multiple-enumerations-test-3 { > > > > type union { > > > > type weekdays; > > > > type weekend { > > > > ext:value-offset 5; > > > > } > > > > } > > > > } > > > > > > > > The position-offset extension can be used as follow: > > > > > > > > typedef weekdays-flags { > > > > type bits { > > > > bit "Monday"; > > > > bit "Tuesday"; > > > > bit "Wednesday"; > > > > bit "Thursday"; > > > > bit "Friday"; > > > > } > > > > } > > > > > > > > typedef weekend-flags { > > > > type bits { > > > > bit "Saturday"; > > > > bit "Sunday"; > > > > } > > > > } > > > > > > > > leaf multiple-bits-test-3 { > > > > type union { > > > > type weekdays-flags; > > > > type weekend-flags { > > > > ext:position-offset 5; > > > > } > > > > } > > > > } > > > > > > > > The yang file in attachment show different examples based on this > > approach. > > > > This module have been validated using > > http://www.yangvalidator.com/validator > > > > > > > > If this approach is accepted, tools like pyang should be updated to > > produce > > > > an error if multiple enumerations or bits are defined with value or > > position > > > > overleaps. > > > > > > > > Please comment, > > > > Michel > > > > > > > > -----Original Message----- > > > > From: Ladislav Lhotka > > > > Sent: Monday, March 25, 2019 4:07 AM > > > > To: Juergen Schoenwaelder ; > > Carsten > > > > Bormann > > > > Cc: Michel Veillette ; netconf@ietf.org; > > > > > > core@ietf.org > > > > Subject: Re: [netconf] YANG encoding in CBOR > > > > > > > > Juergen Schoenwaelder writes: > > > > > > > > > I think we need to look at the whole picture and in which direction > > we > > > > > want to go. In the longer term, I would prefer a solution where the > > > > > values of a union are discriminated. The current XML encoding > > > > > behaviour of 'first match wins' is fragile (for example, if someone > > > > > adds an enum to a type, the interpretation of data can change). > > > > > > > > > > Look at this: > > > > > > > > > > typedef bar { > > > > > type union { > > > > > type enumeration { enum "1"; value 2; enum "2"; value 1; } > > > > > type uint8; > > > > > } > > > > > } > > > > > > > > > > We have some encodings that send the string representations of the > > > > > values and some encodings that prefer to send numeric representations > > > > > where possible. In order to have a robust solution, encodings should > > > > > likely indicate to which type the value belongs. > > > > > > > > Perhaps the easiest way would be to use (optional) annotation that > > > > specifies, using an ordinal number, which of the member types is used > > for > > > > the particular instance. But since there can be unions inside unions, a > > list > > > > of numbers would be needed in general. > > > > > > > > Lada > > > > > > > > > /js > > > > > > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > > > > > > Well, if that is a problem, we can go for a longer representation > > within > > > > > > unions (section 6.12). Theoretically, we could do that only of > > there is > > > > > > more than one enum in the union type (so things stay efficient if > > there > > > > > > is only one), but that might pose difficulties with model evolution. > > > > > > > > > > > > Going for a string representation repeats the feature of XML YANG > > (which > > > > > > was ported over to JSON YANG): > > > > > > > > > > > > typedef foo { > > > > > > type union { > > > > > > type enumeration { > > > > > > enum red { value 1; } > > > > > > enum breen { value 2; } > > > > > > enum glue { value 3; } > > > > > > } > > > > > > type enumeration { > > > > > > enum tacks { value 1; } > > > > > > enum nails { value 2; } > > > > > > enum glue { value 3; } > > > > > > } > > > > > > } > > > > > > } > > > > > > > > > > > > If you use “glue”, you don’t know which of the enumerations are > > being > > > > > > used. > > > > > > > > > > > > Using SIDs, we can do better. > > > > > > > > > > > > So what do we have to do to get the SID tool to allocate SIDs for > > enum > > > > > > values? > > > > > > > > > > > > We could then define the CBOR tag for enums in unions to take the > > usual > > > > > > SID difference (delta relative to the environment, I’d think), not > > an > > > > > > integer value. > > > > > > > > > > > > Several of us are at the hackathon and could make something happen > > today > > > > > > and tomorrow. > > > > > > > > > > > > Grüße, Carsten > > > > > > > > > > > > > > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) > > > > > > > > > wrote: > > > > > > > > > > > > > > I guess that the concern is that this introduces more variation in > > how > > > > > > > data is interpreted between the different XML/JSON/CBOR encodings. > > > > > > > > > > > > > > E.g. if someone switched from XML to CBOR, suddenly the > > configuration > > > > > > > or state data may have a different meaning. > > > > > > > > > > > > > > Thanks, > > > > > > > Rob > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Carsten Bormann > > > > > > > > Sent: 22 March 2019 16:08 > > > > > > > > To: Michel Veillette > > > > > > > > Cc: Rob Wilton (rwilton) ; core@ietf.org; > > > > > > > > netconf@ietf.org > > > > > > > > Subject: Re: [netconf] YANG encoding in CBOR > > > > > > > > > > > > > > > > On Mar 22, 2019, at 16:45, Michel Veillette > > > > > > > > > > > > > > > > wrote: > > > > > > > > > The only potential problem I aware is when multiple > > enumerations > > > > > > > > > are part of > > > > > > > > the same union. > > > > > > > > > Value 4 from enumeration A will be encoded the same way as > > Value > > > > > > > > > 4 from > > > > > > > > enumeration B. > > > > > > > > > > > > > > > > … and that is not a problem for the XML version, because the > > > > > > > > string is being used instead of the value. (But then if two > > > > > > > > enumerations share a string, you have the equivalent problem in > > > > > > > > the XML serialization.) > > > > > > > > > > > > > > > > Anyway, I haven’t seen a piece of real-world YANG that actually > > > > > > > > has this problem, so I would be a bit reluctant to make CBOR- > > based > > > > > > > > implementations more complex (and less efficient) so solve this > > > > > > > > (non-?)problem. > > > > > > > > > > > > > > > > Grüße, Carsten > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > netconf mailing list > > > > > > netconf@ietf.org > > > > > > > > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > > > > > > > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=02%7C01%7C%7C343ea8 > > > > > > > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1 > > > > > > > > %7C636890980182553400&sdata=u1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0 > > > > > > kvPZgr4o%3D&reserved=0 > > > > > > > > > > -- > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > > Fax: +49 421 200 3103 < > > > > > > > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jacobs-university.de%2F&data=02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&sdata=TrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > > > > > > Well, if that is a problem, we can go for a longer representation > > within > > > > > > unions (section 6.12). Theoretically, we could do that only of > > there is > > > > > > more than one enum in the union type (so things stay efficient if > > there > > > > > > is only one), but that might pose difficulties with model evolution. > > > > > > > > > > > > Going for a string representation repeats the feature of XML YANG > > (which > > > > > > was ported over to JSON YANG): > > > > > > > > > > > > typedef foo { > > > > > > type union { > > > > > > type enumeration { > > > > > > enum red { value 1; } > > > > > > enum breen { value 2; } > > > > > > enum glue { value 3; } > > > > > > } > > > > > > type enumeration { > > > > > > enum tacks { value 1; } > > > > > > enum nails { value 2; } > > > > > > enum glue { value 3; } > > > > > > } > > > > > > } > > > > > > } > > > > > > > > > > > > If you use “glue”, you don’t know which of the enumerations are > > being > > > > > > used. > > > > > > > > > > > > Using SIDs, we can do better. > > > > > > > > > > > > So what do we have to do to get the SID tool to allocate SIDs for > > enum > > > > > > values? > > > > > > > > > > > > We could then define the CBOR tag for enums in unions to take the > > usual > > > > > > SID difference (delta relative to the environment, I’d think), not > > an > > > > > > integer value. > > > > > > > > > > > > Several of us are at the hackathon and could make something happen > > today > > > > > > and tomorrow. > > > > > > > > > > > > Grüße, Carsten > > > > > > > > > > > > > > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) > > > > > > > > > wrote: > > > > > > > > > > > > > > I guess that the concern is that this introduces more variation in > > how > > > > > > > data is interpreted between the different XML/JSON/CBOR encodings. > > > > > > > > > > > > > > E.g. if someone switched from XML to CBOR, suddenly the > > configuration > > > > > > > or state data may have a different meaning. > > > > > > > > > > > > > > Thanks, > > > > > > > Rob > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Carsten Bormann > > > > > > > > Sent: 22 March 2019 16:08 > > > > > > > > To: Michel Veillette > > > > > > > > Cc: Rob Wilton (rwilton) ; core@ietf.org; > > > > > > > > netconf@ietf.org > > > > > > > > Subject: Re: [netconf] YANG encoding in CBOR > > > > > > > > > > > > > > > > On Mar 22, 2019, at 16:45, Michel Veillette > > > > > > > > > > > > > > > > wrote: > > > > > > > > > The only potential problem I aware is when multiple > > enumerations > > > > > > > > > are part of > > > > > > > > the same union. > > > > > > > > > Value 4 from enumeration A will be encoded the same way as > > Value > > > > > > > > > 4 from > > > > > > > > enumeration B. > > > > > > > > > > > > > > > > … and that is not a problem for the XML version, because the > > > > > > > > string is being used instead of the value. (But then if two > > > > > > > > enumerations share a string, you have the equivalent problem in > > > > > > > > the XML serialization.) > > > > > > > > > > > > > > > > Anyway, I haven’t seen a piece of real-world YANG that actually > > > > > > > > has this problem, so I would be a bit reluctant to make CBOR- > > based > > > > > > > > implementations more complex (and less efficient) so solve this > > > > > > > > (non-?)problem. > > > > > > > > > > > > > > > > Grüße, Carsten > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > netconf mailing list > > > > > > netconf@ietf.org > > > > > > > > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > > > > > > > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=02%7C01%7C%7C343ea8 > > > > > > > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1 > > > > > > > > %7C636890980182553400&sdata=u1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0 > > > > > > kvPZgr4o%3D&reserved=0 > > > > > > > > > > -- > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > > Fax: +49 421 200 3103 < > > > > > > > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jacobs-university.de%2F&data=02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&sdata=TrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&reserved=0 > > > > > > > > > > > > > > > > _______________________________________________ > > > > > netconf mailing list > > > > > netconf@ietf.org > > > > > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > > > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=02%7C01%7C%7C343ea8d1 > > > > > cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C > > > > > 636890980182553400&sdata=u1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0kvPZ > > > > > gr4o%3D&reserved=0 > > > > > > > > -- > > > > Ladislav Lhotka > > > > Head, CZ.NIC Labs > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Mar 27 13:12:05 2019 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 DB25E120407 for ; Wed, 27 Mar 2019 13:11:53 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 frLvQkGvrcId for ; Wed, 27 Mar 2019 13:11:47 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 9DFB212037C for ; Wed, 27 Mar 2019 13:11:46 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id v22so15560075lje.9 for ; Wed, 27 Mar 2019 13:11:46 -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=90TeAK73HHjK9UBzuuhwpkeMXOKnEbcWq+6rGTaEsbQ=; b=QgweE4TrTuQUMPDcqQyVe+3a77my0gT+C9OQsQGwGA7WRHOc72RAd9+oEZAMUkXseO 6misLk3o3CBtvBc03PPneK4DA34WsAulKcZYZEEKgOovr+W9hob2VMU4gyM/oIuc6B65 mbyK64mDK2p4DV++lakKIWdW2RYOO9Z/FTNi9XTPwIbDhsC0AKdJP0P2fEfvbiznqORb dqALb/Q+qsq+4mYT1P1LHY4GCQ37H8YPperJAgSOdMO3OpiPEsFq5KFkPnUaQw+SYIvk 8kHsBJiJeFbCe88XCDwiNrFqZPcNzo6Wesx5nv8K5sbQFfFWvG461dPABFjN2Ir8btS8 ZgTw== 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=90TeAK73HHjK9UBzuuhwpkeMXOKnEbcWq+6rGTaEsbQ=; b=Szshjr0IFeyQA8jR8G8dBlsEkQOiUym3mDEDM32emkemIBzLPOpsSiF8yIko7/y8Dd RySZOupG3PG/YfIid/wEAsOsYa1Cti2I9bxcHCcEa/NFB/vpVV48yM0Kq7UZn+8jDevK sZpmyzlU0YFbiLdkLtOq9OcDtJHkTPSpn2EU7uJjjhQoI0mnc9wvDOxoRVCE3xWDA+VV Tv/zhG0NEe4msuxHGHr4wp+5c4CqrR6w1QKlT/ZQQlF060d/kJq8bKtp6RuzpxOc1m0C c8h0QonoMJv7uL0M/natju/F6Wt10TGXqz0grHJqvYxFmPTDxmgr6LmHuIWbBy1/HJ8a iHLg== X-Gm-Message-State: APjAAAUI/hv0fr0P/5K+jtXKxSygbpDTTzLmaxjD7vrYc/EbH59AN00w l4j+jByxFDw7Fidbqrnpe2rfWQ7P0HyPY6w51ALcpQ== X-Google-Smtp-Source: APXvYqw5ulRlB4x7JVZxYDqkw8S0X3B+fZhXRQYDFzXfu8hzVne+gBKUiW4CozzCyvfBuS/DcMH3SDkhL453hhvLbto= X-Received: by 2002:a2e:844a:: with SMTP id u10mr9295158ljh.41.1553717504655; Wed, 27 Mar 2019 13:11:44 -0700 (PDT) MIME-Version: 1.0 References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <1f8b326e0e05b400457b9446d52a7b0f6c90e05b.camel@nic.cz> In-Reply-To: From: Andy Bierman Date: Wed, 27 Mar 2019 13:11:33 -0700 Message-ID: To: Ladislav Lhotka Cc: Juergen Schoenwaelder , Michel Veillette , "netconf@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f2603d0585190b7c" Archived-At: Subject: Re: [netconf] [core] YANG encoding in CBOR 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, 27 Mar 2019 20:11:58 -0000 --000000000000f2603d0585190b7c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 27, 2019 at 12:54 PM Ladislav Lhotka wrote: > Andy Bierman p=C3=AD=C5=A1e v St 27. 03. 2019 v 09:13 -0700: > > > > > > On Wed, Mar 27, 2019 at 1:40 AM Ladislav Lhotka wrote: > > > On Wed, 2019-03-27 at 07:16 +0100, Juergen Schoenwaelder wrote: > > > > Hi, > > > > > > > > a union can be formed by using member types that are imported and n= ot > > > > under change control of a single author/organization and ideally th= is > > > > should work without complex coordination of name and number spaces. > > > > Duplicate enum/bits values are legal in YANG today so an encoding h= as > > > > to deal with this aspect of life. > > > > > > > > A robust fix to all these problems will be to tag the type members = in > > > > order to discriminate the values in the encodings. This, however, > will > > > > take some time to specify and we will need to preserve backwards > > > > compatibility with unions without a tag (but compilers can encourag= e > > > > people to add tags whenever modules are updated). > > > > > > I already opened a new issue for this in yang-next: > > > > > > https://github.com/netmod-wg/yang-next/issues/72 > > > > > > > We already explored the solution of giving the member types numbers > > so they could be used in CBOR but this was rejected because it is so > complex > > to implement. > > I don't think it is too complex. Get the type in the schema, get the > member, > that's all. It is much easier and more robust than the current algorithm. > > no it isn't easier because the algorithm is error-prone. Renumbering un-named types nested within unions and referenced named types over many revisions of the module is not easy. The encoding MUST NOT change EVER -- even if the union type is expanded. > > > > Consider when union is within union, and the types are named types from > > Union within union is no problem: it jut requires a sequence of numbers. > > do not agree since the union can have a member type added > > other modules. Union types can be legally updated in new versions of th= e > > module, > > Again, I don't agree. Sec. 11 in RFC 7950 says: > > o A "type" statement may be replaced with another "type" statement > that does not change the syntax or semantics of the type. > ... > > type uint32 { range "1..8"; } I can refactor that into 2 types (1..4 and 5..8) This does not change the semantics of the union type but it adds a member type Other refactoring is possible that will also change the number of member types. Also, deviations do not follow this rule > Adding a new member clearly changes the semantics of the type, if not > syntax. > > no it doesn't always change the semantics > > but the position assignments for SID can never change. > > The annotation would also help resolve the differences between JSON and > XML. SID > is only available in CBOR. > > > > > Even without this complexity this solution would cause the > encoder/decoder to > > be very schema-aware. > > The current method of resolving unions is totally schema-aware (somewhat > less so > in JSON). > > No -- it just needs to know string vs. number. Not schema aware at all. > Lada > > Andy > > > > > > BTW, creating SIDs for enums and bits will break if the server uses > 'deviate > > replace type'. > > There is no way to number the deviated type since this is > server-specific not > > part of the original module > > and the deviation is not actually a data-def-stmt. > > > > > > > Lada > > > > > > > Andy > > > > > > > > > > /js > > > > > > > > On Wed, Mar 27, 2019 at 01:12:52AM +0000, Michel Veillette wrote: > > > > > Hi Ladislav > > > > > > > > > > If I summarize this issue of multiple enumerations or bits in a > union, > > > this > > > > > problem can be solve by the following approaches: > > > > > > > > > > - To not allows these duplicate values or positions to happen in > YANG > > > > > - To encode enumerations and bits as string (in all unions or onl= y > when > > > > > multiple enumerations or bits are defined) > > > > > - To encode enumerations and bits as SID (in all unions or only > when > > > > > multiple enumerations or bits are defined) > > > > > - To encode enumerations and bits as delta between the value SID > and the > > > > > leaf SID (in all unions or only when multiple enumerations or bit= s > are > > > > > defined) > > > > > > > > > > In this email, I will like to focus on the first option, fixing t= he > > > problem > > > > > directly in YANG instead of fixing the consequences. > > > > > > > > > > Without any changes in YANG, a union with multiple enumeration or > bits > > > can > > > > > be constructed without value or position overlaps. > > > > > For example: > > > > > > > > > > leaf multiple-enumerations-test-1 { > > > > > type union { > > > > > type enumeration { > > > > > enum "Monday" { value 0; } > > > > > enum "Tuesday" { value 1; } > > > > > enum "Wednesday" { value 2; } > > > > > enum "Thursday" { value 3; } > > > > > enum "Friday" { value 4; } > > > > > > > > > > } > > > > > type enumeration { > > > > > enum "Saturday" { value 5; } > > > > > enum "Sunday" { value 6; } > > > > > } > > > > > } > > > > > } > > > > > > > > > > leaf multiple-bits-test-1 { > > > > > type union { > > > > > type bits { > > > > > bit "Monday" { position 0; } > > > > > bit "Tuesday" { position 1; } > > > > > bit "Wednesday" { position 2; } > > > > > bit "Thursday" { position 3; } > > > > > bit "Friday" { position 4; } > > > > > > > > > > } > > > > > type bits { > > > > > bit "Saturday" { position 5; } > > > > > bit "Sunday" { position 6; } > > > > > } > > > > > } > > > > > } > > > > > > > > > > When using already defined typedef, avoiding overlap is less > obvious > > > without > > > > > some help. > > > > > To help building unions with already defined typedefs, I propose = to > > > > > introduce two extensions. > > > > > > > > > > extension value-offset { > > > > > argument offset { > > > > > yin-element true; > > > > > } > > > > > description > > > > > "Offset added to each enum value of the associated > enumeration."; > > > > > } > > > > > > > > > > extension position-offset { > > > > > argument offset { > > > > > yin-element true; > > > > > } > > > > > description > > > > > "Offset value added to each bit position of the associated > bits."; > > > > > } > > > > > > > > > > The value-offset extension can be used as follow: > > > > > > > > > > type enumeration { > > > > > enum "Monday"; > > > > > enum "Tuesday"; > > > > > enum "Wednesday"; > > > > > enum "Thursday"; > > > > > enum "Friday"; > > > > > } > > > > > } > > > > > > > > > > typedef weekend { > > > > > type enumeration { > > > > > enum "Saturday"; > > > > > enum "Sunday"; > > > > > } > > > > > } > > > > > > > > > > leaf multiple-enumerations-test-3 { > > > > > type union { > > > > > type weekdays; > > > > > type weekend { > > > > > ext:value-offset 5; > > > > > } > > > > > } > > > > > } > > > > > > > > > > The position-offset extension can be used as follow: > > > > > > > > > > typedef weekdays-flags { > > > > > type bits { > > > > > bit "Monday"; > > > > > bit "Tuesday"; > > > > > bit "Wednesday"; > > > > > bit "Thursday"; > > > > > bit "Friday"; > > > > > } > > > > > } > > > > > > > > > > typedef weekend-flags { > > > > > type bits { > > > > > bit "Saturday"; > > > > > bit "Sunday"; > > > > > } > > > > > } > > > > > > > > > > leaf multiple-bits-test-3 { > > > > > type union { > > > > > type weekdays-flags; > > > > > type weekend-flags { > > > > > ext:position-offset 5; > > > > > } > > > > > } > > > > > } > > > > > > > > > > The yang file in attachment show different examples based on this > > > approach. > > > > > This module have been validated using > > > http://www.yangvalidator.com/validator > > > > > > > > > > If this approach is accepted, tools like pyang should be updated = to > > > produce > > > > > an error if multiple enumerations or bits are defined with value = or > > > position > > > > > overleaps. > > > > > > > > > > Please comment, > > > > > Michel > > > > > > > > > > -----Original Message----- > > > > > From: Ladislav Lhotka > > > > > Sent: Monday, March 25, 2019 4:07 AM > > > > > To: Juergen Schoenwaelder ; > > > Carsten > > > > > Bormann > > > > > Cc: Michel Veillette ; > netconf@ietf.org; > > > > > > > > core@ietf.org > > > > > Subject: Re: [netconf] YANG encoding in CBOR > > > > > > > > > > Juergen Schoenwaelder > writes: > > > > > > > > > > > I think we need to look at the whole picture and in which > direction > > > we > > > > > > want to go. In the longer term, I would prefer a solution where > the > > > > > > values of a union are discriminated. The current XML encoding > > > > > > behaviour of 'first match wins' is fragile (for example, if > someone > > > > > > adds an enum to a type, the interpretation of data can change). > > > > > > > > > > > > Look at this: > > > > > > > > > > > > typedef bar { > > > > > > type union { > > > > > > type enumeration { enum "1"; value 2; enum "2"; value 1; } > > > > > > type uint8; > > > > > > } > > > > > > } > > > > > > > > > > > > We have some encodings that send the string representations of > the > > > > > > values and some encodings that prefer to send numeric > representations > > > > > > where possible. In order to have a robust solution, encodings > should > > > > > > likely indicate to which type the value belongs. > > > > > > > > > > Perhaps the easiest way would be to use (optional) annotation tha= t > > > > > specifies, using an ordinal number, which of the member types is > used > > > for > > > > > the particular instance. But since there can be unions inside > unions, a > > > list > > > > > of numbers would be needed in general. > > > > > > > > > > Lada > > > > > > > > > > > /js > > > > > > > > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote= : > > > > > > > Well, if that is a problem, we can go for a longer > representation > > > within > > > > > > > unions (section 6.12). Theoretically, we could do that only = of > > > there is > > > > > > > more than one enum in the union type (so things stay efficien= t > if > > > there > > > > > > > is only one), but that might pose difficulties with model > evolution. > > > > > > > > > > > > > > Going for a string representation repeats the feature of XML > YANG > > > (which > > > > > > > was ported over to JSON YANG): > > > > > > > > > > > > > > typedef foo { > > > > > > > type union { > > > > > > > type enumeration { > > > > > > > enum red { value 1; } > > > > > > > enum breen { value 2; } > > > > > > > enum glue { value 3; } > > > > > > > } > > > > > > > type enumeration { > > > > > > > enum tacks { value 1; } > > > > > > > enum nails { value 2; } > > > > > > > enum glue { value 3; } > > > > > > > } > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know whi= ch of the enumerations are > > > being > > > > > > > used. > > > > > > > > > > > > > > Using SIDs, we can do better. > > > > > > > > > > > > > > So what do we have to do to get the SID tool to allocate SIDs > for > > > enum > > > > > > > values? > > > > > > > > > > > > > > We could then define the CBOR tag for enums in unions to take > the > > > usual > > > > > > > SID difference (delta relative to the environment, I=E2=80=99= d think), > not > > > an > > > > > > > integer value. > > > > > > > > > > > > > > Several of us are at the hackathon and could make something > happen > > > today > > > > > > > and tomorrow. > > > > > > > > > > > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > > > > > > > > > > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) < > rwilton@cisco.com > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > I guess that the concern is that this introduces more > variation in > > > how > > > > > > > > data is interpreted between the different XML/JSON/CBOR > encodings. > > > > > > > > > > > > > > > > E.g. if someone switched from XML to CBOR, suddenly the > > > configuration > > > > > > > > or state data may have a different meaning. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Rob > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Carsten Bormann > > > > > > > > > Sent: 22 March 2019 16:08 > > > > > > > > > To: Michel Veillette > > > > > > > > > Cc: Rob Wilton (rwilton) ; > core@ietf.org; > > > > > > > > > netconf@ietf.org > > > > > > > > > Subject: Re: [netconf] YANG encoding in CBOR > > > > > > > > > > > > > > > > > > On Mar 22, 2019, at 16:45, Michel Veillette > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > The only potential problem I aware is when multiple > > > enumerations > > > > > > > > > > are part of > > > > > > > > > the same union. > > > > > > > > > > Value 4 from enumeration A will be encoded the same way > as > > > Value > > > > > > > > > > 4 from > > > > > > > > > enumeration B. > > > > > > > > > > > > > > > > > > =E2=80=A6 and that is not a problem for the XML version, = because > the > > > > > > > > > string is being used instead of the value. (But then if > two > > > > > > > > > enumerations share a string, you have the equivalent > problem in > > > > > > > > > the XML serialization.) > > > > > > > > > > > > > > > > > > Anyway, I haven=E2=80=99t seen a piece of real-world YANG= that > actually > > > > > > > > > has this problem, so I would be a bit reluctant to make > CBOR- > > > based > > > > > > > > > implementations more complex (and less efficient) so solv= e > this > > > > > > > > > (non-?)problem. > > > > > > > > > > > > > > > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > netconf mailing list > > > > > > > netconf@ietf.org > > > > > > > > > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww > > > > > > > > > > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343e= a8 > > > > > > > > > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1 > > > > > > > > > > %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2= B0 > > > > > > > kvPZgr4o%3D&reserved=3D0 > > > > > > > > > > > > -- > > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > > > > Fax: +49 421 200 3103 < > > > > > > > > > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.j= acobs-university.de%2F&data=3D02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8= d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&sd= ata=3DTrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&reserved=3D0 > > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote= : > > > > > > > Well, if that is a problem, we can go for a longer > representation > > > within > > > > > > > unions (section 6.12). Theoretically, we could do that only = of > > > there is > > > > > > > more than one enum in the union type (so things stay efficien= t > if > > > there > > > > > > > is only one), but that might pose difficulties with model > evolution. > > > > > > > > > > > > > > Going for a string representation repeats the feature of XML > YANG > > > (which > > > > > > > was ported over to JSON YANG): > > > > > > > > > > > > > > typedef foo { > > > > > > > type union { > > > > > > > type enumeration { > > > > > > > enum red { value 1; } > > > > > > > enum breen { value 2; } > > > > > > > enum glue { value 3; } > > > > > > > } > > > > > > > type enumeration { > > > > > > > enum tacks { value 1; } > > > > > > > enum nails { value 2; } > > > > > > > enum glue { value 3; } > > > > > > > } > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know whi= ch of the enumerations are > > > being > > > > > > > used. > > > > > > > > > > > > > > Using SIDs, we can do better. > > > > > > > > > > > > > > So what do we have to do to get the SID tool to allocate SIDs > for > > > enum > > > > > > > values? > > > > > > > > > > > > > > We could then define the CBOR tag for enums in unions to take > the > > > usual > > > > > > > SID difference (delta relative to the environment, I=E2=80=99= d think), > not > > > an > > > > > > > integer value. > > > > > > > > > > > > > > Several of us are at the hackathon and could make something > happen > > > today > > > > > > > and tomorrow. > > > > > > > > > > > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > > > > > > > > > > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) < > rwilton@cisco.com > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > I guess that the concern is that this introduces more > variation in > > > how > > > > > > > > data is interpreted between the different XML/JSON/CBOR > encodings. > > > > > > > > > > > > > > > > E.g. if someone switched from XML to CBOR, suddenly the > > > configuration > > > > > > > > or state data may have a different meaning. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Rob > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Carsten Bormann > > > > > > > > > Sent: 22 March 2019 16:08 > > > > > > > > > To: Michel Veillette > > > > > > > > > Cc: Rob Wilton (rwilton) ; > core@ietf.org; > > > > > > > > > netconf@ietf.org > > > > > > > > > Subject: Re: [netconf] YANG encoding in CBOR > > > > > > > > > > > > > > > > > > On Mar 22, 2019, at 16:45, Michel Veillette > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > The only potential problem I aware is when multiple > > > enumerations > > > > > > > > > > are part of > > > > > > > > > the same union. > > > > > > > > > > Value 4 from enumeration A will be encoded the same way > as > > > Value > > > > > > > > > > 4 from > > > > > > > > > enumeration B. > > > > > > > > > > > > > > > > > > =E2=80=A6 and that is not a problem for the XML version, = because > the > > > > > > > > > string is being used instead of the value. (But then if > two > > > > > > > > > enumerations share a string, you have the equivalent > problem in > > > > > > > > > the XML serialization.) > > > > > > > > > > > > > > > > > > Anyway, I haven=E2=80=99t seen a piece of real-world YANG= that > actually > > > > > > > > > has this problem, so I would be a bit reluctant to make > CBOR- > > > based > > > > > > > > > implementations more complex (and less efficient) so solv= e > this > > > > > > > > > (non-?)problem. > > > > > > > > > > > > > > > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > netconf mailing list > > > > > > > netconf@ietf.org > > > > > > > > > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww > > > > > > > > > > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343e= a8 > > > > > > > > > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1 > > > > > > > > > > %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2= B0 > > > > > > > kvPZgr4o%3D&reserved=3D0 > > > > > > > > > > > > -- > > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > > > > Fax: +49 421 200 3103 < > > > > > > > > > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.j= acobs-university.de%2F&data=3D02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8= d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&sd= ata=3DTrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&reserved=3D0 > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > netconf mailing list > > > > > > netconf@ietf.org > > > > > > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > > > > > > ietf.org > %2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343ea8d1 > > > > > > > cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C > > > > > > > 636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0kvPZ > > > > > > gr4o%3D&reserved=3D0 > > > > > > > > > > -- > > > > > Ladislav Lhotka > > > > > Head, CZ.NIC Labs > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > --000000000000f2603d0585190b7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 27, 2019 at 12:54 PM Ladi= slav Lhotka <lhotka@nic.cz> wrot= e:
Andy Bierman = p=C3=AD=C5=A1e v St 27. 03. 2019 v 09:13 -0700:
>
>
> On Wed, Mar 27, 2019 at 1:40 AM Ladislav Lhotka <lhotka@nic.cz> wrote:
> > On Wed, 2019-03-27 at 07:16 +0100, Juergen Schoenwaelder wrote: > > > Hi,
> > >
> > > a union can be formed by using member types that are importe= d and not
> > > under change control of a single author/organization and ide= ally this
> > > should work without complex coordination of name and number = spaces.
> > > Duplicate enum/bits values are legal in YANG today so an enc= oding has
> > > to deal with this aspect of life.
> > >
> > > A robust fix to all these problems will be to tag the type m= embers in
> > > order to discriminate the values in the encodings. This, how= ever, will
> > > take some time to specify and we will need to preserve backw= ards
> > > compatibility with unions without a tag (but compilers can e= ncourage
> > > people to add tags whenever modules are updated).
> >
> > I already opened a new issue for this in yang-next:
> >
> > https://github.com/netmod-wg/yang-next/is= sues/72
> >
>
> We already explored the solution of giving the member types numbers > so they could be used in CBOR but this was rejected because it is so c= omplex
> to implement.

I don't think it is too complex. Get the type in the schema, get the me= mber,
that's all. It is much easier and more robust than the current algorith= m.


no it isn't easier because the alg= orithm is error-prone.
Renumbering un-named types nested within u= nions and referenced named types
over many revisions of the modul= e is not easy.
The encoding MUST NOT change EVER -- even if the u= nion type is expanded.
=C2=A0
>
> Consider when union is within union, and the types are named types fro= m

Union within union is no problem: it jut requires a sequence of numbers.

do not agree since the union can have = a member type added

=C2=A0
> other modules. Union types can be legally updated in new versions of t= he
> module,

Again, I don't agree. Sec. 11 in RFC 7950 says:

=C2=A0 =C2=A0o=C2=A0 A "type" statement may be replaced with anot= her "type" statement
=C2=A0 =C2=A0 =C2=A0 that does not change the syntax or semantics of the ty= pe.
=C2=A0 =C2=A0 =C2=A0 ...



=C2=A0 =C2=A0type uint3= 2 { range "1..8"; }

I can refactor that = into 2 types (1..4 and 5..8)
This does not change the semantics o= f the union type but it adds a member type
Other refactoring is p= ossible that will also change the number of member types.

Also, deviations do not follow this rule

= =C2=A0
Adding a new member clearly changes the semantics of the type, if not synta= x.


no it doesn't always change the se= mantics

=C2=A0
> but the position assignments for SID can never change.

The annotation would also help resolve the differences between JSON and XML= . SID
is only available in CBOR.

>
> Even without this complexity this solution would cause the encoder/dec= oder to
> be very schema-aware.

The current method of resolving unions is totally schema-aware (somewhat le= ss so
in JSON).


No -- it just needs to know string vs.= number.
Not schema aware at all.
=C2=A0
Lada


Andy
=C2=A0
>=C2=A0
>
> BTW, creating SIDs for enums and bits will break if the server uses &#= 39;deviate
> replace type'.
> There is no way to number the deviated type since this is server-speci= fic not
> part of the original module
> and the deviation is not actually a data-def-stmt.
>
>
> > Lada
> >
>
> Andy
>=C2=A0
> > >
> > > /js
> > >
> > > On Wed, Mar 27, 2019 at 01:12:52AM +0000, Michel Veillette w= rote:
> > > > Hi Ladislav
> > > >
> > > > If I summarize this issue of multiple enumerations or b= its in a union,
> > this
> > > > problem can be solve by the following approaches:
> > > >
> > > > - To not allows these duplicate values or positions to = happen in YANG
> > > > - To encode enumerations and bits as string (in all uni= ons or only when
> > > > multiple enumerations or bits are defined)
> > > > - To encode enumerations and bits as SID (in all unions= or only when
> > > > multiple enumerations or bits are defined)
> > > > - To encode enumerations and bits as delta between the = value SID and the
> > > > leaf SID (in all unions or only when multiple enumerati= ons or bits are
> > > > defined)
> > > >
> > > > In this email, I will like to focus on the first option= , fixing the
> > problem
> > > > directly in YANG instead of fixing the consequences. > > > >
> > > > Without any changes in YANG, a union with multiple enum= eration or bits
> > can
> > > > be constructed without value or position overlaps.
> > > > For example:
> > > >
> > > >=C2=A0 =C2=A0leaf multiple-enumerations-test-1 {
> > > >=C2=A0 =C2=A0 =C2=A0type union {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0type enumeration {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Monday"= ; { value 0; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Tuesday&quo= t; { value 1; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Wednesday&q= uot; { value 2; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Thursday&qu= ot; { value 3; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Friday"= ; { value 4; }
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0type enumeration {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Saturday&qu= ot; { value 5; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Sunday"= ; { value 6; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > >
> > > >=C2=A0 =C2=A0leaf multiple-bits-test-1 {
> > > >=C2=A0 =C2=A0 =C2=A0type union {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0type bits {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit=C2=A0 "Monday= " { position=C2=A0 0; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Tuesday"= ; { position=C2=A0 1; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Wednesday&qu= ot; { position=C2=A0 2; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Thursday&quo= t; { position=C2=A0 3; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Friday"= { position=C2=A0 4; }
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0type bits {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Saturday&quo= t; { position 5; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Sunday"= { position 6; }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > >
> > > > When using already defined typedef, avoiding overlap is= less obvious
> > without
> > > > some help.
> > > > To help building unions with already defined typedefs, = I propose to
> > > > introduce two extensions.
> > > >
> > > >=C2=A0 =C2=A0extension value-offset {
> > > >=C2=A0 =C2=A0 =C2=A0argument offset {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0yin-element true;
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0description
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Offset added to each en= um value of the associated enumeration.";
> > > >=C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0
> > > >=C2=A0 =C2=A0extension position-offset {
> > > >=C2=A0 =C2=A0 =C2=A0argument offset {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0yin-element true;
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0description
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Offset value added to e= ach bit position of the associated bits.";
> > > >=C2=A0 =C2=A0}
> > > >
> > > > The value-offset extension can be used as follow:
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0type enumeration {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Monday";
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Tuesday";
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Wednesday"; > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Thursday"; > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Friday";
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > >
> > > >=C2=A0 =C2=A0typedef weekend {
> > > >=C2=A0 =C2=A0 =C2=A0type enumeration {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Saturday"; > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "Sunday";
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0
> > > >=C2=A0 =C2=A0leaf multiple-enumerations-test-3 {
> > > >=C2=A0 =C2=A0 =C2=A0type union {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0type weekdays;
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0type weekend {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ext:value-offset 5; > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > >
> > > > The position-offset extension can be used as follow: > > > >
> > > >=C2=A0 =C2=A0typedef weekdays-flags {
> > > >=C2=A0 =C2=A0 =C2=A0type bits {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Monday";
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Tuesday";
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Wednesday"; > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Thursday";
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Friday";
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > >
> > > >=C2=A0 =C2=A0typedef weekend-flags {
> > > >=C2=A0 =C2=A0 =C2=A0type bits {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Saturday";
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0bit "Sunday";
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0
> > > >=C2=A0 =C2=A0leaf multiple-bits-test-3 {
> > > >=C2=A0 =C2=A0 =C2=A0type union {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0type weekdays-flags;
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0type weekend-flags {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ext:position-offset 5;=
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > >
> > > > The yang file in attachment show different examples bas= ed on this
> > approach.
> > > > This module have been validated using
> > http://www.yangvalidator.com/validator
> > > >=C2=A0
> > > > If this approach is accepted, tools like pyang should b= e updated to
> > produce
> > > > an error if multiple enumerations or bits are defined w= ith value or
> > position
> > > > overleaps.
> > > >
> > > > Please comment,
> > > > Michel
> > > >
> > > > -----Original Message-----
> > > > From: Ladislav Lhotka <lhotka@nic.cz>
> > > > Sent: Monday, March 25, 2019 4:07 AM
> > > > To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-uni= versity.de>;
> > Carsten
> > > > Bormann <cabo@tzi.org>
> > > > Cc: Michel Veillette <Michel.Veillette@trilliant.com>= ;; netconf@ietf.org;
> >=C2=A0
> > > > core= @ietf.org
> > > > Subject: Re: [netconf] YANG encoding in CBOR
> > > >
> > > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-univers= ity.de> writes:
> > > >
> > > > > I think we need to look at the whole picture and i= n which direction
> > we
> > > > > want to go. In the longer term, I would prefer a s= olution where the
> > > > > values of a union are discriminated. The current X= ML encoding
> > > > > behaviour of 'first match wins' is fragile= (for example, if someone
> > > > > adds an enum to a type, the interpretation of data= can change).
> > > > >
> > > > > Look at this:
> > > > >
> > > > > typedef bar {
> > > > >=C2=A0 =C2=A0type union {
> > > > >=C2=A0 =C2=A0 =C2=A0type enumeration { enum "1= "; value 2; enum "2"; value 1; }
> > > > >=C2=A0 =C2=A0 =C2=A0type uint8;
> > > > >=C2=A0 =C2=A0}
> > > > > }
> > > > >
> > > > > We have some encodings that send the string repres= entations of the
> > > > > values and some encodings that prefer to send nume= ric representations
> > > > > where possible. In order to have a robust solution= , encodings should
> > > > > likely indicate to which type the value belongs. > > > >
> > > > Perhaps the easiest way would be to use (optional) anno= tation that
> > > > specifies, using an ordinal number, which of the member= types is used
> > for
> > > > the particular instance. But since there can be unions = inside unions, a
> > list
> > > > of numbers would be needed in general.
> > > >
> > > > Lada
> > > >
> > > > > /js
> > > > >
> > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten = Bormann wrote:
> > > > > > Well, if that is a problem, we can go for a l= onger representation
> > within
> > > > > > unions (section 6.12).=C2=A0 Theoretically, w= e could do that only of
> > there is
> > > > > > more than one enum in the union type (so thin= gs stay efficient if
> > there
> > > > > > is only one), but that might pose difficultie= s with model evolution.
> > > > > >
> > > > > > Going for a string representation repeats the= feature of XML YANG
> > (which
> > > > > > was ported over to JSON YANG):
> > > > > >
> > > > > > typedef foo {
> > > > > >=C2=A0 =C2=A0type union {
> > > > > >=C2=A0 =C2=A0 =C2=A0type enumeration {
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum red { value 1;= }
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum breen { value = 2; }
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum glue { value 3= ; }
> > > > > >=C2=A0 =C2=A0 =C2=A0}
> > > > > >=C2=A0 =C2=A0 =C2=A0type enumeration {
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum tacks { value = 1; }
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum nails { value = 2; }
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum glue { value 3= ; }
> > > > > >=C2=A0 =C2=A0 =C2=A0}
> > > > > >=C2=A0 =C2=A0}
> > > > > > }
> > > > > >
> > > > > > If you use =E2=80=9Cglue=E2=80=9D, you don=E2= =80=99t know which of the enumerations are
> > being
> > > > > > used.
> > > > > >
> > > > > > Using SIDs, we can do better.
> > > > > >
> > > > > > So what do we have to do to get the SID tool = to allocate SIDs for
> > enum
> > > > > > values?
> > > > > >
> > > > > > We could then define the CBOR tag for enums i= n unions to take the
> > usual
> > > > > > SID difference (delta relative to the environ= ment, I=E2=80=99d think), not
> > an
> > > > > > integer value.
> > > > > >
> > > > > > Several of us are at the hackathon and could = make something happen
> > today
> > > > > > and tomorrow.
> > > > > >
> > > > > > Gr=C3=BC=C3=9Fe, Carsten
> > > > > >
> > > > > >
> > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (r= wilton) <rwilton@= cisco.com
> > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > I guess that the concern is that this in= troduces more variation in
> > how
> > > > > > > data is interpreted between the differen= t XML/JSON/CBOR encodings.
> > > > > > >
> > > > > > > E.g. if someone switched from XML to CBO= R, suddenly the
> > configuration
> > > > > > > or state data may have a different meani= ng.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Rob
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Carsten Bormann <cabo@tzi.org>
> > > > > > > > Sent: 22 March 2019 16:08
> > > > > > > > To: Michel Veillette <Michel.Veillette@= trilliant.com>
> > > > > > > > Cc: Rob Wilton (rwilton) <rwilton@cisco.com>;= core@ietf.org;
> > > > > > > > netconf@ietf.org
> > > > > > > > Subject: Re: [netconf] YANG encodin= g in CBOR
> > > > > > > >
> > > > > > > > On Mar 22, 2019, at 16:45, Michel V= eillette
> > > > > > > > <Michel.Veillette@trilliant.com>=
> > > > > > > > wrote:
> > > > > > > > > The only potential problem I a= ware is when multiple
> > enumerations
> > > > > > > > > are part of
> > > > > > > > the same union.
> > > > > > > > > Value 4 from enumeration A wil= l be encoded the same way as
> > Value
> > > > > > > > > 4 from
> > > > > > > > enumeration B.
> > > > > > > >
> > > > > > > > =E2=80=A6 and that is not a problem= for the XML version, because the
> > > > > > > > string is being used instead of the= value.=C2=A0 (But then if two
> > > > > > > > enumerations share a string, you ha= ve the equivalent problem in
> > > > > > > > the XML serialization.)
> > > > > > > >
> > > > > > > > Anyway, I haven=E2=80=99t seen a pi= ece of real-world YANG that actually
> > > > > > > > has this problem, so I would be a b= it reluctant to make CBOR-
> > based
> > > > > > > > implementations more complex (and l= ess efficient) so solve this
> > > > > > > > (non-?)problem.
> > > > > > > >
> > > > > > > > Gr=C3=BC=C3=9Fe, Carsten
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > _____________________________________________= __
> > > > > > netconf mailing list
> > > > > > netconf@ietf.org
> > > > > >
> > https://can01.safel= inks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
> > > > > >
> > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&amp;data=3D02%7C01%7C%7C34= 3ea8
> > > > > >
> > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0= %7C1
> > > > > >
> > %7C636890980182553400&amp;sdata=3Du1KFAYAus16B8a7sgsBfPfIquOp= tMlaOb%2B0
> > > > > > kvPZgr4o%3D&amp;reserved=3D0
> > > > >
> > > > > --
> > > > > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Jacobs University Bremen gGmbH
> > > > > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Campus Ring 1 | 28759 Bremen | Germany
> > > > > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0<
> > > > >
> > https:/= /can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.jacobs-uni= versity.de%2F&amp;data=3D02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8d874%= 7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&amp;sda= ta=3DTrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&amp;reserved=3D= 0
> > > > > >
> > > > >
> > > > >
> > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten = Bormann wrote:
> > > > > > Well, if that is a problem, we can go for a l= onger representation
> > within
> > > > > > unions (section 6.12).=C2=A0 Theoretically, w= e could do that only of
> > there is
> > > > > > more than one enum in the union type (so thin= gs stay efficient if
> > there
> > > > > > is only one), but that might pose difficultie= s with model evolution.
> > > > > >
> > > > > > Going for a string representation repeats the= feature of XML YANG
> > (which
> > > > > > was ported over to JSON YANG):
> > > > > >
> > > > > > typedef foo {
> > > > > >=C2=A0 =C2=A0type union {
> > > > > >=C2=A0 =C2=A0 =C2=A0type enumeration {
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum red { value 1;= }
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum breen { value = 2; }
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum glue { value 3= ; }
> > > > > >=C2=A0 =C2=A0 =C2=A0}
> > > > > >=C2=A0 =C2=A0 =C2=A0type enumeration {
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum tacks { value = 1; }
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum nails { value = 2; }
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum glue { value 3= ; }
> > > > > >=C2=A0 =C2=A0 =C2=A0}
> > > > > >=C2=A0 =C2=A0}
> > > > > > }
> > > > > >
> > > > > > If you use =E2=80=9Cglue=E2=80=9D, you don=E2= =80=99t know which of the enumerations are
> > being
> > > > > > used.
> > > > > >
> > > > > > Using SIDs, we can do better.
> > > > > >
> > > > > > So what do we have to do to get the SID tool = to allocate SIDs for
> > enum
> > > > > > values?
> > > > > >
> > > > > > We could then define the CBOR tag for enums i= n unions to take the
> > usual
> > > > > > SID difference (delta relative to the environ= ment, I=E2=80=99d think), not
> > an
> > > > > > integer value.
> > > > > >
> > > > > > Several of us are at the hackathon and could = make something happen
> > today
> > > > > > and tomorrow.
> > > > > >
> > > > > > Gr=C3=BC=C3=9Fe, Carsten
> > > > > >
> > > > > >
> > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (r= wilton) <rwilton@= cisco.com
> > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > I guess that the concern is that this in= troduces more variation in
> > how
> > > > > > > data is interpreted between the differen= t XML/JSON/CBOR encodings.
> > > > > > >
> > > > > > > E.g. if someone switched from XML to CBO= R, suddenly the
> > configuration
> > > > > > > or state data may have a different meani= ng.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Rob
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Carsten Bormann <cabo@tzi.org>
> > > > > > > > Sent: 22 March 2019 16:08
> > > > > > > > To: Michel Veillette <Michel.Veillette@= trilliant.com>
> > > > > > > > Cc: Rob Wilton (rwilton) <rwilton@cisco.com>;= core@ietf.org;
> > > > > > > > netconf@ietf.org
> > > > > > > > Subject: Re: [netconf] YANG encodin= g in CBOR
> > > > > > > >
> > > > > > > > On Mar 22, 2019, at 16:45, Michel V= eillette
> > > > > > > > <Michel.Veillette@trilliant.com>=
> > > > > > > > wrote:
> > > > > > > > > The only potential problem I a= ware is when multiple
> > enumerations
> > > > > > > > > are part of
> > > > > > > > the same union.
> > > > > > > > > Value 4 from enumeration A wil= l be encoded the same way as
> > Value
> > > > > > > > > 4 from
> > > > > > > > enumeration B.
> > > > > > > >
> > > > > > > > =E2=80=A6 and that is not a problem= for the XML version, because the
> > > > > > > > string is being used instead of the= value.=C2=A0 (But then if two
> > > > > > > > enumerations share a string, you ha= ve the equivalent problem in
> > > > > > > > the XML serialization.)
> > > > > > > >
> > > > > > > > Anyway, I haven=E2=80=99t seen a pi= ece of real-world YANG that actually
> > > > > > > > has this problem, so I would be a b= it reluctant to make CBOR-
> > based
> > > > > > > > implementations more complex (and l= ess efficient) so solve this
> > > > > > > > (non-?)problem.
> > > > > > > >
> > > > > > > > Gr=C3=BC=C3=9Fe, Carsten
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > _____________________________________________= __
> > > > > > netconf mailing list
> > > > > > netconf@ietf.org
> > > > > >
> > https://can01.safel= inks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
> > > > > >
> > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&amp;data=3D02%7C01%7C%7C34= 3ea8
> > > > > >
> > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0= %7C1
> > > > > >
> > %7C636890980182553400&amp;sdata=3Du1KFAYAus16B8a7sgsBfPfIquOp= tMlaOb%2B0
> > > > > > kvPZgr4o%3D&amp;reserved=3D0
> > > > >
> > > > > --
> > > > > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Jacobs University Bremen gGmbH
> > > > > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Campus Ring 1 | 28759 Bremen | Germany
> > > > > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0<
> > > > >
> > https:/= /can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.jacobs-uni= versity.de%2F&amp;data=3D02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f8d874%= 7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&amp;sda= ta=3DTrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&amp;reserved=3D= 0
> > > > > >
> > > > >
> > > > > _______________________________________________ > > > > > netconf mailing list
> > > > > netconf@ietf.org
> > > > > http= s://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > > > > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&amp;data=3D0= 2%7C01%7C%7C343ea8d1
> > > > > cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43= 260c04309%7C0%7C1%7C
> > > > > 636890980182553400&amp;sdata=3Du1KFAYAus16B8a7= sgsBfPfIquOptMlaOb%2B0kvPZ
> > > > > gr4o%3D&amp;reserved=3D0
> > > >
> > > > --
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > >
> > >
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

--000000000000f2603d0585190b7c-- From nobody Wed Mar 27 18:37:44 2019 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 7A437120148 for ; Wed, 27 Mar 2019 18:37:34 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 U5OEizqzEjgZ for ; Wed, 27 Mar 2019 18:37:28 -0700 (PDT) Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) (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 7E58912012E for ; Wed, 27 Mar 2019 18:37:28 -0700 (PDT) Received: by mail-lf1-x141.google.com with SMTP id r25so12763130lfn.13 for ; Wed, 27 Mar 2019 18:37:28 -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=tfknNrBJwSLp4kQR0Lu3mUy31/WpYeLthisqCPdE34U=; b=G8Uw1tATUcS9XMk5/OLkXO00hxNoWJb5V4WMpA4oiRmZiI7JUQHqVNS2rmsigTQ1mE zUkS756m5khYWZcMyap9Fyz17sfDMBRAKOcGgTEmuUfrSN7izDtz9ngIdcX/ByQ3LMEh nm3upnwcgcAHZ7fMXTHrahkAxrdrtdSuWT/kAlBT1H4kc0sSJBbAlnUXq7Ieq94yE0Ly L0sHil1EFsjXKCkdyu9UlbBV/QFgTmA2U99sMpQMIwqVxD8ZwpdzJ8hh5420Lu+M1Yxl yivdThzodktWnu406Zb8b8gwLnp0VPRA8wov5Z/0aRcvGfNniZwRmN2vjf5njhc3u++V ASzg== 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=tfknNrBJwSLp4kQR0Lu3mUy31/WpYeLthisqCPdE34U=; b=O8sOs9hzpyYGrpj2DGeZwGI87Nf9ONlGdWeh8YdPocILvRMgfX7FqlOdf2HGq3U5lv dEq4/wENx2L3PLsDHYHZ23g87gk1T+C6/Av3N07A5irEhJw53/MtQOcKF3zj+vrFpiT/ TChEGU0mwWLKnIArI8HKl5ib4bZ4vsyrtSizfvGLoCkT/CqAajCQ5KgClao5zGR8aBPZ uQTjctiAmdP89cyzb6vby7Qc66tXhXT7MenpQ09QmOBUhULlGQVSz8BwXoK4I401qW5p Ae7qNze6xgSjR7gA3dn3IhY9QFtT/W5KngrckSvb6QIwCWhzx35Kpxme6niu6vhOzuf3 1g5A== X-Gm-Message-State: APjAAAXabgjujM/pkFIdPeoQu6Mu+9TjqgEXF6dZidgEBAvur3juwmX+ UVZs9mMrEl7Bc1nr0wnOVyY8ndPW9059TmYVLEsQyw== X-Google-Smtp-Source: APXvYqyRaPFW0AOUPsnL50Vb9oeZVPLSkndbHZR5bHsKrVcItoOnc1+TXSy79ptu3oPtgU7yxqEMxvijqGI48zQW5TM= X-Received: by 2002:ac2:41c4:: with SMTP id d4mr21103116lfi.104.1553737046602; Wed, 27 Mar 2019 18:37:26 -0700 (PDT) MIME-Version: 1.0 References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <1f8b326e0e05b400457b9446d52a7b0f6c90e05b.camel@nic.cz> In-Reply-To: From: Andy Bierman Date: Wed, 27 Mar 2019 18:37:15 -0700 Message-ID: To: Ladislav Lhotka Cc: Juergen Schoenwaelder , Michel Veillette , "netconf@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bcd01e05851d98c5" Archived-At: Subject: Re: [netconf] [core] YANG encoding in CBOR 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, 28 Mar 2019 01:37:35 -0000 --000000000000bcd01e05851d98c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Lada, On Wed, Mar 27, 2019 at 12:54 PM Ladislav Lhotka wrote: > Andy Bierman p=C3=AD=C5=A1e v St 27. 03. 2019 v 09:13 -0700: > > > > > > On Wed, Mar 27, 2019 at 1:40 AM Ladislav Lhotka wrote: > > > On Wed, 2019-03-27 at 07:16 +0100, Juergen Schoenwaelder wrote: > > > > Hi, > > > > > > > > a union can be formed by using member types that are imported and n= ot > > > > under change control of a single author/organization and ideally th= is > > > > should work without complex coordination of name and number spaces. > > > > Duplicate enum/bits values are legal in YANG today so an encoding h= as > > > > to deal with this aspect of life. > > > > > > > > A robust fix to all these problems will be to tag the type members = in > > > > order to discriminate the values in the encodings. This, however, > will > > > > take some time to specify and we will need to preserve backwards > > > > compatibility with unions without a tag (but compilers can encourag= e > > > > people to add tags whenever modules are updated). > > > > > > I already opened a new issue for this in yang-next: > > > > > > https://github.com/netmod-wg/yang-next/issues/72 > > > > > > > We already explored the solution of giving the member types numbers > > so they could be used in CBOR but this was rejected because it is so > complex > > to implement. > > I don't think it is too complex. Get the type in the schema, get the > member, > that's all. It is much easier and more robust than the current algorithm. > ... I think a discriminated union is too complex and overkill, considering the low probability of the problem. It's not as if the client or server developers know which union member type each value is using. This is not going to be hard-wired either. Senders do not usually validate data, especially NETCONF servers. It will be very expensive (and very slow) to validate union types in order to determine the member type number. We cannot rely on YANG authors to follow the update rules, especially when they change type definitions to fix bugs. The encoding for a union cannot ever change over time or it will break clients. We want to support clients without requiring any code changes, even when the server is upgraded. I prefer a much easier and faster solution: The client or server must figure out which data nodes have this problem at boot-time. These data nodes will always be sent with a new tag (for DUP-UNION) and the format will always be a string. A receiver must be able to handle DUP-UNION strings and parse them against the union type correctly. All other union type data nodes are sent as normal. Annotations are not needed. The JSON vs. XML ordering problem can be handled with best practices https://tools.ietf.org/html/rfc8407#section-4.11.4 Andy --000000000000bcd01e05851d98c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Lada,

On Wed, Mar 27, 2019 at 12:54 PM Ladislav Lho= tka <lhotka@nic.cz> wrote:
Andy Bierman p=C3=AD= =C5=A1e v St 27. 03. 2019 v 09:13 -0700:
>
>
> On Wed, Mar 27, 2019 at 1:40 AM Ladislav Lhotka <lhotka@nic.cz> wrote:
> > On Wed, 2019-03-27 at 07:16 +0100, Juergen Schoenwaelder wrote: > > > Hi,
> > >
> > > a union can be formed by using member types that are importe= d and not
> > > under change control of a single author/organization and ide= ally this
> > > should work without complex coordination of name and number = spaces.
> > > Duplicate enum/bits values are legal in YANG today so an enc= oding has
> > > to deal with this aspect of life.
> > >
> > > A robust fix to all these problems will be to tag the type m= embers in
> > > order to discriminate the values in the encodings. This, how= ever, will
> > > take some time to specify and we will need to preserve backw= ards
> > > compatibility with unions without a tag (but compilers can e= ncourage
> > > people to add tags whenever modules are updated).
> >
> > I already opened a new issue for this in yang-next:
> >
> > https://github.com/netmod-wg/yang-next/is= sues/72
> >
>
> We already explored the solution of giving the member types numbers > so they could be used in CBOR but this was rejected because it is so c= omplex
> to implement.

I don't think it is too complex. Get the type in the schema, get the me= mber,
that's all. It is much easier and more robust than the current algorith= m.
...

I think a discriminated union is = too complex and overkill, considering the low probability
of the = problem.

It's not as if the client or server d= evelopers know which union member type each value is using.
This = is not going to be hard-wired either.=C2=A0 Senders do not usually validate= data, especially
NETCONF servers.=C2=A0 It will be very expensiv= e (and very slow) to validate union types
in order to determine t= he member type number.

We cannot rely on YANG auth= ors to follow the update rules, especially when
they change type = definitions to fix bugs.=C2=A0 The encoding for a union cannot ever
change over time or it will break clients. We want to support clients wi= thout requiring
any code changes, even when the server is upgrade= d.

I prefer a much easier and faster solution:

The client or server must figure out which data nodes= have this problem at boot-time.
These data nodes will always be = sent with a new tag (for DUP-UNION) and the
format will always be= a string. A receiver must be able to handle DUP-UNION strings
an= d parse them against the union type correctly.

All= other union type data nodes are sent as normal.
Annotations are = not needed.

The JSON vs. XML ordering problem can = be handled with best practices


Andy

--000000000000bcd01e05851d98c5-- From nobody Thu Mar 28 02:33:29 2019 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 46A32120165; Thu, 28 Mar 2019 02:33:20 -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, 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 KgNW019cq-e6; Thu, 28 Mar 2019 02:33:15 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C78141201A7; Thu, 28 Mar 2019 02:33:14 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 2146118204C5; Thu, 28 Mar 2019 10:32:38 +0100 (CET) Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 29BEA1820047; Thu, 28 Mar 2019 10:32:31 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman Cc: Juergen Schoenwaelder , Michel Veillette , "netconf\@ietf.org" , "core\@ietf.org" In-Reply-To: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <1f8b326e0e05b400457b9446d52a7b0f6c90e05b.camel@nic.cz> Date: Thu, 28 Mar 2019 10:33:06 +0100 Message-ID: <87r2armjhp.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] [core] YANG encoding in CBOR 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, 28 Mar 2019 09:33:20 -0000 Andy Bierman writes: > On Wed, Mar 27, 2019 at 12:54 PM Ladislav Lhotka wrote: > >> Andy Bierman p=C3=AD=C5=A1e v St 27. 03. 2019 v 09:13 -0700: >> > >> > >> > On Wed, Mar 27, 2019 at 1:40 AM Ladislav Lhotka wrote: >> > > On Wed, 2019-03-27 at 07:16 +0100, Juergen Schoenwaelder wrote: >> > > > Hi, >> > > > >> > > > a union can be formed by using member types that are imported and = not >> > > > under change control of a single author/organization and ideally t= his >> > > > should work without complex coordination of name and number spaces. >> > > > Duplicate enum/bits values are legal in YANG today so an encoding = has >> > > > to deal with this aspect of life. >> > > > >> > > > A robust fix to all these problems will be to tag the type members= in >> > > > order to discriminate the values in the encodings. This, however, >> will >> > > > take some time to specify and we will need to preserve backwards >> > > > compatibility with unions without a tag (but compilers can encoura= ge >> > > > people to add tags whenever modules are updated). >> > > >> > > I already opened a new issue for this in yang-next: >> > > >> > > https://github.com/netmod-wg/yang-next/issues/72 >> > > >> > >> > We already explored the solution of giving the member types numbers >> > so they could be used in CBOR but this was rejected because it is so >> complex >> > to implement. >> >> I don't think it is too complex. Get the type in the schema, get the >> member, >> that's all. It is much easier and more robust than the current algorithm. >> >> > no it isn't easier because the algorithm is error-prone. > Renumbering un-named types nested within unions and referenced named types > over many revisions of the module is not easy. > The encoding MUST NOT change EVER -- even if the union type is expanded. > > >> > >> > Consider when union is within union, and the types are named types from >> >> Union within union is no problem: it jut requires a sequence of numbers. >> >> > do not agree since the union can have a member type added > > > >> > other modules. Union types can be legally updated in new versions of t= he >> > module, >> >> Again, I don't agree. Sec. 11 in RFC 7950 says: >> >> o A "type" statement may be replaced with another "type" statement >> that does not change the syntax or semantics of the type. >> ... >> >> > > type uint32 { range "1..8"; } > > I can refactor that into 2 types (1..4 and 5..8) This looks like a pretty contrived example, why would somebody want to do this? Anyway, regarding updates: one can have this union type union { type uint32 { range "1..3"; } type string; } So, in XML representation, the value of 4 will be classified as a string. Now, according to sec. 11, it is legal to expand the range to 1..10, say. Suddenly, the same value becomes a number. > This does not change the semantics of the union type but it adds a member > type > Other refactoring is possible that will also change the number of member > types. > > Also, deviations do not follow this rule > > > >> Adding a new member clearly changes the semantics of the type, if not >> syntax. >> >> > no it doesn't always change the semantics > > > >> > but the position assignments for SID can never change. >> >> The annotation would also help resolve the differences between JSON and >> XML. SID >> is only available in CBOR. >> >> > >> > Even without this complexity this solution would cause the >> encoder/decoder to >> > be very schema-aware. >> >> The current method of resolving unions is totally schema-aware (somewhat >> less so >> in JSON). >> >> > No -- it just needs to know string vs. number. > Not schema aware at all. Of course it is. With both strings and numbers, you also have to check restrictions if they are specified in the schema (pattern, range etc.), deref leafrefs etc. I think we all agree that unions in YANG are fragile and may cause subtle problems. If a better solution is found, then fine, but IMO it needs to be addressed, and not only in CBOR. Lada > > >> Lada >> >> > Andy > > >> > >> > >> > BTW, creating SIDs for enums and bits will break if the server uses >> 'deviate >> > replace type'. >> > There is no way to number the deviated type since this is >> server-specific not >> > part of the original module >> > and the deviation is not actually a data-def-stmt. >> > >> > >> > > Lada >> > > >> > >> > Andy >> > >> > > > >> > > > /js >> > > > >> > > > On Wed, Mar 27, 2019 at 01:12:52AM +0000, Michel Veillette wrote: >> > > > > Hi Ladislav >> > > > > >> > > > > If I summarize this issue of multiple enumerations or bits in a >> union, >> > > this >> > > > > problem can be solve by the following approaches: >> > > > > >> > > > > - To not allows these duplicate values or positions to happen in >> YANG >> > > > > - To encode enumerations and bits as string (in all unions or on= ly >> when >> > > > > multiple enumerations or bits are defined) >> > > > > - To encode enumerations and bits as SID (in all unions or only >> when >> > > > > multiple enumerations or bits are defined) >> > > > > - To encode enumerations and bits as delta between the value SID >> and the >> > > > > leaf SID (in all unions or only when multiple enumerations or bi= ts >> are >> > > > > defined) >> > > > > >> > > > > In this email, I will like to focus on the first option, fixing = the >> > > problem >> > > > > directly in YANG instead of fixing the consequences. >> > > > > >> > > > > Without any changes in YANG, a union with multiple enumeration or >> bits >> > > can >> > > > > be constructed without value or position overlaps. >> > > > > For example: >> > > > > >> > > > > leaf multiple-enumerations-test-1 { >> > > > > type union { >> > > > > type enumeration { >> > > > > enum "Monday" { value 0; } >> > > > > enum "Tuesday" { value 1; } >> > > > > enum "Wednesday" { value 2; } >> > > > > enum "Thursday" { value 3; } >> > > > > enum "Friday" { value 4; } >> > > > > >> > > > > } >> > > > > type enumeration { >> > > > > enum "Saturday" { value 5; } >> > > > > enum "Sunday" { value 6; } >> > > > > } >> > > > > } >> > > > > } >> > > > > >> > > > > leaf multiple-bits-test-1 { >> > > > > type union { >> > > > > type bits { >> > > > > bit "Monday" { position 0; } >> > > > > bit "Tuesday" { position 1; } >> > > > > bit "Wednesday" { position 2; } >> > > > > bit "Thursday" { position 3; } >> > > > > bit "Friday" { position 4; } >> > > > > >> > > > > } >> > > > > type bits { >> > > > > bit "Saturday" { position 5; } >> > > > > bit "Sunday" { position 6; } >> > > > > } >> > > > > } >> > > > > } >> > > > > >> > > > > When using already defined typedef, avoiding overlap is less >> obvious >> > > without >> > > > > some help. >> > > > > To help building unions with already defined typedefs, I propose= to >> > > > > introduce two extensions. >> > > > > >> > > > > extension value-offset { >> > > > > argument offset { >> > > > > yin-element true; >> > > > > } >> > > > > description >> > > > > "Offset added to each enum value of the associated >> enumeration."; >> > > > > } >> > > > > >> > > > > extension position-offset { >> > > > > argument offset { >> > > > > yin-element true; >> > > > > } >> > > > > description >> > > > > "Offset value added to each bit position of the associated >> bits."; >> > > > > } >> > > > > >> > > > > The value-offset extension can be used as follow: >> > > > > >> > > > > type enumeration { >> > > > > enum "Monday"; >> > > > > enum "Tuesday"; >> > > > > enum "Wednesday"; >> > > > > enum "Thursday"; >> > > > > enum "Friday"; >> > > > > } >> > > > > } >> > > > > >> > > > > typedef weekend { >> > > > > type enumeration { >> > > > > enum "Saturday"; >> > > > > enum "Sunday"; >> > > > > } >> > > > > } >> > > > > >> > > > > leaf multiple-enumerations-test-3 { >> > > > > type union { >> > > > > type weekdays; >> > > > > type weekend { >> > > > > ext:value-offset 5; >> > > > > } >> > > > > } >> > > > > } >> > > > > >> > > > > The position-offset extension can be used as follow: >> > > > > >> > > > > typedef weekdays-flags { >> > > > > type bits { >> > > > > bit "Monday"; >> > > > > bit "Tuesday"; >> > > > > bit "Wednesday"; >> > > > > bit "Thursday"; >> > > > > bit "Friday"; >> > > > > } >> > > > > } >> > > > > >> > > > > typedef weekend-flags { >> > > > > type bits { >> > > > > bit "Saturday"; >> > > > > bit "Sunday"; >> > > > > } >> > > > > } >> > > > > >> > > > > leaf multiple-bits-test-3 { >> > > > > type union { >> > > > > type weekdays-flags; >> > > > > type weekend-flags { >> > > > > ext:position-offset 5; >> > > > > } >> > > > > } >> > > > > } >> > > > > >> > > > > The yang file in attachment show different examples based on this >> > > approach. >> > > > > This module have been validated using >> > > http://www.yangvalidator.com/validator >> > > > > >> > > > > If this approach is accepted, tools like pyang should be updated= to >> > > produce >> > > > > an error if multiple enumerations or bits are defined with value= or >> > > position >> > > > > overleaps. >> > > > > >> > > > > Please comment, >> > > > > Michel >> > > > > >> > > > > -----Original Message----- >> > > > > From: Ladislav Lhotka >> > > > > Sent: Monday, March 25, 2019 4:07 AM >> > > > > To: Juergen Schoenwaelder ; >> > > Carsten >> > > > > Bormann >> > > > > Cc: Michel Veillette ; >> netconf@ietf.org; >> > > >> > > > > core@ietf.org >> > > > > Subject: Re: [netconf] YANG encoding in CBOR >> > > > > >> > > > > Juergen Schoenwaelder >> writes: >> > > > > >> > > > > > I think we need to look at the whole picture and in which >> direction >> > > we >> > > > > > want to go. In the longer term, I would prefer a solution where >> the >> > > > > > values of a union are discriminated. The current XML encoding >> > > > > > behaviour of 'first match wins' is fragile (for example, if >> someone >> > > > > > adds an enum to a type, the interpretation of data can change). >> > > > > > >> > > > > > Look at this: >> > > > > > >> > > > > > typedef bar { >> > > > > > type union { >> > > > > > type enumeration { enum "1"; value 2; enum "2"; value 1; } >> > > > > > type uint8; >> > > > > > } >> > > > > > } >> > > > > > >> > > > > > We have some encodings that send the string representations of >> the >> > > > > > values and some encodings that prefer to send numeric >> representations >> > > > > > where possible. In order to have a robust solution, encodings >> should >> > > > > > likely indicate to which type the value belongs. >> > > > > >> > > > > Perhaps the easiest way would be to use (optional) annotation th= at >> > > > > specifies, using an ordinal number, which of the member types is >> used >> > > for >> > > > > the particular instance. But since there can be unions inside >> unions, a >> > > list >> > > > > of numbers would be needed in general. >> > > > > >> > > > > Lada >> > > > > >> > > > > > /js >> > > > > > >> > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrot= e: >> > > > > > > Well, if that is a problem, we can go for a longer >> representation >> > > within >> > > > > > > unions (section 6.12). Theoretically, we could do that only= of >> > > there is >> > > > > > > more than one enum in the union type (so things stay efficie= nt >> if >> > > there >> > > > > > > is only one), but that might pose difficulties with model >> evolution. >> > > > > > > >> > > > > > > Going for a string representation repeats the feature of XML >> YANG >> > > (which >> > > > > > > was ported over to JSON YANG): >> > > > > > > >> > > > > > > typedef foo { >> > > > > > > type union { >> > > > > > > type enumeration { >> > > > > > > enum red { value 1; } >> > > > > > > enum breen { value 2; } >> > > > > > > enum glue { value 3; } >> > > > > > > } >> > > > > > > type enumeration { >> > > > > > > enum tacks { value 1; } >> > > > > > > enum nails { value 2; } >> > > > > > > enum glue { value 3; } >> > > > > > > } >> > > > > > > } >> > > > > > > } >> > > > > > > >> > > > > > > If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know wh= ich of the enumerations are >> > > being >> > > > > > > used. >> > > > > > > >> > > > > > > Using SIDs, we can do better. >> > > > > > > >> > > > > > > So what do we have to do to get the SID tool to allocate SIDs >> for >> > > enum >> > > > > > > values? >> > > > > > > >> > > > > > > We could then define the CBOR tag for enums in unions to take >> the >> > > usual >> > > > > > > SID difference (delta relative to the environment, I=E2=80= =99d think), >> not >> > > an >> > > > > > > integer value. >> > > > > > > >> > > > > > > Several of us are at the hackathon and could make something >> happen >> > > today >> > > > > > > and tomorrow. >> > > > > > > >> > > > > > > Gr=C3=BC=C3=9Fe, Carsten >> > > > > > > >> > > > > > > >> > > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) < >> rwilton@cisco.com >> > > > >> > > > > > > > wrote: >> > > > > > > > >> > > > > > > > I guess that the concern is that this introduces more >> variation in >> > > how >> > > > > > > > data is interpreted between the different XML/JSON/CBOR >> encodings. >> > > > > > > > >> > > > > > > > E.g. if someone switched from XML to CBOR, suddenly the >> > > configuration >> > > > > > > > or state data may have a different meaning. >> > > > > > > > >> > > > > > > > Thanks, >> > > > > > > > Rob >> > > > > > > > >> > > > > > > > >> > > > > > > > > -----Original Message----- >> > > > > > > > > From: Carsten Bormann >> > > > > > > > > Sent: 22 March 2019 16:08 >> > > > > > > > > To: Michel Veillette >> > > > > > > > > Cc: Rob Wilton (rwilton) ; >> core@ietf.org; >> > > > > > > > > netconf@ietf.org >> > > > > > > > > Subject: Re: [netconf] YANG encoding in CBOR >> > > > > > > > > >> > > > > > > > > On Mar 22, 2019, at 16:45, Michel Veillette >> > > > > > > > > >> > > > > > > > > wrote: >> > > > > > > > > > The only potential problem I aware is when multiple >> > > enumerations >> > > > > > > > > > are part of >> > > > > > > > > the same union. >> > > > > > > > > > Value 4 from enumeration A will be encoded the same way >> as >> > > Value >> > > > > > > > > > 4 from >> > > > > > > > > enumeration B. >> > > > > > > > > >> > > > > > > > > =E2=80=A6 and that is not a problem for the XML version,= because >> the >> > > > > > > > > string is being used instead of the value. (But then if >> two >> > > > > > > > > enumerations share a string, you have the equivalent >> problem in >> > > > > > > > > the XML serialization.) >> > > > > > > > > >> > > > > > > > > Anyway, I haven=E2=80=99t seen a piece of real-world YAN= G that >> actually >> > > > > > > > > has this problem, so I would be a bit reluctant to make >> CBOR- >> > > based >> > > > > > > > > implementations more complex (and less efficient) so sol= ve >> this >> > > > > > > > > (non-?)problem. >> > > > > > > > > >> > > > > > > > > Gr=C3=BC=C3=9Fe, Carsten >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > _______________________________________________ >> > > > > > > netconf mailing list >> > > > > > > netconf@ietf.org >> > > > > > > >> > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= www >> > > > > > > >> > > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343= ea8 >> > > > > > > >> > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1 >> > > > > > > >> > > %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%= 2B0 >> > > > > > > kvPZgr4o%3D&reserved=3D0 >> > > > > > >> > > > > > -- >> > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >> Germany >> > > > > > Fax: +49 421 200 3103 < >> > > > > > >> > > >> https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.= jacobs-university.de%2F&data=3D02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f= 8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&s= data=3DTrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&reserved=3D0 >> > > > > > > >> > > > > > >> > > > > > >> > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrot= e: >> > > > > > > Well, if that is a problem, we can go for a longer >> representation >> > > within >> > > > > > > unions (section 6.12). Theoretically, we could do that only= of >> > > there is >> > > > > > > more than one enum in the union type (so things stay efficie= nt >> if >> > > there >> > > > > > > is only one), but that might pose difficulties with model >> evolution. >> > > > > > > >> > > > > > > Going for a string representation repeats the feature of XML >> YANG >> > > (which >> > > > > > > was ported over to JSON YANG): >> > > > > > > >> > > > > > > typedef foo { >> > > > > > > type union { >> > > > > > > type enumeration { >> > > > > > > enum red { value 1; } >> > > > > > > enum breen { value 2; } >> > > > > > > enum glue { value 3; } >> > > > > > > } >> > > > > > > type enumeration { >> > > > > > > enum tacks { value 1; } >> > > > > > > enum nails { value 2; } >> > > > > > > enum glue { value 3; } >> > > > > > > } >> > > > > > > } >> > > > > > > } >> > > > > > > >> > > > > > > If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know wh= ich of the enumerations are >> > > being >> > > > > > > used. >> > > > > > > >> > > > > > > Using SIDs, we can do better. >> > > > > > > >> > > > > > > So what do we have to do to get the SID tool to allocate SIDs >> for >> > > enum >> > > > > > > values? >> > > > > > > >> > > > > > > We could then define the CBOR tag for enums in unions to take >> the >> > > usual >> > > > > > > SID difference (delta relative to the environment, I=E2=80= =99d think), >> not >> > > an >> > > > > > > integer value. >> > > > > > > >> > > > > > > Several of us are at the hackathon and could make something >> happen >> > > today >> > > > > > > and tomorrow. >> > > > > > > >> > > > > > > Gr=C3=BC=C3=9Fe, Carsten >> > > > > > > >> > > > > > > >> > > > > > > > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) < >> rwilton@cisco.com >> > > > >> > > > > > > > wrote: >> > > > > > > > >> > > > > > > > I guess that the concern is that this introduces more >> variation in >> > > how >> > > > > > > > data is interpreted between the different XML/JSON/CBOR >> encodings. >> > > > > > > > >> > > > > > > > E.g. if someone switched from XML to CBOR, suddenly the >> > > configuration >> > > > > > > > or state data may have a different meaning. >> > > > > > > > >> > > > > > > > Thanks, >> > > > > > > > Rob >> > > > > > > > >> > > > > > > > >> > > > > > > > > -----Original Message----- >> > > > > > > > > From: Carsten Bormann >> > > > > > > > > Sent: 22 March 2019 16:08 >> > > > > > > > > To: Michel Veillette >> > > > > > > > > Cc: Rob Wilton (rwilton) ; >> core@ietf.org; >> > > > > > > > > netconf@ietf.org >> > > > > > > > > Subject: Re: [netconf] YANG encoding in CBOR >> > > > > > > > > >> > > > > > > > > On Mar 22, 2019, at 16:45, Michel Veillette >> > > > > > > > > >> > > > > > > > > wrote: >> > > > > > > > > > The only potential problem I aware is when multiple >> > > enumerations >> > > > > > > > > > are part of >> > > > > > > > > the same union. >> > > > > > > > > > Value 4 from enumeration A will be encoded the same way >> as >> > > Value >> > > > > > > > > > 4 from >> > > > > > > > > enumeration B. >> > > > > > > > > >> > > > > > > > > =E2=80=A6 and that is not a problem for the XML version,= because >> the >> > > > > > > > > string is being used instead of the value. (But then if >> two >> > > > > > > > > enumerations share a string, you have the equivalent >> problem in >> > > > > > > > > the XML serialization.) >> > > > > > > > > >> > > > > > > > > Anyway, I haven=E2=80=99t seen a piece of real-world YAN= G that >> actually >> > > > > > > > > has this problem, so I would be a bit reluctant to make >> CBOR- >> > > based >> > > > > > > > > implementations more complex (and less efficient) so sol= ve >> this >> > > > > > > > > (non-?)problem. >> > > > > > > > > >> > > > > > > > > Gr=C3=BC=C3=9Fe, Carsten >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > _______________________________________________ >> > > > > > > netconf mailing list >> > > > > > > netconf@ietf.org >> > > > > > > >> > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= www >> > > > > > > >> > > .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343= ea8 >> > > > > > > >> > > d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1 >> > > > > > > >> > > %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%= 2B0 >> > > > > > > kvPZgr4o%3D&reserved=3D0 >> > > > > > >> > > > > > -- >> > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >> Germany >> > > > > > Fax: +49 421 200 3103 < >> > > > > > >> > > >> https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.= jacobs-university.de%2F&data=3D02%7C01%7C%7C343ea8d1cf8f4e39afc708d6b0f= 8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C636890980182553400&s= data=3DTrW2iL3nUDlZ%2BVvhPxWeqdU1X%2BqvFCnXyodX6Bu1e94%3D&reserved=3D0 >> > > > > > > >> > > > > > >> > > > > > _______________________________________________ >> > > > > > netconf mailing list >> > > > > > netconf@ietf.org >> > > > > > >> https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. >> > > > > > ietf.org >> %2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343ea8d1 >> > > > > > >> cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1%7C >> > > > > > >> 636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0kvPZ >> > > > > > gr4o%3D&reserved=3D0 >> > > > > >> > > > > -- >> > > > > Ladislav Lhotka >> > > > > Head, CZ.NIC Labs >> > > > > PGP Key ID: 0xB8F92B08A9F76C67 >> > > > >> > > > >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Mar 28 03:03:55 2019 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 54A8F120331; Thu, 28 Mar 2019 03:03:29 -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, 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 gG-bQeT3VQjO; Thu, 28 Mar 2019 03:03:24 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 12E6D120480; Thu, 28 Mar 2019 03:03:24 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 6042118204C5; Thu, 28 Mar 2019 11:02:47 +0100 (CET) Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id C0F501820047; Thu, 28 Mar 2019 11:02:42 +0100 (CET) From: Ladislav Lhotka To: Michel Veillette , Juergen Schoenwaelder Cc: Carsten Bormann , "netconf\@ietf.org" , "core\@ietf.org" In-Reply-To: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> Date: Thu, 28 Mar 2019 11:03:17 +0100 Message-ID: <87k1gjmi3e.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 28 Mar 2019 10:03:34 -0000 Hi Michel, string tags look like a more robust solution than numeric member positions. It would be better though to have them as a built-in statement, or at least a "critical" extension. Lada Michel Veillette writes: > Hi Juergen > > You will find in attachment the updated version of 'test-union@2019-03-25= .yang' based on your proposed solution, type tagging. > This module defines an extension called union-tag as follow: > > extension union-tag { > argument tag { > yin-element true; > } > description > "In some cases, the interpretation of a value of a union type can d= iffer > when encoded using the different data format. This difference comes= from > the level of type information supported by the different data forma= ts. > In the case of XML, all elements and attributes are encoded as stri= ng > and no type information are included. JSON supports string, number = and > boolean. Finally, CBOR supports all YANG basic types. > > This extension can be used to add a tag to a type within a union to > guarantee its proper interpretation when decoded."; > } > > This extension can be used as follow: > > leaf multiple-enumerations-test-2 { > type union { > type enumeration { > ext:union-tag weekdays; > enum "Monday"; > enum "Tuesday"; > enum "Wednesday"; > enum "Thursday"; > enum "Friday"; > } > type enumeration { > ext:union-tag weekend; > enum "Saturday"; > enum "Sunday"; > } > } > } > > If I assume this solution or similar solution is implemented, the next qu= estion is how this tag is encoded in CBOR. > Let assume that the data node SID is 1820 and the SID assigned to "weekda= ys" tag is 1821. > > When set to "Tuesday", this data node can be encoded using a CBOR map as = follows: > > { > 1820 : { "weekdays", 1} > } > > Do we need to add a CBOR tag to this encoding to specify the use of a uni= on tag? (99 in this example) > I personally don't think so since the use of a CBOR map for a union data = node is not currently possible. > > { > 1820 : (99) { "weekdays", 1} > } > > Should we use a SID instead of the tag?=20 > > { > 1820 : { 1821, 1} > } > > Should we use a delta between the data node SID and the union tag SID? > The drawback of this approach is that the same value assigned to differen= t data nodes is encoded differently. > I won't personally recommend this approach. > > { > 1820 : { 1, 1} > } > > I hope this email will help moving the discussion closer to the final sol= ution. > > Please comments > Michel > > -----Original Message----- > From: Juergen Schoenwaelder =20 > Sent: Wednesday, March 27, 2019 2:17 AM > To: Michel Veillette > Cc: Ladislav Lhotka ; Carsten Bormann ; netc= onf@ietf.org; core@ietf.org > Subject: Re: [netconf] YANG encoding in CBOR > > Hi, > > a union can be formed by using member types that are imported and not und= er change control of a single author/organization and ideally this should w= ork without complex coordination of name and number spaces. > Duplicate enum/bits values are legal in YANG today so an encoding has to = deal with this aspect of life. > > A robust fix to all these problems will be to tag the type members in ord= er to discriminate the values in the encodings. This, however, will take so= me time to specify and we will need to preserve backwards compatibility wit= h unions without a tag (but compilers can encourage people to add tags when= ever modules are updated). > > /js > > On Wed, Mar 27, 2019 at 01:12:52AM +0000, Michel Veillette wrote: >> Hi Ladislav >>=20 >> If I summarize this issue of multiple enumerations or bits in a union, t= his problem can be solve by the following approaches: >>=20 >> - To not allows these duplicate values or positions to happen in YANG >> - To encode enumerations and bits as string (in all unions or only=20 >> when multiple enumerations or bits are defined) >> - To encode enumerations and bits as SID (in all unions or only when=20 >> multiple enumerations or bits are defined) >> - To encode enumerations and bits as delta between the value SID and=20 >> the leaf SID (in all unions or only when multiple enumerations or bits=20 >> are defined) >>=20 >> In this email, I will like to focus on the first option, fixing the prob= lem directly in YANG instead of fixing the consequences. >>=20 >> Without any changes in YANG, a union with multiple enumeration or bits c= an be constructed without value or position overlaps. >> For example: >>=20 >> leaf multiple-enumerations-test-1 { >> type union { >> type enumeration { >> enum "Monday" { value 0; } >> enum "Tuesday" { value 1; } >> enum "Wednesday" { value 2; } >> enum "Thursday" { value 3; } >> enum "Friday" { value 4; } >>=20 >> } >> type enumeration { >> enum "Saturday" { value 5; } >> enum "Sunday" { value 6; } >> } >> } >> } >>=20 >> leaf multiple-bits-test-1 { >> type union { >> type bits { >> bit "Monday" { position 0; } >> bit "Tuesday" { position 1; } >> bit "Wednesday" { position 2; } >> bit "Thursday" { position 3; } >> bit "Friday" { position 4; } >>=20 >> } >> type bits { >> bit "Saturday" { position 5; } >> bit "Sunday" { position 6; } >> } >> } >> } >>=20 >> When using already defined typedef, avoiding overlap is less obvious wit= hout some help. >> To help building unions with already defined typedefs, I propose to intr= oduce two extensions.=20 >>=20 >> extension value-offset { >> argument offset { >> yin-element true; >> } >> description >> "Offset added to each enum value of the associated enumeration."; >> } >>=20=20=20 >> extension position-offset { >> argument offset { >> yin-element true; >> } >> description >> "Offset value added to each bit position of the associated bits."; >> } >>=20 >> The value-offset extension can be used as follow: >>=20 >> type enumeration { >> enum "Monday"; >> enum "Tuesday"; >> enum "Wednesday"; >> enum "Thursday"; >> enum "Friday"; >> } >> } >>=20 >> typedef weekend { >> type enumeration { >> enum "Saturday"; >> enum "Sunday"; >> } >> } >>=20=20=20 >> leaf multiple-enumerations-test-3 { >> type union { >> type weekdays; >> type weekend { >> ext:value-offset 5; >> } >> } >> } >>=20 >> The position-offset extension can be used as follow: >>=20 >> typedef weekdays-flags { >> type bits { >> bit "Monday"; >> bit "Tuesday"; >> bit "Wednesday"; >> bit "Thursday"; >> bit "Friday"; >> } >> } >>=20 >> typedef weekend-flags { >> type bits { >> bit "Saturday"; >> bit "Sunday"; >> } >> } >>=20=20=20 >> leaf multiple-bits-test-3 { >> type union { >> type weekdays-flags; >> type weekend-flags { >> ext:position-offset 5; >> } >> } >> } >>=20 >> The yang file in attachment show different examples based on this approa= ch. >> This module have been validated using=20 >> https://can01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.y >> angvalidator.com%2Fvalidator&data=3D02%7C01%7C%7Cc69426dcaaf8448e1d4 >> 708d6b27bc735%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C63689264207 >> 3257660&sdata=3DXqo40lzBjINVFZhIZZI1LEktAdq5mee2AdxeYqefnsA%3D&r >> eserved=3D0 If this approach is accepted, tools like pyang should be=20 >> updated to produce an error if multiple enumerations or bits are defined= with value or position overleaps. >>=20 >> Please comment, >> Michel >>=20 >> -----Original Message----- >> From: Ladislav Lhotka >> Sent: Monday, March 25, 2019 4:07 AM >> To: Juergen Schoenwaelder ;=20 >> Carsten Bormann >> Cc: Michel Veillette ;=20 >> netconf@ietf.org; core@ietf.org >> Subject: Re: [netconf] YANG encoding in CBOR >>=20 >> Juergen Schoenwaelder writes: >>=20 >> > I think we need to look at the whole picture and in which direction=20 >> > we want to go. In the longer term, I would prefer a solution where=20 >> > the values of a union are discriminated. The current XML encoding=20 >> > behaviour of 'first match wins' is fragile (for example, if someone=20 >> > adds an enum to a type, the interpretation of data can change). >> > >> > Look at this: >> > >> > typedef bar { >> > type union { >> > type enumeration { enum "1"; value 2; enum "2"; value 1; } >> > type uint8; >> > } >> > } >> > >> > We have some encodings that send the string representations of the=20 >> > values and some encodings that prefer to send numeric=20 >> > representations where possible. In order to have a robust solution,=20 >> > encodings should likely indicate to which type the value belongs. >>=20 >> Perhaps the easiest way would be to use (optional) annotation that speci= fies, using an ordinal number, which of the member types is used for the pa= rticular instance. But since there can be unions inside unions, a list of n= umbers would be needed in general. >>=20 >> Lada >>=20 >> > >> > /js >> > >> > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: >> >> Well, if that is a problem, we can go for a longer representation wit= hin unions (section 6.12). Theoretically, we could do that only of there i= s more than one enum in the union type (so things stay efficient if there i= s only one), but that might pose difficulties with model evolution. >> >>=20 >> >> Going for a string representation repeats the feature of XML YANG (wh= ich was ported over to JSON YANG): >> >>=20 >> >> typedef foo { >> >> type union { >> >> type enumeration { >> >> enum red { value 1; } >> >> enum breen { value 2; } >> >> enum glue { value 3; } >> >> } >> >> type enumeration { >> >> enum tacks { value 1; } >> >> enum nails { value 2; } >> >> enum glue { value 3; } >> >> } >> >> } >> >> } >> >>=20 >> >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of th= e enumerations are being used. >> >>=20 >> >> Using SIDs, we can do better. >> >>=20 >> >> So what do we have to do to get the SID tool to allocate SIDs for enu= m values? >> >>=20 >> >> We could then define the CBOR tag for enums in unions to take the usu= al SID difference (delta relative to the environment, I=E2=80=99d think), n= ot an integer value. >> >>=20 >> >> Several of us are at the hackathon and could make something happen to= day and tomorrow. >> >>=20 >> >> Gr=C3=BC=C3=9Fe, Carsten >> >>=20 >> >>=20 >> >> > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) = wrote: >> >> >=20 >> >> > I guess that the concern is that this introduces more variation in = how data is interpreted between the different XML/JSON/CBOR encodings. >> >> >=20 >> >> > E.g. if someone switched from XML to CBOR, suddenly the configurati= on or state data may have a different meaning. >> >> >=20 >> >> > Thanks, >> >> > Rob >> >> >=20 >> >> >=20 >> >> >> -----Original Message----- >> >> >> From: Carsten Bormann >> >> >> Sent: 22 March 2019 16:08 >> >> >> To: Michel Veillette >> >> >> Cc: Rob Wilton (rwilton) ; core@ietf.org;=20 >> >> >> netconf@ietf.org >> >> >> Subject: Re: [netconf] YANG encoding in CBOR >> >> >>=20 >> >> >> On Mar 22, 2019, at 16:45, Michel Veillette=20 >> >> >> >> >> >> wrote: >> >> >>>=20 >> >> >>> The only potential problem I aware is when multiple=20 >> >> >>> enumerations are part of >> >> >> the same union. >> >> >>> Value 4 from enumeration A will be encoded the same way as=20 >> >> >>> Value >> >> >>> 4 from >> >> >> enumeration B. >> >> >>=20 >> >> >> =E2=80=A6 and that is not a problem for the XML version, because t= he=20 >> >> >> string is being used instead of the value. (But then if two=20 >> >> >> enumerations share a string, you have the equivalent problem in=20 >> >> >> the XML serialization.) >> >> >>=20 >> >> >> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that act= ually=20 >> >> >> has this problem, so I would be a bit reluctant to make=20 >> >> >> CBOR-based implementations more complex (and less efficient) so so= lve this (non-?)problem. >> >> >>=20 >> >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> >=20 >> >> >=20 >> >> >=20 >> >>=20 >> >> _______________________________________________ >> >> netconf mailing list >> >> netconf@ietf.org >> >> https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw >> >> ww >> >> .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343e >> >> a8 >> >> d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7 >> >> C1 >> >> %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2 >> >> B0 >> >> kvPZgr4o%3D&reserved=3D0 >> > >> > --=20 >> > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> > Fax: +49 421 200 3103 >> > >> > >> > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: >> >> Well, if that is a problem, we can go for a longer representation wit= hin unions (section 6.12). Theoretically, we could do that only of there i= s more than one enum in the union type (so things stay efficient if there i= s only one), but that might pose difficulties with model evolution. >> >>=20 >> >> Going for a string representation repeats the feature of XML YANG (wh= ich was ported over to JSON YANG): >> >>=20 >> >> typedef foo { >> >> type union { >> >> type enumeration { >> >> enum red { value 1; } >> >> enum breen { value 2; } >> >> enum glue { value 3; } >> >> } >> >> type enumeration { >> >> enum tacks { value 1; } >> >> enum nails { value 2; } >> >> enum glue { value 3; } >> >> } >> >> } >> >> } >> >>=20 >> >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of th= e enumerations are being used. >> >>=20 >> >> Using SIDs, we can do better. >> >>=20 >> >> So what do we have to do to get the SID tool to allocate SIDs for enu= m values? >> >>=20 >> >> We could then define the CBOR tag for enums in unions to take the usu= al SID difference (delta relative to the environment, I=E2=80=99d think), n= ot an integer value. >> >>=20 >> >> Several of us are at the hackathon and could make something happen to= day and tomorrow. >> >>=20 >> >> Gr=C3=BC=C3=9Fe, Carsten >> >>=20 >> >>=20 >> >> > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) = wrote: >> >> >=20 >> >> > I guess that the concern is that this introduces more variation in = how data is interpreted between the different XML/JSON/CBOR encodings. >> >> >=20 >> >> > E.g. if someone switched from XML to CBOR, suddenly the configurati= on or state data may have a different meaning. >> >> >=20 >> >> > Thanks, >> >> > Rob >> >> >=20 >> >> >=20 >> >> >> -----Original Message----- >> >> >> From: Carsten Bormann >> >> >> Sent: 22 March 2019 16:08 >> >> >> To: Michel Veillette >> >> >> Cc: Rob Wilton (rwilton) ; core@ietf.org;=20 >> >> >> netconf@ietf.org >> >> >> Subject: Re: [netconf] YANG encoding in CBOR >> >> >>=20 >> >> >> On Mar 22, 2019, at 16:45, Michel Veillette=20 >> >> >> >> >> >> wrote: >> >> >>>=20 >> >> >>> The only potential problem I aware is when multiple=20 >> >> >>> enumerations are part of >> >> >> the same union. >> >> >>> Value 4 from enumeration A will be encoded the same way as=20 >> >> >>> Value >> >> >>> 4 from >> >> >> enumeration B. >> >> >>=20 >> >> >> =E2=80=A6 and that is not a problem for the XML version, because t= he=20 >> >> >> string is being used instead of the value. (But then if two=20 >> >> >> enumerations share a string, you have the equivalent problem in=20 >> >> >> the XML serialization.) >> >> >>=20 >> >> >> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that act= ually=20 >> >> >> has this problem, so I would be a bit reluctant to make=20 >> >> >> CBOR-based implementations more complex (and less efficient) so so= lve this (non-?)problem. >> >> >>=20 >> >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> >=20 >> >> >=20 >> >> >=20 >> >>=20 >> >> _______________________________________________ >> >> netconf mailing list >> >> netconf@ietf.org >> >> https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw >> >> ww >> >> .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343e >> >> a8 >> >> d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7 >> >> C1 >> >> %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2 >> >> B0 >> >> kvPZgr4o%3D&reserved=3D0 >> > >> > --=20 >> > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> > Fax: +49 421 200 3103 >> > >> > _______________________________________________ >> > netconf mailing list >> > netconf@ietf.org >> > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w. >> > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343ea8 >> > d1=20 >> > cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1% >> > 7C=20 >> > 636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B0kv >> > PZ >> > gr4o%3D&reserved=3D0 >>=20 >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 > > > > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Mar 28 04:31:42 2019 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 2D295120495; Thu, 28 Mar 2019 04:31:33 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 rJxszafERvZG; Thu, 28 Mar 2019 04:31:27 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0861206AB; Thu, 28 Mar 2019 04:30:24 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 80A7DB23; Thu, 28 Mar 2019 12:30:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Q85Wbd4PVdug; Thu, 28 Mar 2019 12:30:21 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 28 Mar 2019 12:30:21 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 689EF200A8; Thu, 28 Mar 2019 12:30:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id yvUdl8jHnP1E; Thu, 28 Mar 2019 12:30:20 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 293A4200A7; Thu, 28 Mar 2019 12:30:20 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Thu, 28 Mar 2019 12:30:19 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 14C283007A0795; Thu, 28 Mar 2019 12:30:18 +0100 (CET) Date: Thu, 28 Mar 2019 12:30:18 +0100 From: Juergen Schoenwaelder To: Michel Veillette CC: Ladislav Lhotka , Carsten Bormann , "netconf@ietf.org" , "core@ietf.org" Message-ID: <20190328113018.uzujjtc7a2ukhovl@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Michel Veillette , Ladislav Lhotka , Carsten Bormann , "netconf@ietf.org" , "core@ietf.org" References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 28 Mar 2019 11:31:41 -0000 Michel, I think the YANG part of the problem needs to be resolved as part of the yang next effort. We now have an issue for it so this will not get lost. YANG extensions have their limits; you can not expect that client and server both understand an extension and hence it is a stretch to make the encoding of data depending on tags provided by extensions. So what we need is: a) A CBOR encoding that works with the current YANG rules (even if it may be less efficient CBOR). b) Work on a general solution for tagged unions as part of the YANG next effort. c) Eventually update the XML,JSON,CBOR encodings such that tagged unions are handled properly. Assuming you won't be willing to wait for b), you have to define something that works reasonably with YANG 1.1 (task a) and get prepared to update the CBOR encoding when the YANG next effort has settled on a solution (task c). /js On Wed, Mar 27, 2019 at 04:00:42PM +0000, Michel Veillette wrote: > Hi Juergen >=20 > You will find in attachment the updated version of 'test-union@2019-03-= 25.yang' based on your proposed solution, type tagging. > This module defines an extension called union-tag as follow: >=20 > extension union-tag { > argument tag { > yin-element true; > } > description > "In some cases, the interpretation of a value of a union type can= differ > when encoded using the different data format. This difference com= es from > the level of type information supported by the different data for= mats. > In the case of XML, all elements and attributes are encoded as st= ring > and no type information are included. JSON supports string, numbe= r and > boolean. Finally, CBOR supports all YANG basic types. >=20 > This extension can be used to add a tag to a type within a union = to > guarantee its proper interpretation when decoded."; > } >=20 > This extension can be used as follow: >=20 > leaf multiple-enumerations-test-2 { > type union { > type enumeration { > ext:union-tag weekdays; > enum "Monday"; > enum "Tuesday"; > enum "Wednesday"; > enum "Thursday"; > enum "Friday"; > } > type enumeration { > ext:union-tag weekend; > enum "Saturday"; > enum "Sunday"; > } > } > } >=20 > If I assume this solution or similar solution is implemented, the next = question is how this tag is encoded in CBOR. > Let assume that the data node SID is 1820 and the SID assigned to "week= days" tag is 1821. >=20 > When set to "Tuesday", this data node can be encoded using a CBOR map a= s follows: >=20 > { > 1820 : { "weekdays", 1} > } >=20 > Do we need to add a CBOR tag to this encoding to specify the use of a u= nion tag? (99 in this example) > I personally don't think so since the use of a CBOR map for a union dat= a node is not currently possible. >=20 > { > 1820 : (99) { "weekdays", 1} > } >=20 > Should we use a SID instead of the tag?=20 >=20 > { > 1820 : { 1821, 1} > } >=20 > Should we use a delta between the data node SID and the union tag SID? > The drawback of this approach is that the same value assigned to differ= ent data nodes is encoded differently. > I won't personally recommend this approach. >=20 > { > 1820 : { 1, 1} > } >=20 > I hope this email will help moving the discussion closer to the final s= olution. >=20 > Please comments > Michel >=20 > -----Original Message----- > From: Juergen Schoenwaelder =20 > Sent: Wednesday, March 27, 2019 2:17 AM > To: Michel Veillette > Cc: Ladislav Lhotka ; Carsten Bormann ; ne= tconf@ietf.org; core@ietf.org > Subject: Re: [netconf] YANG encoding in CBOR >=20 > Hi, >=20 > a union can be formed by using member types that are imported and not u= nder change control of a single author/organization and ideally this shou= ld work without complex coordination of name and number spaces. > Duplicate enum/bits values are legal in YANG today so an encoding has t= o deal with this aspect of life. >=20 > A robust fix to all these problems will be to tag the type members in o= rder to discriminate the values in the encodings. This, however, will tak= e some time to specify and we will need to preserve backwards compatibili= ty with unions without a tag (but compilers can encourage people to add t= ags whenever modules are updated). >=20 > /js >=20 > On Wed, Mar 27, 2019 at 01:12:52AM +0000, Michel Veillette wrote: > > Hi Ladislav > >=20 > > If I summarize this issue of multiple enumerations or bits in a union= , this problem can be solve by the following approaches: > >=20 > > - To not allows these duplicate values or positions to happen in YANG > > - To encode enumerations and bits as string (in all unions or only=20 > > when multiple enumerations or bits are defined) > > - To encode enumerations and bits as SID (in all unions or only when=20 > > multiple enumerations or bits are defined) > > - To encode enumerations and bits as delta between the value SID and=20 > > the leaf SID (in all unions or only when multiple enumerations or bit= s=20 > > are defined) > >=20 > > In this email, I will like to focus on the first option, fixing the p= roblem directly in YANG instead of fixing the consequences. > >=20 > > Without any changes in YANG, a union with multiple enumeration or bit= s can be constructed without value or position overlaps. > > For example: > >=20 > > leaf multiple-enumerations-test-1 { > > type union { > > type enumeration { > > enum "Monday" { value 0; } > > enum "Tuesday" { value 1; } > > enum "Wednesday" { value 2; } > > enum "Thursday" { value 3; } > > enum "Friday" { value 4; } > >=20 > > } > > type enumeration { > > enum "Saturday" { value 5; } > > enum "Sunday" { value 6; } > > } > > } > > } > >=20 > > leaf multiple-bits-test-1 { > > type union { > > type bits { > > bit "Monday" { position 0; } > > bit "Tuesday" { position 1; } > > bit "Wednesday" { position 2; } > > bit "Thursday" { position 3; } > > bit "Friday" { position 4; } > >=20 > > } > > type bits { > > bit "Saturday" { position 5; } > > bit "Sunday" { position 6; } > > } > > } > > } > >=20 > > When using already defined typedef, avoiding overlap is less obvious = without some help. > > To help building unions with already defined typedefs, I propose to i= ntroduce two extensions.=20 > >=20 > > extension value-offset { > > argument offset { > > yin-element true; > > } > > description > > "Offset added to each enum value of the associated enumeration.= "; > > } > > =20 > > extension position-offset { > > argument offset { > > yin-element true; > > } > > description > > "Offset value added to each bit position of the associated bits= ."; > > } > >=20 > > The value-offset extension can be used as follow: > >=20 > > type enumeration { > > enum "Monday"; > > enum "Tuesday"; > > enum "Wednesday"; > > enum "Thursday"; > > enum "Friday"; > > } > > } > >=20 > > typedef weekend { > > type enumeration { > > enum "Saturday"; > > enum "Sunday"; > > } > > } > > =20 > > leaf multiple-enumerations-test-3 { > > type union { > > type weekdays; > > type weekend { > > ext:value-offset 5; > > } > > } > > } > >=20 > > The position-offset extension can be used as follow: > >=20 > > typedef weekdays-flags { > > type bits { > > bit "Monday"; > > bit "Tuesday"; > > bit "Wednesday"; > > bit "Thursday"; > > bit "Friday"; > > } > > } > >=20 > > typedef weekend-flags { > > type bits { > > bit "Saturday"; > > bit "Sunday"; > > } > > } > > =20 > > leaf multiple-bits-test-3 { > > type union { > > type weekdays-flags; > > type weekend-flags { > > ext:position-offset 5; > > } > > } > > } > >=20 > > The yang file in attachment show different examples based on this app= roach. > > This module have been validated using=20 > > https://can01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fww= w.y > > angvalidator.com%2Fvalidator&data=3D02%7C01%7C%7Cc69426dcaaf8448e= 1d4 > > 708d6b27bc735%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C6368926420= 7 > > 3257660&sdata=3DXqo40lzBjINVFZhIZZI1LEktAdq5mee2AdxeYqefnsA%3D&am= p;r > > eserved=3D0 If this approach is accepted, tools like pyang should be=20 > > updated to produce an error if multiple enumerations or bits are defi= ned with value or position overleaps. > >=20 > > Please comment, > > Michel > >=20 > > -----Original Message----- > > From: Ladislav Lhotka > > Sent: Monday, March 25, 2019 4:07 AM > > To: Juergen Schoenwaelder ;=20 > > Carsten Bormann > > Cc: Michel Veillette ;=20 > > netconf@ietf.org; core@ietf.org > > Subject: Re: [netconf] YANG encoding in CBOR > >=20 > > Juergen Schoenwaelder writes: > >=20 > > > I think we need to look at the whole picture and in which direction= =20 > > > we want to go. In the longer term, I would prefer a solution where=20 > > > the values of a union are discriminated. The current XML encoding=20 > > > behaviour of 'first match wins' is fragile (for example, if someone= =20 > > > adds an enum to a type, the interpretation of data can change). > > > > > > Look at this: > > > > > > typedef bar { > > > type union { > > > type enumeration { enum "1"; value 2; enum "2"; value 1; } > > > type uint8; > > > } > > > } > > > > > > We have some encodings that send the string representations of the=20 > > > values and some encodings that prefer to send numeric=20 > > > representations where possible. In order to have a robust solution,= =20 > > > encodings should likely indicate to which type the value belongs. > >=20 > > Perhaps the easiest way would be to use (optional) annotation that sp= ecifies, using an ordinal number, which of the member types is used for t= he particular instance. But since there can be unions inside unions, a li= st of numbers would be needed in general. > >=20 > > Lada > >=20 > > > > > > /js > > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > > >> Well, if that is a problem, we can go for a longer representation = within unions (section 6.12). Theoretically, we could do that only of th= ere is more than one enum in the union type (so things stay efficient if = there is only one), but that might pose difficulties with model evolution= . > > >>=20 > > >> Going for a string representation repeats the feature of XML YANG = (which was ported over to JSON YANG): > > >>=20 > > >> typedef foo { > > >> type union { > > >> type enumeration { > > >> enum red { value 1; } > > >> enum breen { value 2; } > > >> enum glue { value 3; } > > >> } > > >> type enumeration { > > >> enum tacks { value 1; } > > >> enum nails { value 2; } > > >> enum glue { value 3; } > > >> } > > >> } > > >> } > > >>=20 > > >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of= the enumerations are being used. > > >>=20 > > >> Using SIDs, we can do better. > > >>=20 > > >> So what do we have to do to get the SID tool to allocate SIDs for = enum values? > > >>=20 > > >> We could then define the CBOR tag for enums in unions to take the = usual SID difference (delta relative to the environment, I=E2=80=99d thin= k), not an integer value. > > >>=20 > > >> Several of us are at the hackathon and could make something happen= today and tomorrow. > > >>=20 > > >> Gr=C3=BC=C3=9Fe, Carsten > > >>=20 > > >>=20 > > >> > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) wrote: > > >> >=20 > > >> > I guess that the concern is that this introduces more variation = in how data is interpreted between the different XML/JSON/CBOR encodings. > > >> >=20 > > >> > E.g. if someone switched from XML to CBOR, suddenly the configur= ation or state data may have a different meaning. > > >> >=20 > > >> > Thanks, > > >> > Rob > > >> >=20 > > >> >=20 > > >> >> -----Original Message----- > > >> >> From: Carsten Bormann > > >> >> Sent: 22 March 2019 16:08 > > >> >> To: Michel Veillette > > >> >> Cc: Rob Wilton (rwilton) ; core@ietf.org;=20 > > >> >> netconf@ietf.org > > >> >> Subject: Re: [netconf] YANG encoding in CBOR > > >> >>=20 > > >> >> On Mar 22, 2019, at 16:45, Michel Veillette=20 > > >> >> > > >> >> wrote: > > >> >>>=20 > > >> >>> The only potential problem I aware is when multiple=20 > > >> >>> enumerations are part of > > >> >> the same union. > > >> >>> Value 4 from enumeration A will be encoded the same way as=20 > > >> >>> Value > > >> >>> 4 from > > >> >> enumeration B. > > >> >>=20 > > >> >> =E2=80=A6 and that is not a problem for the XML version, becaus= e the=20 > > >> >> string is being used instead of the value. (But then if two=20 > > >> >> enumerations share a string, you have the equivalent problem in= =20 > > >> >> the XML serialization.) > > >> >>=20 > > >> >> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that = actually=20 > > >> >> has this problem, so I would be a bit reluctant to make=20 > > >> >> CBOR-based implementations more complex (and less efficient) so= solve this (non-?)problem. > > >> >>=20 > > >> >> Gr=C3=BC=C3=9Fe, Carsten > > >> >=20 > > >> >=20 > > >> >=20 > > >>=20 > > >> _______________________________________________ > > >> netconf mailing list > > >> netconf@ietf.org > > >> https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fw > > >> ww > > >> .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C3= 43e > > >> a8 > > >> d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%= 7 > > >> C1 > > >> %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaO= b%2 > > >> B0 > > >> kvPZgr4o%3D&reserved=3D0 > > > > > > --=20 > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germ= any > > > Fax: +49 421 200 3103 > > > > > > > > > On Sat, Mar 23, 2019 at 10:03:32AM +0100, Carsten Bormann wrote: > > >> Well, if that is a problem, we can go for a longer representation = within unions (section 6.12). Theoretically, we could do that only of th= ere is more than one enum in the union type (so things stay efficient if = there is only one), but that might pose difficulties with model evolution= . > > >>=20 > > >> Going for a string representation repeats the feature of XML YANG = (which was ported over to JSON YANG): > > >>=20 > > >> typedef foo { > > >> type union { > > >> type enumeration { > > >> enum red { value 1; } > > >> enum breen { value 2; } > > >> enum glue { value 3; } > > >> } > > >> type enumeration { > > >> enum tacks { value 1; } > > >> enum nails { value 2; } > > >> enum glue { value 3; } > > >> } > > >> } > > >> } > > >>=20 > > >> If you use =E2=80=9Cglue=E2=80=9D, you don=E2=80=99t know which of= the enumerations are being used. > > >>=20 > > >> Using SIDs, we can do better. > > >>=20 > > >> So what do we have to do to get the SID tool to allocate SIDs for = enum values? > > >>=20 > > >> We could then define the CBOR tag for enums in unions to take the = usual SID difference (delta relative to the environment, I=E2=80=99d thin= k), not an integer value. > > >>=20 > > >> Several of us are at the hackathon and could make something happen= today and tomorrow. > > >>=20 > > >> Gr=C3=BC=C3=9Fe, Carsten > > >>=20 > > >>=20 > > >> > On Mar 22, 2019, at 18:30, Rob Wilton (rwilton) wrote: > > >> >=20 > > >> > I guess that the concern is that this introduces more variation = in how data is interpreted between the different XML/JSON/CBOR encodings. > > >> >=20 > > >> > E.g. if someone switched from XML to CBOR, suddenly the configur= ation or state data may have a different meaning. > > >> >=20 > > >> > Thanks, > > >> > Rob > > >> >=20 > > >> >=20 > > >> >> -----Original Message----- > > >> >> From: Carsten Bormann > > >> >> Sent: 22 March 2019 16:08 > > >> >> To: Michel Veillette > > >> >> Cc: Rob Wilton (rwilton) ; core@ietf.org;=20 > > >> >> netconf@ietf.org > > >> >> Subject: Re: [netconf] YANG encoding in CBOR > > >> >>=20 > > >> >> On Mar 22, 2019, at 16:45, Michel Veillette=20 > > >> >> > > >> >> wrote: > > >> >>>=20 > > >> >>> The only potential problem I aware is when multiple=20 > > >> >>> enumerations are part of > > >> >> the same union. > > >> >>> Value 4 from enumeration A will be encoded the same way as=20 > > >> >>> Value > > >> >>> 4 from > > >> >> enumeration B. > > >> >>=20 > > >> >> =E2=80=A6 and that is not a problem for the XML version, becaus= e the=20 > > >> >> string is being used instead of the value. (But then if two=20 > > >> >> enumerations share a string, you have the equivalent problem in= =20 > > >> >> the XML serialization.) > > >> >>=20 > > >> >> Anyway, I haven=E2=80=99t seen a piece of real-world YANG that = actually=20 > > >> >> has this problem, so I would be a bit reluctant to make=20 > > >> >> CBOR-based implementations more complex (and less efficient) so= solve this (non-?)problem. > > >> >>=20 > > >> >> Gr=C3=BC=C3=9Fe, Carsten > > >> >=20 > > >> >=20 > > >> >=20 > > >>=20 > > >> _______________________________________________ > > >> netconf mailing list > > >> netconf@ietf.org > > >> https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fw > > >> ww > > >> .ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C3= 43e > > >> a8 > > >> d1cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%= 7 > > >> C1 > > >> %7C636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaO= b%2 > > >> B0 > > >> kvPZgr4o%3D&reserved=3D0 > > > > > > --=20 > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germ= any > > > Fax: +49 421 200 3103 > > > > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Fwww. > > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D02%7C01%7C%7C343= ea8 > > > d1=20 > > > cf8f4e39afc708d6b0f8d874%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C1= % > > > 7C=20 > > > 636890980182553400&sdata=3Du1KFAYAus16B8a7sgsBfPfIquOptMlaOb%2B= 0kv > > > PZ > > > gr4o%3D&reserved=3D0 > >=20 > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 >=20 >=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Mar 28 06:47:07 2019 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 0730A1204AF; Thu, 28 Mar 2019 06:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 bwC5fswHYFrN; Thu, 28 Mar 2019 06:46:56 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCC801204AA; Thu, 28 Mar 2019 06:46:55 -0700 (PDT) Received: from client-0188.vpn.uni-bremen.de (client-0188.vpn.uni-bremen.de [134.102.107.188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44VR4F2G0lzybw; Thu, 28 Mar 2019 14:46:53 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <20190328113018.uzujjtc7a2ukhovl@anna.jacobs.jacobs-university.de> Date: Thu, 28 Mar 2019 14:46:52 +0100 Cc: Michel Veillette , Ladislav Lhotka , "netconf@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 575473610.430299-1be8c2a53aee320582306091876de64f Content-Transfer-Encoding: quoted-printable Message-Id: <4656560A-2135-4F51-B3E7-8DB31B43B17D@tzi.org> References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <20190328113018.uzujjtc7a2ukhovl@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 28 Mar 2019 13:47:06 -0000 So for enum/bits we are back to value outside, string inside union? Can we use SIDs instead of the strings for the latter? This can=E2=80=99t be much more complicated than assigning a SID to each = string that occurs in an enum/bits in a union. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Mar 28 07:06:28 2019 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 0CAD7120318; Thu, 28 Mar 2019 07:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.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 ObMS8pxHtdcC; Thu, 28 Mar 2019 07:06:21 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-eopbgr800101.outbound.protection.outlook.com [40.107.80.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E50B120274; Thu, 28 Mar 2019 07:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2kiZbIVUZWwTFQNkbiDo10EzVN4UyN8cz1gP3vevvDM=; b=ee4KIKlE5VCECLiqskW+Poru78SjFKyn775DoUVchBL29bG1+DYNbVTqJPLLSFfx/JKZbxDTfLyENUPfSnbRQz5y09+WO47mGX6ENmPYj04lZOyNNMEdv8hCGbPkHtYYyAp9tUqkj3HVq1Of/oS9QumHX3PDh/N0LldQqi0SLAs= Received: from BL0PR06MB5042.namprd06.prod.outlook.com (10.167.240.31) by BL0PR06MB4370.namprd06.prod.outlook.com (10.167.181.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Thu, 28 Mar 2019 14:06:17 +0000 Received: from BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::6d4a:3963:7ffb:1f30]) by BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::6d4a:3963:7ffb:1f30%2]) with mapi id 15.20.1750.017; Thu, 28 Mar 2019 14:06:17 +0000 From: Michel Veillette To: Carsten Bormann , Juergen Schoenwaelder CC: Ladislav Lhotka , "netconf@ietf.org" , "core@ietf.org" Thread-Topic: [netconf] YANG encoding in CBOR Thread-Index: AdTf3q8hCOPNH5o0Q0SJZRQQHN87VgA3tcGQAAL8XAAAAtt/gAAgmRkAAAJStYAAYEUIgABUqX2QAAwU1oAAE3mQoAApxZcAAATFAAAAAF65QA== Date: Thu, 28 Mar 2019 14:06:17 +0000 Message-ID: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <20190328113018.uzujjtc7a2ukhovl@anna.jacobs.jacobs-university.de> <4656560A-2135-4F51-B3E7-8DB31B43B17D@tzi.org> In-Reply-To: <4656560A-2135-4F51-B3E7-8DB31B43B17D@tzi.org> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a02707fd-b61b-463f-9b29-08d6b3868c17 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4370; x-ms-traffictypediagnostic: BL0PR06MB4370: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0990C54589 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(376002)(396003)(136003)(39840400004)(189003)(199004)(13464003)(7696005)(53546011)(99286004)(102836004)(2906002)(76176011)(6506007)(186003)(26005)(97736004)(446003)(11346002)(476003)(486006)(106356001)(105586002)(3846002)(478600001)(6116002)(72206003)(14454004)(53936002)(93886005)(86362001)(81166006)(81156014)(8676002)(74316002)(52536014)(7736002)(305945005)(229853002)(8936002)(6436002)(66066001)(110136005)(54906003)(25786009)(55016002)(68736007)(316002)(6306002)(9686003)(4326008)(5660300002)(6246003)(71190400001)(71200400001)(256004)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4370; H:BL0PR06MB5042.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 2P6tUx3NXX8VZ/OTL7Ty1GGsiiOR7BnnveggRF9Zr4G02NEnA1KFjAz4qTjyu4YNiwnLQbEoPxO2z+ulgsJGfvONqPX8ew5BweA5WyAnlkyfi77InuoUvxEW/rCMYf+qzCUnOX1TEiliBwEhxaaORRHmJRqdqWXCr4YPYVmwP9gyJtgUe1qefYGVeszmWgKSShFcKi0qIRR5LA4wTzIVcaq94OlQFIHhTrLFHK0hLtJrcRzaabt8fjQTtTX1fXjJCmxr/l9Nv3/AfNLu8t+vGpTqGzxUmnorUMpc6CSurbRQvAB7KhMKcXYfUEWd8UvxIScQ/SB6RgSpLe/ZwQ8R7lqREyMWRBli3Dy4Qy+NFxtkAaQUHxuXh4jp4v/kY45c6B9hnFfwD+BEeG+wdEsi4qS7/RY8aYjt+l+0CgE5Iww= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: a02707fd-b61b-463f-9b29-08d6b3868c17 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2019 14:06:17.5429 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4370 Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 28 Mar 2019 14:06:27 -0000 KzEgZm9yIHZhbHVlIG91dHNpZGUsIHN0cmluZyBpbnNpZGUgdW5pb24NCg0KTXkgcmF0aW9uYWw6 DQoNCi0gU0lEIGNhbiBoYXZlIHVwIHRvIDggYnl0ZXMgYW5kIHdpbGwgcHJvdmlkZSBhIG1hcmdp bmFsIGNvbXByZXNzaW9uLg0KLSBHZW5lcmF0aW5nIFNJRCBmb3IgYWxsICdlbnVtZXJhdGlvbicg YW5kICdiaXRzJyBpbiBjYXNlIHRoZXkgYXJlIHVzZWQgaW4gJ3VuaW9uJyBpcyBsb3Qgb2Ygb3Zl cmhlYWQgdG8gcmV2b2x2ZSBhIGNvcm5lciBjYXNlLg0KLSBZQU5HIGFsc28gc3VwcG9ydCB0aGUg J2Nob2ljZScgc3RhdGVtZW50IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzk1MCNz ZWN0aW9uLTQuMi43KSB3aGljaCBpcyBzaW1pbGFyIHRvDQogICB0aGUgY29uY2VwdCBvZiB0eXBl IHRhZ2dpbmcgd2l0aGluIHVuaW9uLiBUaGlzIGNvbnN0cnVjdCBjYW4gYmUgdXNlZCBieSBZQU5H IG1vZHVsZXMgc3BlY2lmaWNhbGx5IGNyZWF0ZWQgZm9yDQogIGVtYmVkZGVkIGFwcGxpY2F0aW9u cyB0byB0YWtlIGFkdmFudGFnZSBvZiAnZW51bWVyYXRpb24nIGVuY29kZWQgYXMgdmFsdWUgYW5k ICdiaXRzJyBlbmNvZGVkIGFzIGJpdC4NCg0KTWljaGVsDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPiANClNlbnQ6IFRo dXJzZGF5LCBNYXJjaCAyOCwgMjAxOSA5OjQ3IEFNDQpUbzogSnVlcmdlbiBTY2hvZW53YWVsZGVy IDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+DQpDYzogTWljaGVsIFZlaWxs ZXR0ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQuY29tPjsgTGFkaXNsYXYgTGhvdGthIDxs aG90a2FAbmljLmN6PjsgbmV0Y29uZkBpZXRmLm9yZzsgY29yZUBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtuZXRjb25mXSBZQU5HIGVuY29kaW5nIGluIENCT1INCg0KU28gZm9yIGVudW0vYml0cyB3 ZSBhcmUgYmFjayB0byB2YWx1ZSBvdXRzaWRlLCBzdHJpbmcgaW5zaWRlIHVuaW9uPw0KQ2FuIHdl IHVzZSBTSURzIGluc3RlYWQgb2YgdGhlIHN0cmluZ3MgZm9yIHRoZSBsYXR0ZXI/DQpUaGlzIGNh buKAmXQgYmUgbXVjaCBtb3JlIGNvbXBsaWNhdGVkIHRoYW4gYXNzaWduaW5nIGEgU0lEIHRvIGVh Y2ggc3RyaW5nIHRoYXQgb2NjdXJzIGluIGFuIGVudW0vYml0cyBpbiBhIHVuaW9uLg0KDQpHcsO8 w59lLCBDYXJzdGVuDQoNCg== From nobody Thu Mar 28 07:30:57 2019 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 595171204BB; Thu, 28 Mar 2019 07:30:44 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 lD_bQ5UP1GPW; Thu, 28 Mar 2019 07:30:39 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC8B1204D1; Thu, 28 Mar 2019 07:30:35 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 9A977B23; Thu, 28 Mar 2019 15:30:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id zlVCyeSHjk3Z; Thu, 28 Mar 2019 15:30:33 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 28 Mar 2019 15:30:33 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 79C55200AC; Thu, 28 Mar 2019 15:30:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id u7ra-Qv1iXeU; Thu, 28 Mar 2019 15:30:33 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 2EDDC200A7; Thu, 28 Mar 2019 15:30:33 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Thu, 28 Mar 2019 15:30:32 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 41B6F3007A0C2A; Thu, 28 Mar 2019 15:30:32 +0100 (CET) Date: Thu, 28 Mar 2019 15:30:31 +0100 From: Juergen Schoenwaelder To: Michel Veillette CC: Carsten Bormann , Ladislav Lhotka , "netconf@ietf.org" , "core@ietf.org" Message-ID: <20190328143031.ho7nmhpg4jb373p7@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Michel Veillette , Carsten Bormann , Ladislav Lhotka , "netconf@ietf.org" , "core@ietf.org" References: <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <20190328113018.uzujjtc7a2ukhovl@anna.jacobs.jacobs-university.de> <4656560A-2135-4F51-B3E7-8DB31B43B17D@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 28 Mar 2019 14:30:56 -0000 I agree with your points. It seems this is the best we can do right now and hopefully we can do better in the future. /js On Thu, Mar 28, 2019 at 02:06:17PM +0000, Michel Veillette wrote: > +1 for value outside, string inside union >=20 > My rational: >=20 > - SID can have up to 8 bytes and will provide a marginal compression. > - Generating SID for all 'enumeration' and 'bits' in case they are used= in 'union' is lot of overhead to revolve a corner case. > - YANG also support the 'choice' statement (https://tools.ietf.org/html= /rfc7950#section-4.2.7) which is similar to > the concept of type tagging within union. This construct can be used= by YANG modules specifically created for > embedded applications to take advantage of 'enumeration' encoded as v= alue and 'bits' encoded as bit. >=20 > Michel >=20 >=20 > -----Original Message----- > From: Carsten Bormann =20 > Sent: Thursday, March 28, 2019 9:47 AM > To: Juergen Schoenwaelder > Cc: Michel Veillette ; Ladislav Lhotka = ; netconf@ietf.org; core@ietf.org > Subject: Re: [netconf] YANG encoding in CBOR >=20 > So for enum/bits we are back to value outside, string inside union? > Can we use SIDs instead of the strings for the latter? > This can=E2=80=99t be much more complicated than assigning a SID to eac= h string that occurs in an enum/bits in a union. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Mar 28 07:40:40 2019 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 022D31204DC for ; Thu, 28 Mar 2019 07:40:24 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.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 Ay6sy1gNEbCc for ; Thu, 28 Mar 2019 07:40:19 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 B706B1202BA for ; Thu, 28 Mar 2019 07:40:18 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id y13so5519207wrd.3 for ; Thu, 28 Mar 2019 07:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=SwjP9ELAmVPGfOjvjJcTg+zAXje9vGlU7RzYOrp8g1A=; b=OFENi4WB2FBdtDyU1keOe0mfCkfXBoTIsZwLjJ6E1w49nxaiX1MHmHLnDCLHnoSsD0 NVpROLZnkcHUfd9a6KB4VhKnqoU3lWVxjd2kpGEcRm/6Db5FLV5fpKck0ncEu8g+6dvB fd/dD7ZwypvhYZb3E31AA2Rq+uT39ieBNP8HdJdeR2lqcj3i8bZmaP01jSWu0YYDojuZ 6JbXrHCNe1EvsH9ot6f5GKc3bbIW8x+2J0kW2D0o8xeezQv1tnBQtL4YIMe+VL1CNKJK pNokMU/svCpU3o98nilTQVqvNVcqAq4R/T2lZghP/tpXPJXtvMUxDjOilp8xtwsCyOaI ispA== 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; bh=SwjP9ELAmVPGfOjvjJcTg+zAXje9vGlU7RzYOrp8g1A=; b=LbOGcYwo2NlIHWFWKhGr2WQtCydfc9fr3bVk0TLmnPsez49/rctzVHxPZt/2agpoPI zewbF70F2BbEQ4oNIJo4d4XjRy1Z/BelQ4lgiG/EdBiglG1mdfWDF1jBOH6Jh4qvx1rD gt4d5fPAEs3D3XQtkxstoJrBntgP/Ptz613Cop2Q6Cg8YVTPijWtWj476W5gvcvPPXte K7ugGZNs7X924Wz7b/IDJcvJ5tp43qVctROZPwyP3fJ190IpcvlTHQsW58pRPGqaf1qT 5Q7R031bBeMBFile1PdrVvDmrGe8S1gMpof9GHVaLmrpjhPKfsVxXNVBFBSPadosBtge bpuw== X-Gm-Message-State: APjAAAXsrT7Ej5T2X00fFeLVssXwcL7+0OCoeE1Vd84XpFKqG03eL7zk LJGRkKewr+uorzFYjsR3NYzQIPIXZ1v1dcmIvwLIYQ== X-Google-Smtp-Source: APXvYqzynPH2NhkNOYS4t29EWjddpTPDZB8c0u9yNJ/hYXRs382jVnfpPepEItOexBYNATXKWcsagHCUjT9ImYcnusM= X-Received: by 2002:adf:b68d:: with SMTP id j13mr24358856wre.50.1553784017070; Thu, 28 Mar 2019 07:40:17 -0700 (PDT) MIME-Version: 1.0 References: <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <20190328113018.uzujjtc7a2ukhovl@anna.jacobs.jacobs-university.de> <4656560A-2135-4F51-B3E7-8DB31B43B17D@tzi.org> <20190328143031.ho7nmhpg4jb373p7@anna.jacobs.jacobs-university.de> In-Reply-To: <20190328143031.ho7nmhpg4jb373p7@anna.jacobs.jacobs-university.de> From: ivaylo petrov Date: Thu, 28 Mar 2019 15:39:50 +0100 Message-ID: To: Juergen Schoenwaelder , Michel Veillette , Carsten Bormann , Ladislav Lhotka , "netconf@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="000000000000654178058528889f" Archived-At: Subject: Re: [netconf] [core] YANG encoding in CBOR 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, 28 Mar 2019 14:40:31 -0000 --000000000000654178058528889f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, I also support value outside and string inside unions. Michel gave a rather good rationale why this is a good option and for me this seems as the best option available right now. Best regards, Ivaylo On Thu, Mar 28, 2019 at 3:32 PM Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > I agree with your points. It seems this is the best we can do right > now and hopefully we can do better in the future. > > /js > > On Thu, Mar 28, 2019 at 02:06:17PM +0000, Michel Veillette wrote: > > +1 for value outside, string inside union > > > > My rational: > > > > - SID can have up to 8 bytes and will provide a marginal compression. > > - Generating SID for all 'enumeration' and 'bits' in case they are used > in 'union' is lot of overhead to revolve a corner case. > > - YANG also support the 'choice' statement ( > https://tools.ietf.org/html/rfc7950#section-4.2.7) which is similar to > > the concept of type tagging within union. This construct can be used > by YANG modules specifically created for > > embedded applications to take advantage of 'enumeration' encoded as > value and 'bits' encoded as bit. > > > > Michel > > > > > > -----Original Message----- > > From: Carsten Bormann > > Sent: Thursday, March 28, 2019 9:47 AM > > To: Juergen Schoenwaelder > > Cc: Michel Veillette ; Ladislav Lhotka = < > lhotka@nic.cz>; netconf@ietf.org; core@ietf.org > > Subject: Re: [netconf] YANG encoding in CBOR > > > > So for enum/bits we are back to value outside, string inside union? > > Can we use SIDs instead of the strings for the latter? > > This can=E2=80=99t be much more complicated than assigning a SID to eac= h string > that occurs in an enum/bits in a union. > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --000000000000654178058528889f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I also su= pport value outside and string inside unions. Michel gave a rather good rat= ionale why this is a good option and for me this seems as the best option a= vailable right now.

Best regards,
Ivaylo

On Thu, Mar 28, 2019 at 3:32 PM Juergen Schoenwaelder <= ;j.schoenwaelder@ja= cobs-university.de> wrote:
I agree with your points. It seems this is the best we ca= n do right
now and hopefully we can do better in the future.

/js

On Thu, Mar 28, 2019 at 02:06:17PM +0000, Michel Veillette wrote:
> +1 for value outside, string inside union
>
> My rational:
>
> - SID can have up to 8 bytes and will provide a marginal compression.<= br> > - Generating SID for all 'enumeration' and 'bits' in c= ase they are used in 'union' is lot of overhead to revolve a corner= case.
> - YANG also support the 'choice' statement (https://tools.ietf.org/html/rfc7950#section-4.2.7) which is simil= ar to
>=C2=A0 =C2=A0 the concept of type tagging within union. This construct = can be used by YANG modules specifically created for
>=C2=A0 =C2=A0embedded applications to take advantage of 'enumeratio= n' encoded as value and 'bits' encoded as bit.
>
> Michel
>
>
> -----Original Message-----
> From: Carsten Bormann <cabo@tzi.org>
> Sent: Thursday, March 28, 2019 9:47 AM
> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de&= gt;
> Cc: Michel Veillette <Michel.Veillette@trilliant.com>; Ladislav Lho= tka <lhotka@nic.cz>; netconf@ietf.o= rg; core@ietf.org
> Subject: Re: [netconf] YANG encoding in CBOR
>
> So for enum/bits we are back to value outside, string inside union? > Can we use SIDs instead of the strings for the latter?
> This can=E2=80=99t be much more complicated than assigning a SID to ea= ch string that occurs in an enum/bits in a union.
>
> Gr=C3=BC=C3=9Fe, Carsten
>

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--000000000000654178058528889f-- From nobody Thu Mar 28 08:51:09 2019 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 4769E1203C7 for ; Thu, 28 Mar 2019 08:50:51 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 TKZ5qzCuz-fB for ; Thu, 28 Mar 2019 08:50:48 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 A177D120298 for ; Thu, 28 Mar 2019 08:50:47 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id y6so18072531ljd.12 for ; Thu, 28 Mar 2019 08:50:47 -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=VBi5/65t6qirOCDG0oQiS2Vlet1D9L3yon1BaCSU56s=; b=e3DYuFI6VeYHH2OSyfFI9NBL6btTZJwfy6uq998x/CyLUMOKJcp1TEDGNI8NI6bTkB SNdaWPIKlTzJFAllJs6tOqOl4CT5U2toC1aGep8jAQTUmPkcYJoKeCkmIv7Q12CX5jXZ 1eybxGYumQrcZ7kWRR4VerRH4qPWPeKBsHX4vrOlofRwn/zpO3krzd/YceNfUHcUpcaZ EQDedpeG9aYFJ6V97i9roDhoM+L9XnExLmCvZOLqVIRL5uVmDptwN+ea0hKtgb/KiMbL 616nFZrYxikCJHdXvdBLYDUCQ1BnXTtEp3Q09CUeA/rBKTjxZcxqKgZ6baJAkXk1XoZj oQrg== 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=VBi5/65t6qirOCDG0oQiS2Vlet1D9L3yon1BaCSU56s=; b=UbwXOVZhroj6IxpTXCLxfOGK84yEQ84z5bTIMBazTBNVDt4+aD4CADjpk8yigDjt/d umEujcQD9S7/b/lXT1SKBbUB6e48JdId8da+9khdxvl8GjwL8UeMF+iJOmi5PKE52sK8 ya4sfhygtWGZblmBx+dgRxUSZhTYK6M29np80MBYqckFzrk7rM3JHQvcGxog9fpzHwO1 IB5X1jpRDmQpMxT1T2okJj+b0PSrDCyy3yfWL1qQKsr2u6yRDzrWQMjXzQ0q878ariI7 k2mK2AQpPg+s7o8m0oZuN98rgKWkWQ5OH+4p5RX3UAAmDVXXcUW9l06dfXz5lQrfhXzm cPWg== X-Gm-Message-State: APjAAAXUWoGLyaSG6aLeddnpfcSHJAgce3OjF/tQz859cIu0w/9dikXH 121a6XVXgA9PXc2oqWZCtmEh3z8lQl5gFUT0AlzvUQ== X-Google-Smtp-Source: APXvYqz9ioTdszjv1p3sR6NiPNMOd8FocSqCh6twmMD75nfYaf6FfNORIEwCP7VyKKqwoU5dHPqXutogWDKcTMzv/oI= X-Received: by 2002:a2e:9e4d:: with SMTP id g13mr10393892ljk.12.1553788245832; Thu, 28 Mar 2019 08:50:45 -0700 (PDT) MIME-Version: 1.0 References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <20190328113018.uzujjtc7a2ukhovl@anna.jacobs.jacobs-university.de> <4656560A-2135-4F51-B3E7-8DB31B43B17D@tzi.org> In-Reply-To: From: Andy Bierman Date: Thu, 28 Mar 2019 08:50:34 -0700 Message-ID: To: Michel Veillette Cc: Carsten Bormann , Juergen Schoenwaelder , "core@ietf.org" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="00000000000073086d058529847c" Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 28 Mar 2019 15:50:55 -0000 --00000000000073086d058529847c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 28, 2019 at 7:06 AM Michel Veillette < Michel.Veillette@trilliant.com> wrote: > +1 for value outside, string inside union > > This is simple, but I was trying to support some very common types (like ip-address) that are unions of strings, and are desirable to send as binary instead of string representation. Andy My rational: > > - SID can have up to 8 bytes and will provide a marginal compression. > - Generating SID for all 'enumeration' and 'bits' in case they are used i= n > 'union' is lot of overhead to revolve a corner case. > - YANG also support the 'choice' statement ( > https://tools.ietf.org/html/rfc7950#section-4.2.7) which is similar to > the concept of type tagging within union. This construct can be used b= y > YANG modules specifically created for > embedded applications to take advantage of 'enumeration' encoded as > value and 'bits' encoded as bit. > > Michel > > > -----Original Message----- > From: Carsten Bormann > Sent: Thursday, March 28, 2019 9:47 AM > To: Juergen Schoenwaelder > Cc: Michel Veillette ; Ladislav Lhotka < > lhotka@nic.cz>; netconf@ietf.org; core@ietf.org > Subject: Re: [netconf] YANG encoding in CBOR > > So for enum/bits we are back to value outside, string inside union? > Can we use SIDs instead of the strings for the latter? > This can=E2=80=99t be much more complicated than assigning a SID to each = string > that occurs in an enum/bits in a union. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --00000000000073086d058529847c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Mar 28, 2019 at 7:06 AM Miche= l Veillette <Michel.Ve= illette@trilliant.com> wrote:
+1 for value outside, string inside union


This is simple, but I was trying to su= pport some very common types (like ip-address)
that are unions of= strings, and are desirable to send as binary instead of string representat= ion.

Andy

My rational:

- SID can have up to 8 bytes and will provide a marginal compression.
- Generating SID for all 'enumeration' and 'bits' in case t= hey are used in 'union' is lot of overhead to revolve a corner case= .
- YANG also support the 'choice' statement (https://tools.ietf.org/html/rfc7950#section-4.2.7) which is similar to=
=C2=A0 =C2=A0the concept of type tagging within union. This construct can b= e used by YANG modules specifically created for
=C2=A0 embedded applications to take advantage of 'enumeration' enc= oded as value and 'bits' encoded as bit.

Michel


-----Original Message-----
From: Carsten Bormann <cabo@tzi.org>
Sent: Thursday, March 28, 2019 9:47 AM
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Cc: Michel Veillette <Michel.Veillette@trilliant.com>; Ladislav Lhotka &= lt;lhotka@nic.cz>= ; netconf@ietf.org; core@ietf.org
Subject: Re: [netconf] YANG encoding in CBOR

So for enum/bits we are back to value outside, string inside union?
Can we use SIDs instead of the strings for the latter?
This can=E2=80=99t be much more complicated than assigning a SID to each st= ring that occurs in an enum/bits in a union.

Gr=C3=BC=C3=9Fe, Carsten

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--00000000000073086d058529847c-- From nobody Thu Mar 28 09:07:22 2019 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 E116C120096; Thu, 28 Mar 2019 09:07:20 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 JF2nKNAHHcfK; Thu, 28 Mar 2019 09:07:18 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF337120003; Thu, 28 Mar 2019 09:07:17 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 48B0340; Thu, 28 Mar 2019 17:07:16 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id EhkNaw8KA5qc; Thu, 28 Mar 2019 17:07:16 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 28 Mar 2019 17:07:16 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 304B0200A8; Thu, 28 Mar 2019 17:07:16 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id fdp1hkBlsV4D; Thu, 28 Mar 2019 17:07:15 +0100 (CET) Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id E7CE8200A7; Thu, 28 Mar 2019 17:07:15 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Thu, 28 Mar 2019 17:07:15 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 1816C3007A1080; Thu, 28 Mar 2019 17:07:14 +0100 (CET) Date: Thu, 28 Mar 2019 17:07:14 +0100 From: Juergen Schoenwaelder To: Andy Bierman CC: Michel Veillette , Carsten Bormann , "core@ietf.org" , "netconf@ietf.org" Message-ID: <20190328160714.uuzfvxrjjxflktg5@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , Michel Veillette , Carsten Bormann , "core@ietf.org" , "netconf@ietf.org" References: <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <20190328113018.uzujjtc7a2ukhovl@anna.jacobs.jacobs-university.de> <4656560A-2135-4F51-B3E7-8DB31B43B17D@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 28 Mar 2019 16:07:21 -0000 On Thu, Mar 28, 2019 at 08:50:34AM -0700, Andy Bierman wrote: > On Thu, Mar 28, 2019 at 7:06 AM Michel Veillette < > Michel.Veillette@trilliant.com> wrote: > > > +1 for value outside, string inside union > > > > > This is simple, but I was trying to support some very common types (like > ip-address) > that are unions of strings, and are desirable to send as binary instead of > string representation. > How does CBOR deal with say inet:ipv4-address? Does inet:ipv4-address magically get converted into a binary format? If not, the surprise that it is a string in a union is not a bit surprise. It seems to take full advantage of binary formats efficiently we need some additional magic. The YANG language requires the definition of canonical (textual) format. Do we need a way to define corresponding canonical binary formats for some of the types (where the default textual format is inefficient to send as a string)? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Mar 28 09:31:10 2019 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 9EBB312004B for ; Thu, 28 Mar 2019 09:31:01 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 waV1xc73UvEn for ; Thu, 28 Mar 2019 09:30:59 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 4B4F31200EF for ; Thu, 28 Mar 2019 09:30:42 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id f23so18257665ljc.0 for ; Thu, 28 Mar 2019 09:30:42 -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; bh=RiosPYGuRqXlxbL/4YNBU0BmgPKmtsXQZ4xHz5XK+H0=; b=Rb2nPCiW/GYc0zu9b3dSc+FVvpzl5uq6rwokFoE3D+MOTtjsMcqkklwIo9lD+TIG93 0C8Y+xiOtGszJ9fG+ihGAzM+9aRiFBpqGXBzjoHhd3ZbKMQt6TfT45qA63jTSupcMh5Z jmC4yo8AQt/pbDfGw2RKjxfiRePO1wRiinaBOi9Qcof7iNLTsPLkNCwiLrGEPnoB+I5B HeISWRtFoknULrVgRhF8BeSbHOmqHbSVIDNSdMdr+vw9FSFKuk3xDob90iPZvNfyCS6E BF6QxeWRzRYkzpq05O4dv7dzLifwa4aluzz6RaDwNdBEE/JKhKrenFIuO7q03IUQPCAN GKtA== 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; bh=RiosPYGuRqXlxbL/4YNBU0BmgPKmtsXQZ4xHz5XK+H0=; b=KW2PvDUVE3czBHZMqKNTtq0L38MF6xOHGtQ+RCGZD5vlb2JQqTN3XjNE1a9w/7bDlP lWAJ+QM+jxEzjTzVZiSL8upHjv/CcUMYP1OFyTlvZQmIpqJHvtjwniDqQNFc+YX3nYX6 +9y5ZzWzVa70IPMubk78XmstScjxSpon1Oif8vkwzL/+9dmEnqYnLPy7xId7Xx6u37oi 8tz8vZD+xh9k9ZVEHZ/6HV9q8ih5/blmhkedbstw/3/J9kfcK7TnwbhiLOXN82Hi9ihM n5VmiAWSFHcvAypavE05ng47Fh+3NRi3XVld56VsxMiW9EV4jvgl5bmbh28R+wZ8opu8 Zrxg== X-Gm-Message-State: APjAAAXhPra/7A8JVPioamD0TuxaIuYr1DGVbF9Fjk3i3H9N+nutI0e8 e7h4GNOORTIIT/nG1q3VzuWtaQRmYE0uNh/kcRHrgA== X-Google-Smtp-Source: APXvYqxkYd67kF+pX2p9pVK7YaNem36LhJCvYM1LVyPHchWin1m7q1lJNBR0S7xWXAn5s5HVHygfrslJinDJmNrNsgg= X-Received: by 2002:a2e:844a:: with SMTP id u10mr12165033ljh.41.1553790640259; Thu, 28 Mar 2019 09:30:40 -0700 (PDT) MIME-Version: 1.0 References: <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <20190328113018.uzujjtc7a2ukhovl@anna.jacobs.jacobs-university.de> <4656560A-2135-4F51-B3E7-8DB31B43B17D@tzi.org> <20190328160714.uuzfvxrjjxflktg5@anna.jacobs.jacobs-university.de> In-Reply-To: <20190328160714.uuzfvxrjjxflktg5@anna.jacobs.jacobs-university.de> From: Andy Bierman Date: Thu, 28 Mar 2019 09:30:28 -0700 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , Michel Veillette , Carsten Bormann , "core@ietf.org" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002b1c1d05852a136e" Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 28 Mar 2019 16:31:02 -0000 --0000000000002b1c1d05852a136e Content-Type: text/plain; charset="UTF-8" On Thu, Mar 28, 2019 at 9:07 AM Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Mar 28, 2019 at 08:50:34AM -0700, Andy Bierman wrote: > > On Thu, Mar 28, 2019 at 7:06 AM Michel Veillette < > > Michel.Veillette@trilliant.com> wrote: > > > > > +1 for value outside, string inside union > > > > > > > > This is simple, but I was trying to support some very common types (like > > ip-address) > > that are unions of strings, and are desirable to send as binary instead > of > > string representation. > > > > How does CBOR deal with say inet:ipv4-address? Does inet:ipv4-address > magically get converted into a binary format? If not, the surprise that > it is a string in a union is not a bit surprise. > > It seems to take full advantage of binary formats efficiently we need > some additional magic. The YANG language requires the definition of > canonical (textual) format. Do we need a way to define corresponding > canonical binary formats for some of the types (where the default > textual format is inefficient to send as a string)? > > I thought there was a magic tag for an IPv4 address. I don't see it now. Maybe it got removed. > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --0000000000002b1c1d05852a136e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Mar 28, 2019 at 9:07 AM Juerg= en Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Mar 28, 2019 at 08:50:34AM -0= 700, Andy Bierman wrote:
> On Thu, Mar 28, 2019 at 7:06 AM Michel Veillette <
> Mi= chel.Veillette@trilliant.com> wrote:
>
> > +1 for value outside, string inside union
> >
> >
> This is simple, but I was trying to support some very common types (li= ke
> ip-address)
> that are unions of strings, and are desirable to send as binary instea= d of
> string representation.
>

How does CBOR deal with say inet:ipv4-address? Does inet:ipv4-address
magically get converted into a binary format? If not, the surprise that
it is a string in a union is not a bit surprise.

It seems to take full advantage of binary formats efficiently we need
some additional magic. The YANG language requires the definition of
canonical (textual) format. Do we need a way to define corresponding
canonical binary formats for some of the types (where the default
textual format is inefficient to send as a string)?


I thought there was a magic tag for an= IPv4 address.
I don't see it now.=C2=A0 Maybe it got removed= .

=C2=A0
/js

Andy
=C2=A0

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>
--0000000000002b1c1d05852a136e-- From nobody Thu Mar 28 11:01:54 2019 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 2C4A31202F5; Thu, 28 Mar 2019 11:01:45 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.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 wk2jUkp1wasF; Thu, 28 Mar 2019 11:01:39 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750121.outbound.protection.outlook.com [40.107.75.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F701202EF; Thu, 28 Mar 2019 11:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pUAuzwptZV5dJJG9g+pczbGz6Ee9Jayv+Wn9LfvXOSk=; b=Xdn5vVkw3pf3y8bdvD1zj4L1xboxv7tOYKSdLDBsEPG3DsDsr9jn1QqrTARIYLH8Rkn+w9u81d1jpE+diDWjTQDl1DVJw6HN2Tg7WYDCIT5UVqBxk+iordkPS7/4Dl9z/ufNAZ2H95C1fT64nXQtsLq5HSTC7Jdz2LesYCU+AHg= Received: from BL0PR06MB5042.namprd06.prod.outlook.com (10.167.240.31) by BL0PR06MB4227.namprd06.prod.outlook.com (10.167.179.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.19; Thu, 28 Mar 2019 18:01:36 +0000 Received: from BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::6d4a:3963:7ffb:1f30]) by BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::6d4a:3963:7ffb:1f30%2]) with mapi id 15.20.1750.017; Thu, 28 Mar 2019 18:01:36 +0000 From: Michel Veillette To: Andy Bierman CC: Carsten Bormann , Juergen Schoenwaelder , "core@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] YANG encoding in CBOR Thread-Index: AdTf3q8hCOPNH5o0Q0SJZRQQHN87VgA3tcGQAAL8XAAAAtt/gAAgmRkAAAJStYAAYEUIgABUqX2QAAwU1oAAE3mQoAApxZcAAATFAAAAAF65QAAD8z4AAAQMWjA= Date: Thu, 28 Mar 2019 18:01:36 +0000 Message-ID: References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <871s2vqsxi.fsf@nic.cz> <20190327061637.g5a7t7nulk7kyh2v@anna.jacobs.jacobs-university.de> <20190328113018.uzujjtc7a2ukhovl@anna.jacobs.jacobs-university.de> <4656560A-2135-4F51-B3E7-8DB31B43B17D@tzi.org> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d44db18a-4070-489f-bbdb-08d6b3a76b87 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4227; x-ms-traffictypediagnostic: BL0PR06MB4227: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0990C54589 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(366004)(346002)(136003)(39850400004)(199004)(189003)(13464003)(476003)(2906002)(33656002)(106356001)(105586002)(486006)(8676002)(6306002)(97736004)(66066001)(54896002)(4326008)(229853002)(790700001)(6116002)(6916009)(81166006)(68736007)(11346002)(81156014)(3846002)(6436002)(25786009)(8936002)(446003)(9686003)(72206003)(966005)(478600001)(7736002)(55016002)(236005)(606006)(74316002)(53936002)(14454004)(6246003)(6506007)(26005)(53546011)(316002)(76176011)(186003)(256004)(102836004)(5660300002)(52536014)(71200400001)(71190400001)(86362001)(7696005)(93886005)(99286004)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4227; H:BL0PR06MB5042.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: xyE/QQ7MRYT7GajVUnCn23nEcbgARMAqPQJpsxfOo30zwI190N2yJwBXwOl+PTT4tukj45aQ8bZ58UR15Ee/lFaElFy9l70PkC6G0cdoSgh+A+SbnOOoSqRPk8vmE8aNTiGU6ZtzGKaZlAslEjO7qeg+m5x1ZRhNxHnHDpkrXBAawsGc6r9Q0EfG0AJJNMIm3WfiZVAIGmCaSTKCYW5R16TRMWay7FxX1ocvVZeg5dqoSnrHX+6FiWtNP34RH0+Q7wfEAFVKRFKPREzNnVxUCnjVy6NdeksMlPBp7p4ffldqtOezcB/PDTvjLelj3QsEvX9aeNeXNyOPGAyM/q2BfXhHmlmFWfWIvaxQU0NB7SpyXGgzkRTKT0CM6/OVR6FMOeIl7LbJ7FSr39gQLaZo2dPtO/p3eRc4SUKi7WpUDFQ= Content-Type: multipart/alternative; boundary="_000_BL0PR06MB504204A4C313AC09CFC8C8EF9A590BL0PR06MB5042namp_" MIME-Version: 1.0 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: d44db18a-4070-489f-bbdb-08d6b3a76b87 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2019 18:01:36.0899 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4227 Archived-At: Subject: Re: [netconf] YANG encoding in CBOR 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, 28 Mar 2019 18:01:45 -0000 --_000_BL0PR06MB504204A4C313AC09CFC8C8EF9A590BL0PR06MB5042namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keQ0KDQpUaGUgY3VycmVudCBkaXNjdXNzaW9uIG9uICd1bmlvbicgZG9uJ3QgaGVscCBy ZWR1Y2luZyB0aGUgc2l6ZSBhbmQgY29tcGxleGl0eSBvZiBzb21lIG9mIHRoZSAnaWV0Zi1pbmV0 LXR5cGVzJyB0eXBlcyBzdWNoIGFzOg0KdHlwZWRlZiBpcC1hZGRyZXNzDQp0eXBlZGVmIGlwdjQt YWRkcmVzcw0KdHlwZWRlZiBpcHY2LWFkZHJlc3MNCnR5cGVkZWYgaXAtYWRkcmVzcy1uby16b25l DQp0eXBlZGVmIGlwdjQtYWRkcmVzcy1uby16b25lDQp0eXBlZGVmIGlwdjYtYWRkcmVzcy1uby16 b25lDQp0eXBlZGVmIGlwLXByZWZpeA0KdHlwZWRlZiBpcHY0LXByZWZpeA0KDQpPciBzb21lIG9m IHRoZSAnaWV0Zi15YW5nLXR5cGVzJyB0eXBlcyBzdWNoIGFzOg0KdHlwZWRlZiBkYXRlLWFuZC10 aW1lDQp0eXBlZGVmIHRpbWVzdGFtcA0KdHlwZWRlZiBwaHlzLWFkZHJlc3MNCnR5cGVkZWYgbWFj LWFkZHJlc3MNCnR5cGVkZWYgaGV4LXN0cmluZw0KdHlwZWRlZiB1dWlkDQp0eXBlZGVmIGRvdHRl ZC1xdWFkDQoNClRoZSBzaW1wbGVzIHdheSB0byBhZGRyZXNzIHRob3NlIGlzIHRvIGNyZWF0ZSBh IG5ldyB2ZXJzaW9uIG9mIHRoZXNlIFlBTkcgbW9kdWxlcyBieSBhZGRpbmcgYSBiaW5hcnkgb3B0 aW9uIHVzaW5nIGEgdW5pb24uDQpJIGhvcGUgdGhpcyBjYW4gZXZlbnR1YWxseSBoYXBwZW4gd2hl biB0aGUgQ0JPUiBlbmNvZGluZyBnZXQgbW9yZSBwb3B1bGFyLg0KDQpSZWdhcmRzLA0KTWljaGVs DQoNCg0KRnJvbTogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+DQpTZW50OiBUaHVy c2RheSwgTWFyY2ggMjgsIDIwMTkgMTE6NTEgQU0NClRvOiBNaWNoZWwgVmVpbGxldHRlIDxNaWNo ZWwuVmVpbGxldHRlQHRyaWxsaWFudC5jb20+DQpDYzogQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6 aS5vcmc+OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5p dmVyc2l0eS5kZT47IGNvcmVAaWV0Zi5vcmc7IG5ldGNvbmZAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbbmV0Y29uZl0gWUFORyBlbmNvZGluZyBpbiBDQk9SDQoNCg0KDQpPbiBUaHUsIE1hciAyOCwg MjAxOSBhdCA3OjA2IEFNIE1pY2hlbCBWZWlsbGV0dGUgPE1pY2hlbC5WZWlsbGV0dGVAdHJpbGxp YW50LmNvbTxtYWlsdG86TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQuY29tPj4gd3JvdGU6DQor MSBmb3IgdmFsdWUgb3V0c2lkZSwgc3RyaW5nIGluc2lkZSB1bmlvbg0KDQpUaGlzIGlzIHNpbXBs ZSwgYnV0IEkgd2FzIHRyeWluZyB0byBzdXBwb3J0IHNvbWUgdmVyeSBjb21tb24gdHlwZXMgKGxp a2UgaXAtYWRkcmVzcykNCnRoYXQgYXJlIHVuaW9ucyBvZiBzdHJpbmdzLCBhbmQgYXJlIGRlc2ly YWJsZSB0byBzZW5kIGFzIGJpbmFyeSBpbnN0ZWFkIG9mIHN0cmluZyByZXByZXNlbnRhdGlvbi4N Cg0KQW5keQ0KDQpNeSByYXRpb25hbDoNCg0KLSBTSUQgY2FuIGhhdmUgdXAgdG8gOCBieXRlcyBh bmQgd2lsbCBwcm92aWRlIGEgbWFyZ2luYWwgY29tcHJlc3Npb24uDQotIEdlbmVyYXRpbmcgU0lE IGZvciBhbGwgJ2VudW1lcmF0aW9uJyBhbmQgJ2JpdHMnIGluIGNhc2UgdGhleSBhcmUgdXNlZCBp biAndW5pb24nIGlzIGxvdCBvZiBvdmVyaGVhZCB0byByZXZvbHZlIGEgY29ybmVyIGNhc2UuDQot IFlBTkcgYWxzbyBzdXBwb3J0IHRoZSAnY2hvaWNlJyBzdGF0ZW1lbnQgKGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM3OTUwI3NlY3Rpb24tNC4yLjc8aHR0cHM6Ly9jYW4wMS5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5v cmclMkZodG1sJTJGcmZjNzk1MCUyM3NlY3Rpb24tNC4yLjcmZGF0YT0wMiU3QzAxJTdDJTdDOTE2 ZmYwNmNlOTM4NGI4YTEwNGEwOGQ2YjM5NTI1NjElN0M0ZjZmYmQxMzBkZmI0MTUwODVjM2Q0MzI2 MGMwNDMwOSU3QzAlN0MwJTdDNjM2ODkzODUwNDkwMzM0Mjk0JnNkYXRhPU85ZjBHTmNSdmc5czVh RSUyQkI5UjQzRGpJMnF1aUt6QWZNZlFjSGhkbnJNZyUzRCZyZXNlcnZlZD0wPikgd2hpY2ggaXMg c2ltaWxhciB0bw0KICAgdGhlIGNvbmNlcHQgb2YgdHlwZSB0YWdnaW5nIHdpdGhpbiB1bmlvbi4g VGhpcyBjb25zdHJ1Y3QgY2FuIGJlIHVzZWQgYnkgWUFORyBtb2R1bGVzIHNwZWNpZmljYWxseSBj cmVhdGVkIGZvcg0KICBlbWJlZGRlZCBhcHBsaWNhdGlvbnMgdG8gdGFrZSBhZHZhbnRhZ2Ugb2Yg J2VudW1lcmF0aW9uJyBlbmNvZGVkIGFzIHZhbHVlIGFuZCAnYml0cycgZW5jb2RlZCBhcyBiaXQu DQoNCk1pY2hlbA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDYXJzdGVu IEJvcm1hbm4gPGNhYm9AdHppLm9yZzxtYWlsdG86Y2Fib0B0emkub3JnPj4NClNlbnQ6IFRodXJz ZGF5LCBNYXJjaCAyOCwgMjAxOSA5OjQ3IEFNDQpUbzogSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxq LnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRl ckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4+DQpDYzogTWljaGVsIFZlaWxsZXR0ZSA8TWljaGVsLlZl aWxsZXR0ZUB0cmlsbGlhbnQuY29tPG1haWx0bzpNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudC5j b20+PjsgTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PG1haWx0bzpsaG90a2FAbmljLmN6 Pj47IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+OyBjb3JlQGlldGYu b3JnPG1haWx0bzpjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtuZXRjb25mXSBZQU5HIGVu Y29kaW5nIGluIENCT1INCg0KU28gZm9yIGVudW0vYml0cyB3ZSBhcmUgYmFjayB0byB2YWx1ZSBv dXRzaWRlLCBzdHJpbmcgaW5zaWRlIHVuaW9uPw0KQ2FuIHdlIHVzZSBTSURzIGluc3RlYWQgb2Yg dGhlIHN0cmluZ3MgZm9yIHRoZSBsYXR0ZXI/DQpUaGlzIGNhbuKAmXQgYmUgbXVjaCBtb3JlIGNv bXBsaWNhdGVkIHRoYW4gYXNzaWduaW5nIGEgU0lEIHRvIGVhY2ggc3RyaW5nIHRoYXQgb2NjdXJz IGluIGFuIGVudW0vYml0cyBpbiBhIHVuaW9uLg0KDQpHcsO8w59lLCBDYXJzdGVuDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRjb25mIG1haWxp bmcgbGlzdA0KbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjxodHRwczovL2NhbjAxLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0 Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZuZXRjb25mJmRhdGE9MDIlN0MwMSU3QyU3Qzkx NmZmMDZjZTkzODRiOGExMDRhMDhkNmIzOTUyNTYxJTdDNGY2ZmJkMTMwZGZiNDE1MDg1YzNkNDMy NjBjMDQzMDklN0MwJTdDMCU3QzYzNjg5Mzg1MDQ5MDM0NDMwOCZzZGF0YT04JTJCR2pyRnVjTSUy QmZzNkwyVFklMkZ2SFVZbDgzQ3E5WWt1cWN4UUFOa1I0aGtRJTNEJnJlc2VydmVkPTA+DQo= --_000_BL0PR06MB504204A4C313AC09CFC8C8EF9A590BL0PR06MB5042namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1i b3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5IaSBB bmR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5UaGUgY3VycmVudCBkaXNjdXNzaW9uIG9uICd1bmlvbicg ZG9uJ3QgaGVscCByZWR1Y2luZyB0aGUgc2l6ZSBhbmQgY29tcGxleGl0eSBvZiBzb21lIG9mIHRo ZSAnaWV0Zi1pbmV0LXR5cGVzJyB0eXBlcyBzdWNoIGFzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj50eXBlZGVmIGlwLWFkZHJl c3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSI+dHlwZWRlZiBpcHY0LWFkZHJlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+dHlwZWRlZiBpcHY2LWFkZHJlc3M8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSI+dHlwZWRlZiBpcC1hZGRyZXNzLW5vLXpvbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+dHlwZWRlZiBpcHY0LWFkZHJl c3Mtbm8tem9uZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIj50eXBlZGVmIGlwdjYtYWRkcmVzcy1uby16b25lPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPnR5cGVk ZWYgaXAtcHJlZml4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQ0EiPnR5cGVkZWYgaXB2NC1wcmVmaXg8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei Pk9yIHNvbWUgb2YgdGhlICdpZXRmLXlhbmctdHlwZXMnIHR5cGVzIHN1Y2ggYXM6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPnR5 cGVkZWYgZGF0ZS1hbmQtdGltZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj50eXBlZGVmIHRpbWVzdGFtcDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj50eXBlZGVm IHBoeXMtYWRkcmVzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUNBIj50eXBlZGVmIG1hYy1hZGRyZXNzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPnR5cGVkZWYgaGV4 LXN0cmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIj50eXBlZGVmIHV1aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+dHlwZWRlZiBkb3R0ZWQtcXVhZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNB Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1DQSI+VGhlIHNpbXBsZXMgd2F5IHRvIGFkZHJlc3MgdGhvc2UgaXMgdG8gY3Jl YXRlIGEgbmV3IHZlcnNpb24gb2YgdGhlc2UgWUFORyBtb2R1bGVzIGJ5IGFkZGluZyBhIGJpbmFy eSBvcHRpb24gdXNpbmcgYSB1bmlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+SSBob3BlIHRoaXMgY2FuIGV2ZW50dWFsbHkg aGFwcGVuIHdoZW4gdGhlIENCT1IgZW5jb2RpbmcgZ2V0IG1vcmUgcG9wdWxhci48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPk1pY2hlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+ IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OyA8YnI+DQo8Yj5TZW50Ojwv Yj4gVGh1cnNkYXksIE1hcmNoIDI4LCAyMDE5IDExOjUxIEFNPGJyPg0KPGI+VG86PC9iPiBNaWNo ZWwgVmVpbGxldHRlICZsdDtNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudC5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBDYXJzdGVuIEJvcm1hbm4gJmx0O2NhYm9AdHppLm9yZyZndDs7IEp1ZXJnZW4g U2Nob2Vud2FlbGRlciAmbHQ7ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlJmd0 OzsgY29yZUBpZXRmLm9yZzsgbmV0Y29uZkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW25ldGNvbmZdIFlBTkcgZW5jb2RpbmcgaW4gQ0JPUjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gVGh1LCBNYXIgMjgsIDIwMTkgYXQgNzowNiBBTSBNaWNoZWwgVmVpbGxl dHRlICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQuY29tIj5N aWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+JiM0MzsxIGZvciB2YWx1ZSBvdXRzaWRlLCBzdHJpbmcgaW5zaWRl IHVuaW9uPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGlzIGlzIHNpbXBsZSwgYnV0IEkgd2FzIHRyeWluZyB0byBzdXBwb3J0IHNv bWUgdmVyeSBjb21tb24gdHlwZXMgKGxpa2UgaXAtYWRkcmVzcyk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoYXQgYXJlIHVuaW9ucyBvZiBzdHJp bmdzLCBhbmQgYXJlIGRlc2lyYWJsZSB0byBzZW5kIGFzIGJpbmFyeSBpbnN0ZWFkIG9mIHN0cmlu ZyByZXByZXNlbnRhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSByYXRpb25hbDo8YnI+DQo8YnI+DQotIFNJRCBjYW4g aGF2ZSB1cCB0byA4IGJ5dGVzIGFuZCB3aWxsIHByb3ZpZGUgYSBtYXJnaW5hbCBjb21wcmVzc2lv bi48YnI+DQotIEdlbmVyYXRpbmcgU0lEIGZvciBhbGwgJ2VudW1lcmF0aW9uJyBhbmQgJ2JpdHMn IGluIGNhc2UgdGhleSBhcmUgdXNlZCBpbiAndW5pb24nIGlzIGxvdCBvZiBvdmVyaGVhZCB0byBy ZXZvbHZlIGEgY29ybmVyIGNhc2UuPGJyPg0KLSBZQU5HIGFsc28gc3VwcG9ydCB0aGUgJ2Nob2lj ZScgc3RhdGVtZW50ICg8YSBocmVmPSJodHRwczovL2NhbjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZy ZmM3OTUwJTIzc2VjdGlvbi00LjIuNyZhbXA7ZGF0YT0wMiU3QzAxJTdDJTdDOTE2ZmYwNmNlOTM4 NGI4YTEwNGEwOGQ2YjM5NTI1NjElN0M0ZjZmYmQxMzBkZmI0MTUwODVjM2Q0MzI2MGMwNDMwOSU3 QzAlN0MwJTdDNjM2ODkzODUwNDkwMzM0Mjk0JmFtcDtzZGF0YT1POWYwR05jUnZnOXM1YUUlMkJC OVI0M0RqSTJxdWlLekFmTWZRY0hoZG5yTWclM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzk1MCNzZWN0aW9uLTQuMi43PC9h PikNCiB3aGljaCBpcyBzaW1pbGFyIHRvPGJyPg0KJm5ic3A7ICZuYnNwO3RoZSBjb25jZXB0IG9m IHR5cGUgdGFnZ2luZyB3aXRoaW4gdW5pb24uIFRoaXMgY29uc3RydWN0IGNhbiBiZSB1c2VkIGJ5 IFlBTkcgbW9kdWxlcyBzcGVjaWZpY2FsbHkgY3JlYXRlZCBmb3I8YnI+DQombmJzcDsgZW1iZWRk ZWQgYXBwbGljYXRpb25zIHRvIHRha2UgYWR2YW50YWdlIG9mICdlbnVtZXJhdGlvbicgZW5jb2Rl ZCBhcyB2YWx1ZSBhbmQgJ2JpdHMnIGVuY29kZWQgYXMgYml0Ljxicj4NCjxicj4NCk1pY2hlbDxi cj4NCjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogQ2Fy c3RlbiBCb3JtYW5uICZsdDs8YSBocmVmPSJtYWlsdG86Y2Fib0B0emkub3JnIiB0YXJnZXQ9Il9i bGFuayI+Y2Fib0B0emkub3JnPC9hPiZndDsNCjxicj4NClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAy OCwgMjAxOSA5OjQ3IEFNPGJyPg0KVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSIgdGFyZ2V0PSJf YmxhbmsiPmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4mZ3Q7PGJyPg0K Q2M6IE1pY2hlbCBWZWlsbGV0dGUgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoZWwuVmVpbGxldHRl QHRyaWxsaWFudC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFu dC5jb208L2E+Jmd0OzsgTGFkaXNsYXYgTGhvdGthICZsdDs8YSBocmVmPSJtYWlsdG86bGhvdGth QG5pYy5jeiIgdGFyZ2V0PSJfYmxhbmsiPmxob3RrYUBuaWMuY3o8L2E+Jmd0OzsNCjxhIGhyZWY9 Im1haWx0bzpuZXRjb25mQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0Y29uZkBpZXRmLm9y ZzwvYT47IDxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpj b3JlQGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gWUFORyBlbmNvZGlu ZyBpbiBDQk9SPGJyPg0KPGJyPg0KU28gZm9yIGVudW0vYml0cyB3ZSBhcmUgYmFjayB0byB2YWx1 ZSBvdXRzaWRlLCBzdHJpbmcgaW5zaWRlIHVuaW9uPzxicj4NCkNhbiB3ZSB1c2UgU0lEcyBpbnN0 ZWFkIG9mIHRoZSBzdHJpbmdzIGZvciB0aGUgbGF0dGVyPzxicj4NClRoaXMgY2Fu4oCZdCBiZSBt dWNoIG1vcmUgY29tcGxpY2F0ZWQgdGhhbiBhc3NpZ25pbmcgYSBTSUQgdG8gZWFjaCBzdHJpbmcg dGhhdCBvY2N1cnMgaW4gYW4gZW51bS9iaXRzIGluIGEgdW5pb24uPGJyPg0KPGJyPg0KR3LDvMOf ZSwgQ2Fyc3Rlbjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KbmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86bmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldGNvbmZAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9jYW4wMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZv JTJGbmV0Y29uZiZhbXA7ZGF0YT0wMiU3QzAxJTdDJTdDOTE2ZmYwNmNlOTM4NGI4YTEwNGEwOGQ2 YjM5NTI1NjElN0M0ZjZmYmQxMzBkZmI0MTUwODVjM2Q0MzI2MGMwNDMwOSU3QzAlN0MwJTdDNjM2 ODkzODUwNDkwMzQ0MzA4JmFtcDtzZGF0YT04JTJCR2pyRnVjTSUyQmZzNkwyVFklMkZ2SFVZbDgz Q3E5WWt1cWN4UUFOa1I0aGtRJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_BL0PR06MB504204A4C313AC09CFC8C8EF9A590BL0PR06MB5042namp_-- From nobody Fri Mar 29 01:59:17 2019 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 0450112015F; Fri, 29 Mar 2019 01:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de 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 VJndKO_Xo8Re; Fri, 29 Mar 2019 01:59:11 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B441120026; Fri, 29 Mar 2019 01:59:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 7AE1B25A1C; Fri, 29 Mar 2019 09:59:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1553849948; bh=Bt3UObEVEy/qT1flteVbaf+/C8G7fPdRvxO0JlWbY/w=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=lP7eHMZUzpnn8wTD9POSfQtwCfzQ6eVoeu94+rN79yBU2P/lwpM2j/jJ5eo2OjBTi wUHzM50Xv9rMy97JLXqRuSVndjui8IcdwkbQ8bAYUZapKPsxhEAo5h/RrudeyShPeP 91pdQzOa9vfnQIuT0IKhitBit5lbUli3IOYQU1pY= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWBwx1lWb3-C; Fri, 29 Mar 2019 09:59:06 +0100 (CET) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Fri, 29 Mar 2019 09:59:06 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.111]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Fri, 29 Mar 2019 09:59:06 +0100 From: "Scharf, Michael" To: Kent Watsen , Juergen Schoenwaelder CC: "tcpm@ietf.org" , Netconf Thread-Topic: [netconf] Adoption poll for tcp-client-server and http-client-server draft Thread-Index: AQHU48WN++elmQAJ10utC4WVEX8JVqYd0z1QgAASMICAAAllAIAEWONg Date: Fri, 29 Mar 2019 08:59:05 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D28C36D@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D282BBC@rznt8114.rznt.rzdir.fht-esslingen.de> <20190326141905.246www5dwmyojlpe@anna.jacobs.jacobs-university.de> <01000169ba7d39d8-b3f6bfca-17a6-4c01-bd1c-81f5270f1476-000000@email.amazonses.com> In-Reply-To: <01000169ba7d39d8-b3f6bfca-17a6-4c01-bd1c-81f5270f1476-000000@email.amazonses.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D28C36Drznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft 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, 29 Mar 2019 08:59:16 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D28C36Drznt8114rzntrzd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VudCwNCg0KQXMgYWxyZWFkeSBub3RlZCBkdXJpbmcgb3VyIHZlcnkgdXNlZnVsIGhhbGx3 YXkgZGlzY3Vzc2lvbiwgSSBhbSBmaW5lIHdpdGggdGhpcyBwcm9wb3NhbCAoYm90aCBhcyBjaGFp ciBhbmQgYXMgaW5kaXZpZHVhbCBjb250cmlidXRvcikuIEkgYmVsaWV2ZSB0aGF0IHRoZSBkcmFm dCBzaG91bGQgYmUgcHJlc2VudGVkIGluIFRDUE0gaW4gTW9udHJlYWwgc28gdGhhdCB0aGUgVENQ TSBjb21tdW5pdHkgY2FuIHJldmlldyB0aGUgbW9kZWwgYW5kIGRpc2N1c3MgcG90ZW50aWFsIG5l eHQgc3RlcHMuIFRoZSBUQ1BNIGNvbW11bml0eSBjYW4gdGhlbiBkZWNpZGUgZS5nLiB3aGV0aGVy IGEgam9pbnQgV0dMQyB3aWxsIGJlIHVzZWZ1bC4gQXMgdXN1YWwgaW4gVENQTSwgdGhlIGNoYWly cyB3aWxsIGNhcmVmdWxseSBsaXN0ZW4gdG8gZmVlZGJhY2sgZnJvbSBUQ1AgaW1wbGVtZW50ZXJz Lg0KDQpBcyBsb25nIGFzIHByb3BlciByZXZpZXcgYnkgVENQIGltcGxlbWVudGVycyBpcyBlbnN1 cmVkIGFuZCBhcyBsb25nIGFzIHdlIGNhbiBjb21lIHVwIHdpdGggYSBmdXR1cmUtcHJvb2Ygc29s dXRpb24sIGl0IGlzIGFjdHVhbGx5IG5vdCBpbXBvcnRhbnQgdG8gbWUgd2hpY2ggV0cgcHVibGlz aGVzIGRyYWZ0LWt3YXRzZW4tbmV0Y29uZi10Y3AtY2xpZW50LXNlcnZlci0wMC4NCg0KSSBoYXZl IHNvbWUgdGVjaG5pY2FsIHF1ZXN0aW9ucyBvbiB0aGUgbW9kZWwgYW5kIGl0cyBzdHJ1Y3R1cmUg KGUuZy4sIHdoeSB0aGUgcGFyYW1ldGVyIOKAnGlkbGUtdGltZeKAnSBpcyBtZWFzdXJlZCBpbiBt aW51dGVzIGluc3RlYWQgb2Ygc2Vjb25kcykuIExldOKAmXMgc29ydCB0aGF0IG91dCBvZmZsaW5l Lg0KDQpUaGFua3MNCg0KTUljaGFlbA0KDQoNClBTOiBBIHBlcnNvbmFsIGNvbW1lbnQgbW9zdGx5 IHRvIHRoZSBUQ1BNIGNvbW11bml0eTogVW5mb3J0dW5hdGVseSBJIGhhdmUgbm90IGJlZW4gYXdh cmUgb2YgZHJhZnQta3dhdHNlbi1uZXRjb25mLXRjcC1jbGllbnQtc2VydmVyLTAwIHByaW9yIHRv IFR1ZXNkYXkgYW5kIHRoaXMgaXMgd2h5IEkgaGF2ZSBub3QgbWVudGlvbmVkIHRoZSBJLUQgZHVy aW5nIG15IHRhbGsgaW4gVENQTSBvbiBNb25kYXkuIEkgZm9sbG93IHF1aXRlIGEgYml0IG9mIHdv cmtpbmcgZ3JvdXBzIG91dHNpZGUgVFNWIGFyZWEsIGJ1dCBJIHdhcyBxdWl0ZSBidXN5IGluIHRo ZSB3ZWVrcyBwcmlvciB0byB0aGUgbWVldGluZyBhbmQgdGh1cyBJIG1pc3NlZCB0aGUgc3VibWlz c2lvbiBvZiB0aGlzIGRyYWZ0LiBJZiBJIGhhZCBiZWVuIGF3YXJlIG9mIHRoZSBJLUQsIEkgd291 bGQgb2J2aW91c2x5IGhhdmUgaW52aXRlZCBLZW50IHRvIHByZXNlbnQgdGhlIGRvY3VtZW50IGlu IFRDUE0gaW4gUHJhZ3VlLCBhcyBvbmUgZXhhbXBsZSBvZiBlbWVyZ2luZyBUQ1AtcmVsYXRlZCBZ QU5HIG1vZGVscyB0aGF0IFRDUE0gc2hvdWxkIHBlcmhhcHMgYmUgYXdhcmUgb2YuDQoNCg0KDQpG cm9tOiBLZW50IFdhdHNlbiA8a2VudEB3YXRzZW4ubmV0Pg0KU2VudDogVHVlc2RheSwgTWFyY2gg MjYsIDIwMTkgMzo1MyBQTQ0KVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVs ZGVyQGphY29icy11bml2ZXJzaXR5LmRlPg0KQ2M6IFNjaGFyZiwgTWljaGFlbCA8TWljaGFlbC5T Y2hhcmZAaHMtZXNzbGluZ2VuLmRlPjsgdGNwbUBpZXRmLm9yZzsgTmV0Y29uZiA8bmV0Y29uZkBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gQWRvcHRpb24gcG9sbCBmb3IgdGNwLWNs aWVudC1zZXJ2ZXIgYW5kIGh0dHAtY2xpZW50LXNlcnZlciBkcmFmdA0KDQoNCldhaXQsIEkgZG9u 4oCZdCB0aGluayB3ZSBuZWVkIHRvIGRvIGFueXRoaW5nIGRyYXN0aWMgaGVyZS4NCg0KTWljaGFl bCwgcGxlYXNlIG5vdGUgdGhhdCB0aGUgVENQIG1vZHVsZXMgaGVyZSBhcmUgaW50ZW5kZWQgdG8g YmUgdmVyeSBsaW1pdGVkIGluIHNjb3BlLCBqdXN0IHRoZSBiYXJlIG1pbmltdW0gbmVjZXNzYXJ5 IHRvIHN1cHBvcnQgdGhlIE5FVENPTkYvUkVTVENPTkYgdGhhdCAoaW4gY2FzZSB5b3UgZG9u4oCZ dCBrbm93KSBhcmUgbGF5ZXJlZCBvbiB0b3Agb2YgU1NIIGFuZCBUTFMsIGFuZCBoZW5jZSBUQ1Au ICBUaGUgYmFyZSBtaW5pbXVtIGFwcGVhcnMgdG8gYmUganVzdCBhZGRyZXNzZXMsIHBvcnRzLCBh bmQga2VlcC1hbGl2ZXMuICAgVGhlIE5FVENPTkYgV0cgaGFzIE5PIGludGVyZXN0IGluIGV4dGVu ZGluZyB0aGlzIG1vZHVsZSBiZXlvbmQgdGhpcyBtaW5pbWFsIGFtb3VudC4NCg0KQWRkaXRpb25h bGx5LCBwbGVhc2Ugc2VlIFNsaWRlIDkgaGVyZSBbMV0gYW5kIG5vdGUgdGhhdCB0aGlzIG1vZHVs ZSBpcyBwYXJ0IG9mIGEgcmF0aGVyIGxhcmdlIGVjby1zeXN0ZW0gb2YgaW50ZXJyZWxhdGVkIG1v ZHVsZXMuICBUaGUgcG9pbnQgYmVpbmcgaXMgdGhhdCB0aGUgcmVhc29uIGZvciBpdCBiZWluZyAg c3RydWN0dXJlZCB0aGUgd2F5IGl0IGlzIChlLmcuLCBhcyBncm91cGluZ3MpIGlzIHByZXR0eSB3 ZWxsIGp1c3RpZmllZC4NCg0KTXkgcHJvcG9zYWwgaXMgYXMgZm9sbG93czoNCg0KICAxKSBMZXTi gJlzIChhcyBjby1hdXRob3JzKSBnZXQgdGhlIGRyYWZ0LWt3YXRzZW4tbmV0Y29uZi10Y3AtY2xp ZW50LXNlcnZlci0wMA0KICAgICAgd2l0aCBpdOKAmXMgY3VycmVudCBzY29wZSB0byBSRkMgc3Rh dHVzIEFTQVAgKGEgY291cGxlIG1vbnRocyksIHNvIHRoYXQgdGhpcw0KICAgICAgZml2ZS15ZWFy IE5FVENPTkYgcHJvamVjdCBjYW4gZW5kLiAgSGFwcHkgdG8gdHdlYWsgaXQgYXMgeW91IHNlZSBm aXQuDQogICAgICBXaGljaCBXRyBkb2VzIHRoaXMgaXMgbm90IGltcG9ydGFudCwgYnV0IGZvciBh IHRpbWUtZXhwZWRpZW5jeSBwZXJzcGVjdGl2ZSwNCiAgICAgIEkgcmVjb21tZW5kIHRoZSBORVRD T05GIFdHIGR1ZSB0byB0aGUgaGVhdnkgaW50ZXJsaW5raW5nIG1lbnRpb25lZA0KICAgICAgYmVm b3JlLg0KDQoNCiAgMikgVENQTSB0YWtlcyBvdmVyIHRoZSBSRkMsIHB1Ymxpc2hpbmcgYSBiaXMg d2l0aCBhbGwgdGhlIGV4dHJhIHBhcmFtZXRlcnMNCiAgICAgICB0aGF0IGFyZSBpbiBkcmFmdC1z Y2hhcmYtdGNwbS15YW5nLXRjcC4gIFRDUE0gY291bGQgZXZlbiBkbyB0aGlzIHdvcmsNCiAgICAg ICBpbiBwYXJhbGxlbCwgc28gYXMgdG8gbm90IGNhdXNlIGFueSBzY2hlZHVsaW5nIGRlbGF5cy4N Cg0KVGhvdWdodHM/ICBDYW4gd2UgaGF2ZSBhIHNob3J0LXRlcm0gY29sbGFib3JhdGlvbiBhbmQg dGhlbiBsZXQgVENQTSB0YWtlIG92ZXI/DQoNClsxXSBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL21lZXRpbmcvMTA0L21hdGVyaWFscy9zbGlkZXMtMTA0LW5ldGNvbmYtY3J5cHRvLXR5cGVz LWNsaWVudHNlcnZlci1zdWl0ZS1vZi1kcmFmdHMtMDAucGRmDQoNCg0KUFM6IExldOKAmXMgKCsg Y28tY2hhaXJzKSBtZWV0IHVwIHRvZGF5L3RvbW9ycm93Lg0KDQpLZW50IC8vIGNvbnRyaWJ1dG9y DQoNCg0KT24gTWFyIDI2LCAyMDE5LCBhdCAzOjE5IFBNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIg PGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTxtYWlsdG86ai5zY2hvZW53YWVs ZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj4gd3JvdGU6DQpEZWFyIE1pY2hhZWwsDQoNCnBsZWFz ZSBub3RlIHRoYXQgYSBjb25maWd1cmF0aW9uIG1vZGVsIGZvciBORVRDT05GIGlzIG9uIHRoZSBO RVRDT05GDQpjaGFydGVyIGZvciB+NSB5ZWFycy4gVG8gZXN0YWJsaXNoIE5FVENPTkYgc2Vzc2lv biwgd2Ugb2J2aW91c2x5IG5lZWQNCnRvIGVzdGFibGlzaCBUQ1AgY29ubmVjdGlvbnMuIFRoaXMg aXMgd2hhdCB0aGlzIHdvcmsgZG9lcy4gSXQgaXMNCmVudGlyZWx5IG9ydGhvZ29uYWwgdG8gZHJh ZnQtc2NoYXJmLXRjcG0teWFuZy10Y3AsIHdoaWNoIHRhbGtzIGFib3V0DQpUQ1AgcHJvdG9jb2wg ZW5naW5lIGludGVybmFscy4gSWYgdGhlIFRDUE0gY2hhaXIgaGFzIGFuIGlzc3VlIHdpdGggYQ0K Z2VuZXJpYyBzb2x1dGlvbiB0byBlc3RhYmxpc2ggVENQIGNvbm5lY3Rpb24gbm90IGJlaW5nIGRv bmUgaW4gVENQTSwNCndlIHNob3VsZCBwZXJoYXBzIGp1c3QgaGFyZGNvZGUgaG93IHRvIGVzdGFi bGlzaCBUQ1AgY29ubmVjdGlvbnMgZm9yDQpORVRDT05GIGFuZCBSRVNUQ09ORiBhbmQgY2FsbCBp dCB0aGUgZGF5IGFuZCB0aGVuIFRDUE0gY2FuIHBpY2sgdXAgdGhlDQpwaWVjZXMgYW5kIHN0YXJ0 IHdvcmsgb24gYSBnZW5lcmljIHNvbHV0aW9uLg0KDQovanMNCg0KT24gVHVlLCBNYXIgMjYsIDIw MTkgYXQgMDE6MDI6NDlQTSArMDAwMCwgU2NoYXJmLCBNaWNoYWVsIHdyb3RlOg0KDQpIaSBNYWhl c2gsDQoNCkFzIGNoYWlyIG9mIHRoZSBUQ1BNIHdvcmtpbmcgZ3JvdXAsIEkgYmVsaWV2ZSB0aGF0 IHRoZSBkb2N1bWVudCBkcmFmdC1rd2F0c2VuLW5ldGNvbmYtdGNwLWNsaWVudC1zZXJ2ZXItMDAg YmVsb25ncyBpbnRvIHRoZSBUQ1BNIHdvcmtpbmcgZ3JvdXAuIFRoZSBkb2N1bWVudCBpcyBhYm91 dCBhIGdlbmVyaWMgWUFORyBtb2RlbCBmb3IgYW4gaW50ZXJmYWNlIGZvciBUQ1AgImZvciBhbiBT U0gsIFRMUywgb3IgSFRUUCBiYXNlZCBhcHBsaWNhdGlvbiIuIEkgZmFpbCB0byBzZWUgYSByZWFz b24gd2h5IHN1Y2ggYSBnZW5lcmljIFRDUCBtb2RlbCBzaG91bGQgYmUgZG9uZSBpbiBORVRDT05G Lg0KDQpUaHVzLCBhcyBhIGNoYWlyIG9mIFRDUE0sIEkgb2JqZWN0IHRvIGFkb3B0aW9uIGluIE5F VENPTkYuDQoNCkkgYWxzbyB3YW50IHRvIG5vdGUgdGhhdCBpdCB3b3VsZCBoYXZlIGJlZW4gcG9z c2libGUgdG8gc2VuZCBhIG5vdGUgdG8gdGhlIFRDUE0gbGlzdCBwcmlvciB0byBzdGFydGluZyBh biBhZG9wdGlvbiBjYWxsLCBhcyB0aGUgVENQTSBsaXN0IGlzIG1vbml0b3JlZCBieSBtYW55IFRD UCBpbXBsZW1lbnRlcnMgd2hvIGNvdWxkIGJlIGFmZmVjdGVkIGJ5IHN1Y2ggYSBZQU5HIG1vZGVs LiBZQU5HIG1vZGVscyBjYW4gYmUgdXNlZCBpbiBkaWZmZXJlbnQgdXNlIGNhc2VzLiBUQ1BNIGhh cyBhIHRyYWRpdGlvbiBvZiBiZWluZyB2ZXJ5IG9wZW4gdG8gcHJlc2VudGF0aW9ucyBmcm9tIG90 aGVyIHdvcmtpbmcgZ3JvdXBzIGlmIHRoZXkgcmVsYXRlIHRvIFRDUC4gSSBoYXZlIGFkZGVkIHRo ZSBUQ1BNIGxpc3QgaW4gQ0MuDQoNCkFzIGFuIGluZGl2aWR1YWwgY29udHJpYnV0b3IgdG8gdGhl IElFVEYsIEkgaGFwcGVuIHRvIGJlIGFuIGF1dGhvciBvZiBkcmFmdC1zY2hhcmYtdGNwbS15YW5n LXRjcCwgd2hpY2ggYWN0dWFsbHkgd2FzIHN1Ym1pdHRlZCBsYXN0IHllYXIuIEdpdmVuIHRoYXQg ZGlmZmVyZW50IHdvcmtpbmcgZ3JvdXBzIHNlZW0gdG8gYmUgaW52b2x2ZWQsIEkgYmVsaWV2ZSB0 aGF0IGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gam9pbiBlZmZvcnRzLiBTaG91bGRuJ3Qgd2UgaGF2 ZSBhIGNoYXQgb24gdGhlIGJlc3QgbmV4dCBzdGVwcz8NCg0KVGhhbmtzDQoNCk1pY2hhZWwNCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbmV0Y29uZiA8bmV0Y29uZi1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYg T2YgTWFoZXNoDQpKZXRoYW5hbmRhbmkNClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDI2LCAyMDE5IDEy OjE3IFBNDQpUbzogTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRm Lm9yZz4+DQpTdWJqZWN0OiBbbmV0Y29uZl0gQWRvcHRpb24gcG9sbCBmb3IgdGNwLWNsaWVudC1z ZXJ2ZXIgYW5kIGh0dHAtY2xpZW50LXNlcnZlcg0KZHJhZnQNCg0KVGhpcyBpcyB0aGUgc3RhcnQg b2YgYSB0d28gd2VlayBwb2xsIGZvciBXRyBhZG9wdGlvbiBvZiB0aGUgdHdvIGRyYWZ0czoNCg0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWt3YXRzZW4tbmV0Y29uZi10Y3AtY2xp ZW50LXNlcnZlci0wMA0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWt3YXRzZW4t bmV0Y29uZi1odHRwLWNsaWVudC1zZXJ2ZXItMDANCg0KUGxlYXNlIGluZGljYXRlIHlvdXIgc3Vw cG9ydCBmb3Igb3IgYW55IG9iamVjdGlvbnMgeW91IG1pZ2h0IGhhdmUgZm9yDQphZG9wdGluZyB0 aGUgdHdvIGRyYWZ0cyBhcyBXRyBpdGVtcyBieSBBcHJpbCA5Lg0KDQpNYWhlc2ggSmV0aGFuYW5k YW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5j b20+DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KbmV0Y29uZiBtYWlsaW5nIGxpc3QNCm5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldGNv bmYgbWFpbGluZyBsaXN0DQpuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCi0tDQpK dWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBn R21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3 NTkgQnJlbWVuIHwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0 cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0Y29uZiBtYWlsaW5nIGxpc3QNCm5ldGNvbmZA aWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg== --_000_6EC6417807D9754DA64F3087E2E2E03E2D28C36Drznt8114rzntrzd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu bXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5h bWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0K c3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkUtTWFpbEZvcm1hdHZvcmxhZ2UxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3Nl Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCAyLjBjbSA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgS2VudCw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BcyBhbHJlYWR5IG5vdGVkIGR1cmlu ZyBvdXIgdmVyeSB1c2VmdWwgaGFsbHdheSBkaXNjdXNzaW9uLCBJIGFtIGZpbmUgd2l0aCB0aGlz IHByb3Bvc2FsIChib3RoIGFzIGNoYWlyIGFuZCBhcyBpbmRpdmlkdWFsDQogY29udHJpYnV0b3Ip LiBJIGJlbGlldmUgdGhhdCB0aGUgZHJhZnQgc2hvdWxkIGJlIHByZXNlbnRlZCBpbiBUQ1BNIGlu IE1vbnRyZWFsIHNvIHRoYXQgdGhlIFRDUE0gY29tbXVuaXR5IGNhbiByZXZpZXcgdGhlIG1vZGVs IGFuZCBkaXNjdXNzIHBvdGVudGlhbCBuZXh0IHN0ZXBzLiBUaGUgVENQTSBjb21tdW5pdHkgY2Fu IHRoZW4gZGVjaWRlIGUuZy4gd2hldGhlciBhIGpvaW50IFdHTEMgd2lsbCBiZSB1c2VmdWwuIEFz IHVzdWFsIGluIFRDUE0sDQogdGhlIGNoYWlycyB3aWxsIGNhcmVmdWxseSBsaXN0ZW4gdG8gZmVl ZGJhY2sgZnJvbSBUQ1AgaW1wbGVtZW50ZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BcyBsb25nIGFzIHByb3BlciBy ZXZpZXcgYnkgVENQIGltcGxlbWVudGVycyBpcyBlbnN1cmVkIGFuZCBhcyBsb25nIGFzIHdlIGNh biBjb21lIHVwIHdpdGggYSBmdXR1cmUtcHJvb2Ygc29sdXRpb24sIGl0DQogaXMgYWN0dWFsbHkg bm90IGltcG9ydGFudCB0byBtZSB3aGljaCBXRyBwdWJsaXNoZXMgZHJhZnQta3dhdHNlbi1uZXRj b25mLXRjcC1jbGllbnQtc2VydmVyLTAwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGhhdmUgc29tZSB0ZWNobmljYWwg cXVlc3Rpb25zIG9uIHRoZSBtb2RlbCBhbmQgaXRzIHN0cnVjdHVyZSAoZS5nLiwgd2h5IHRoZSBw YXJhbWV0ZXIg4oCcaWRsZS10aW1l4oCdIGlzIG1lYXN1cmVkIGluIG1pbnV0ZXMNCiBpbnN0ZWFk IG9mIHNlY29uZHMpLiBMZXTigJlzIHNvcnQgdGhhdCBvdXQgb2ZmbGluZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhh bmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPk1JY2hhZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5QUzogQSBwZXJzb25hbCBjb21t ZW50IG1vc3RseSB0byB0aGUgVENQTSBjb21tdW5pdHk6IFVuZm9ydHVuYXRlbHkgSSBoYXZlIG5v dCBiZWVuIGF3YXJlIG9mIGRyYWZ0LWt3YXRzZW4tbmV0Y29uZi10Y3AtY2xpZW50LXNlcnZlci0w MA0KIHByaW9yIHRvIFR1ZXNkYXkgYW5kIHRoaXMgaXMgd2h5IEkgaGF2ZSBub3QgbWVudGlvbmVk IHRoZSBJLUQgZHVyaW5nIG15IHRhbGsgaW4gVENQTSBvbiBNb25kYXkuIEkgZm9sbG93IHF1aXRl IGEgYml0IG9mIHdvcmtpbmcgZ3JvdXBzIG91dHNpZGUgVFNWIGFyZWEsIGJ1dCBJIHdhcyBxdWl0 ZSBidXN5IGluIHRoZSB3ZWVrcyBwcmlvciB0byB0aGUgbWVldGluZyBhbmQgdGh1cyBJIG1pc3Nl ZCB0aGUgc3VibWlzc2lvbiBvZiB0aGlzIGRyYWZ0Lg0KIElmIEkgaGFkIGJlZW4gYXdhcmUgb2Yg dGhlIEktRCwgSSB3b3VsZCBvYnZpb3VzbHkgaGF2ZSBpbnZpdGVkIEtlbnQgdG8gcHJlc2VudCB0 aGUgZG9jdW1lbnQgaW4gVENQTSBpbiBQcmFndWUsIGFzIG9uZSBleGFtcGxlIG9mIGVtZXJnaW5n IFRDUC1yZWxhdGVkIFlBTkcgbW9kZWxzIHRoYXQgVENQTSBzaG91bGQgcGVyaGFwcyBiZSBhd2Fy ZSBvZi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IEtlbnQgV2F0c2VuICZsdDtrZW50QHdhdHNlbi5uZXQmZ3Q7DQo8YnI+ DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWFyY2ggMjYsIDIwMTkgMzo1MyBQTTxicj4NCjxiPlRv OjwvYj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVu aXZlcnNpdHkuZGUmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBTY2hhcmYsIE1pY2hhZWwgJmx0O01pY2hh ZWwuU2NoYXJmQGhzLWVzc2xpbmdlbi5kZSZndDs7IHRjcG1AaWV0Zi5vcmc7IE5ldGNvbmYgJmx0 O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0Y29uZl0g QWRvcHRpb24gcG9sbCBmb3IgdGNwLWNsaWVudC1zZXJ2ZXIgYW5kIGh0dHAtY2xpZW50LXNlcnZl ciBkcmFmdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ V2FpdCwgSSBkb27igJl0IHRoaW5rIHdlIG5lZWQgdG8gZG8gYW55dGhpbmcgZHJhc3RpYyBoZXJl LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWljaGFlbCwg cGxlYXNlIG5vdGUgdGhhdCB0aGUgVENQIG1vZHVsZXMgaGVyZSBhcmUgaW50ZW5kZWQgdG8gYmUg dmVyeSBsaW1pdGVkIGluIHNjb3BlLCBqdXN0IHRoZSBiYXJlIG1pbmltdW0gbmVjZXNzYXJ5IHRv IHN1cHBvcnQgdGhlIE5FVENPTkYvUkVTVENPTkYgdGhhdCAoaW4gY2FzZSB5b3UgZG9u4oCZdCBr bm93KSBhcmUgbGF5ZXJlZCBvbiB0b3Agb2YgU1NIIGFuZCBUTFMsIGFuZCBoZW5jZSBUQ1AuICZu YnNwO1RoZQ0KIGJhcmUgbWluaW11bSBhcHBlYXJzIHRvIGJlIGp1c3QgYWRkcmVzc2VzLCBwb3J0 cywgYW5kIGtlZXAtYWxpdmVzLiAmbmJzcDsgVGhlIE5FVENPTkYgV0cgaGFzIE5PIGludGVyZXN0 IGluIGV4dGVuZGluZyB0aGlzIG1vZHVsZSBiZXlvbmQgdGhpcyBtaW5pbWFsIGFtb3VudC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWRkaXRp b25hbGx5LCBwbGVhc2Ugc2VlIFNsaWRlIDkgaGVyZSBbMV0gYW5kIG5vdGUgdGhhdCB0aGlzIG1v ZHVsZSBpcyBwYXJ0IG9mIGEgcmF0aGVyIGxhcmdlIGVjby1zeXN0ZW0gb2YgaW50ZXJyZWxhdGVk IG1vZHVsZXMuICZuYnNwO1RoZSBwb2ludCBiZWluZyBpcyB0aGF0IHRoZSByZWFzb24gZm9yIGl0 IGJlaW5nICZuYnNwO3N0cnVjdHVyZWQgdGhlIHdheSBpdCBpcyAoZS5nLiwgYXMgZ3JvdXBpbmdz KSBpcyBwcmV0dHkNCiB3ZWxsIGp1c3RpZmllZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgcHJvcG9zYWwgaXMgYXMgZm9sbG93czo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 IDEpIExldOKAmXMgKGFzIGNvLWF1dGhvcnMpIGdldCB0aGUgZHJhZnQta3dhdHNlbi1uZXRjb25m LXRjcC1jbGllbnQtc2VydmVyLTAwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyB3aXRoIGl04oCZcyBjdXJyZW50 IHNjb3BlIHRvIFJGQyBzdGF0dXMgQVNBUCAoYSBjb3VwbGUgbW9udGhzKSwgc28gdGhhdCB0aGlz PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyBmaXZlLXllYXIgTkVUQ09ORiZuYnNwO3Byb2plY3QgY2FuIGVuZC4g Jm5ic3A7SGFwcHkgdG8gdHdlYWsgaXQgYXMgeW91IHNlZSBmaXQuICZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgV2hpY2ggV0cgZG9lcyB0aGlzIGlzJm5ic3A7bm90IGltcG9ydGFudCwgYnV0IGZvciBh IHRpbWUtZXhwZWRpZW5jeSBwZXJzcGVjdGl2ZSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IEkgcmVjb21tZW5k IHRoZSZuYnNwO05FVENPTkYgV0cgZHVlIHRvIHRoZSBoZWF2eSBpbnRlcmxpbmtpbmcgbWVudGlv bmVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyBiZWZvcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAyKSBUQ1BNIHRha2VzIG92ZXIg dGhlIFJGQywgcHVibGlzaGluZyBhIGJpcyB3aXRoIGFsbCB0aGUgZXh0cmEgcGFyYW1ldGVyczxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhhdCBhcmUgaW4mbmJzcDtkcmFmdC1zY2hhcmYtdGNwbS15 YW5nLXRjcC4gJm5ic3A7VENQTSBjb3VsZCBldmVuIGRvIHRoaXMgd29yazxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7aW4gcGFyYWxsZWwsIHNvIGFzIHRvIG5vdCBjYXVzZSBhbnkgc2NoZWR1bGluZyBk ZWxheXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRob3VnaHRzPyAmbmJzcDtDYW4gd2UgaGF2ZSBhIHNob3J0LXRlcm0gY29sbGFib3JhdGlv biBhbmQgdGhlbiBsZXQgVENQTSB0YWtlIG92ZXI/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlsxXSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDQvbWF0ZXJpYWxzL3NsaWRlcy0xMDQtbmV0Y29u Zi1jcnlwdG8tdHlwZXMtY2xpZW50c2VydmVyLXN1aXRlLW9mLWRyYWZ0cy0wMC5wZGYiPmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDQvbWF0ZXJpYWxzL3NsaWRlcy0xMDQt bmV0Y29uZi1jcnlwdG8tdHlwZXMtY2xpZW50c2VydmVyLXN1aXRlLW9mLWRyYWZ0cy0wMC5wZGY8 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+UFM6IExldOKAmXMgKCYjNDM7IGNvLWNoYWlycykgbWVldCB1cCB0b2RheS90b21vcnJvdy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2Vu dCAvLyBjb250cmlidXRvciZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KT24gTWFyIDI2LCAyMDE5LCBhdCAzOjE5IFBNLCBKdWVyZ2VuIFNjaG9lbndh ZWxkZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNp dHkuZGUiPmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5E ZWFyIE1pY2hhZWwsPGJyPg0KPGJyPg0KcGxlYXNlIG5vdGUgdGhhdCBhIGNvbmZpZ3VyYXRpb24g bW9kZWwgZm9yIE5FVENPTkYgaXMgb24gdGhlIE5FVENPTkY8YnI+DQpjaGFydGVyIGZvciB+NSB5 ZWFycy4gVG8gZXN0YWJsaXNoIE5FVENPTkYgc2Vzc2lvbiwgd2Ugb2J2aW91c2x5IG5lZWQ8YnI+ DQp0byBlc3RhYmxpc2ggVENQIGNvbm5lY3Rpb25zLiBUaGlzIGlzIHdoYXQgdGhpcyB3b3JrIGRv ZXMuIEl0IGlzPGJyPg0KZW50aXJlbHkgb3J0aG9nb25hbCB0byBkcmFmdC1zY2hhcmYtdGNwbS15 YW5nLXRjcCwgd2hpY2ggdGFsa3MgYWJvdXQ8YnI+DQpUQ1AgcHJvdG9jb2wgZW5naW5lIGludGVy bmFscy4gSWYgdGhlIFRDUE0gY2hhaXIgaGFzIGFuIGlzc3VlIHdpdGggYTxicj4NCmdlbmVyaWMg c29sdXRpb24gdG8gZXN0YWJsaXNoIFRDUCBjb25uZWN0aW9uIG5vdCBiZWluZyBkb25lIGluIFRD UE0sPGJyPg0Kd2Ugc2hvdWxkIHBlcmhhcHMganVzdCBoYXJkY29kZSBob3cgdG8gZXN0YWJsaXNo IFRDUCBjb25uZWN0aW9ucyBmb3I8YnI+DQpORVRDT05GIGFuZCBSRVNUQ09ORiBhbmQgY2FsbCBp dCB0aGUgZGF5IGFuZCB0aGVuIFRDUE0gY2FuIHBpY2sgdXAgdGhlPGJyPg0KcGllY2VzIGFuZCBz dGFydCB3b3JrIG9uIGEgZ2VuZXJpYyBzb2x1dGlvbi48YnI+DQo8YnI+DQovanM8YnI+DQo8YnI+ DQpPbiBUdWUsIE1hciAyNiwgMjAxOSBhdCAwMTowMjo0OVBNICYjNDM7MDAwMCwgU2NoYXJmLCBN aWNoYWVsIHdyb3RlOjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSBNYWhlc2gsPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBjaGFpciBvZiB0aGUgVENQTSB3b3JraW5nIGdyb3VwLCBJ IGJlbGlldmUgdGhhdCB0aGUgZG9jdW1lbnQgZHJhZnQta3dhdHNlbi1uZXRjb25mLXRjcC1jbGll bnQtc2VydmVyLTAwIGJlbG9uZ3MgaW50byB0aGUgVENQTSB3b3JraW5nIGdyb3VwLiBUaGUgZG9j dW1lbnQgaXMgYWJvdXQgYSBnZW5lcmljIFlBTkcgbW9kZWwgZm9yIGFuIGludGVyZmFjZSBmb3Ig VENQICZxdW90O2ZvciBhbiBTU0gsIFRMUywgb3IgSFRUUA0KIGJhc2VkIGFwcGxpY2F0aW9uJnF1 b3Q7LiBJIGZhaWwgdG8gc2VlIGEgcmVhc29uIHdoeSBzdWNoIGEgZ2VuZXJpYyBUQ1AgbW9kZWwg c2hvdWxkIGJlIGRvbmUgaW4gTkVUQ09ORi48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRodXMsIGFzIGEgY2hhaXIgb2YgVENQTSwgSSBv YmplY3QgdG8gYWRvcHRpb24gaW4gTkVUQ09ORi48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxzbyB3YW50IHRvIG5vdGUgdGhhdCBp dCB3b3VsZCBoYXZlIGJlZW4gcG9zc2libGUgdG8gc2VuZCBhIG5vdGUgdG8gdGhlIFRDUE0gbGlz dCBwcmlvciB0byBzdGFydGluZyBhbiBhZG9wdGlvbiBjYWxsLCBhcyB0aGUgVENQTSBsaXN0IGlz IG1vbml0b3JlZCBieSBtYW55IFRDUCBpbXBsZW1lbnRlcnMgd2hvIGNvdWxkIGJlIGFmZmVjdGVk IGJ5IHN1Y2ggYSBZQU5HIG1vZGVsLiBZQU5HIG1vZGVscyBjYW4NCiBiZSB1c2VkIGluIGRpZmZl cmVudCB1c2UgY2FzZXMuIFRDUE0gaGFzIGEgdHJhZGl0aW9uIG9mIGJlaW5nIHZlcnkgb3BlbiB0 byBwcmVzZW50YXRpb25zIGZyb20gb3RoZXIgd29ya2luZyBncm91cHMgaWYgdGhleSByZWxhdGUg dG8gVENQLiBJIGhhdmUgYWRkZWQgdGhlIFRDUE0gbGlzdCBpbiBDQy48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGFuIGluZGl2aWR1 YWwgY29udHJpYnV0b3IgdG8gdGhlIElFVEYsIEkgaGFwcGVuIHRvIGJlIGFuIGF1dGhvciBvZiBk cmFmdC1zY2hhcmYtdGNwbS15YW5nLXRjcCwgd2hpY2ggYWN0dWFsbHkgd2FzIHN1Ym1pdHRlZCBs YXN0IHllYXIuIEdpdmVuIHRoYXQgZGlmZmVyZW50IHdvcmtpbmcgZ3JvdXBzIHNlZW0gdG8gYmUg aW52b2x2ZWQsIEkgYmVsaWV2ZSB0aGF0IGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gam9pbg0KIGVm Zm9ydHMuIFNob3VsZG4ndCB3ZSBoYXZlIGEgY2hhdCBvbiB0aGUgYmVzdCBuZXh0IHN0ZXBzPzxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhbmtzPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5NaWNoYWVsPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkZyb206IG5ldGNvbmYgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNA aWV0Zi5vcmciPm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IE9uIEJlaGFsZiBPZiBN YWhlc2g8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5KZXRoYW5hbmRhbmk8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZW50OiBUdWVz ZGF5LCBNYXJjaCAyNiwgMjAxOSAxMjoxNyBQTTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvOiBOZXRjb25mICZs dDs8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT4m Z3Q7PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+U3ViamVjdDogW25ldGNvbmZdIEFkb3B0aW9uIHBvbGwgZm9yIHRj cC1jbGllbnQtc2VydmVyIGFuZCBodHRwLWNsaWVudC1zZXJ2ZXI8bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kcmFm dDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgdGhlIHN0YXJ0IG9m IGEgdHdvIHdlZWsgcG9sbCBmb3IgV0cgYWRvcHRpb24gb2YgdGhlIHR3byBkcmFmdHM6PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWt3YXRzZW4tbmV0Y29uZi10Y3AtY2xpZW50LXNlcnZlci0wMCI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWt3YXRzZW4tbmV0Y29uZi10Y3AtY2xpZW50 LXNlcnZlci0wMDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQta3dhdHNlbi1uZXRjb25mLWh0dHAtY2xpZW50LXNlcnZlci0wMCI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWt3YXRzZW4tbmV0Y29uZi1odHRwLWNsaWVu dC1zZXJ2ZXItMDA8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNl IGluZGljYXRlIHlvdXIgc3VwcG9ydCBmb3Igb3IgYW55IG9iamVjdGlvbnMgeW91IG1pZ2h0IGhh dmUgZm9yPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+YWRvcHRpbmcgdGhlIHR3byBkcmFmdHMgYXMgV0cgaXRlbXMg YnkgQXByaWwgOS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYWhlc2ggSmV0 aGFuYW5kYW5pPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21h aWwuY29tIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPm5ldGNvbmYgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOm5l dGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5uZXRjb25mIG1h aWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9y ZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25m Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQotLSA8 YnI+DQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdH bWJIPGJyPg0KUGhvbmU6ICYjNDM7NDkgNDIxIDIwMCAzNTg3ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0NhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4g fCBHZXJtYW55PGJyPg0KRmF4OiAmbmJzcDsmbmJzcDsmIzQzOzQ5IDQyMSAyMDAgMzEwMyAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7PGEgaHJlZj0i aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIj5odHRwczovL3d3dy5qYWNvYnMtdW5p dmVyc2l0eS5kZS88L2E+Jmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6EC6417807D9754DA64F3087E2E2E03E2D28C36Drznt8114rzntrzd_-- From nobody Fri Mar 29 13:25:40 2019 Return-Path: <01000169cb20ec39-94187bed-9312-4e19-a91f-466db763ee7e-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 AC4A7120282 for ; Fri, 29 Mar 2019 13:25: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 KjdHenwElz_n for ; Fri, 29 Mar 2019 13:25:35 -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 E3CD012033F for ; Fri, 29 Mar 2019 13:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553891126; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=s3xZVcktNJgnUhxIQ7OAvcNaJlm1c8TYruCioDu/fnU=; b=TeyxPMkKlI2b41D2FaB7vK1WUbjXqImDz4+dIfSUUypItyuabGgZ3h9ZtPqIlK1Z EaWI81/VMojaG9UFlqOF7OJL1LMQpsEdYPcm1bLdq1foJMIn8Bm65mAPCHSldM3I1g4 pCxT7R7DkhTloVtP+TIHSlsWCxD4MCc6dF/2MRSo= From: Kent Watsen Message-ID: <01000169cb20ec39-94187bed-9312-4e19-a91f-466db763ee7e-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F4ADC1E1-1123-4C52-B1AC-1DCCBE515E80" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 29 Mar 2019 20:25:26 +0000 In-Reply-To: Cc: tom petch , Juergen Schoenwaelder , "netconf@ietf.org" To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= References: <20190321152920.jdkny7szk7ik3sp4@anna.jacobs.jacobs-university.de> <00b701d4e0cb$e79e9660$4001a8c0@gateway.2wire.net> <01000169ac01ff08-27f75526-1e78-461a-be8e-9737cf762edf-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.29-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden 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, 29 Mar 2019 20:25:39 -0000 --Apple-Mail=_F4ADC1E1-1123-4C52-B1AC-1DCCBE515E80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Balazs, > In some implementations I can understand that backup/restore is via = YANG interface, but backup/restore is possible by other methods too. On = the other hand, the private key material should be created and kept on = the owner device according to best security practices and certification = done by for example a certificate signing request. >=20 > In that sense the generate-hidden-key action and the CSR creation = action are solving the most common need for handling keys, and that is = really regardless if the key is stored in a TPM, a file system, or = centralized KMS. True. > I personally was fine with 'hidden' and I was also ok with the current = actions, it was only the descriptions that seemed to be restrictive to = TPM usage, thus I was asking some clarification. However, if 'hidden' is = not true this way, then just call it 'generate-key'. Would that then = create a binary string for the 'private-key' in operational too instead = of 'permanently-hidden' thus you are referring to a 3rd option? As I understand it, your intention is to have users 1) use actions to = generate private keys and CSRs and 2) that the private-key value is = otherwise inaccessible to the users. I don't believe you have a = concern with the keys being "configuration" (since the = nacm:default-deny-all makes the value inaccessible), and that the only = bad part with the current model is that the user has to pass the private = key value, which is bad because a) they are aware of the private key = value and also it's possible that the private key value they generate is = poor quality (e.g. having low entropy). This is effectively what was defined on page 22 in = https://tools.ietf.org/html/draft-ietf-netconf-keystore-00 = (we moved = to the current strategy in the next version of that draft where = (surprise!) the enum was called "INACCESSIBLE". Some more history is = here: = https://mailarchive.ietf.org/arch/msg/netconf/OtYAlqLmlErfCr3Z4mcXqRvez48 = . The main problem with this is actions don't typically create = configuration, though we certainly could define this action as doing so = (i.e., it locks when called)...and we might even see ourselves = doing this even for keys that are *interactively* generated by a = cryptographic processor. Of course, any keys generated by the vendor = during manufacturing (i.e., the IDevID key) would still be operational = state. In order to support systems that have crypto processors, since it may = not be desirable to use the cryptographic processor for all keys, we = need either a parameter or another action to direct the system to use = the crypto processor to generate the key. Regarding what does "inaccessible" mean, the intention is that the value = is not accessible for reasons beyond access control, with this driving = use-case being a cryptographic processor. Since the term = (inaccessible) is being used in a YANG module, it stands to reason that = it applies to all YANG-driven interfaces and that there is no statement = regarding how it may or may not be "inaccessible" in other interfaces. = That said, the goal of YANG modules is to model reality, not just a view = presented by YANG-driven interfaces, and I imagine great confusion = ensuing if mismatches exist across interfaces. I agree that the description statement for the "permanently-hidden" = enumeration can be improved, how about this? leaf private-key { nacm:default-deny-all; type union { type binary; type enumeration { enum permanently-hidden { description "The private key is inaccessible due to being protected by the system (e.g., a cryptographic hardware module)."; } } } ... } Notes: 1) I removed the "It is not possible to configure a permanently hidden = key, as a real private key value must be set." text because it was = confusing and yet what's intended is self-evident (i.e., the leaf is a = union of a value and an enum, only one can be passed). 2) I removed "Permanently hidden keys cannot be archived or backed up." = text because it was a bit overreaching. As mentioned, even = TPM-protected keys can be backed-up/restored if shrouded and the = restoration is to the same machine. The more correct statement is "RMA = workflows are limited", but it doesn't need to be said here. If the goal is to open up these actions for general use, I think that we = SHOULD update them to generate *configuration*. Clearly the intent is = that keys are configuration, use of the action should be seen as = supporting a best practice, but otherwise shouldn't change the = characteristic that interactively-generated keys are configuration. Thoughts? Kent // contributor --Apple-Mail=_F4ADC1E1-1123-4C52-B1AC-1DCCBE515E80 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Balazs,

In some implementations I can understand that = backup/restore is via YANG interface, but backup/restore is possible by = other methods too.  On the other hand, the private key material = should be created and kept on the owner device according to best = security practices and certification done by for example a certificate = signing request.

In that sense = the generate-hidden-key action and the CSR creation action are solving = the most common need for handling keys, and that is really regardless if = the key is stored in a TPM, a file system, or centralized KMS.

True.

I personally was fine with = 'hidden' and I was also ok with the current actions, it was only the = descriptions that seemed to be restrictive to TPM usage, thus I was = asking some clarification. However, if 'hidden' is not true this way, = then just call it 'generate-key'. Would that then create a binary string = for the 'private-key' in operational too instead of 'permanently-hidden' = thus you are referring to a 3rd option?

As I = understand it, your intention is to have users 1) use actions to = generate private keys and CSRs and 2) that the private-key value is = otherwise inaccessible to the users.   I don't believe you have a = concern with the keys being "configuration" (since the = nacm:default-deny-all makes the value inaccessible), and that the only = bad part with the current model is that the user has to pass the private = key value, which is bad because a) they are aware of the private key = value and also it's possible that the private key value they generate is = poor quality (e.g. having low entropy).

This is effectively what was defined on page 22 in = https://tools.ietf.org/html/draft-ietf-netconf-keystore-00&= nbsp;(we moved to the current strategy in the next version of that draft = where (surprise!) the enum was called "INACCESSIBLE".   Some = more history is here: https://mailarchive.ietf.org/arch/msg/netconf/OtYAlqLmlErfCr3Z4= mcXqRvez48.

The main problem with this is actions don't = typically create configuration, though we certainly could define this = action as doing so (i.e., it locks <running> when called)...and we = might even see ourselves doing this even for keys that are = *interactively* generated by a cryptographic processor.  Of course, = any keys generated by the vendor during manufacturing (i.e., the IDevID = key) would still be operational state.

In order to support systems that have crypto = processors, since it may not be desirable to use the cryptographic = processor for all keys, we need either a parameter or another action to = direct the system to use the crypto processor to generate the = key.

Regarding what = does "inaccessible" mean, the intention is that the value is not = accessible for reasons beyond access control, with this driving use-case = being a cryptographic processor.   Since the term (inaccessible) is = being used in a YANG module, it stands to reason that it applies to all = YANG-driven interfaces and that there is no statement regarding how it = may or may not be "inaccessible" in other interfaces.  That said, = the goal of YANG modules is to model reality, not just a view presented = by YANG-driven interfaces, and I imagine great confusion ensuing if = mismatches exist across interfaces.

I agree that the description statement = for the "permanently-hidden" enumeration can be improved, how about = this?

    leaf private-key {
 =     nacm:default-deny-all;
    =   type union {
      =   type binary;
      =   type enumeration {
    =       enum permanently-hidden {
            description
              "The = private key is inaccessible due to being
    =            protected by the system (e.g., = a cryptographic
            =    hardware module).";
      =     }
        }
      }
  =     ...
    }

Notes:

1) = I removed the "It is not possible to configure a permanently hidden = key, as a real private key value must be set." text because it was = confusing and yet what's intended is self-evident (i.e., the leaf is a = union of a value and an enum, only one can be passed).

2) I removed "Permanently hidden keys cannot be = archived or backed up." text because it was a bit overreaching.  As = mentioned, even TPM-protected keys can be backed-up/restored if shrouded = and the restoration is to the same machine.  The more correct = statement is "RMA workflows are limited", but it doesn't need to be said = here.


If the goal is to open up these actions for = general use, I think that we SHOULD update them to generate = *configuration*.   Clearly the intent is that keys are = configuration, use of the action should be seen as supporting a best = practice, but otherwise shouldn't change the characteristic that = interactively-generated keys are configuration.

Thoughts?

Kent = // contributor



= --Apple-Mail=_F4ADC1E1-1123-4C52-B1AC-1DCCBE515E80-- From nobody Fri Mar 29 13:53:31 2019 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 646D412036F for ; Fri, 29 Mar 2019 13:53:29 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 F_bwItIw7hLK for ; Fri, 29 Mar 2019 13:53:26 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32EE120366 for ; Fri, 29 Mar 2019 13:53:25 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 24C0B6CF; Fri, 29 Mar 2019 21:53:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id OhjnqTFWw_N4; Fri, 29 Mar 2019 21:53:18 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 29 Mar 2019 21:53:18 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id D09F3200A8; Fri, 29 Mar 2019 21:53:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id diTm0feoxKsL; Fri, 29 Mar 2019 21:53:18 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 1EA73200A7; Fri, 29 Mar 2019 21:53:18 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Fri, 29 Mar 2019 21:53:17 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 0B8493007A4129; Fri, 29 Mar 2019 21:53:16 +0100 (CET) Date: Fri, 29 Mar 2019 21:53:16 +0100 From: Juergen Schoenwaelder To: Kent Watsen CC: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= , tom petch , "netconf@ietf.org" Message-ID: <20190329205316.tcjzicuythyd4gvm@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= , tom petch , "netconf@ietf.org" References: <20190321152920.jdkny7szk7ik3sp4@anna.jacobs.jacobs-university.de> <00b701d4e0cb$e79e9660$4001a8c0@gateway.2wire.net> <01000169ac01ff08-27f75526-1e78-461a-be8e-9737cf762edf-000000@email.amazonses.com> <01000169cb20ec39-94187bed-9312-4e19-a91f-466db763ee7e-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <01000169cb20ec39-94187bed-9312-4e19-a91f-466db763ee7e-000000@email.amazonses.com> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden 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, 29 Mar 2019 20:53:30 -0000 I agree, I think we need to distinguish - upload of keys - generation of keys on the box that become (protected) configuration - generation of keys on the box that will to into hardware protected storage (and never be accessible) and the creation of a private key that becomes (protected) configuration is similar to the creation of a user account, where an unused uid is allocated that becomes configuration. /js On Fri, Mar 29, 2019 at 08:25:26PM +0000, Kent Watsen wrote: > Hi Balazs, > > > In some implementations I can understand that backup/restore is via YANG interface, but backup/restore is possible by other methods too. On the other hand, the private key material should be created and kept on the owner device according to best security practices and certification done by for example a certificate signing request. > > > > In that sense the generate-hidden-key action and the CSR creation action are solving the most common need for handling keys, and that is really regardless if the key is stored in a TPM, a file system, or centralized KMS. > > True. > > > I personally was fine with 'hidden' and I was also ok with the current actions, it was only the descriptions that seemed to be restrictive to TPM usage, thus I was asking some clarification. However, if 'hidden' is not true this way, then just call it 'generate-key'. Would that then create a binary string for the 'private-key' in operational too instead of 'permanently-hidden' thus you are referring to a 3rd option? > > As I understand it, your intention is to have users 1) use actions to generate private keys and CSRs and 2) that the private-key value is otherwise inaccessible to the users. I don't believe you have a concern with the keys being "configuration" (since the nacm:default-deny-all makes the value inaccessible), and that the only bad part with the current model is that the user has to pass the private key value, which is bad because a) they are aware of the private key value and also it's possible that the private key value they generate is poor quality (e.g. having low entropy). > > This is effectively what was defined on page 22 in https://tools.ietf.org/html/draft-ietf-netconf-keystore-00 (we moved to the current strategy in the next version of that draft where (surprise!) the enum was called "INACCESSIBLE". Some more history is here: https://mailarchive.ietf.org/arch/msg/netconf/OtYAlqLmlErfCr3Z4mcXqRvez48 . > > The main problem with this is actions don't typically create configuration, though we certainly could define this action as doing so (i.e., it locks when called)...and we might even see ourselves doing this even for keys that are *interactively* generated by a cryptographic processor. Of course, any keys generated by the vendor during manufacturing (i.e., the IDevID key) would still be operational state. > > In order to support systems that have crypto processors, since it may not be desirable to use the cryptographic processor for all keys, we need either a parameter or another action to direct the system to use the crypto processor to generate the key. > > Regarding what does "inaccessible" mean, the intention is that the value is not accessible for reasons beyond access control, with this driving use-case being a cryptographic processor. Since the term (inaccessible) is being used in a YANG module, it stands to reason that it applies to all YANG-driven interfaces and that there is no statement regarding how it may or may not be "inaccessible" in other interfaces. That said, the goal of YANG modules is to model reality, not just a view presented by YANG-driven interfaces, and I imagine great confusion ensuing if mismatches exist across interfaces. > > I agree that the description statement for the "permanently-hidden" enumeration can be improved, how about this? > > leaf private-key { > nacm:default-deny-all; > type union { > type binary; > type enumeration { > enum permanently-hidden { > description > "The private key is inaccessible due to being > protected by the system (e.g., a cryptographic > hardware module)."; > } > } > } > ... > } > > Notes: > > 1) I removed the "It is not possible to configure a permanently hidden key, as a real private key value must be set." text because it was confusing and yet what's intended is self-evident (i.e., the leaf is a union of a value and an enum, only one can be passed). > > 2) I removed "Permanently hidden keys cannot be archived or backed up." text because it was a bit overreaching. As mentioned, even TPM-protected keys can be backed-up/restored if shrouded and the restoration is to the same machine. The more correct statement is "RMA workflows are limited", but it doesn't need to be said here. > > > If the goal is to open up these actions for general use, I think that we SHOULD update them to generate *configuration*. Clearly the intent is that keys are configuration, use of the action should be seen as supporting a best practice, but otherwise shouldn't change the characteristic that interactively-generated keys are configuration. > > Thoughts? > > Kent // contributor > > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103