From nobody Wed Jun 1 09:47:17 2016 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 DD71A12D530 for ; Wed, 1 Jun 2016 09:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=randy_presuhn@mindspring.com header.d=mindspring.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 mBkLbLWUxWLD for ; Wed, 1 Jun 2016 09:47:08 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 283F712B05C for ; Wed, 1 Jun 2016 09:47:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=sB2x4nlOI8Go53OS6ArN7dTYNv6kPQ4QnU/1g/FFTt3Loo4e5L8OFOF6r/NHDvvy; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.38] (helo=elwamui-lapwing.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1b89IG-000778-64 for netconf@ietf.org; Wed, 01 Jun 2016 12:46:56 -0400 Received: from 76.254.52.66 by webmail.earthlink.net with HTTP; Wed, 1 Jun 2016 12:46:55 -0400 Message-ID: <3955733.1464799615772.JavaMail.wam@elwamui-lapwing.atl.sa.earthlink.net> Date: Wed, 1 Jun 2016 09:46:55 -0700 (GMT-07:00) From: Randy Presuhn To: "netconf@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b484d7840976cb7ead1243281b923fde8179fdb8ed5d60b5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.38 Archived-At: Subject: Re: [Netconf] Clarification request for NETCONF edit-config default-operation replace X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 16:47:10 -0000 Hi - > From: Andy Bierman > Sent: May 31, 2016 5:49 PM > To: "Sterne, Jason (Nokia - CA)" > Cc: "netconf@ietf.org" > Subject: Re: [Netconf] Clarification request for NETCONF edit-config default-operation replace ... > copy-config is for complete configurations. > There is an unwritten assumption that the copy-config contents are > not pruned at all by access control. There are (at least) two ways of understanding "pruned" in this statement. But I think, more importantly, that "unwritten assumptions", particularly with respect to access control, are a very bad thing in standardization, and it might be worthwhile to consider how to make whatever is intended explicit. > A missing node will be > interpreted as a delete attempt. This is what *I* would expect, but I'm not a netconf person. > This is not at all desirable > if the client is not authorized and is not even aware > of these "hidden" nodes. Perhaps. If one agrees with your earlier statement that "copy-config is for complete configurations", such behaviour is what one would expect - only clients with unlimited write access should even attempt a copy-config. For other clients, it seems it would only function as a way of finding out whether there exist portions of the source or destination configuration to which they do not have read or write access, respectively. Randy From nobody Wed Jun 1 11:26:57 2016 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 C6D2112D16C for ; Wed, 1 Jun 2016 11:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 QoQYFllqZ4AP for ; Wed, 1 Jun 2016 11:26:55 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBADC12D0D1 for ; Wed, 1 Jun 2016 11:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3581; q=dns/txt; s=iport; t=1464805614; x=1466015214; h=from:to:cc:subject:date:message-id:mime-version; bh=EH/8R0weVylQvOBa5pvEerCDN4nHl092BUGJ0HM0WHw=; b=B360YvbArx/pTjht92G3YDEtHhg/g2CuNfKfMncxLq9IG63BVq0q1uXL fY6j08BrM7VjpcLXr50MYmTwpqBgRPVntU72WrDBZLjWDbTyhw6sGultd +rmQ4QspALXKlIQu2mKCKyFeX7mnjYTaTOK1kNyA6e+OAV1db4Oo8ck5K 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAgDUJ09X/4UNJK1dgnBNVn0GtR2Ee?= =?us-ascii?q?QENgXokhW2BNTgUAQEBAQEBAWUnhEwMbRIBDHQfCAQBDYg0DsE9AQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEYBYYnjmcFjh2KGgGFf4ggjxyPSwEeAQFCg21uAQGJNn8BA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.26,402,1459814400"; d="scan'208,217";a="280432106" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jun 2016 18:26:53 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u51IQrux011987 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 Jun 2016 18:26:53 GMT Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 1 Jun 2016 13:26:53 -0500 Received: from xch-rcd-010.cisco.com ([173.37.102.20]) by XCH-RCD-010.cisco.com ([173.37.102.20]) with mapi id 15.00.1104.009; Wed, 1 Jun 2016 13:26:53 -0500 From: "Yi Yang (yiya)" To: Andy Bierman , Martin Bjorklund , "Kent Watsen" Thread-Topic: data format for list entry Thread-Index: AQHRvDMrpNbid4+bfUeprsDZEbYSJw== Date: Wed, 1 Jun 2016 18:26:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.228.113] Content-Type: multipart/alternative; boundary="_000_D374A12B15C46yiyaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: [Netconf] data format for list entry X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 18:26:57 -0000 --_000_D374A12B15C46yiyaciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am trying to understand how the data should be formatted when updating a = list entry. Using the list model presented in https://tools.ietf.org/html/d= raft-ietf-netconf-restconf-13#section-3.5.1, if I want to create an entry i= n the list2 with key (key4v, key5v), I undertand the creation request shoul= d be encoded as: GET /restconf/data/example-top:top/list1=3Dkey1v,key2v,key3v/list2=3Dkey4v,= key5v Accept: application/yang.data+json Inside the rest request, how the data will be encapsulated in json? Based o= n the example given at https://tools.ietf.org/html/draft-ietf-netconf-restc= onf-13#appendix-D.3.9, it seems the entry needs to encoded as a list, even = though it's a single list entry: { "list2": [ { "key4": "key4v", "key5": "key5v", "X": "x_value" } ] } Is this correct? Yi --_000_D374A12B15C46yiyaciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <8124B7C4D1C191488126830BBBD28ADC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I am trying to understand how the data = should be formatted when updating a list entry. Using the list model presen= ted in https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#sect= ion-3.5.1, if I want to create an entry in the list2 with key (key4v, key5v), I undertand the creation request sho= uld be encoded as: 

GET /restconf/data/example-top:top/list1=3Dkey1v,key2v,key3v/list2=3Dk= ey4v,key5v
Accept: application/yang.data+json<= /div>
Inside the rest request, how the data will be encapsulated in json? Ba= sed on the example given at https://tools.ietf.org/html/draft-ietf-net= conf-restconf-13#appendix-D.3.9, it seems the entry needs to encoded as a list, even though it’s a single list entry:

{
    “list2”: [
        {
          &nbs= p; “key4”: “key4v”,
          &nbs= p; “key5”: “key5v”,
          &nbs= p; “X”: “x_value"
        }
    ]
}

Is this correct?

Yi
--_000_D374A12B15C46yiyaciscocom_-- From nobody Thu Jun 2 03:37:06 2016 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 83A4712D569 for ; Thu, 2 Jun 2016 03:37:04 -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 37fa2VxKeQ8i for ; Thu, 2 Jun 2016 03:37:02 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 372D412D0BE for ; Thu, 2 Jun 2016 03:37:02 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id E643A1CC024F; Thu, 2 Jun 2016 12:37:05 +0200 (CEST) From: Ladislav Lhotka To: "Yi Yang \(yiya\)" , Andy Bierman , Martin Bjorklund , Kent Watsen In-Reply-To: References: User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 02 Jun 2016 12:36:58 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] data format for list entry X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 10:37:04 -0000 "Yi Yang (yiya)" writes: > I am trying to understand how the data should be formatted when updating a list entry. Using the list model presented in https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-3.5.1, if I want to create an entry in the list2 with key (key4v, key5v), I undertand the creation request should be encoded as: > > GET /restconf/data/example-top:top/list1=key1v,key2v,key3v/list2=key4v,key5v > Accept: application/yang.data+json To create a new entry of list2, you have to POST to the list resource, so the Request-URI should be POST /restconf/data/example-top:top/list1=key1v,key2v,key3v/list2 > > Inside the rest request, how the data will be encapsulated in json? Based on the example given at https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#appendix-D.3.9, it seems the entry needs to encoded as a list, even though it's a single list entry: > > { > "list2": [ > { > "key4": "key4v", > "key5": "key5v", > "X": "x_value" > } > ] > } I think this is correct. Lada > > Is this correct? > > Yi > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jun 2 03:49:53 2016 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 B4A5812D110 for ; Thu, 2 Jun 2016 03:49:52 -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 IMhsys46f6Qm for ; Thu, 2 Jun 2016 03:49:51 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4DE12D093 for ; Thu, 2 Jun 2016 03:49:51 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 310941CC024F; Thu, 2 Jun 2016 12:49:57 +0200 (CEST) From: Ladislav Lhotka To: "Yi Yang \(yiya\)" , Andy Bierman , Martin Bjorklund , Kent Watsen In-Reply-To: References: User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 02 Jun 2016 12:49:50 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] data format for list entry X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 10:49:52 -0000 "Yi Yang (yiya)" writes: > I am trying to understand how the data should be formatted when updating a list entry. Using the list model presented in https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-3.5.1, if I want to create an entry in the list2 with key (key4v, key5v), I undertand the creation request should be encoded as: > > GET /restconf/data/example-top:top/list1=key1v,key2v,key3v/list2=key4v,key5v > Accept: application/yang.data+json > > Inside the rest request, how the data will be encapsulated in json? > Based on the example given at > https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#appendix-D.3.9, > it seems the entry needs to encoded as a list, even though it's a > single list entry: Oh, I missed this point. Yes, it would indeed be more logical to send just the entry, i.e. { "key4": "key4v", "key5": "key5v", "X": "x_value" } However, this won't work in the XML encoding where each list entry is wrapped in an element with the list name: key4v key5v x_value Lada > > { > "list2": [ > { > "key4": "key4v", > "key5": "key5v", > "X": "x_value" > } > ] > } > > Is this correct? > > Yi > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jun 2 07:15:55 2016 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 B651E12D72C for ; Thu, 2 Jun 2016 07:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 mCOPHgByjtFh for ; Thu, 2 Jun 2016 07:15:47 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3BAB12D6FA for ; Thu, 2 Jun 2016 07:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2147; q=dns/txt; s=iport; t=1464876947; x=1466086547; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0koxm1zPpOyL/AB2DW0DqCmsNuJc9F7BYIdzCeXe6FQ=; b=iTS+WA2L2+dRIN3dzGo8dOM5gKXDA6BCMy9nUMob9VJTOiLBp3F1np7I EHwDH5mvgg1HxAQLe493j58uwa2BwZa82A16aGiVqQ/c6HId41k7OvEpu lJUt5ZWyRVGQ5wt2Wo7LwEchcPx1wpfOab4QTUmYwcA1Erz4bKm5AE7Xr k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQCEPlBX/4UNJK1dgzpWfQa6KYF5F?= =?us-ascii?q?w2FJEoCgS84FAEBAQEBAQFlJ4RGAQEEAQEBCWILEAIBCEYnCyUCBAENBYgvDrV?= =?us-ascii?q?sjBoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYnhE2EEhEBHIVaBY1lOIoaAYV/i?= =?us-ascii?q?CCPHI9LAR42g25uAQGJRTZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,406,1459814400"; d="scan'208";a="109064672" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jun 2016 14:15:46 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u52EFk6g006278 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 Jun 2016 14:15:46 GMT Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 2 Jun 2016 09:15:46 -0500 Received: from xch-rcd-010.cisco.com ([173.37.102.20]) by XCH-RCD-010.cisco.com ([173.37.102.20]) with mapi id 15.00.1104.009; Thu, 2 Jun 2016 09:15:46 -0500 From: "Yi Yang (yiya)" To: Ladislav Lhotka , Andy Bierman , "Martin Bjorklund" , Kent Watsen Thread-Topic: [Netconf] data format for list entry Thread-Index: AQHRvDMrpNbid4+bfUeprsDZEbYSJ5/WVGQA///2eQA= Date: Thu, 2 Jun 2016 14:15:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.179.89] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] data format for list entry X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 14:15:54 -0000 Hi Lada, To have a consisten structure between JSON and XML, does this indicate the JSON format MSUT also be wrapped in an element with the list name, as noted in my previous email? { =B3list2=B2: [ { =B3key4=B2: =B3key4v=B2, =B3key5=B2: =B3key5v=B2, =B3X=B2: =B3x_value" } ] } Regardless, it would be great to have some clarifications on this in the draft. Yi On 6/2/16, 6:49 AM, "Ladislav Lhotka" wrote: >"Yi Yang (yiya)" writes: > >> I am trying to understand how the data should be formatted when >>updating a list entry. Using the list model presented in >>https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-3.5.1, >> if I want to create an entry in the list2 with key (key4v, key5v), I >>undertand the creation request should be encoded as: >> >> GET=20 >>/restconf/data/example-top:top/list1=3Dkey1v,key2v,key3v/list2=3Dkey4v,ke= y5v >> Accept: application/yang.data+json >> >> Inside the rest request, how the data will be encapsulated in json? >> Based on the example given at >>=20 >>https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#appendix-D.3.9 >>, >> it seems the entry needs to encoded as a list, even though it's a >> single list entry: > >Oh, I missed this point. Yes, it would indeed be more logical to send >just the >entry, i.e. > >{ > "key4": "key4v", > "key5": "key5v", > "X": "x_value" >} > >However, this won't work in the XML encoding where each list entry is >wrapped in an element with the list name: > > > key4v > key5v > x_value > > >Lada > >> >> { >> "list2": [ >> { >> "key4": "key4v", >> "key5": "key5v", >> "X": "x_value" >> } >> ] >> } >> >> Is this correct? >> >> Yi >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > >--=20 >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C From nobody Thu Jun 2 07:46:56 2016 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 D3A4512D522 for ; Thu, 2 Jun 2016 07:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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, RP_MATCHES_RCVD=-1.426] 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 Stmgjv1oAotm for ; Thu, 2 Jun 2016 07:46:51 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6DE12D1D8 for ; Thu, 2 Jun 2016 07:46:50 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:b58a:79e7:8e5f:5ee4] (unknown [IPv6:2001:718:1a02:1:b58a:79e7:8e5f:5ee4]) by mail.nic.cz (Postfix) with ESMTPSA id 97CA5607E1; Thu, 2 Jun 2016 16:46:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1464878808; bh=emGgEagXcgOYYEy2uOAWtoe+J5WA17hTfToKu7ivrlA=; h=From:Date:To; b=x4kObR/QnrGegLWCp/iiMv9dNgg8auKsvthSd6hZnhNJhXs+y85JXcZ8SvKpdG9Ma Ceu6mukzHyytNwAuCbkkYBad29SZYOaLoatgkbM8hDrTGFmArSkgXBa7X+kBwc6qmS 1gSeHmSt8QJlyhUkMW2IladnFIbQM0ZmkZK4XczM= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 2 Jun 2016 16:46:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Yi Yang (yiya)" X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] data format for list entry X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 14:46:54 -0000 > On 02 Jun 2016, at 16:15, Yi Yang (yiya) wrote: >=20 > Hi Lada, >=20 > To have a consisten structure between JSON and XML, does this indicate = the > JSON format MSUT also be wrapped in an element with the list name, as > noted in my previous email? Yes, RESTCONF designers preferred to have a consistent structure. This = was already discussed: https://www.ietf.org/mail-archive/web/netconf/current/msg11023.html Lada >=20 > { > =B3list2=B2: [ > { > =B3key4=B2: =B3key4v=B2, > =B3key5=B2: =B3key5v=B2, > =B3X=B2: =B3x_value" > } > ] > } >=20 > Regardless, it would be great to have some clarifications on this in = the > draft. >=20 > Yi >=20 >=20 >=20 >=20 >=20 > On 6/2/16, 6:49 AM, "Ladislav Lhotka" wrote: >=20 >> "Yi Yang (yiya)" writes: >>=20 >>> I am trying to understand how the data should be formatted when >>> updating a list entry. Using the list model presented in >>> = https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-3.5.1, >>> if I want to create an entry in the list2 with key (key4v, key5v), I >>> undertand the creation request should be encoded as: >>>=20 >>> GET=20 >>> = /restconf/data/example-top:top/list1=3Dkey1v,key2v,key3v/list2=3Dkey4v,key= 5v >>> Accept: application/yang.data+json >>>=20 >>> Inside the rest request, how the data will be encapsulated in json? >>> Based on the example given at >>>=20 >>> = https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#appendix-D.3.9 >>> , >>> it seems the entry needs to encoded as a list, even though it's a >>> single list entry: >>=20 >> Oh, I missed this point. Yes, it would indeed be more logical to send >> just the >> entry, i.e. >>=20 >> { >> "key4": "key4v", >> "key5": "key5v", >> "X": "x_value" >> } >>=20 >> However, this won't work in the XML encoding where each list entry is >> wrapped in an element with the list name: >>=20 >> >> key4v >> key5v >> x_value >> >>=20 >> Lada >>=20 >>>=20 >>> { >>> "list2": [ >>> { >>> "key4": "key4v", >>> "key5": "key5v", >>> "X": "x_value" >>> } >>> ] >>> } >>>=20 >>> Is this correct? >>>=20 >>> Yi >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>=20 >> --=20 >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jun 2 07:53:32 2016 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 7B9C712D548 for ; Thu, 2 Jun 2016 07:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 PDoGzYr1GGmD for ; Thu, 2 Jun 2016 07:53:29 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 958FA12D522 for ; Thu, 2 Jun 2016 07:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1960; q=dns/txt; s=iport; t=1464879209; x=1466088809; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=liTcdMhV56hNI69f3osN+rLg734bJfIolb9yFZsD5Kg=; b=GYEg8FLhncakH4k7NnqJabWvge/mRryDu3h+SKygxIJnVVlWm0KqHzkP OfrGx5mTrgZ5FEL1ABujJi8ZJXkBsRtX82Pb+gVEoaNnK6BH9I2blS5nY e0MLo23Q/Rqn/+onzmpNFOKnYmd5OjXuJsXVO1OLuxYtl/uhkwFD9xC5Q g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQCVR1BX/5hdJa1dgzpWfQa6J4F5F?= =?us-ascii?q?w2FJEoCgS84FAEBAQEBAQFlJ4RGAQEEAQEBawsQAgEIRicLJQIEAQ0FiC8OwiU?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYnhE2EQIVaBY1lOIoaAYV/iCCPHI9LA?= =?us-ascii?q?R42g25uAQGJe38BAQE?= X-IronPort-AV: E=Sophos;i="5.26,406,1459814400"; d="scan'208";a="280807270" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jun 2016 14:53:28 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u52ErSC8016928 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 Jun 2016 14:53:28 GMT Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 2 Jun 2016 09:53:28 -0500 Received: from xch-rcd-010.cisco.com ([173.37.102.20]) by XCH-RCD-010.cisco.com ([173.37.102.20]) with mapi id 15.00.1104.009; Thu, 2 Jun 2016 09:53:28 -0500 From: "Yi Yang (yiya)" To: Ladislav Lhotka , Andy Bierman , "Martin Bjorklund" , Kent Watsen Thread-Topic: [Netconf] data format for list entry Thread-Index: AQHRvDMrpNbid4+bfUeprsDZEbYSJ5/WUMwAgAAEm4A= Date: Thu, 2 Jun 2016 14:53:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.179.89] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] data format for list entry X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 14:53:31 -0000 Hi Lada, While my original question was about =B3GET=B2, your response actually brin= gs a second question to me. Yes, as you suggested, creating a list entry can be done by POST to the list URI POST /restconf/data/example-top:top/list1=3Dkey1v,key2v,key3v/list2 Or, it can be created by PUT to the list-entry specific URI: PUT=20 /restconf/data/example-top:top/list1=3Dkey1v,key2v,key3v/list2=3Dkey4v,key5= v I assume, for consistency, both should be wrapped in an element with the list name? Yi On 6/2/16, 6:36 AM, "Ladislav Lhotka" wrote: >"Yi Yang (yiya)" writes: > >> I am trying to understand how the data should be formatted when >>updating a list entry. Using the list model presented in >>https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-3.5.1, >> if I want to create an entry in the list2 with key (key4v, key5v), I >>undertand the creation request should be encoded as: >> >> GET=20 >>/restconf/data/example-top:top/list1=3Dkey1v,key2v,key3v/list2=3Dkey4v,ke= y5v >> Accept: application/yang.data+json > >To create a new entry of list2, you have to POST to the list resource, so >the Request-URI should be > > >> >> Inside the rest request, how the data will be encapsulated in json? >>Based on the example given at >>https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#appendix-D.3.9 >>, it seems the entry needs to encoded as a list, even though it's a >>single list entry: >> >> { >> "list2": [ >> { >> "key4": "key4v", >> "key5": "key5v", >> "X": "x_value" >> } >> ] >> } > >I think this is correct. > >Lada > >> >> Is this correct? >> >> Yi >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > >--=20 >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C From nobody Thu Jun 2 17:48:33 2016 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 4719912D1DA for ; Thu, 2 Jun 2016 17:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 r1UA0Yk5-3e3 for ; Thu, 2 Jun 2016 17:48:17 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 6A08112D535 for ; Thu, 2 Jun 2016 17:48:17 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id DF01C8CCF2B00; Fri, 3 Jun 2016 00:48:13 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u530mGvd004718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2016 00:48:16 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u530mFvv003741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jun 2016 00:48:16 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Thu, 2 Jun 2016 20:48:15 -0400 From: "Sterne, Jason (Nokia - CA)" To: Mahesh Jethanandani Thread-Topic: [Netconf] Clarification request for NETCONF edit-config default-operation replace Thread-Index: AQHRlyYGiZoT03uS4U+O6QebXc6r0J+hZVpggACXP4CABVTvsIAAYfwAgCqd10CAAPY+gIAACTeggABg+oCAA4JwkA== Date: Fri, 3 Jun 2016 00:48:15 +0000 Message-ID: References: <01f401d1a54f$621dbad0$26593070$@seguesoft.com> <20160531.105003.567321207823725528.mbj@tail-f.com> <4CE02CDD-99AA-4E12-AFAE-8A06081749E4@gmail.com> In-Reply-To: <4CE02CDD-99AA-4E12-AFAE-8A06081749E4@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Clarification request for NETCONF edit-config default-operation replace X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 00:48:26 -0000 Hi Mahesh, In a system with the writable-running capability you can dire= ctly to the running datastore. SR OS has that capability (and I think that= is basically how Cisco IOS, non-XR, works in their CLI). Regards, Jason=20 -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh Jethana= ndani Sent: Tuesday, May 31, 2016 11:10 To: Sterne, Jason (Nokia - CA) Cc: netconf@ietf.org Subject: Re: [Netconf] Clarification request for NETCONF edit-config defaul= t-operation replace > On May 31, 2016, at 6:36 AM, Sterne, Jason (Nokia - CA) wrote: >=20 > Thx Martin. Your explanation that a default replace operation can only a= pply to elements that are in the request helps a lot. >=20 > So there really is no such thing as an edit-config 'replace' operation th= at operates "at the root". That can only be done with a special dedicated R= PC (e.g. copy-config as you show in Case 5). >=20 > So my case 4 is equivalent to this: >=20 >> >> =20 >> 10 =20 >> =20 >> >=20 > which will replace the entire contents of the /system subtree (but not an= ything else). >=20 > On a related note -> is the final result (i.e. datastore contents) of a r= eplace operation always exactly the same as a remove + merge with the same = data at the same location ? I can't think of an example where that isn't t= rue but I may be missing some corner case. =20 >=20 > For the candidate datastore it seems that 'replace' is simply a shorthand= way to do remove+merge in a single edit-config. For a running datastore (= writeable-running) the impacts would be quite different though since the ed= it-config 'remove' would be applied immediately which would clear out all c= onfig for a short period before the 'merge' then gets processed. You would normally edit the candidate configuration, and once validated com= mit it to running. You would normally not the running data st= ore directly. Mahesh Jethanandani mjethanandani@gmail.com >=20 > Regards, > Jason >=20 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, May 31, 2016 4:50 > To: Sterne, Jason (Nokia - CA) > Cc: xiangli@seguesoft.com; wivory@Brocade.com; netconf@ietf.org > Subject: Re: [Netconf] Clarification request for NETCONF edit-config=20 > default-operation replace >=20 > "Sterne, Jason (Nokia - CA)" wrote: >> Hi guys, >>=20 >> I think there is some conflicting information wrt default-operation=20 >> replace here. >=20 > I agree it is not clear. >=20 >> The following snippet of RFC 6241 clearly states (IMO) that the=20 >> entire config is affected/replaced. The first sentence says it. >=20 > I don't think this statement clearly says that the entire datastore is re= placed. It uses the term "completely replace". I don't know how that is d= ifferent from "replace". IMO, "replace" implies "completely"... >=20 >> Then the second sentence gives yet another indication that it=20 >> replaces the entire config: >=20 > Not necessarily. >=20 >>> replace: The configuration data in the parameter >>> completely replaces the configuration in the target >>> datastore. This is useful for loading previously saved >>> configuration data. >>=20 >>=20 >> I also found an older discussion on this on the mailing list that=20 >> indicates that a default action of replace is intended to be used for=20 >> the entire datastore. From >> https://mailarchive.ietf.org/arch/msg/netconf/s4KOJxIgbDzqAXS-uF_jFi-iQs= U: >>=20 >>=20 >>> 1) >>> $backup =3D get-config(source=3Drunning) >>> 2) >>> copy-config(source=3D$backup, target=3Drunning) OR >>> edit-config(source=3D$backup, target=3Drunning, >>> default-operation=3Dreplace)" >>=20 >>=20 >> operations are inherited. The default-operation applies=20 >> to all top level objects. But I'm not certain whether it applies to=20 >> all top level objects in the data model on the server or just all the=20 >> top level objects that are included in the request. >=20 > The latter. It is just a default value for the "operation" attribute; i.= e., instead of using "default-operation", you could explicitly set the "ope= ration" attribute - and you can only do that for the elements in the reques= t (obvioulsy). >=20 >> From the descriptions above it seems it must apply to all top level=20 >> objects in the server but that seems to conflict with: >>=20 >>> "only the configuration actually present in the parameter=20 >>> is affected" >>=20 >> Here is a set of examples that may help clarify things. The first 3=20 >> cases are an incremental lead-in to case 4 which is the least clear=20 >> for me. >>=20 >> ## Initial server Config A (used in all the cases below): >> >> >> 12 >> true >> >> >> 132 >> true >> >> >> >> >> 8 >> true >> >> >>=20 >> ## Case 1: >> - Initial Config A >> - edit-config request (no default operation): >> >> >> 10 >> >> >> - Resulting config on the server (only 'min-length' affected): >> >> >> 10 >> true >> >> >> 132 >> true >> >> >> >> >> 8 >> true >> >> >>=20 >> ## Case 2: >> - Initial Config A >> - edit-config request (no default operation): >> >> >> 10 // inherited replace >> >> >> - Resulting config on the server (all 'password-control' affected): >> >> >> 10 >> >> >> 132 >> true >> >> >> >> >> 8 >> true >> >> >>=20 >> ## Case 3: >> - Initial Config A >> - edit-config request (no default operation): >> >> // inherited replace >> 10 // inherited replace >> >> >> - Resulting config on the server (all 'system' affected) : >> >> >> 10 >> >> >> >> >> 8 >> true >> >> >>=20 >> ## Case 4: >> - Initial Config A >> - edit-config request (!! with default-operation replace !!): >> >> =20 >> 10 =20 >> =20 >> >> - Resulting config on the server (entire server datastore affected ?): >> >> >> 10 >> >> >> // no qos data ? >=20 > This is not correct; qos is unaffected. >=20 > ## Case 5: > - Initial Config A > - copy-config request > > =20 > 10 =20 > =20 > > - Resulting config on the server (entire server datastore affected !): > > > 10 > > > // no qos data ! >=20 >=20 >=20 > /martin >=20 >=20 >=20 >>=20 >> Regards, >> Jason >>=20 >> -----Original Message----- >> From: EXT Xiang Li [mailto:xiangli@seguesoft.com] >> Sent: Tuesday, May 03, 2016 11:21 >> To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund';=20 >> wivory@Brocade.com >> Cc: netconf@ietf.org >> Subject: RE: [Netconf] Clarification request for NETCONF edit-config=20 >> default-operation replace >>=20 >> Hi >>=20 >>> -----Original Message----- >>> ...=20 >>> In my first question I meant "using an ": >>>=20 >>> Is there no way to delete (or replace) the entire contents of the >> datastore >>> using an (and without using without=20 >>> having to explicitly list every single top level node ? >>=20 >> I don't think edit-config is designed to do that. >>=20 >> To delete a datastore, use , although can't=20 >> be deleted. >> To replace the *entire config*, use .=20 >>=20 >>> From the description of the default-operation 'replace' it seems it=20 >>> is >> possible >>> via the default operation: >>> replace: The configuration data in the parameter >>> completely replaces the configuration in the target >>> datastore. This is useful for loading previously saved >>> configuration data. >>=20 >>=20 >> No. The definition of "replace" as an operation says clearly: >>=20 >> Unlike a operation, which replaces the entire = target >> configuration, only the configuration actually present in >> the parameter is affected. >>=20 >> In other words, the only replaces the data nodes that exist=20 >> in the target and for nodes that are in in the=20 >> but not in the target, they are created. Other nodes=20 >> that exist in the device but are not present in the of the=20 >> are NOT affected in any way (this is the key difference=20 >> with , where they are removed because it operates on the >> *entire* datastore.) >>=20 >>> But can replace of the entire contents be done without replace as=20 >>> the >> default >>> operation ? >>=20 >> Not with the default "replace" operation, nor with the normal=20 >> "replace" >> operation. >> The default "replace" operation has no additional semantics compared=20 >> to The "operation" parameter >>=20 >>> Or delete of the entire contents ? The RFC doesn't seem to clear on=20 >>> whether we can use an operation on the node: >>> >>> >>=20 >>=20 >> The description of says: the target configuration is=20 >> not necessarily replaced, as with the message. =20 >> Instead, the target configuration is changed in accordance with the=20 >> source's data and requested operations. >>=20 >> In other words, the parameter in will not be=20 >> valid if you do not specify it (assuming no url capability) or make=20 >> it empty, as in your example. >>=20 >> config: A hierarchy of configuration data as defined by one of >> the device's data models. The contents MUST be placed in an >> appropriate namespace, to allow the device to detect the >> appropriate data model, and the contents MUST follow the >> constraints of that data model, as defined by its capability >> definition. >>=20 >>=20 >>> (c) and (d) have a delete operation on a leaf (in (c) is it >>> inherited) but >> are >>> providing a value for the leaf at the same time. What is the meaning=20 >>> of >> the >>> value ? That seems like an error to me. We should warn the client=20 >>> that they've done something unexpected (the client may have been=20 >>> intending to do something different than deleting that leaf). >>> I can see how that works when the leaf is a key leaf in a list. But=20 >>> it >> seems like >>> an error for just a plain leaf. >>=20 >>=20 >> No. I think the value is actually used by . For example, >> RFC6241 >> has this example: >>=20 >> Delete the configuration for an interface named "Ethernet0/0" from >> the running configuration: >>=20 >> > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> >> >> >> none >> >> >> >> Ethernet0/0 >> >> >> >> >> >>=20 >>=20 >> Without specifying value so that the device can find an exact matched=20 >> interface, this won't work. >>=20 >> In other words, my understanding is that if a value is given, and the=20 >> device >>=20 >> can't find a match then then the delete will fail with a=20 >> error. >>=20 >>> I'm also not convinced about (f) and (g). Wrt your analogy of a=20 >>> directory >> with >>> files: you can delete a container in NETCONF and that automatically >> deletes >>> any children, grandchildren and so on (the entire subtree). It=20 >>> seems >> strange >>> that there is no way to delete (or replace) the entire contents of a=20 >>> list >> or leaf- >>> list. >>=20 >> I don't necessarily disagree with you on this one. >>=20 >> I was simply suggesting that the protocol perhaps should have a=20 >> simple way to allow me to remove list entries. In particular I think=20 >> it would be useful it allows: >> 1) to delete a specific list entry by providing a list entry's=20 >> Instance ID ( all key nodes and corresponding values). >> 2) to delete all entries of a list by just providing all key nodes in=20 >> the . >>=20 >> Best, >> --Xiang >>=20 >>=20 >>=20 >>> Or perhaps I'm misinterpreting the description of the replace and=20 >>> delete operations in RFC6241 (the sentences "only the configuration=20 >>> actually present in the parameter is affected" and "if and=20 >>> only if the configuration data currently exists" are giving me some=20 >>> pause here). >> There >>> aren't many examples illustrating delete & replace in the RFC. >>>=20 >>> Regards, >>> Jason >>>=20 >>> -----Original Message----- >>> From: EXT Xiang Li [mailto:xiangli@seguesoft.com] >>> Sent: Friday, April 29, 2016 20:05 >>> To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund';=20 >>> wivory@Brocade.com >>> Cc: netconf@ietf.org >>> Subject: RE: [Netconf] Clarification request for NETCONF edit-config >> default- >>> operation replace >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Sterne,=20 >>> Jason (Nokia - CA) >>> Sent: Friday, April 29, 2016 2:12 PM >>> To: Martin Bjorklund ; wivory@Brocade.com >>> Cc: netconf@ietf.org >>> Subject: Re: [Netconf] Clarification request for NETCONF edit-config >> default- >>> operation replace >>>=20 >>> Is there no way to delete the entire contents of the datastore=20 >>> without >> having >>> to explicitly list every single top level node ? >>>=20 >>> e.g. >>> with no default operation (i.e. merge): >>> >>>=20 >>> Or >>> With default operation =3D delete: >>> >>>=20 >>> Similarly -> Is there no way to replace the entire contents of the >> datastore ? >>>=20 >>> [XL] I think< copy-config> or can do this. >>>=20 >>> About the cases below shouldn't (c) and (d) return an error ? They >> contain >>> data for an object that is being deleted. (e) seems like the=20 >>> correct way >> to do >>> it. >>>=20 >>> [XL] I think Martin's explanation is correct. My understanding is=20 >>> that if >> the >>> value does not match, then the would return an error since=20 >>> the no matching data node found (yes I view this as a content-match). >>> Or I might >> be >>> totally wrong here, i.e., the value does not matter in any way as=20 >>> Martin >> said? >>>=20 >>> (f) and (g) surprise me. If I can an entire leaf-list=20 >>> or >> list by just >>> specifying the tag for the leaf-list/list name, why doesn't delete=20 >>> get rid >> of the >>> entire leaf-list/list ? >>> (if you specify a specific list entry/member in a delete it is=20 >>> basically >> just a >>> content match node but otherwise you've selected the entire list no=20 >>> ?). >>>=20 >>> [XL] I also thought that I can delete a list entry by specifying all=20 >>> key >> nodes >>> and their values (i.e., list entry's instance ID). If no values of=20 >>> key >> nodes are >>> given, then the entire list entries matched and all of them should=20 >>> be >> deleted. >>> Although Martin's explanation also makes sense here, that is, you=20 >>> can't >> just >>> delete a key node yet if it is still used by non-key nodes. >>> Just like deleting a directory when the directory still contains=20 >>> files. >> But, in any >>> case, I would still like that I can delete a list entry by giving=20 >>> the >> list entry's IID >>> since we can unmistakably identify a list entry by given a list=20 >>> entry's >> IID (i.e. , >>> all key nodes and their corresponding values). I think such a=20 >>> delete operation would be useful, just like "rm -rf directory". >>>=20 >>> --Xiang >>> -----Original Message----- >>> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin=20 >>> Bjorklund >>> Sent: Friday, April 15, 2016 10:49 >>> To: wivory@Brocade.com >>> Cc: netconf@ietf.org >>> Subject: Re: [Netconf] Clarification request for NETCONF edit-config >> default- >>> operation replace >>>=20 >>> William Ivory wrote: >>>> OK - I think it might help if I gave some specific examples, with=20 >>>> my understanding of what would get deleted and you can tell me if=20 >>>> I'm correct or not. Apologies for length, but I'd like to avoid=20 >>>> any confusion by not spelling out my queries, and I'm struggling to=20 >>>> get a clear picture of how this all works with all the different=20 >>>> permutations! >>>>=20 >>>> Let's take a configuration like this: >>>>=20 >>>> >>>> leafValue >>>> leaflistValueOne >>>> leaflistValueTwo >>>> >>>> firstEntryKey >>>> firstEntryLeaf >>>> >>>> >>>> secondEntryKey >>>> secondEntryLeaf >>>> >>>> >>>>=20 >>>> --- >>>>=20 >>>> (a) topCont, default operation delete >>>>=20 >>>> With the default operation set to delete: >>>>=20 >>>> >>>> >>>> >>>>=20 >>>> =3D> topCont, and everything under it, would be deleted >>>=20 >>> Yes. >>>=20 >>>> (b) topCont, operation delete >>>>=20 >>>> With the default operation set to none: >>>>=20 >>>> >>>> >>>> >>>>=20 >>>> =3D> topCont, and everything under it, would be deleted >>>=20 >>> Yes. >>>=20 >>>> --- >>>>=20 >>>> (c) aLeaf delete, operation specified for topCont >>>>=20 >>>> With the default operation set to none: >>>>=20 >>>> >>>> >>>> leafValue >>>> >>>>=20 >>>> =3D> Will delete aLeaf node. If this leaves topCont empty, then=20 >>>> topCont would be removed. If topCont still contains other=20 >>>> elements, topCont would remain? >>>=20 >>> No. This deletes the topCont and everything below it. >>>=20 >>>> --- >>>>=20 >>>> (d) aLeaf delete, operation specified for aLeaf >>>>=20 >>>> With the default operation set to none: >>>>=20 >>>> >>>> >>>> leafValue >>>> >>>>=20 >>>> =3D> Will delete aLeaf node. If this leaves topCont empty, then=20 >>>> topCont would be removed unless it is a presence node. >>>=20 >>> Yes (s/would/may/) >>>=20 >>>> --- >>>>=20 >>>> (e) aLeaf delete, operation specified for aLeaf, but no value given >>>>=20 >>>> With the default operation set to none: >>>>=20 >>>> >>>> >>>> >>>>=20 >>>> =3D> Would this delete aLeaf, and, as per (d), conditionally=20 >>>> , or must the value of the leaf be specified? >>>=20 >>> Yes, this would delete aLeaf. The value doesn't matter. >>>=20 >>>> --- >>>>=20 >>>> (f) aLeafListEntry >>>>=20 >>>> Is there a way to delete all leaflist entries without specifying=20 >>>> them individually, eg: >>>>=20 >>>> >>>=20 >>> No >>>=20 >>>=20 >>>>=20 >>>> ... or, assuming there are other sibling nodes such that we can't=20 >>>> just delete topCont, must I specify each individual leaflist=20 >>>> element I wish to remove? >>>>=20 >>>> --- >>>>=20 >>>> (g) aListEntry >>>>=20 >>>> As per leaflist entries, is there a way to delete all entries=20 >>>> generically >>>=20 >>> No. >>>=20 >>>> , or must each be specified? >>>=20 >>> Yes. >>>=20 >>>> Separately, if I delete a non-key node inside a list entry, I=20 >>>> assume that just deletes that node. If I delete the list's key=20 >>>> node, then presumably that removes the complete entry, eg: >>>>=20 >>>> >>>> >>>> >>>> firstEntryKey >>>> >>>> >>>=20 >>> Yes >>>=20 >>>> Would the following achieve the same, ie removal of this list entry: >>>>=20 >>>> >>>> >>>> >>>> firstEntryKey >>>> >>>> >>>=20 >>> Hmm. I would say that this results in an error - deleting just the=20 >>> key of >> a list is >>> not possible. >>>=20 >>>=20 >>>=20 >>> /martin >>>=20 >>>=20 >>>=20 >>>>=20 >>>> --- >>>>=20 >>>> Thanks for bearing with me, >>>>=20 >>>> William >>>>=20 >>>> -----Original Message----- >>>> From: Martin Bjorklund [mailto:mbj@tail-f.com] >>>> Sent: 15 April 2016 13:44 >>>> To: William Ivory >>>> Cc: netconf@ietf.org >>>> Subject: Re: [Netconf] Clarification request for NETCONF=20 >>>> edit-config default-operation replace >>>>=20 >>>> William Ivory wrote: >>>>> Hi Martin, >>>>>=20 >>>>> Thanks - I think that the section on 'replace' under=20 >>>>> 'default-operation' could do with being clarified next time the=20 >>>>> RFC is updated then. >>>>>=20 >>>>> I'd appreciate some further clarification on what exactly ' only=20 >>>>> the configuration actually present in the parameter is=20 >>>>> affected' >>>>> means in practice. >>>>>=20 >>>>> First, the general pattern of examples which use=20 >>>>> 'operation=3D' is that this command is put in the 'parent' >>>>> element's tag, ie the tag which specifies 'delete' is *not* deleted. >>>>=20 >>>> No. For example: >>>>=20 >>>> >>>> 192.0.2.4 >>>> >>>>=20 >>>> will delete the "interface" node with the name "192.0.2.4" >>>>=20 >>>> It does NOT keep the "interface" node and just delete the "name" node. >>>>=20 >>>>> How then would you delete a top-level container? >>>>=20 >>>> >>>>=20 >>>>=20 >>>>=20 >>>> /martin >>>>=20 >>>>=20 >>>>> The examples have a >>>>> '' element but in cases where there are multiple top-level=20 >>>>> nodes, some of which are optional in the configuration (ie not=20 >>>>> presence containers), is it possible to delete these nodes? >>>>>=20 >>>>> Secondly, if I'm correct that the 'delete' operation would only=20 >>>>> affect nodes below the one with the delete operation, is it=20 >>>>> possible to construct an edit-config PDU that would delete all=20 >>>>> child nodes without having to explicitly specify each one? Or is=20 >>>>> the only way to achieve this either to explicitly specify all=20 >>>>> config to be removed, or to do a copy-config explicitly specifying=20 >>>>> all config that is not to be deleted. >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> William >>>>>=20 >>>>> -----Original Message----- >>>>> From: Martin Bjorklund [mailto:mbj@tail-f.com] >>>>> Sent: 14 April 2016 09:34 >>>>> To: William Ivory >>>>> Cc: netconf@ietf.org >>>>> Subject: Re: [Netconf] Clarification request for NETCONF=20 >>>>> edit-config default-operation replace >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> William Ivory wrote: >>>>>> Hi, >>>>>>=20 >>>>>> I'd appreciate clarification of how the NETCONF edit-config=20 >>>>>> command should work with default-operation set to 'replace'. >>>>>> For the most part, the edit-config section is clear that config=20 >>>>>> will only be replaced if explicitly overwritten (ie if you=20 >>>>>> provide replacement config for given nodes). However, the=20 >>>>>> section on default-operation is less clear: >>>>>>=20 >>>>>> The parameter is optional, but if >>> provided, >>>>>> it has one of the following values: >>>>>>=20 >>>>>> merge: The configuration data in the parameter is >>>>>> merged with the configuration at the corresponding=20 >>>>>> level >>> in >>>>>> the target datastore. This is the default behavior. >>>>>>=20 >>>>>> replace: The configuration data in the parameter >>>>>> completely replaces the configuration in the target >>>>>> datastore. This is useful for loading previously saved >>>>>> configuration data. >>>>>>=20 >>>>>> Specifically, while 'merge' states that merge happesn with=20 >>>>>> 'configuration as the corresponding level', 'replace' states that=20 >>>>>> is 'completely replaces' the configuration, suggesting that it=20 >>>>>> will remove ALL existing configuration regardless of what is=20 >>>>>> explicitly provided as the replacement. Is that correct, or is=20 >>>>>> 'replace' meant to have equivalent semantics to 'merge' ie it=20 >>>>>> will only replace configuration when an explicit replacement is=20 >>>>>> provided. In other words, if the latter case is correct, all it=20 >>>>>> does is remove the requirement to specify the operation in each >>> element of new config. >>>>>=20 >>>>> Yes the latter is correct. Note that the definition of "replace"=20 >>>>> as an operation says: >>>>>=20 >>>>> Unlike a >>>>> operation, which replaces the entire target >>>>> configuration, only the configuration actually present in >>>>> the parameter is affected. >>>>>=20 >>>>>=20 >>>>> /martin >>>=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 > _______________________________________________ > 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 Thu Jun 2 17:50:13 2016 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 14A6A12B059 for ; Thu, 2 Jun 2016 17:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 GcCfrSj1yQqB for ; Thu, 2 Jun 2016 17:50:03 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 412941200A0 for ; Thu, 2 Jun 2016 17:50:03 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 43EA4F5D4B7C9; Fri, 3 Jun 2016 00:49:58 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u530o05c005889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2016 00:50:00 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u530nxeN004676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jun 2016 00:49:59 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Thu, 2 Jun 2016 20:49:59 -0400 From: "Sterne, Jason (Nokia - CA)" To: Andy Bierman Thread-Topic: [Netconf] Clarification request for NETCONF edit-config default-operation replace Thread-Index: AQHRlyYGiZoT03uS4U+O6QebXc6r0J+hZVpggACXP4CABVTvsIAAYfwAgCqd10CAAPY+gIAACTeggAEC3oCAAU4PkA== Date: Fri, 3 Jun 2016 00:49:58 +0000 Message-ID: References: <01f401d1a54f$621dbad0$26593070$@seguesoft.com> <20160531.105003.567321207823725528.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CCA4838US70TWXCHMBA11z_" MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Clarification request for NETCONF edit-config default-operation replace X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 00:50:08 -0000 --_000_A125E53CE190A749957C19483DC79F9F5CCA4838US70TWXCHMBA11z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGh4LiAgSW4gY2FzZSBJIGFjY2lkZW50bHkgZ2F2ZSB0aGUgd3JvbmcgaW1wcmVzc2lvbiAtPiBJ IHdhc27igJl0IGFkdm9jYXRpbmcgdG8gY2hhbmdlIDxlZGl0LWNvbmZpZz4uICBKdXN0IHRyeWlu ZyB0byBjbGFyaWZ5IHRoZSBpbnRlbmRlZC9leHBlY3RlZCBiZWhhdmlvci4NCg0KSSB3YXNu4oCZ dCBldmVuIGNvbnNpZGVyaW5nIE5BQ00gZHVyaW5nIHRoaXMgd2hvbGUgZGlzY3Vzc2lvbi4gIEkg d291bGQgYXNzdW1lIE5BQ00gd291bGQgYWZmZWN0IHRoZSBiZWhhdmlvciBvZiA8ZWRpdC1jb25m aWc+IHJlcGxhY2Ugb3IgZGVsZXRlIChpLmUuIG5vZGVzIHRoYXQgdGhlIGNsaWVudCBjYW7igJl0 IGFjY2VzcyBhcmUgbm90IGRlbGV0ZWQsIGNhbiBlYXNpbHkgcmVzdWx0IGluIGludmFsaWQgY2Fu ZGlkYXRlIGNvbmZpZ3MpICwgYnV0IHRoYXQgcGVybWlzc2lvbiBzaG91bGQgYmUgY29udHJvbGxl ZCBmb3IgdGhlIDxjb3B5LWNvbmZpZz4gYXQgdGhlIFJQQyBsZXZlbCAoaS5lLiBhbGwgb3Igbm90 aGluZyBhdXRob3JpemF0aW9uIGZvciBhIGNsaWVudC91c2VyIHRvIHVzZSB0aGUgY29weS1jb25m aWcgUlBDKS4NCg0KSmFzb24NCg0KRnJvbTogQW5keSBCaWVybWFuIFttYWlsdG86YW5keUB5dW1h d29ya3MuY29tXQ0KU2VudDogVHVlc2RheSwgTWF5IDMxLCAyMDE2IDIwOjUwDQpUbzogU3Rlcm5l LCBKYXNvbiAoTm9raWEgLSBDQSkNCkNjOiBNYXJ0aW4gQmpvcmtsdW5kOyBuZXRjb25mQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIENsYXJpZmljYXRpb24gcmVxdWVzdCBmb3IgTkVU Q09ORiBlZGl0LWNvbmZpZyBkZWZhdWx0LW9wZXJhdGlvbiByZXBsYWNlDQoNCkhpLA0KDQpJIGRv bid0IHRoaW5rIDxlZGl0LWNvbmZpZz4gbmVlZHMgdG8gYmUgY2hhbmdlZCB0byBwcm92aWRlIHRo ZQ0Kc2FtZSByZXBsYWNlIHNlbWFudGljcyBhcyA8Y29weS1jb25maWc+LiAgY29weS1jb25maWcg aXMNCmZvciBjb21wbGV0ZSBjb25maWd1cmF0aW9ucy4NCg0KVGhlcmUgaXMgYW4gdW53cml0dGVu IGFzc3VtcHRpb24gdGhhdCB0aGUgY29weS1jb25maWcgY29udGVudHMgYXJlDQpub3QgcHJ1bmVk IGF0IGFsbCBieSBhY2Nlc3MgY29udHJvbC4gQSBtaXNzaW5nIG5vZGUgd2lsbCBiZSBpbnRlcnBy ZXRlZCBhcyBhIGRlbGV0ZSBhdHRlbXB0Lg0KVGhpcyBpcyBub3QgYXQgYWxsIGRlc2lyYWJsZSBp ZiB0aGUgY2xpZW50IGlzIG5vdCBhdXRob3JpemVkIGFuZCBpcyBub3QgZXZlbiBhd2FyZQ0Kb2Yg dGhlc2UgImhpZGRlbiIgbm9kZXMuDQoNCg0KQW5keQ0KDQoNCk9uIFR1ZSwgTWF5IDMxLCAyMDE2 IGF0IDY6MzYgQU0sIFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EpIDxqYXNvbi5zdGVybmVAbm9r aWEuY29tPG1haWx0bzpqYXNvbi5zdGVybmVAbm9raWEuY29tPj4gd3JvdGU6DQpUaHggTWFydGlu LiAgWW91ciBleHBsYW5hdGlvbiB0aGF0IGEgZGVmYXVsdCByZXBsYWNlIG9wZXJhdGlvbiBjYW4g b25seSBhcHBseSB0byBlbGVtZW50cyB0aGF0IGFyZSBpbiB0aGUgcmVxdWVzdCBoZWxwcyBhIGxv dC4NCg0KU28gdGhlcmUgcmVhbGx5IGlzIG5vIHN1Y2ggdGhpbmcgYXMgYW4gZWRpdC1jb25maWcg J3JlcGxhY2UnIG9wZXJhdGlvbiB0aGF0IG9wZXJhdGVzICJhdCB0aGUgcm9vdCIuIFRoYXQgY2Fu IG9ubHkgYmUgZG9uZSB3aXRoIGEgc3BlY2lhbCBkZWRpY2F0ZWQgUlBDIChlLmcuIGNvcHktY29u ZmlnIGFzIHlvdSBzaG93IGluIENhc2UgNSkuDQoNClNvIG15IGNhc2UgNCBpcyBlcXVpdmFsZW50 IHRvIHRoaXM6DQoNCj4gICAgICA8c3lzdGVtIG9wZXJhdGlvbj0ncmVwbGFjZSc+DQo+ICAgICAg ICA8cGFzc3dvcmQtY29udHJvbCBvcGVyYXRpb249J3JlcGxhY2UnPg0KPiAgICAgICAgICA8bWlu LWxlbmd0aCBvcGVyYXRpb249J3JlcGxhY2UnPjEwPC9taW4tbGVuZ3RoPg0KPiAgICAgICAgPC9w YXNzd29yZC1jb250cm9sPg0KPiAgICAgIDwvc3lzdGVtPg0KDQp3aGljaCB3aWxsIHJlcGxhY2Ug dGhlIGVudGlyZSBjb250ZW50cyBvZiB0aGUgL3N5c3RlbSBzdWJ0cmVlIChidXQgbm90IGFueXRo aW5nIGVsc2UpLg0KDQpPbiBhIHJlbGF0ZWQgbm90ZSAtPiBpcyB0aGUgZmluYWwgcmVzdWx0IChp LmUuIGRhdGFzdG9yZSBjb250ZW50cykgb2YgYSByZXBsYWNlIG9wZXJhdGlvbiBhbHdheXMgZXhh Y3RseSB0aGUgc2FtZSBhcyBhIHJlbW92ZSArIG1lcmdlIHdpdGggdGhlIHNhbWUgZGF0YSBhdCB0 aGUgc2FtZSBsb2NhdGlvbiA/ICBJIGNhbid0IHRoaW5rIG9mIGFuIGV4YW1wbGUgd2hlcmUgdGhh dCBpc24ndCB0cnVlIGJ1dCBJIG1heSBiZSBtaXNzaW5nIHNvbWUgY29ybmVyIGNhc2UuDQoNCkZv ciB0aGUgY2FuZGlkYXRlIGRhdGFzdG9yZSBpdCBzZWVtcyB0aGF0ICdyZXBsYWNlJyBpcyBzaW1w bHkgYSBzaG9ydGhhbmQgd2F5IHRvIGRvIHJlbW92ZSttZXJnZSBpbiBhIHNpbmdsZSBlZGl0LWNv bmZpZy4gIEZvciBhIHJ1bm5pbmcgZGF0YXN0b3JlICh3cml0ZWFibGUtcnVubmluZykgdGhlIGlt cGFjdHMgd291bGQgYmUgcXVpdGUgZGlmZmVyZW50IHRob3VnaCBzaW5jZSB0aGUgZWRpdC1jb25m aWcgJ3JlbW92ZScgd291bGQgYmUgYXBwbGllZCBpbW1lZGlhdGVseSB3aGljaCB3b3VsZCBjbGVh ciBvdXQgYWxsIGNvbmZpZyBmb3IgYSBzaG9ydCBwZXJpb2QgYmVmb3JlIHRoZSAnbWVyZ2UnIHRo ZW4gZ2V0cyBwcm9jZXNzZWQuDQoNClJlZ2FyZHMsDQpKYXNvbg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogTWFydGluIEJqb3JrbHVuZCBbbWFpbHRvOm1iakB0YWlsLWYuY29t PG1haWx0bzptYmpAdGFpbC1mLmNvbT5dDQpTZW50OiBUdWVzZGF5LCBNYXkgMzEsIDIwMTYgNDo1 MA0KVG86IFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EpDQpDYzogeGlhbmdsaUBzZWd1ZXNvZnQu Y29tPG1haWx0bzp4aWFuZ2xpQHNlZ3Vlc29mdC5jb20+OyB3aXZvcnlAQnJvY2FkZS5jb208bWFp bHRvOndpdm9yeUBCcm9jYWRlLmNvbT47IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIENsYXJpZmljYXRpb24gcmVxdWVzdCBm b3IgTkVUQ09ORiBlZGl0LWNvbmZpZyBkZWZhdWx0LW9wZXJhdGlvbiByZXBsYWNlDQoNCiJTdGVy bmUsIEphc29uIChOb2tpYSAtIENBKSIgPGphc29uLnN0ZXJuZUBub2tpYS5jb208bWFpbHRvOmph c29uLnN0ZXJuZUBub2tpYS5jb20+PiB3cm90ZToNCj4gSGkgZ3V5cywNCj4NCj4gSSB0aGluayB0 aGVyZSBpcyBzb21lIGNvbmZsaWN0aW5nIGluZm9ybWF0aW9uIHdydCBkZWZhdWx0LW9wZXJhdGlv bg0KPiByZXBsYWNlIGhlcmUuDQoNCkkgYWdyZWUgaXQgaXMgbm90IGNsZWFyLg0KDQo+IFRoZSBm b2xsb3dpbmcgc25pcHBldCBvZiBSRkMgNjI0MSBjbGVhcmx5IHN0YXRlcyAoSU1PKSB0aGF0IHRo ZSBlbnRpcmUNCj4gY29uZmlnIGlzIGFmZmVjdGVkL3JlcGxhY2VkLiAgVGhlIGZpcnN0IHNlbnRl bmNlIHNheXMgaXQuDQoNCkkgZG9uJ3QgdGhpbmsgdGhpcyBzdGF0ZW1lbnQgY2xlYXJseSBzYXlz IHRoYXQgdGhlIGVudGlyZSBkYXRhc3RvcmUgaXMgcmVwbGFjZWQuICBJdCB1c2VzIHRoZSB0ZXJt ICJjb21wbGV0ZWx5IHJlcGxhY2UiLiAgSSBkb24ndCBrbm93IGhvdyB0aGF0IGlzIGRpZmZlcmVu dCBmcm9tICJyZXBsYWNlIi4gIElNTywgInJlcGxhY2UiIGltcGxpZXMgImNvbXBsZXRlbHkiLi4u DQoNCj4gVGhlbiB0aGUgc2Vjb25kIHNlbnRlbmNlIGdpdmVzIHlldCBhbm90aGVyIGluZGljYXRp b24gdGhhdCBpdCByZXBsYWNlcw0KPiB0aGUgZW50aXJlIGNvbmZpZzoNCg0KTm90IG5lY2Vzc2Fy aWx5Lg0KDQo+ID4gICAgICAgICByZXBsYWNlOiAgVGhlIGNvbmZpZ3VyYXRpb24gZGF0YSBpbiB0 aGUgPGNvbmZpZz4gcGFyYW1ldGVyDQo+ID4gICAgICAgICAgICBjb21wbGV0ZWx5IHJlcGxhY2Vz IHRoZSBjb25maWd1cmF0aW9uIGluIHRoZSB0YXJnZXQNCj4gPiAgICAgICAgICAgIGRhdGFzdG9y ZS4gIFRoaXMgaXMgdXNlZnVsIGZvciBsb2FkaW5nIHByZXZpb3VzbHkgc2F2ZWQNCj4gPiAgICAg ICAgICAgIGNvbmZpZ3VyYXRpb24gZGF0YS4NCj4NCj4NCj4gSSBhbHNvIGZvdW5kIGFuIG9sZGVy IGRpc2N1c3Npb24gb24gdGhpcyBvbiB0aGUgbWFpbGluZyBsaXN0IHRoYXQNCj4gaW5kaWNhdGVz IHRoYXQgYSBkZWZhdWx0IGFjdGlvbiBvZiByZXBsYWNlIGlzIGludGVuZGVkIHRvIGJlIHVzZWQg Zm9yDQo+IHRoZSBlbnRpcmUgZGF0YXN0b3JlLiAgRnJvbQ0KPiBodHRwczovL21haWxhcmNoaXZl LmlldGYub3JnL2FyY2gvbXNnL25ldGNvbmYvczRLT0p4SWdiRHpxQVhTLXVGX2pGaS1pUXNVOg0K Pg0KPg0KPiA+ICAxKQ0KPiA+ICAgICRiYWNrdXAgPSBnZXQtY29uZmlnKHNvdXJjZT1ydW5uaW5n KQ0KPiA+ICAyKQ0KPiA+ICAgIGNvcHktY29uZmlnKHNvdXJjZT0kYmFja3VwLCB0YXJnZXQ9cnVu bmluZykgIE9SDQo+ID4gICAgZWRpdC1jb25maWcoc291cmNlPSRiYWNrdXAsIHRhcmdldD1ydW5u aW5nLA0KPiA+ICAgIGRlZmF1bHQtb3BlcmF0aW9uPXJlcGxhY2UpIg0KPg0KPg0KPiA8ZWRpdC1j b25maWc+IG9wZXJhdGlvbnMgYXJlIGluaGVyaXRlZC4gVGhlIGRlZmF1bHQtb3BlcmF0aW9uIGFw cGxpZXMNCj4gdG8gYWxsIHRvcCBsZXZlbCBvYmplY3RzLiAgQnV0IEknbSBub3QgY2VydGFpbiB3 aGV0aGVyIGl0IGFwcGxpZXMgdG8NCj4gYWxsIHRvcCBsZXZlbCBvYmplY3RzIGluIHRoZSBkYXRh IG1vZGVsIG9uIHRoZSBzZXJ2ZXIgb3IganVzdCBhbGwgdGhlDQo+IHRvcCBsZXZlbCBvYmplY3Rz IHRoYXQgYXJlIGluY2x1ZGVkIGluIHRoZSA8ZWRpdC1jb25maWc+IHJlcXVlc3QuDQoNClRoZSBs YXR0ZXIuICBJdCBpcyBqdXN0IGEgZGVmYXVsdCB2YWx1ZSBmb3IgdGhlICJvcGVyYXRpb24iIGF0 dHJpYnV0ZTsgaS5lLiwgaW5zdGVhZCBvZiB1c2luZyAiZGVmYXVsdC1vcGVyYXRpb24iLCB5b3Ug Y291bGQgZXhwbGljaXRseSBzZXQgdGhlICJvcGVyYXRpb24iIGF0dHJpYnV0ZSAtIGFuZCB5b3Ug Y2FuIG9ubHkgZG8gdGhhdCBmb3IgdGhlIGVsZW1lbnRzIGluIHRoZSByZXF1ZXN0IChvYnZpb3Vs c3kpLg0KDQo+IEZyb20gdGhlIGRlc2NyaXB0aW9ucyBhYm92ZSBpdCBzZWVtcyBpdCBtdXN0IGFw cGx5IHRvIGFsbCB0b3AgbGV2ZWwNCj4gb2JqZWN0cyBpbiB0aGUgc2VydmVyIGJ1dCB0aGF0IHNl ZW1zIHRvIGNvbmZsaWN0IHdpdGg6DQo+DQo+ID4gICJvbmx5IHRoZSBjb25maWd1cmF0aW9uIGFj dHVhbGx5IHByZXNlbnQgaW4gdGhlIDxjb25maWc+IHBhcmFtZXRlcg0KPiA+IGlzICBhZmZlY3Rl ZCINCj4NCj4gSGVyZSBpcyBhIHNldCBvZiBleGFtcGxlcyB0aGF0IG1heSBoZWxwIGNsYXJpZnkg dGhpbmdzLiBUaGUgZmlyc3QgMw0KPiBjYXNlcyBhcmUgYW4gaW5jcmVtZW50YWwgbGVhZC1pbiB0 byBjYXNlIDQgd2hpY2ggaXMgdGhlIGxlYXN0IGNsZWFyDQo+IGZvciBtZS4NCj4NCj4gIyMgSW5p dGlhbCBzZXJ2ZXIgQ29uZmlnIEEgKHVzZWQgaW4gYWxsIHRoZSBjYXNlcyBiZWxvdyk6DQo+ICAg PHN5c3RlbT4NCj4gICAgIDxwYXNzd29yZC1jb250cm9sPg0KPiAgICAgICA8bWluLWxlbmd0aD4x MjwvbWluLWxlbmd0aD4NCj4gICAgICAgPHJlcXVpcmUtY2Fwcz50cnVlPHJlcXVpcmUtY2Fwcz4N Cj4gICAgIDwvcGFzc3dvcmQtY29udHJvbD4NCj4gICAgIDxjb25zb2xlPg0KPiAgICAgICA8d2lk dGg+MTMyPC93aWR0aD4NCj4gICAgICAgPGVuYWJsZWQ+dHJ1ZTwvZW5hYmxlZD4NCj4gICAgIDwv Y29uc29sZT4NCj4gICA8L3N5c3RlbT4NCj4gICA8cW9zPg0KPiAgICAgPGluZ3Jlc3M+DQo+ICAg ICAgIDxjbGFzcy1saW1pdD44PC9jbGFzcy1saW1pdD4NCj4gICAgICAgPHN1Yi1jbGFzc2VzPnRy dWU8L3N1Yi1jbGFzc2VzPg0KPiAgICAgPC9pbmdyZXNzPg0KPiAgIDwvcW9zPg0KPg0KPiAjIyBD YXNlIDE6DQo+IC0gSW5pdGlhbCBDb25maWcgQQ0KPiAtIGVkaXQtY29uZmlnIHJlcXVlc3QgKG5v IGRlZmF1bHQgb3BlcmF0aW9uKToNCj4gICAgICA8c3lzdGVtPg0KPiAgICAgICAgPHBhc3N3b3Jk LWNvbnRyb2w+DQo+ICAgICAgICAgIDxtaW4tbGVuZ3RoIG9wZXJhdGlvbj0ncmVwbGFjZSc+MTA8 L21pbi1sZW5ndGg+DQo+ICAgICAgICA8L3Bhc3N3b3JkLWNvbnRyb2w+DQo+ICAgICAgPC9zeXN0 ZW0+DQo+IC0gUmVzdWx0aW5nIGNvbmZpZyBvbiB0aGUgc2VydmVyIChvbmx5ICdtaW4tbGVuZ3Ro JyBhZmZlY3RlZCk6DQo+ICAgICAgPHN5c3RlbT4NCj4gICAgICAgIDxwYXNzd29yZC1jb250cm9s Pg0KPiAgICAgICAgICA8bWluLWxlbmd0aD4xMDwvbWluLWxlbmd0aD4NCj4gICAgICAgICAgPHJl cXVpcmUtY2Fwcz50cnVlPHJlcXVpcmUtY2Fwcz4NCj4gICAgICAgIDwvcGFzc3dvcmQtY29udHJv bD4NCj4gICAgICAgIDxjb25zb2xlPg0KPiAgICAgICAgICA8d2lkdGg+MTMyPC93aWR0aD4NCj4g ICAgICAgICAgPGVuYWJsZWQ+dHJ1ZTwvZW5hYmxlZD4NCj4gICAgICAgIDwvY29uc29sZT4NCj4g ICAgICA8L3N5c3RlbT4NCj4gICAgICA8cW9zPg0KPiAgICAgICAgPGluZ3Jlc3M+DQo+ICAgICAg ICAgIDxjbGFzcy1saW1pdD44PC9jbGFzcy1saW1pdD4NCj4gICAgICAgICAgPHN1Yi1jbGFzc2Vz PnRydWU8L3N1Yi1jbGFzc2VzPg0KPiAgICAgICAgPC9pbmdyZXNzPg0KPiAgICAgIDwvcW9zPg0K Pg0KPiAjIyBDYXNlIDI6DQo+IC0gSW5pdGlhbCBDb25maWcgQQ0KPiAtIGVkaXQtY29uZmlnIHJl cXVlc3QgKG5vIGRlZmF1bHQgb3BlcmF0aW9uKToNCj4gICAgICA8c3lzdGVtPg0KPiAgICAgICAg PHBhc3N3b3JkLWNvbnRyb2wgb3BlcmF0aW9uPSdyZXBsYWNlJz4NCj4gICAgICAgICAgPG1pbi1s ZW5ndGg+MTA8L21pbi1sZW5ndGg+ICAgLy8gaW5oZXJpdGVkIHJlcGxhY2UNCj4gICAgICAgIDwv cGFzc3dvcmQtY29udHJvbD4NCj4gICAgICA8L3N5c3RlbT4NCj4gLSBSZXN1bHRpbmcgY29uZmln IG9uIHRoZSBzZXJ2ZXIgKGFsbCAncGFzc3dvcmQtY29udHJvbCcgYWZmZWN0ZWQpOg0KPiAgICAg IDxzeXN0ZW0+DQo+ICAgICAgICA8cGFzc3dvcmQtY29udHJvbD4NCj4gICAgICAgICAgPG1pbi1s ZW5ndGg+MTA8L21pbi1sZW5ndGg+DQo+ICAgICAgICA8L3Bhc3N3b3JkLWNvbnRyb2w+DQo+ICAg ICAgICA8Y29uc29sZT4NCj4gICAgICAgICAgPHdpZHRoPjEzMjwvd2lkdGg+DQo+ICAgICAgICAg IDxlbmFibGVkPnRydWU8L2VuYWJsZWQ+DQo+ICAgICAgICA8L2NvbnNvbGU+DQo+ICAgICAgPC9z eXN0ZW0+DQo+ICAgICAgPHFvcz4NCj4gICAgICAgIDxpbmdyZXNzPg0KPiAgICAgICAgICA8Y2xh c3MtbGltaXQ+ODwvY2xhc3MtbGltaXQ+DQo+ICAgICAgICAgIDxzdWItY2xhc3Nlcz50cnVlPC9z dWItY2xhc3Nlcz4NCj4gICAgICAgIDwvaW5ncmVzcz4NCj4gICAgICA8L3Fvcz4NCj4NCj4gIyMg Q2FzZSAzOg0KPiAtIEluaXRpYWwgQ29uZmlnIEENCj4gLSBlZGl0LWNvbmZpZyByZXF1ZXN0IChu byBkZWZhdWx0IG9wZXJhdGlvbik6DQo+ICAgICAgPHN5c3RlbSBvcGVyYXRpb249J3JlcGxhY2Un Pg0KPiAgICAgICAgPHBhc3N3b3JkLWNvbnRyb2w+ICAgICAgICAgICAgIC8vIGluaGVyaXRlZCBy ZXBsYWNlDQo+ICAgICAgICAgIDxtaW4tbGVuZ3RoPjEwPC9taW4tbGVuZ3RoPiAgLy8gaW5oZXJp dGVkIHJlcGxhY2UNCj4gICAgICAgIDwvcGFzc3dvcmQtY29udHJvbD4NCj4gICAgICA8L3N5c3Rl bT4NCj4gLSBSZXN1bHRpbmcgY29uZmlnIG9uIHRoZSBzZXJ2ZXIgKGFsbCAnc3lzdGVtJyBhZmZl Y3RlZCkgOg0KPiAgICAgIDxzeXN0ZW0+DQo+ICAgICAgICA8cGFzc3dvcmQtY29udHJvbD4NCj4g ICAgICAgICAgPG1pbi1sZW5ndGg+MTA8L21pbi1sZW5ndGg+DQo+ICAgICAgICA8L3Bhc3N3b3Jk LWNvbnRyb2w+DQo+ICAgICAgPC9zeXN0ZW0+DQo+ICAgICAgPHFvcz4NCj4gICAgICAgIDxpbmdy ZXNzPg0KPiAgICAgICAgICA8Y2xhc3MtbGltaXQ+ODwvY2xhc3MtbGltaXQ+DQo+ICAgICAgICAg IDxzdWItY2xhc3Nlcz50cnVlPC9zdWItY2xhc3Nlcz4NCj4gICAgICAgIDwvaW5ncmVzcz4NCj4g ICAgICA8L3Fvcz4NCj4NCj4gIyMgQ2FzZSA0Og0KPiAtIEluaXRpYWwgQ29uZmlnIEENCj4gLSBl ZGl0LWNvbmZpZyByZXF1ZXN0ICghISB3aXRoIGRlZmF1bHQtb3BlcmF0aW9uIHJlcGxhY2UgISEp Og0KPiAgICAgIDxzeXN0ZW0+DQo+ICAgICAgICA8cGFzc3dvcmQtY29udHJvbD4NCj4gICAgICAg ICAgPG1pbi1sZW5ndGg+MTA8L21pbi1sZW5ndGg+DQo+ICAgICAgICA8L3Bhc3N3b3JkLWNvbnRy b2w+DQo+ICAgICAgPC9zeXN0ZW0+DQo+IC0gUmVzdWx0aW5nIGNvbmZpZyBvbiB0aGUgc2VydmVy IChlbnRpcmUgc2VydmVyIGRhdGFzdG9yZSBhZmZlY3RlZCA/KToNCj4gICAgICA8c3lzdGVtPg0K PiAgICAgICAgPHBhc3N3b3JkLWNvbnRyb2w+DQo+ICAgICAgICAgIDxtaW4tbGVuZ3RoPjEwPC9t aW4tbGVuZ3RoPg0KPiAgICAgICAgPC9wYXNzd29yZC1jb250cm9sPg0KPiAgICAgIDwvc3lzdGVt Pg0KPiAgICAgLy8gbm8gcW9zIGRhdGEgPw0KDQpUaGlzIGlzIG5vdCBjb3JyZWN0OyBxb3MgaXMg dW5hZmZlY3RlZC4NCg0KIyMgQ2FzZSA1Og0KLSBJbml0aWFsIENvbmZpZyBBDQotIGNvcHktY29u ZmlnIHJlcXVlc3QNCiAgICA8c3lzdGVtPg0KICAgICAgIDxwYXNzd29yZC1jb250cm9sPg0KICAg ICAgICAgPG1pbi1sZW5ndGg+MTA8L21pbi1sZW5ndGg+DQogICAgICA8L3Bhc3N3b3JkLWNvbnRy b2w+DQogICAgIDwvc3lzdGVtPg0KLSBSZXN1bHRpbmcgY29uZmlnIG9uIHRoZSBzZXJ2ZXIgKGVu dGlyZSBzZXJ2ZXIgZGF0YXN0b3JlIGFmZmVjdGVkICEpOg0KICAgICA8c3lzdGVtPg0KICAgICAg IDxwYXNzd29yZC1jb250cm9sPg0KICAgICAgICA8bWluLWxlbmd0aD4xMDwvbWluLWxlbmd0aD4N CiAgICAgIDwvcGFzc3dvcmQtY29udHJvbD4NCiAgICAgPC9zeXN0ZW0+DQogICAgLy8gbm8gcW9z IGRhdGEgIQ0KDQoNCg0KL21hcnRpbg0KDQoNCg0KPg0KPiBSZWdhcmRzLA0KPiBKYXNvbg0KPg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBFWFQgWGlhbmcgTGkgW21haWx0 bzp4aWFuZ2xpQHNlZ3Vlc29mdC5jb208bWFpbHRvOnhpYW5nbGlAc2VndWVzb2Z0LmNvbT5dDQo+ IFNlbnQ6IFR1ZXNkYXksIE1heSAwMywgMjAxNiAxMToyMQ0KPiBUbzogU3Rlcm5lLCBKYXNvbiAo Tm9raWEgLSBDQSk7ICdNYXJ0aW4gQmpvcmtsdW5kJzsgd2l2b3J5QEJyb2NhZGUuY29tPG1haWx0 bzp3aXZvcnlAQnJvY2FkZS5jb20+DQo+IENjOiBuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRj b25mQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSRTogW05ldGNvbmZdIENsYXJpZmljYXRpb24gcmVx dWVzdCBmb3IgTkVUQ09ORiBlZGl0LWNvbmZpZw0KPiBkZWZhdWx0LW9wZXJhdGlvbiByZXBsYWNl DQo+DQo+IEhpDQo+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPi4uLg0KPiA+ IEluIG15IGZpcnN0IHF1ZXN0aW9uIEkgbWVhbnQgInVzaW5nIGFuIDxlZGl0LWNvbmZpZz4iOg0K PiA+DQo+ID4gSXMgdGhlcmUgbm8gd2F5IHRvIGRlbGV0ZSAob3IgcmVwbGFjZSkgdGhlIGVudGly ZSBjb250ZW50cyBvZiB0aGUNCj4gZGF0YXN0b3JlDQo+ID4gdXNpbmcgYW4gPGVkaXQtY29uZmln PiAoYW5kIHdpdGhvdXQgdXNpbmcgPGNvcHktY29uZmlnPiB3aXRob3V0DQo+ID4gaGF2aW5nIHRv IGV4cGxpY2l0bHkgbGlzdCBldmVyeSBzaW5nbGUgdG9wIGxldmVsIG5vZGUgPw0KPiA+DQo+DQo+ IEkgZG9uJ3QgdGhpbmsgZWRpdC1jb25maWcgaXMgZGVzaWduZWQgdG8gZG8gdGhhdC4NCj4NCj4g VG8gZGVsZXRlIGEgZGF0YXN0b3JlLCB1c2UgPGRlbGV0ZS1jb25maWc+LCBhbHRob3VnaCA8cnVu bmluZz4gY2FuJ3QNCj4gYmUgZGVsZXRlZC4NCj4gVG8gcmVwbGFjZSB0aGUgKmVudGlyZSBjb25m aWcqLCB1c2UgPGNvcHktY29uZmlnPi4NCj4NCj4gPiBGcm9tIHRoZSBkZXNjcmlwdGlvbiBvZiB0 aGUgZGVmYXVsdC1vcGVyYXRpb24gJ3JlcGxhY2UnIGl0IHNlZW1zIGl0DQo+ID4gaXMNCj4gcG9z c2libGUNCj4gPiB2aWEgdGhlIGRlZmF1bHQgb3BlcmF0aW9uOg0KPiA+ICAgICAgICAgIHJlcGxh Y2U6ICBUaGUgY29uZmlndXJhdGlvbiBkYXRhIGluIHRoZSA8Y29uZmlnPiBwYXJhbWV0ZXINCj4g PiAgICAgICAgICAgICBjb21wbGV0ZWx5IHJlcGxhY2VzIHRoZSBjb25maWd1cmF0aW9uIGluIHRo ZSB0YXJnZXQNCj4gPiAgICAgICAgICAgICBkYXRhc3RvcmUuICBUaGlzIGlzIHVzZWZ1bCBmb3Ig bG9hZGluZyBwcmV2aW91c2x5IHNhdmVkDQo+ID4gICAgICAgICAgICAgY29uZmlndXJhdGlvbiBk YXRhLg0KPg0KPg0KPiBOby4gVGhlIGRlZmluaXRpb24gb2YgInJlcGxhY2UiIGFzIGFuIG9wZXJh dGlvbiBzYXlzIGNsZWFybHk6DQo+DQo+ICAgICAgICAgICAgIFVubGlrZSBhICA8Y29weS1jb25m aWc+IG9wZXJhdGlvbiwgd2hpY2ggcmVwbGFjZXMgdGhlIGVudGlyZSB0YXJnZXQNCj4gICAgICAg ICAgICAgY29uZmlndXJhdGlvbiwgb25seSB0aGUgY29uZmlndXJhdGlvbiBhY3R1YWxseSBwcmVz ZW50IGluDQo+ICAgICAgICAgICAgIHRoZSA8Y29uZmlnPiBwYXJhbWV0ZXIgaXMgYWZmZWN0ZWQu DQo+DQo+IEluIG90aGVyIHdvcmRzLCB0aGUgPHJlcGxhY2U+IG9ubHkgcmVwbGFjZXMgdGhlIGRh dGEgbm9kZXMgdGhhdCBleGlzdA0KPiBpbiB0aGUgdGFyZ2V0IGFuZCBmb3Igbm9kZXMgdGhhdCBh cmUgaW4gPGNvbmZpZz4gaW4gdGhlDQo+IDxlZGl0LWNvbmZpZz5idXQgbm90IGluIHRoZSB0YXJn ZXQsIHRoZXkgYXJlIGNyZWF0ZWQuIE90aGVyIG5vZGVzIHRoYXQNCj4gZXhpc3QgaW4gdGhlIGRl dmljZSBidXQgYXJlIG5vdCBwcmVzZW50IGluIHRoZSA8Y29uZmlnPiBvZiB0aGUNCj4gPGVkaXQt Y29uZmlnPiBhcmUgTk9UIGFmZmVjdGVkIGluIGFueSB3YXkgKHRoaXMgaXMgdGhlIGtleSBkaWZm ZXJlbmNlDQo+IHdpdGggPGNvcHktY29uZmlnPiwgd2hlcmUgdGhleSBhcmUgcmVtb3ZlZCBiZWNh dXNlIGl0IG9wZXJhdGVzIG9uIHRoZQ0KPiAqZW50aXJlKiBkYXRhc3RvcmUuKQ0KPg0KPiA+IEJ1 dCBjYW4gcmVwbGFjZSBvZiB0aGUgZW50aXJlIGNvbnRlbnRzIGJlIGRvbmUgd2l0aG91dCByZXBs YWNlIGFzDQo+ID4gdGhlDQo+IGRlZmF1bHQNCj4gPiBvcGVyYXRpb24gPw0KPg0KPiBOb3Qgd2l0 aCB0aGUgZGVmYXVsdCAicmVwbGFjZSIgb3BlcmF0aW9uLCBub3Igd2l0aCB0aGUgbm9ybWFsDQo+ ICJyZXBsYWNlIg0KPiBvcGVyYXRpb24uDQo+IFRoZSBkZWZhdWx0ICJyZXBsYWNlIiBvcGVyYXRp b24gaGFzIG5vIGFkZGl0aW9uYWwgc2VtYW50aWNzIGNvbXBhcmVkDQo+IHRvIFRoZSAib3BlcmF0 aW9uIiBwYXJhbWV0ZXINCj4NCj4gPiBPciBkZWxldGUgb2YgdGhlIGVudGlyZSBjb250ZW50cyA/ ICBUaGUgUkZDIGRvZXNuJ3Qgc2VlbSB0byBjbGVhciBvbg0KPiA+IHdoZXRoZXIgd2UgY2FuIHVz ZSBhbiBvcGVyYXRpb24gb24gdGhlIDxjb25maWc+IG5vZGU6DQo+ID4gPGNvbmZpZyBvcGVyYXRp b249ImRlbGV0ZSIvPg0KPiA+IDxjb25maWcgb3BlcmF0aW9uPSJyZXBsYWNlIi8+DQo+DQo+DQo+ IFRoZSBkZXNjcmlwdGlvbiBvZiA8ZWRpdC1jb25maWc+IHNheXM6IHRoZSB0YXJnZXQgY29uZmln dXJhdGlvbiBpcyBub3QNCj4gbmVjZXNzYXJpbHkgcmVwbGFjZWQsIGFzIHdpdGggdGhlIDxjb3B5 LWNvbmZpZz4gbWVzc2FnZS4gIEluc3RlYWQsIHRoZQ0KPiB0YXJnZXQgY29uZmlndXJhdGlvbiBp cyBjaGFuZ2VkIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgc291cmNlJ3MgZGF0YQ0KPiBhbmQgcmVx dWVzdGVkIG9wZXJhdGlvbnMuDQo+DQo+IEluIG90aGVyIHdvcmRzLCB0aGUgPGNvbmZpZz4gcGFy YW1ldGVyIGluIDxlZGl0LWNvbmZpZz4gd2lsbCBub3QgYmUNCj4gdmFsaWQgaWYgeW91IGRvIG5v dCBzcGVjaWZ5IGl0IChhc3N1bWluZyBubyB1cmwgY2FwYWJpbGl0eSkgb3IgbWFrZSBpdA0KPiBl bXB0eSwgYXMgaW4geW91ciBleGFtcGxlLg0KPg0KPiBjb25maWc6ICBBIGhpZXJhcmNoeSBvZiBj b25maWd1cmF0aW9uIGRhdGEgYXMgZGVmaW5lZCBieSBvbmUgb2YNCj4gICAgICAgICAgdGhlIGRl dmljZSdzIGRhdGEgbW9kZWxzLiAgVGhlIGNvbnRlbnRzIE1VU1QgYmUgcGxhY2VkIGluIGFuDQo+ ICAgICAgICAgIGFwcHJvcHJpYXRlIG5hbWVzcGFjZSwgdG8gYWxsb3cgdGhlIGRldmljZSB0byBk ZXRlY3QgdGhlDQo+ICAgICAgICAgIGFwcHJvcHJpYXRlIGRhdGEgbW9kZWwsIGFuZCB0aGUgY29u dGVudHMgTVVTVCBmb2xsb3cgdGhlDQo+ICAgICAgICAgIGNvbnN0cmFpbnRzIG9mIHRoYXQgZGF0 YSBtb2RlbCwgYXMgZGVmaW5lZCBieSBpdHMgY2FwYWJpbGl0eQ0KPiAgICAgICAgICBkZWZpbml0 aW9uLg0KPg0KPg0KPiA+IChjKSBhbmQgKGQpIGhhdmUgYSBkZWxldGUgb3BlcmF0aW9uIG9uIGEg bGVhZiAoaW4gKGMpIGlzIGl0DQo+ID4gaW5oZXJpdGVkKSBidXQNCj4gYXJlDQo+ID4gcHJvdmlk aW5nIGEgdmFsdWUgZm9yIHRoZSBsZWFmIGF0IHRoZSBzYW1lIHRpbWUuIFdoYXQgaXMgdGhlIG1l YW5pbmcNCj4gPiBvZg0KPiB0aGUNCj4gPiB2YWx1ZSA/IFRoYXQgc2VlbXMgbGlrZSBhbiBlcnJv ciB0byBtZS4gIFdlIHNob3VsZCB3YXJuIHRoZSBjbGllbnQNCj4gPiB0aGF0IHRoZXkndmUgZG9u ZSBzb21ldGhpbmcgdW5leHBlY3RlZCAodGhlIGNsaWVudCBtYXkgaGF2ZSBiZWVuDQo+ID4gaW50 ZW5kaW5nIHRvIGRvIHNvbWV0aGluZyBkaWZmZXJlbnQgdGhhbiBkZWxldGluZyB0aGF0IGxlYWYp Lg0KPiA+IEkgY2FuIHNlZSBob3cgdGhhdCB3b3JrcyB3aGVuIHRoZSBsZWFmIGlzIGEga2V5IGxl YWYgaW4gYSBsaXN0LiAgQnV0DQo+ID4gaXQNCj4gc2VlbXMgbGlrZQ0KPiA+IGFuIGVycm9yIGZv ciBqdXN0IGEgcGxhaW4gbGVhZi4NCj4NCj4NCj4gTm8uIEkgdGhpbmsgdGhlIHZhbHVlIGlzIGFj dHVhbGx5IHVzZWQgYnkgPGVkaXQtY29uZmlnPi4gRm9yIGV4YW1wbGUsDQo+IFJGQzYyNDENCj4g aGFzIHRoaXMgZXhhbXBsZToNCj4NCj4gRGVsZXRlIHRoZSBjb25maWd1cmF0aW9uIGZvciBhbiBp bnRlcmZhY2UgbmFtZWQgIkV0aGVybmV0MC8wIiBmcm9tDQo+ICAgIHRoZSBydW5uaW5nIGNvbmZp Z3VyYXRpb246DQo+DQo+ICAgICAgPHJwYyBtZXNzYWdlLWlkPSIxMDEiDQo+ICAgICAgICAgICB4 bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIj4NCj4gICAgICAg IDxlZGl0LWNvbmZpZz4NCj4gICAgICAgICAgPHRhcmdldD4NCj4gICAgICAgICAgICA8cnVubmlu Zy8+DQo+ICAgICAgICAgIDwvdGFyZ2V0Pg0KPiAgICAgICAgICA8ZGVmYXVsdC1vcGVyYXRpb24+ bm9uZTwvZGVmYXVsdC1vcGVyYXRpb24+DQo+ICAgICAgICAgIDxjb25maWcgeG1sbnM6eGM9InVy bjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQo+ICAgICAgICAgICAgPHRv cCB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS8xLjIvY29uZmlnIj4NCj4gICAgICAg ICAgICAgIDxpbnRlcmZhY2UgeGM6b3BlcmF0aW9uPSJkZWxldGUiPg0KPiAgICAgICAgICAgICAg ICA8bmFtZT5FdGhlcm5ldDAvMDwvbmFtZT4NCj4gICAgICAgICAgICAgIDwvaW50ZXJmYWNlPg0K PiAgICAgICAgICAgIDwvdG9wPg0KPiAgICAgICAgICA8L2NvbmZpZz4NCj4gICAgICAgIDwvZWRp dC1jb25maWc+DQo+ICAgICAgPC9ycGM+DQo+DQo+DQo+IFdpdGhvdXQgc3BlY2lmeWluZyB2YWx1 ZSBzbyB0aGF0IHRoZSBkZXZpY2UgY2FuIGZpbmQgYW4gZXhhY3QgbWF0Y2hlZA0KPiBpbnRlcmZh Y2UsIHRoaXMgd29uJ3Qgd29yay4NCj4NCj4gSW4gb3RoZXIgd29yZHMsIG15IHVuZGVyc3RhbmRp bmcgaXMgdGhhdCBpZiBhIHZhbHVlIGlzIGdpdmVuLCBhbmQgdGhlDQo+IGRldmljZQ0KPg0KPiBj YW4ndCBmaW5kIGEgbWF0Y2ggdGhlbiB0aGVuIHRoZSBkZWxldGUgd2lsbCBmYWlsIHdpdGggYQ0K PiA8ZGF0YS1taXNzaW5nPiBlcnJvci4NCj4NCj4gPiBJJ20gYWxzbyBub3QgY29udmluY2VkIGFi b3V0IChmKSBhbmQgKGcpLiAgV3J0IHlvdXIgYW5hbG9neSBvZiBhDQo+ID4gZGlyZWN0b3J5DQo+ IHdpdGgNCj4gPiBmaWxlczogeW91IGNhbiBkZWxldGUgYSBjb250YWluZXIgaW4gTkVUQ09ORiBh bmQgdGhhdCBhdXRvbWF0aWNhbGx5DQo+IGRlbGV0ZXMNCj4gPiBhbnkgY2hpbGRyZW4sIGdyYW5k Y2hpbGRyZW4gYW5kIHNvIG9uICh0aGUgZW50aXJlIHN1YnRyZWUpLiAgSXQNCj4gPiBzZWVtcw0K PiBzdHJhbmdlDQo+ID4gdGhhdCB0aGVyZSBpcyBubyB3YXkgdG8gZGVsZXRlIChvciByZXBsYWNl KSB0aGUgZW50aXJlIGNvbnRlbnRzIG9mIGENCj4gPiBsaXN0DQo+IG9yIGxlYWYtDQo+ID4gbGlz dC4NCj4NCj4gSSBkb24ndCBuZWNlc3NhcmlseSBkaXNhZ3JlZSB3aXRoIHlvdSBvbiB0aGlzIG9u ZS4NCj4NCj4gSSB3YXMgc2ltcGx5IHN1Z2dlc3RpbmcgdGhhdCB0aGUgcHJvdG9jb2wgcGVyaGFw cyBzaG91bGQgaGF2ZSBhIHNpbXBsZQ0KPiB3YXkgdG8gYWxsb3cgbWUgdG8gcmVtb3ZlIGxpc3Qg ZW50cmllcy4gSW4gcGFydGljdWxhciBJIHRoaW5rIGl0IHdvdWxkDQo+IGJlIHVzZWZ1bCBpdCBh bGxvd3M6DQo+IDEpIHRvIGRlbGV0ZSBhIHNwZWNpZmljIGxpc3QgZW50cnkgYnkgcHJvdmlkaW5n IGEgbGlzdCBlbnRyeSdzDQo+IEluc3RhbmNlIElEICggYWxsIGtleSBub2RlcyBhbmQgY29ycmVz cG9uZGluZyB2YWx1ZXMpLg0KPiAyKSB0byBkZWxldGUgYWxsIGVudHJpZXMgb2YgYSBsaXN0IGJ5 IGp1c3QgcHJvdmlkaW5nIGFsbCBrZXkgbm9kZXMgaW4NCj4gdGhlIDxjb25maWc+Lg0KPg0KPiBC ZXN0LA0KPiAtLVhpYW5nDQo+DQo+DQo+DQo+ID4gT3IgcGVyaGFwcyBJJ20gbWlzaW50ZXJwcmV0 aW5nIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgcmVwbGFjZSBhbmQNCj4gPiBkZWxldGUgb3BlcmF0 aW9ucyBpbiBSRkM2MjQxICh0aGUgc2VudGVuY2VzICJvbmx5IHRoZSBjb25maWd1cmF0aW9uDQo+ ID4gYWN0dWFsbHkgcHJlc2VudCBpbiB0aGUgPGNvbmZpZz4gcGFyYW1ldGVyIGlzIGFmZmVjdGVk IiBhbmQgImlmIGFuZA0KPiA+IG9ubHkgaWYgdGhlIGNvbmZpZ3VyYXRpb24gZGF0YSBjdXJyZW50 bHkgZXhpc3RzIiBhcmUgZ2l2aW5nIG1lIHNvbWUNCj4gPiBwYXVzZSBoZXJlKS4NCj4gVGhlcmUN Cj4gPiBhcmVuJ3QgbWFueSBleGFtcGxlcyBpbGx1c3RyYXRpbmcgZGVsZXRlICYgcmVwbGFjZSBp biB0aGUgUkZDLg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPiBKYXNvbg0KPiA+DQo+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBFWFQgWGlhbmcgTGkgW21haWx0bzp4aWFu Z2xpQHNlZ3Vlc29mdC5jb208bWFpbHRvOnhpYW5nbGlAc2VndWVzb2Z0LmNvbT5dDQo+ID4gU2Vu dDogRnJpZGF5LCBBcHJpbCAyOSwgMjAxNiAyMDowNQ0KPiA+IFRvOiBTdGVybmUsIEphc29uIChO b2tpYSAtIENBKTsgJ01hcnRpbiBCam9ya2x1bmQnOw0KPiA+IHdpdm9yeUBCcm9jYWRlLmNvbTxt YWlsdG86d2l2b3J5QEJyb2NhZGUuY29tPg0KPiA+IENjOiBuZXRjb25mQGlldGYub3JnPG1haWx0 bzpuZXRjb25mQGlldGYub3JnPg0KPiA+IFN1YmplY3Q6IFJFOiBbTmV0Y29uZl0gQ2xhcmlmaWNh dGlvbiByZXF1ZXN0IGZvciBORVRDT05GIGVkaXQtY29uZmlnDQo+IGRlZmF1bHQtDQo+ID4gb3Bl cmF0aW9uIHJlcGxhY2UNCj4gPg0KPiA+DQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+IEZyb206IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBTdGVybmUsDQo+ ID4gSmFzb24gKE5va2lhIC0gQ0EpDQo+ID4gU2VudDogRnJpZGF5LCBBcHJpbCAyOSwgMjAxNiAy OjEyIFBNDQo+ID4gVG86IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPG1haWx0bzpt YmpAdGFpbC1mLmNvbT4+OyB3aXZvcnlAQnJvY2FkZS5jb208bWFpbHRvOndpdm9yeUBCcm9jYWRl LmNvbT4NCj4gPiBDYzogbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4N Cj4gPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIENsYXJpZmljYXRpb24gcmVxdWVzdCBmb3IgTkVU Q09ORiBlZGl0LWNvbmZpZw0KPiBkZWZhdWx0LQ0KPiA+IG9wZXJhdGlvbiByZXBsYWNlDQo+ID4N Cj4gPiBJcyB0aGVyZSBubyB3YXkgdG8gZGVsZXRlIHRoZSBlbnRpcmUgY29udGVudHMgb2YgdGhl IGRhdGFzdG9yZQ0KPiA+IHdpdGhvdXQNCj4gaGF2aW5nDQo+ID4gdG8gZXhwbGljaXRseSBsaXN0 IGV2ZXJ5IHNpbmdsZSB0b3AgbGV2ZWwgbm9kZSA/DQo+ID4NCj4gPiBlLmcuDQo+ID4gd2l0aCBu byBkZWZhdWx0IG9wZXJhdGlvbiAoaS5lLiBtZXJnZSk6DQo+ID4gPGNvbmZpZyBvcGVyYXRpb249 ImRlbGV0ZSIvPg0KPiA+DQo+ID4gT3INCj4gPiBXaXRoIGRlZmF1bHQgb3BlcmF0aW9uID0gZGVs ZXRlOg0KPiA+IDxjb25maWcvPg0KPiA+DQo+ID4gU2ltaWxhcmx5IC0+IElzIHRoZXJlIG5vIHdh eSB0byByZXBsYWNlIHRoZSBlbnRpcmUgY29udGVudHMgb2YgdGhlDQo+IGRhdGFzdG9yZSA/DQo+ ID4NCj4gPiBbWExdIEkgdGhpbms8IGNvcHktY29uZmlnPiBvciA8ZGVsZXRlLWNvbmZpZz4gY2Fu IGRvIHRoaXMuDQo+ID4NCj4gPiBBYm91dCB0aGUgY2FzZXMgYmVsb3cgc2hvdWxkbid0IChjKSBh bmQgKGQpIHJldHVybiBhbiBlcnJvciA/ICBUaGV5DQo+IGNvbnRhaW4NCj4gPiBkYXRhIGZvciBh biBvYmplY3QgdGhhdCBpcyBiZWluZyBkZWxldGVkLiAgKGUpIHNlZW1zIGxpa2UgdGhlDQo+ID4g Y29ycmVjdCB3YXkNCj4gdG8gZG8NCj4gPiBpdC4NCj4gPg0KPiA+IFtYTF0gSSB0aGluayBNYXJ0 aW4ncyBleHBsYW5hdGlvbiBpcyBjb3JyZWN0LiBNeSB1bmRlcnN0YW5kaW5nIGlzDQo+ID4gdGhh dCBpZg0KPiB0aGUNCj4gPiB2YWx1ZSBkb2VzIG5vdCBtYXRjaCwgdGhlbiB0aGUgPGRlbGV0ZT4g d291bGQgcmV0dXJuIGFuIGVycm9yIHNpbmNlDQo+ID4gdGhlIG5vIG1hdGNoaW5nIGRhdGEgbm9k ZSBmb3VuZCAoeWVzIEkgdmlldyB0aGlzIGFzIGEgY29udGVudC1tYXRjaCkuDQo+ID4gT3IgSSBt aWdodA0KPiBiZQ0KPiA+IHRvdGFsbHkgd3JvbmcgaGVyZSwgaS5lLiwgdGhlIHZhbHVlIGRvZXMg bm90IG1hdHRlciBpbiBhbnkgd2F5IGFzDQo+ID4gTWFydGluDQo+IHNhaWQ/DQo+ID4NCj4gPiAo ZikgYW5kIChnKSBzdXJwcmlzZSBtZS4gIElmIEkgY2FuIDxnZXQtY29uZmlnPiBhbiBlbnRpcmUg bGVhZi1saXN0DQo+ID4gb3INCj4gbGlzdCBieSBqdXN0DQo+ID4gc3BlY2lmeWluZyB0aGUgdGFn IGZvciB0aGUgbGVhZi1saXN0L2xpc3QgbmFtZSwgd2h5IGRvZXNuJ3QgZGVsZXRlDQo+ID4gZ2V0 IHJpZA0KPiBvZiB0aGUNCj4gPiBlbnRpcmUgbGVhZi1saXN0L2xpc3QgPw0KPiA+IChpZiB5b3Ug c3BlY2lmeSBhIHNwZWNpZmljIGxpc3QgZW50cnkvbWVtYmVyIGluIGEgZGVsZXRlIGl0IGlzDQo+ ID4gYmFzaWNhbGx5DQo+IGp1c3QgYQ0KPiA+IGNvbnRlbnQgbWF0Y2ggbm9kZSBidXQgb3RoZXJ3 aXNlIHlvdSd2ZSBzZWxlY3RlZCB0aGUgZW50aXJlIGxpc3Qgbm8NCj4gPiA/KS4NCj4gPg0KPiA+ IFtYTF0gSSBhbHNvIHRob3VnaHQgdGhhdCBJIGNhbiBkZWxldGUgYSBsaXN0IGVudHJ5IGJ5IHNw ZWNpZnlpbmcNCj4gPiBhbGwga2V5DQo+IG5vZGVzDQo+ID4gYW5kIHRoZWlyIHZhbHVlcyAoaS5l LiwgbGlzdCBlbnRyeSdzIGluc3RhbmNlIElEKS4gSWYgbm8gdmFsdWVzIG9mDQo+ID4ga2V5DQo+ IG5vZGVzIGFyZQ0KPiA+IGdpdmVuLCB0aGVuIHRoZSBlbnRpcmUgbGlzdCBlbnRyaWVzIG1hdGNo ZWQgYW5kIGFsbCBvZiB0aGVtIHNob3VsZA0KPiA+IGJlDQo+IGRlbGV0ZWQuDQo+ID4gQWx0aG91 Z2ggTWFydGluJ3MgZXhwbGFuYXRpb24gYWxzbyBtYWtlcyBzZW5zZSBoZXJlLCB0aGF0IGlzLCB5 b3UNCj4gPiBjYW4ndA0KPiBqdXN0DQo+ID4gZGVsZXRlIGEga2V5IG5vZGUgeWV0IGlmIGl0IGlz IHN0aWxsIHVzZWQgYnkgbm9uLWtleSBub2Rlcy4NCj4gPiBKdXN0IGxpa2UgZGVsZXRpbmcgYSBk aXJlY3Rvcnkgd2hlbiB0aGUgZGlyZWN0b3J5IHN0aWxsIGNvbnRhaW5zDQo+ID4gZmlsZXMuDQo+ IEJ1dCwgaW4gYW55DQo+ID4gY2FzZSwgIEkgd291bGQgc3RpbGwgbGlrZSB0aGF0IEkgY2FuIGRl bGV0ZSBhIGxpc3QgZW50cnkgYnkgZ2l2aW5nDQo+ID4gdGhlDQo+IGxpc3QgZW50cnkncyBJSUQN Cj4gPiBzaW5jZSB3ZSBjYW4gdW5taXN0YWthYmx5IGlkZW50aWZ5ICBhIGxpc3QgZW50cnkgYnkg Z2l2ZW4gYSBsaXN0DQo+ID4gZW50cnkncw0KPiBJSUQgKGkuZS4gLA0KPiA+IGFsbCBrZXkgbm9k ZXMgYW5kIHRoZWlyIGNvcnJlc3BvbmRpbmcgdmFsdWVzKS4gIEkgdGhpbmsgc3VjaCBhDQo+ID4g ZGVsZXRlIG9wZXJhdGlvbiB3b3VsZCBiZSB1c2VmdWwsICBqdXN0IGxpa2UgInJtIC1yZiBkaXJl Y3RvcnkiLg0KPiA+DQo+ID4gLS1YaWFuZw0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4gRnJvbTogTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIE1hcnRpbg0KPiA+IEJq b3JrbHVuZA0KPiA+IFNlbnQ6IEZyaWRheSwgQXByaWwgMTUsIDIwMTYgMTA6NDkNCj4gPiBUbzog d2l2b3J5QEJyb2NhZGUuY29tPG1haWx0bzp3aXZvcnlAQnJvY2FkZS5jb20+DQo+ID4gQ2M6IG5l dGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogUmU6 IFtOZXRjb25mXSBDbGFyaWZpY2F0aW9uIHJlcXVlc3QgZm9yIE5FVENPTkYgZWRpdC1jb25maWcN Cj4gZGVmYXVsdC0NCj4gPiBvcGVyYXRpb24gcmVwbGFjZQ0KPiA+DQo+ID4gV2lsbGlhbSBJdm9y eSA8d2l2b3J5QEJyb2NhZGUuY29tPG1haWx0bzp3aXZvcnlAQnJvY2FkZS5jb20+PiB3cm90ZToN Cj4gPiA+IE9LIC0gSSB0aGluayBpdCBtaWdodCBoZWxwIGlmIEkgZ2F2ZSBzb21lIHNwZWNpZmlj IGV4YW1wbGVzLCB3aXRoDQo+ID4gPiBteSB1bmRlcnN0YW5kaW5nIG9mIHdoYXQgd291bGQgZ2V0 IGRlbGV0ZWQgYW5kIHlvdSBjYW4gdGVsbCBtZSBpZg0KPiA+ID4gSSdtIGNvcnJlY3Qgb3Igbm90 LiAgQXBvbG9naWVzIGZvciBsZW5ndGgsIGJ1dCBJJ2QgbGlrZSB0byBhdm9pZA0KPiA+ID4gYW55 IGNvbmZ1c2lvbiBieSBub3Qgc3BlbGxpbmcgb3V0IG15IHF1ZXJpZXMsIGFuZCBJJ20gc3RydWdn bGluZw0KPiA+ID4gdG8gZ2V0IGEgY2xlYXIgcGljdHVyZSBvZiBob3cgdGhpcyBhbGwgd29ya3Mg d2l0aCBhbGwgdGhlDQo+ID4gPiBkaWZmZXJlbnQgcGVybXV0YXRpb25zIQ0KPiA+ID4NCj4gPiA+ IExldCdzIHRha2UgYSBjb25maWd1cmF0aW9uIGxpa2UgdGhpczoNCj4gPiA+DQo+ID4gPiA8dG9w Q29udD4NCj4gPiA+ICAgICA8YUxlYWY+bGVhZlZhbHVlPC9hTGVhZj4NCj4gPiA+ICAgICA8YUxl YWZMaXN0RW50cnk+bGVhZmxpc3RWYWx1ZU9uZTwvYUxlYWZMaXN0RW50cnk+DQo+ID4gPiAgICAg PGFMZWFmTGlzdEVudHJ5PmxlYWZsaXN0VmFsdWVUd288L2FMZWFmTGlzdEVudHJ5Pg0KPiA+ID4g ICAgIDxhTGlzdEVudHJ5Pg0KPiA+ID4gICAgICAgICA8bGlzdEtleT5maXJzdEVudHJ5S2V5PC9s aXN0S2V5Pg0KPiA+ID4gICAgICAgICA8bGlzdExlYWY+Zmlyc3RFbnRyeUxlYWY8L2xpc3RMZWFm Pg0KPiA+ID4gICAgIDwvYUxpc3RFbnRyeT4NCj4gPiA+ICAgICA8YUxpc3RFbnRyeT4NCj4gPiA+ ICAgICAgICAgPGxpc3RLZXk+c2Vjb25kRW50cnlLZXk8L2xpc3RLZXk+DQo+ID4gPiAgICAgICAg IDxsaXN0TGVhZj5zZWNvbmRFbnRyeUxlYWY8L2xpc3RMZWFmPg0KPiA+ID4gICAgIDwvYUxpc3RF bnRyeT4NCj4gPiA+IDwvdG9wQ29udD4NCj4gPiA+DQo+ID4gPiAtLS0NCj4gPiA+DQo+ID4gPiAo YSkgdG9wQ29udCwgZGVmYXVsdCBvcGVyYXRpb24gZGVsZXRlDQo+ID4gPg0KPiA+ID4gV2l0aCB0 aGUgZGVmYXVsdCBvcGVyYXRpb24gc2V0IHRvIGRlbGV0ZToNCj4gPiA+DQo+ID4gPiA8Y29uZmln Pg0KPiA+ID4gICAgIDx0b3BDb250Pg0KPiA+ID4gPC9jb25maWc+DQo+ID4gPg0KPiA+ID4gPT4g dG9wQ29udCwgYW5kIGV2ZXJ5dGhpbmcgdW5kZXIgaXQsIHdvdWxkIGJlIGRlbGV0ZWQNCj4gPg0K PiA+IFllcy4NCj4gPg0KPiA+ID4gKGIpIHRvcENvbnQsIG9wZXJhdGlvbiBkZWxldGUNCj4gPiA+ DQo+ID4gPiBXaXRoIHRoZSBkZWZhdWx0IG9wZXJhdGlvbiBzZXQgdG8gbm9uZToNCj4gPiA+DQo+ ID4gPiA8Y29uZmlnPg0KPiA+ID4gICAgIDx0b3BDb250IHhjOm9wZXJhdGlvbj1kZWxldGU+DQo+ ID4gPiA8L2NvbmZpZz4NCj4gPiA+DQo+ID4gPiA9PiB0b3BDb250LCBhbmQgZXZlcnl0aGluZyB1 bmRlciBpdCwgd291bGQgYmUgZGVsZXRlZA0KPiA+ID4NCj4gPg0KPiA+IFllcy4NCj4gPg0KPiA+ ID4gLS0tDQo+ID4gPg0KPiA+ID4gKGMpIGFMZWFmIGRlbGV0ZSwgb3BlcmF0aW9uIHNwZWNpZmll ZCBmb3IgdG9wQ29udA0KPiA+ID4NCj4gPiA+IFdpdGggdGhlIGRlZmF1bHQgb3BlcmF0aW9uIHNl dCB0byBub25lOg0KPiA+ID4NCj4gPiA+IDxjb25maWc+DQo+ID4gPiAgICAgPHRvcENvbnQgeGM6 b3BlcmF0aW9uPWRlbGV0ZT4NCj4gPiA+ICAgICAgICAgPGFMZWFmPmxlYWZWYWx1ZTwvYUxlYWY+ DQo+ID4gPiA8L2NvbmZpZz4NCj4gPiA+DQo+ID4gPiA9PiBXaWxsIGRlbGV0ZSBhTGVhZiBub2Rl LiAgSWYgdGhpcyBsZWF2ZXMgdG9wQ29udCBlbXB0eSwgdGhlbg0KPiA+ID4gdG9wQ29udCB3b3Vs ZCBiZSByZW1vdmVkLiAgSWYgdG9wQ29udCBzdGlsbCBjb250YWlucyBvdGhlcg0KPiA+ID4gZWxl bWVudHMsIHRvcENvbnQgd291bGQgcmVtYWluPw0KPiA+DQo+ID4gTm8uICBUaGlzIGRlbGV0ZXMg dGhlIHRvcENvbnQgYW5kIGV2ZXJ5dGhpbmcgYmVsb3cgaXQuDQo+ID4NCj4gPiA+IC0tLQ0KPiA+ ID4NCj4gPiA+IChkKSBhTGVhZiBkZWxldGUsIG9wZXJhdGlvbiBzcGVjaWZpZWQgZm9yIGFMZWFm DQo+ID4gPg0KPiA+ID4gV2l0aCB0aGUgZGVmYXVsdCBvcGVyYXRpb24gc2V0IHRvIG5vbmU6DQo+ ID4gPg0KPiA+ID4gPGNvbmZpZz4NCj4gPiA+ICAgICA8dG9wQ29udD4NCj4gPiA+ICAgICAgICAg PGFMZWFmIHhjOm9wZXJhdGlvbj1kZWxldGU+bGVhZlZhbHVlPC9hTGVhZj4NCj4gPiA+IDwvY29u ZmlnPg0KPiA+ID4NCj4gPiA+ID0+IFdpbGwgZGVsZXRlIGFMZWFmIG5vZGUuICBJZiB0aGlzIGxl YXZlcyB0b3BDb250IGVtcHR5LCB0aGVuDQo+ID4gPiB0b3BDb250IHdvdWxkIGJlIHJlbW92ZWQg dW5sZXNzIGl0IGlzIGEgcHJlc2VuY2Ugbm9kZS4NCj4gPg0KPiA+IFllcyAgKHMvd291bGQvbWF5 LykNCj4gPg0KPiA+ID4gLS0tDQo+ID4gPg0KPiA+ID4gKGUpIGFMZWFmIGRlbGV0ZSwgb3BlcmF0 aW9uIHNwZWNpZmllZCBmb3IgYUxlYWYsIGJ1dCBubyB2YWx1ZQ0KPiA+ID4gZ2l2ZW4NCj4gPiA+ DQo+ID4gPiBXaXRoIHRoZSBkZWZhdWx0IG9wZXJhdGlvbiBzZXQgdG8gbm9uZToNCj4gPiA+DQo+ ID4gPiA8Y29uZmlnPg0KPiA+ID4gICAgIDx0b3BDb250Pg0KPiA+ID4gICAgICAgICA8YUxlYWYg eGM6b3BlcmF0aW9uPWRlbGV0ZS8+IDwvY29uZmlnPg0KPiA+ID4NCj4gPiA+ID0+IFdvdWxkIHRo aXMgZGVsZXRlIGFMZWFmLCBhbmQsIGFzIHBlciAoZCksIGNvbmRpdGlvbmFsbHkNCj4gPiA+IDx0 b3BDb250Piwgb3IgbXVzdCB0aGUgdmFsdWUgb2YgdGhlIGxlYWYgYmUgc3BlY2lmaWVkPw0KPiA+ ID4NCj4gPg0KPiA+IFllcywgdGhpcyB3b3VsZCBkZWxldGUgYUxlYWYuICBUaGUgdmFsdWUgZG9l c24ndCBtYXR0ZXIuDQo+ID4NCj4gPiA+IC0tLQ0KPiA+ID4NCj4gPiA+IChmKSBhTGVhZkxpc3RF bnRyeQ0KPiA+ID4NCj4gPiA+IElzIHRoZXJlIGEgd2F5IHRvIGRlbGV0ZSBhbGwgbGVhZmxpc3Qg ZW50cmllcyB3aXRob3V0IHNwZWNpZnlpbmcNCj4gPiA+IHRoZW0gaW5kaXZpZHVhbGx5LCBlZzoN Cj4gPiA+DQo+ID4gPiA8YUxlYWZMaXN0RW50cnkgeGM6b3BlcmF0aW9uPWRlbGV0ZT4NCj4gPg0K PiA+IE5vDQo+ID4NCj4gPg0KPiA+ID4NCj4gPiA+IC4uLiBvciwgYXNzdW1pbmcgdGhlcmUgYXJl IG90aGVyIHNpYmxpbmcgbm9kZXMgc3VjaCB0aGF0IHdlIGNhbid0DQo+ID4gPiBqdXN0IGRlbGV0 ZSB0b3BDb250LCBtdXN0IEkgc3BlY2lmeSBlYWNoIGluZGl2aWR1YWwgbGVhZmxpc3QNCj4gPiA+ IGVsZW1lbnQgSSB3aXNoIHRvIHJlbW92ZT8NCj4gPiA+DQo+ID4gPiAtLS0NCj4gPiA+DQo+ID4g PiAoZykgYUxpc3RFbnRyeQ0KPiA+ID4NCj4gPiA+IEFzIHBlciBsZWFmbGlzdCBlbnRyaWVzLCBp cyB0aGVyZSBhIHdheSB0byBkZWxldGUgYWxsIGVudHJpZXMNCj4gPiA+IGdlbmVyaWNhbGx5DQo+ ID4NCj4gPiBOby4NCj4gPg0KPiA+ID4sIG9yIG11c3QgZWFjaCBiZSBzcGVjaWZpZWQ/DQo+ID4N Cj4gPiBZZXMuDQo+ID4NCj4gPiA+IFNlcGFyYXRlbHksIGlmIEkgZGVsZXRlIGEgbm9uLWtleSBu b2RlIGluc2lkZSBhIGxpc3QgZW50cnksIEkNCj4gPiA+IGFzc3VtZSB0aGF0IGp1c3QgZGVsZXRl cyB0aGF0IG5vZGUuICBJZiBJIGRlbGV0ZSB0aGUgbGlzdCdzIGtleQ0KPiA+ID4gbm9kZSwgdGhl biBwcmVzdW1hYmx5IHRoYXQgcmVtb3ZlcyB0aGUgY29tcGxldGUgZW50cnksIGVnOg0KPiA+ID4N Cj4gPiA+IDxjb25maWc+DQo+ID4gPiAgICAgPHRvcENvbnQ+DQo+ID4gPiAgICAgICAgIDxhTGlz dEVudHJ5IHhjOm9wZXJhdGlvbj1kZWxldGU+DQo+ID4gPiAgICAgICAgICAgICA8bGlzdEtleT5m aXJzdEVudHJ5S2V5PC9saXN0S2V5Pg0KPiA+ID4gICAgICAgICA8L2FMaXN0RW50cnk+DQo+ID4g PiA8L2NvbmZpZz4NCj4gPg0KPiA+IFllcw0KPiA+DQo+ID4gPiBXb3VsZCB0aGUgZm9sbG93aW5n IGFjaGlldmUgdGhlIHNhbWUsIGllIHJlbW92YWwgb2YgdGhpcyBsaXN0IGVudHJ5Og0KPiA+ID4N Cj4gPiA+IDxjb25maWc+DQo+ID4gPiAgICAgPHRvcENvbnQ+DQo+ID4gPiAgICAgICAgIDxhTGlz dEVudHJ5ID4NCj4gPiA+ICAgICAgICAgICAgIDxsaXN0S2V5IHhjOm9wZXJhdGlvbj1kZWxldGUg PmZpcnN0RW50cnlLZXk8L2xpc3RLZXk+DQo+ID4gPiAgICAgICAgIDwvYUxpc3RFbnRyeT4NCj4g PiA+IDwvY29uZmlnPg0KPiA+DQo+ID4gSG1tLiAgSSB3b3VsZCBzYXkgdGhhdCB0aGlzIHJlc3Vs dHMgaW4gYW4gZXJyb3IgLSBkZWxldGluZyBqdXN0IHRoZQ0KPiA+IGtleSBvZg0KPiBhIGxpc3Qg aXMNCj4gPiBub3QgcG9zc2libGUuDQo+ID4NCj4gPg0KPiA+DQo+ID4gL21hcnRpbg0KPiA+DQo+ ID4NCj4gPg0KPiA+ID4NCj4gPiA+IC0tLQ0KPiA+ID4NCj4gPiA+IFRoYW5rcyAgZm9yIGJlYXJp bmcgd2l0aCBtZSwNCj4gPiA+DQo+ID4gPiBXaWxsaWFtDQo+ID4gPg0KPiA+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IE1hcnRpbiBCam9ya2x1bmQgW21haWx0bzpt YmpAdGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwtZi5jb20+XQ0KPiA+ID4gU2VudDogMTUgQXBy aWwgMjAxNiAxMzo0NA0KPiA+ID4gVG86IFdpbGxpYW0gSXZvcnkgPHdpdm9yeUBCcm9jYWRlLmNv bTxtYWlsdG86d2l2b3J5QEJyb2NhZGUuY29tPj4NCj4gPiA+IENjOiBuZXRjb25mQGlldGYub3Jn PG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0KPiA+ID4gU3ViamVjdDogUmU6IFtOZXRjb25mXSBD bGFyaWZpY2F0aW9uIHJlcXVlc3QgZm9yIE5FVENPTkYNCj4gPiA+IGVkaXQtY29uZmlnIGRlZmF1 bHQtb3BlcmF0aW9uIHJlcGxhY2UNCj4gPiA+DQo+ID4gPiBXaWxsaWFtIEl2b3J5IDx3aXZvcnlA QnJvY2FkZS5jb208bWFpbHRvOndpdm9yeUBCcm9jYWRlLmNvbT4+IHdyb3RlOg0KPiA+ID4gPiBI aSBNYXJ0aW4sDQo+ID4gPiA+DQo+ID4gPiA+IFRoYW5rcyAtIEkgdGhpbmsgdGhhdCB0aGUgc2Vj dGlvbiBvbiAncmVwbGFjZScgdW5kZXINCj4gPiA+ID4gJ2RlZmF1bHQtb3BlcmF0aW9uJyBjb3Vs ZCBkbyB3aXRoIGJlaW5nIGNsYXJpZmllZCBuZXh0IHRpbWUgdGhlDQo+ID4gPiA+IFJGQyBpcyB1 cGRhdGVkIHRoZW4uDQo+ID4gPiA+DQo+ID4gPiA+IEknZCBhcHByZWNpYXRlIHNvbWUgZnVydGhl ciBjbGFyaWZpY2F0aW9uIG9uIHdoYXQgZXhhY3RseSAnIG9ubHkNCj4gPiA+ID4gdGhlIGNvbmZp Z3VyYXRpb24gYWN0dWFsbHkgcHJlc2VudCBpbiB0aGUgPGNvbmZpZz4gcGFyYW1ldGVyIGlzDQo+ ID4gPiA+IGFmZmVjdGVkJw0KPiA+ID4gPiBtZWFucyBpbiBwcmFjdGljZS4NCj4gPiA+ID4NCj4g PiA+ID4gRmlyc3QsIHRoZSBnZW5lcmFsIHBhdHRlcm4gb2YgZXhhbXBsZXMgd2hpY2ggdXNlDQo+ ID4gPiA+ICdvcGVyYXRpb249PG9wZXJhdGlvbj4nIGlzIHRoYXQgdGhpcyBjb21tYW5kIGlzIHB1 dCBpbiB0aGUgJ3BhcmVudCcNCj4gPiA+ID4gZWxlbWVudCdzIHRhZywgaWUgdGhlIHRhZyB3aGlj aCBzcGVjaWZpZXMgJ2RlbGV0ZScgaXMgKm5vdCogZGVsZXRlZC4NCj4gPiA+DQo+ID4gPiBOby4g IEZvciBleGFtcGxlOg0KPiA+ID4NCj4gPiA+ICAgICA8aW50ZXJmYWNlIHhjOm9wZXJhdGlvbj0i ZGVsZXRlIj4NCj4gPiA+ICAgICAgIDxuYW1lPjE5Mi4wLjIuNDwvbmFtZT4NCj4gPiA+ICAgICA8 L2ludGVyZmFjZT4NCj4gPiA+DQo+ID4gPiB3aWxsIGRlbGV0ZSB0aGUgImludGVyZmFjZSIgbm9k ZSB3aXRoIHRoZSBuYW1lICIxOTIuMC4yLjQiDQo+ID4gPg0KPiA+ID4gSXQgZG9lcyBOT1Qga2Vl cCB0aGUgImludGVyZmFjZSIgbm9kZSBhbmQganVzdCBkZWxldGUgdGhlICJuYW1lIiBub2RlLg0K PiA+ID4NCj4gPiA+ID4gSG93IHRoZW4gd291bGQgeW91IGRlbGV0ZSBhIHRvcC1sZXZlbCBjb250 YWluZXI/DQo+ID4gPg0KPiA+ID4gIDxteS10b3AtbGV2ZWwtY29udGFpbmVyIG5jOm9wZXJhdGlv bj0iZGVsZXRlIi8+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiAvbWFydGluDQo+ID4gPg0K PiA+ID4NCj4gPiA+ID4gVGhlIGV4YW1wbGVzIGhhdmUgYQ0KPiA+ID4gPiAnPHRvcD4nIGVsZW1l bnQgYnV0IGluIGNhc2VzIHdoZXJlIHRoZXJlIGFyZSBtdWx0aXBsZSB0b3AtbGV2ZWwNCj4gPiA+ ID4gbm9kZXMsIHNvbWUgb2Ygd2hpY2ggYXJlIG9wdGlvbmFsIGluIHRoZSBjb25maWd1cmF0aW9u IChpZSBub3QNCj4gPiA+ID4gcHJlc2VuY2UgY29udGFpbmVycyksIGlzIGl0IHBvc3NpYmxlIHRv IGRlbGV0ZSB0aGVzZSBub2Rlcz8NCj4gPiA+ID4NCj4gPiA+ID4gU2Vjb25kbHksIGlmIEknbSBj b3JyZWN0IHRoYXQgdGhlICdkZWxldGUnIG9wZXJhdGlvbiB3b3VsZCBvbmx5DQo+ID4gPiA+IGFm ZmVjdCBub2RlcyBiZWxvdyB0aGUgb25lIHdpdGggdGhlIGRlbGV0ZSBvcGVyYXRpb24sIGlzIGl0 DQo+ID4gPiA+IHBvc3NpYmxlIHRvIGNvbnN0cnVjdCBhbiBlZGl0LWNvbmZpZyBQRFUgdGhhdCB3 b3VsZCBkZWxldGUgYWxsDQo+ID4gPiA+IGNoaWxkIG5vZGVzIHdpdGhvdXQgaGF2aW5nIHRvIGV4 cGxpY2l0bHkgc3BlY2lmeSBlYWNoIG9uZT8gIE9yDQo+ID4gPiA+IGlzIHRoZSBvbmx5IHdheSB0 byBhY2hpZXZlIHRoaXMgZWl0aGVyIHRvIGV4cGxpY2l0bHkgc3BlY2lmeSBhbGwNCj4gPiA+ID4g Y29uZmlnIHRvIGJlIHJlbW92ZWQsIG9yIHRvIGRvIGEgY29weS1jb25maWcgZXhwbGljaXRseQ0K PiA+ID4gPiBzcGVjaWZ5aW5nIGFsbCBjb25maWcgdGhhdCBpcyBub3QgdG8gYmUgZGVsZXRlZC4N Cj4gPiA+ID4NCj4gPiA+ID4gVGhhbmtzLA0KPiA+ID4gPg0KPiA+ID4gPiBXaWxsaWFtDQo+ID4g PiA+DQo+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+IEZyb206IE1h cnRpbiBCam9ya2x1bmQgW21haWx0bzptYmpAdGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwtZi5j b20+XQ0KPiA+ID4gPiBTZW50OiAxNCBBcHJpbCAyMDE2IDA5OjM0DQo+ID4gPiA+IFRvOiBXaWxs aWFtIEl2b3J5IDx3aXZvcnlAQnJvY2FkZS5jb208bWFpbHRvOndpdm9yeUBCcm9jYWRlLmNvbT4+ DQo+ID4gPiA+IENjOiBuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0K PiA+ID4gPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIENsYXJpZmljYXRpb24gcmVxdWVzdCBmb3Ig TkVUQ09ORg0KPiA+ID4gPiBlZGl0LWNvbmZpZyBkZWZhdWx0LW9wZXJhdGlvbiByZXBsYWNlDQo+ ID4gPiA+DQo+ID4gPiA+IEhpLA0KPiA+ID4gPg0KPiA+ID4gPiBXaWxsaWFtIEl2b3J5IDx3aXZv cnlAQnJvY2FkZS5jb208bWFpbHRvOndpdm9yeUBCcm9jYWRlLmNvbT4+IHdyb3RlOg0KPiA+ID4g PiA+IEhpLA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSSdkIGFwcHJlY2lhdGUgY2xhcmlmaWNhdGlv biBvZiBob3cgdGhlIE5FVENPTkYgZWRpdC1jb25maWcNCj4gPiA+ID4gPiBjb21tYW5kIHNob3Vs ZCB3b3JrIHdpdGggZGVmYXVsdC1vcGVyYXRpb24gc2V0IHRvICdyZXBsYWNlJy4NCj4gPiA+ID4g PiBGb3IgdGhlIG1vc3QgcGFydCwgdGhlIGVkaXQtY29uZmlnIHNlY3Rpb24gaXMgY2xlYXIgdGhh dA0KPiA+ID4gPiA+IGNvbmZpZyB3aWxsIG9ubHkgYmUgcmVwbGFjZWQgaWYgZXhwbGljaXRseSBv dmVyd3JpdHRlbiAoaWUgaWYNCj4gPiA+ID4gPiB5b3UgcHJvdmlkZSByZXBsYWNlbWVudCBjb25m aWcgZm9yIGdpdmVuIG5vZGVzKS4gIEhvd2V2ZXIsIHRoZQ0KPiA+ID4gPiA+IHNlY3Rpb24gb24g ZGVmYXVsdC1vcGVyYXRpb24gaXMgbGVzcyBjbGVhcjoNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAg ICAgICAgIFRoZSA8ZGVmYXVsdC1vcGVyYXRpb24+IHBhcmFtZXRlciBpcyBvcHRpb25hbCwgYnV0 IGlmDQo+ID4gcHJvdmlkZWQsDQo+ID4gPiA+ID4gICAgICAgICAgaXQgaGFzIG9uZSBvZiB0aGUg Zm9sbG93aW5nIHZhbHVlczoNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAgICAgICAgIG1lcmdlOiAg VGhlIGNvbmZpZ3VyYXRpb24gZGF0YSBpbiB0aGUgPGNvbmZpZz4gcGFyYW1ldGVyIGlzDQo+ID4g PiA+ID4gICAgICAgICAgICAgbWVyZ2VkIHdpdGggdGhlIGNvbmZpZ3VyYXRpb24gYXQgdGhlIGNv cnJlc3BvbmRpbmcNCj4gPiA+ID4gPiBsZXZlbA0KPiA+IGluDQo+ID4gPiA+ID4gICAgICAgICAg ICAgdGhlIHRhcmdldCBkYXRhc3RvcmUuICBUaGlzIGlzIHRoZSBkZWZhdWx0IGJlaGF2aW9yLg0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gICAgICAgICAgcmVwbGFjZTogIFRoZSBjb25maWd1cmF0aW9u IGRhdGEgaW4gdGhlIDxjb25maWc+IHBhcmFtZXRlcg0KPiA+ID4gPiA+ICAgICAgICAgICAgIGNv bXBsZXRlbHkgcmVwbGFjZXMgdGhlIGNvbmZpZ3VyYXRpb24gaW4gdGhlIHRhcmdldA0KPiA+ID4g PiA+ICAgICAgICAgICAgIGRhdGFzdG9yZS4gIFRoaXMgaXMgdXNlZnVsIGZvciBsb2FkaW5nIHBy ZXZpb3VzbHkgc2F2ZWQNCj4gPiA+ID4gPiAgICAgICAgICAgICBjb25maWd1cmF0aW9uIGRhdGEu DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBTcGVjaWZpY2FsbHksIHdoaWxlICdtZXJnZScgc3RhdGVz IHRoYXQgbWVyZ2UgaGFwcGVzbiB3aXRoDQo+ID4gPiA+ID4gJ2NvbmZpZ3VyYXRpb24gYXMgdGhl IGNvcnJlc3BvbmRpbmcgbGV2ZWwnLCAncmVwbGFjZScgc3RhdGVzDQo+ID4gPiA+ID4gdGhhdCBp cyAnY29tcGxldGVseSByZXBsYWNlcycgdGhlIGNvbmZpZ3VyYXRpb24sIHN1Z2dlc3RpbmcNCj4g PiA+ID4gPiB0aGF0IGl0IHdpbGwgcmVtb3ZlIEFMTCBleGlzdGluZyBjb25maWd1cmF0aW9uIHJl Z2FyZGxlc3Mgb2YNCj4gPiA+ID4gPiB3aGF0IGlzIGV4cGxpY2l0bHkgcHJvdmlkZWQgYXMgdGhl IHJlcGxhY2VtZW50LiAgSXMgdGhhdA0KPiA+ID4gPiA+IGNvcnJlY3QsIG9yIGlzICdyZXBsYWNl JyBtZWFudCB0byBoYXZlIGVxdWl2YWxlbnQgc2VtYW50aWNzIHRvDQo+ID4gPiA+ID4gJ21lcmdl JyBpZSBpdCB3aWxsIG9ubHkgcmVwbGFjZSBjb25maWd1cmF0aW9uIHdoZW4gYW4gZXhwbGljaXQN Cj4gPiA+ID4gPiByZXBsYWNlbWVudCBpcyBwcm92aWRlZC4gIEluIG90aGVyIHdvcmRzLCBpZiB0 aGUgbGF0dGVyIGNhc2UNCj4gPiA+ID4gPiBpcyBjb3JyZWN0LCBhbGwgaXQgZG9lcyBpcyByZW1v dmUgdGhlIHJlcXVpcmVtZW50IHRvIHNwZWNpZnkNCj4gPiA+ID4gPiB0aGUgb3BlcmF0aW9uIGlu IGVhY2gNCj4gPiBlbGVtZW50IG9mIG5ldyBjb25maWcuDQo+ID4gPiA+DQo+ID4gPiA+IFllcyB0 aGUgbGF0dGVyIGlzIGNvcnJlY3QuICBOb3RlIHRoYXQgdGhlIGRlZmluaXRpb24gb2YgInJlcGxh Y2UiDQo+ID4gPiA+IGFzIGFuIG9wZXJhdGlvbiBzYXlzOg0KPiA+ID4gPg0KPiA+ID4gPiAgICAg ICAgICAgICBVbmxpa2UgYQ0KPiA+ID4gPiAgICAgICAgICAgICA8Y29weS1jb25maWc+IG9wZXJh dGlvbiwgd2hpY2ggcmVwbGFjZXMgdGhlIGVudGlyZSB0YXJnZXQNCj4gPiA+ID4gICAgICAgICAg ICAgY29uZmlndXJhdGlvbiwgb25seSB0aGUgY29uZmlndXJhdGlvbiBhY3R1YWxseSBwcmVzZW50 IGluDQo+ID4gPiA+ICAgICAgICAgICAgIHRoZSA8Y29uZmlnPiBwYXJhbWV0ZXIgaXMgYWZmZWN0 ZWQuDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IC9tYXJ0aW4NCj4gPiA+ID4NCj4gPiA+DQo+ ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4gTmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86TmV0 Y29uZkBpZXRmLm9yZz4NCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldGNvbmYNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiBOZXRjb25mQGlldGYub3Jn PG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0Y29uZg0KPg0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5v cmc8bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldGNvbmYNCg0K --_000_A125E53CE190A749957C19483DC79F9F5CCA4838US70TWXCHMBA11z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28t c3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoeC4mbmJzcDsgSW4g Y2FzZSBJIGFjY2lkZW50bHkgZ2F2ZSB0aGUgd3JvbmcgaW1wcmVzc2lvbiAtJmd0OyBJIHdhc27i gJl0IGFkdm9jYXRpbmcgdG8gY2hhbmdlICZsdDtlZGl0LWNvbmZpZyZndDsuJm5ic3A7IEp1c3Qg dHJ5aW5nIHRvIGNsYXJpZnkgdGhlIGludGVuZGVkL2V4cGVjdGVkIGJlaGF2aW9yLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SSB3YXNu4oCZdCBldmVuIGNvbnNpZGVyaW5nIE5BQ00gZHVyaW5nIHRoaXMgd2hvbGUgZGlz Y3Vzc2lvbi4mbmJzcDsgSSB3b3VsZCBhc3N1bWUgTkFDTSB3b3VsZCBhZmZlY3QgdGhlIGJlaGF2 aW9yIG9mICZsdDtlZGl0LWNvbmZpZyZndDsgcmVwbGFjZSBvciBkZWxldGUgKGkuZS4gbm9kZXMg dGhhdA0KIHRoZSBjbGllbnQgY2Fu4oCZdCBhY2Nlc3MgYXJlIG5vdCBkZWxldGVkLCBjYW4gZWFz aWx5IHJlc3VsdCBpbiBpbnZhbGlkIGNhbmRpZGF0ZSBjb25maWdzKSAsIGJ1dCB0aGF0IHBlcm1p c3Npb24gc2hvdWxkIGJlIGNvbnRyb2xsZWQgZm9yIHRoZSAmbHQ7Y29weS1jb25maWcmZ3Q7IGF0 IHRoZSBSUEMgbGV2ZWwgKGkuZS4gYWxsIG9yIG5vdGhpbmcgYXV0aG9yaXphdGlvbiBmb3IgYSBj bGllbnQvdXNlciB0byB1c2UgdGhlIGNvcHktY29uZmlnIFJQQykuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5KYXNvbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gQW5keSBCaWVybWFuIFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0KPGJy Pg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1heSAzMSwgMjAxNiAyMDo1MDxicj4NCjxiPlRvOjwv Yj4gU3Rlcm5lLCBKYXNvbiAoTm9raWEgLSBDQSk8YnI+DQo8Yj5DYzo8L2I+IE1hcnRpbiBCam9y a2x1bmQ7IG5ldGNvbmZAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtOZXRjb25m XSBDbGFyaWZpY2F0aW9uIHJlcXVlc3QgZm9yIE5FVENPTkYgZWRpdC1jb25maWcgZGVmYXVsdC1v cGVyYXRpb24gcmVwbGFjZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGksPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGRvbid0IHRoaW5rICZsdDtlZGl0LWNvbmZpZyZndDsgbmVlZHMgdG8gYmUgY2hhbmdlZCB0byBw cm92aWRlIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+c2FtZSByZXBsYWNlIHNlbWFudGljcyBhcyAmbHQ7Y29weS1jb25maWcmZ3Q7LiAmbmJz cDtjb3B5LWNvbmZpZyBpczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Zm9yIGNvbXBsZXRlIGNvbmZpZ3VyYXRpb25zLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBpcyBhbiB1bndyaXR0 ZW4gYXNzdW1wdGlvbiB0aGF0IHRoZSBjb3B5LWNvbmZpZyBjb250ZW50cyBhcmU8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm5vdCBwcnVuZWQgYXQg YWxsIGJ5IGFjY2VzcyBjb250cm9sLiBBIG1pc3Npbmcgbm9kZSB3aWxsIGJlIGludGVycHJldGVk IGFzIGEgZGVsZXRlIGF0dGVtcHQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIG5vdCBhdCBhbGwgZGVzaXJhYmxlIGlmIHRoZSBjbGll bnQgaXMgbm90IGF1dGhvcml6ZWQgYW5kIGlzIG5vdCBldmVuIGF3YXJlPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5vZiB0aGVzZSAmcXVvdDtoaWRk ZW4mcXVvdDsgbm9kZXMuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE1heSAzMSwgMjAxNiBhdCA2OjM2IEFN LCBTdGVybmUsIEphc29uIChOb2tpYSAtIENBKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphc29uLnN0 ZXJuZUBub2tpYS5jb20iIHRhcmdldD0iX2JsYW5rIj5qYXNvbi5zdGVybmVAbm9raWEuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaHggTWFy dGluLiZuYnNwOyBZb3VyIGV4cGxhbmF0aW9uIHRoYXQgYSBkZWZhdWx0IHJlcGxhY2Ugb3BlcmF0 aW9uIGNhbiBvbmx5IGFwcGx5IHRvIGVsZW1lbnRzIHRoYXQgYXJlIGluIHRoZSByZXF1ZXN0IGhl bHBzIGEgbG90Ljxicj4NCjxicj4NClNvIHRoZXJlIHJlYWxseSBpcyBubyBzdWNoIHRoaW5nIGFz IGFuIGVkaXQtY29uZmlnICdyZXBsYWNlJyBvcGVyYXRpb24gdGhhdCBvcGVyYXRlcyAmcXVvdDth dCB0aGUgcm9vdCZxdW90Oy4gVGhhdCBjYW4gb25seSBiZSBkb25lIHdpdGggYSBzcGVjaWFsIGRl ZGljYXRlZCBSUEMgKGUuZy4gY29weS1jb25maWcgYXMgeW91IHNob3cgaW4gQ2FzZSA1KS48YnI+ DQo8YnI+DQpTbyBteSBjYXNlIDQgaXMgZXF1aXZhbGVudCB0byB0aGlzOjxicj4NCjxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7c3lzdGVtIG9wZXJhdGlvbj0ncmVwbGFjZScmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7cGFzc3dvcmQtY29udHJv bCBvcGVyYXRpb249J3JlcGxhY2UnJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZsdDttaW4tbGVuZ3RoIG9wZXJhdGlvbj0ncmVwbGFjZScmZ3Q7MTAmbHQ7 L21pbi1sZW5ndGgmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7 L3Bhc3N3b3JkLWNvbnRyb2wmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDsv c3lzdGVtJmd0Ozxicj4NCjxicj4NCndoaWNoIHdpbGwgcmVwbGFjZSB0aGUgZW50aXJlIGNvbnRl bnRzIG9mIHRoZSAvc3lzdGVtIHN1YnRyZWUgKGJ1dCBub3QgYW55dGhpbmcgZWxzZSkuPGJyPg0K PGJyPg0KT24gYSByZWxhdGVkIG5vdGUgLSZndDsgaXMgdGhlIGZpbmFsIHJlc3VsdCAoaS5lLiBk YXRhc3RvcmUgY29udGVudHMpIG9mIGEgcmVwbGFjZSBvcGVyYXRpb24gYWx3YXlzIGV4YWN0bHkg dGhlIHNhbWUgYXMgYSByZW1vdmUgJiM0MzsgbWVyZ2Ugd2l0aCB0aGUgc2FtZSBkYXRhIGF0IHRo ZSBzYW1lIGxvY2F0aW9uID8mbmJzcDsgSSBjYW4ndCB0aGluayBvZiBhbiBleGFtcGxlIHdoZXJl IHRoYXQgaXNuJ3QgdHJ1ZSBidXQgSSBtYXkgYmUgbWlzc2luZyBzb21lIGNvcm5lcg0KIGNhc2Uu PGJyPg0KPGJyPg0KRm9yIHRoZSBjYW5kaWRhdGUgZGF0YXN0b3JlIGl0IHNlZW1zIHRoYXQgJ3Jl cGxhY2UnIGlzIHNpbXBseSBhIHNob3J0aGFuZCB3YXkgdG8gZG8gcmVtb3ZlJiM0MzttZXJnZSBp biBhIHNpbmdsZSBlZGl0LWNvbmZpZy4mbmJzcDsgRm9yIGEgcnVubmluZyBkYXRhc3RvcmUgKHdy aXRlYWJsZS1ydW5uaW5nKSB0aGUgaW1wYWN0cyB3b3VsZCBiZSBxdWl0ZSBkaWZmZXJlbnQgdGhv dWdoIHNpbmNlIHRoZSBlZGl0LWNvbmZpZyAncmVtb3ZlJyB3b3VsZCBiZSBhcHBsaWVkDQogaW1t ZWRpYXRlbHkgd2hpY2ggd291bGQgY2xlYXIgb3V0IGFsbCBjb25maWcgZm9yIGEgc2hvcnQgcGVy aW9kIGJlZm9yZSB0aGUgJ21lcmdlJyB0aGVuIGdldHMgcHJvY2Vzc2VkLjxicj4NCjxicj4NClJl Z2FyZHMsPGJyPg0KSmFzb248YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCkZyb206IE1hcnRpbiBCam9ya2x1bmQgW21haWx0bzo8YSBocmVmPSJtYWlsdG86bWJqQHRh aWwtZi5jb20iPm1iakB0YWlsLWYuY29tPC9hPl08YnI+DQpTZW50OiBUdWVzZGF5LCBNYXkgMzEs IDIwMTYgNDo1MDxicj4NClRvOiBTdGVybmUsIEphc29uIChOb2tpYSAtIENBKTxicj4NCkNjOiA8 YSBocmVmPSJtYWlsdG86eGlhbmdsaUBzZWd1ZXNvZnQuY29tIj54aWFuZ2xpQHNlZ3Vlc29mdC5j b208L2E+OyA8YSBocmVmPSJtYWlsdG86d2l2b3J5QEJyb2NhZGUuY29tIj4NCndpdm9yeUBCcm9j YWRlLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGll dGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gQ2xhcmlmaWNhdGlvbiByZXF1 ZXN0IGZvciBORVRDT05GIGVkaXQtY29uZmlnIGRlZmF1bHQtb3BlcmF0aW9uIHJlcGxhY2U8YnI+ DQo8YnI+DQomcXVvdDtTdGVybmUsIEphc29uIChOb2tpYSAtIENBKSZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmphc29uLnN0ZXJuZUBub2tpYS5jb20iPmphc29uLnN0ZXJuZUBub2tpYS5jb208 L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IEhpIGd1eXMsPGJyPg0KJmd0Ozxicj4NCiZndDsgSSB0 aGluayB0aGVyZSBpcyBzb21lIGNvbmZsaWN0aW5nIGluZm9ybWF0aW9uIHdydCBkZWZhdWx0LW9w ZXJhdGlvbjxicj4NCiZndDsgcmVwbGFjZSBoZXJlLjxicj4NCjxicj4NCkkgYWdyZWUgaXQgaXMg bm90IGNsZWFyLjxicj4NCjxicj4NCiZndDsgVGhlIGZvbGxvd2luZyBzbmlwcGV0IG9mIFJGQyA2 MjQxIGNsZWFybHkgc3RhdGVzIChJTU8pIHRoYXQgdGhlIGVudGlyZTxicj4NCiZndDsgY29uZmln IGlzIGFmZmVjdGVkL3JlcGxhY2VkLiZuYnNwOyBUaGUgZmlyc3Qgc2VudGVuY2Ugc2F5cyBpdC48 YnI+DQo8YnI+DQpJIGRvbid0IHRoaW5rIHRoaXMgc3RhdGVtZW50IGNsZWFybHkgc2F5cyB0aGF0 IHRoZSBlbnRpcmUgZGF0YXN0b3JlIGlzIHJlcGxhY2VkLiZuYnNwOyBJdCB1c2VzIHRoZSB0ZXJt ICZxdW90O2NvbXBsZXRlbHkgcmVwbGFjZSZxdW90Oy4mbmJzcDsgSSBkb24ndCBrbm93IGhvdyB0 aGF0IGlzIGRpZmZlcmVudCBmcm9tICZxdW90O3JlcGxhY2UmcXVvdDsuJm5ic3A7IElNTywgJnF1 b3Q7cmVwbGFjZSZxdW90OyBpbXBsaWVzICZxdW90O2NvbXBsZXRlbHkmcXVvdDsuLi48YnI+DQo8 YnI+DQomZ3Q7IFRoZW4gdGhlIHNlY29uZCBzZW50ZW5jZSBnaXZlcyB5ZXQgYW5vdGhlciBpbmRp Y2F0aW9uIHRoYXQgaXQgcmVwbGFjZXM8YnI+DQomZ3Q7IHRoZSBlbnRpcmUgY29uZmlnOjxicj4N Cjxicj4NCk5vdCBuZWNlc3NhcmlseS48YnI+DQo8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmVwbGFjZTombmJzcDsgVGhlIGNvbmZpZ3VyYXRpb24gZGF0 YSBpbiB0aGUgJmx0O2NvbmZpZyZndDsgcGFyYW1ldGVyPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY29tcGxldGVseSByZXBsYWNlcyB0aGUg Y29uZmlndXJhdGlvbiBpbiB0aGUgdGFyZ2V0PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGF0YXN0b3JlLiZuYnNwOyBUaGlzIGlzIHVzZWZ1 bCBmb3IgbG9hZGluZyBwcmV2aW91c2x5IHNhdmVkPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY29uZmlndXJhdGlvbiBkYXRhLjxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGFsc28gZm91bmQgYW4gb2xkZXIgZGlzY3Vzc2lvbiBv biB0aGlzIG9uIHRoZSBtYWlsaW5nIGxpc3QgdGhhdDxicj4NCiZndDsgaW5kaWNhdGVzIHRoYXQg YSBkZWZhdWx0IGFjdGlvbiBvZiByZXBsYWNlIGlzIGludGVuZGVkIHRvIGJlIHVzZWQgZm9yPGJy Pg0KJmd0OyB0aGUgZW50aXJlIGRhdGFzdG9yZS4mbmJzcDsgRnJvbTxicj4NCiZndDsgPGEgaHJl Zj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9uZXRjb25mL3M0S09KeEln YkR6cUFYUy11Rl9qRmktaVFzVSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9tYWlsYXJjaGl2 ZS5pZXRmLm9yZy9hcmNoL21zZy9uZXRjb25mL3M0S09KeElnYkR6cUFYUy11Rl9qRmktaVFzVTwv YT46PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgMSk8YnI+DQomZ3Q7 ICZndDsmbmJzcDsgJm5ic3A7ICRiYWNrdXAgPSBnZXQtY29uZmlnKHNvdXJjZT1ydW5uaW5nKTxi cj4NCiZndDsgJmd0OyZuYnNwOyAyKTxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgY29weS1j b25maWcoc291cmNlPSRiYWNrdXAsIHRhcmdldD1ydW5uaW5nKSZuYnNwOyBPUjxicj4NCiZndDsg Jmd0OyZuYnNwOyAmbmJzcDsgZWRpdC1jb25maWcoc291cmNlPSRiYWNrdXAsIHRhcmdldD1ydW5u aW5nLDxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgZGVmYXVsdC1vcGVyYXRpb249cmVwbGFj ZSkmcXVvdDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgJmx0O2VkaXQtY29uZmlnJmd0 OyBvcGVyYXRpb25zIGFyZSBpbmhlcml0ZWQuIFRoZSBkZWZhdWx0LW9wZXJhdGlvbiBhcHBsaWVz PGJyPg0KJmd0OyB0byBhbGwgdG9wIGxldmVsIG9iamVjdHMuJm5ic3A7IEJ1dCBJJ20gbm90IGNl cnRhaW4gd2hldGhlciBpdCBhcHBsaWVzIHRvPGJyPg0KJmd0OyBhbGwgdG9wIGxldmVsIG9iamVj dHMgaW4gdGhlIGRhdGEgbW9kZWwgb24gdGhlIHNlcnZlciBvciBqdXN0IGFsbCB0aGU8YnI+DQom Z3Q7IHRvcCBsZXZlbCBvYmplY3RzIHRoYXQgYXJlIGluY2x1ZGVkIGluIHRoZSAmbHQ7ZWRpdC1j b25maWcmZ3Q7IHJlcXVlc3QuPGJyPg0KPGJyPg0KVGhlIGxhdHRlci4mbmJzcDsgSXQgaXMganVz dCBhIGRlZmF1bHQgdmFsdWUgZm9yIHRoZSAmcXVvdDtvcGVyYXRpb24mcXVvdDsgYXR0cmlidXRl OyBpLmUuLCBpbnN0ZWFkIG9mIHVzaW5nICZxdW90O2RlZmF1bHQtb3BlcmF0aW9uJnF1b3Q7LCB5 b3UgY291bGQgZXhwbGljaXRseSBzZXQgdGhlICZxdW90O29wZXJhdGlvbiZxdW90OyBhdHRyaWJ1 dGUgLSBhbmQgeW91IGNhbiBvbmx5IGRvIHRoYXQgZm9yIHRoZSBlbGVtZW50cyBpbiB0aGUgcmVx dWVzdCAob2J2aW91bHN5KS48YnI+DQo8YnI+DQomZ3Q7IEZyb20gdGhlIGRlc2NyaXB0aW9ucyBh Ym92ZSBpdCBzZWVtcyBpdCBtdXN0IGFwcGx5IHRvIGFsbCB0b3AgbGV2ZWw8YnI+DQomZ3Q7IG9i amVjdHMgaW4gdGhlIHNlcnZlciBidXQgdGhhdCBzZWVtcyB0byBjb25mbGljdCB3aXRoOjxicj4N CiZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJnF1b3Q7b25seSB0aGUgY29uZmlndXJhdGlvbiBh Y3R1YWxseSBwcmVzZW50IGluIHRoZSAmbHQ7Y29uZmlnJmd0OyBwYXJhbWV0ZXI8YnI+DQomZ3Q7 ICZndDsgaXMmbmJzcDsgYWZmZWN0ZWQmcXVvdDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIZXJlIGlz IGEgc2V0IG9mIGV4YW1wbGVzIHRoYXQgbWF5IGhlbHAgY2xhcmlmeSB0aGluZ3MuIFRoZSBmaXJz dCAzPGJyPg0KJmd0OyBjYXNlcyBhcmUgYW4gaW5jcmVtZW50YWwgbGVhZC1pbiB0byBjYXNlIDQg d2hpY2ggaXMgdGhlIGxlYXN0IGNsZWFyPGJyPg0KJmd0OyBmb3IgbWUuPGJyPg0KJmd0Ozxicj4N CiZndDsgIyMgSW5pdGlhbCBzZXJ2ZXIgQ29uZmlnIEEgKHVzZWQgaW4gYWxsIHRoZSBjYXNlcyBi ZWxvdyk6PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsmbHQ7c3lzdGVtJmd0Ozxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyZsdDtwYXNzd29yZC1jb250cm9sJmd0Ozxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7bWluLWxlbmd0aCZndDsxMiZsdDsvbWluLWxlbmd0aCZn dDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O3JlcXVpcmUtY2FwcyZn dDt0cnVlJmx0O3JlcXVpcmUtY2FwcyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsm bHQ7L3Bhc3N3b3JkLWNvbnRyb2wmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0 O2NvbnNvbGUmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDt3aWR0 aCZndDsxMzImbHQ7L3dpZHRoJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmbHQ7ZW5hYmxlZCZndDt0cnVlJmx0Oy9lbmFibGVkJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyZsdDsvY29uc29sZSZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyZsdDsvc3lz dGVtJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7Jmx0O3FvcyZndDs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsmbHQ7aW5ncmVzcyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmx0O2NsYXNzLWxpbWl0Jmd0OzgmbHQ7L2NsYXNzLWxpbWl0Jmd0Ozxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7c3ViLWNsYXNzZXMmZ3Q7dHJ1ZSZsdDsv c3ViLWNsYXNzZXMmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy9pbmdyZXNz Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7Jmx0Oy9xb3MmZ3Q7PGJyPg0KJmd0Ozxicj4NCiZn dDsgIyMgQ2FzZSAxOjxicj4NCiZndDsgLSBJbml0aWFsIENvbmZpZyBBPGJyPg0KJmd0OyAtIGVk aXQtY29uZmlnIHJlcXVlc3QgKG5vIGRlZmF1bHQgb3BlcmF0aW9uKTo8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJmx0O3N5c3RlbSZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZsdDtwYXNzd29yZC1jb250cm9sJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDttaW4tbGVuZ3RoIG9wZXJhdGlvbj0ncmVwbGFjZScm Z3Q7MTAmbHQ7L21pbi1sZW5ndGgmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbHQ7L3Bhc3N3b3JkLWNvbnRyb2wmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZsdDsvc3lzdGVtJmd0Ozxicj4NCiZndDsgLSBSZXN1bHRpbmcgY29uZmlnIG9uIHRoZSBz ZXJ2ZXIgKG9ubHkgJ21pbi1sZW5ndGgnIGFmZmVjdGVkKTo8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJmx0O3N5c3RlbSZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZsdDtwYXNzd29yZC1jb250cm9sJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZsdDttaW4tbGVuZ3RoJmd0OzEwJmx0Oy9taW4tbGVuZ3RoJmd0Ozxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtyZXF1aXJlLWNh cHMmZ3Q7dHJ1ZSZsdDtyZXF1aXJlLWNhcHMmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbHQ7L3Bhc3N3b3JkLWNvbnRyb2wmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbHQ7Y29uc29sZSZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7d2lkdGgmZ3Q7MTMyJmx0Oy93aWR0aCZndDs8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7ZW5hYmxlZCZndDt0cnVl Jmx0Oy9lbmFibGVkJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0 Oy9jb25zb2xlJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7L3N5c3RlbSZn dDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O3FvcyZndDs8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtpbmdyZXNzJmd0Ozxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtjbGFzcy1saW1pdCZndDs4Jmx0Oy9jbGFz cy1saW1pdCZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bHQ7c3ViLWNsYXNzZXMmZ3Q7dHJ1ZSZsdDsvc3ViLWNsYXNzZXMmZ3Q7PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7L2luZ3Jlc3MmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZsdDsvcW9zJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICMjIENhc2UgMjo8 YnI+DQomZ3Q7IC0gSW5pdGlhbCBDb25maWcgQTxicj4NCiZndDsgLSBlZGl0LWNvbmZpZyByZXF1 ZXN0IChubyBkZWZhdWx0IG9wZXJhdGlvbik6PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZsdDtzeXN0ZW0mZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7 cGFzc3dvcmQtY29udHJvbCBvcGVyYXRpb249J3JlcGxhY2UnJmd0Ozxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDttaW4tbGVuZ3RoJmd0OzEwJmx0Oy9taW4t bGVuZ3RoJmd0OyZuYnNwOyAmbmJzcDsvLyBpbmhlcml0ZWQgcmVwbGFjZTxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0Oy9wYXNzd29yZC1jb250cm9sJmd0Ozxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7L3N5c3RlbSZndDs8YnI+DQomZ3Q7IC0gUmVzdWx0 aW5nIGNvbmZpZyBvbiB0aGUgc2VydmVyIChhbGwgJ3Bhc3N3b3JkLWNvbnRyb2wnIGFmZmVjdGVk KTo8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O3N5c3RlbSZndDs8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtwYXNzd29yZC1jb250cm9sJmd0Ozxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDttaW4tbGVuZ3RoJmd0 OzEwJmx0Oy9taW4tbGVuZ3RoJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJmx0Oy9wYXNzd29yZC1jb250cm9sJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJmx0O2NvbnNvbGUmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJmx0O3dpZHRoJmd0OzEzMiZsdDsvd2lkdGgmZ3Q7PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O2VuYWJsZWQmZ3Q7dHJ1ZSZsdDsvZW5h YmxlZCZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDsvY29uc29s ZSZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0Oy9zeXN0ZW0mZ3Q7PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtxb3MmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbHQ7aW5ncmVzcyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7Y2xhc3MtbGltaXQmZ3Q7OCZsdDsvY2xhc3MtbGltaXQm Z3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O3N1Yi1j bGFzc2VzJmd0O3RydWUmbHQ7L3N1Yi1jbGFzc2VzJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJmx0Oy9pbmdyZXNzJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbHQ7L3FvcyZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAjIyBDYXNlIDM6PGJyPg0KJmd0 OyAtIEluaXRpYWwgQ29uZmlnIEE8YnI+DQomZ3Q7IC0gZWRpdC1jb25maWcgcmVxdWVzdCAobm8g ZGVmYXVsdCBvcGVyYXRpb24pOjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7c3lz dGVtIG9wZXJhdGlvbj0ncmVwbGFjZScmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbHQ7cGFzc3dvcmQtY29udHJvbCZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsvLyBpbmhlcml0ZWQgcmVwbGFjZTxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDttaW4tbGVuZ3RoJmd0OzEwJmx0Oy9t aW4tbGVuZ3RoJmd0OyZuYnNwOyAvLyBpbmhlcml0ZWQgcmVwbGFjZTxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0Oy9wYXNzd29yZC1jb250cm9sJmd0Ozxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7L3N5c3RlbSZndDs8YnI+DQomZ3Q7IC0gUmVzdWx0aW5n IGNvbmZpZyBvbiB0aGUgc2VydmVyIChhbGwgJ3N5c3RlbScgYWZmZWN0ZWQpIDo8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O3N5c3RlbSZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZsdDtwYXNzd29yZC1jb250cm9sJmd0Ozxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDttaW4tbGVuZ3RoJmd0OzEwJmx0Oy9taW4t bGVuZ3RoJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0Oy9wYXNz d29yZC1jb250cm9sJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7L3N5c3Rl bSZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O3FvcyZndDs8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtpbmdyZXNzJmd0Ozxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtjbGFzcy1saW1pdCZndDs4Jmx0Oy9j bGFzcy1saW1pdCZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbHQ7c3ViLWNsYXNzZXMmZ3Q7dHJ1ZSZsdDsvc3ViLWNsYXNzZXMmZ3Q7PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7L2luZ3Jlc3MmZ3Q7PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZsdDsvcW9zJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICMjIENhc2Ug NDo8YnI+DQomZ3Q7IC0gSW5pdGlhbCBDb25maWcgQTxicj4NCiZndDsgLSBlZGl0LWNvbmZpZyBy ZXF1ZXN0ICghISB3aXRoIGRlZmF1bHQtb3BlcmF0aW9uIHJlcGxhY2UgISEpOjxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7c3lzdGVtJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJmx0O3Bhc3N3b3JkLWNvbnRyb2wmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O21pbi1sZW5ndGgmZ3Q7MTAmbHQ7L21pbi1s ZW5ndGgmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7L3Bhc3N3 b3JkLWNvbnRyb2wmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDsvc3lzdGVt Jmd0Ozxicj4NCiZndDsgLSBSZXN1bHRpbmcgY29uZmlnIG9uIHRoZSBzZXJ2ZXIgKGVudGlyZSBz ZXJ2ZXIgZGF0YXN0b3JlIGFmZmVjdGVkID8pOjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbHQ7c3lzdGVtJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0 O3Bhc3N3b3JkLWNvbnRyb2wmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJmx0O21pbi1sZW5ndGgmZ3Q7MTAmbHQ7L21pbi1sZW5ndGgmZ3Q7PGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7L3Bhc3N3b3JkLWNvbnRyb2wmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDsvc3lzdGVtJmd0Ozxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOy8vIG5vIHFvcyBkYXRhID88YnI+DQo8YnI+DQpUaGlzIGlzIG5vdCBj b3JyZWN0OyBxb3MgaXMgdW5hZmZlY3RlZC48YnI+DQo8YnI+DQojIyBDYXNlIDU6PGJyPg0KLSBJ bml0aWFsIENvbmZpZyBBPGJyPg0KLSBjb3B5LWNvbmZpZyByZXF1ZXN0PGJyPg0KJm5ic3A7ICZu YnNwOyAmbHQ7c3lzdGVtJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtw YXNzd29yZC1jb250cm9sJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmbHQ7bWluLWxlbmd0aCZndDsxMCZsdDsvbWluLWxlbmd0aCZndDs8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbHQ7L3Bhc3N3b3JkLWNvbnRyb2wmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsmbHQ7L3N5c3RlbSZndDs8YnI+DQotIFJlc3VsdGluZyBjb25maWcgb24gdGhlIHNlcnZl ciAoZW50aXJlIHNlcnZlciBkYXRhc3RvcmUgYWZmZWN0ZWQgISk6PGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsmbHQ7c3lzdGVtJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZs dDtwYXNzd29yZC1jb250cm9sJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bHQ7bWluLWxlbmd0aCZndDsxMCZsdDsvbWluLWxlbmd0aCZndDs8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbHQ7L3Bhc3N3b3JkLWNvbnRyb2wmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsmbHQ7L3N5c3RlbSZndDs8YnI+DQombmJzcDsgJm5ic3A7IC8vIG5vIHFvcyBkYXRhICE8YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQovbWFydGluPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KJmd0Ozxi cj4NCiZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7IEphc29uPGJyPg0KJmd0Ozxicj4NCiZndDsgLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IEVYVCBYaWFuZyBMaSBbbWFp bHRvOjxhIGhyZWY9Im1haWx0bzp4aWFuZ2xpQHNlZ3Vlc29mdC5jb20iPnhpYW5nbGlAc2VndWVz b2Z0LmNvbTwvYT5dPGJyPg0KJmd0OyBTZW50OiBUdWVzZGF5LCBNYXkgMDMsIDIwMTYgMTE6MjE8 YnI+DQomZ3Q7IFRvOiBTdGVybmUsIEphc29uIChOb2tpYSAtIENBKTsgJ01hcnRpbiBCam9ya2x1 bmQnOyA8YSBocmVmPSJtYWlsdG86d2l2b3J5QEJyb2NhZGUuY29tIj4NCndpdm9yeUBCcm9jYWRl LmNvbTwvYT48YnI+DQomZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+ bmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6IFJFOiBbTmV0Y29uZl0gQ2xh cmlmaWNhdGlvbiByZXF1ZXN0IGZvciBORVRDT05GIGVkaXQtY29uZmlnPGJyPg0KJmd0OyBkZWZh dWx0LW9wZXJhdGlvbiByZXBsYWNlPGJyPg0KJmd0Ozxicj4NCiZndDsgSGk8YnI+DQomZ3Q7PGJy Pg0KJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7Li4u PGJyPg0KJmd0OyAmZ3Q7IEluIG15IGZpcnN0IHF1ZXN0aW9uIEkgbWVhbnQgJnF1b3Q7dXNpbmcg YW4gJmx0O2VkaXQtY29uZmlnJmd0OyZxdW90Ozo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgSXMgdGhlcmUgbm8gd2F5IHRvIGRlbGV0ZSAob3IgcmVwbGFjZSkgdGhlIGVudGlyZSBjb250 ZW50cyBvZiB0aGU8YnI+DQomZ3Q7IGRhdGFzdG9yZTxicj4NCiZndDsgJmd0OyB1c2luZyBhbiAm bHQ7ZWRpdC1jb25maWcmZ3Q7IChhbmQgd2l0aG91dCB1c2luZyAmbHQ7Y29weS1jb25maWcmZ3Q7 IHdpdGhvdXQ8YnI+DQomZ3Q7ICZndDsgaGF2aW5nIHRvIGV4cGxpY2l0bHkgbGlzdCBldmVyeSBz aW5nbGUgdG9wIGxldmVsIG5vZGUgPzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 IEkgZG9uJ3QgdGhpbmsgZWRpdC1jb25maWcgaXMgZGVzaWduZWQgdG8gZG8gdGhhdC48YnI+DQom Z3Q7PGJyPg0KJmd0OyBUbyBkZWxldGUgYSBkYXRhc3RvcmUsIHVzZSAmbHQ7ZGVsZXRlLWNvbmZp ZyZndDssIGFsdGhvdWdoICZsdDtydW5uaW5nJmd0OyBjYW4ndDxicj4NCiZndDsgYmUgZGVsZXRl ZC48YnI+DQomZ3Q7IFRvIHJlcGxhY2UgdGhlICplbnRpcmUgY29uZmlnKiwgdXNlICZsdDtjb3B5 LWNvbmZpZyZndDsuPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyBGcm9tIHRoZSBkZXNjcmlwdGlv biBvZiB0aGUgZGVmYXVsdC1vcGVyYXRpb24gJ3JlcGxhY2UnIGl0IHNlZW1zIGl0PGJyPg0KJmd0 OyAmZ3Q7IGlzPGJyPg0KJmd0OyBwb3NzaWJsZTxicj4NCiZndDsgJmd0OyB2aWEgdGhlIGRlZmF1 bHQgb3BlcmF0aW9uOjxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgcmVwbGFjZTombmJzcDsgVGhlIGNvbmZpZ3VyYXRpb24gZGF0YSBpbiB0aGUgJmx0O2Nv bmZpZyZndDsgcGFyYW1ldGVyPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29tcGxldGVseSByZXBsYWNlcyB0aGUgY29uZmlndXJh dGlvbiBpbiB0aGUgdGFyZ2V0PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZGF0YXN0b3JlLiZuYnNwOyBUaGlzIGlzIHVzZWZ1bCBm b3IgbG9hZGluZyBwcmV2aW91c2x5IHNhdmVkPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29uZmlndXJhdGlvbiBkYXRhLjxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBOby4gVGhlIGRlZmluaXRpb24gb2YgJnF1b3Q7cmVw bGFjZSZxdW90OyBhcyBhbiBvcGVyYXRpb24gc2F5cyBjbGVhcmx5Ojxicj4NCiZndDs8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VW5saWtl IGEmbmJzcDsgJmx0O2NvcHktY29uZmlnJmd0OyBvcGVyYXRpb24sIHdoaWNoIHJlcGxhY2VzIHRo ZSBlbnRpcmUgdGFyZ2V0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2NvbmZpZ3VyYXRpb24sIG9ubHkgdGhlIGNvbmZpZ3VyYXRpb24gYWN0 dWFsbHkgcHJlc2VudCBpbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDt0aGUgJmx0O2NvbmZpZyZndDsgcGFyYW1ldGVyIGlzIGFmZmVjdGVk Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEluIG90aGVyIHdvcmRzLCB0aGUgJmx0O3JlcGxhY2UmZ3Q7 IG9ubHkgcmVwbGFjZXMgdGhlIGRhdGEgbm9kZXMgdGhhdCBleGlzdDxicj4NCiZndDsgaW4gdGhl IHRhcmdldCBhbmQgZm9yIG5vZGVzIHRoYXQgYXJlIGluICZsdDtjb25maWcmZ3Q7IGluIHRoZTxi cj4NCiZndDsgJmx0O2VkaXQtY29uZmlnJmd0O2J1dCBub3QgaW4gdGhlIHRhcmdldCwgdGhleSBh cmUgY3JlYXRlZC4gT3RoZXIgbm9kZXMgdGhhdDxicj4NCiZndDsgZXhpc3QgaW4gdGhlIGRldmlj ZSBidXQgYXJlIG5vdCBwcmVzZW50IGluIHRoZSAmbHQ7Y29uZmlnJmd0OyBvZiB0aGU8YnI+DQom Z3Q7ICZsdDtlZGl0LWNvbmZpZyZndDsgYXJlIE5PVCBhZmZlY3RlZCBpbiBhbnkgd2F5ICh0aGlz IGlzIHRoZSBrZXkgZGlmZmVyZW5jZTxicj4NCiZndDsgd2l0aCAmbHQ7Y29weS1jb25maWcmZ3Q7 LCB3aGVyZSB0aGV5IGFyZSByZW1vdmVkIGJlY2F1c2UgaXQgb3BlcmF0ZXMgb24gdGhlPGJyPg0K Jmd0OyAqZW50aXJlKiBkYXRhc3RvcmUuKTxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgQnV0IGNh biByZXBsYWNlIG9mIHRoZSBlbnRpcmUgY29udGVudHMgYmUgZG9uZSB3aXRob3V0IHJlcGxhY2Ug YXM8YnI+DQomZ3Q7ICZndDsgdGhlPGJyPg0KJmd0OyBkZWZhdWx0PGJyPg0KJmd0OyAmZ3Q7IG9w ZXJhdGlvbiA/PGJyPg0KJmd0Ozxicj4NCiZndDsgTm90IHdpdGggdGhlIGRlZmF1bHQgJnF1b3Q7 cmVwbGFjZSZxdW90OyBvcGVyYXRpb24sIG5vciB3aXRoIHRoZSBub3JtYWw8YnI+DQomZ3Q7ICZx dW90O3JlcGxhY2UmcXVvdDs8YnI+DQomZ3Q7IG9wZXJhdGlvbi48YnI+DQomZ3Q7IFRoZSBkZWZh dWx0ICZxdW90O3JlcGxhY2UmcXVvdDsgb3BlcmF0aW9uIGhhcyBubyBhZGRpdGlvbmFsIHNlbWFu dGljcyBjb21wYXJlZDxicj4NCiZndDsgdG8gVGhlICZxdW90O29wZXJhdGlvbiZxdW90OyBwYXJh bWV0ZXI8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE9yIGRlbGV0ZSBvZiB0aGUgZW50aXJlIGNv bnRlbnRzID8mbmJzcDsgVGhlIFJGQyBkb2Vzbid0IHNlZW0gdG8gY2xlYXIgb248YnI+DQomZ3Q7 ICZndDsgd2hldGhlciB3ZSBjYW4gdXNlIGFuIG9wZXJhdGlvbiBvbiB0aGUgJmx0O2NvbmZpZyZn dDsgbm9kZTo8YnI+DQomZ3Q7ICZndDsgJmx0O2NvbmZpZyBvcGVyYXRpb249JnF1b3Q7ZGVsZXRl JnF1b3Q7LyZndDs8YnI+DQomZ3Q7ICZndDsgJmx0O2NvbmZpZyBvcGVyYXRpb249JnF1b3Q7cmVw bGFjZSZxdW90Oy8mZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBkZXNjcmlw dGlvbiBvZiAmbHQ7ZWRpdC1jb25maWcmZ3Q7IHNheXM6IHRoZSB0YXJnZXQgY29uZmlndXJhdGlv biBpcyBub3Q8YnI+DQomZ3Q7IG5lY2Vzc2FyaWx5IHJlcGxhY2VkLCBhcyB3aXRoIHRoZSAmbHQ7 Y29weS1jb25maWcmZ3Q7IG1lc3NhZ2UuJm5ic3A7IEluc3RlYWQsIHRoZTxicj4NCiZndDsgdGFy Z2V0IGNvbmZpZ3VyYXRpb24gaXMgY2hhbmdlZCBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIHNvdXJj ZSdzIGRhdGE8YnI+DQomZ3Q7IGFuZCByZXF1ZXN0ZWQgb3BlcmF0aW9ucy48YnI+DQomZ3Q7PGJy Pg0KJmd0OyBJbiBvdGhlciB3b3JkcywgdGhlICZsdDtjb25maWcmZ3Q7IHBhcmFtZXRlciBpbiAm bHQ7ZWRpdC1jb25maWcmZ3Q7IHdpbGwgbm90IGJlPGJyPg0KJmd0OyB2YWxpZCBpZiB5b3UgZG8g bm90IHNwZWNpZnkgaXQgKGFzc3VtaW5nIG5vIHVybCBjYXBhYmlsaXR5KSBvciBtYWtlIGl0PGJy Pg0KJmd0OyBlbXB0eSwgYXMgaW4geW91ciBleGFtcGxlLjxicj4NCiZndDs8YnI+DQomZ3Q7IGNv bmZpZzombmJzcDsgQSBoaWVyYXJjaHkgb2YgY29uZmlndXJhdGlvbiBkYXRhIGFzIGRlZmluZWQg Ynkgb25lIG9mPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhl IGRldmljZSdzIGRhdGEgbW9kZWxzLiZuYnNwOyBUaGUgY29udGVudHMgTVVTVCBiZSBwbGFjZWQg aW4gYW48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhcHByb3By aWF0ZSBuYW1lc3BhY2UsIHRvIGFsbG93IHRoZSBkZXZpY2UgdG8gZGV0ZWN0IHRoZTxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGFwcHJvcHJpYXRlIGRhdGEgbW9k ZWwsIGFuZCB0aGUgY29udGVudHMgTVVTVCBmb2xsb3cgdGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY29uc3RyYWludHMgb2YgdGhhdCBkYXRhIG1vZGVsLCBh cyBkZWZpbmVkIGJ5IGl0cyBjYXBhYmlsaXR5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgZGVmaW5pdGlvbi48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsg Jmd0OyAoYykgYW5kIChkKSBoYXZlIGEgZGVsZXRlIG9wZXJhdGlvbiBvbiBhIGxlYWYgKGluIChj KSBpcyBpdDxicj4NCiZndDsgJmd0OyBpbmhlcml0ZWQpIGJ1dDxicj4NCiZndDsgYXJlPGJyPg0K Jmd0OyAmZ3Q7IHByb3ZpZGluZyBhIHZhbHVlIGZvciB0aGUgbGVhZiBhdCB0aGUgc2FtZSB0aW1l LiBXaGF0IGlzIHRoZSBtZWFuaW5nPGJyPg0KJmd0OyAmZ3Q7IG9mPGJyPg0KJmd0OyB0aGU8YnI+ DQomZ3Q7ICZndDsgdmFsdWUgPyBUaGF0IHNlZW1zIGxpa2UgYW4gZXJyb3IgdG8gbWUuJm5ic3A7 IFdlIHNob3VsZCB3YXJuIHRoZSBjbGllbnQ8YnI+DQomZ3Q7ICZndDsgdGhhdCB0aGV5J3ZlIGRv bmUgc29tZXRoaW5nIHVuZXhwZWN0ZWQgKHRoZSBjbGllbnQgbWF5IGhhdmUgYmVlbjxicj4NCiZn dDsgJmd0OyBpbnRlbmRpbmcgdG8gZG8gc29tZXRoaW5nIGRpZmZlcmVudCB0aGFuIGRlbGV0aW5n IHRoYXQgbGVhZikuPGJyPg0KJmd0OyAmZ3Q7IEkgY2FuIHNlZSBob3cgdGhhdCB3b3JrcyB3aGVu IHRoZSBsZWFmIGlzIGEga2V5IGxlYWYgaW4gYSBsaXN0LiZuYnNwOyBCdXQ8YnI+DQomZ3Q7ICZn dDsgaXQ8YnI+DQomZ3Q7IHNlZW1zIGxpa2U8YnI+DQomZ3Q7ICZndDsgYW4gZXJyb3IgZm9yIGp1 c3QgYSBwbGFpbiBsZWFmLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBOby4gSSB0aGlu ayB0aGUgdmFsdWUgaXMgYWN0dWFsbHkgdXNlZCBieSAmbHQ7ZWRpdC1jb25maWcmZ3Q7LiBGb3Ig ZXhhbXBsZSw8YnI+DQomZ3Q7IFJGQzYyNDE8YnI+DQomZ3Q7IGhhcyB0aGlzIGV4YW1wbGU6PGJy Pg0KJmd0Ozxicj4NCiZndDsgRGVsZXRlIHRoZSBjb25maWd1cmF0aW9uIGZvciBhbiBpbnRlcmZh Y2UgbmFtZWQgJnF1b3Q7RXRoZXJuZXQwLzAmcXVvdDsgZnJvbTxicj4NCiZndDsmbmJzcDsgJm5i c3A7IHRoZSBydW5uaW5nIGNvbmZpZ3VyYXRpb246PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbHQ7cnBjIG1lc3NhZ2UtaWQ9JnF1b3Q7MTAxJnF1b3Q7PGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7eG1sbnM9JnF1b3Q7dXJu OmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wJnF1b3Q7Jmd0Ozxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O2VkaXQtY29uZmlnJmd0Ozxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDt0YXJnZXQmZ3Q7PGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtydW5uaW5nLyZn dDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7L3Rhcmdl dCZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7ZGVm YXVsdC1vcGVyYXRpb24mZ3Q7bm9uZSZsdDsvZGVmYXVsdC1vcGVyYXRpb24mZ3Q7PGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O2NvbmZpZyB4bWxuczp4Yz0m cXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAmcXVvdDsmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDt0b3Ag eG1sbnM9JnF1b3Q7PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS8xLjIvY29uZmln IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS8xLjIvY29uZmlnPC9h PiZxdW90OyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZsdDtpbnRlcmZhY2UgeGM6b3BlcmF0aW9uPSZxdW90O2RlbGV0ZSZxdW90 OyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbHQ7bmFtZSZndDtFdGhlcm5ldDAvMCZsdDsvbmFtZSZndDs8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDsv aW50ZXJmYWNlJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbHQ7L3RvcCZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbHQ7L2NvbmZpZyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZsdDsvZWRpdC1jb25maWcmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZs dDsvcnBjJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBXaXRob3V0IHNwZWNpZnlp bmcgdmFsdWUgc28gdGhhdCB0aGUgZGV2aWNlIGNhbiBmaW5kIGFuIGV4YWN0IG1hdGNoZWQ8YnI+ DQomZ3Q7IGludGVyZmFjZSwgdGhpcyB3b24ndCB3b3JrLjxicj4NCiZndDs8YnI+DQomZ3Q7IElu IG90aGVyIHdvcmRzLCBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgaWYgYSB2YWx1ZSBpcyBnaXZl biwgYW5kIHRoZTxicj4NCiZndDsgZGV2aWNlPGJyPg0KJmd0Ozxicj4NCiZndDsgY2FuJ3QgZmlu ZCBhIG1hdGNoIHRoZW4gdGhlbiB0aGUgZGVsZXRlIHdpbGwgZmFpbCB3aXRoIGE8YnI+DQomZ3Q7 ICZsdDtkYXRhLW1pc3NpbmcmZ3Q7IGVycm9yLjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgSSdt IGFsc28gbm90IGNvbnZpbmNlZCBhYm91dCAoZikgYW5kIChnKS4mbmJzcDsgV3J0IHlvdXIgYW5h bG9neSBvZiBhPGJyPg0KJmd0OyAmZ3Q7IGRpcmVjdG9yeTxicj4NCiZndDsgd2l0aDxicj4NCiZn dDsgJmd0OyBmaWxlczogeW91IGNhbiBkZWxldGUgYSBjb250YWluZXIgaW4gTkVUQ09ORiBhbmQg dGhhdCBhdXRvbWF0aWNhbGx5PGJyPg0KJmd0OyBkZWxldGVzPGJyPg0KJmd0OyAmZ3Q7IGFueSBj aGlsZHJlbiwgZ3JhbmRjaGlsZHJlbiBhbmQgc28gb24gKHRoZSBlbnRpcmUgc3VidHJlZSkuJm5i c3A7IEl0PGJyPg0KJmd0OyAmZ3Q7IHNlZW1zPGJyPg0KJmd0OyBzdHJhbmdlPGJyPg0KJmd0OyAm Z3Q7IHRoYXQgdGhlcmUgaXMgbm8gd2F5IHRvIGRlbGV0ZSAob3IgcmVwbGFjZSkgdGhlIGVudGly ZSBjb250ZW50cyBvZiBhPGJyPg0KJmd0OyAmZ3Q7IGxpc3Q8YnI+DQomZ3Q7IG9yIGxlYWYtPGJy Pg0KJmd0OyAmZ3Q7IGxpc3QuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBkb24ndCBuZWNlc3Nhcmls eSBkaXNhZ3JlZSB3aXRoIHlvdSBvbiB0aGlzIG9uZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHdh cyBzaW1wbHkgc3VnZ2VzdGluZyB0aGF0IHRoZSBwcm90b2NvbCBwZXJoYXBzIHNob3VsZCBoYXZl IGEgc2ltcGxlPGJyPg0KJmd0OyB3YXkgdG8gYWxsb3cgbWUgdG8gcmVtb3ZlIGxpc3QgZW50cmll cy4gSW4gcGFydGljdWxhciBJIHRoaW5rIGl0IHdvdWxkPGJyPg0KJmd0OyBiZSB1c2VmdWwgaXQg YWxsb3dzOjxicj4NCiZndDsgMSkgdG8gZGVsZXRlIGEgc3BlY2lmaWMgbGlzdCBlbnRyeSBieSBw cm92aWRpbmcgYSBsaXN0IGVudHJ5J3M8YnI+DQomZ3Q7IEluc3RhbmNlIElEICggYWxsIGtleSBu b2RlcyBhbmQgY29ycmVzcG9uZGluZyB2YWx1ZXMpLjxicj4NCiZndDsgMikgdG8gZGVsZXRlIGFs bCBlbnRyaWVzIG9mIGEgbGlzdCBieSBqdXN0IHByb3ZpZGluZyBhbGwga2V5IG5vZGVzIGluPGJy Pg0KJmd0OyB0aGUgJmx0O2NvbmZpZyZndDsuPGJyPg0KJmd0Ozxicj4NCiZndDsgQmVzdCw8YnI+ DQomZ3Q7IC0tWGlhbmc8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICZn dDsgT3IgcGVyaGFwcyBJJ20gbWlzaW50ZXJwcmV0aW5nIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUg cmVwbGFjZSBhbmQ8YnI+DQomZ3Q7ICZndDsgZGVsZXRlIG9wZXJhdGlvbnMgaW4gUkZDNjI0MSAo dGhlIHNlbnRlbmNlcyAmcXVvdDtvbmx5IHRoZSBjb25maWd1cmF0aW9uPGJyPg0KJmd0OyAmZ3Q7 IGFjdHVhbGx5IHByZXNlbnQgaW4gdGhlICZsdDtjb25maWcmZ3Q7IHBhcmFtZXRlciBpcyBhZmZl Y3RlZCZxdW90OyBhbmQgJnF1b3Q7aWYgYW5kPGJyPg0KJmd0OyAmZ3Q7IG9ubHkgaWYgdGhlIGNv bmZpZ3VyYXRpb24gZGF0YSBjdXJyZW50bHkgZXhpc3RzJnF1b3Q7IGFyZSBnaXZpbmcgbWUgc29t ZTxicj4NCiZndDsgJmd0OyBwYXVzZSBoZXJlKS48YnI+DQomZ3Q7IFRoZXJlPGJyPg0KJmd0OyAm Z3Q7IGFyZW4ndCBtYW55IGV4YW1wbGVzIGlsbHVzdHJhdGluZyBkZWxldGUgJmFtcDsgcmVwbGFj ZSBpbiB0aGUgUkZDLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBSZWdhcmRzLDxicj4N CiZndDsgJmd0OyBKYXNvbjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyBGcm9tOiBFWFQgWGlhbmcgTGkgW21haWx0 bzo8YSBocmVmPSJtYWlsdG86eGlhbmdsaUBzZWd1ZXNvZnQuY29tIj54aWFuZ2xpQHNlZ3Vlc29m dC5jb208L2E+XTxicj4NCiZndDsgJmd0OyBTZW50OiBGcmlkYXksIEFwcmlsIDI5LCAyMDE2IDIw OjA1PGJyPg0KJmd0OyAmZ3Q7IFRvOiBTdGVybmUsIEphc29uIChOb2tpYSAtIENBKTsgJ01hcnRp biBCam9ya2x1bmQnOzxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86d2l2b3J5QEJyb2Nh ZGUuY29tIj53aXZvcnlAQnJvY2FkZS5jb208L2E+PGJyPg0KJmd0OyAmZ3Q7IENjOiA8YSBocmVm PSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7 ICZndDsgU3ViamVjdDogUkU6IFtOZXRjb25mXSBDbGFyaWZpY2F0aW9uIHJlcXVlc3QgZm9yIE5F VENPTkYgZWRpdC1jb25maWc8YnI+DQomZ3Q7IGRlZmF1bHQtPGJyPg0KJmd0OyAmZ3Q7IG9wZXJh dGlvbiByZXBsYWNlPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7 IEZyb206IE5ldGNvbmYgW21haWx0bzo8YSBocmVmPSJtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGll dGYub3JnIj5uZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgU3Rlcm5l LDxicj4NCiZndDsgJmd0OyBKYXNvbiAoTm9raWEgLSBDQSk8YnI+DQomZ3Q7ICZndDsgU2VudDog RnJpZGF5LCBBcHJpbCAyOSwgMjAxNiAyOjEyIFBNPGJyPg0KJmd0OyAmZ3Q7IFRvOiBNYXJ0aW4g QmpvcmtsdW5kICZsdDs8YSBocmVmPSJtYWlsdG86bWJqQHRhaWwtZi5jb20iPm1iakB0YWlsLWYu Y29tPC9hPiZndDs7IDxhIGhyZWY9Im1haWx0bzp3aXZvcnlAQnJvY2FkZS5jb20iPg0Kd2l2b3J5 QEJyb2NhZGUuY29tPC9hPjxicj4NCiZndDsgJmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOm5ldGNv bmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6 IFJlOiBbTmV0Y29uZl0gQ2xhcmlmaWNhdGlvbiByZXF1ZXN0IGZvciBORVRDT05GIGVkaXQtY29u ZmlnPGJyPg0KJmd0OyBkZWZhdWx0LTxicj4NCiZndDsgJmd0OyBvcGVyYXRpb24gcmVwbGFjZTxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJcyB0aGVyZSBubyB3YXkgdG8gZGVsZXRlIHRo ZSBlbnRpcmUgY29udGVudHMgb2YgdGhlIGRhdGFzdG9yZTxicj4NCiZndDsgJmd0OyB3aXRob3V0 PGJyPg0KJmd0OyBoYXZpbmc8YnI+DQomZ3Q7ICZndDsgdG8gZXhwbGljaXRseSBsaXN0IGV2ZXJ5 IHNpbmdsZSB0b3AgbGV2ZWwgbm9kZSA/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IGUu Zy48YnI+DQomZ3Q7ICZndDsgd2l0aCBubyBkZWZhdWx0IG9wZXJhdGlvbiAoaS5lLiBtZXJnZSk6 PGJyPg0KJmd0OyAmZ3Q7ICZsdDtjb25maWcgb3BlcmF0aW9uPSZxdW90O2RlbGV0ZSZxdW90Oy8m Z3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE9yPGJyPg0KJmd0OyAmZ3Q7IFdpdGgg ZGVmYXVsdCBvcGVyYXRpb24gPSBkZWxldGU6PGJyPg0KJmd0OyAmZ3Q7ICZsdDtjb25maWcvJmd0 Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBTaW1pbGFybHkgLSZndDsgSXMgdGhlcmUg bm8gd2F5IHRvIHJlcGxhY2UgdGhlIGVudGlyZSBjb250ZW50cyBvZiB0aGU8YnI+DQomZ3Q7IGRh dGFzdG9yZSA/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFtYTF0gSSB0aGluayZsdDsg Y29weS1jb25maWcmZ3Q7IG9yICZsdDtkZWxldGUtY29uZmlnJmd0OyBjYW4gZG8gdGhpcy48YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQWJvdXQgdGhlIGNhc2VzIGJlbG93IHNob3VsZG4n dCAoYykgYW5kIChkKSByZXR1cm4gYW4gZXJyb3IgPyZuYnNwOyBUaGV5PGJyPg0KJmd0OyBjb250 YWluPGJyPg0KJmd0OyAmZ3Q7IGRhdGEgZm9yIGFuIG9iamVjdCB0aGF0IGlzIGJlaW5nIGRlbGV0 ZWQuJm5ic3A7IChlKSBzZWVtcyBsaWtlIHRoZTxicj4NCiZndDsgJmd0OyBjb3JyZWN0IHdheTxi cj4NCiZndDsgdG8gZG88YnI+DQomZ3Q7ICZndDsgaXQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7IFtYTF0gSSB0aGluayBNYXJ0aW4ncyBleHBsYW5hdGlvbiBpcyBjb3JyZWN0LiBNeSB1 bmRlcnN0YW5kaW5nIGlzPGJyPg0KJmd0OyAmZ3Q7IHRoYXQgaWY8YnI+DQomZ3Q7IHRoZTxicj4N CiZndDsgJmd0OyB2YWx1ZSBkb2VzIG5vdCBtYXRjaCwgdGhlbiB0aGUgJmx0O2RlbGV0ZSZndDsg d291bGQgcmV0dXJuIGFuIGVycm9yIHNpbmNlPGJyPg0KJmd0OyAmZ3Q7IHRoZSBubyBtYXRjaGlu ZyBkYXRhIG5vZGUgZm91bmQgKHllcyBJIHZpZXcgdGhpcyBhcyBhIGNvbnRlbnQtbWF0Y2gpLjxi cj4NCiZndDsgJmd0OyBPciBJIG1pZ2h0PGJyPg0KJmd0OyBiZTxicj4NCiZndDsgJmd0OyB0b3Rh bGx5IHdyb25nIGhlcmUsIGkuZS4sIHRoZSB2YWx1ZSBkb2VzIG5vdCBtYXR0ZXIgaW4gYW55IHdh eSBhczxicj4NCiZndDsgJmd0OyBNYXJ0aW48YnI+DQomZ3Q7IHNhaWQ/PGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7IChmKSBhbmQgKGcpIHN1cnByaXNlIG1lLiZuYnNwOyBJZiBJIGNhbiAm bHQ7Z2V0LWNvbmZpZyZndDsgYW4gZW50aXJlIGxlYWYtbGlzdDxicj4NCiZndDsgJmd0OyBvcjxi cj4NCiZndDsgbGlzdCBieSBqdXN0PGJyPg0KJmd0OyAmZ3Q7IHNwZWNpZnlpbmcgdGhlIHRhZyBm b3IgdGhlIGxlYWYtbGlzdC9saXN0IG5hbWUsIHdoeSBkb2Vzbid0IGRlbGV0ZTxicj4NCiZndDsg Jmd0OyBnZXQgcmlkPGJyPg0KJmd0OyBvZiB0aGU8YnI+DQomZ3Q7ICZndDsgZW50aXJlIGxlYWYt bGlzdC9saXN0ID88YnI+DQomZ3Q7ICZndDsgKGlmIHlvdSBzcGVjaWZ5IGEgc3BlY2lmaWMgbGlz dCBlbnRyeS9tZW1iZXIgaW4gYSBkZWxldGUgaXQgaXM8YnI+DQomZ3Q7ICZndDsgYmFzaWNhbGx5 PGJyPg0KJmd0OyBqdXN0IGE8YnI+DQomZ3Q7ICZndDsgY29udGVudCBtYXRjaCBub2RlIGJ1dCBv dGhlcndpc2UgeW91J3ZlIHNlbGVjdGVkIHRoZSBlbnRpcmUgbGlzdCBubzxicj4NCiZndDsgJmd0 OyA/KS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgW1hMXSBJIGFsc28gdGhvdWdodCB0 aGF0IEkgY2FuIGRlbGV0ZSBhIGxpc3QgZW50cnkgYnkgc3BlY2lmeWluZzxicj4NCiZndDsgJmd0 OyBhbGwga2V5PGJyPg0KJmd0OyBub2Rlczxicj4NCiZndDsgJmd0OyBhbmQgdGhlaXIgdmFsdWVz IChpLmUuLCBsaXN0IGVudHJ5J3MgaW5zdGFuY2UgSUQpLiBJZiBubyB2YWx1ZXMgb2Y8YnI+DQom Z3Q7ICZndDsga2V5PGJyPg0KJmd0OyBub2RlcyBhcmU8YnI+DQomZ3Q7ICZndDsgZ2l2ZW4sIHRo ZW4gdGhlIGVudGlyZSBsaXN0IGVudHJpZXMgbWF0Y2hlZCBhbmQgYWxsIG9mIHRoZW0gc2hvdWxk PGJyPg0KJmd0OyAmZ3Q7IGJlPGJyPg0KJmd0OyBkZWxldGVkLjxicj4NCiZndDsgJmd0OyBBbHRo b3VnaCBNYXJ0aW4ncyBleHBsYW5hdGlvbiBhbHNvIG1ha2VzIHNlbnNlIGhlcmUsIHRoYXQgaXMs IHlvdTxicj4NCiZndDsgJmd0OyBjYW4ndDxicj4NCiZndDsganVzdDxicj4NCiZndDsgJmd0OyBk ZWxldGUgYSBrZXkgbm9kZSB5ZXQgaWYgaXQgaXMgc3RpbGwgdXNlZCBieSBub24ta2V5IG5vZGVz Ljxicj4NCiZndDsgJmd0OyBKdXN0IGxpa2UgZGVsZXRpbmcgYSBkaXJlY3Rvcnkgd2hlbiB0aGUg ZGlyZWN0b3J5IHN0aWxsIGNvbnRhaW5zPGJyPg0KJmd0OyAmZ3Q7IGZpbGVzLjxicj4NCiZndDsg QnV0LCBpbiBhbnk8YnI+DQomZ3Q7ICZndDsgY2FzZSwmbmJzcDsgSSB3b3VsZCBzdGlsbCBsaWtl IHRoYXQgSSBjYW4gZGVsZXRlIGEgbGlzdCBlbnRyeSBieSBnaXZpbmc8YnI+DQomZ3Q7ICZndDsg dGhlPGJyPg0KJmd0OyBsaXN0IGVudHJ5J3MgSUlEPGJyPg0KJmd0OyAmZ3Q7IHNpbmNlIHdlIGNh biB1bm1pc3Rha2FibHkgaWRlbnRpZnkmbmJzcDsgYSBsaXN0IGVudHJ5IGJ5IGdpdmVuIGEgbGlz dDxicj4NCiZndDsgJmd0OyBlbnRyeSdzPGJyPg0KJmd0OyBJSUQgKGkuZS4gLDxicj4NCiZndDsg Jmd0OyBhbGwga2V5IG5vZGVzIGFuZCB0aGVpciBjb3JyZXNwb25kaW5nIHZhbHVlcykuJm5ic3A7 IEkgdGhpbmsgc3VjaCBhPGJyPg0KJmd0OyAmZ3Q7IGRlbGV0ZSBvcGVyYXRpb24gd291bGQgYmUg dXNlZnVsLCZuYnNwOyBqdXN0IGxpa2UgJnF1b3Q7cm0gLXJmIGRpcmVjdG9yeSZxdW90Oy48YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgLS1YaWFuZzxicj4NCiZndDsgJmd0OyAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyBGcm9tOiBOZXRjb25mIFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyI+bmV0Y29uZi1ib3VuY2Vz QGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIE1hcnRpbjxicj4NCiZndDsgJmd0OyBCam9ya2x1 bmQ8YnI+DQomZ3Q7ICZndDsgU2VudDogRnJpZGF5LCBBcHJpbCAxNSwgMjAxNiAxMDo0OTxicj4N CiZndDsgJmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOndpdm9yeUBCcm9jYWRlLmNvbSI+d2l2b3J5 QEJyb2NhZGUuY29tPC9hPjxicj4NCiZndDsgJmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOm5ldGNv bmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6 IFJlOiBbTmV0Y29uZl0gQ2xhcmlmaWNhdGlvbiByZXF1ZXN0IGZvciBORVRDT05GIGVkaXQtY29u ZmlnPGJyPg0KJmd0OyBkZWZhdWx0LTxicj4NCiZndDsgJmd0OyBvcGVyYXRpb24gcmVwbGFjZTxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBXaWxsaWFtIEl2b3J5ICZsdDs8YSBocmVmPSJt YWlsdG86d2l2b3J5QEJyb2NhZGUuY29tIj53aXZvcnlAQnJvY2FkZS5jb208L2E+Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyBPSyAtIEkgdGhpbmsgaXQgbWlnaHQgaGVscCBpZiBJIGdh dmUgc29tZSBzcGVjaWZpYyBleGFtcGxlcywgd2l0aDxicj4NCiZndDsgJmd0OyAmZ3Q7IG15IHVu ZGVyc3RhbmRpbmcgb2Ygd2hhdCB3b3VsZCBnZXQgZGVsZXRlZCBhbmQgeW91IGNhbiB0ZWxsIG1l IGlmPGJyPg0KJmd0OyAmZ3Q7ICZndDsgSSdtIGNvcnJlY3Qgb3Igbm90LiZuYnNwOyBBcG9sb2dp ZXMgZm9yIGxlbmd0aCwgYnV0IEknZCBsaWtlIHRvIGF2b2lkPGJyPg0KJmd0OyAmZ3Q7ICZndDsg YW55IGNvbmZ1c2lvbiBieSBub3Qgc3BlbGxpbmcgb3V0IG15IHF1ZXJpZXMsIGFuZCBJJ20gc3Ry dWdnbGluZzxicj4NCiZndDsgJmd0OyAmZ3Q7IHRvIGdldCBhIGNsZWFyIHBpY3R1cmUgb2YgaG93 IHRoaXMgYWxsIHdvcmtzIHdpdGggYWxsIHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7IGRpZmZlcmVu dCBwZXJtdXRhdGlvbnMhPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBM ZXQncyB0YWtlIGEgY29uZmlndXJhdGlvbiBsaWtlIHRoaXM6PGJyPg0KJmd0OyAmZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmbHQ7dG9wQ29udCZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2FMZWFmJmd0O2xlYWZWYWx1ZSZsdDsvYUxlYWYmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDthTGVhZkxpc3RFbnRyeSZn dDtsZWFmbGlzdFZhbHVlT25lJmx0Oy9hTGVhZkxpc3RFbnRyeSZndDs8YnI+DQomZ3Q7ICZndDsg Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2FMZWFmTGlzdEVudHJ5Jmd0O2xlYWZsaXN0VmFs dWVUd28mbHQ7L2FMZWFmTGlzdEVudHJ5Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsmbHQ7YUxpc3RFbnRyeSZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7bGlzdEtleSZndDtmaXJzdEVudHJ5S2V5Jmx0 Oy9saXN0S2V5Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZsdDtsaXN0TGVhZiZndDtmaXJzdEVudHJ5TGVhZiZsdDsvbGlzdExlYWYmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsvYUxpc3RFbnRyeSZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2FMaXN0RW50cnkm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmx0O2xpc3RLZXkmZ3Q7c2Vjb25kRW50cnlLZXkmbHQ7L2xpc3RLZXkmZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2xpc3RMZWFmJmd0 O3NlY29uZEVudHJ5TGVhZiZsdDsvbGlzdExlYWYmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyZsdDsvYUxpc3RFbnRyeSZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm bHQ7L3RvcENvbnQmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAt LS08YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IChhKSB0b3BDb250LCBk ZWZhdWx0IG9wZXJhdGlvbiBkZWxldGU8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyAmZ3Q7IFdpdGggdGhlIGRlZmF1bHQgb3BlcmF0aW9uIHNldCB0byBkZWxldGU6PGJyPg0KJmd0 OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbHQ7Y29uZmlnJmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7dG9wQ29udCZndDs8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmbHQ7L2NvbmZpZyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyAmZ3Q7ID0mZ3Q7IHRvcENvbnQsIGFuZCBldmVyeXRoaW5nIHVuZGVyIGl0LCB3b3VsZCBiZSBk ZWxldGVkPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFllcy48YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyAoYikgdG9wQ29udCwgb3BlcmF0aW9uIGRlbGV0ZTxicj4NCiZn dDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgV2l0aCB0aGUgZGVmYXVsdCBvcGVyYXRp b24gc2V0IHRvIG5vbmU6PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm bHQ7Y29uZmlnJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7 dG9wQ29udCB4YzpvcGVyYXRpb249ZGVsZXRlJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZsdDsv Y29uZmlnJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPSZndDsg dG9wQ29udCwgYW5kIGV2ZXJ5dGhpbmcgdW5kZXIgaXQsIHdvdWxkIGJlIGRlbGV0ZWQ8YnI+DQom Z3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBZZXMuPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgJmd0OyAoYykgYUxlYWYgZGVsZXRlLCBvcGVyYXRpb24gc3BlY2lmaWVkIGZvciB0 b3BDb250PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBXaXRoIHRoZSBk ZWZhdWx0IG9wZXJhdGlvbiBzZXQgdG8gbm9uZTo8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZsdDtjb25maWcmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyZsdDt0b3BDb250IHhjOm9wZXJhdGlvbj1kZWxldGUmZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2FMZWFmJmd0O2xl YWZWYWx1ZSZsdDsvYUxlYWYmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmx0Oy9jb25maWcmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyA9Jmd0OyBXaWxsIGRlbGV0 ZSBhTGVhZiBub2RlLiZuYnNwOyBJZiB0aGlzIGxlYXZlcyB0b3BDb250IGVtcHR5LCB0aGVuPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgdG9wQ29udCB3b3VsZCBiZSByZW1vdmVkLiZuYnNwOyBJZiB0b3BD b250IHN0aWxsIGNvbnRhaW5zIG90aGVyPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZWxlbWVudHMsIHRv cENvbnQgd291bGQgcmVtYWluPzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBOby4mbmJz cDsgVGhpcyBkZWxldGVzIHRoZSB0b3BDb250IGFuZCBldmVyeXRoaW5nIGJlbG93IGl0Ljxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IC0tLTxicj4NCiZndDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgKGQpIGFMZWFmIGRlbGV0ZSwgb3BlcmF0aW9uIHNwZWNpZmllZCBm b3IgYUxlYWY8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFdpdGggdGhl IGRlZmF1bHQgb3BlcmF0aW9uIHNldCB0byBub25lOjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmx0O2NvbmZpZyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7Jmx0O3RvcENvbnQmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2FMZWFmIHhjOm9wZXJhdGlvbj1kZWxldGUmZ3Q7 bGVhZlZhbHVlJmx0Oy9hTGVhZiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbHQ7L2NvbmZpZyZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ID0mZ3Q7IFdpbGwgZGVs ZXRlIGFMZWFmIG5vZGUuJm5ic3A7IElmIHRoaXMgbGVhdmVzIHRvcENvbnQgZW1wdHksIHRoZW48 YnI+DQomZ3Q7ICZndDsgJmd0OyB0b3BDb250IHdvdWxkIGJlIHJlbW92ZWQgdW5sZXNzIGl0IGlz IGEgcHJlc2VuY2Ugbm9kZS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgWWVzJm5ic3A7 IChzL3dvdWxkL21heS8pPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgLS0tPGJy Pg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAoZSkgYUxlYWYgZGVsZXRlLCBv cGVyYXRpb24gc3BlY2lmaWVkIGZvciBhTGVhZiwgYnV0IG5vIHZhbHVlPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgZ2l2ZW48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFdpdGgg dGhlIGRlZmF1bHQgb3BlcmF0aW9uIHNldCB0byBub25lOjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmx0O2NvbmZpZyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7Jmx0O3RvcENvbnQmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2FMZWFmIHhjOm9wZXJhdGlvbj1kZWxldGUv Jmd0OyAmbHQ7L2NvbmZpZyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAm Z3Q7ID0mZ3Q7IFdvdWxkIHRoaXMgZGVsZXRlIGFMZWFmLCBhbmQsIGFzIHBlciAoZCksIGNvbmRp dGlvbmFsbHk8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbHQ7dG9wQ29udCZndDssIG9yIG11c3QgdGhl IHZhbHVlIG9mIHRoZSBsZWFmIGJlIHNwZWNpZmllZD88YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBZZXMsIHRoaXMgd291bGQgZGVsZXRlIGFMZWFmLiZu YnNwOyBUaGUgdmFsdWUgZG9lc24ndCBtYXR0ZXIuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsgLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAoZikg YUxlYWZMaXN0RW50cnk8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IElz IHRoZXJlIGEgd2F5IHRvIGRlbGV0ZSBhbGwgbGVhZmxpc3QgZW50cmllcyB3aXRob3V0IHNwZWNp Znlpbmc8YnI+DQomZ3Q7ICZndDsgJmd0OyB0aGVtIGluZGl2aWR1YWxseSwgZWc6PGJyPg0KJmd0 OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbHQ7YUxlYWZMaXN0RW50cnkgeGM6b3Bl cmF0aW9uPWRlbGV0ZSZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgTm88YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyAmZ3Q7IC4uLiBvciwgYXNzdW1pbmcgdGhlcmUgYXJlIG90aGVyIHNpYmxpbmcgbm9kZXMgc3Vj aCB0aGF0IHdlIGNhbid0PGJyPg0KJmd0OyAmZ3Q7ICZndDsganVzdCBkZWxldGUgdG9wQ29udCwg bXVzdCBJIHNwZWNpZnkgZWFjaCBpbmRpdmlkdWFsIGxlYWZsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZn dDsgZWxlbWVudCBJIHdpc2ggdG8gcmVtb3ZlPzxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAo ZykgYUxpc3RFbnRyeTxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgQXMg cGVyIGxlYWZsaXN0IGVudHJpZXMsIGlzIHRoZXJlIGEgd2F5IHRvIGRlbGV0ZSBhbGwgZW50cmll czxicj4NCiZndDsgJmd0OyAmZ3Q7IGdlbmVyaWNhbGx5PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7IE5vLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7LCBvciBtdXN0IGVh Y2ggYmUgc3BlY2lmaWVkPzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBZZXMuPGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgU2VwYXJhdGVseSwgaWYgSSBkZWxldGUgYSBu b24ta2V5IG5vZGUgaW5zaWRlIGEgbGlzdCBlbnRyeSwgSTxicj4NCiZndDsgJmd0OyAmZ3Q7IGFz c3VtZSB0aGF0IGp1c3QgZGVsZXRlcyB0aGF0IG5vZGUuJm5ic3A7IElmIEkgZGVsZXRlIHRoZSBs aXN0J3Mga2V5PGJyPg0KJmd0OyAmZ3Q7ICZndDsgbm9kZSwgdGhlbiBwcmVzdW1hYmx5IHRoYXQg cmVtb3ZlcyB0aGUgY29tcGxldGUgZW50cnksIGVnOjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmx0O2NvbmZpZyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7Jmx0O3RvcENvbnQmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2FMaXN0RW50cnkgeGM6b3BlcmF0aW9uPWRlbGV0 ZSZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZsdDtsaXN0S2V5Jmd0O2ZpcnN0RW50cnlLZXkmbHQ7L2xpc3RLZXkm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmx0Oy9hTGlzdEVudHJ5Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZsdDsvY29uZmlnJmd0Ozxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBZZXM8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgJmd0OyBXb3VsZCB0aGUgZm9sbG93aW5nIGFjaGlldmUgdGhlIHNhbWUsIGllIHJlbW92 YWwgb2YgdGhpcyBsaXN0IGVudHJ5Ojxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmx0O2NvbmZpZyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7Jmx0O3RvcENvbnQmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmx0O2FMaXN0RW50cnkgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2xpc3RLZXkg eGM6b3BlcmF0aW9uPWRlbGV0ZSAmZ3Q7Zmlyc3RFbnRyeUtleSZsdDsvbGlzdEtleSZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7L2FM aXN0RW50cnkmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmx0Oy9jb25maWcmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEhtbS4mbmJzcDsgSSB3b3VsZCBzYXkgdGhhdCB0aGlzIHJl c3VsdHMgaW4gYW4gZXJyb3IgLSBkZWxldGluZyBqdXN0IHRoZTxicj4NCiZndDsgJmd0OyBrZXkg b2Y8YnI+DQomZ3Q7IGEgbGlzdCBpczxicj4NCiZndDsgJmd0OyBub3QgcG9zc2libGUuPGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC9t YXJ0aW48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IC0tLTxicj4NCiZndDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhhbmtzJm5ic3A7IGZvciBiZWFyaW5nIHdpdGggbWUsPGJy Pg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBXaWxsaWFtPGJyPg0KJmd0OyAm Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCiZndDsgJmd0OyAmZ3Q7IEZyb206IE1hcnRpbiBCam9ya2x1bmQgW21haWx0bzo8YSBocmVm PSJtYWlsdG86bWJqQHRhaWwtZi5jb20iPm1iakB0YWlsLWYuY29tPC9hPl08YnI+DQomZ3Q7ICZn dDsgJmd0OyBTZW50OiAxNSBBcHJpbCAyMDE2IDEzOjQ0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgVG86 IFdpbGxpYW0gSXZvcnkgJmx0OzxhIGhyZWY9Im1haWx0bzp3aXZvcnlAQnJvY2FkZS5jb20iPndp dm9yeUBCcm9jYWRlLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgQ2M6IDxhIGhyZWY9 Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPjxicj4NCiZndDsg Jmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gQ2xhcmlmaWNhdGlvbiByZXF1ZXN0IGZv ciBORVRDT05GPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZWRpdC1jb25maWcgZGVmYXVsdC1vcGVyYXRp b24gcmVwbGFjZTxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgV2lsbGlh bSBJdm9yeSAmbHQ7PGEgaHJlZj0ibWFpbHRvOndpdm9yeUBCcm9jYWRlLmNvbSI+d2l2b3J5QEJy b2NhZGUuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBIaSBNYXJ0 aW4sPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhh bmtzIC0gSSB0aGluayB0aGF0IHRoZSBzZWN0aW9uIG9uICdyZXBsYWNlJyB1bmRlcjxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJ2RlZmF1bHQtb3BlcmF0aW9uJyBjb3VsZCBkbyB3aXRoIGJlaW5n IGNsYXJpZmllZCBuZXh0IHRpbWUgdGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBSRkMgaXMg dXBkYXRlZCB0aGVuLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IEknZCBhcHByZWNpYXRlIHNvbWUgZnVydGhlciBjbGFyaWZpY2F0aW9uIG9uIHdoYXQg ZXhhY3RseSAnIG9ubHk8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZSBjb25maWd1cmF0aW9u IGFjdHVhbGx5IHByZXNlbnQgaW4gdGhlICZsdDtjb25maWcmZ3Q7IHBhcmFtZXRlciBpczxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgYWZmZWN0ZWQnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBt ZWFucyBpbiBwcmFjdGljZS48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyBGaXJzdCwgdGhlIGdlbmVyYWwgcGF0dGVybiBvZiBleGFtcGxlcyB3aGljaCB1 c2U8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICdvcGVyYXRpb249Jmx0O29wZXJhdGlvbiZndDsn IGlzIHRoYXQgdGhpcyBjb21tYW5kIGlzIHB1dCBpbiB0aGUgJ3BhcmVudCc8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IGVsZW1lbnQncyB0YWcsIGllIHRoZSB0YWcgd2hpY2ggc3BlY2lmaWVzICdk ZWxldGUnIGlzICpub3QqIGRlbGV0ZWQuPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgJmd0OyBOby4mbmJzcDsgRm9yIGV4YW1wbGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2ludGVyZmFjZSB4YzpvcGVyYXRp b249JnF1b3Q7ZGVsZXRlJnF1b3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmx0O25hbWUmZ3Q7MTkyLjAuMi40Jmx0Oy9uYW1lJmd0Ozxicj4NCiZn dDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7L2ludGVyZmFjZSZndDs8YnI+DQom Z3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IHdpbGwgZGVsZXRlIHRoZSAmcXVvdDtp bnRlcmZhY2UmcXVvdDsgbm9kZSB3aXRoIHRoZSBuYW1lICZxdW90OzE5Mi4wLjIuNCZxdW90Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgSXQgZG9lcyBOT1Qga2VlcCB0 aGUgJnF1b3Q7aW50ZXJmYWNlJnF1b3Q7IG5vZGUgYW5kIGp1c3QgZGVsZXRlIHRoZSAmcXVvdDtu YW1lJnF1b3Q7IG5vZGUuPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7IEhvdyB0aGVuIHdvdWxkIHlvdSBkZWxldGUgYSB0b3AtbGV2ZWwgY29udGFpbmVyPzxicj4N CiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJmx0O215LXRvcC1sZXZl bC1jb250YWluZXIgbmM6b3BlcmF0aW9uPSZxdW90O2RlbGV0ZSZxdW90Oy8mZ3Q7PGJyPg0KJmd0 OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgL21hcnRpbjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZSBleGFtcGxlcyBoYXZlIGE8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ICcmbHQ7dG9wJmd0OycgZWxlbWVudCBidXQgaW4gY2FzZXMgd2hl cmUgdGhlcmUgYXJlIG11bHRpcGxlIHRvcC1sZXZlbDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg bm9kZXMsIHNvbWUgb2Ygd2hpY2ggYXJlIG9wdGlvbmFsIGluIHRoZSBjb25maWd1cmF0aW9uIChp ZSBub3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHByZXNlbmNlIGNvbnRhaW5lcnMpLCBpcyBp dCBwb3NzaWJsZSB0byBkZWxldGUgdGhlc2Ugbm9kZXM/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgU2Vjb25kbHksIGlmIEknbSBjb3JyZWN0IHRoYXQg dGhlICdkZWxldGUnIG9wZXJhdGlvbiB3b3VsZCBvbmx5PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyBhZmZlY3Qgbm9kZXMgYmVsb3cgdGhlIG9uZSB3aXRoIHRoZSBkZWxldGUgb3BlcmF0aW9uLCBp cyBpdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgcG9zc2libGUgdG8gY29uc3RydWN0IGFuIGVk aXQtY29uZmlnIFBEVSB0aGF0IHdvdWxkIGRlbGV0ZSBhbGw8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7IGNoaWxkIG5vZGVzIHdpdGhvdXQgaGF2aW5nIHRvIGV4cGxpY2l0bHkgc3BlY2lmeSBlYWNo IG9uZT8mbmJzcDsgT3I8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGlzIHRoZSBvbmx5IHdheSB0 byBhY2hpZXZlIHRoaXMgZWl0aGVyIHRvIGV4cGxpY2l0bHkgc3BlY2lmeSBhbGw8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IGNvbmZpZyB0byBiZSByZW1vdmVkLCBvciB0byBkbyBhIGNvcHktY29u ZmlnIGV4cGxpY2l0bHk8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHNwZWNpZnlpbmcgYWxsIGNv bmZpZyB0aGF0IGlzIG5vdCB0byBiZSBkZWxldGVkLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBXaWxsaWFtPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEZyb206IE1hcnRpbiBCam9ya2x1bmQgW21haWx0bzo8YSBo cmVmPSJtYWlsdG86bWJqQHRhaWwtZi5jb20iPm1iakB0YWlsLWYuY29tPC9hPl08YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IFNlbnQ6IDE0IEFwcmlsIDIwMTYgMDk6MzQ8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IFRvOiBXaWxsaWFtIEl2b3J5ICZsdDs8YSBocmVmPSJtYWlsdG86d2l2b3J5QEJy b2NhZGUuY29tIj53aXZvcnlAQnJvY2FkZS5jb208L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGlldGYu b3JnPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtOZXRjb25mXSBD bGFyaWZpY2F0aW9uIHJlcXVlc3QgZm9yIE5FVENPTkY8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 IGVkaXQtY29uZmlnIGRlZmF1bHQtb3BlcmF0aW9uIHJlcGxhY2U8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBIaSw8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBXaWxsaWFtIEl2b3J5ICZsdDs8YSBocmVmPSJt YWlsdG86d2l2b3J5QEJyb2NhZGUuY29tIj53aXZvcnlAQnJvY2FkZS5jb208L2E+Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgSGksPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEknZCBhcHByZWNpYXRlIGNs YXJpZmljYXRpb24gb2YgaG93IHRoZSBORVRDT05GIGVkaXQtY29uZmlnPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7IGNvbW1hbmQgc2hvdWxkIHdvcmsgd2l0aCBkZWZhdWx0LW9wZXJhdGlv biBzZXQgdG8gJ3JlcGxhY2UnLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBGb3IgdGhl IG1vc3QgcGFydCwgdGhlIGVkaXQtY29uZmlnIHNlY3Rpb24gaXMgY2xlYXIgdGhhdDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBjb25maWcgd2lsbCBvbmx5IGJlIHJlcGxhY2VkIGlmIGV4 cGxpY2l0bHkgb3ZlcndyaXR0ZW4gKGllIGlmPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 IHlvdSBwcm92aWRlIHJlcGxhY2VtZW50IGNvbmZpZyBmb3IgZ2l2ZW4gbm9kZXMpLiZuYnNwOyBI b3dldmVyLCB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgc2VjdGlvbiBvbiBkZWZh dWx0LW9wZXJhdGlvbiBpcyBsZXNzIGNsZWFyOjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgVGhlICZsdDtkZWZhdWx0LW9wZXJhdGlvbiZndDsgcGFyYW1ldGVyIGlzIG9wdGlv bmFsLCBidXQgaWY8YnI+DQomZ3Q7ICZndDsgcHJvdmlkZWQsPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpdCBoYXMgb25lIG9m IHRoZSBmb2xsb3dpbmcgdmFsdWVzOjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgbWVyZ2U6Jm5ic3A7IFRoZSBjb25maWd1cmF0aW9uIGRhdGEgaW4gdGhlICZsdDtjb25maWcm Z3Q7IHBhcmFtZXRlciBpczxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO21lcmdlZCB3aXRoIHRoZSBjb25m aWd1cmF0aW9uIGF0IHRoZSBjb3JyZXNwb25kaW5nPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7IGxldmVsPGJyPg0KJmd0OyAmZ3Q7IGluPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlIHRhcmdl dCBkYXRhc3RvcmUuJm5ic3A7IFRoaXMgaXMgdGhlIGRlZmF1bHQgYmVoYXZpb3IuPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyByZXBsYWNlOiZuYnNwOyBUaGUgY29uZmlndXJh dGlvbiBkYXRhIGluIHRoZSAmbHQ7Y29uZmlnJmd0OyBwYXJhbWV0ZXI8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtjb21wbGV0ZWx5IHJlcGxhY2VzIHRoZSBjb25maWd1cmF0aW9uIGluIHRoZSB0YXJnZXQ8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtkYXRhc3RvcmUuJm5ic3A7IFRoaXMgaXMgdXNlZnVsIGZvciBs b2FkaW5nIHByZXZpb3VzbHkgc2F2ZWQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb25maWd1cmF0aW9u IGRhdGEuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7IFNwZWNpZmljYWxseSwgd2hpbGUgJ21lcmdlJyBzdGF0ZXMgdGhhdCBtZXJnZSBo YXBwZXNuIHdpdGg8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJ2NvbmZpZ3VyYXRpb24g YXMgdGhlIGNvcnJlc3BvbmRpbmcgbGV2ZWwnLCAncmVwbGFjZScgc3RhdGVzPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7IHRoYXQgaXMgJ2NvbXBsZXRlbHkgcmVwbGFjZXMnIHRoZSBjb25m aWd1cmF0aW9uLCBzdWdnZXN0aW5nPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoYXQg aXQgd2lsbCByZW1vdmUgQUxMIGV4aXN0aW5nIGNvbmZpZ3VyYXRpb24gcmVnYXJkbGVzcyBvZjxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyB3aGF0IGlzIGV4cGxpY2l0bHkgcHJvdmlkZWQg YXMgdGhlIHJlcGxhY2VtZW50LiZuYnNwOyBJcyB0aGF0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7IGNvcnJlY3QsIG9yIGlzICdyZXBsYWNlJyBtZWFudCB0byBoYXZlIGVxdWl2YWxlbnQg c2VtYW50aWNzIHRvPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICdtZXJnZScgaWUgaXQg d2lsbCBvbmx5IHJlcGxhY2UgY29uZmlndXJhdGlvbiB3aGVuIGFuIGV4cGxpY2l0PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHJlcGxhY2VtZW50IGlzIHByb3ZpZGVkLiZuYnNwOyBJbiBv dGhlciB3b3JkcywgaWYgdGhlIGxhdHRlciBjYXNlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7IGlzIGNvcnJlY3QsIGFsbCBpdCBkb2VzIGlzIHJlbW92ZSB0aGUgcmVxdWlyZW1lbnQgdG8g c3BlY2lmeTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUgb3BlcmF0aW9uIGluIGVh Y2g8YnI+DQomZ3Q7ICZndDsgZWxlbWVudCBvZiBuZXcgY29uZmlnLjxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFllcyB0aGUgbGF0dGVyIGlzIGNvcnJl Y3QuJm5ic3A7IE5vdGUgdGhhdCB0aGUgZGVmaW5pdGlvbiBvZiAmcXVvdDtyZXBsYWNlJnF1b3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBhcyBhbiBvcGVyYXRpb24gc2F5czo8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1VubGlrZSBhPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZs dDtjb3B5LWNvbmZpZyZndDsgb3BlcmF0aW9uLCB3aGljaCByZXBsYWNlcyB0aGUgZW50aXJlIHRh cmdldDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtjb25maWd1cmF0aW9uLCBvbmx5IHRoZSBjb25maWd1cmF0aW9u IGFjdHVhbGx5IHByZXNlbnQgaW48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlICZsdDtjb25maWcmZ3Q7IHBh cmFtZXRlciBpcyBhZmZlY3RlZC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgL21hcnRpbjxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCiZndDsgJmd0OyBOZXRjb25mIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyA8YSBocmVm PSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyI+TmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7 ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRj b25mIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRjb25mPC9hPjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBOZXRjb25m IG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRm Lm9yZyI+TmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9hPjxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpOZXRjb25mIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpOZXRjb25mQGlldGYub3JnIj5OZXRjb25mQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A125E53CE190A749957C19483DC79F9F5CCA4838US70TWXCHMBA11z_-- From nobody Thu Jun 2 18:00:15 2016 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 9320E12D147 for ; Thu, 2 Jun 2016 18:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 5COOrHnL3bNi for ; Thu, 2 Jun 2016 18:00:06 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::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 AF7CF12D09F for ; Thu, 2 Jun 2016 18:00:05 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id o16so66846427ywd.2 for ; Thu, 02 Jun 2016 18:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=8vk4PCaFnHqGgm5adiSTP2dIexEKyOSa0pCKif5cstg=; b=wasPHbDuCFMu9iQC1h5M50vU3nzi2+5QVsHZqn6frRnBs4Y2Y7GK0Ohhoe6CgAcxOY SM/2znUkPr2SeNSUTwanKcy5nwcpInkAkbhSbyCkp1KuQfKnwhxWV6WXwlKUCOc13iuQ 2bESjCGYfWRqK8UfBs2kU5h0KSssSprLVJT14DaKVYvRRnzW1wPy3QaaQTovhygjbX4j VVMAf9eEunDAzs+syzNnN2+8FYQxuZ47IVqT3TdTWfCiPpKlQHobL6q68Zq8SOTaFY/F 9FIdNgR1RuifsLYFkle/OCCvuWigmxRcA9V+/d3jap/sUPaX20OecZztuQN2+AFotI04 aT0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=8vk4PCaFnHqGgm5adiSTP2dIexEKyOSa0pCKif5cstg=; b=EFZVJZYoITQlBC6H+qLOvmNNNZ+1ifQDpyDJHwRldtVy5Yc8eETY6DGVQzEGsmDudA wYRZFDMmIeGMS479A0emcHA7YahKzQre6zGGVNSDo/NobSbqXqxVFqMoTkjTqwwtOziX rUITQGuO2ZMkg1a46hiMiYQgitzmfKC1F12p4n3xHs2y0+krzk52pjt+ha7VF6knr3Ly z2qnIXcBZPHW72s4kr9Q+ji9zkNBhTbT9kpTqwQ1klFoFSevX6330iVGaIG1mPxqmxA/ Brnn/ZQW0hMC2mbw24WLJqH71MP+MOXmgJdHLCmnSDsFmUJKIc7vk1SwhwSkBS5DbyAC bYYQ== X-Gm-Message-State: ALyK8tIF2bBQenTSnInzx6WXgdKcE0e9b1aXYcNJ60FglCm7On39g1BB8MGs8aux/yZnymzuLHJCS1//HX/leA== MIME-Version: 1.0 X-Received: by 10.13.202.207 with SMTP id m198mr766289ywd.140.1464915604705; Thu, 02 Jun 2016 18:00:04 -0700 (PDT) Received: by 10.37.115.208 with HTTP; Thu, 2 Jun 2016 18:00:04 -0700 (PDT) In-Reply-To: References: <01f401d1a54f$621dbad0$26593070$@seguesoft.com> <20160531.105003.567321207823725528.mbj@tail-f.com> Date: Thu, 2 Jun 2016 18:00:04 -0700 Message-ID: From: Andy Bierman To: "Sterne, Jason (Nokia - CA)" Content-Type: multipart/alternative; boundary=001a11482d6a3ecc830534553eca Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Clarification request for NETCONF edit-config default-operation replace X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 01:00:10 -0000 --001a11482d6a3ecc830534553eca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, NACM is not defined to be all-or-nothing for GET. The round-trip described in RFC 3535 only works if the GET is complete config =3D get-config source=3Drunning [edit config offline] copy-config source=3Dconfig target=3Dcandidate Any nodes missing from the get-config because the user is unauthorized will look like delete attempts in the copy-config. The nodes can be anywhere, not just top-level. Andy On Thu, Jun 2, 2016 at 5:49 PM, Sterne, Jason (Nokia - CA) < jason.sterne@nokia.com> wrote: > Thx. In case I accidently gave the wrong impression -> I wasn=E2=80=99t > advocating to change . Just trying to clarify the > intended/expected behavior. > > > > I wasn=E2=80=99t even considering NACM during this whole discussion. I w= ould > assume NACM would affect the behavior of replace or delete > (i.e. nodes that the client can=E2=80=99t access are not deleted, can eas= ily result > in invalid candidate configs) , but that permission should be controlled > for the at the RPC level (i.e. all or nothing authorization > for a client/user to use the copy-config RPC). > > > > Jason > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Tuesday, May 31, 2016 20:50 > *To:* Sterne, Jason (Nokia - CA) > *Cc:* Martin Bjorklund; netconf@ietf.org > *Subject:* Re: [Netconf] Clarification request for NETCONF edit-config > default-operation replace > > > > Hi, > > > > I don't think needs to be changed to provide the > > same replace semantics as . copy-config is > > for complete configurations. > > > > There is an unwritten assumption that the copy-config contents are > > not pruned at all by access control. A missing node will be interpreted a= s > a delete attempt. > > This is not at all desirable if the client is not authorized and is not > even aware > > of these "hidden" nodes. > > > > > > Andy > > > > > > On Tue, May 31, 2016 at 6:36 AM, Sterne, Jason (Nokia - CA) < > jason.sterne@nokia.com> wrote: > > Thx Martin. Your explanation that a default replace operation can only > apply to elements that are in the request helps a lot. > > So there really is no such thing as an edit-config 'replace' operation > that operates "at the root". That can only be done with a special dedicat= ed > RPC (e.g. copy-config as you show in Case 5). > > So my case 4 is equivalent to this: > > > > > > > 10 > > > > > > which will replace the entire contents of the /system subtree (but not > anything else). > > On a related note -> is the final result (i.e. datastore contents) of a > replace operation always exactly the same as a remove + merge with the sa= me > data at the same location ? I can't think of an example where that isn't > true but I may be missing some corner case. > > For the candidate datastore it seems that 'replace' is simply a shorthand > way to do remove+merge in a single edit-config. For a running datastore > (writeable-running) the impacts would be quite different though since the > edit-config 'remove' would be applied immediately which would clear out a= ll > config for a short period before the 'merge' then gets processed. > > Regards, > Jason > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, May 31, 2016 4:50 > To: Sterne, Jason (Nokia - CA) > Cc: xiangli@seguesoft.com; wivory@Brocade.com; netconf@ietf.org > Subject: Re: [Netconf] Clarification request for NETCONF edit-config > default-operation replace > > "Sterne, Jason (Nokia - CA)" wrote: > > Hi guys, > > > > I think there is some conflicting information wrt default-operation > > replace here. > > I agree it is not clear. > > > The following snippet of RFC 6241 clearly states (IMO) that the entire > > config is affected/replaced. The first sentence says it. > > I don't think this statement clearly says that the entire datastore is > replaced. It uses the term "completely replace". I don't know how that = is > different from "replace". IMO, "replace" implies "completely"... > > > Then the second sentence gives yet another indication that it replaces > > the entire config: > > Not necessarily. > > > > replace: The configuration data in the parameter > > > completely replaces the configuration in the target > > > datastore. This is useful for loading previously saved > > > configuration data. > > > > > > I also found an older discussion on this on the mailing list that > > indicates that a default action of replace is intended to be used for > > the entire datastore. From > > > https://mailarchive.ietf.org/arch/msg/netconf/s4KOJxIgbDzqAXS-uF_jFi-iQsU= : > > > > > > > 1) > > > $backup =3D get-config(source=3Drunning) > > > 2) > > > copy-config(source=3D$backup, target=3Drunning) OR > > > edit-config(source=3D$backup, target=3Drunning, > > > default-operation=3Dreplace)" > > > > > > operations are inherited. The default-operation applies > > to all top level objects. But I'm not certain whether it applies to > > all top level objects in the data model on the server or just all the > > top level objects that are included in the request. > > The latter. It is just a default value for the "operation" attribute; > i.e., instead of using "default-operation", you could explicitly set the > "operation" attribute - and you can only do that for the elements in the > request (obvioulsy). > > > From the descriptions above it seems it must apply to all top level > > objects in the server but that seems to conflict with: > > > > > "only the configuration actually present in the parameter > > > is affected" > > > > Here is a set of examples that may help clarify things. The first 3 > > cases are an incremental lead-in to case 4 which is the least clear > > for me. > > > > ## Initial server Config A (used in all the cases below): > > > > > > 12 > > true > > > > > > 132 > > true > > > > > > > > > > 8 > > true > > > > > > > > ## Case 1: > > - Initial Config A > > - edit-config request (no default operation): > > > > > > 10 > > > > > > - Resulting config on the server (only 'min-length' affected): > > > > > > 10 > > true > > > > > > 132 > > true > > > > > > > > > > 8 > > true > > > > > > > > ## Case 2: > > - Initial Config A > > - edit-config request (no default operation): > > > > > > 10 // inherited replace > > > > > > - Resulting config on the server (all 'password-control' affected): > > > > > > 10 > > > > > > 132 > > true > > > > > > > > > > 8 > > true > > > > > > > > ## Case 3: > > - Initial Config A > > - edit-config request (no default operation): > > > > // inherited replace > > 10 // inherited replace > > > > > > - Resulting config on the server (all 'system' affected) : > > > > > > 10 > > > > > > > > > > 8 > > true > > > > > > > > ## Case 4: > > - Initial Config A > > - edit-config request (!! with default-operation replace !!): > > > > > > 10 > > > > > > - Resulting config on the server (entire server datastore affected ?): > > > > > > 10 > > > > > > // no qos data ? > > This is not correct; qos is unaffected. > > ## Case 5: > - Initial Config A > - copy-config request > > > 10 > > > - Resulting config on the server (entire server datastore affected !): > > > 10 > > > // no qos data ! > > > > /martin > > > > > > > Regards, > > Jason > > > > -----Original Message----- > > From: EXT Xiang Li [mailto:xiangli@seguesoft.com] > > Sent: Tuesday, May 03, 2016 11:21 > > To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund'; wivory@Brocade.com > > Cc: netconf@ietf.org > > Subject: RE: [Netconf] Clarification request for NETCONF edit-config > > default-operation replace > > > > Hi > > > > > -----Original Message----- > > >... > > > In my first question I meant "using an ": > > > > > > Is there no way to delete (or replace) the entire contents of the > > datastore > > > using an (and without using without > > > having to explicitly list every single top level node ? > > > > > > > I don't think edit-config is designed to do that. > > > > To delete a datastore, use , although can't > > be deleted. > > To replace the *entire config*, use . > > > > > From the description of the default-operation 'replace' it seems it > > > is > > possible > > > via the default operation: > > > replace: The configuration data in the parameter > > > completely replaces the configuration in the target > > > datastore. This is useful for loading previously saved > > > configuration data. > > > > > > No. The definition of "replace" as an operation says clearly: > > > > Unlike a operation, which replaces the entir= e > target > > configuration, only the configuration actually present in > > the parameter is affected. > > > > In other words, the only replaces the data nodes that exist > > in the target and for nodes that are in in the > > but not in the target, they are created. Other nodes that > > exist in the device but are not present in the of the > > are NOT affected in any way (this is the key difference > > with , where they are removed because it operates on the > > *entire* datastore.) > > > > > But can replace of the entire contents be done without replace as > > > the > > default > > > operation ? > > > > Not with the default "replace" operation, nor with the normal > > "replace" > > operation. > > The default "replace" operation has no additional semantics compared > > to The "operation" parameter > > > > > Or delete of the entire contents ? The RFC doesn't seem to clear on > > > whether we can use an operation on the node: > > > > > > > > > > > > The description of says: the target configuration is not > > necessarily replaced, as with the message. Instead, the > > target configuration is changed in accordance with the source's data > > and requested operations. > > > > In other words, the parameter in will not be > > valid if you do not specify it (assuming no url capability) or make it > > empty, as in your example. > > > > config: A hierarchy of configuration data as defined by one of > > the device's data models. The contents MUST be placed in an > > appropriate namespace, to allow the device to detect the > > appropriate data model, and the contents MUST follow the > > constraints of that data model, as defined by its capability > > definition. > > > > > > > (c) and (d) have a delete operation on a leaf (in (c) is it > > > inherited) but > > are > > > providing a value for the leaf at the same time. What is the meaning > > > of > > the > > > value ? That seems like an error to me. We should warn the client > > > that they've done something unexpected (the client may have been > > > intending to do something different than deleting that leaf). > > > I can see how that works when the leaf is a key leaf in a list. But > > > it > > seems like > > > an error for just a plain leaf. > > > > > > No. I think the value is actually used by . For example, > > RFC6241 > > has this example: > > > > Delete the configuration for an interface named "Ethernet0/0" from > > the running configuration: > > > > > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > none > > > > > > > > Ethernet0/0 > > > > > > > > > > > > > > > > Without specifying value so that the device can find an exact matched > > interface, this won't work. > > > > In other words, my understanding is that if a value is given, and the > > device > > > > can't find a match then then the delete will fail with a > > error. > > > > > I'm also not convinced about (f) and (g). Wrt your analogy of a > > > directory > > with > > > files: you can delete a container in NETCONF and that automatically > > deletes > > > any children, grandchildren and so on (the entire subtree). It > > > seems > > strange > > > that there is no way to delete (or replace) the entire contents of a > > > list > > or leaf- > > > list. > > > > I don't necessarily disagree with you on this one. > > > > I was simply suggesting that the protocol perhaps should have a simple > > way to allow me to remove list entries. In particular I think it would > > be useful it allows: > > 1) to delete a specific list entry by providing a list entry's > > Instance ID ( all key nodes and corresponding values). > > 2) to delete all entries of a list by just providing all key nodes in > > the . > > > > Best, > > --Xiang > > > > > > > > > Or perhaps I'm misinterpreting the description of the replace and > > > delete operations in RFC6241 (the sentences "only the configuration > > > actually present in the parameter is affected" and "if and > > > only if the configuration data currently exists" are giving me some > > > pause here). > > There > > > aren't many examples illustrating delete & replace in the RFC. > > > > > > Regards, > > > Jason > > > > > > -----Original Message----- > > > From: EXT Xiang Li [mailto:xiangli@seguesoft.com] > > > Sent: Friday, April 29, 2016 20:05 > > > To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund'; > > > wivory@Brocade.com > > > Cc: netconf@ietf.org > > > Subject: RE: [Netconf] Clarification request for NETCONF edit-config > > default- > > > operation replace > > > > > > > > > > > > -----Original Message----- > > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Sterne, > > > Jason (Nokia - CA) > > > Sent: Friday, April 29, 2016 2:12 PM > > > To: Martin Bjorklund ; wivory@Brocade.com > > > Cc: netconf@ietf.org > > > Subject: Re: [Netconf] Clarification request for NETCONF edit-config > > default- > > > operation replace > > > > > > Is there no way to delete the entire contents of the datastore > > > without > > having > > > to explicitly list every single top level node ? > > > > > > e.g. > > > with no default operation (i.e. merge): > > > > > > > > > Or > > > With default operation =3D delete: > > > > > > > > > Similarly -> Is there no way to replace the entire contents of the > > datastore ? > > > > > > [XL] I think< copy-config> or can do this. > > > > > > About the cases below shouldn't (c) and (d) return an error ? They > > contain > > > data for an object that is being deleted. (e) seems like the > > > correct way > > to do > > > it. > > > > > > [XL] I think Martin's explanation is correct. My understanding is > > > that if > > the > > > value does not match, then the would return an error since > > > the no matching data node found (yes I view this as a content-match). > > > Or I might > > be > > > totally wrong here, i.e., the value does not matter in any way as > > > Martin > > said? > > > > > > (f) and (g) surprise me. If I can an entire leaf-list > > > or > > list by just > > > specifying the tag for the leaf-list/list name, why doesn't delete > > > get rid > > of the > > > entire leaf-list/list ? > > > (if you specify a specific list entry/member in a delete it is > > > basically > > just a > > > content match node but otherwise you've selected the entire list no > > > ?). > > > > > > [XL] I also thought that I can delete a list entry by specifying > > > all key > > nodes > > > and their values (i.e., list entry's instance ID). If no values of > > > key > > nodes are > > > given, then the entire list entries matched and all of them should > > > be > > deleted. > > > Although Martin's explanation also makes sense here, that is, you > > > can't > > just > > > delete a key node yet if it is still used by non-key nodes. > > > Just like deleting a directory when the directory still contains > > > files. > > But, in any > > > case, I would still like that I can delete a list entry by giving > > > the > > list entry's IID > > > since we can unmistakably identify a list entry by given a list > > > entry's > > IID (i.e. , > > > all key nodes and their corresponding values). I think such a > > > delete operation would be useful, just like "rm -rf directory". > > > > > > --Xiang > > > -----Original Message----- > > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin > > > Bjorklund > > > Sent: Friday, April 15, 2016 10:49 > > > To: wivory@Brocade.com > > > Cc: netconf@ietf.org > > > Subject: Re: [Netconf] Clarification request for NETCONF edit-config > > default- > > > operation replace > > > > > > William Ivory wrote: > > > > OK - I think it might help if I gave some specific examples, with > > > > my understanding of what would get deleted and you can tell me if > > > > I'm correct or not. Apologies for length, but I'd like to avoid > > > > any confusion by not spelling out my queries, and I'm struggling > > > > to get a clear picture of how this all works with all the > > > > different permutations! > > > > > > > > Let's take a configuration like this: > > > > > > > > > > > > leafValue > > > > leaflistValueOne > > > > leaflistValueTwo > > > > > > > > firstEntryKey > > > > firstEntryLeaf > > > > > > > > > > > > secondEntryKey > > > > secondEntryLeaf > > > > > > > > > > > > > > > > --- > > > > > > > > (a) topCont, default operation delete > > > > > > > > With the default operation set to delete: > > > > > > > > > > > > > > > > > > > > > > > > =3D> topCont, and everything under it, would be deleted > > > > > > Yes. > > > > > > > (b) topCont, operation delete > > > > > > > > With the default operation set to none: > > > > > > > > > > > > > > > > > > > > > > > > =3D> topCont, and everything under it, would be deleted > > > > > > > > > > Yes. > > > > > > > --- > > > > > > > > (c) aLeaf delete, operation specified for topCont > > > > > > > > With the default operation set to none: > > > > > > > > > > > > > > > > leafValue > > > > > > > > > > > > =3D> Will delete aLeaf node. If this leaves topCont empty, then > > > > topCont would be removed. If topCont still contains other > > > > elements, topCont would remain? > > > > > > No. This deletes the topCont and everything below it. > > > > > > > --- > > > > > > > > (d) aLeaf delete, operation specified for aLeaf > > > > > > > > With the default operation set to none: > > > > > > > > > > > > > > > > leafValue > > > > > > > > > > > > =3D> Will delete aLeaf node. If this leaves topCont empty, then > > > > topCont would be removed unless it is a presence node. > > > > > > Yes (s/would/may/) > > > > > > > --- > > > > > > > > (e) aLeaf delete, operation specified for aLeaf, but no value > > > > given > > > > > > > > With the default operation set to none: > > > > > > > > > > > > > > > > > > > > > > > > =3D> Would this delete aLeaf, and, as per (d), conditionally > > > > , or must the value of the leaf be specified? > > > > > > > > > > Yes, this would delete aLeaf. The value doesn't matter. > > > > > > > --- > > > > > > > > (f) aLeafListEntry > > > > > > > > Is there a way to delete all leaflist entries without specifying > > > > them individually, eg: > > > > > > > > > > > > > > No > > > > > > > > > > > > > > ... or, assuming there are other sibling nodes such that we can't > > > > just delete topCont, must I specify each individual leaflist > > > > element I wish to remove? > > > > > > > > --- > > > > > > > > (g) aListEntry > > > > > > > > As per leaflist entries, is there a way to delete all entries > > > > generically > > > > > > No. > > > > > > >, or must each be specified? > > > > > > Yes. > > > > > > > Separately, if I delete a non-key node inside a list entry, I > > > > assume that just deletes that node. If I delete the list's key > > > > node, then presumably that removes the complete entry, eg: > > > > > > > > > > > > > > > > > > > > firstEntryKey > > > > > > > > > > > > > > Yes > > > > > > > Would the following achieve the same, ie removal of this list entry= : > > > > > > > > > > > > > > > > > > > > firstEntryKey > > > > > > > > > > > > > > Hmm. I would say that this results in an error - deleting just the > > > key of > > a list is > > > not possible. > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > --- > > > > > > > > Thanks for bearing with me, > > > > > > > > William > > > > > > > > -----Original Message----- > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > Sent: 15 April 2016 13:44 > > > > To: William Ivory > > > > Cc: netconf@ietf.org > > > > Subject: Re: [Netconf] Clarification request for NETCONF > > > > edit-config default-operation replace > > > > > > > > William Ivory wrote: > > > > > Hi Martin, > > > > > > > > > > Thanks - I think that the section on 'replace' under > > > > > 'default-operation' could do with being clarified next time the > > > > > RFC is updated then. > > > > > > > > > > I'd appreciate some further clarification on what exactly ' only > > > > > the configuration actually present in the parameter is > > > > > affected' > > > > > means in practice. > > > > > > > > > > First, the general pattern of examples which use > > > > > 'operation=3D' is that this command is put in the 'par= ent' > > > > > element's tag, ie the tag which specifies 'delete' is *not* > deleted. > > > > > > > > No. For example: > > > > > > > > > > > > 192.0.2.4 > > > > > > > > > > > > will delete the "interface" node with the name "192.0.2.4" > > > > > > > > It does NOT keep the "interface" node and just delete the "name" > node. > > > > > > > > > How then would you delete a top-level container? > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > The examples have a > > > > > '' element but in cases where there are multiple top-level > > > > > nodes, some of which are optional in the configuration (ie not > > > > > presence containers), is it possible to delete these nodes? > > > > > > > > > > Secondly, if I'm correct that the 'delete' operation would only > > > > > affect nodes below the one with the delete operation, is it > > > > > possible to construct an edit-config PDU that would delete all > > > > > child nodes without having to explicitly specify each one? Or > > > > > is the only way to achieve this either to explicitly specify all > > > > > config to be removed, or to do a copy-config explicitly > > > > > specifying all config that is not to be deleted. > > > > > > > > > > Thanks, > > > > > > > > > > William > > > > > > > > > > -----Original Message----- > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > > Sent: 14 April 2016 09:34 > > > > > To: William Ivory > > > > > Cc: netconf@ietf.org > > > > > Subject: Re: [Netconf] Clarification request for NETCONF > > > > > edit-config default-operation replace > > > > > > > > > > Hi, > > > > > > > > > > William Ivory wrote: > > > > > > Hi, > > > > > > > > > > > > I'd appreciate clarification of how the NETCONF edit-config > > > > > > command should work with default-operation set to 'replace'. > > > > > > For the most part, the edit-config section is clear that > > > > > > config will only be replaced if explicitly overwritten (ie if > > > > > > you provide replacement config for given nodes). However, the > > > > > > section on default-operation is less clear: > > > > > > > > > > > > The parameter is optional, but if > > > provided, > > > > > > it has one of the following values: > > > > > > > > > > > > merge: The configuration data in the > parameter is > > > > > > merged with the configuration at the corresponding > > > > > > level > > > in > > > > > > the target datastore. This is the default behavior= . > > > > > > > > > > > > replace: The configuration data in the > parameter > > > > > > completely replaces the configuration in the target > > > > > > datastore. This is useful for loading previously > saved > > > > > > configuration data. > > > > > > > > > > > > Specifically, while 'merge' states that merge happesn with > > > > > > 'configuration as the corresponding level', 'replace' states > > > > > > that is 'completely replaces' the configuration, suggesting > > > > > > that it will remove ALL existing configuration regardless of > > > > > > what is explicitly provided as the replacement. Is that > > > > > > correct, or is 'replace' meant to have equivalent semantics to > > > > > > 'merge' ie it will only replace configuration when an explicit > > > > > > replacement is provided. In other words, if the latter case > > > > > > is correct, all it does is remove the requirement to specify > > > > > > the operation in each > > > element of new config. > > > > > > > > > > Yes the latter is correct. Note that the definition of "replace" > > > > > as an operation says: > > > > > > > > > > Unlike a > > > > > operation, which replaces the entire > target > > > > > configuration, only the configuration actually presen= t > in > > > > > the parameter is affected. > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > --001a11482d6a3ecc830534553eca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

NACM is not defined to be all-or-no= thing for GET.

The round-trip described in RFC 353= 5 only works if the GET is complete

=C2=A0 config = =3D get-config source=3Drunning

[edit config offli= ne]

=C2=A0 =C2=A0copy-config source=3Dconfig targe= t=3Dcandidate

Any nodes missing from the get-confi= g because the user is unauthorized
will look like delete attempts= in the copy-config.=C2=A0 The nodes can be anywhere,
not just to= p-level.

Andy


On Thu, Jun 2, 2016 at 5:49= PM, Sterne, Jason (Nokia - CA) <jason.sterne@nokia.com> wrote:

Thx.=C2=A0 In case I acci= dently gave the wrong impression -> I wasn=E2=80=99t advocating to chang= e <edit-config>.=C2=A0 Just trying to clarify the intended/expected b= ehavior.

=C2=A0

I wasn=E2=80=99t even con= sidering NACM during this whole discussion.=C2=A0 I would assume NACM would= affect the behavior of <edit-config> replace or delete (i.e. nodes t= hat the client can=E2=80=99t access are not deleted, can easily result in inva= lid candidate configs) , but that permission should be controlled for the &= lt;copy-config> at the RPC level (i.e. all or nothing authorization for = a client/user to use the copy-config RPC).

=C2=A0

Jason

=C2=A0

From: Andy Bie= rman [mailto:andy@y= umaworks.com]
Sent: Tuesday, May 31, 2016 20:50
To: Sterne, Jason (Nokia - CA)
Cc: Martin Bjorklund; netconf@ietf.org
Subject: Re: [Netconf] Clarification request for NETCONF edit-config= default-operation replace

=C2=A0

Hi,

=C2=A0

I don't think <edit-config> needs to be ch= anged to provide the

same replace semantics as <copy-config>. =C2= =A0copy-config is

for complete configurations.

=C2=A0

There is an unwritten assumption that the copy-confi= g contents are

not pruned at all by access control. A missing node = will be interpreted as a delete attempt.

This is not at all desirable if the client is not au= thorized and is not even aware

of these "hidden" nodes. =C2=A0<= /u>

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

On Tue, May 31, 2016 at 6:36 AM, Sterne, Jason (Noki= a - CA) <jas= on.sterne@nokia.com> wrote:

Thx Martin.=C2=A0 Your explanation that a default re= place operation can only apply to elements that are in the request helps a = lot.

So there really is no such thing as an edit-config 'replace' operat= ion that operates "at the root". That can only be done with a spe= cial dedicated RPC (e.g. copy-config as you show in Case 5).

So my case 4 is equivalent to this:

>=C2=A0 =C2=A0 =C2=A0 <system operation=3D'replace'>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <password-control operation=3D'repla= ce'>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <min-length operation=3D'repl= ace'>10</min-length>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </password-control>
>=C2=A0 =C2=A0 =C2=A0 </system>

which will replace the entire contents of the /system subtree (but not anyt= hing else).

On a related note -> is the final result (i.e. datastore contents) of a = replace operation always exactly the same as a remove + merge with the same= data at the same location ?=C2=A0 I can't think of an example where th= at isn't true but I may be missing some corner case.

For the candidate datastore it seems that 'replace' is simply a sho= rthand way to do remove+merge in a single edit-config.=C2=A0 For a running = datastore (writeable-running) the impacts would be quite different though s= ince the edit-config 'remove' would be applied immediately which would clear out all config for a short period before the= 'merge' then gets processed.

Regards,
Jason

-----Original Message-----
From: Martin Bjorklund [mailto:mbj@tail-f.com]
Sent: Tuesday, May 31, 2016 4:50
To: Sterne, Jason (Nokia - CA)
Cc: xiangli@segu= esoft.com; wivory@Brocade.com; netconf@ietf.org
Subject: Re: [Netconf] Clarification request for NETCONF edit-config defaul= t-operation replace

"Sterne, Jason (Nokia - CA)" <jason.sterne@nokia.com> wrote:
> Hi guys,
>
> I think there is some conflicting information wrt default-operation > replace here.

I agree it is not clear.

> The following snippet of RFC 6241 clearly states (IMO) that the entire=
> config is affected/replaced.=C2=A0 The first sentence says it.

I don't think this statement clearly says that the entire datastore is = replaced.=C2=A0 It uses the term "completely replace".=C2=A0 I do= n't know how that is different from "replace".=C2=A0 IMO, &qu= ot;replace" implies "completely"...

> Then the second sentence gives yet another indication that it replaces=
> the entire config:

Not necessarily.

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0replace:=C2=A0 The configuration= data in the <config> parameter
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 completely replaces the = configuration in the target
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 datastore.=C2=A0 This is= useful for loading previously saved
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration data.
>
>
> I also found an older discussion on this on the mailing list that
> indicates that a default action of replace is intended to be used for<= br> > the entire datastore.=C2=A0 From
> https://mailarchive.ietf.org/arch/msg/netconf/s4KOJxIgbDzqAXS-uF_jFi-iQsU:
>
>
> >=C2=A0 1)
> >=C2=A0 =C2=A0 $backup =3D get-config(source=3Drunning)
> >=C2=A0 2)
> >=C2=A0 =C2=A0 copy-config(source=3D$backup, target=3Drunning)=C2= =A0 OR
> >=C2=A0 =C2=A0 edit-config(source=3D$backup, target=3Drunning,
> >=C2=A0 =C2=A0 default-operation=3Dreplace)"
>
>
> <edit-config> operations are inherited. The default-operation ap= plies
> to all top level objects.=C2=A0 But I'm not certain whether it app= lies to
> all top level objects in the data model on the server or just all the<= br> > top level objects that are included in the <edit-config> request= .

The latter.=C2=A0 It is just a default value for the "operation" = attribute; i.e., instead of using "default-operation", you could = explicitly set the "operation" attribute - and you can only do th= at for the elements in the request (obvioulsy).

> From the descriptions above it seems it must apply to all top level > objects in the server but that seems to conflict with:
>
> >=C2=A0 "only the configuration actually present in the <co= nfig> parameter
> > is=C2=A0 affected"
>
> Here is a set of examples that may help clarify things. The first 3 > cases are an incremental lead-in to case 4 which is the least clear > for me.
>
> ## Initial server Config A (used in all the cases below):
>=C2=A0 =C2=A0<system>
>=C2=A0 =C2=A0 =C2=A0<password-control>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<min-length>12</min-length>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<require-caps>true<require-caps>=
>=C2=A0 =C2=A0 =C2=A0</password-control>
>=C2=A0 =C2=A0 =C2=A0<console>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<width>132</width>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<enabled>true</enabled>
>=C2=A0 =C2=A0 =C2=A0</console>
>=C2=A0 =C2=A0</system>
>=C2=A0 =C2=A0<qos>
>=C2=A0 =C2=A0 =C2=A0<ingress>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<class-limit>8</class-limit>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<sub-classes>true</sub-classes><= br> >=C2=A0 =C2=A0 =C2=A0</ingress>
>=C2=A0 =C2=A0</qos>
>
> ## Case 1:
> - Initial Config A
> - edit-config request (no default operation):
>=C2=A0 =C2=A0 =C2=A0 <system>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <password-control>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <min-length operation=3D'repl= ace'>10</min-length>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </password-control>
>=C2=A0 =C2=A0 =C2=A0 </system>
> - Resulting config on the server (only 'min-length' affected):=
>=C2=A0 =C2=A0 =C2=A0 <system>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <password-control>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <min-length>10</min-length&= gt;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <require-caps>true<require-= caps>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </password-control>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <console>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <width>132</width>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <enabled>true</enabled><= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 </console>
>=C2=A0 =C2=A0 =C2=A0 </system>
>=C2=A0 =C2=A0 =C2=A0 <qos>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <ingress>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <class-limit>8</class-limit= >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <sub-classes>true</sub-clas= ses>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </ingress>
>=C2=A0 =C2=A0 =C2=A0 </qos>
>
> ## Case 2:
> - Initial Config A
> - edit-config request (no default operation):
>=C2=A0 =C2=A0 =C2=A0 <system>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <password-control operation=3D'repla= ce'>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <min-length>10</min-length&= gt;=C2=A0 =C2=A0// inherited replace
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </password-control>
>=C2=A0 =C2=A0 =C2=A0 </system>
> - Resulting config on the server (all 'password-control' affec= ted):
>=C2=A0 =C2=A0 =C2=A0 <system>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <password-control>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <min-length>10</min-length&= gt;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </password-control>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <console>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <width>132</width>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <enabled>true</enabled><= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 </console>
>=C2=A0 =C2=A0 =C2=A0 </system>
>=C2=A0 =C2=A0 =C2=A0 <qos>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <ingress>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <class-limit>8</class-limit= >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <sub-classes>true</sub-clas= ses>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </ingress>
>=C2=A0 =C2=A0 =C2=A0 </qos>
>
> ## Case 3:
> - Initial Config A
> - edit-config request (no default operation):
>=C2=A0 =C2=A0 =C2=A0 <system operation=3D'replace'>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <password-control>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// inherited replace
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <min-length>10</min-length&= gt;=C2=A0 // inherited replace
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </password-control>
>=C2=A0 =C2=A0 =C2=A0 </system>
> - Resulting config on the server (all 'system' affected) :
>=C2=A0 =C2=A0 =C2=A0 <system>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <password-control>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <min-length>10</min-length&= gt;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </password-control>
>=C2=A0 =C2=A0 =C2=A0 </system>
>=C2=A0 =C2=A0 =C2=A0 <qos>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <ingress>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <class-limit>8</class-limit= >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <sub-classes>true</sub-clas= ses>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </ingress>
>=C2=A0 =C2=A0 =C2=A0 </qos>
>
> ## Case 4:
> - Initial Config A
> - edit-config request (!! with default-operation replace !!):
>=C2=A0 =C2=A0 =C2=A0 <system>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <password-control>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <min-length>10</min-length&= gt;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </password-control>
>=C2=A0 =C2=A0 =C2=A0 </system>
> - Resulting config on the server (entire server datastore affected ?):=
>=C2=A0 =C2=A0 =C2=A0 <system>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <password-control>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <min-length>10</min-length&= gt;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </password-control>
>=C2=A0 =C2=A0 =C2=A0 </system>
>=C2=A0 =C2=A0 =C2=A0// no qos data ?

This is not correct; qos is unaffected.

## Case 5:
- Initial Config A
- copy-config request
=C2=A0 =C2=A0 <system>
=C2=A0 =C2=A0 =C2=A0 =C2=A0<password-control>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<min-length>10</min-length> =C2=A0 =C2=A0 =C2=A0 </password-control>
=C2=A0 =C2=A0 =C2=A0</system>
- Resulting config on the server (entire server datastore affected !):
=C2=A0 =C2=A0 =C2=A0<system>
=C2=A0 =C2=A0 =C2=A0 =C2=A0<password-control>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <min-length>10</min-length>
=C2=A0 =C2=A0 =C2=A0 </password-control>
=C2=A0 =C2=A0 =C2=A0</system>
=C2=A0 =C2=A0 // no qos data !



/martin



>
> Regards,
> Jason
>
> -----Original Message-----
> From: EXT Xiang Li [mailto:xiangli@seguesoft.com]
> Sent: Tuesday, May 03, 2016 11:21
> To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund'; wivory@Brocade.com
> Cc: netconf@ietf= .org
> Subject: RE: [Netconf] Clarification request for NETCONF edit-config > default-operation replace
>
> Hi
>
> > -----Original Message-----
> >...
> > In my first question I meant "using an <edit-config>&q= uot;:
> >
> > Is there no way to delete (or replace) the entire contents of the=
> datastore
> > using an <edit-config> (and without using <copy-config&g= t; without
> > having to explicitly list every single top level node ?
> >
>
> I don't think edit-config is designed to do that.
>
> To delete a datastore, use <delete-config>, although <running= > can't
> be deleted.
> To replace the *entire config*, use <copy-config>.
>
> > From the description of the default-operation 'replace' i= t seems it
> > is
> possible
> > via the default operation:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 replace:=C2=A0 The configuratio= n data in the <config> parameter
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0completely replace= s the configuration in the target
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0datastore.=C2=A0 T= his is useful for loading previously saved
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration data= .
>
>
> No. The definition of "replace" as an operation says clearly= :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Unlike a=C2=A0 <copy= -config> operation, which replaces the entire target
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration, only the= configuration actually present in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the <config> para= meter is affected.
>
> In other words, the <replace> only replaces the data nodes that = exist
> in the target and for nodes that are in <config> in the
> <edit-config>but not in the target, they are created. Other node= s that
> exist in the device but are not present in the <config> of the > <edit-config> are NOT affected in any way (this is the key diffe= rence
> with <copy-config>, where they are removed because it operates o= n the
> *entire* datastore.)
>
> > But can replace of the entire contents be done without replace as=
> > the
> default
> > operation ?
>
> Not with the default "replace" operation, nor with the norma= l
> "replace"
> operation.
> The default "replace" operation has no additional semantics = compared
> to The "operation" parameter
>
> > Or delete of the entire contents ?=C2=A0 The RFC doesn't seem= to clear on
> > whether we can use an operation on the <config> node:
> > <config operation=3D"delete"/>
> > <config operation=3D"replace"/>
>
>
> The description of <edit-config> says: the target configuration = is not
> necessarily replaced, as with the <copy-config> message.=C2=A0 I= nstead, the
> target configuration is changed in accordance with the source's da= ta
> and requested operations.
>
> In other words, the <config> parameter in <edit-config> wi= ll not be
> valid if you do not specify it (assuming no url capability) or make it=
> empty, as in your example.
>
> config:=C2=A0 A hierarchy of configuration data as defined by one of >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the device's data models.=C2=A0 = The contents MUST be placed in an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 appropriate namespace, to allow the = device to detect the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 appropriate data model, and the cont= ents MUST follow the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 constraints of that data model, as d= efined by its capability
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 definition.
>
>
> > (c) and (d) have a delete operation on a leaf (in (c) is it
> > inherited) but
> are
> > providing a value for the leaf at the same time. What is the mean= ing
> > of
> the
> > value ? That seems like an error to me.=C2=A0 We should warn the = client
> > that they've done something unexpected (the client may have b= een
> > intending to do something different than deleting that leaf).
> > I can see how that works when the leaf is a key leaf in a list.= =C2=A0 But
> > it
> seems like
> > an error for just a plain leaf.
>
>
> No. I think the value is actually used by <edit-config>. For exa= mple,
> RFC6241
> has this example:
>
> Delete the configuration for an interface named "Ethernet0/0"= ; from
>=C2=A0 =C2=A0 the running configuration:
>
>=C2=A0 =C2=A0 =C2=A0 <rpc message-id=3D"101"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns=3D"urn:ietf:params:= xml:ns:netconf:base:1.0">
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <edit-config>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <target>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <running/>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </target>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <default-operation>none</de= fault-operation>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <config xmlns:xc=3D"urn:ietf= :params:xml:ns:netconf:base:1.0">
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <top xmlns=3D"http://example.= com/schema/1.2/config">
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <interface xc:opera= tion=3D"delete">
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>Eth= ernet0/0</name>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </interface>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </top>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </config>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </edit-config>
>=C2=A0 =C2=A0 =C2=A0 </rpc>
>
>
> Without specifying value so that the device can find an exact matched<= br> > interface, this won't work.
>
> In other words, my understanding is that if a value is given, and the<= br> > device
>
> can't find a match then then the delete will fail with a
> <data-missing> error.
>
> > I'm also not convinced about (f) and (g).=C2=A0 Wrt your anal= ogy of a
> > directory
> with
> > files: you can delete a container in NETCONF and that automatical= ly
> deletes
> > any children, grandchildren and so on (the entire subtree).=C2=A0= It
> > seems
> strange
> > that there is no way to delete (or replace) the entire contents o= f a
> > list
> or leaf-
> > list.
>
> I don't necessarily disagree with you on this one.
>
> I was simply suggesting that the protocol perhaps should have a simple=
> way to allow me to remove list entries. In particular I think it would=
> be useful it allows:
> 1) to delete a specific list entry by providing a list entry's
> Instance ID ( all key nodes and corresponding values).
> 2) to delete all entries of a list by just providing all key nodes in<= br> > the <config>.
>
> Best,
> --Xiang
>
>
>
> > Or perhaps I'm misinterpreting the description of the replace= and
> > delete operations in RFC6241 (the sentences "only the config= uration
> > actually present in the <config> parameter is affected"= ; and "if and
> > only if the configuration data currently exists" are giving = me some
> > pause here).
> There
> > aren't many examples illustrating delete & replace in the= RFC.
> >
> > Regards,
> > Jason
> >
> > -----Original Message-----
> > From: EXT Xiang Li [mailto:xiangli@seguesoft.com]
> > Sent: Friday, April 29, 2016 20:05
> > To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund';
> > wivory@Br= ocade.com
> > Cc: netconf= @ietf.org
> > Subject: RE: [Netconf] Clarification request for NETCONF edit-con= fig
> default-
> > operation replace
> >
> >
> >
> > -----Original Message-----
> > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Sterne,
> > Jason (Nokia - CA)
> > Sent: Friday, April 29, 2016 2:12 PM
> > To: Martin Bjorklund <mbj@tail-f.com>; wivory@Brocade.com
> > Cc: netconf= @ietf.org
> > Subject: Re: [Netconf] Clarification request for NETCONF edit-con= fig
> default-
> > operation replace
> >
> > Is there no way to delete the entire contents of the datastore > > without
> having
> > to explicitly list every single top level node ?
> >
> > e.g.
> > with no default operation (i.e. merge):
> > <config operation=3D"delete"/>
> >
> > Or
> > With default operation =3D delete:
> > <config/>
> >
> > Similarly -> Is there no way to replace the entire contents of= the
> datastore ?
> >
> > [XL] I think< copy-config> or <delete-config> can do = this.
> >
> > About the cases below shouldn't (c) and (d) return an error ?= =C2=A0 They
> contain
> > data for an object that is being deleted.=C2=A0 (e) seems like th= e
> > correct way
> to do
> > it.
> >
> > [XL] I think Martin's explanation is correct. My understandin= g is
> > that if
> the
> > value does not match, then the <delete> would return an err= or since
> > the no matching data node found (yes I view this as a content-mat= ch).
> > Or I might
> be
> > totally wrong here, i.e., the value does not matter in any way as=
> > Martin
> said?
> >
> > (f) and (g) surprise me.=C2=A0 If I can <get-config> an ent= ire leaf-list
> > or
> list by just
> > specifying the tag for the leaf-list/list name, why doesn't d= elete
> > get rid
> of the
> > entire leaf-list/list ?
> > (if you specify a specific list entry/member in a delete it is > > basically
> just a
> > content match node but otherwise you've selected the entire l= ist no
> > ?).
> >
> > [XL] I also thought that I can delete a list entry by specifying<= br> > > all key
> nodes
> > and their values (i.e., list entry's instance ID). If no valu= es of
> > key
> nodes are
> > given, then the entire list entries matched and all of them shoul= d
> > be
> deleted.
> > Although Martin's explanation also makes sense here, that is,= you
> > can't
> just
> > delete a key node yet if it is still used by non-key nodes.
> > Just like deleting a directory when the directory still contains<= br> > > files.
> But, in any
> > case,=C2=A0 I would still like that I can delete a list entry by = giving
> > the
> list entry's IID
> > since we can unmistakably identify=C2=A0 a list entry by given a = list
> > entry's
> IID (i.e. ,
> > all key nodes and their corresponding values).=C2=A0 I think such= a
> > delete operation would be useful,=C2=A0 just like "rm -rf di= rectory".
> >
> > --Xiang
> > -----Original Message-----
> > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin
> > Bjorklund
> > Sent: Friday, April 15, 2016 10:49
> > To: wivor= y@Brocade.com
> > Cc: netconf= @ietf.org
> > Subject: Re: [Netconf] Clarification request for NETCONF edit-con= fig
> default-
> > operation replace
> >
> > William Ivory <wivory@Brocade.com> wrote:
> > > OK - I think it might help if I gave some specific examples,= with
> > > my understanding of what would get deleted and you can tell = me if
> > > I'm correct or not.=C2=A0 Apologies for length, but I= 9;d like to avoid
> > > any confusion by not spelling out my queries, and I'm st= ruggling
> > > to get a clear picture of how this all works with all the > > > different permutations!
> > >
> > > Let's take a configuration like this:
> > >
> > > <topCont>
> > >=C2=A0 =C2=A0 =C2=A0<aLeaf>leafValue</aLeaf>
> > >=C2=A0 =C2=A0 =C2=A0<aLeafListEntry>leaflistValueOne<= ;/aLeafListEntry>
> > >=C2=A0 =C2=A0 =C2=A0<aLeafListEntry>leaflistValueTwo<= ;/aLeafListEntry>
> > >=C2=A0 =C2=A0 =C2=A0<aListEntry>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<listKey>firstEntryKe= y</listKey>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<listLeaf>firstEntryL= eaf</listLeaf>
> > >=C2=A0 =C2=A0 =C2=A0</aListEntry>
> > >=C2=A0 =C2=A0 =C2=A0<aListEntry>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<listKey>secondEntryK= ey</listKey>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<listLeaf>secondEntry= Leaf</listLeaf>
> > >=C2=A0 =C2=A0 =C2=A0</aListEntry>
> > > </topCont>
> > >
> > > ---
> > >
> > > (a) topCont, default operation delete
> > >
> > > With the default operation set to delete:
> > >
> > > <config>
> > >=C2=A0 =C2=A0 =C2=A0<topCont>
> > > </config>
> > >
> > > =3D> topCont, and everything under it, would be deleted > >
> > Yes.
> >
> > > (b) topCont, operation delete
> > >
> > > With the default operation set to none:
> > >
> > > <config>
> > >=C2=A0 =C2=A0 =C2=A0<topCont xc:operation=3Ddelete>
> > > </config>
> > >
> > > =3D> topCont, and everything under it, would be deleted > > >
> >
> > Yes.
> >
> > > ---
> > >
> > > (c) aLeaf delete, operation specified for topCont
> > >
> > > With the default operation set to none:
> > >
> > > <config>
> > >=C2=A0 =C2=A0 =C2=A0<topCont xc:operation=3Ddelete>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<aLeaf>leafValue</= aLeaf>
> > > </config>
> > >
> > > =3D> Will delete aLeaf node.=C2=A0 If this leaves topCont= empty, then
> > > topCont would be removed.=C2=A0 If topCont still contains ot= her
> > > elements, topCont would remain?
> >
> > No.=C2=A0 This deletes the topCont and everything below it.
> >
> > > ---
> > >
> > > (d) aLeaf delete, operation specified for aLeaf
> > >
> > > With the default operation set to none:
> > >
> > > <config>
> > >=C2=A0 =C2=A0 =C2=A0<topCont>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<aLeaf xc:operation=3Dde= lete>leafValue</aLeaf>
> > > </config>
> > >
> > > =3D> Will delete aLeaf node.=C2=A0 If this leaves topCont= empty, then
> > > topCont would be removed unless it is a presence node.
> >
> > Yes=C2=A0 (s/would/may/)
> >
> > > ---
> > >
> > > (e) aLeaf delete, operation specified for aLeaf, but no valu= e
> > > given
> > >
> > > With the default operation set to none:
> > >
> > > <config>
> > >=C2=A0 =C2=A0 =C2=A0<topCont>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<aLeaf xc:operation=3Dde= lete/> </config>
> > >
> > > =3D> Would this delete aLeaf, and, as per (d), conditiona= lly
> > > <topCont>, or must the value of the leaf be specified?=
> > >
> >
> > Yes, this would delete aLeaf.=C2=A0 The value doesn't matter.=
> >
> > > ---
> > >
> > > (f) aLeafListEntry
> > >
> > > Is there a way to delete all leaflist entries without specif= ying
> > > them individually, eg:
> > >
> > > <aLeafListEntry xc:operation=3Ddelete>
> >
> > No
> >
> >
> > >
> > > ... or, assuming there are other sibling nodes such that we = can't
> > > just delete topCont, must I specify each individual leaflist=
> > > element I wish to remove?
> > >
> > > ---
> > >
> > > (g) aListEntry
> > >
> > > As per leaflist entries, is there a way to delete all entrie= s
> > > generically
> >
> > No.
> >
> > >, or must each be specified?
> >
> > Yes.
> >
> > > Separately, if I delete a non-key node inside a list entry, = I
> > > assume that just deletes that node.=C2=A0 If I delete the li= st's key
> > > node, then presumably that removes the complete entry, eg: > > >
> > > <config>
> > >=C2=A0 =C2=A0 =C2=A0<topCont>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<aListEntry xc:operation= =3Ddelete>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<listKey&g= t;firstEntryKey</listKey>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</aListEntry>
> > > </config>
> >
> > Yes
> >
> > > Would the following achieve the same, ie removal of this lis= t entry:
> > >
> > > <config>
> > >=C2=A0 =C2=A0 =C2=A0<topCont>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<aListEntry >
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<listKey x= c:operation=3Ddelete >firstEntryKey</listKey>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</aListEntry>
> > > </config>
> >
> > Hmm.=C2=A0 I would say that this results in an error - deleting j= ust the
> > key of
> a list is
> > not possible.
> >
> >
> >
> > /martin
> >
> >
> >
> > >
> > > ---
> > >
> > > Thanks=C2=A0 for bearing with me,
> > >
> > > William
> > >
> > > -----Original Message-----
> > > From: Martin Bjorklund [mailto:mbj@tail-f.com]
> > > Sent: 15 April 2016 13:44
> > > To: William Ivory <wivory@Brocade.com>
> > > Cc: ne= tconf@ietf.org
> > > Subject: Re: [Netconf] Clarification request for NETCONF
> > > edit-config default-operation replace
> > >
> > > William Ivory <wivory@Brocade.com> wrote:
> > > > Hi Martin,
> > > >
> > > > Thanks - I think that the section on 'replace' = under
> > > > 'default-operation' could do with being clarifi= ed next time the
> > > > RFC is updated then.
> > > >
> > > > I'd appreciate some further clarification on what e= xactly ' only
> > > > the configuration actually present in the <config>= ; parameter is
> > > > affected'
> > > > means in practice.
> > > >
> > > > First, the general pattern of examples which use
> > > > 'operation=3D<operation>' is that this co= mmand is put in the 'parent'
> > > > element's tag, ie the tag which specifies 'dele= te' is *not* deleted.
> > >
> > > No.=C2=A0 For example:
> > >
> > >=C2=A0 =C2=A0 =C2=A0<interface xc:operation=3D"delete= ">
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0<name>192.0.2.4</name>=
> > >=C2=A0 =C2=A0 =C2=A0</interface>
> > >
> > > will delete the "interface" node with the name &qu= ot;192.0.2.4"
> > >
> > > It does NOT keep the "interface" node and just del= ete the "name" node.
> > >
> > > > How then would you delete a top-level container?
> > >
> > >=C2=A0 <my-top-level-container nc:operation=3D"delete= "/>
> > >
> > >
> > >
> > > /martin
> > >
> > >
> > > > The examples have a
> > > > '<top>' element but in cases where there = are multiple top-level
> > > > nodes, some of which are optional in the configuration = (ie not
> > > > presence containers), is it possible to delete these no= des?
> > > >
> > > > Secondly, if I'm correct that the 'delete' = operation would only
> > > > affect nodes below the one with the delete operation, i= s it
> > > > possible to construct an edit-config PDU that would del= ete all
> > > > child nodes without having to explicitly specify each o= ne?=C2=A0 Or
> > > > is the only way to achieve this either to explicitly sp= ecify all
> > > > config to be removed, or to do a copy-config explicitly=
> > > > specifying all config that is not to be deleted.
> > > >
> > > > Thanks,
> > > >
> > > > William
> > > >
> > > > -----Original Message-----
> > > > From: Martin Bjorklund [mailto:mbj@tail-f.com]
> > > > Sent: 14 April 2016 09:34
> > > > To: William Ivory <wivory@Brocade.com>
> > > > Cc: netconf@ietf.org
> > > > Subject: Re: [Netconf] Clarification request for NETCON= F
> > > > edit-config default-operation replace
> > > >
> > > > Hi,
> > > >
> > > > William Ivory <wivory@Brocade.com> wrote:
> > > > > Hi,
> > > > >
> > > > > I'd appreciate clarification of how the NETCON= F edit-config
> > > > > command should work with default-operation set to = 'replace'.
> > > > > For the most part, the edit-config section is clea= r that
> > > > > config will only be replaced if explicitly overwri= tten (ie if
> > > > > you provide replacement config for given nodes).= =C2=A0 However, the
> > > > > section on default-operation is less clear:
> > > > >
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The <default-= operation> parameter is optional, but if
> > provided,
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 it has one of th= e following values:
> > > > >
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 merge:=C2=A0 The= configuration data in the <config> parameter is
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mer= ged with the configuration at the corresponding
> > > > > level
> > in
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the= target datastore.=C2=A0 This is the default behavior.
> > > > >
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 replace:=C2=A0 T= he configuration data in the <config> parameter
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0com= pletely replaces the configuration in the target
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dat= astore.=C2=A0 This is useful for loading previously saved
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0con= figuration data.
> > > > >
> > > > > Specifically, while 'merge' states that me= rge happesn with
> > > > > 'configuration as the corresponding level'= , 'replace' states
> > > > > that is 'completely replaces' the configur= ation, suggesting
> > > > > that it will remove ALL existing configuration reg= ardless of
> > > > > what is explicitly provided as the replacement.=C2= =A0 Is that
> > > > > correct, or is 'replace' meant to have equ= ivalent semantics to
> > > > > 'merge' ie it will only replace configurat= ion when an explicit
> > > > > replacement is provided.=C2=A0 In other words, if = the latter case
> > > > > is correct, all it does is remove the requirement = to specify
> > > > > the operation in each
> > element of new config.
> > > >
> > > > Yes the latter is correct.=C2=A0 Note that the definiti= on of "replace"
> > > > as an operation says:
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Unlike a=
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<copy= -config> operation, which replaces the entire target
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configur= ation, only the configuration actually present in
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the <= config> parameter is affected.
> > > >
> > > >
> > > > /martin
> > > >
> > >
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@iet= f.org
> > https://www.ietf.org/mailman/listinfo/netconf
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@iet= f.org
> > https://www.ietf.org/mailman/listinfo/netconf
>
>

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

=C2=A0


--001a11482d6a3ecc830534553eca-- From nobody Tue Jun 7 00:11:24 2016 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 63D1E12D1AF for ; Tue, 7 Jun 2016 00:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 H6UBrNsmXjoU for ; Tue, 7 Jun 2016 00:11:18 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3C812D159 for ; Tue, 7 Jun 2016 00:11:17 -0700 (PDT) Received: from 172.18.9.243 (EHLO lhreml708-cah.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAI23139; Tue, 07 Jun 2016 02:11:15 -0500 (CDT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 7 Jun 2016 08:09:44 +0100 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.0235.001; Tue, 7 Jun 2016 15:09:36 +0800 From: Qin Wu To: Ladislav Lhotka , "Yi Yang (yiya)" Thread-Topic: [Netconf] data format for list entry Thread-Index: AQHRvDMrpNbid4+bfUeprsDZEbYSJ5/VenYAgAA5iQCAAAisAIAH4T1w Date: Tue, 7 Jun 2016 07:09:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.81.46] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Netconf Subject: Re: [Netconf] data format for list entry X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 07:11:22 -0000 QWdyZWUgdG8gaGF2ZSBjb25zaXN0ZW50IHN0cnVjdHVyZSBiZXR3ZWVuIEpTT04gYW5kIFhNTCwg b3RoZXJ3aXNlIGl0IGxvb2tzIEpTT04gYW5kIFhNTCBpcyBub3QgZXhjaGFuZ2VhYmxlLg0KDQot UWluDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IE5ldGNvbmYgW21haWx0bzpu ZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBMYWRpc2xhdiBMaG90a2ENCuWPkemAgeaX tumXtDogMjAxNuW5tDbmnIgy5pelIDIyOjQ3DQrmlLbku7bkuro6IFlpIFlhbmcgKHlpeWEpDQrm ioTpgIE6IE5ldGNvbmYNCuS4u+mimDogUmU6IFtOZXRjb25mXSBkYXRhIGZvcm1hdCBmb3IgbGlz dCBlbnRyeQ0KDQoNCj4gT24gMDIgSnVuIDIwMTYsIGF0IDE2OjE1LCBZaSBZYW5nICh5aXlhKSA8 eWl5YUBjaXNjby5jb20+IHdyb3RlOg0KPiANCj4gSGkgTGFkYSwNCj4gDQo+IFRvIGhhdmUgYSBj b25zaXN0ZW4gc3RydWN0dXJlIGJldHdlZW4gSlNPTiBhbmQgWE1MLCBkb2VzIHRoaXMgaW5kaWNh dGUgDQo+IHRoZSBKU09OIGZvcm1hdCBNU1VUIGFsc28gYmUgd3JhcHBlZCBpbiBhbiBlbGVtZW50 IHdpdGggdGhlIGxpc3QgbmFtZSwgDQo+IGFzIG5vdGVkIGluIG15IHByZXZpb3VzIGVtYWlsPw0K DQpZZXMsIFJFU1RDT05GIGRlc2lnbmVycyBwcmVmZXJyZWQgdG8gaGF2ZSBhIGNvbnNpc3RlbnQg c3RydWN0dXJlLiBUaGlzIHdhcyBhbHJlYWR5IGRpc2N1c3NlZDoNCg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRjb25mL2N1cnJlbnQvbXNnMTEwMjMuaHRtbA0KDQpM YWRhDQoNCj4gDQo+IHsNCj4gICAgwrNsaXN0MsKyOiBbDQo+ICAgICAgICB7DQo+ICAgICAgICAg ICAgwrNrZXk0wrI6IMKza2V5NHbCsiwNCj4gICAgICAgICAgICDCs2tleTXCsjogwrNrZXk1dsKy LA0KPiAgICAgICAgICAgIMKzWMKyOiDCs3hfdmFsdWUiDQo+ICAgICAgICB9DQo+ICAgIF0NCj4g fQ0KPiANCj4gUmVnYXJkbGVzcywgaXQgd291bGQgYmUgZ3JlYXQgdG8gaGF2ZSBzb21lIGNsYXJp ZmljYXRpb25zIG9uIHRoaXMgaW4gDQo+IHRoZSBkcmFmdC4NCj4gDQo+IFlpDQo+IA0KPiANCj4g DQo+IA0KPiANCj4gT24gNi8yLzE2LCA2OjQ5IEFNLCAiTGFkaXNsYXYgTGhvdGthIiA8bGhvdGth QG5pYy5jej4gd3JvdGU6DQo+IA0KPj4gIllpIFlhbmcgKHlpeWEpIiA8eWl5YUBjaXNjby5jb20+ IHdyaXRlczoNCj4+IA0KPj4+IEkgYW0gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgaG93IHRoZSBkYXRh IHNob3VsZCBiZSBmb3JtYXR0ZWQgd2hlbiANCj4+PiB1cGRhdGluZyBhIGxpc3QgZW50cnkuIFVz aW5nIHRoZSBsaXN0IG1vZGVsIHByZXNlbnRlZCBpbiANCj4+PiBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLTEzI3NlY3Rpb24tMw0KPj4+IC41 LjEsIGlmIEkgd2FudCB0byBjcmVhdGUgYW4gZW50cnkgaW4gdGhlIGxpc3QyIHdpdGgga2V5IChr ZXk0diwgDQo+Pj4ga2V5NXYpLCBJIHVuZGVydGFuZCB0aGUgY3JlYXRpb24gcmVxdWVzdCBzaG91 bGQgYmUgZW5jb2RlZCBhczoNCj4+PiANCj4+PiBHRVQNCj4+PiAvcmVzdGNvbmYvZGF0YS9leGFt cGxlLXRvcDp0b3AvbGlzdDE9a2V5MXYsa2V5MnYsa2V5M3YvbGlzdDI9a2V5NHYsaw0KPj4+IGV5 NXYNCj4+PiBBY2NlcHQ6IGFwcGxpY2F0aW9uL3lhbmcuZGF0YStqc29uDQo+Pj4gDQo+Pj4gSW5z aWRlIHRoZSByZXN0IHJlcXVlc3QsIGhvdyB0aGUgZGF0YSB3aWxsIGJlIGVuY2Fwc3VsYXRlZCBp biBqc29uPw0KPj4+IEJhc2VkIG9uIHRoZSBleGFtcGxlIGdpdmVuIGF0DQo+Pj4gDQo+Pj4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi0xMyNh cHBlbmRpeC0NCj4+PiBELjMuOQ0KPj4+ICwNCj4+PiBpdCBzZWVtcyB0aGUgZW50cnkgbmVlZHMg dG8gZW5jb2RlZCBhcyBhIGxpc3QsIGV2ZW4gdGhvdWdoIGl0J3MgYSANCj4+PiBzaW5nbGUgbGlz dCBlbnRyeToNCj4+IA0KPj4gT2gsIEkgbWlzc2VkIHRoaXMgcG9pbnQuIFllcywgaXQgd291bGQg aW5kZWVkIGJlIG1vcmUgbG9naWNhbCB0byBzZW5kIA0KPj4ganVzdCB0aGUgZW50cnksIGkuZS4N Cj4+IA0KPj4gew0KPj4gICAia2V5NCI6ICJrZXk0diIsDQo+PiAgICJrZXk1IjogImtleTV2IiwN Cj4+ICAgIlgiOiAieF92YWx1ZSINCj4+IH0NCj4+IA0KPj4gSG93ZXZlciwgdGhpcyB3b24ndCB3 b3JrIGluIHRoZSBYTUwgZW5jb2Rpbmcgd2hlcmUgZWFjaCBsaXN0IGVudHJ5IGlzIA0KPj4gd3Jh cHBlZCBpbiBhbiBlbGVtZW50IHdpdGggdGhlIGxpc3QgbmFtZToNCj4+IA0KPj4gPGxpc3QyPg0K Pj4gPGtleTQ+a2V5NHY8L2tleTQ+DQo+PiA8a2V5NT5rZXk1djwva2V5NT4NCj4+IDxYPnhfdmFs dWU8L1g+DQo+PiA8L2xpc3QyPg0KPj4gDQo+PiBMYWRhDQo+PiANCj4+PiANCj4+PiB7DQo+Pj4g ICAgImxpc3QyIjogWw0KPj4+ICAgICAgICB7DQo+Pj4gICAgICAgICAgICAia2V5NCI6ICJrZXk0 diIsDQo+Pj4gICAgICAgICAgICAia2V5NSI6ICJrZXk1diIsDQo+Pj4gICAgICAgICAgICAiWCI6 ICJ4X3ZhbHVlIg0KPj4+ICAgICAgICB9DQo+Pj4gICAgXQ0KPj4+IH0NCj4+PiANCj4+PiBJcyB0 aGlzIGNvcnJlY3Q/DQo+Pj4gDQo+Pj4gWWkNCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+Pj4gTmV0 Y29uZkBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0Y29uZg0KPj4gDQo+PiAtLQ0KPj4gTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPj4g UEdQIEtleSBJRDogRTc0RThDMEMNCj4gDQoNCi0tDQpMYWRpc2xhdiBMaG90a2EsIENaLk5JQyBM YWJzDQpQR1AgS2V5IElEOiBFNzRFOEMwQw0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K From nobody Tue Jun 7 00:35:23 2016 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 4D1BA12D159 for ; Tue, 7 Jun 2016 00:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=unavailable 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 6S_z2iInBjDu for ; Tue, 7 Jun 2016 00:35:21 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3ED612D134 for ; Tue, 7 Jun 2016 00:26:58 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F1A1811EB; Tue, 7 Jun 2016 09:26:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id peT0ogDcIim3; Tue, 7 Jun 2016 09:26:55 +0200 (CEST) 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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 7 Jun 2016 09:26:56 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 413E42004E; Tue, 7 Jun 2016 09:26:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hKykLFJMf61T; Tue, 7 Jun 2016 09:26:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B365920047; Tue, 7 Jun 2016 09:26:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0F6B73B0A437; Tue, 7 Jun 2016 09:26:52 +0200 (CEST) Date: Tue, 7 Jun 2016 09:26:52 +0200 From: Juergen Schoenwaelder To: Qin Wu Message-ID: <20160607072652.GA8899@elstar.local> Mail-Followup-To: Qin Wu , Ladislav Lhotka , "Yi Yang (yiya)" , Netconf References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Netconf Subject: Re: [Netconf] data format for list entry X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 07:35:22 -0000 On Tue, Jun 07, 2016 at 07:09:35AM +0000, Qin Wu wrote: > Agree to have consistent structure between JSON and XML, otherwise > it looks JSON and XML is not exchangeable. The truth is that JSON and XML is 'exchangable' only if you have access to the data models. You can't transform XML encoding to JSON encoding or vice versa without having access to the model definition. /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 Jun 7 01:41:45 2016 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 BCB9C12B024 for ; Tue, 7 Jun 2016 01:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 47Rw_OBkCDTs for ; Tue, 7 Jun 2016 01:41:40 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5990712D0B9 for ; Tue, 7 Jun 2016 01:41:39 -0700 (PDT) Received: from 172.18.9.243 (EHLO lhreml701-cah.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQZ21168; Tue, 07 Jun 2016 03:41:36 -0500 (CDT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 7 Jun 2016 09:40:13 +0100 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.0235.001; Tue, 7 Jun 2016 16:40:08 +0800 From: Qin Wu To: Juergen Schoenwaelder Thread-Topic: [Netconf] data format for list entry Thread-Index: AQHRvDMrpNbid4+bfUeprsDZEbYSJ5/VenYAgAA5iQCAAAisAIAH4T1w//9/gQCAAJmjsA== Date: Tue, 7 Jun 2016 08:40:07 +0000 Message-ID: References: <20160607072652.GA8899@elstar.local> In-Reply-To: <20160607072652.GA8899@elstar.local> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.83.159] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Netconf Subject: Re: [Netconf] data format for list entry X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 08:41:43 -0000 RXhhY3RseS4gVGhhbmtzIGZvciBjbGFyaWZpY2F0aW9uLg0KDQotUWluDQotLS0tLdPKvP7Urbz+ LS0tLS0NCreivP7IyzogSnVlcmdlbiBTY2hvZW53YWVsZGVyIFttYWlsdG86ai5zY2hvZW53YWVs ZGVyQGphY29icy11bml2ZXJzaXR5LmRlXSANCreiy83KsbzkOiAyMDE2xOo21MI3yNUgMTU6MjcN CsrVvP7IyzogUWluIFd1DQqzrcvNOiBMYWRpc2xhdiBMaG90a2E7IFlpIFlhbmcgKHlpeWEpOyBO ZXRjb25mDQrW98ziOiBSZTogW05ldGNvbmZdIGRhdGEgZm9ybWF0IGZvciBsaXN0IGVudHJ5DQoN Ck9uIFR1ZSwgSnVuIDA3LCAyMDE2IGF0IDA3OjA5OjM1QU0gKzAwMDAsIFFpbiBXdSB3cm90ZToN Cg0KPiBBZ3JlZSB0byBoYXZlIGNvbnNpc3RlbnQgc3RydWN0dXJlIGJldHdlZW4gSlNPTiBhbmQg WE1MLCBvdGhlcndpc2UgaXQgDQo+IGxvb2tzIEpTT04gYW5kIFhNTCBpcyBub3QgZXhjaGFuZ2Vh YmxlLg0KDQpUaGUgdHJ1dGggaXMgdGhhdCBKU09OIGFuZCBYTUwgaXMgJ2V4Y2hhbmdhYmxlJyBv bmx5IGlmIHlvdSBoYXZlIGFjY2VzcyB0byB0aGUgZGF0YSBtb2RlbHMuIFlvdSBjYW4ndCB0cmFu c2Zvcm0gWE1MIGVuY29kaW5nIHRvIEpTT04gZW5jb2Rpbmcgb3IgdmljZSB2ZXJzYSB3aXRob3V0 IGhhdmluZyBhY2Nlc3MgdG8gdGhlIG1vZGVsIGRlZmluaXRpb24uDQoNCi9qcw0KDQotLSANCkp1 ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdH bWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1 OSBCcmVtZW4gfCBHZXJtYW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRw Oi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg== From nobody Wed Jun 8 13:30:53 2016 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 D20D512B063 for ; Wed, 8 Jun 2016 13:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 9lIOeLF0zwDL for ; Wed, 8 Jun 2016 13:30:49 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7B612B00C for ; Wed, 8 Jun 2016 13:30:49 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id 62so5808685pfd.1 for ; Wed, 08 Jun 2016 13:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=BT8VYPBNbpIaUlM4WwDywN0OB4Ih9XiSTBuZzzkb8xU=; b=0eu2uZXJh707rzYw7knXakgAqDlb0EfJfaZttK+tdF+rSLTomJTs3LND9wQP9TghWE dk923VN3+bYtZN2wYE+T3WxajOjRFSIWRf2xQdUf0MSiTfePhquRITUEnI+uAWJmIJmw vL7VDn7hiszF26rvxDG8rjvXQosveC+3p4lV8h7Deawl32skRWPeZSYlyUkWDeoLE/7D YWdVAh0dZN1sKI4cedGQY0/dqGnIOf0RyGLUS2tCTRyAFQJ+Euculc67d51ptaXjXe98 4Ofx7/w6UdQsVBHLQZXqOjaZb9bTmPuO7RWryP3kpW1W0JDXUod9h/itRTwKa0T7R9+b DkyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=BT8VYPBNbpIaUlM4WwDywN0OB4Ih9XiSTBuZzzkb8xU=; b=cuBe/LJr44v8V9aKNMYUEjGRykL4PROohmCR3or2DTK2QMYaHVAIIyuWRA+keIqtN8 JIqiH87VO5I0BsKAWis0onrWITeBUwZMV1/L040S2bziK47PxMkuhFbO0ZpzPrcIE7KV 3FSH+0Htqfnwgfz3pQO9SJtyOJAIFlu5+dH8Z5gYcKQoYT8DxQE0VQzZKuF/QKTM3swq 7gkLWSmC4x2cRW8oKhFI0XrC5rUSshgV7yDDqneZO0c1x9QIp5AeanpLxldrJymiMKIB oTn+v3VaLw6XSrVdYWXwyiCJD+nHzUbd4xh4+sdD4+xcGN0WrfJg1X1QNRDgUm6XDU80 fSjA== X-Gm-Message-State: ALyK8tK/i3Sp+Ua+Obwv0g16YtXxi2m0Xe/DAgDDqGkU7yoMKkacVtHqnrq1AbJcRrHxNg== X-Received: by 10.98.27.215 with SMTP id b206mr260380pfb.61.1465417849159; Wed, 08 Jun 2016 13:30:49 -0700 (PDT) Received: from ?IPv6:2001:420:290:1330:a570:540b:44bc:d149? ([2001:420:290:1330:a570:540b:44bc:d149]) by smtp.gmail.com with ESMTPSA id bf4sm4485317pac.4.2016.06.08.13.30.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Jun 2016 13:30:48 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E04266DF-2EEF-4149-A1FB-63E3A324AC5C" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Wed, 8 Jun 2016 13:30:57 -0700 Message-Id: <92C0E754-C399-4A93-BDDA-AFCFC5FC667F@gmail.com> References: <3C88D813-7674-47C4-A6AF-E02C368CE71C@juniper.net> <20160429.100226.431840842419129504.mbj@tail-f.com> <20160429081529.GA26297@elstar.local> <20160429.102116.1627845264494578220.mbj@tail-f.com> <00aa01d1a209$2d165a20$4001a8c0@gateway.2wire.net> <9E3A9643-2348-42AA-A6B0-6FB9F13D1A29@juniper.net> <022801d1a456$c20e12e0$4001a8c0@gateway.2wire.net> <92BAF631-804E-45AD-89A3-48059966B2F4@gmail.com> To: Kent Watsen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Confirming the decision to split the server-model draft into several drafts. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 20:30:52 -0000 --Apple-Mail=_E04266DF-2EEF-4149-A1FB-63E3A324AC5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Kent. This confirms the consensus of going with Proposal #3. Kent will go = ahead and split the draft as suggested. > On May 31, 2016, at 5:38 PM, Kent Watsen wrote: >=20 >=20 > Thank you everyone that responded. It appears that the on-list = consensus is to go with Proposal #3, a total of 5 drafts (see below). = If no objections are raised before next Monday, I=E2=80=99ll assume that = this consensus is confirmed and will start making the changes. >=20 >=20 > Here is the 5 drafts and their modules from Proposal #3: >=20 > 1. draft-ietf-netconf-system-keychain > - ietf-system-keychain >=20 > 2. draft-ietf-netconf-ssh-client-server > - ietf-ssh-client =20 > - ietf-ssh-server >=20 > 3. draft-ietf-netconf-tls-client-server > - ietf-tls-client =20 > - ietf-tls-server =20 >=20 > 4. draft-ietf-netconf-netconf-client-server > - ietf-netconf-client =20 > - ietf-netconf-server =20 >=20 > 5. draft-ietf-netconf-restconf-client-server > - ietf-restconf-client =20 > - ietf-restconf-server =20 >=20 >=20 > Thanks, > Kent >=20 >=20 > On 5/27/16, 1:12 PM, "Netconf on behalf of Kent Watsen" = on behalf of = kwatsen@juniper.net > wrote: >=20 >>=20 >>=20 >> On 5/3/16, 7:18 PM, "Mahesh Jethanandani" = wrote: >>=20 >>> It appears that a virtual interim meeting might help this discussion = and the discussion around key-chain models.=20 >>>=20 >>> Consider this a two week notice for the meeting. Details will be = sent out later. >>>=20 >>> Mahesh & Mehmet >>=20 >>=20 >> Okay, we had the interim. The slides I presented then are attached. >>=20 >> Of the various proposals listed in the slides, the interim=E2=80=99s = consensus was to move forward with either proposal #2 or proposal #3 = (slides 8 and 9). The only difference between these proposals is that = #3 splits out the restconf client/server models into its own draft, as = opposed to having them in the same draft with the netconf client/server = models. >>=20 >> Assuming the interim=E2=80=99s consensus is upheld here on list, we = now need to pick between proposals #2 and #3. FWIW, I have a slight = preference for #3 only because I like the consistency of it. Any other = opinions? >>=20 >> Thanks, >> Kent >>=20 >>=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_E04266DF-2EEF-4149-A1FB-63E3A324AC5C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Kent.

This confirms the consensus of going with Proposal #3. Kent = will go ahead and split the draft as suggested.

On = May 31, 2016, at 5:38 PM, Kent Watsen <kwatsen@juniper.net>= wrote:


Thank you everyone = that responded.  It appears that the on-list consensus is to go = with Proposal #3, a total of 5 drafts (see below).   If no = objections are raised before next Monday, I=E2=80=99ll assume that this = consensus is confirmed and will start making the changes.


Here is the 5 drafts and their modules from = Proposal #3:

1. =    draft-ietf-netconf-system-keychain
          &nb= sp;- ietf-system-keychain

2. =    draft-ietf-netconf-ssh-client-server
          &nb= sp;- ietf-ssh-client  
          &nb= sp;- ietf-ssh-server

3. =    draft-ietf-netconf-tls-client-server
          &nb= sp;- ietf-tls-client  
          &nb= sp;- ietf-tls-server  

4. =    draft-ietf-netconf-netconf-client-server
          &nb= sp;- ietf-netconf-client  
          &nb= sp;- ietf-netconf-server  

5. =    draft-ietf-netconf-restconf-client-server
          &nb= sp;- ietf-restconf-client  
          &nb= sp;- ietf-restconf-server  


Thanks,
Kent


On 5/27/16, 1:12 PM, "Netconf on behalf of Kent = Watsen" <netconf-bounces@ietf.org on behalf of kwatsen@juniper.net> wrote:



On 5/3/16, 7:18 PM, = "Mahesh Jethanandani" <mjethanandani@gmail.com> wrote:

It appears that a = virtual interim meeting might help this discussion and the discussion = around key-chain models. 

Consider this a two week notice for the meeting. Details will = be sent out later.

Mahesh & Mehmet


Okay, we had the = interim.  The slides I presented then are attached.
Of the various proposals listed in the slides, the = interim=E2=80=99s consensus was to move forward with either proposal #2 = or proposal #3 (slides 8 and 9).  The only difference between these = proposals is that #3 splits out the restconf client/server models into = its own draft, as opposed to having them in the same draft with the = netconf client/server models.

Assuming the = interim=E2=80=99s consensus is upheld here on list, we now need to pick = between proposals #2 and #3.   FWIW, I have a slight preference for = #3 only because I like the consistency of it.  Any other = opinions?

Thanks,
Kent



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

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_E04266DF-2EEF-4149-A1FB-63E3A324AC5C-- From nobody Wed Jun 8 18:20:21 2016 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 E435512D66D; Wed, 8 Jun 2016 18:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 w8mTVZ13540u; Wed, 8 Jun 2016 18:20:18 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::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 5B16812D0B7; Wed, 8 Jun 2016 18:20:18 -0700 (PDT) Received: by mail-pa0-x236.google.com with SMTP id hl6so7497666pac.2; Wed, 08 Jun 2016 18:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=YChotIDdyJEXDsOETm38C4wpgNPAGPuMrOcEO1rfrsE=; b=SaoVrrwmLAzxBIH+m+DfNGXNl4kF75eCzSDOOtFBnggFtXGd/X/c+YLnVqLU1GVZMS j8gg1tt+K16SlpMRwSq6YIhl/zAx3TKCdTviSl7XVCiTZRNxgDdDNPwrCsWivtNl5aPU 9zUMWEk+ZFE/EZhnB9mjqiYNon9vcs9LxOONf4rooHRNExrKzHmnT3HcKeJmmzLOrjdF jRSvrU/AezHSwCogQjKp702W57Nwa5LY1Z8O6VQNGLjCQW2lpC0p5tr2GgeJbGzzLj7C ihGFOy9Z21M6xaH7LfBIN2fuqeWgw9cblk+XOcmoG/TadVURQVVwJ/LU97uXH2l/WLWW 2cRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=YChotIDdyJEXDsOETm38C4wpgNPAGPuMrOcEO1rfrsE=; b=gSBW9kZnbiTnoIG+zvXT0KAXIRVFW1eklvDo50f+2tsK2JKw3crFLUf26Xj2ZiRaAc B3KW4BRANo0I1AkFwRvAYA6enFJrAJPqOpY58jDYMlDRXe+LNh0Po12LzymmNKXjZyL/ kjpAzfafZdRO6H5f4pqTden85Ulc6kYHAXOy5OrGAL2YbS8h0CTzieyKQo1B44/v6tes x41kOR8h3E3RSBqEj+uxdrLeiJtI1C2bkoVuTSJmtYz9fqd7No86BkfvoVDoSrWJq5wT QVmm1SIxK6YaPqj4rS9AHsZ5PaBOg2TyNpMlmIdBJza7GAjORSiHjn04TBALRA7gArre 8Clg== X-Gm-Message-State: ALyK8tJpe1wXCU6M7jr6LefXopSVKCWgqMetPPY9RrwKbwMGcfGL7iLECcyajnVT24KpAg== X-Received: by 10.66.62.196 with SMTP id a4mr8853134pas.25.1465435217777; Wed, 08 Jun 2016 18:20:17 -0700 (PDT) Received: from [10.24.45.227] ([128.107.241.184]) by smtp.gmail.com with ESMTPSA id i65sm5090167pfk.84.2016.06.08.18.20.15 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Jun 2016 18:20:16 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_62A747BC-9AFF-4C34-A4B5-33309127E467" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Wed, 8 Jun 2016 18:20:15 -0700 Message-Id: References: <20160601213426.C34A7B80EA5@rfc-editor.org> <50fdaaa4-3b30-3254-3dcf-3db115f0bd78@cisco.com> <78F3FE3C-5413-488F-B669-AE9ECEA1A74E@gmail.com> <8D2A4656-481A-4359-84FB-C2961141C7E1@juniper.net> <8CE8391A-AA80-4DCF-9D8B-063DDDC67CDC@juniper.net> <95174A92-E35C-4652-A4FF-3DCBC5EB1752@gmail.com> <458b25ce-0b7a-cf7f-34df-38b608b6cc30@cisco.com> To: Netconf X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "netconf-chairs@ietf.org" , "netconf-ads@ietf.org" , RFC Editor Subject: Re: [Netconf] AUTH48 [DF][RV]: RFC 7895 NOW AVAILABLE X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 01:20:20 -0000 --Apple-Mail=_62A747BC-9AFF-4C34-A4B5-33309127E467 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The authors of draft-ietf-netconf-yang-library are making one more = change to the module. See details below. This begins a 1 week poll to address any concerns folks might have with = this change. This is not a chance to review the whole document. Thanks. > On Jun 8, 2016, at 5:00 PM, Andy Bierman wrote: >=20 > Hi, >=20 > We decided to remove the submodules container: >=20 >=20 > 1) YANG module:=20 > 1.1) update revision date (also date > 1.2) remove container submodules from grouping >=20 > OLD: >=20 > container submodules { > description > "Contains information about all the submodules used > by the parent module entry"; >=20 > list submodule { > key "name revision"; > description > "Each entry represents one submodule within the > parent module."; > uses common-leafs; > uses schema-leaf; > } > } >=20 > NEW: >=20 > list submodule { > key "name revision"; > description > "Each entry represents one submodule within the > parent module."; > uses common-leafs; > uses schema-leaf; > } >=20 > 2) YANG tree diagram > 2.1 remove submodules > 2.2 Should the notification be listed? If not, remove from NEW: >=20 > OLD: >=20 >=20 > +--ro modules-state > +--ro module-set-id string > +--ro module* [name revision] > +--ro name yang:yang-identifier > +--ro revision union > +--ro schema? inet:uri > +--ro namespace inet:uri > +--ro feature* yang:yang-identifier > +--ro deviation* [name revision] > | +--ro name yang:yang-identifier > | +--ro revision union > +--ro conformance-type enumeration > +--ro submodules > +--ro submodule* [name revision] > +--ro name yang:yang-identifier > +--ro revision union > +--ro schema? inet:uri >=20 > NEW: >=20 > +--ro modules-state > +--ro module-set-id string > +--ro module* [name revision] > +--ro name yang:yang-identifier > +--ro revision union > +--ro schema? inet:uri > +--ro namespace inet:uri > +--ro feature* yang:yang-identifier > +--ro deviation* [name revision] > | +--ro name yang:yang-identifier > | +--ro revision union > +--ro conformance-type enumeration > +--ro submodule* [name revision] > +--ro name yang:yang-identifier > +--ro revision union > +--ro schema? inet:uri > notifications: > +---n yang-library-change > +--ro module-set-id -> /modules-state/module-set-id >=20 >=20 > Andy Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_62A747BC-9AFF-4C34-A4B5-33309127E467 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The authors of draft-ietf-netconf-yang-library are making one = more change to the module. See details below.

This begins a 1 week poll to address = any concerns folks might have with this change. This is not a chance to = review the whole document.

Thanks.

On Jun 8, 2016, at 5:00 PM, = Andy Bierman <andy@yumaworks.com> wrote:

Hi,

We = decided to remove the submodules container:


1) = YANG module: 
   1.1) update = revision date (also <CODE BEGINS> date
  =  1.2) remove container submodules from grouping

    =  OLD:

      container submodules {
        description
          "Contains information = about all the submodules used
      =      by the parent module entry";

        list = submodule {
          key = "name revision";
          = description
          =   "Each entry represents one submodule within the
             parent = module.";
          uses = common-leafs;
          = uses schema-leaf;
        = }
      }

      = NEW:

      list submodule {
        key "name revision";
        description
          "Each entry represents one = submodule within the
        =    parent module.";
      =   uses common-leafs;
      =   uses schema-leaf;
      = }

 2)= YANG tree diagram
     2.1 remove = submodules
     2.2 Should the = notification be listed? If not, remove from NEW:

OLD:


   +--ro modules-state
  =     +--ro module-set-id    string
      +--ro module* [name revision]
         +--ro name     =               = yang:yang-identifier
        =  +--ro revision               = union
         +--ro = schema?               =  inet:uri
        =  +--ro namespace             =  inet:uri
        =  +--ro feature*               = yang:yang-identifier
        =  +--ro deviation* [name revision]
  =        |  +--ro name       =  yang:yang-identifier
      =    |  +--ro revision    union
         +--ro conformance-type =       enumeration
    =      +--ro submodules
    =         +--ro submodule* [name revision]
               +--ro = name        yang:yang-identifier
               +--ro = revision    union
      =          +--ro schema?     = inet:uri

NEW:

   +--ro modules-state
      +--ro module-set-id   =  string
      +--ro module* = [name revision]
        =  +--ro name               =  yang:yang-identifier
      =    +--ro revision           =  union
         +--ro = schema?             inet:uri
         +--ro namespace   =         inet:uri
    =      +--ro feature*           =  yang:yang-identifier
      =    +--ro deviation* [name revision]
  =        |  +--ro name       =  yang:yang-identifier
      =    |  +--ro revision    union
         +--ro conformance-type =    enumeration
      =    +--ro submodule* [name revision]
  =           +--ro name       =  yang:yang-identifier
      =       +--ro revision    union
            +--ro schema? =     inet:uri
notifications:
   +---n yang-library-change
      +--ro module-set-id    -> = /modules-state/module-set-id


Andy

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_62A747BC-9AFF-4C34-A4B5-33309127E467-- From nobody Thu Jun 9 08:41:27 2016 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 B62F412D0DC for ; Thu, 9 Jun 2016 08:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 7SniA1qwNa8A for ; Thu, 9 Jun 2016 08:41:23 -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 34D0F12D13B for ; Thu, 9 Jun 2016 08:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12702; q=dns/txt; s=iport; t=1465486883; x=1466696483; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=FnYmAT2zYduUR0yT8wBBsWjoZNWOzvT9+N0MMvZzpUU=; b=a8VOXuz1fFcpwvicDSQTlmZCdaNQzcUma11gOYrBCM7qf5xCsJMdXmkt I809PT9AVsMMZCMcqAo+jtSURUr8VmhniPG3lIalFIhRJpRtDWLxZ+F2c gRaG1l6CAEqae4euYXDmfRPEDO2JTji5D4z58mC6i62ZDjLKBfECCWP3k k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DjBADljVlX/xbLJq1ehBQrUrYbgnCEC?= =?us-ascii?q?SSFbwKCAQEBAQEBAWYnhEUBAQEEI2YcAwECKwICTQIIBg0GAgEBBQsCBogTDgO?= =?us-ascii?q?tF5EIAQEBAQEBAQMBAQEBAQEBAR+ECYIegXcIgk6CWYFzFIJhglkFiXKOY4YDi?= =?us-ascii?q?CSCN4cNhVyPZVSDcDoyAYoHAQEB?= X-IronPort-AV: E=Sophos;i="5.26,445,1459814400"; d="scan'208,217";a="636099020" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jun 2016 15:41:11 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u59FfAkR003106 for ; Thu, 9 Jun 2016 15:41:10 GMT References: To: NETCONF From: Benoit Claise X-Forwarded-Message-Id: Message-ID: Date: Thu, 9 Jun 2016 17:41:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------177A638DA67C3727E93DC909" Archived-At: Subject: [Netconf] Fwd: YANG Model Coordination Group directory closure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 15:41:26 -0000 This is a multi-part message in MIME format. --------------177A638DA67C3727E93DC909 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Forwarded Message -------- Subject: YANG Model Coordination Group directory closure Date: Thu, 9 Jun 2016 17:35:07 +0200 From: Benoit Claise To: IETF-Discussion list , yang-coord@ietf.org Dear all, The YANG Model Coordination Group has been a success, and has served its purpose. The plan and the time commitment (each person committed to spend 1/3 of his time) for this group were ambitious: * Phase 1: List of the YANG models (inventory) * Phase 2: Tooling * Phase 3: Help with compilation * Phase 4: Training & Education * Phase 5: Coordination across SDOs/Opensource * Phase 6: Model Coordination within the IETF * Phase 7: Standardization Priorities Let's review the achievements. Quiet impressive for a couple of volunteers if you ask me. Phase 1: List of the YANG models (inventory) Extracted all YANG data models from IETF drafts and RFCs on http://www.claise.be/ Started to work on YANG data model catalog for the industry Phase 2: Tooling YANG data models extraction from drafts/RFCs YANG data models dependency visualization YANG data model grouping extraction and compilation Created http://www.yangvalidator.org/ pyang integration in idnits/tracker pyang plugin for the YANG data model catalog Along the process we filed a couple of pyang bugs Organized the YANG track at the IETF Hackathon etc. Phase 3: Help with compilation Proactively contacted the IETF draft authors, discussing their compilation error messages Kept track of the situation here Flagged the duplicate YANG module names, groupings, etc. Phase 4: Training & Education Created some training materials, presented at IETF94 NETCONF Slides , YANG Slides , pyang Slides Phase 5: Coordination across SDOs/Opensource Coordinated with the IEEE/MEF/BBF, amongst others Worked on the YANG Data Model Classification, accepted as NETMOD WG document Based on github, we're compiling the IEEE/BBF/Opendaylight/openconfig data models Helped on URN for different SDOs YANG Modeling Efforts in the Industry Phase 6: Model Coordination within the IETF We helped with the coordination, even if the YANG routing design team contributed significantly for the routing aspects. Phase 7: Standardization Priorities This is maybe where we haven't had enough time to dedicate, even if we have identified the next steps. See YANG Data Models in the Industry: Current State of Affairs I probably missed some of the achievements. Sorry about that. Let's analyze the current situation! It's difficult, in a voluntary-based organization to dedicate so much time on this YANG effort. On the other hand, this group efforts helped with the heavy-lifting job to promote YANG in the industry. Thanks for that. These days, even if it doesn't translate yet in many RFC numbers, YANG became a mature technology, which can now rely on a bigger community. I expect that the YANG doctors to take over some of the effort here, helping with the proactive review of YANG data models. More on this later. Regarding the tooling aspects, the IETF hackathon will continue to play an important role: a couple of people signed up already Thanks to Carl, Dean, and Qin as YANG Model Coordination Group members, and to many others who helped directly or indirectly. I will now request to close this directorate. Regards, Benoit (OPS AD) --------------177A638DA67C3727E93DC909 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit FYI


-------- Forwarded Message --------
Subject: YANG Model Coordination Group directory closure
Date: Thu, 9 Jun 2016 17:35:07 +0200
From: Benoit Claise <bclaise@cisco.com>
To: IETF-Discussion list <ietf@ietf.org>, yang-coord@ietf.org <yang-coord@ietf.org>


Dear all,

The YANG Model Coordination Group has been a success, and has served its purpose.

The plan and the time commitment (each person committed to spend 1/3 of his time) for this group were ambitious:
  • Phase 1: List of the YANG models (inventory)
  • Phase 2: Tooling
  • Phase 3: Help with compilation
  • Phase 4: Training & Education
  • Phase 5: Coordination across SDOs/Opensource
  • Phase 6: Model Coordination within the IETF
  • Phase 7: Standardization Priorities
Let's review the achievements. Quiet impressive for a couple of volunteers if you ask me.

Phase 1: List of the YANG models (inventory)
    Extracted all YANG data models from IETF drafts and RFCs on http://www.claise.be/
    Started to work on YANG data model catalog for the industry

Phase 2: Tooling
    YANG data models extraction from drafts/RFCs
    YANG data models dependency visualization
    YANG data model grouping extraction and compilation
    Created http://www.yangvalidator.org/
    pyang integration in idnits/tracker
    pyang plugin for the YANG data model catalog
    Along the process we filed a couple of pyang bugs
    Organized the YANG track at the IETF Hackathon
    etc.

Phase 3: Help with compilation
    Proactively contacted the IETF draft authors, discussing their compilation error messages
    Kept track of the situation here
    Flagged the duplicate YANG module names, groupings, etc.

Phase 4: Training & Education
    Created some training materials, presented at IETF94
    NETCONF Slides, YANG Slides, pyang Slides

Phase 5: Coordination across SDOs/Opensource
    Coordinated with the IEEE/MEF/BBF, amongst others
    Worked on the YANG Data Model Classification, accepted as NETMOD WG document
    Based on github, we're compiling the IEEE/BBF/Opendaylight/openconfig data models
    Helped on URN for different SDOs
    YANG Modeling Efforts in the Industry

Phase 6: Model Coordination within the IETF
    We helped with the coordination, even if the YANG routing design team
    contributed significantly for the routing aspects.

Phase 7: Standardization Priorities
    This is maybe where we haven't had enough time to dedicate,
    even if we have identified the next steps.
    See YANG Data Models in the Industry: Current State of Affairs

I probably missed some of the achievements. Sorry about that.

Let's analyze the current situation!
It's difficult, in a voluntary-based organization to dedicate so much time on this YANG effort. On the other hand, this group efforts helped with the heavy-lifting job to promote YANG in the industry. Thanks for that. These days, even if it doesn't translate yet in many RFC numbers, YANG became a mature technology, which can now rely on a bigger community.
I expect that the YANG doctors to take over some of the effort here, helping with the proactive review of YANG data models. More on this later.
Regarding the tooling aspects, the IETF hackathon will continue to play an important role: a couple of people signed up already

Thanks to Carl, Dean, and Qin as YANG Model Coordination Group members, and to many others who helped directly or indirectly.

I will now request to close this directorate.

Regards, Benoit (OPS AD)
--------------177A638DA67C3727E93DC909-- From nobody Fri Jun 10 04:44:04 2016 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 D211912B02D for ; Fri, 10 Jun 2016 04:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-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 bwex9PgIrIVt for ; Fri, 10 Jun 2016 04:44:00 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 205AF12B017 for ; Fri, 10 Jun 2016 04:44:00 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 54323A2; Fri, 10 Jun 2016 13:43:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1465559029; bh=3wMd1nfQ+j8uLu14Dfnx/HbtQxSPzYQuTt1gdCwh2ow=; h=Date:From:To:Subject:From; b=FxqSRPLin31hlD9eOdYPxS57HYjzJHtC1Zsh0kAch80iSn53HexngRtWFtBafDsoj g0rz3cDu/ZJYL0AmkC7/92xjXO7vDZQLvtiup2Q+W3ZlrjHXEsnVb+EPddavo0+M3v cYVmPmjR6cH63DWIRL+yW2T+fx5tRD+CD5nP8PnY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 43F78A1 for ; Fri, 10 Jun 2016 13:43:49 +0200 (CEST) Date: Fri, 10 Jun 2016 13:43:49 +0200 (CEST) From: Mikael Abrahamsson To: netconf@ietf.org Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: [Netconf] Announcement of Sysrepo project Netconf/YANG datastore project participation in IETF96 Hackathon X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 11:44:03 -0000 Hello. Sysrepo (http://www.sysrepo.org) is a free open source project that aims to provide infrastructure to make devices/applications manageable using Netconf/YANG. Development is done using Github. Mailing lists are available here at (http://lists.sysrepo.org/listinfo). Currently it consists of Netopeer2 (Netconf Server), Sysrepod (data store daemon), Libyang (YANG validation library) and other components for testing etc. Sysrepo is right now under development, but what's already finished is support for configuration data (running/startup) and RPCs. In the upcoming months there will be support for operational data, notifications, commit/confirm, and changes to support YANG 1.1. We also plan to add more programming language bindings for applications that are controlled via Sysrepo. You can also use the Sysrepo libraries for standalone mode without having a deamon running, just using files on disk for the configuraton. Currently development target platforms are OpenWrt and other Linux operating systems, but the goal is to be platform independent. We're in the process of migrating previous work that created support for multiple IETF standards model, to the new APIs. Multiple Sysrepo developers/participants will be available at the Hackathon at IETF96 to assist if there are any questions in how to get started with Sysrepo, and we're currently talking to multiple parties who will be attending and doing work on adopting applications to speak to Sysrepo. We have for instance done an example modification of "dnsmasq" to store its configuraiton in Sysrepo and make it configurable by external means using Netconf: https://github.com/sysrepo/dnsmasq-sysrepo Announcement including asciinema "video" here: http://lists.sysrepo.org/archives/sysrepo-devel/2016-June/000103.html We'd be happy to answer any further questions or thoughts/improvement suggestions, either here, privately or if you subscribe to the Sysrepo mailing lists and ask the questions there. Thanks! -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sat Jun 11 11:27:11 2016 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 E1CC012D853 for ; Sat, 11 Jun 2016 11:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-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 LDT1BWLgygqi for ; Sat, 11 Jun 2016 11:27:07 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::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 8383D12D85B for ; Sat, 11 Jun 2016 11:27:05 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id v76so18920905qgv.3 for ; Sat, 11 Jun 2016 11:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=mx91J6W3L09MoCqNqBa6cljaS/gN0pw6OW0W9i9amK8=; b=xcJ0dyR4qbqP8ALApPg4RODNrATWUHhZVARlSv76muUvBTXlhRc3BkZooiD1//Beaa yn6brMYAdx8CYeqmf3SlvgTnIr096k7KySBVJdESwYFRkkL/pv3L6Dp3oB2nHxNQLg/k VZVXrwfNmLLVVEADMhHe6AAcdUHgAiU2NXp/jS5ruHP0M6iu/zR7ZI/+reU4qlJKFIJU 0v846ldu71qmlqp3FnTUn7zC+pXlnu8iXw8RPsfa7PIW0TcSMS0pepCEmxf5vR+WscR2 onYeBB3X7oTbarAnSKWBcLgDzC2Ym1LH0PNYMHwb2fnSxVHqr2ZkHWSMg5fjT2rsAC37 H5Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=mx91J6W3L09MoCqNqBa6cljaS/gN0pw6OW0W9i9amK8=; b=Lwenserf+ccZE2OmYJ1FnLDwb3KKLN9LXMKEkJ3tTGeVE6MlMe161C0oifh1W27g5K w1/n+i57B5sF7dRP/twzMuGcw4Ipm6sbq+aDist+k7WQ1GEsWjWlL1HO/NK8jUC20Lnp h6YqaBUOJDczRqw5dEl7PvfEh1uhg8G6r/ru3uTamuF9vN2yNE/C3HxEe/xX9o5fKCDX n4svgzULjyp42blLR4sJWRfZY2Zmf7MnWOM662N8tAipFzGIIQ6MZSH8/qI5b6B77tIw eM816fQwX3ltO4+yhEMPIlucrl9Y8DbG2dT14cofUmOsgBVZwaRzlbwpPTFey/XhPUeS yrWQ== X-Gm-Message-State: ALyK8tKlpkqa+zAH81h+vBhUMiULrt5SSGryzqgXifSoNBu27vwu7AJ7+8jWBMLeakJoPN4L+rvLj4YnQDz66w== MIME-Version: 1.0 X-Received: by 10.141.44.69 with SMTP id v66mr2750903qhe.74.1465669624553; Sat, 11 Jun 2016 11:27:04 -0700 (PDT) Received: by 10.200.56.16 with HTTP; Sat, 11 Jun 2016 11:27:04 -0700 (PDT) In-Reply-To: References: <20160601213426.C34A7B80EA5@rfc-editor.org> <50fdaaa4-3b30-3254-3dcf-3db115f0bd78@cisco.com> <78F3FE3C-5413-488F-B669-AE9ECEA1A74E@gmail.com> <8D2A4656-481A-4359-84FB-C2961141C7E1@juniper.net> <8CE8391A-AA80-4DCF-9D8B-063DDDC67CDC@juniper.net> <95174A92-E35C-4652-A4FF-3DCBC5EB1752@gmail.com> <458b25ce-0b7a-cf7f-34df-38b608b6cc30@cisco.com> Date: Sat, 11 Jun 2016 11:27:04 -0700 Message-ID: From: Andy Bierman To: Mahesh Jethanandani Content-Type: multipart/alternative; boundary=94eb2c0bdc5c547dce053504cdff Archived-At: Cc: "netconf-chairs@ietf.org" , "netconf-ads@ietf.org" , Netconf , RFC Editor Subject: Re: [Netconf] AUTH48 [DF][RV]: RFC 7895 NOW AVAILABLE X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 18:27:09 -0000 --94eb2c0bdc5c547dce053504cdff Content-Type: text/plain; charset=UTF-8 Hi, I noticed that the YANG library example in RESTCONF-13 does not have the 'submodules' container https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#appendix-D.1.2 I think this was a missed edit in the ietf-yang-library module Andy On Wed, Jun 8, 2016 at 6:20 PM, Mahesh Jethanandani wrote: > The authors of draft-ietf-netconf-yang-library are making one more change > to the module. See details below. > > This begins a 1 week poll to address any concerns folks might have with > this change. This is not a chance to review the whole document. > > Thanks. > > On Jun 8, 2016, at 5:00 PM, Andy Bierman wrote: > > Hi, > > We decided to remove the submodules container: > > > 1) YANG module: > 1.1) update revision date (also date > 1.2) remove container submodules from grouping > > OLD: > > container submodules { > description > "Contains information about all the submodules used > by the parent module entry"; > > list submodule { > key "name revision"; > description > "Each entry represents one submodule within the > parent module."; > uses common-leafs; > uses schema-leaf; > } > } > > NEW: > > list submodule { > key "name revision"; > description > "Each entry represents one submodule within the > parent module."; > uses common-leafs; > uses schema-leaf; > } > > 2) YANG tree diagram > 2.1 remove submodules > 2.2 Should the notification be listed? If not, remove from NEW: > > OLD: > > > +--ro modules-state > +--ro module-set-id string > +--ro module* [name revision] > +--ro name yang:yang-identifier > +--ro revision union > +--ro schema? inet:uri > +--ro namespace inet:uri > +--ro feature* yang:yang-identifier > +--ro deviation* [name revision] > | +--ro name yang:yang-identifier > | +--ro revision union > +--ro conformance-type enumeration > +--ro submodules > +--ro submodule* [name revision] > +--ro name yang:yang-identifier > +--ro revision union > +--ro schema? inet:uri > > NEW: > > +--ro modules-state > +--ro module-set-id string > +--ro module* [name revision] > +--ro name yang:yang-identifier > +--ro revision union > +--ro schema? inet:uri > +--ro namespace inet:uri > +--ro feature* yang:yang-identifier > +--ro deviation* [name revision] > | +--ro name yang:yang-identifier > | +--ro revision union > +--ro conformance-type enumeration > +--ro submodule* [name revision] > +--ro name yang:yang-identifier > +--ro revision union > +--ro schema? inet:uri > notifications: > +---n yang-library-change > +--ro module-set-id -> /modules-state/module-set-id > > > Andy > > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > > > --94eb2c0bdc5c547dce053504cdff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I noticed that the YANG library exa= mple in RESTCONF-13 does not
have the 'submodules' contai= ner


I t= hink this was a missed edit in the ietf-yang-library module

<= /div>

Andy


On Wed, Jun 8, 2016 at 6:20 PM, Mahe= sh Jethanandani <mjethanandani@gmail.com> wrote:
The author= s of draft-ietf-netconf-yang-library are making one more change to the modu= le. See details below.

This begins a 1 week poll to addr= ess any concerns folks might have with this change. This is not a chance to= review the whole document.

Thanks.

=
On Jun 8, 2016, at 5:00 PM, Andy Bierma= n <andy@yumawork= s.com> wrote:

Hi,

= We decided to remove the submodules container:

1) YANG module:=C2=A0
=C2=A0 =C2=A01.1) update revisi= on date (also <CODE BEGINS> date
=C2=A0 =C2=A01.2) remove c= ontainer submodules from grouping

=C2=A0 =C2=A0 = =C2=A0OLD:

=C2=A0 =C2=A0 =C2=A0 container sub= modules {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 description
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Contains information about all the su= bmodules used
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by the par= ent module entry";

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 list submodule {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key "= ;name revision";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 descript= ion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Each entry re= presents one submodule within the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0parent module.";
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 uses common-leafs;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = uses schema-leaf;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 = =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 NEW:

=C2=A0 =C2=A0 =C2=A0 list submodule {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 key "name revision";
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 "Each entry represents one submodule within the
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0parent module.";
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 uses common-leafs;
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 uses schema-leaf;
=C2=A0 =C2=A0 =C2=A0 }
<= br>
=C2=A02) YANG tree diagram
=C2=A0 =C2=A0 =C2=A02.1 = remove submodules
=C2=A0 =C2=A0 =C2=A02.2 Should the notification= be listed? If not, remove from NEW:

OLD:


=C2=A0 =C2=A0+--ro modules-state
=
=C2=A0 =C2=A0 =C2=A0 +--ro module-set-id =C2=A0 =C2=A0string
=C2=A0 =C2=A0 =C2=A0 +--ro module* [name revision]
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0+--ro name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 yang:yang-identifier
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0+--ro revision =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 union
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro schema? =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0inet:uri
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro namespace =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0inet:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro= feature* =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:yang-identi= fier
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro deviation* [name rev= ision]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0+--ro name =C2= =A0 =C2=A0 =C2=A0 =C2=A0yang:yang-identifier
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0| =C2=A0+--ro revision =C2=A0 =C2=A0union
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro conformance-type =C2=A0 =C2=A0 =C2=A0 enum= eration
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro submodules
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro submodule* [name revisi= on]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro = name =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:yang-identifier
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro revision =C2=A0 =C2=A0un= ion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro = schema? =C2=A0 =C2=A0 inet:uri

NEW:

=C2=A0 =C2=A0+--ro modules-state
=C2=A0 =C2= =A0 =C2=A0 +--ro module-set-id =C2=A0 =C2=A0string
=C2=A0 =C2=A0 = =C2=A0 +--ro module* [name revision]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+--ro name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yan= g:yang-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro revisio= n =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0union
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+--ro schema? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= inet:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro namespace =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet:uri
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+--ro feature* =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:yang= -identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro deviation* [n= ame revision]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0+--ro nam= e =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:yang-identifier
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0+--ro revision =C2=A0 =C2=A0union
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro conformance-type =C2=A0 =C2=A0enumerat= ion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro submodule* [name revi= sion]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro name =C2=A0= =C2=A0 =C2=A0 =C2=A0yang:yang-identifier
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +--ro revision =C2=A0 =C2=A0union
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro schema? =C2=A0 =C2=A0 inet:uri
<= div>notifications:
=C2=A0 =C2=A0+---n yang-library-change
=C2=A0 =C2=A0 =C2=A0 +--ro module-set-id =C2=A0 =C2=A0-> /modules-sta= te/module-set-id


Andy

Mahesh Jethanandani






--94eb2c0bdc5c547dce053504cdff-- From nobody Sun Jun 12 14:57:13 2016 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 DB98612D6B8; Sun, 12 Jun 2016 14:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 rqWKds7Oh9m5; Sun, 12 Jun 2016 14:57:08 -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 8F8B712D732; Sun, 12 Jun 2016 14:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22125; q=dns/txt; s=iport; t=1465768628; x=1466978228; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/qFtiPTyrzS45JtPtqAJ2qoFgE7QaCRa7IBCr1C53us=; b=EevdxmMcByeut5JIBxovv0r9gEQ0cSwleneUmACpmcwa/JJdT25/bKKf JVBL/NWMx1krvzX96tFLQHttCxuvwXJfpO4VbN9Xj2/KrtjRX7FwjTSAI oBrTgM6/Mtj26x+Ny1JsfS5mtgkMAZhbr9jqCF7ctmdMx2/FsdKAesi0a 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgBF2l1X/5JdJa1dgnBOVn0Grx6HA?= =?us-ascii?q?IUAgXkdhTBKAhyBBzgUAQEBAQEBAWUnhEoBAQEEI1YQAgEIDgMDAQIoAwICAh8?= =?us-ascii?q?RFAkIAgQOBYgWAxcOrEOMLg2DfgEBAQEBAQEBAQEBAQEBAQEBAQEBHYp0gkOBZ?= =?us-ascii?q?zaCYYJaBY1uij80AYwtgXqBaYRSiGWGSIE5h2wBHjaCBxyBS24BAYkHfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,463,1459814400"; d="scan'208,217";a="284091067" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jun 2016 21:57:07 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u5CLv6Nr011825 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 12 Jun 2016 21:57:06 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 12 Jun 2016 17:57:05 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Sun, 12 Jun 2016 17:57:05 -0400 From: "Acee Lindem (acee)" To: Kent Watsen Thread-Topic: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09 Thread-Index: AQHRifX44uk/iivOuEmrTCpBJDXsvZ99sTmAgAKen+KAD4/+AIAAOu0AgAB6U4D//9OoAIASoseAgEPLQYA= Date: Sun, 12 Jun 2016 21:57:05 +0000 Message-ID: References: <20160329.212556.1290892363387952983.mbj@tail-f.com> <3D60808E-EB76-4BE9-8281-B91B4FD83527@juniper.net> <021201d191b1$757fbe40$4001a8c0@gateway.2wire.net> <64FFAE09-4DF0-4D87-ADCF-2A319DB4F684@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.53.251] Content-Type: multipart/alternative; boundary="_000_D383521F642C9aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" , Routing WG , "draft-ietf-rtgwg-keychain@ietf.org" Subject: Re: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 21:57:12 -0000 --_000_D383521F642C9aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gYWJvdXQgdG8gdXBkYXRlIHRoaXMga2V5LWNoYWluIG1vZHVsZSBhbmQgd291bGQgbGlr ZSB0byByZXN0b3JlIHRoZSBuYW1lIG9mIHNpbXBseSBrZXktY2hhaW4gc2luY2UgSeKAmXZlIHJl Y2VpdmVkIG5lZ2F0aXZlIGZlZWRiYWNrIG9uIHRoZSB0aGUgY2hhbmdlIHRvIHJvdXRpbmcta2V5 LWNoYWluIHNpbmNlIGl0IHdpbGwgbGlrZWx5IGJlIHVzZWQgZm9yIGEgbXlyaWFkIG9mIG5vbi1y b3V0aW5nIGFwcGxpY2F0aW9ucy4NCg0KS2VudCAtIHdvdWxkIHlvdSBiZSBvcHBvc2VkIHRvIHRo aXM/IE5vdGUgdGhhdCB5b3VyIGNvbXBhbnnigJlzIHByb2R1Y3RzIHJlZmVyIHRvIGl0IGFzIHNp bXBseSDigJxrZXktY2hhaW7igJ0uDQoNCmh0dHA6Ly93d3cuanVuaXBlci5uZXQvZG9jdW1lbnRh dGlvbi9lbl9VUy9qdW5vczE0LjIvdG9waWNzL3JlZmVyZW5jZS9jb25maWd1cmF0aW9uLXN0YXRl bWVudC9rZXktY2hhaW4tZWRpdC1zZWN1cml0eS1hdXRoZW50aWNhdGlvbi1rZXktY2hhaW5zLmh0 bWwNCg0KDQpGcm9tOiBydGd3ZyA8cnRnd2ctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRnd2ct Ym91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBBY2VlIExpbmRlbSA8YWNlZUBjaXNjby5j b208bWFpbHRvOmFjZWVAY2lzY28uY29tPj4NCkRhdGU6IFNhdHVyZGF5LCBBcHJpbCAzMCwgMjAx NiBhdCAyOjQwIFBNDQpUbzogTWFoZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFp bC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPj4NCkNjOiAiZHJhZnQtaWV0Zi1y dGd3Zy1rZXljaGFpbkBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1ydGd3Zy1rZXljaGFpbkBp ZXRmLm9yZz4iIDxkcmFmdC1pZXRmLXJ0Z3dnLWtleWNoYWluQGlldGYub3JnPG1haWx0bzpkcmFm dC1pZXRmLXJ0Z3dnLWtleWNoYWluQGlldGYub3JnPj4sIFJvdXRpbmcgV0cgPHJ0Z3dnQGlldGYu b3JnPG1haWx0bzpydGd3Z0BpZXRmLm9yZz4+LCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1m LmNvbTxtYWlsdG86bWJqQHRhaWwtZi5jb20+PiwgVG9tIFBldGNoIDxpZXRmY0BidGNvbm5lY3Qu Y29tPG1haWx0bzppZXRmY0BidGNvbm5lY3QuY29tPj4sICJuZXRjb25mQGlldGYub3JnPG1haWx0 bzpuZXRjb25mQGlldGYub3JnPiIgPG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBtYmogcmV2aWV3IG9mIGRyYWZ0LWlldGYt bmV0Y29uZi1yZXN0Y29uZi1zZXJ2ZXItbW9kZWwtMDkNCg0KU28gaG9wZWZ1bGx5IHdl4oCZdmUg cHV0IHRoZSBpc3N1ZSBvZiBjb21iaW5pbmcgdGhlIG1vZHVsZSB0byBiZWQgZm9yIGdvb2TigKYg SWYgbG9vayBhdCB0aGUgZGF0ZSBub2RlcyBmb3IgdGhlc2UgdHdvIG1vZGVscywgaXQgaXMgcGF0 ZW50bHkgY2xlYXIgdGhhdCB0aGVzZSBzZXJ2ZSB0d28gZGlmZmVyZW50IHB1cnBvc2VzLg0KDQpX aGF0IGFib3V0IHRoZSBuYW1pbmcgaXNzdWU/IEkgZ290IGEgY29tbWVudCB0aGF0IEkgc2hvdWxk IHRha2Ug4oCccm91dGluZy3igJwgYmFjayBvdXQgZHVlIHRvIHRoZSBmYWN0IHRoYXQgdGhpcyBp cyB3aGF0IHRoYXQgdGhlc2Uga2V5LWNoYWlucyBjYW4gYmUgdXNlZCBmb3IgbWFueSBub24tcm91 dGluZyBwdXJwb3Nlcy4gRm9yIGV4YW1wbGUsIEJGRCAtIGh0dHA6Ly93d3cuanVuaXBlci5uZXQv ZG9jdW1lbnRhdGlvbi9lbl9VUy9qdW5vczE0LjIvdG9waWNzL3JlZmVyZW5jZS9jb25maWd1cmF0 aW9uLXN0YXRlbWVudC9rZXktY2hhaW4tZWRpdC1zZWN1cml0eS1hdXRoZW50aWNhdGlvbi1rZXkt Y2hhaW5zLmh0bWwNCg0KVGhhbmtzLA0KQWNlZQ0KDQpGcm9tOiBydGd3ZyA8cnRnd2ctYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86cnRnd2ctYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBB Y2VlIExpbmRlbSA8YWNlZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lzY28uY29tPj4NCkRhdGU6 IE1vbmRheSwgQXByaWwgMTgsIDIwMTYgYXQgNjowNCBQTQ0KVG86IE1haGVzaCBKZXRoYW5hbmRh bmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNv bT4+DQpDYzogTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWls LWYuY29tPj4sIFRvbSBQZXRjaCA8aWV0ZmNAYnRjb25uZWN0LmNvbTxtYWlsdG86aWV0ZmNAYnRj b25uZWN0LmNvbT4+LCAibmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4i IDxuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPj4sICJkcmFmdC1pZXRm LXJ0Z3dnLWtleWNoYWluQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXJ0Z3dnLWtleWNoYWlu QGlldGYub3JnPiIgPGRyYWZ0LWlldGYtcnRnd2cta2V5Y2hhaW5AaWV0Zi5vcmc8bWFpbHRvOmRy YWZ0LWlldGYtcnRnd2cta2V5Y2hhaW5AaWV0Zi5vcmc+PiwgUm91dGluZyBXRyA8cnRnd2dAaWV0 Zi5vcmc8bWFpbHRvOnJ0Z3dnQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gbWJq IHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtc2VydmVyLW1vZGVsLTA5DQoN Cg0KDQpGcm9tOiBNYWhlc2ggSmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxt YWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+Pg0KRGF0ZTogTW9uZGF5LCBBcHJpbCAxOCwg MjAxNiBhdCA0OjQzIFBNDQpUbzogQWNlZSBMaW5kZW0gPGFjZWVAY2lzY28uY29tPG1haWx0bzph Y2VlQGNpc2NvLmNvbT4+DQpDYzogS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ8bWFp bHRvOmt3YXRzZW5AanVuaXBlci5uZXQ+PiwgVG9tIFBldGNoIDxpZXRmY0BidGNvbm5lY3QuY29t PG1haWx0bzppZXRmY0BidGNvbm5lY3QuY29tPj4sIE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWls LWYuY29tPG1haWx0bzptYmpAdGFpbC1mLmNvbT4+LCAibmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86 bmV0Y29uZkBpZXRmLm9yZz4iIDxuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYu b3JnPj4sIFJvdXRpbmcgV0cgPHJ0Z3dnQGlldGYub3JnPG1haWx0bzpydGd3Z0BpZXRmLm9yZz4+ LCAiZHJhZnQtaWV0Zi1ydGd3Zy1rZXljaGFpbkBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1y dGd3Zy1rZXljaGFpbkBpZXRmLm9yZz4iIDxkcmFmdC1pZXRmLXJ0Z3dnLWtleWNoYWluQGlldGYu b3JnPG1haWx0bzpkcmFmdC1pZXRmLXJ0Z3dnLWtleWNoYWluQGlldGYub3JnPj4NClN1YmplY3Q6 IFJlOiBbTmV0Y29uZl0gbWJqIHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYt c2VydmVyLW1vZGVsLTA5DQoNCg0KT24gQXByIDE4LCAyMDE2LCBhdCAxMDoyNSBBTSwgQWNlZSBM aW5kZW0gKGFjZWUpIDxhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNlZUBjaXNjby5jb20+PiB3cm90 ZToNCg0KSSBkaWQgZ2V0IHNvbWUgbmVnYXRpdmUgZmVlZGJhY2sgd2l0aCByZXNwZWN0IHRvIGFk ZGluZyDigJxyb3V0aW5nLeKAnCB0byB0aGUNCm1vZGVsIG5hbWUgc2luY2Uga2V5IGNoYWlucyBh cmUgdXNlZCBmb3Igb3RoZXIgbm9uLXJvdXRpbmcgYXBwbGljYXRpb25zIGFzDQp3ZWxsLg0KDQpP bmUgb2YgdGhvc2Ugbm9uLXJvdXRpbmcgcHJvdG9jb2xzIGlzIEJGRC4gSSBhbSBmaW5lIGlmIHRo ZSBtb2RlbCBpcyBjYWxsZWQgcHJvdG9jb2wta2V5LWNoYWluLCBidXQgSSB3b25kZXIgd2hhdCBo YXBwZW5zIHRoZSBuZXh0IGVudGl0eSBuZWVkaW5nIGtleS1jaGFpbiBpcyBub3QgYSBwcm90b2Nv bC4NCg0KVGhlIGJpZ2dlciBxdWVzdGlvbiBpbiBteSBtaW5kIGlzLCBhcmUgdGhlc2UgcmVhbGx5 IGRpZmZlcmVudCB0eXBlcyBvZiBrZXktY2hhaW5zIG1vZGVscywgb3IgYXJlIHdlIHRhbGtpbmcg YWJvdXQgb25lIGtleS1jaGFpbiBtb2RlbD8NCg0KVGhlIHJ0Z3dnIGtleSBjaGFpbiBtb2RlbCBp cyB0aGUgb25lIHdlIGFsbCBrbm93IGFuZCBsb3ZlIGFzc29jaWF0ZWQgd2l0aCB0aGUgZ3JhY2Vm dWwgcm9sbG92ZXIgb2YgY29uZmlndXJhYmxlIGtleXMuIFRoZSBuZXRjb25mIG1vZGVsIGlzIGxp c3Qgb2YgY2VydGlmaWNhdGVzIGZvciBhIHB1YmxpYyBrZXkuIFBsZWFzZSBsb29rIGF0IHRoZSBp bmZvcm1hdGlvbiBjb250ZW50IG9mIHRoZSB0d28gbW9kZWxzLiBJIGhvcGUgSSBkb27igJl0IGhh dmUgdG8gYW5zd2VyIHRoaXMgcXVlc3Rpb24gYWdhaW4gO14pDQoNCkFjZWUNCg0KDQoNCg0KDQpN YWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhh bmFuZGFuaUBnbWFpbC5jb20+DQoNCg0KDQo= --_000_D383521F642C9aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4BC64EE241D85144913DBD0498D2B229@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K SeKAmW0gYWJvdXQgdG8gdXBkYXRlIHRoaXMga2V5LWNoYWluIG1vZHVsZSBhbmQgd291bGQgbGlr ZSB0byByZXN0b3JlIHRoZSBuYW1lIG9mIHNpbXBseSBrZXktY2hhaW4gc2luY2UgSeKAmXZlIHJl Y2VpdmVkIG5lZ2F0aXZlIGZlZWRiYWNrIG9uIHRoZSB0aGUgY2hhbmdlIHRvIHJvdXRpbmcta2V5 LWNoYWluIHNpbmNlIGl0IHdpbGwgbGlrZWx5IGJlIHVzZWQgZm9yIGEgbXlyaWFkIG9mIG5vbi1y b3V0aW5nIGFwcGxpY2F0aW9ucy4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KS2VudCAt IHdvdWxkIHlvdSBiZSBvcHBvc2VkIHRvIHRoaXM/IE5vdGUgdGhhdCB5b3VyIGNvbXBhbnnigJlz IHByb2R1Y3RzIHJlZmVyIHRvIGl0IGFzIHNpbXBseSDigJxrZXktY2hhaW7igJ0uJm5ic3A7PC9k aXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5odHRwOi8vd3d3Lmp1bmlwZXIubmV0L2RvY3Vt ZW50YXRpb24vZW5fVVMvanVub3MxNC4yL3RvcGljcy9yZWZlcmVuY2UvY29uZmlndXJhdGlvbi1z dGF0ZW1lbnQva2V5LWNoYWluLWVkaXQtc2VjdXJpdHktYXV0aGVudGljYXRpb24ta2V5LWNoYWlu cy5odG1sPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxzcGFu IGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxl ZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6 IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFE RElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJ R0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPnJ0Z3dnICZsdDs8YSBocmVmPSJtYWlsdG86cnRnd2ct Ym91bmNlc0BpZXRmLm9yZyI+cnRnd2ctYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFs ZiBvZiBBY2VlIExpbmRlbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjZWVAY2lzY28uY29tIj5hY2Vl QGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRh dGU6IDwvc3Bhbj5TYXR1cmRheSwgQXByaWwgMzAsIDIwMTYgYXQgMjo0MCBQTTxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPk1haGVzaCBKZXRoYW5hbmRhbmkg Jmx0OzxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWpldGhhbmFuZGFu aUBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5D YzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXJ0Z3dnLWtleWNoYWlu QGlldGYub3JnIj5kcmFmdC1pZXRmLXJ0Z3dnLWtleWNoYWluQGlldGYub3JnPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtcnRnd2cta2V5Y2hhaW5AaWV0Zi5vcmciPmRy YWZ0LWlldGYtcnRnd2cta2V5Y2hhaW5AaWV0Zi5vcmc8L2E+Jmd0OywgUm91dGluZyBXRyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJ0Z3dnQGlldGYub3JnIj5ydGd3Z0BpZXRmLm9yZzwvYT4mZ3Q7LA0K IE1hcnRpbiBCam9ya2x1bmQgJmx0OzxhIGhyZWY9Im1haWx0bzptYmpAdGFpbC1mLmNvbSI+bWJq QHRhaWwtZi5jb208L2E+Jmd0OywgVG9tIFBldGNoICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZmNA YnRjb25uZWN0LmNvbSI+aWV0ZmNAYnRjb25uZWN0LmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVm PSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPiZn dDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJl OiBbTmV0Y29uZl0gbWJqIHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtc2Vy dmVyLW1vZGVsLTA5PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg aWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVG VDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9k ZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7Ij4NCjxkaXY+U28gaG9wZWZ1bGx5IHdl4oCZdmUgcHV0IHRoZSBpc3N1ZSBvZiBjb21i aW5pbmcgdGhlIG1vZHVsZSB0byBiZWQgZm9yIGdvb2TigKYgSWYgbG9vayBhdCB0aGUgZGF0ZSBu b2RlcyBmb3IgdGhlc2UgdHdvIG1vZGVscywgaXQgaXMgcGF0ZW50bHkgY2xlYXIgdGhhdCB0aGVz ZSBzZXJ2ZSB0d28gZGlmZmVyZW50IHB1cnBvc2VzLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+V2hhdCBhYm91dCB0aGUgbmFtaW5nIGlzc3VlPyBJIGdvdCBhIGNvbW1lbnQg dGhhdCBJIHNob3VsZCB0YWtlIOKAnHJvdXRpbmct4oCcIGJhY2sgb3V0IGR1ZSB0byB0aGUgZmFj dCB0aGF0IHRoaXMgaXMgd2hhdCB0aGF0IHRoZXNlIGtleS1jaGFpbnMgY2FuIGJlIHVzZWQgZm9y IG1hbnkgbm9uLXJvdXRpbmcgcHVycG9zZXMuIEZvciBleGFtcGxlLCBCRkQgLSZuYnNwOzxhIGhy ZWY9Imh0dHA6Ly93d3cuanVuaXBlci5uZXQvZG9jdW1lbnRhdGlvbi9lbl9VUy9qdW5vczE0LjIv dG9waWNzL3JlZmVyZW5jZS9jb25maWd1cmF0aW9uLXN0YXRlbWVudC9rZXktY2hhaW4tZWRpdC1z ZWN1cml0eS1hdXRoZW50aWNhdGlvbi1rZXktY2hhaW5zLmh0bWwiPmh0dHA6Ly93d3cuanVuaXBl ci5uZXQvZG9jdW1lbnRhdGlvbi9lbl9VUy9qdW5vczE0LjIvdG9waWNzL3JlZmVyZW5jZS9jb25m aWd1cmF0aW9uLXN0YXRlbWVudC9rZXktY2hhaW4tZWRpdC1zZWN1cml0eS1hdXRoZW50aWNhdGlv bi1rZXktY2hhaW5zLmh0bWw8L2E+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFu a3MsPC9kaXY+DQo8ZGl2PkFjZWU8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0i T0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsg Zm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RU T006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9N OiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6 ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRP UDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+cnRn d2cgJmx0OzxhIGhyZWY9Im1haWx0bzpydGd3Zy1ib3VuY2VzQGlldGYub3JnIj5ydGd3Zy1ib3Vu Y2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIEFjZWUgTGluZGVtICZsdDs8YSBocmVm PSJtYWlsdG86YWNlZUBjaXNjby5jb20iPmFjZWVAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPk1vbmRheSwgQXByaWwgMTgs IDIwMTYgYXQgNjowNCBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Ubzog PC9zcGFuPk1haGVzaCBKZXRoYW5hbmRhbmkgJmx0OzxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5k YW5pQGdtYWlsLmNvbSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPk1hcnRpbiBCam9ya2x1bmQgJmx0 OzxhIGhyZWY9Im1haWx0bzptYmpAdGFpbC1mLmNvbSI+bWJqQHRhaWwtZi5jb208L2E+Jmd0Oywg VG9tIFBldGNoICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZmNAYnRjb25uZWN0LmNvbSI+aWV0ZmNA YnRjb25uZWN0LmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRm Lm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRj b25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPiZndDssDQogJnF1b3Q7PGEgaHJlZj0i bWFpbHRvOmRyYWZ0LWlldGYtcnRnd2cta2V5Y2hhaW5AaWV0Zi5vcmciPmRyYWZ0LWlldGYtcnRn d2cta2V5Y2hhaW5AaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQt aWV0Zi1ydGd3Zy1rZXljaGFpbkBpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1ydGd3Zy1rZXljaGFpbkBp ZXRmLm9yZzwvYT4mZ3Q7LCBSb3V0aW5nIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cnRnd2dAaWV0 Zi5vcmciPnJ0Z3dnQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbTmV0Y29uZl0gbWJqIHJldmlldyBvZiBkcmFm dC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtc2VydmVyLW1vZGVsLTA5PGJyPg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JM T0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAg MCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBi cmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazog YWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxl ZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6 IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFE RElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJ R0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPk1haGVzaCBKZXRoYW5hbmRhbmkgJmx0OzxhIGhyZWY9 Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208 L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+ TW9uZGF5LCBBcHJpbCAxOCwgMjAxNiBhdCA0OjQzIFBNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+QWNlZSBMaW5kZW0gJmx0OzxhIGhyZWY9Im1haWx0bzph Y2VlQGNpc2NvLmNvbSI+YWNlZUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPktlbnQgV2F0c2VuICZsdDs8YSBocmVmPSJtYWls dG86a3dhdHNlbkBqdW5pcGVyLm5ldCI+a3dhdHNlbkBqdW5pcGVyLm5ldDwvYT4mZ3Q7LCBUb20g UGV0Y2ggJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmY0BidGNvbm5lY3QuY29tIj5pZXRmY0BidGNv bm5lY3QuY29tPC9hPiZndDssIE1hcnRpbiBCam9ya2x1bmQgJmx0OzxhIGhyZWY9Im1haWx0bzpt YmpAdGFpbC1mLmNvbSI+bWJqQHRhaWwtZi5jb208L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJt YWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPiZndDss IFJvdXRpbmcgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpydGd3Z0BpZXRmLm9yZyI+cnRnd2dAaWV0 Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtcnRnd2cta2V5 Y2hhaW5AaWV0Zi5vcmciPmRyYWZ0LWlldGYtcnRnd2cta2V5Y2hhaW5AaWV0Zi5vcmc8L2E+JnF1 b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXJ0Z3dnLWtleWNoYWluQGlldGYu b3JnIj5kcmFmdC1pZXRmLXJ0Z3dnLWtleWNoYWluQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbTmV0Y29uZl0g bWJqIHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtc2VydmVyLW1vZGVsLTA5 PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRM T09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1 IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13 ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+T24gQXByIDE4LCAyMDE2LCBhdCAxMDoyNSBBTSwgQWNlZSBMaW5kZW0gKGFjZWUpICZs dDs8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20iIGNsYXNzPSIiPmFjZWVAY2lzY28uY29t PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xp bmUiPg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdo dDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog YXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg ZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+SQ0KIGRp ZCBnZXQgc29tZSBuZWdhdGl2ZSBmZWVkYmFjayB3aXRoIHJlc3BlY3QgdG8gYWRkaW5nIOKAnHJv dXRpbmct4oCcIHRvIHRoZTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWln aHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDog bm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5tb2RlbA0KIG5hbWUg c2luY2Uga2V5IGNoYWlucyBhcmUgdXNlZCBmb3Igb3RoZXIgbm9uLXJvdXRpbmcgYXBwbGljYXRp b25zIGFzPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNw bGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPndlbGwuPHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5PbmUgb2YgdGhvc2Ugbm9uLXJvdXRpbmcg cHJvdG9jb2xzIGlzIEJGRC4gSSBhbSBmaW5lIGlmIHRoZSBtb2RlbCBpcyBjYWxsZWQgcHJvdG9j b2wta2V5LWNoYWluLCBidXQgSSB3b25kZXIgd2hhdCBoYXBwZW5zIHRoZSBuZXh0IGVudGl0eSBu ZWVkaW5nIGtleS1jaGFpbiBpcyBub3QgYSBwcm90b2NvbC48L2Rpdj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2PlRoZSBiaWdnZXIgcXVlc3Rpb24gaW4gbXkgbWluZCBpcywgYXJl IHRoZXNlIHJlYWxseSBkaWZmZXJlbnQgdHlwZXMgb2Yga2V5LWNoYWlucyBtb2RlbHMsIG9yIGFy ZSB3ZSB0YWxraW5nIGFib3V0IG9uZSBrZXktY2hhaW4gbW9kZWw/PC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhl IHJ0Z3dnIGtleSBjaGFpbiBtb2RlbCBpcyB0aGUgb25lIHdlIGFsbCBrbm93IGFuZCBsb3ZlIGFz c29jaWF0ZWQgd2l0aCB0aGUgZ3JhY2VmdWwgcm9sbG92ZXIgb2YgY29uZmlndXJhYmxlIGtleXMu IFRoZSBuZXRjb25mIG1vZGVsIGlzIGxpc3Qgb2YgY2VydGlmaWNhdGVzIGZvciBhIHB1YmxpYyBr ZXkuIFBsZWFzZSBsb29rIGF0IHRoZSBpbmZvcm1hdGlvbiBjb250ZW50IG9mIHRoZSB0d28gbW9k ZWxzLiBJIGhvcGUgSSBkb27igJl0IGhhdmUNCiB0byBhbnN3ZXIgdGhpcyBxdWVzdGlvbiBhZ2Fp biA7XikmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFjZWUmbmJzcDs8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K PGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxl PSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjow IDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Vi a2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3Bh Y2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgYXBwbGUtY29udGVudC1lZGl0ZWQ9 InRydWUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5NYWhlc2ggSmV0aGFuYW5kYW5pPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSIg Y2xhc3M9IiI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXds aW5lIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D383521F642C9aceeciscocom_-- From nobody Sun Jun 12 15:03:51 2016 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 9A87412B031; Sun, 12 Jun 2016 15:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 X7xlAC58E6S6; Sun, 12 Jun 2016 15:03:46 -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 74F7F128B44; Sun, 12 Jun 2016 15:03:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22227; q=dns/txt; s=iport; t=1465769026; x=1466978626; h=from:to:cc:subject:date:message-id:mime-version; bh=ywQ0/rWXobLPk+vhXY444A+UZjuIeMAvBRqTuAcMMBw=; b=NmtEDgS4GlILdE9svovr6V8QDXdjjldWIHc/Oj6oQBOqEAYnd2vwdYtP pq5rSoRnVKSrdzaSA58V15ZTbALiDfIp3Y2CkhoyKPa96KGUI3ZrTaHEN L+mzkDBf3BHsCbRI2PtkBzs9/7Zn1/adoYXpTYngEqeX4uORI9IT94+yE k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAgCW211X/5JdJa1dgnBOVn0Grx6HA?= =?us-ascii?q?IUAgXkdhTBKHoEHOBQBAQEBAQEBZSeESgEBAQQjVhIBCA4DAwECJAQDAgQfERQ?= =?us-ascii?q?JCgQOBYgWAxcOrESMLw2DfgEBAQEBAQEDAQEBAQEBASCKdIJDgWc2gmGCWgWNb?= =?us-ascii?q?oo/NAGMLYF6gWmEUohlhkiBOYdsAR42ggccFoE1bgEBiQd/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,463,1459814400"; d="scan'208,217";a="112174061" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jun 2016 22:03:45 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u5CM3jsr014953 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 12 Jun 2016 22:03:45 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 12 Jun 2016 18:03:44 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Sun, 12 Jun 2016 18:03:44 -0400 From: "Acee Lindem (acee)" To: Kent Watsen Thread-Topic: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09 (Reply to this one - corrected the draft alias) Thread-Index: AQHRxPZJtV2I7wzICkGEyXhuAh87oA== Date: Sun, 12 Jun 2016 22:03:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.53.251] Content-Type: multipart/alternative; boundary="_000_D38353BE642D7aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , Routing WG Subject: Re: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09 (Reply to this one - corrected the draft alias) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 22:03:48 -0000 --_000_D38353BE642D7aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gYWJvdXQgdG8gdXBkYXRlIHRoaXMga2V5LWNoYWluIG1vZHVsZSBhbmQgd291bGQgbGlr ZSB0byByZXN0b3JlIHRoZSBuYW1lIG9mIHNpbXBseSBrZXktY2hhaW4gc2luY2UgSeKAmXZlIHJl Y2VpdmVkIG5lZ2F0aXZlIGZlZWRiYWNrIG9uIHRoZSB0aGUgY2hhbmdlIHRvIHJvdXRpbmcta2V5 LWNoYWluIHNpbmNlIGl0IHdpbGwgbGlrZWx5IGJlIHVzZWQgZm9yIGEgbXlyaWFkIG9mIG5vbi1y b3V0aW5nIGFwcGxpY2F0aW9ucy4NCg0KS2VudCAtIHdvdWxkIHlvdSBiZSBvcHBvc2VkIHRvIHRo aXM/IE5vdGUgdGhhdCB5b3VyIGNvbXBhbnnigJlzIHByb2R1Y3RzIHJlZmVyIHRvIHRoZSBtb2Rl bCBhcyBzaW1wbHkg4oCca2V5LWNoYWlu4oCdLg0KDQpodHRwOi8vd3d3Lmp1bmlwZXIubmV0L2Rv Y3VtZW50YXRpb24vZW5fVVMvanVub3MxNC4yL3RvcGljcy9yZWZlcmVuY2UvY29uZmlndXJhdGlv bi1zdGF0ZW1lbnQva2V5LWNoYWluLWVkaXQtc2VjdXJpdHktYXV0aGVudGljYXRpb24ta2V5LWNo YWlucy5odG1sDQoNClRoYW5rcywNCkFjZWUNCg0KRnJvbTogcnRnd2cgPHJ0Z3dnLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgQWNl ZSBMaW5kZW0gPGFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+DQpEYXRlOiBT YXR1cmRheSwgQXByaWwgMzAsIDIwMTYgYXQgMjo0MCBQTQ0KVG86IE1haGVzaCBKZXRoYW5hbmRh bmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNv bT4+DQpDYzogImRyYWZ0LWlldGYtcnRnd2cta2V5Y2hhaW5AaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0 LWlldGYtcnRnd2cta2V5Y2hhaW5AaWV0Zi5vcmc+IiA8ZHJhZnQtaWV0Zi1ydGd3Zy1rZXljaGFp bkBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1ydGd3Zy1rZXljaGFpbkBpZXRmLm9yZz4+LCBS b3V0aW5nIFdHIDxydGd3Z0BpZXRmLm9yZzxtYWlsdG86cnRnd2dAaWV0Zi5vcmc+PiwgTWFydGlu IEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29tPj4sIFRvbSBQ ZXRjaCA8aWV0ZmNAYnRjb25uZWN0LmNvbTxtYWlsdG86aWV0ZmNAYnRjb25uZWN0LmNvbT4+LCAi bmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4iIDxuZXRjb25mQGlldGYu b3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gbWJq IHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtc2VydmVyLW1vZGVsLTA5DQoN ClNvIGhvcGVmdWxseSB3ZeKAmXZlIHB1dCB0aGUgaXNzdWUgb2YgY29tYmluaW5nIHRoZSBtb2R1 bGUgdG8gYmVkIGZvciBnb29k4oCmIElmIGxvb2sgYXQgdGhlIGRhdGUgbm9kZXMgZm9yIHRoZXNl IHR3byBtb2RlbHMsIGl0IGlzIHBhdGVudGx5IGNsZWFyIHRoYXQgdGhlc2Ugc2VydmUgdHdvIGRp ZmZlcmVudCBwdXJwb3Nlcy4NCg0KV2hhdCBhYm91dCB0aGUgbmFtaW5nIGlzc3VlPyBJIGdvdCBh IGNvbW1lbnQgdGhhdCBJIHNob3VsZCB0YWtlIOKAnHJvdXRpbmct4oCcIGJhY2sgb3V0IGR1ZSB0 byB0aGUgZmFjdCB0aGF0IHRoaXMgaXMgd2hhdCB0aGF0IHRoZXNlIGtleS1jaGFpbnMgY2FuIGJl IHVzZWQgZm9yIG1hbnkgbm9uLXJvdXRpbmcgcHVycG9zZXMuIEZvciBleGFtcGxlLCBCRkQgLSBo dHRwOi8vd3d3Lmp1bmlwZXIubmV0L2RvY3VtZW50YXRpb24vZW5fVVMvanVub3MxNC4yL3RvcGlj cy9yZWZlcmVuY2UvY29uZmlndXJhdGlvbi1zdGF0ZW1lbnQva2V5LWNoYWluLWVkaXQtc2VjdXJp dHktYXV0aGVudGljYXRpb24ta2V5LWNoYWlucy5odG1sDQoNClRoYW5rcywNCkFjZWUNCg0KRnJv bTogcnRnd2cgPHJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnLWJvdW5jZXNAaWV0 Zi5vcmc+PiBvbiBiZWhhbGYgb2YgQWNlZSBMaW5kZW0gPGFjZWVAY2lzY28uY29tPG1haWx0bzph Y2VlQGNpc2NvLmNvbT4+DQpEYXRlOiBNb25kYXksIEFwcmlsIDE4LCAyMDE2IGF0IDY6MDQgUE0N ClRvOiBNYWhlc2ggSmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86 bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+Pg0KQ2M6IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWls LWYuY29tPG1haWx0bzptYmpAdGFpbC1mLmNvbT4+LCBUb20gUGV0Y2ggPGlldGZjQGJ0Y29ubmVj dC5jb208bWFpbHRvOmlldGZjQGJ0Y29ubmVjdC5jb20+PiwgIm5ldGNvbmZAaWV0Zi5vcmc8bWFp bHRvOm5ldGNvbmZAaWV0Zi5vcmc+IiA8bmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBp ZXRmLm9yZz4+LCAiZHJhZnQtaWV0Zi1ydGd3Zy1rZXljaGFpbkBpZXRmLm9yZzxtYWlsdG86ZHJh ZnQtaWV0Zi1ydGd3Zy1rZXljaGFpbkBpZXRmLm9yZz4iIDxkcmFmdC1pZXRmLXJ0Z3dnLWtleWNo YWluQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXJ0Z3dnLWtleWNoYWluQGlldGYub3JnPj4s IFJvdXRpbmcgV0cgPHJ0Z3dnQGlldGYub3JnPG1haWx0bzpydGd3Z0BpZXRmLm9yZz4+DQpTdWJq ZWN0OiBSZTogW05ldGNvbmZdIG1iaiByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rj b25mLXNlcnZlci1tb2RlbC0wOQ0KDQoNCg0KRnJvbTogTWFoZXNoIEpldGhhbmFuZGFuaSA8bWpl dGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPj4NCkRh dGU6IE1vbmRheSwgQXByaWwgMTgsIDIwMTYgYXQgNDo0MyBQTQ0KVG86IEFjZWUgTGluZGVtIDxh Y2VlQGNpc2NvLmNvbTxtYWlsdG86YWNlZUBjaXNjby5jb20+Pg0KQ2M6IEtlbnQgV2F0c2VuIDxr d2F0c2VuQGp1bmlwZXIubmV0PG1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0Pj4sIFRvbSBQZXRj aCA8aWV0ZmNAYnRjb25uZWN0LmNvbTxtYWlsdG86aWV0ZmNAYnRjb25uZWN0LmNvbT4+LCBNYXJ0 aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwtZi5jb20+PiwgIm5l dGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+IiA8bmV0Y29uZkBpZXRmLm9y ZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4+LCBSb3V0aW5nIFdHIDxydGd3Z0BpZXRmLm9yZzxt YWlsdG86cnRnd2dAaWV0Zi5vcmc+PiwgImRyYWZ0LWlldGYtcnRnd2cta2V5Y2hhaW5AaWV0Zi5v cmc8bWFpbHRvOmRyYWZ0LWlldGYtcnRnd2cta2V5Y2hhaW5AaWV0Zi5vcmc+IiA8ZHJhZnQtaWV0 Zi1ydGd3Zy1rZXljaGFpbkBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1ydGd3Zy1rZXljaGFp bkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIG1iaiByZXZpZXcgb2YgZHJhZnQt aWV0Zi1uZXRjb25mLXJlc3Rjb25mLXNlcnZlci1tb2RlbC0wOQ0KDQoNCk9uIEFwciAxOCwgMjAx NiwgYXQgMTA6MjUgQU0sIEFjZWUgTGluZGVtIChhY2VlKSA8YWNlZUBjaXNjby5jb208bWFpbHRv OmFjZWVAY2lzY28uY29tPj4gd3JvdGU6DQoNCkkgZGlkIGdldCBzb21lIG5lZ2F0aXZlIGZlZWRi YWNrIHdpdGggcmVzcGVjdCB0byBhZGRpbmcg4oCccm91dGluZy3igJwgdG8gdGhlDQptb2RlbCBu YW1lIHNpbmNlIGtleSBjaGFpbnMgYXJlIHVzZWQgZm9yIG90aGVyIG5vbi1yb3V0aW5nIGFwcGxp Y2F0aW9ucyBhcw0Kd2VsbC4NCg0KT25lIG9mIHRob3NlIG5vbi1yb3V0aW5nIHByb3RvY29scyBp cyBCRkQuIEkgYW0gZmluZSBpZiB0aGUgbW9kZWwgaXMgY2FsbGVkIHByb3RvY29sLWtleS1jaGFp biwgYnV0IEkgd29uZGVyIHdoYXQgaGFwcGVucyB0aGUgbmV4dCBlbnRpdHkgbmVlZGluZyBrZXkt Y2hhaW4gaXMgbm90IGEgcHJvdG9jb2wuDQoNClRoZSBiaWdnZXIgcXVlc3Rpb24gaW4gbXkgbWlu ZCBpcywgYXJlIHRoZXNlIHJlYWxseSBkaWZmZXJlbnQgdHlwZXMgb2Yga2V5LWNoYWlucyBtb2Rl bHMsIG9yIGFyZSB3ZSB0YWxraW5nIGFib3V0IG9uZSBrZXktY2hhaW4gbW9kZWw/DQoNClRoZSBy dGd3ZyBrZXkgY2hhaW4gbW9kZWwgaXMgdGhlIG9uZSB3ZSBhbGwga25vdyBhbmQgbG92ZSBhc3Nv Y2lhdGVkIHdpdGggdGhlIGdyYWNlZnVsIHJvbGxvdmVyIG9mIGNvbmZpZ3VyYWJsZSBrZXlzLiBU aGUgbmV0Y29uZiBtb2RlbCBpcyBsaXN0IG9mIGNlcnRpZmljYXRlcyBmb3IgYSBwdWJsaWMga2V5 LiBQbGVhc2UgbG9vayBhdCB0aGUgaW5mb3JtYXRpb24gY29udGVudCBvZiB0aGUgdHdvIG1vZGVs cy4gSSBob3BlIEkgZG9u4oCZdCBoYXZlIHRvIGFuc3dlciB0aGlzIHF1ZXN0aW9uIGFnYWluIDte KQ0KDQpBY2VlDQoNCg0KDQoNCg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFuZGFuaUBn bWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQoNCg0K --_000_D38353BE642D7aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <2519903122ED474CB9A596C030089FD8@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJy aSxzYW5zLXNlcmlmIj5J4oCZbSBhYm91dCB0byB1cGRhdGUgdGhpcyBrZXktY2hhaW4gbW9kdWxl IGFuZCB3b3VsZCBsaWtlIHRvIHJlc3RvcmUgdGhlIG5hbWUgb2Ygc2ltcGx5IGtleS1jaGFpbiBz aW5jZSBJ4oCZdmUgcmVjZWl2ZWQgbmVnYXRpdmUgZmVlZGJhY2sgb24gdGhlIHRoZSBjaGFuZ2Ug dG8gcm91dGluZy1rZXktY2hhaW4gc2luY2UgaXQgd2lsbCBsaWtlbHkgYmUgdXNlZCBmb3IgYSBt eXJpYWQgb2Ygbm9uLXJvdXRpbmcNCiBhcHBsaWNhdGlvbnMuJm5ic3A7PC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5LZW50IC0gd291bGQgeW91IGJl IG9wcG9zZWQgdG8gdGhpcz8gTm90ZSB0aGF0IHlvdXIgY29tcGFueeKAmXMgcHJvZHVjdHMgcmVm ZXIgdG8gdGhlIG1vZGVsIGFzIHNpbXBseSDigJxrZXktY2hhaW7igJ0uJm5ic3A7PC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5odHRwOi8vd3d3Lmp1 bmlwZXIubmV0L2RvY3VtZW50YXRpb24vZW5fVVMvanVub3MxNC4yL3RvcGljcy9yZWZlcmVuY2Uv Y29uZmlndXJhdGlvbi1zdGF0ZW1lbnQva2V5LWNoYWluLWVkaXQtc2VjdXJpdHktYXV0aGVudGlj YXRpb24ta2V5LWNoYWlucy5odG1sPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7 Ij4NClRoYW5rcyw8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCkFjZWU8L2Rp dj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9 Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsg Y29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVk aXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5H LVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6 IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5Gcm9tOiA8L3NwYW4+cnRnd2cgJmx0OzxhIGhyZWY9Im1haWx0bzpydGd3Zy1ib3Vu Y2VzQGlldGYub3JnIj5ydGd3Zy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9m IEFjZWUgTGluZGVtICZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20iPmFjZWVAY2lz Y28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTog PC9zcGFuPlNhdHVyZGF5LCBBcHJpbCAzMCwgMjAxNiBhdCAyOjQwIFBNPGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+TWFoZXNoIEpldGhhbmFuZGFuaSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj5tamV0aGFuYW5kYW5pQGdt YWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8 L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtcnRnd2cta2V5Y2hhaW5AaWV0 Zi5vcmciPmRyYWZ0LWlldGYtcnRnd2cta2V5Y2hhaW5AaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1ydGd3Zy1rZXljaGFpbkBpZXRmLm9yZyI+ZHJhZnQt aWV0Zi1ydGd3Zy1rZXljaGFpbkBpZXRmLm9yZzwvYT4mZ3Q7LCBSb3V0aW5nIFdHICZsdDs8YSBo cmVmPSJtYWlsdG86cnRnd2dAaWV0Zi5vcmciPnJ0Z3dnQGlldGYub3JnPC9hPiZndDssDQogTWFy dGluIEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIj5tYmpAdGFp bC1mLmNvbTwvYT4mZ3Q7LCBUb20gUGV0Y2ggJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmY0BidGNv bm5lY3QuY29tIj5pZXRmY0BidGNvbm5lY3QuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1h aWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+Jmd0Ozxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtO ZXRjb25mXSBtYmogcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1zZXJ2ZXIt bW9kZWwtMDk8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0i TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAj YjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBz cGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiPg0KPGRpdj5TbyBob3BlZnVsbHkgd2XigJl2ZSBwdXQgdGhlIGlzc3VlIG9mIGNvbWJpbmlu ZyB0aGUgbW9kdWxlIHRvIGJlZCBmb3IgZ29vZOKApiBJZiBsb29rIGF0IHRoZSBkYXRlIG5vZGVz IGZvciB0aGVzZSB0d28gbW9kZWxzLCBpdCBpcyBwYXRlbnRseSBjbGVhciB0aGF0IHRoZXNlIHNl cnZlIHR3byBkaWZmZXJlbnQgcHVycG9zZXMuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5XaGF0IGFib3V0IHRoZSBuYW1pbmcgaXNzdWU/IEkgZ290IGEgY29tbWVudCB0aGF0 IEkgc2hvdWxkIHRha2Ug4oCccm91dGluZy3igJwgYmFjayBvdXQgZHVlIHRvIHRoZSBmYWN0IHRo YXQgdGhpcyBpcyB3aGF0IHRoYXQgdGhlc2Uga2V5LWNoYWlucyBjYW4gYmUgdXNlZCBmb3IgbWFu eSBub24tcm91dGluZyBwdXJwb3Nlcy4gRm9yIGV4YW1wbGUsIEJGRCAtJm5ic3A7PGEgaHJlZj0i aHR0cDovL3d3dy5qdW5pcGVyLm5ldC9kb2N1bWVudGF0aW9uL2VuX1VTL2p1bm9zMTQuMi90b3Bp Y3MvcmVmZXJlbmNlL2NvbmZpZ3VyYXRpb24tc3RhdGVtZW50L2tleS1jaGFpbi1lZGl0LXNlY3Vy aXR5LWF1dGhlbnRpY2F0aW9uLWtleS1jaGFpbnMuaHRtbCI+aHR0cDovL3d3dy5qdW5pcGVyLm5l dC9kb2N1bWVudGF0aW9uL2VuX1VTL2p1bm9zMTQuMi90b3BpY3MvcmVmZXJlbmNlL2NvbmZpZ3Vy YXRpb24tc3RhdGVtZW50L2tleS1jaGFpbi1lZGl0LXNlY3VyaXR5LWF1dGhlbnRpY2F0aW9uLWtl eS1jaGFpbnMuaHRtbDwvYT48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8 L2Rpdj4NCjxkaXY+QWNlZTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtf U1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250 LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTog bWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBp bjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1 YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAz cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5ydGd3ZyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmciPnJ0Z3dnLWJvdW5jZXNA aWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgQWNlZSBMaW5kZW0gJmx0OzxhIGhyZWY9Im1h aWx0bzphY2VlQGNpc2NvLmNvbSI+YWNlZUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+TW9uZGF5LCBBcHJpbCAxOCwgMjAx NiBhdCA2OjA0IFBNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3Nw YW4+TWFoZXNoIEpldGhhbmFuZGFuaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlA Z21haWwuY29tIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+TWFydGluIEJqb3JrbHVuZCAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIj5tYmpAdGFpbC1mLmNvbTwvYT4mZ3Q7LCBUb20g UGV0Y2ggJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmY0BidGNvbm5lY3QuY29tIj5pZXRmY0BidGNv bm5lY3QuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3Jn Ij5uZXRjb25mQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZA aWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJtYWls dG86ZHJhZnQtaWV0Zi1ydGd3Zy1rZXljaGFpbkBpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1ydGd3Zy1r ZXljaGFpbkBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRm LXJ0Z3dnLWtleWNoYWluQGlldGYub3JnIj5kcmFmdC1pZXRmLXJ0Z3dnLWtleWNoYWluQGlldGYu b3JnPC9hPiZndDssIFJvdXRpbmcgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpydGd3Z0BpZXRmLm9y ZyI+cnRnd2dAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtOZXRjb25mXSBtYmogcmV2aWV3IG9mIGRyYWZ0LWll dGYtbmV0Y29uZi1yZXN0Y29uZi1zZXJ2ZXItbW9kZWwtMDk8YnI+DQo8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tR VU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAg NTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRl ci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsg Y29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVk aXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5H LVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6 IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5Gcm9tOiA8L3NwYW4+TWFoZXNoIEpldGhhbmFuZGFuaSAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT4m Z3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5Nb25k YXksIEFwcmlsIDE4LCAyMDE2IGF0IDQ6NDMgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+VG86IDwvc3Bhbj5BY2VlIExpbmRlbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjZWVA Y2lzY28uY29tIj5hY2VlQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+S2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpr d2F0c2VuQGp1bmlwZXIubmV0Ij5rd2F0c2VuQGp1bmlwZXIubmV0PC9hPiZndDssIFRvbSBQZXRj aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZjQGJ0Y29ubmVjdC5jb20iPmlldGZjQGJ0Y29ubmVj dC5jb208L2E+Jmd0OywgTWFydGluIEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0 YWlsLWYuY29tIj5tYmpAdGFpbC1mLmNvbTwvYT4mZ3Q7LA0KICZxdW90OzxhIGhyZWY9Im1haWx0 bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+Jmd0OywgUm91 dGluZyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Z3dnQGlldGYub3JnIj5ydGd3Z0BpZXRmLm9y ZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1ydGd3Zy1rZXljaGFp bkBpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1ydGd3Zy1rZXljaGFpbkBpZXRmLm9yZzwvYT4mcXVvdDsN CiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtcnRnd2cta2V5Y2hhaW5AaWV0Zi5vcmci PmRyYWZ0LWlldGYtcnRnd2cta2V5Y2hhaW5AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtOZXRjb25mXSBtYmog cmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1zZXJ2ZXItbW9kZWwtMDk8YnI+ DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tf QVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29s aWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtp dC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij5PbiBBcHIgMTgsIDIwMTYsIGF0IDEwOjI1IEFNLCBBY2VlIExpbmRlbSAoYWNlZSkgJmx0Ozxh IGhyZWY9Im1haWx0bzphY2VlQGNpc2NvLmNvbSIgY2xhc3M9IiI+YWNlZUBjaXNjby5jb208L2E+ Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+ DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9h dDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5JDQogZGlkIGdl dCBzb21lIG5lZ2F0aXZlIGZlZWRiYWNrIHdpdGggcmVzcGVjdCB0byBhZGRpbmcg4oCccm91dGlu Zy3igJwgdG8gdGhlPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDog bm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0 bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNs YXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25l OyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPm1vZGVsDQogbmFtZSBzaW5j ZSBrZXkgY2hhaW5zIGFyZSB1c2VkIGZvciBvdGhlciBub24tcm91dGluZyBhcHBsaWNhdGlvbnMg YXM8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9y cGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6 IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+d2VsbC48c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pk9uZSBvZiB0aG9zZSBub24tcm91dGluZyBwcm90 b2NvbHMgaXMgQkZELiBJIGFtIGZpbmUgaWYgdGhlIG1vZGVsIGlzIGNhbGxlZCBwcm90b2NvbC1r ZXktY2hhaW4sIGJ1dCBJIHdvbmRlciB3aGF0IGhhcHBlbnMgdGhlIG5leHQgZW50aXR5IG5lZWRp bmcga2V5LWNoYWluIGlzIG5vdCBhIHByb3RvY29sLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXY+VGhlIGJpZ2dlciBxdWVzdGlvbiBpbiBteSBtaW5kIGlzLCBhcmUgdGhl c2UgcmVhbGx5IGRpZmZlcmVudCB0eXBlcyBvZiBrZXktY2hhaW5zIG1vZGVscywgb3IgYXJlIHdl IHRhbGtpbmcgYWJvdXQgb25lIGtleS1jaGFpbiBtb2RlbD88L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgcnRn d2cga2V5IGNoYWluIG1vZGVsIGlzIHRoZSBvbmUgd2UgYWxsIGtub3cgYW5kIGxvdmUgYXNzb2Np YXRlZCB3aXRoIHRoZSBncmFjZWZ1bCByb2xsb3ZlciBvZiBjb25maWd1cmFibGUga2V5cy4gVGhl IG5ldGNvbmYgbW9kZWwgaXMgbGlzdCBvZiBjZXJ0aWZpY2F0ZXMgZm9yIGEgcHVibGljIGtleS4g UGxlYXNlIGxvb2sgYXQgdGhlIGluZm9ybWF0aW9uIGNvbnRlbnQgb2YgdGhlIHR3byBtb2RlbHMu IEkgaG9wZSBJIGRvbuKAmXQgaGF2ZQ0KIHRvIGFuc3dlciB0aGlzIHF1ZXN0aW9uIGFnYWluIDte KSZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QWNlZSZuYnNwOzwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8Ymxv Y2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJP UkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAw IDU7Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQt bmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsi IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBhcHBsZS1jb250ZW50LWVkaXRlZD0idHJ1 ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk1haGVzaCBKZXRoYW5hbmRhbmk8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIiBjbGFz cz0iIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUi Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+PC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D38353BE642D7aceeciscocom_-- From nobody Sun Jun 12 23:39:44 2016 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 229A0128E19; Sun, 12 Jun 2016 23:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 ZQH2m5ES-6TH; Sun, 12 Jun 2016 23:39:41 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0620127078; Sun, 12 Jun 2016 23:39:38 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 61BE080E; Mon, 13 Jun 2016 08:39:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3o5wGylzDVX2; Mon, 13 Jun 2016 08:39:34 +0200 (CEST) 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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 13 Jun 2016 08:39:34 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C9382004E; Mon, 13 Jun 2016 08:39:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id s3--FaRsB51k; Mon, 13 Jun 2016 08:39:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 418F920047; Mon, 13 Jun 2016 08:39:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 371FE3B1DC5D; Mon, 13 Jun 2016 08:39:31 +0200 (CEST) Date: Mon, 13 Jun 2016 08:39:31 +0200 From: Juergen Schoenwaelder To: "Acee Lindem (acee)" Message-ID: <20160613063930.GB20531@elstar.local> Mail-Followup-To: "Acee Lindem (acee)" , Kent Watsen , "netconf@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , Routing WG References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netconf@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , Routing WG Subject: Re: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09 (Reply to this one - corrected the draft alias) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 06:39:43 -0000 Yes, both ietf-routing-key-chain and ietf-system-keychain seem to be misleading module names. I think the module names should express what makes these two keychain modules different and they should not reflect where the keys might be used. /js On Sun, Jun 12, 2016 at 10:03:44PM +0000, Acee Lindem (acee) wrote: > I’m about to update this key-chain module and would like to restore the name of simply key-chain since I’ve received negative feedback on the the change to routing-key-chain since it will likely be used for a myriad of non-routing applications. > > Kent - would you be opposed to this? Note that your company’s products refer to the model as simply “key-chainâ€. > > http://www.juniper.net/documentation/en_US/junos14.2/topics/reference/configuration-statement/key-chain-edit-security-authentication-key-chains.html > > Thanks, > Acee > > From: rtgwg > on behalf of Acee Lindem > > Date: Saturday, April 30, 2016 at 2:40 PM > To: Mahesh Jethanandani > > Cc: "draft-ietf-rtgwg-keychain@ietf.org" >, Routing WG >, Martin Bjorklund >, Tom Petch >, "netconf@ietf.org" > > Subject: Re: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09 > > So hopefully we’ve put the issue of combining the module to bed for good… If look at the date nodes for these two models, it is patently clear that these serve two different purposes. > > What about the naming issue? I got a comment that I should take “routing-“ back out due to the fact that this is what that these key-chains can be used for many non-routing purposes. For example, BFD - http://www.juniper.net/documentation/en_US/junos14.2/topics/reference/configuration-statement/key-chain-edit-security-authentication-key-chains.html > > Thanks, > Acee > > From: rtgwg > on behalf of Acee Lindem > > Date: Monday, April 18, 2016 at 6:04 PM > To: Mahesh Jethanandani > > Cc: Martin Bjorklund >, Tom Petch >, "netconf@ietf.org" >, "draft-ietf-rtgwg-keychain@ietf.org" >, Routing WG > > Subject: Re: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09 > > > > From: Mahesh Jethanandani > > Date: Monday, April 18, 2016 at 4:43 PM > To: Acee Lindem > > Cc: Kent Watsen >, Tom Petch >, Martin Bjorklund >, "netconf@ietf.org" >, Routing WG >, "draft-ietf-rtgwg-keychain@ietf.org" > > Subject: Re: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09 > > > On Apr 18, 2016, at 10:25 AM, Acee Lindem (acee) > wrote: > > I did get some negative feedback with respect to adding “routing-“ to the > model name since key chains are used for other non-routing applications as > well. > > One of those non-routing protocols is BFD. I am fine if the model is called protocol-key-chain, but I wonder what happens the next entity needing key-chain is not a protocol. > > The bigger question in my mind is, are these really different types of key-chains models, or are we talking about one key-chain model? > > The rtgwg key chain model is the one we all know and love associated with the graceful rollover of configurable keys. The netconf model is list of certificates for a public key. Please look at the information content of the two models. I hope I don’t have to answer this question again ;^) > > Acee > > > > > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > _______________________________________________ > 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 Mon Jun 13 12:49:11 2016 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 C268A12D0D8 for ; Mon, 13 Jun 2016 12:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 f8Zdn9hAkkwi for ; Mon, 13 Jun 2016 12:49:07 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D084512D578 for ; Mon, 13 Jun 2016 12:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=l9RiMaoBt+r+4co9L5OpylBP9W4MDcDKh9IWZDoGFqk=; b=LSKzHNPP4H6wx/7Ugu3EfXnTt21Zd1EBSZxqaomZsFAqKOCGb5MM+bb/0Ooi+DOtZ6cmUXdKYt5N/pK9e1pzbsVxMCukqV8lAwCgTqvXavROpdfnkE2if1qs1JUU0afHFVQcLuPSGhDpYUsUkla5T1TyzQYnV85QH9nJVWiyq2U= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1451.namprd05.prod.outlook.com (10.160.149.12) with Microsoft SMTP Server (TLS) id 15.1.517.8; Mon, 13 Jun 2016 19:48:47 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0517.009; Mon, 13 Jun 2016 19:48:47 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [netmod] The Restconf root Thread-Index: AQHRxZ1C0kBX7ncE3kSA1002lJSqOp/niukA Date: Mon, 13 Jun 2016 19:48:47 +0000 Message-ID: <6B5F6F5D-9E91-4541-BFF4-CC36750D132E@juniper.net> References: <877fdtx97j.fsf@hobgoblin.ariadne.com> In-Reply-To: <877fdtx97j.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-ms-office365-filtering-correlation-id: 4fb81a44-aef0-42d4-7d32-08d393c3bc34 x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1451; 6:gQBvR2P2nnuhokpWmICFY/uVFTuN+TnZU5r8khta4aVDONNDMu6eaL+qNwFCYBE9UPJj01rLWcNIVsH0+OjJ+Y/ohOKS8vlPbR/nhXlQy1iATlUA/K1UI//p7mm9gVXzwrfrhdHdkfvJpIPjN2pk2fhZ6W3/IOs3mjYkX7SdFK+pDAfcISId2A6+mzUjfPSqIHPzf7zau4ZLwu9y+brw7pOWls6EpwqU1hTIHbruPo25GoJi5jlGFSAdHdk6ozCHST4MiSiNNnEtjfg5iisLC2gGMAjmmORXRjaRgqWwvDpV8oSxW7JuldDQSXn183WX; 5:fCvUm9W7XxBKNjbyN+LZ1W0myQREty3sJm/DiEo/dWmSjVZF/e99iwlynCWjx7kEaiU9S6POiiMm5EOEtT079roasjx9yC+60iZs6HZAWHw8k3ZjUvpyzS46Vze9GEpw+Ur6ftKeWt8BBW0zs5ue6w==; 24:sEfaeLe1FUBiFgGOcWoK0fOlFFWPWNnKr+iM7eA2Np2K7dGYfr2dxB8FVtmeIYOMj/NQ9lAkl00nv7jlkw4rgpnSezi1dl/zdJ0Z+6VxHrE=; 7:t6H5lO/K1ZkhmqPIS0TaS8YYmchdvrgCb+BeVnsshKV7eSQ/EtZsQRSfS5i7IeBQod+1e4GPGwCu/D81L1GX236dSE/GrG7kNIIWN73JoxoE6u+YA1ij7U46zWWjwxqGEuNZytSSR0f95nQXGW0LO3PlqIBUG+ihkbqKqgvTVhnyIENExK0RymCovatobnuUJ9xlZYymSzC0biYXUcan4w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1451; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(38170694233816)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CY1PR0501MB1451; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1451; x-forefront-prvs: 0972DEC1D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(24454002)(199003)(377454003)(54356999)(92566002)(76176999)(107886002)(110136002)(189998001)(83716003)(2906002)(50986999)(33656002)(101416001)(99286002)(36756003)(8676002)(7906002)(10400500002)(1730700003)(86362001)(2900100001)(81156014)(81166006)(2950100001)(5640700001)(97736004)(3660700001)(3280700002)(4001350100001)(19580395003)(122556002)(31430400001)(19300405004)(106356001)(106116001)(15975445007)(105586002)(82746002)(68736007)(450100001)(2351001)(66066001)(8936002)(5004730100002)(19617315012)(19580405001)(87936001)(2501003)(5002640100001)(586003)(83506001)(11100500001)(102836003)(3846002)(6116002)(5008740100001)(15395725005)(77096005)(562404015)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1451; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <188C6C673DBB3D4486F23D14486F71A6@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2016 19:48:47.3723 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1451 Archived-At: Subject: [Netconf] FW: [netmod] The Restconf root X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 19:49:10 -0000 DQpGb3J3YXJkaW5nIHRvIE5FVENPTkYgbGlzdC4NCg0KS2VudA0KDQoNCk9uIDYvMTMvMTYsIDE6 NTcgUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIERhbGUgUi4gV29ybGV5IiA8bmV0bW9kLWJvdW5j ZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHdvcmxleUBhcmlhZG5lLmNvbT4gd3JvdGU6DQoNCj4o SSdtIG5ldyB0byB0aGUgTmV0Y29uZiBtYWlsaW5nIGxpc3QsIHNvIGl0J3MgcG9zc2libGUgdGhh dCB0aGlzIGlzc3VlDQo+aGFzIGFscmVhZHkgYmVlbiBkaXNwb3NlZCBvZi4pDQo+DQo+TG9va2lu ZyBhdCBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtMTMsIGl0IGxvb2tzIGxpa2UgdGhlIFJG QyA3MzIwDQo+bWVjaGFuaXNtIGlzIHVzZWQgdG8gZmluZCB0aGUgcm9vdCBVUkwsIGZyb20gd2hp Y2ggYWxsIHRoZSBSZXN0Y29uZiBVUkxzDQo+YXJlIGRlcml2ZWQgYnkgYXBwZW5kaW5nIHBhdGgg Y29tcG9uZW50cyBhcyBzcGVjaWZpZWQgaW4gdGhlIGRyYWZ0Lg0KPg0KPkJ1dCBsb29raW5nIGF0 IFJGQyA2NTcwLCB3aGljaCBpcyByZWZlcmVuY2VkIGJ5IGJvdGggNzMyMCBhbmQgdGhlIGRyYWZ0 LA0KPml0IHNlZW1zIHRoYXQgc3BlY2lmeWluZyBwYXRoIGNvbXBvbmVudHMgdG8gYmUgYXBwZW5k ZWQgYSBjb25maWd1cmVkDQo+YmFzZSBVUkwgaXMgbm8gbG9uZ2VyIGJlc3QgcHJhY3RpY2UsIGJl Y2F1c2UgaXQgcmVxdWlyZXMgdGhlIEhUVFAgc2VydmVyDQo+dG8gYmUgYWJsZSB0byBjb25uZWN0 IGFsbCB0aG9zZSBVUkxzIHRvIHRoZSBSZXN0Y29uZiBzZXJ2ZXIgZGVzcGl0ZQ0KPnRoZWlyIGRp ZmZlcmVudCBwYXRocy4gIEl0IHNlZW1zIHRoYXQgdGhlIG5ldywgaW1wcm92ZWQgbWV0aG9kIGlz IHRvDQo+YWR2ZXJ0aXNlIGEgVVJMIHRlbXBsYXRlLCBhbmQgdGhlIGNsaWVudCBzaG91bGQgdXNl IHRoZSB0ZW1wbGF0ZSBhbmQgdGhlDQo+UmVzdGNvbmYgImFkZGl0aW9uYWwgcGF0aCIgdG8gY29u c3RydWN0IHRoZSBVUkwgdG8gYmUgdXNlZC4NCj4NCj5FLmcuLCBub3csIHRoZSBzZWNvbmQgZXhh bXBsZSBpbiBzZWN0aW9uIDMuMSBzaG93cyBob3cgdGhlIFJlc3Rjb25mIHJvb3QNCj5pcyBvYnRh aW5lZDoNCj4NCj4gICAgICBSZXF1ZXN0DQo+ICAgICAgLS0tLS0tLQ0KPiAgICAgIEdFVCAvLndl bGwta25vd24vaG9zdC1tZXRhIEhUVFAvMS4xDQo+ICAgICAgSG9zdDogZXhhbXBsZS5jb20NCj4g ICAgICBBY2NlcHQ6IGFwcGxpY2F0aW9uL3hyZCt4bWwNCj4NCj4gICAgICBSZXNwb25zZQ0KPiAg ICAgIC0tLS0tLS0tDQo+ICAgICAgSFRUUC8xLjEgMjAwIE9LDQo+ICAgICAgQ29udGVudC1UeXBl OiBhcHBsaWNhdGlvbi94cmQreG1sDQo+ICAgICAgQ29udGVudC1MZW5ndGg6IG5ubg0KPg0KPiAg ICAgIDxYUkQgeG1sbnM9J2h0dHA6Ly9kb2NzLm9hc2lzLW9wZW4ub3JnL25zL3hyaS94cmQtMS4w Jz4NCj4gICAgICAgICAgPExpbmsgcmVsPSdyZXN0Y29uZicgaHJlZj0nL3RvcC9yZXN0Y29uZicv Pg0KPiAgICAgIDwvWFJEPg0KPg0KPmFuZCB1c2VkLCB3aXRoIHRoZSBzdWItVVJMICJvcGVyYXRp b25zIjoNCj4NCj4gICAgICBSZXF1ZXN0DQo+ICAgICAgLS0tLS0tLQ0KPiAgICAgIEdFVCAvdG9w L3Jlc3Rjb25mL29wZXJhdGlvbnMgIEhUVFAvMS4xDQo+ICAgICAgSG9zdDogZXhhbXBsZS5jb20N Cj4gICAgICBBY2NlcHQ6IGFwcGxpY2F0aW9uL3lhbmcuYXBpK2pzb24NCj4NCj5SRkMgNjU3MCBz ZWVtcyB0byBzdWdnZXN0IHRoYXQgdGhlIGZpcnN0IGxvb2t1cCBzaG91bGQgcmV0dXJuIGEgVVJM DQo+dGVtcGxhdGU6DQo+DQo+ICAgICAgUmVxdWVzdA0KPiAgICAgIC0tLS0tLS0NCj4gICAgICBH RVQgLy53ZWxsLWtub3duL2hvc3QtbWV0YSBIVFRQLzEuMQ0KPiAgICAgIEhvc3Q6IGV4YW1wbGUu Y29tDQo+ICAgICAgQWNjZXB0OiBhcHBsaWNhdGlvbi94cmQreG1sDQo+DQo+ICAgICAgUmVzcG9u c2UNCj4gICAgICAtLS0tLS0tLQ0KPiAgICAgIEhUVFAvMS4xIDIwMCBPSw0KPiAgICAgIENvbnRl bnQtVHlwZTogYXBwbGljYXRpb24veHJkK3htbA0KPiAgICAgIENvbnRlbnQtTGVuZ3RoOiBubm4N Cj4NCj4gICAgICA8WFJEIHhtbG5zPSdodHRwOi8vZG9jcy5vYXNpcy1vcGVuLm9yZy9ucy94cmkv eHJkLTEuMCc+DQo+ICAgICAgICAgIDxMaW5rIHJlbD0ncmVzdGNvbmYnIGhyZWY9J2h0dHA6Ly9l eGFtcGxlLmNvbS90b3AvcmVzdGNvbmYve3Jlc291cmNlfScvPg0KPiAgICAgIDwvWFJEPg0KPg0K PlRoZSB2YWx1ZSBvZiB0aGlzIGJlaW5nIHRoYXQgYSBkaWZmZXJlbnQgc2VydmVyIG1pZ2h0IHJl dHVybiB0aGUNCj50ZW1wbGF0ZSAnaHR0cDovL2V4YW1wbGUuY29tL3RvcC9yZXN0Y29uZns/cmVz b3VyY2V9JywgY2F1c2luZyB0aGUNCj5zZWNvbmQgcmVxdWVzdCB0byB1c2UgdGhlIFVSTA0KPido dHRwOi8vZXhhbXBsZS5jb20vdG9wL3Jlc3Rjb25mP3Jlc291cmNlPW9wZXJhdGlvbnMnLg0KPg0K PkFsdGhvdWdoIHRoaXMgcHJvYmFibHkgcmVxdWlyZXMgYSByZXZpc2lvbiBvZiB0aGUgaHJlZiBh dHRyaWJ1dGUgb2YgdGhlDQo+TGluayBlbGVtZW50LCBzaW5jZSBpdCBub3cgY2FycmllcyBhIFVS TCB0ZW1wbGF0ZSByYXRoZXIgdGhhbiBhIFVSTC4NCj4NCj5EYWxlDQo+DQo+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5uZXRtb2QgbWFpbGluZyBsaXN0 DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QNCg0K From nobody Tue Jun 14 09:51:26 2016 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 D3FE312D09B for ; Tue, 14 Jun 2016 09:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 K75oFfMmTnme for ; Tue, 14 Jun 2016 09:51:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:732]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3A5C12D85B for ; Tue, 14 Jun 2016 09:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1XEkZsdffikb3zNYg0VFoEqiA2ZGfMqR0yLxMCYpVmg=; b=YNcBHn4/H6W5T9QxNrd9VaOXYDkOfVPcfuMJlDsosWU4tXE9Imc7wDyzC2fOm4/88JpDjmoxcViAnicbLjB138hBIsKdDEeDy7Z4XY4qwmGlf+JmqhZ4zjUFA2QKPxIwacdBXxaPGschARb/9TbnkgvG5Tj0TQgfLVDybWDQzwk= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (TLS) id 15.1.517.8; Tue, 14 Jun 2016 16:51:02 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0511.016; Tue, 14 Jun 2016 16:51:02 +0000 From: Kent Watsen To: "Dale R. Worley" Thread-Topic: [Netconf] FW: [netmod] The Restconf root Thread-Index: AQHRxlzuriIzWY/g6keOiQDoI/Nzeg== Date: Tue, 14 Jun 2016 16:51:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-ms-office365-filtering-correlation-id: 00a92098-e711-4286-ecbc-08d3947411a0 x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 6:KtwioBOc7Zw6vTbO6fqEaJ9H6gSAbU+6HJPmuK0vBDCilYIwNlMkZ0QiTDMeIn8igEidfv2lZIZTuaySdH7Bch8mrMC/nNwhFCnBBfXwfIxLnHYZE4pq1MezsdKYAwjV/ixj68kSD4BuClNqp1sfGATgPy4xBCSoijLGnzPKD+eNDmpna5Ok6bMGnBrgRmv0CVqgHUm/74OnsUhgcVWSELckjy4gSD6xPxDQoHcsJxBkkl9zzoX6iWIvgRmzIhqqGuYv6JDnUZ8wGtqxxfs7RM605g01vfzoSy5Z1/b3/hrrzny6BdJWhNc0g5umAYjM; 5:aFfuFRRN4LUhb75d5rL98r+s4hJMWUQy0gcewQ7siMZ75BHLN9vd3AaYa7USpE3ADQqjkC1vHJgE8eeJWwGxitloLEMlue6+HOyHMccT9XkOJ+/cSaCutdCj7b06rDXeNyo+IDFtBk2GTvamQ5DiKg==; 24:qGQa2Z5Gk+QEL/ez/ldmjK/5AfyI9XwiUgltsy7ouBC25OYn3ZRUrNPXf/MytQZo2Bz8sFZKaTGOenvx5VCX7jxh3//FVAOmhVHrm1hrKig=; 7:4OasB/apD8jmo5fp9DhuLca1IFk5BurR503d370nrcZeqiluWUIYapbDj2AHtSNpslylK27X6cCSMSx1m6riopq1xkuhdyZaTXiVdNDf0d+D0O0WOyz1HQEYhfM7fDfd49/z0AxOqjF5xwmZDzsJ5Kf+x59/uBYBH/GKNmFosjFypHuAbP6h2stPYGyx4SVWHLm2/koCsB4Yiks/ZGT8ZQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(38170694233816)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(7916002)(24454002)(377454003)(199003)(189002)(19617315012)(82746002)(122556002)(86362001)(4326007)(66066001)(83716003)(99286002)(106116001)(2906002)(106356001)(105586002)(15395725005)(586003)(19300405004)(3846002)(11100500001)(102836003)(6116002)(7906002)(83506001)(10400500002)(8936002)(19580405001)(5004730100002)(77096005)(36756003)(5002640100001)(19580395003)(54356999)(189998001)(31430400001)(2900100001)(87936001)(15975445007)(33656002)(3280700002)(101416001)(5008740100001)(92566002)(81166006)(81156014)(8676002)(50986999)(97736004)(3660700001)(110136002)(68736007)(4001350100001)(562404015)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2016 16:51:01.9435 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] FW: [netmod] The Restconf root X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 16:51:24 -0000 SGkgRGFsZSwNCg0KV2UgcmVjZW50bHkgcmVjZWl2ZWQgYSBzaW1pbGFyIGNvbW1lbnQgZnJvbSBN YXJrIE5vdHRpbmdoYW0sIHdoaWNoIGlzIGludGVyZXN0aW5nIHNpbmNlIGhlIHdhcyBpbnZvbHZl ZCB3aXRoIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBjdXJyZW50IG1lY2hhbmlzbSBhIGNvdXBsZSB5 ZWFycyBiYWNrIGFzIHdlbGwgKGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv bmV0Y29uZi9jdXJyZW50L21zZzA5MTQ1Lmh0bWwpLg0KDQpUaGUgUkVTVENPTkYgZHJhZnQgYXV0 aG9ycyBkaXNjdXNzZWQgdGhpcyBpc3N1ZSB5ZXN0ZXJkYXkuICBXZSBiZWxpZXZlIHRoYXQgd2Ug dW5kZXJzdGFuZCB0aGUgbWVyaXRzIG9mIFVSSSB0ZW1wbGF0ZXMsIGJ1dCBkb27igJl0IGZlZWwg dGhhdCB0aGV5IGFkZCBhbnkgdmFsdWUgdG8gUkVTVENPTkYuICBUaGlzIGlzIGJlY2F1c2UgUkVT VENPTkYgZXhwZWN0cyBjbGllbnRzIHRvIGJlIGF3YXJlIG9mIFJFU1RDT05G4oCZcyB0aHJlZSB0 b3AtbGV2ZWwgcmVzb3VyY2VzIChkYXRhLCBvcGVyYXRpb25zLCBhbmQgeWFuZy1saWJyYXJ5LXZl cnNpb24pLCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjMgaW4gdGhlIC0wOCBkcmFmdCwgYW5k IGZyb20gdGhlbiBvbiBiZSBhYmxlIHRvIGdlbmVyYXRlIFVSTHMgdmlhIFlBTkcgbWFwcGluZ3Mg KG5vdCB0ZW1wbGF0ZXMpLiAgSW4gbGluZSB3aXRoIHRoaXMsIFJFU1RDT05GIGFsc28gZG9lcyBu b3Qgc3VwcG9ydCBIQVRFT0FTIChzZWUgU2VjdGlvbiAxLjMgaW4gdGhlIC0wOCBkcmFmdCkuICAg V2UgdW5kZXJzdGFuZCB0aGF0IHRlbXBsYXRlcyBtYXkgYmUgYSBiZXN0IHByYWN0aWNlIGZvciBv dGhlciBIVFRQIHNlcnZlcnMsIGJ1dCBiZWxpZXZlIHRoYXQgd2hhdCB3ZSBoYXZlIG5vdyBpcyBw ZXJmZWN0IGZvciB0aGlzIHVzZS4gICBEbyB5b3Ugc3RpbGwgZmVlbCB0aGF0IHdlIGNhbiBkbyBi ZXR0ZXI/DQoNCktlbnQNCg0KDQo+T24gNi8xMy8xNiwgMTo1NyBQTSwgIm5ldG1vZCBvbiBiZWhh bGYgb2YgRGFsZSBSLiBXb3JsZXkiIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg b2Ygd29ybGV5QGFyaWFkbmUuY29tPiB3cm90ZToNCj4NCj4+KEknbSBuZXcgdG8gdGhlIE5ldGNv bmYgbWFpbGluZyBsaXN0LCBzbyBpdCdzIHBvc3NpYmxlIHRoYXQgdGhpcyBpc3N1ZQ0KPj5oYXMg YWxyZWFkeSBiZWVuIGRpc3Bvc2VkIG9mLikNCj4+DQo+Pkxvb2tpbmcgYXQgZHJhZnQtaWV0Zi1u ZXRjb25mLXJlc3Rjb25mLTEzLCBpdCBsb29rcyBsaWtlIHRoZSBSRkMgNzMyMA0KPj5tZWNoYW5p c20gaXMgdXNlZCB0byBmaW5kIHRoZSByb290IFVSTCwgZnJvbSB3aGljaCBhbGwgdGhlIFJlc3Rj b25mIFVSTHMNCj4+YXJlIGRlcml2ZWQgYnkgYXBwZW5kaW5nIHBhdGggY29tcG9uZW50cyBhcyBz cGVjaWZpZWQgaW4gdGhlIGRyYWZ0Lg0KPj4NCj4+QnV0IGxvb2tpbmcgYXQgUkZDIDY1NzAsIHdo aWNoIGlzIHJlZmVyZW5jZWQgYnkgYm90aCA3MzIwIGFuZCB0aGUgZHJhZnQsDQo+Pml0IHNlZW1z IHRoYXQgc3BlY2lmeWluZyBwYXRoIGNvbXBvbmVudHMgdG8gYmUgYXBwZW5kZWQgYSBjb25maWd1 cmVkDQo+PmJhc2UgVVJMIGlzIG5vIGxvbmdlciBiZXN0IHByYWN0aWNlLCBiZWNhdXNlIGl0IHJl cXVpcmVzIHRoZSBIVFRQIHNlcnZlcg0KPj50byBiZSBhYmxlIHRvIGNvbm5lY3QgYWxsIHRob3Nl IFVSTHMgdG8gdGhlIFJlc3Rjb25mIHNlcnZlciBkZXNwaXRlDQo+PnRoZWlyIGRpZmZlcmVudCBw YXRocy4gIEl0IHNlZW1zIHRoYXQgdGhlIG5ldywgaW1wcm92ZWQgbWV0aG9kIGlzIHRvDQo+PmFk dmVydGlzZSBhIFVSTCB0ZW1wbGF0ZSwgYW5kIHRoZSBjbGllbnQgc2hvdWxkIHVzZSB0aGUgdGVt cGxhdGUgYW5kIHRoZQ0KPj5SZXN0Y29uZiAiYWRkaXRpb25hbCBwYXRoIiB0byBjb25zdHJ1Y3Qg dGhlIFVSTCB0byBiZSB1c2VkLg0KPj4NCj4+RS5nLiwgbm93LCB0aGUgc2Vjb25kIGV4YW1wbGUg aW4gc2VjdGlvbiAzLjEgc2hvd3MgaG93IHRoZSBSZXN0Y29uZiByb290DQo+PmlzIG9idGFpbmVk Og0KPj4NCj4+ICAgICAgUmVxdWVzdA0KPj4gICAgICAtLS0tLS0tDQo+PiAgICAgIEdFVCAvLndl bGwta25vd24vaG9zdC1tZXRhIEhUVFAvMS4xDQo+PiAgICAgIEhvc3Q6IGV4YW1wbGUuY29tDQo+ PiAgICAgIEFjY2VwdDogYXBwbGljYXRpb24veHJkK3htbA0KPj4NCj4+ICAgICAgUmVzcG9uc2UN Cj4+ICAgICAgLS0tLS0tLS0NCj4+ICAgICAgSFRUUC8xLjEgMjAwIE9LDQo+PiAgICAgIENvbnRl bnQtVHlwZTogYXBwbGljYXRpb24veHJkK3htbA0KPj4gICAgICBDb250ZW50LUxlbmd0aDogbm5u DQo+Pg0KPj4gICAgICA8WFJEIHhtbG5zPSdodHRwOi8vZG9jcy5vYXNpcy1vcGVuLm9yZy9ucy94 cmkveHJkLTEuMCc+DQo+PiAgICAgICAgICA8TGluayByZWw9J3Jlc3Rjb25mJyBocmVmPScvdG9w L3Jlc3Rjb25mJy8+DQo+PiAgICAgIDwvWFJEPg0KPj4NCj4+YW5kIHVzZWQsIHdpdGggdGhlIHN1 Yi1VUkwgIm9wZXJhdGlvbnMiOg0KPj4NCj4+ICAgICAgUmVxdWVzdA0KPj4gICAgICAtLS0tLS0t DQo+PiAgICAgIEdFVCAvdG9wL3Jlc3Rjb25mL29wZXJhdGlvbnMgIEhUVFAvMS4xDQo+PiAgICAg IEhvc3Q6IGV4YW1wbGUuY29tDQo+PiAgICAgIEFjY2VwdDogYXBwbGljYXRpb24veWFuZy5hcGkr anNvbg0KPj4NCj4+UkZDIDY1NzAgc2VlbXMgdG8gc3VnZ2VzdCB0aGF0IHRoZSBmaXJzdCBsb29r dXAgc2hvdWxkIHJldHVybiBhIFVSTA0KPj50ZW1wbGF0ZToNCj4+DQo+PiAgICAgIFJlcXVlc3QN Cj4+ICAgICAgLS0tLS0tLQ0KPj4gICAgICBHRVQgLy53ZWxsLWtub3duL2hvc3QtbWV0YSBIVFRQ LzEuMQ0KPj4gICAgICBIb3N0OiBleGFtcGxlLmNvbQ0KPj4gICAgICBBY2NlcHQ6IGFwcGxpY2F0 aW9uL3hyZCt4bWwNCj4+DQo+PiAgICAgIFJlc3BvbnNlDQo+PiAgICAgIC0tLS0tLS0tDQo+PiAg ICAgIEhUVFAvMS4xIDIwMCBPSw0KPj4gICAgICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3hy ZCt4bWwNCj4+ICAgICAgQ29udGVudC1MZW5ndGg6IG5ubg0KPj4NCj4+ICAgICAgPFhSRCB4bWxu cz0naHR0cDovL2RvY3Mub2FzaXMtb3Blbi5vcmcvbnMveHJpL3hyZC0xLjAnPg0KPj4gICAgICAg ICAgPExpbmsgcmVsPSdyZXN0Y29uZicgaHJlZj0naHR0cDovL2V4YW1wbGUuY29tL3RvcC9yZXN0 Y29uZi97cmVzb3VyY2V9Jy8+DQo+PiAgICAgIDwvWFJEPg0KPj4NCj4+VGhlIHZhbHVlIG9mIHRo aXMgYmVpbmcgdGhhdCBhIGRpZmZlcmVudCBzZXJ2ZXIgbWlnaHQgcmV0dXJuIHRoZQ0KPj50ZW1w bGF0ZSAnaHR0cDovL2V4YW1wbGUuY29tL3RvcC9yZXN0Y29uZns/cmVzb3VyY2V9JywgY2F1c2lu ZyB0aGUNCj4+c2Vjb25kIHJlcXVlc3QgdG8gdXNlIHRoZSBVUkwNCj4+J2h0dHA6Ly9leGFtcGxl LmNvbS90b3AvcmVzdGNvbmY/cmVzb3VyY2U9b3BlcmF0aW9ucycuDQo+Pg0KPj5BbHRob3VnaCB0 aGlzIHByb2JhYmx5IHJlcXVpcmVzIGEgcmV2aXNpb24gb2YgdGhlIGhyZWYgYXR0cmlidXRlIG9m IHRoZQ0KPj5MaW5rIGVsZW1lbnQsIHNpbmNlIGl0IG5vdyBjYXJyaWVzIGEgVVJMIHRlbXBsYXRl IHJhdGhlciB0aGFuIGEgVVJMLg0KPj4NCj4+RGFsZQ0KPj4NCj4+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+bmV0bW9kIG1haWxpbmcgbGlzdA0KPj5u ZXRtb2RAaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2QNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPk5ldGNvbmYgbWFpbGluZyBsaXN0DQo+TmV0Y29uZkBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KDQo= From nobody Tue Jun 14 17:14:36 2016 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 E6FDA12DA31; Tue, 14 Jun 2016 17:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 DC25wPRXZYRd; Tue, 14 Jun 2016 17:14:32 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 34E0212DA38; Tue, 14 Jun 2016 17:14:32 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id c2so2491036pfa.2; Tue, 14 Jun 2016 17:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=IX1R/xoMPvzmFdNwGafW+s3Ftq+/EPuy/lzUpow7Kec=; b=IoiIW/7nDA4Mx4AHGdIYoqlrQ280dO/WUTGA/lokN/3X8PKnP2t78wNODV51sSoGih MgkrkADThLK+4uJbiJvLocyAk/gKpjYrZfjGAp0SL4PmCalIqw/yh736nriiyXNtjRZU JIN73vlyltIQfJKLOiOcrgwpVOCuGJSDGpd1LXqKKxUfa54Zge8bebpWKFkLyThi1aNP kked9MIz5rH50bRd0aRUm827XobpNdNETIWbYDVoHanJ7jt6qVfFr9vzDVlIdIneoaKm 4miE1dEGkclIj+smQTvGRNKGJoKiJJiMy7YSnCazyCfbOSNwuTTJ159OctjCGso0Lg8y 5psA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=IX1R/xoMPvzmFdNwGafW+s3Ftq+/EPuy/lzUpow7Kec=; b=ITUj9aWstFi0vXCIecEiFyUI3BOxomzPLL132xmT96OvWXL1pDppmBOXLsvJyo1Ixf kC38A0ZkFWsJqchkJ5fUTeocOIuFdAul7POt8WYBfLw6sYZRpqqX9ZM5KOFLF89sq219 rRteHTUX3m3pfBGrf2V7DnS+rBuOqkDJIu//rjDcmPN8tiSYPwNO7YvnoKkMSUoARtuu epj3KuHYGCcyk3H2IhQ5rQFLIlp2IgmK+WARSSEkI3LwCSz6VIvl49AzI2DdVP/8ZXQu W7hAfOk4UVDQCQOnoyIkIieLrb8RKPPEv7byG03dd2yTRlRj8fgpGiXXylqawBhnef59 HeVg== X-Gm-Message-State: ALyK8tJNglaRyrTPqaxnUPgJ2mmu2fjaRyfns+dIVMfS9jEMrQGtcv6PwFKB3b1+RBcuWg== X-Received: by 10.98.100.14 with SMTP id y14mr453361pfb.84.1465949671556; Tue, 14 Jun 2016 17:14:31 -0700 (PDT) Received: from ?IPv6:2001:420:290:1330:a570:540b:44bc:d149? ([2001:420:290:1330:a570:540b:44bc:d149]) by smtp.gmail.com with ESMTPSA id ym9sm18361108pac.25.2016.06.14.17.14.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Jun 2016 17:14:30 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_98B5259E-0544-4FB2-BD15-0F7C0D336E4B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Tue, 14 Jun 2016 17:14:28 -0700 Message-Id: <2FF1C370-82EB-467A-94B9-1E42D530195F@gmail.com> References: <20160601213426.C34A7B80EA5@rfc-editor.org> <50fdaaa4-3b30-3254-3dcf-3db115f0bd78@cisco.com> <78F3FE3C-5413-488F-B669-AE9ECEA1A74E@gmail.com> <8D2A4656-481A-4359-84FB-C2961141C7E1@juniper.net> <8CE8391A-AA80-4DCF-9D8B-063DDDC67CDC@juniper.net> <95174A92-E35C-4652-A4FF-3DCBC5EB1752@gmail.com> <458b25ce-0b7a-cf7f-34df-38b608b6cc30@cisco.com> To: Netconf X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "netconf-chairs@ietf.org" , "netconf-ads@ietf.org" , RFC Editor Subject: Re: [Netconf] AUTH48 [DF][RV]: RFC 7895 NOW AVAILABLE X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 00:14:35 -0000 --Apple-Mail=_98B5259E-0544-4FB2-BD15-0F7C0D336E4B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This concludes the poll for the changes proposed by the authors. The RFC Editors will go ahead and make the suggested changes. Thanks. > On Jun 8, 2016, at 6:20 PM, Mahesh Jethanandani = wrote: >=20 > The authors of draft-ietf-netconf-yang-library are making one more = change to the module. See details below. >=20 > This begins a 1 week poll to address any concerns folks might have = with this change. This is not a chance to review the whole document. >=20 > Thanks. >=20 >> On Jun 8, 2016, at 5:00 PM, Andy Bierman > wrote: >>=20 >> Hi, >>=20 >> We decided to remove the submodules container: >>=20 >>=20 >> 1) YANG module:=20 >> 1.1) update revision date (also date >> 1.2) remove container submodules from grouping >>=20 >> OLD: >>=20 >> container submodules { >> description >> "Contains information about all the submodules used >> by the parent module entry"; >>=20 >> list submodule { >> key "name revision"; >> description >> "Each entry represents one submodule within the >> parent module."; >> uses common-leafs; >> uses schema-leaf; >> } >> } >>=20 >> NEW: >>=20 >> list submodule { >> key "name revision"; >> description >> "Each entry represents one submodule within the >> parent module."; >> uses common-leafs; >> uses schema-leaf; >> } >>=20 >> 2) YANG tree diagram >> 2.1 remove submodules >> 2.2 Should the notification be listed? If not, remove from NEW: >>=20 >> OLD: >>=20 >>=20 >> +--ro modules-state >> +--ro module-set-id string >> +--ro module* [name revision] >> +--ro name yang:yang-identifier >> +--ro revision union >> +--ro schema? inet:uri >> +--ro namespace inet:uri >> +--ro feature* yang:yang-identifier >> +--ro deviation* [name revision] >> | +--ro name yang:yang-identifier >> | +--ro revision union >> +--ro conformance-type enumeration >> +--ro submodules >> +--ro submodule* [name revision] >> +--ro name yang:yang-identifier >> +--ro revision union >> +--ro schema? inet:uri >>=20 >> NEW: >>=20 >> +--ro modules-state >> +--ro module-set-id string >> +--ro module* [name revision] >> +--ro name yang:yang-identifier >> +--ro revision union >> +--ro schema? inet:uri >> +--ro namespace inet:uri >> +--ro feature* yang:yang-identifier >> +--ro deviation* [name revision] >> | +--ro name yang:yang-identifier >> | +--ro revision union >> +--ro conformance-type enumeration >> +--ro submodule* [name revision] >> +--ro name yang:yang-identifier >> +--ro revision union >> +--ro schema? inet:uri >> notifications: >> +---n yang-library-change >> +--ro module-set-id -> /modules-state/module-set-id >>=20 >>=20 >> Andy >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_98B5259E-0544-4FB2-BD15-0F7C0D336E4B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This concludes the poll for the changes proposed by the = authors.

The RFC = Editors will go ahead and make the suggested changes.

Thanks.

On Jun 8, 2016, at 6:20 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

The authors of = draft-ietf-netconf-yang-library are making one more change to the = module. See details below.

This begins a 1 week poll to address any concerns folks might = have with this change. This is not a chance to review the whole = document.

Thanks.

On Jun = 8, 2016, at 5:00 PM, Andy Bierman <andy@yumaworks.com> = wrote:

Hi,

We decided to remove the submodules container:


1) YANG module: 
   1.1) = update revision date (also <CODE BEGINS> date
   1.2) remove container submodules from = grouping

  =    OLD:

      container submodules = {
        description
          "Contains information = about all the submodules used
      =      by the parent module entry";

        list = submodule {
          key = "name revision";
          = description
          =   "Each entry represents one submodule within the
             parent = module.";
          uses = common-leafs;
          = uses schema-leaf;
        = }
      }

      = NEW:

      list submodule {
        key "name revision";
        description
          "Each entry represents one = submodule within the
        =    parent module.";
      =   uses common-leafs;
      =   uses schema-leaf;
      = }

 2)= YANG tree diagram
     2.1 remove = submodules
     2.2 Should the = notification be listed? If not, remove from NEW:

OLD:


   +--ro modules-state
  =     +--ro module-set-id    string
      +--ro module* [name revision]
         +--ro name     =               = yang:yang-identifier
        =  +--ro revision               = union
         +--ro = schema?               =  inet:uri
        =  +--ro namespace             =  inet:uri
        =  +--ro feature*               = yang:yang-identifier
        =  +--ro deviation* [name revision]
  =        |  +--ro name       =  yang:yang-identifier
      =    |  +--ro revision    union
         +--ro conformance-type =       enumeration
    =      +--ro submodules
    =         +--ro submodule* [name revision]
               +--ro = name        yang:yang-identifier
               +--ro = revision    union
      =          +--ro schema?     = inet:uri

NEW:

   +--ro modules-state
      +--ro module-set-id   =  string
      +--ro module* = [name revision]
        =  +--ro name               =  yang:yang-identifier
      =    +--ro revision           =  union
         +--ro = schema?             inet:uri
         +--ro namespace   =         inet:uri
    =      +--ro feature*           =  yang:yang-identifier
      =    +--ro deviation* [name revision]
  =        |  +--ro name       =  yang:yang-identifier
      =    |  +--ro revision    union
         +--ro conformance-type =    enumeration
      =    +--ro submodule* [name revision]
  =           +--ro name       =  yang:yang-identifier
      =       +--ro revision    union
            +--ro schema? =     inet:uri
notifications:
   +---n yang-library-change
      +--ro module-set-id    -> = /modules-state/module-set-id


Andy

Mahesh Jethanandani
mjethanandani@gmail.com






Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_98B5259E-0544-4FB2-BD15-0F7C0D336E4B-- From nobody Wed Jun 15 08:41:27 2016 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 3513112D7C9 for ; Wed, 15 Jun 2016 08:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 geTGVcl6uPBd for ; Wed, 15 Jun 2016 08:41:24 -0700 (PDT) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (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 39F4D12D790 for ; Wed, 15 Jun 2016 08:41:24 -0700 (PDT) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-06v.sys.comcast.net with SMTP id DCtsbI5BqBNj9DCwVb7sWg; Wed, 15 Jun 2016 15:41:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466005283; bh=v9ZgSWIhblfhEAJ8Ye9kHl7VAauJ9676TppdFa2BGxE=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=LFotpo4smB7XLtpjUHqpMTSW7T2mSo17LWMA9zxdzFqa2ZAdUAnKWU8zxBL3T5MfF dKNqvQf3Lnu02DO+QRvJy07ti0U4RvKdWwTlYTDeQqPdX9L6oOT+mvrBgIugoipQl5 dO9p7RCtu9unPP2M1AzWYgx2eGHIPTu7plK2dzAp2sWmsqVz5AoVKTrLX8rFsqm08k BFRfpkWLDj5xa+ySZHpyKBe0avMA0CDIga+9GocNBZO3b23/FV37Hp9ybbRp9vT9Oq /zALdw/mw2ebj9dohnXqSFkHlErAXeZj2DF0GJD2a5wGJ6xrnWhoViofhgJahjGIvm 91FHzfb/mI5mA== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-15v.sys.comcast.net with comcast id 73hM1t00c1nMCLR013hNWg; Wed, 15 Jun 2016 15:41:22 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5FFfLKs029927; Wed, 15 Jun 2016 11:41:21 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5FFfLDO029924; Wed, 15 Jun 2016 11:41:21 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Kent Watsen In-Reply-To: (kwatsen@juniper.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 15 Jun 2016 11:41:20 -0400 Message-ID: <87r3bytq73.fsf@hobgoblin.ariadne.com> Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] FW: [netmod] The Restconf root X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 15:41:26 -0000 Kent Watsen writes: > We understand that templates may be a best practice for other HTTP > servers, but believe that what we have now is perfect for this use. > Do you still feel that we can do better? Mostly, I wanted to know that the WG had considered the question. This question may be coupled to another one: The draft assumes that the HTTP URL authority part (DNS name and port) is associated with exactly one RESTCONF datastore, because the well-known service mechanism can point to only one root URL. I suppose this is the most common case. Though RESTCONF could support multiple datastores, each with its own root URL, as long as there was some other mechanism for locating the roots. Dale From nobody Wed Jun 15 18:12:39 2016 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 45B5312DA45 for ; Wed, 15 Jun 2016 18:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 6Zwupo0giZ5y for ; Wed, 15 Jun 2016 18:12:35 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (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 6594A12D504 for ; Wed, 15 Jun 2016 18:12:34 -0700 (PDT) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-08v.sys.comcast.net with SMTP id DLqbbWsDZB1Y8DLrFbLB7V; Thu, 16 Jun 2016 01:12:33 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466039553; bh=iAEGV2tbdp1uzIaaXyGSEepw3GfUsodeukilIWnuapY=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Zlkvn2dwmSsUChyYmyAiXsdXYldHUI/G6pGJ9yZW7LQWqAZG7ACwQS8jFlS/Dw1vu XLkAjFc/JATxA/51W0FQcWvuZSEVDHLNEX2iZjNeFMIouuK9Cp2bGhkO7lQHz3Kgpj 2VCYtacqFSN8uyQeq38/s2hp49RrzeWNOo+iSNJAiEe+WT00O0nt605h4X/IqK5ATX ZWFQgaESV2UdtC4J5Dg90JV/U6twcb2T7AKEwNg715e+JBGWv8exxFIcvd/MjIxioy jFC0iehvaO9icJKFIrRh30bjhrdaDIccsHJJY7hEcjtTHv5yfLLmZaRncOD//XRHvM 5mBOCqbwR1c5A== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-14v.sys.comcast.net with comcast id 7DCY1t0011nMCLR01DCYXz; Thu, 16 Jun 2016 01:12:33 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5G1CV5f022901 for ; Wed, 15 Jun 2016 21:12:31 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5G1CUxk022898; Wed, 15 Jun 2016 21:12:30 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: netconf@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 15 Jun 2016 21:12:30 -0400 Message-ID: <87d1niszr5.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [Netconf] Comments on draft-ietf-netconf-restconf-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 01:12:37 -0000 This is a bunch of comments on draft-ietf-netconf-restconf-13. Some of these comments might be redundant or due to misunderstanding because I'm coming into this process late. But as I'm likely to be the Gen-ART reviewer, it's best to take care of these now. I think almost all of these comments are at the nits level. The two comments that seem to have technical content are: - Leaf-list nodes may now have duplicated values, so identifying leaf-list instances by value may not always work. But perhaps that ambiguity never arises in practice due to restrictions on the CRUD operations. - Any identifier that is materialized as an XML element or attribute can't start with "xml" (with any case). This includes the data nodes that are materialized in XML and extension keywords. But this restriction isn't specified in draft-ietf-netmod-rfc6020. 1.1.4 o event stream resource: This resource represents an SSE (Server- Sent Events) event stream. The content consists of text using the media type "text/event-stream", as defined by the HTML5 [W3C.REC-html5-20141028] specification. Each event represents one message generated by the server. It contains a conceptual system or data-model specific event that is delivered within an event notification stream. Also called a "stream resource". Is this correct? I can't find "event-stream" within . It appears that the latest Server-Sent Events specification is . 3.5.1 If a data node in the path expression is a YANG leaf-list node, then the leaf-list value MUST be encoded according to the following rules: o The instance-identifier for the leaf-list MUST be encoded using one path segment [RFC3986]. o The path segment is constructed by having the leaf-list name, followed by an "=" character, followed by the leaf-list value. (e.g., /restconf/data/top-leaflist=fred). In item 2, does "leaf-list value" mean the encoded instance-identifier of item 1? But the example below does not show a full instance-identifier as one path segment, but only the leaf-list element name and value as the last path segment: /restconf/data/example-top:top/Y=instance-value Perhaps item 1 means "the leaf-list name MUST be encoded ...". o Resource URI values returned in Location headers for data resources MUST identify the module name, even if there are no conflicting local names when the resource is created. This Is this restricted to list nodes, as its position indicates? Or is it generally applicable, and should be pulled out to a top-level paragraph? "identify the module name" is vague. I think this means that each element name must be qualified with its module name. For the above YANG definition, a target resource URI for leaf-list "Y" would be encoded as follows: /restconf/data/example-top:top/Y=instance-value Non-unique values are now allowed for leaf-lists, so this syntax may be ambiguous. (Does this apply to instance-identifiers in modules?) Perhaps the 'insert' and 'point' query parameters are used to disambiguate non-unique leaf-list values? It seems that any netconf data node that is materialized as an XML element can't start with "xml" (case-insensitive). But this is not noted in draft-ietf-netmod-rfc6020 as a restriction. The existence of YIN requires that extension keywords also may not start with "xml" (case-insensitive). 3.6 POST /restconf/operations/module-A:reset HTTP/1.1 Server example.com In two locations, the "Server" header is shown without a colon. If the operation is invoked without errors, and if the "rpc" or "action" statement has an "output" section, then a message-body MAY be sent by the server in the response, otherwise the response message MUST NOT include a message-body in the response message, and MUST send a "204 No Content" status-line instead. It seems odd that if an RPC is performed, then it is optional for the output data to be returned to the client. This means the 'input' element of an RPC body is in the namespace of the module. Similarly for 'output' elements. This is not specified anywhere. (Errors is specified to be in "ietf-restconf" in section 7.1.) 4 Operations are applied to a single data resource instance at once. IMO it would be useful to use the word "atomically", as that has a well-understood meaning. 4.3 If a retrieval request for a data resource representing a YANG leaf- list or list object identifies more than one instance, and XML encoding is used in the response, then an error response containing a "400 Bad Request" status-line MUST be returned by the server. What about zero instances? Presumably it gets a 404 response rather than an empty body, but it would be good to specify that. Note that the way that access control is applied to data resources is completely incompatible with HTTP caching. The Last-Modified and ETag headers maintained for a data resource are not affected by changes to the access control rules for that data resource. It is possible for the representation of a data resource that is visible to a particular client to be changed without detection via the Last- Modified or ETag values. Note that it's possible for the client to detect changes in configuration data that it is not allowed to read by detecting changes in the Last-Modified/ETag values. This probably isn't a security problem, but the authors should be aware of it. What does a GET of the datastore URL return? I would guess an XML document with a top node of "datastore" (in the module namespace), but that doesn't seem to be specified. Perhaps it is a known thing that the datastore contains one instance of every top-level data node in the module definition... but there can be multiple modules defined in the server... Similarly, one can ask how PUT, POST, PATCH, and DELETE are applied to the datastore resource. 4.4.1 The message-body MUST NOT contain more than one instance of the expected data resource. It seems like you want "MUST contain exactly one", since it seems that you don't want to allow zero instances. 4.6 This document defines one patch mechanism (Section 4.6.1). The YANG PATCH mechanism is defined in [I-D.ietf-netconf-yang-patch]. Other patch mechanisms may be defined by future specifications. This sentence isn't clear that "one patch mechanism" is different from "The YANG PATCH mechanism ...". Perhaps: This document defines one patch mechanism (Section 4.6.1). Another patch mechanism, the YANG PATCH mechanism, is defined in [I-D.ietf-netconf-yang-patch]. Other patch mechanisms may be defined by future specifications. 4.6.1 Plain patch can be used to create or update, but not delete, a child resource within the target resource. Please see [I-D.ietf-netconf-yang-patch] for an alternate media-type supporting more granular control. I assume this means "supporting deletion of child resources". 4.8 | point | POST, PUT | Insertion point for ordered-yb | "ordered-yb" should be "ordered-by". o Each parameter can appear at most once in a request URI. Despite being given here as a general rule, it is repeated in 4.8.2, 4.8.3, 4.8.4, 4.8.5, 4.8.6, 4.8.7, 4.8.8, and 4.8.9 (but not 4.8.1). Also, if the repetition is to be removed, the general rule needs to add "If more than one instance is present, then a "400 Bad Request" status-line MUST be returned by the server." 4.8.2 By default, the server will include all sub-resources within a retrieved resource, which have the same resource type as the requested resource. Only one level of sub-resources with a different media type than the target resource will be returned. The exception is the datastore resource. If this resource type is retrieved then by default the datastore and all child data resources are returned. Does the second sentence do anything? The only instance I know of of a node whose media type is different from that of its child nodes is the the datastore resource, and that is specifically exempted from the effect of the 2nd sentence. 4.8.3. I take it that "fields=admin(label;catalogue-number)". is equivalent to "fields=admin/label;admin/catalogue-number" But the lack of a / before the ( is not really standard practice and might trip up users. (Compare with Un*x shell "/a/b/c/{d,e}" and "/a/b/c{d,e}".) 4.8.7 It is not valid to specify start times that are later than the current time. It seems that there needs to be a way for the client to determine the time the *server* thinks it is. The client can't use its own clock, because there can be clock skew between the client and the server, and also the server may not know what time it is, so its time scale could have an arbitrary offset from real time. 7 Since an operation resource is defined with a YANG "rpc" statement, and an action is defined with a YANG "action" statement, a mapping between the NETCONF value and the HTTP status code is needed. The specific error condition and response code to use are data-model specific and might be contained in the YANG "description" statement for the "action" or "rpc" statement. I assume this means "The specific error-tag value and response code ..."; the word "condition" appears nowhere else in the draft. +-------------------------+-------------+ | | status code | +-------------------------+-------------+ Why is "‑" (‑, NON-BREAKING HYPHEN) used here? 7.1 [...] then the server SHOULD send a response message-body containing the information described by the "errors" container definition within the YANG module Section 8. There's probably a missing word before "Section 8". Specifically, this sentence needs to say that "errors" is defined in the YANG module "ietf-restconf" -- as the sentence stands, it's easy to assume that "errors" is within "the YANG module", i.e., the one defining the operation. 11.2 Looking at RFC 3688 and the registry (http://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns) it looks like you want to explicitly say that the URIs are being registered as namespaces in the IETF XML registry. 11.4 o the name of the RESTCONF capability. By convention, this name is prefixed with the colon ':' character. I think "begins" rather than "prefixed" is preferable, as it makes clear that the colon is part of the name, rather than being prepended to the name. 13 Who is The Space & Terrestrial Communications Directorate? Maybe it would add to the credit of the S&TCD by prefixing the country that funds it ... which seems to be "United States Army". 8. draft-ietf-netmod-yang-json defines JSON encoding rules for all RESTCONF media types that use the '+json' suffix. There needs to be an RFC Editor note to replace "draft-ietf-netmod-yang-json" with the eventual RFC name. D.1.3 Is it true that there's no NS URN? Section 9.3 suggests it should have namespace "urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring". D.2.1 Note that the "Location" header line is wrapped for display purposes only: You might want to promote this comment to a higher section, as wrapping is done in other places. D.3.4 Location: https://example.com/restconf/data/ example-jukebox:jukebox/playlist=Foo-One/song=1 But the text doesn't say that the Location header is wrapped only for display purposes. From nobody Thu Jun 16 11:32:28 2016 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 9F4C112DA86 for ; Thu, 16 Jun 2016 11:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 3oQ86EXuFbAS for ; Thu, 16 Jun 2016 11:32:20 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F0A912DAA8 for ; Thu, 16 Jun 2016 11:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7025; q=dns/txt; s=iport; t=1466101940; x=1467311540; h=from:to:subject:date:message-id:mime-version; bh=wYuxt2fszB58vYeG8o7OabOdOw5wp5XdR4qJmG/XksY=; b=jERyJE7CbyL8LsqJXHWvpXtEuGEcf8wbpSYRAmu+yMbrD0/R37L0XWjr Jar1pTnkoA3f+pS8OMdHZ2u/u4xzKbmJzVYzhk9WXhO/hMJSSMGFXoOq6 AEtM1UW0syftFCwhanlElJA74aXXXRsyXMeN3O3mqqRo2imfX98TOIvrL o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CKAgAC8GJX/49dJa1egnBOVn0GtVSCc?= =?us-ascii?q?oIPgXoXAQyHITgUAQEBAQEBAWUcC4RSLV4BLVMmAQQPDAGIJw6gEaA9AQEBAQE?= =?us-ascii?q?FAQEBAQEBIYYnjmgFmHEBhgSIHYFwhFKIZ4ZOiSYBHjaDcG4BBYh/AX4BAQE?= X-IronPort-AV: E=Sophos;i="5.26,481,1459814400"; d="scan'208,217";a="115860383" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jun 2016 18:32:19 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u5GIWJ5t001429 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 16 Jun 2016 18:32:19 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 16 Jun 2016 14:32:18 -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.1104.009; Thu, 16 Jun 2016 14:32:18 -0400 From: "Eric Voit (evoit)" To: "netconf@ietf.org" Thread-Topic: Event & YANG Datastore Subscription drafts posted Thread-Index: AdHH/MTxpRZZvl8ZSRKeVskGAivUxQAAHdPQ Date: Thu, 16 Jun 2016 18:32:17 +0000 Message-ID: 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: [161.44.213.50] Content-Type: multipart/alternative; boundary="_000_effb2f587bf3495f8b42d3aab11ccc5bXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] Event & YANG Datastore Subscription drafts posted X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 18:32:24 -0000 --_000_effb2f587bf3495f8b42d3aab11ccc5bXCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable After IETF 95, a number of NETCONF contributors began weekly meetings relat= ed to Event and YANG Datastore Subscriptions. The goal was to scope and f= rame adoptable drafts. A summarized context around these drafts were presente= d at the May 18th NETCONF interim. Over the last couple days, we have posted the following: Subscriptions for Event Notifications (RFC5277bis) draft-gonzalez-netconf-5277bis NETCONF Transport for Event Notifications draft-gonzalez-netconf-event-notifications RESTCONF & HTTP Transport for Event Notifications draft-voit-netconf-restconf-notif We are hoping for your review and feedback. Please note the open issues li= st which exist in the appendices of each document. There still is plenty o= f work to do. I would like to thank people attending the subteam's weekly calls who have = provided excellent comments and suggestions. These include Andy Bierman, S= haron Chisholm, Alex Clemm, Yan Gang, Einar Nilsen-Nygaard, Alberto Gonzale= z Prieto, Peipei Guo, Susan Hares, Tim Jenkins, Balazs Lengyel, Ambika Pras= ad Tripathy, Hector Trevino, Kent Watsen, and Guangying Zheng. On behalf of the subteam, Eric Voit P.S.: Expect a corresponding update to the (already adopted) YANG Datastor= e Push draft in a couple days draft-ietf-netconf-yang-push --_000_effb2f587bf3495f8b42d3aab11ccc5bXCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

After IETF 95, a number of NETCONF contributors b= egan weekly meetings related to Event and YANG Datastore Subscriptions.&nbs= p;  The goal was to scope and frame adoptable drafts.   &nbs= p;A summarized context around these drafts were presented at the May = 18th NETCONF interim.   

 

Over the last couple days, we have posted the fol= lowing:

 

Subscriptions for Event Notifications  (RFC5= 277bis)

draft-gonzalez-netconf-5277bis

 

NETCONF Transport for Event Notifications

draft-gonzalez-netconf-event-notifi= cations 

 

RESTCONF & HTTP Transport for Event Notificat= ions

draft-voit-netconf-restconf-notif

 

We are hoping for your review and feedback. = Please note the open issues list which exist in the appendices of each doc= ument.  There still is plenty of work to do.

 

I would like to thank people attending the subtea= m’s weekly calls who have provided excellent comments and suggestions= .  These include Andy Bierman, Sharon Chisholm, Alex Clemm, Yan Gang, = Einar Nilsen-Nygaard, Alberto Gonzalez Prieto, Peipei Guo, Susan Hares, Tim Jenkins, Balazs Lengyel, Ambika Prasad Tripat= hy, Hector Trevino, Kent Watsen, and Guangying Zheng.

 

On behalf of the subteam,

Eric Voit

 

P.S.:  Expect a corresponding update to the = (already adopted) YANG Datastore Push draft in a couple days

draft-ietf-netconf-yang-push

 

--_000_effb2f587bf3495f8b42d3aab11ccc5bXCHRTP013ciscocom_-- From nobody Thu Jun 16 15:47:19 2016 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 B7CAA12DCEC; Thu, 16 Jun 2016 15:47:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.22.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160616224713.20732.80826.idtracker@ietfa.amsl.com> Date: Thu, 16 Jun 2016 15:47:13 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-push-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 22:47:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : Subscribing to YANG datastore push updates Authors : Alexander Clemm Alberto Gonzalez Prieto Eric Voit Ambika Prasad Tripathy Einar Nilsen-Nygaard Filename : draft-ietf-netconf-yang-push-03.txt Pages : 55 Date : 2016-06-16 Abstract: This document defines a subscription and push mechanism for YANG datastores. This mechanism allows client applications to request updates from a YANG datastore, which are then pushed by the server to a receiver per a subscription policy, without requiring additional client requests. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-yang-push-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-push-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 Thu Jun 16 20:28:00 2016 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 171EF12DAEA for ; Thu, 16 Jun 2016 20:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 IwS17ADlmzUx for ; Thu, 16 Jun 2016 20:27:57 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 333CB12DBAB for ; Thu, 16 Jun 2016 20:27:57 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id d185so99887021vkg.0 for ; Thu, 16 Jun 2016 20:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=BjGXgAGGLtjYlJQy/QsXR2XQNhWLsOgC1hcLjPUgoiU=; b=h8hx96MKk1qDVu1xJvtQlfrh1xyTNkPH0CxonGi2/HMmImlaHT1dJUlEdX0KTZQn6f W6heHgaHijftN6cM0OgdUAmlonF6UDE9MqNmpwd0v6nbQW92uZpA5MckLxw8LyJUEsG6 89E+gQbMtzTQEsUvAuHdsyiWqB+afgz/C135G2NYrAUFyZefpS5Ee2pHkQlM9aI+sAAA 2pE/vWBlW2ND5+lCghsXVbVf2vUGMzmnY6+VaoVWTmc/KyYSKuN50ovNdMyBvZvhsJTJ ZPE2u9sAmAK0gveWm8FB1isOUpAdNK5oZPGYY7oXg2OGHHnXxpCHcG0PQtSih09yuHKw 5r6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=BjGXgAGGLtjYlJQy/QsXR2XQNhWLsOgC1hcLjPUgoiU=; b=P+3zvurxvm7TqcZgoarL/EcHgmuSlamlJlv0PxIIAZhO7yuAEfpCW5r1A9f88CcfQ/ tXLPQVYnmVbqfXQeTYz6KLqKcAJypHnwJT1S7PJTQfw/4702LEzXi1I9BU7qFjfM4bOz gl34LVEy4rAk5Ju9E9dIoL6PxQbBlJQ+ivwAgXXZCNNO2ukxi3sQmnasOuhOSImgZpLW UoYFaS+imqx5tdV+Pny7i5EmJ5SyaHTV8IRQTOtdYNF4nnf4kthsYqDzPSY1mXubpMus r8P4Hs0vPY7Akr3nhRPNLcJbphecDBYRQMM3jSNXE9inz1Uo26DlzePXmA5yTMm4dQZ1 H91w== X-Gm-Message-State: ALyK8tKPfKMUfb/WmwMVo38psapGUz4Q3QpogC9y41nk21COtD8ZkCcUHjHH6u6UZQmmEua27AZ7tsNhW6MyGw== MIME-Version: 1.0 X-Received: by 10.176.69.243 with SMTP id u106mr3702528uau.135.1466134076103; Thu, 16 Jun 2016 20:27:56 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Thu, 16 Jun 2016 20:27:56 -0700 (PDT) In-Reply-To: <87r3bytq73.fsf@hobgoblin.ariadne.com> References: <87r3bytq73.fsf@hobgoblin.ariadne.com> Date: Thu, 16 Jun 2016 20:27:56 -0700 Message-ID: From: Andy Bierman To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=94eb2c11be74ccb582053570f076 Archived-At: Cc: Netconf Subject: Re: [Netconf] FW: [netmod] The Restconf root X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 03:27:59 -0000 --94eb2c11be74ccb582053570f076 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 15, 2016 at 8:41 AM, Dale R. Worley wrote: > Kent Watsen writes: > > We understand that templates may be a best practice for other HTTP > > servers, but believe that what we have now is perfect for this use. > > Do you still feel that we can do better? > > Mostly, I wanted to know that the WG had considered the question. > > This question may be coupled to another one: The draft assumes that the > HTTP URL authority part (DNS name and port) is associated with exactly > one RESTCONF datastore, because the well-known service mechanism can > point to only one root URL. > > I suppose this is the most common case. Though RESTCONF could support > multiple datastores, each with its own root URL, as long as there was > some other mechanism for locating the roots. > > You mean we cannot add /restconf/candidate or /restconf/my-datastore? I think an SDO or vendor could define a RESTCONF capability URI to indicate a new datastore was supported. > Dale > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --94eb2c11be74ccb582053570f076 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 15, 2016 at 8:41 AM, Dale R. Worley <<= a href=3D"mailto:worley@ariadne.com" target=3D"_blank">worley@ariadne.com> wrote:
Kent Watsen <kwatsen@juniper.net> writes:
> We understand that templates may be a best practice for other HTTP
> servers, but believe that what we have now is perfect for this use. > Do you still feel that we can do better?

Mostly, I wanted to know that the WG had considered the question.

This question may be coupled to another one:=C2=A0 The draft assumes that t= he
HTTP URL authority part (DNS name and port) is associated with exactly
one RESTCONF datastore, because the well-known service mechanism can
point to only one root URL.

I suppose this is the most common case.=C2=A0 Though RESTCONF could support=
multiple datastores, each with its own root URL, as long as there was
some other mechanism for locating the roots.



You mean we cannot add = /restconf/candidate or /restconf/my-datastore?
I think an SDO or = vendor could define a RESTCONF capability URI to
indicate a new d= atastore was supported.

=C2=A0
Dale


Andy
=C2=A0
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--94eb2c11be74ccb582053570f076-- From nobody Thu Jun 16 23:26:40 2016 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 8F73912B024 for ; Thu, 16 Jun 2016 23:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 GWknMYDWqjJz for ; Thu, 16 Jun 2016 23:26:36 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1F812D0FB for ; Thu, 16 Jun 2016 23:26:35 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DC8B4767; Fri, 17 Jun 2016 08:26:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Gw_CmunjxkMi; Fri, 17 Jun 2016 08:26:28 +0200 (CEST) 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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 17 Jun 2016 08:26:32 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C50D920054; Fri, 17 Jun 2016 08:26:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id oRZmsGSbPz2T; Fri, 17 Jun 2016 08:26:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C23720031; Fri, 17 Jun 2016 08:26:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9C5283B27C34; Fri, 17 Jun 2016 08:26:30 +0200 (CEST) Date: Fri, 17 Jun 2016 08:26:30 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20160617062630.GA34404@elstar.local> Mail-Followup-To: Andy Bierman , "Dale R. Worley" , Netconf References: <87r3bytq73.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Netconf Subject: Re: [Netconf] FW: [netmod] The Restconf root X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 06:26:38 -0000 On Thu, Jun 16, 2016 at 08:27:56PM -0700, Andy Bierman wrote: > On Wed, Jun 15, 2016 at 8:41 AM, Dale R. Worley wrote: > > > Kent Watsen writes: > > > We understand that templates may be a best practice for other HTTP > > > servers, but believe that what we have now is perfect for this use. > > > Do you still feel that we can do better? > > > > Mostly, I wanted to know that the WG had considered the question. > > > > This question may be coupled to another one: The draft assumes that the > > HTTP URL authority part (DNS name and port) is associated with exactly > > one RESTCONF datastore, because the well-known service mechanism can > > point to only one root URL. > > > > I suppose this is the most common case. Though RESTCONF could support > > multiple datastores, each with its own root URL, as long as there was > > some other mechanism for locating the roots. > > > > You mean we cannot add /restconf/candidate or /restconf/my-datastore? > I think an SDO or vendor could define a RESTCONF capability URI to > indicate a new datastore was supported. > Andy, I think Dale used "datastore" in a wider sense, i.e., as 'RESTCONF instance'. For a given (DNS name, port) tuple, there is a restriction of at most one RESTCONF instance. /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 Fri Jun 17 00:29:45 2016 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 1754312B019 for ; Fri, 17 Jun 2016 00:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 vf72693wu_M6 for ; Fri, 17 Jun 2016 00:29:40 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEAB912B024 for ; Fri, 17 Jun 2016 00:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13127; q=dns/txt; s=iport; t=1466148580; x=1467358180; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=eKuO5csOpCPB+/AT5DpBS+fPOXGdE4XMZRmkR0jHFqc=; b=LRPhM6AX37j1I+cEtG+SKgBUTeVpXMnjNXlNTuGQhj/dFxlj+o0j16Ca kPuyOO+v8oEMxqo2fdqfmRQq2DMzXPoja17MbStZcAOgVWNXl7dZg4C8v X1IgXb9ot01oI63QSvNPIrFy7RI3Y+P6qjABhTIUWgRa1G5T1dy2gUNLe Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+BQB9pWNX/xbLJq1TCoQUK1KydIllF?= =?us-ascii?q?wuFK0YCAgKBdwEBAQEBAWYnhEwBAQQBAQE1KQ0bCxguJzAGAQwGAgEBBYgnDrM?= =?us-ascii?q?BjU4BAQEBAQEBAQEBAQEBAQEBAQEBAQEchieBd4JWhBAIEoVxBYgRgWuDeIVTh?= =?us-ascii?q?SqGBYgkgWlOhASDCiOFOoZOiSdUgggcgU46MgGINoFEAQEB?= X-IronPort-AV: E=Sophos;i="5.26,482,1459814400"; d="scan'208";a="638063200" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jun 2016 07:29:35 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u5H7TZCj013291; Fri, 17 Jun 2016 07:29:35 GMT To: "Dale R. Worley" , netconf@ietf.org References: <87d1niszr5.fsf@hobgoblin.ariadne.com> From: Benoit Claise Message-ID: <109369e1-c8b2-0b34-37fd-0468f5d25636@cisco.com> Date: Fri, 17 Jun 2016 09:29:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <87d1niszr5.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] Comments on draft-ietf-netconf-restconf-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 07:29:43 -0000 On 6/16/2016 3:12 AM, Dale R. Worley wrote: > This is a bunch of comments on draft-ietf-netconf-restconf-13. Some of > these comments might be redundant or due to misunderstanding because I'm > coming into this process late. But as I'm likely to be the Gen-ART > reviewer, it's best to take care of these now. Yes. Dale did such a good job on the gen-ART review of RFC6020bis that he accepted to review the RESTCONF document the same way. Thanks Dale. Regards, Benoit > > I think almost all of these comments are at the nits level. The two > comments that seem to have technical content are: > > - Leaf-list nodes may now have duplicated values, so identifying > leaf-list instances by value may not always work. But perhaps that > ambiguity never arises in practice due to restrictions on the CRUD > operations. > > - Any identifier that is materialized as an XML element or attribute > can't start with "xml" (with any case). This includes the data > nodes that are materialized in XML and extension keywords. But this > restriction isn't specified in draft-ietf-netmod-rfc6020. > > 1.1.4 > > o event stream resource: This resource represents an SSE (Server- > Sent Events) event stream. The content consists of text using the > media type "text/event-stream", as defined by the HTML5 > [W3C.REC-html5-20141028] specification. Each event represents one > message generated by the server. It contains a > conceptual system or data-model specific event that is delivered > within an event notification stream. Also called a "stream > resource". > > Is this correct? I can't find "event-stream" within > . It appears that the > latest Server-Sent Events specification is > . > > 3.5.1 > > If a data node in the path expression is a YANG leaf-list node, then > the leaf-list value MUST be encoded according to the following rules: > > o The instance-identifier for the leaf-list MUST be encoded using > one path segment [RFC3986]. > > o The path segment is constructed by having the leaf-list name, > followed by an "=" character, followed by the leaf-list value. > (e.g., /restconf/data/top-leaflist=fred). > > In item 2, does "leaf-list value" mean the encoded instance-identifier > of item 1? But the example below does not show a full > instance-identifier as one path segment, but only the leaf-list > element name and value as the last path segment: > > /restconf/data/example-top:top/Y=instance-value > > Perhaps item 1 means "the leaf-list name MUST be encoded ...". > > o Resource URI values returned in Location headers for data > resources MUST identify the module name, even if there are no > conflicting local names when the resource is created. This > > Is this restricted to list nodes, as its position indicates? Or is it > generally applicable, and should be pulled out to a top-level > paragraph? > > "identify the module name" is vague. I think this means that each > element name must be qualified with its module name. > > For the above YANG definition, a target resource URI for leaf-list > "Y" would be encoded as follows: > > /restconf/data/example-top:top/Y=instance-value > > Non-unique values are now allowed for leaf-lists, so this syntax may > be ambiguous. (Does this apply to instance-identifiers in modules?) > Perhaps the 'insert' and 'point' query parameters are used to > disambiguate non-unique leaf-list values? > > It seems that any netconf data node that is materialized as an XML > element can't start with "xml" (case-insensitive). But this is not > noted in draft-ietf-netmod-rfc6020 as a restriction. The existence of > YIN requires that extension keywords also may not start with "xml" > (case-insensitive). > > 3.6 > > POST /restconf/operations/module-A:reset HTTP/1.1 > Server example.com > > In two locations, the "Server" header is shown without a colon. > > If the operation is invoked without errors, and if the "rpc" or > "action" statement has an "output" section, then a message-body MAY > be sent by the server in the response, otherwise the response message > MUST NOT include a message-body in the response message, and MUST > send a "204 No Content" status-line instead. > > It seems odd that if an RPC is performed, then it is optional for the > output data to be returned to the client. > > > > This means the 'input' element of an RPC body is in the namespace of > the module. Similarly for 'output' elements. This is not specified > anywhere. (Errors is specified to be in "ietf-restconf" in section > 7.1.) > > 4 > > Operations are applied to a single data resource instance at once. > > IMO it would be useful to use the word "atomically", as that has > a well-understood meaning. > > 4.3 > > If a retrieval request for a data resource representing a YANG leaf- > list or list object identifies more than one instance, and XML > encoding is used in the response, then an error response containing a > "400 Bad Request" status-line MUST be returned by the server. > > What about zero instances? Presumably it gets a 404 response rather > than an empty body, but it would be good to specify that. > > Note that the way that access control is applied to data resources is > completely incompatible with HTTP caching. The Last-Modified and > ETag headers maintained for a data resource are not affected by > changes to the access control rules for that data resource. It is > possible for the representation of a data resource that is visible to > a particular client to be changed without detection via the Last- > Modified or ETag values. > > Note that it's possible for the client to detect changes in > configuration data that it is not allowed to read by detecting changes > in the Last-Modified/ETag values. This probably isn't a security > problem, but the authors should be aware of it. > > What does a GET of the datastore URL return? I would guess an XML > document with a top node of "datastore" (in the module namespace), but > that doesn't seem to be specified. Perhaps it is a known thing that > the datastore contains one instance of every top-level data node in > the module definition... but there can be multiple modules defined in > the server... Similarly, one can ask how PUT, POST, PATCH, and DELETE > are applied to the datastore resource. > > 4.4.1 > > The message-body MUST NOT contain more than one instance > of the expected data resource. > > It seems like you want "MUST contain exactly one", since it seems that > you don't want to allow zero instances. > > 4.6 > > This document defines one patch mechanism (Section 4.6.1). The YANG > PATCH mechanism is defined in [I-D.ietf-netconf-yang-patch]. Other > patch mechanisms may be defined by future specifications. > > This sentence isn't clear that "one patch mechanism" is different from > "The YANG PATCH mechanism ...". Perhaps: > > This document defines one patch mechanism (Section 4.6.1). Another > patch mechanism, the YANG PATCH mechanism, is defined in > [I-D.ietf-netconf-yang-patch]. Other patch mechanisms may be > defined by future specifications. > > 4.6.1 > > Plain patch can be used to create or update, but not delete, a child > resource within the target resource. Please see > [I-D.ietf-netconf-yang-patch] for an alternate media-type supporting > more granular control. > > I assume this means "supporting deletion of child resources". > > 4.8 > > | point | POST, PUT | Insertion point for ordered-yb | > > "ordered-yb" should be "ordered-by". > > o Each parameter can appear at most once in a request URI. > > Despite being given here as a general rule, it is repeated in 4.8.2, > 4.8.3, 4.8.4, 4.8.5, 4.8.6, 4.8.7, 4.8.8, and 4.8.9 (but not 4.8.1). > Also, if the repetition is to be removed, the general rule needs to > add "If more than one instance is present, then a "400 Bad Request" > status-line MUST be returned by the server." > > 4.8.2 > > By default, the server will include all sub-resources within a > retrieved resource, which have the same resource type as the > requested resource. Only one level of sub-resources with a different > media type than the target resource will be returned. The exception > is the datastore resource. If this resource type is retrieved then > by default the datastore and all child data resources are returned. > > Does the second sentence do anything? The only instance I know of of > a node whose media type is different from that of its child nodes is > the the datastore resource, and that is specifically exempted from the > effect of the 2nd sentence. > > 4.8.3. > > I take it that > > "fields=admin(label;catalogue-number)". > > is equivalent to > > "fields=admin/label;admin/catalogue-number" > > But the lack of a / before the ( is not really standard practice and > might trip up users. (Compare with Un*x shell "/a/b/c/{d,e}" and > "/a/b/c{d,e}".) > > 4.8.7 > > It is not valid to specify start times that are later than the > current time. > > It seems that there needs to be a way for the client to determine the > time the *server* thinks it is. The client can't use its own clock, > because there can be clock skew between the client and the server, and > also the server may not know what time it is, so its time scale could > have an arbitrary offset from real time. > > 7 > > Since an operation resource is defined with a YANG "rpc" statement, > and an action is defined with a YANG "action" statement, a mapping > between the NETCONF value and the HTTP status code is > needed. The specific error condition and response code to use are > data-model specific and might be contained in the YANG "description" > statement for the "action" or "rpc" statement. > > I assume this means "The specific error-tag value and response code > ..."; the word "condition" appears nowhere else in the draft. > > +-------------------------+-------------+ > | | status code | > +-------------------------+-------------+ > > Why is "‑" (‑, NON-BREAKING HYPHEN) used here? > > 7.1 > > [...] then the server SHOULD send a response > message-body containing the information described by the "errors" > container definition within the YANG module Section 8. > > There's probably a missing word before "Section 8". Specifically, > this sentence needs to say that "errors" is defined in the YANG module > "ietf-restconf" -- as the sentence stands, it's easy to assume that > "errors" is within "the YANG module", i.e., the one defining the > operation. > > 11.2 > > Looking at RFC 3688 and the registry > (http://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns) > it looks like you want to explicitly say that the URIs are being > registered as namespaces in the IETF XML registry. > > 11.4 > > o the name of the RESTCONF capability. By convention, this name is > prefixed with the colon ':' character. > > I think "begins" rather than "prefixed" is preferable, as it makes > clear that the colon is part of the name, rather than being prepended > to the name. > > 13 > > Who is The Space & Terrestrial Communications Directorate? Maybe it > would add to the credit of the S&TCD by prefixing the country that > funds it ... which seems to be "United States Army". > > 8. > > draft-ietf-netmod-yang-json defines > JSON encoding rules for all RESTCONF media types that > use the '+json' suffix. > > There needs to be an RFC Editor note to replace > "draft-ietf-netmod-yang-json" with the eventual RFC name. > > D.1.3 > > > > Is it true that there's no NS URN? Section 9.3 suggests it should > have namespace "urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring". > > D.2.1 > > Note that the "Location" header line is wrapped for display purposes > only: > > You might want to promote this comment to a higher section, as > wrapping is done in other places. > > D.3.4 > > Location: https://example.com/restconf/data/ > example-jukebox:jukebox/playlist=Foo-One/song=1 > > But the text doesn't say that the Location header is wrapped only for > display purposes. > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > . > From nobody Fri Jun 17 04:51:33 2016 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 A0C0712D587 for ; Fri, 17 Jun 2016 04:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 xSARuyupPLZk for ; Fri, 17 Jun 2016 04:51:29 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 6938F12D576 for ; Fri, 17 Jun 2016 04:51:27 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id u64so112367595vkf.3 for ; Fri, 17 Jun 2016 04:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=+b5oC4Qqsz0hXldXCEREUmZUQe+1Gyvx5IrHfSPbCE8=; b=k9k2yfyaabiSkcOqK2AvDga3Y74+QMN2WYnj12D6Wuc0EXlG/QLXo6F9z1YRQ2SD05 gqxo3+cFxL6XHDzuMVcnH1j0jnMafdmJ+NeyjQ5obxVLG5xQ1VvziNKcnD5gN38bGCun BrPcNH8UzUOKAphLn/WV0WxhEq0PNcYQm9Q85A6uOzVy4xPNANy5tlal1RlFQEN4o+u9 3wCg4TxBh1lkWl+G/e34znsXqHK/qDa50U9L/v3xCRIrP6iboyZXQUutN8Tl30W7wVaz 8Z1ZDb7rccZhx4B6Y1tUD1yKO5Pw0smENF+NOy6he7SHZgxCJhC0opwYckw29fZ5BSeJ hxjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=+b5oC4Qqsz0hXldXCEREUmZUQe+1Gyvx5IrHfSPbCE8=; b=kJLW2vlGUKLYEzGN9hes3r71+ltTil66/eku2XDppDJKxXcXCcGbS5xotzaCgNzTiS pF1jtL8FoR61mDnPIMhcKxnBHVBVJsOjak0ggulgxloBnZnJRZyakJBZvYJmLbMJNp4J rQyWghZxarS5/hZSoz/t+79zJ9pfQZniyT4XLm3HTHJ7WLlweJtGmuPEz/7stgGPDs3U RCGzVK697hB9mq+wlDAy+35/BKmC18XMKv4jVI4bdbse5qwEnPjZKMvIC0XRns9Giutf 26WCPVPZ8/FNWk/nPjMHpyUpVg89wmTfPeh83L2W+zZUYANfxTtlR2TUtgOnYhrwYN8L aoNg== X-Gm-Message-State: ALyK8tIS/DNEoU8wohwwv+O5qGyDDkim7ZVMsS82aumv0eqV9KjDW0ISMJreeLBXKGlRz/xJzTUj23sEJ1nBBg== MIME-Version: 1.0 X-Received: by 10.159.35.72 with SMTP id 66mr675844uae.55.1466164286474; Fri, 17 Jun 2016 04:51:26 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Fri, 17 Jun 2016 04:51:26 -0700 (PDT) In-Reply-To: <20160617062630.GA34404@elstar.local> References: <87r3bytq73.fsf@hobgoblin.ariadne.com> <20160617062630.GA34404@elstar.local> Date: Fri, 17 Jun 2016 04:51:26 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "Dale R. Worley" , Netconf Content-Type: multipart/alternative; boundary=001a113530927a644f053577f93d Archived-At: Subject: Re: [Netconf] FW: [netmod] The Restconf root X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 11:51:31 -0000 --001a113530927a644f053577f93d Content-Type: text/plain; charset=UTF-8 On Thu, Jun 16, 2016 at 11:26 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Jun 16, 2016 at 08:27:56PM -0700, Andy Bierman wrote: > > On Wed, Jun 15, 2016 at 8:41 AM, Dale R. Worley > wrote: > > > > > Kent Watsen writes: > > > > We understand that templates may be a best practice for other HTTP > > > > servers, but believe that what we have now is perfect for this use. > > > > Do you still feel that we can do better? > > > > > > Mostly, I wanted to know that the WG had considered the question. > > > > > > This question may be coupled to another one: The draft assumes that > the > > > HTTP URL authority part (DNS name and port) is associated with exactly > > > one RESTCONF datastore, because the well-known service mechanism can > > > point to only one root URL. > > > > > > I suppose this is the most common case. Though RESTCONF could support > > > multiple datastores, each with its own root URL, as long as there was > > > some other mechanism for locating the roots. > > > > > > > You mean we cannot add /restconf/candidate or /restconf/my-datastore? > > I think an SDO or vendor could define a RESTCONF capability URI to > > indicate a new datastore was supported. > > > > Andy, > > I think Dale used "datastore" in a wider sense, i.e., as 'RESTCONF > instance'. For a given (DNS name, port) tuple, there is a restriction > of at most one RESTCONF instance. > > So why is this a problem? Run the server on abnothe port if you want 2 of them. > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a113530927a644f053577f93d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jun 16, 2016 at 11:26 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Jun 16, 2016 at 08:27:56PM -0700, Andy Bier= man wrote:
> On Wed, Jun 15, 2016 at 8:41 AM, Dale R. Worley <worley@ariadne.com> wrote:
>
> > Kent Watsen <kwatsen@ju= niper.net> writes:
> > > We understand that templates may be a best practice for othe= r HTTP
> > > servers, but believe that what we have now is perfect for th= is use.
> > > Do you still feel that we can do better?
> >
> > Mostly, I wanted to know that the WG had considered the question.=
> >
> > This question may be coupled to another one:=C2=A0 The draft assu= mes that the
> > HTTP URL authority part (DNS name and port) is associated with ex= actly
> > one RESTCONF datastore, because the well-known service mechanism = can
> > point to only one root URL.
> >
> > I suppose this is the most common case.=C2=A0 Though RESTCONF cou= ld support
> > multiple datastores, each with its own root URL, as long as there= was
> > some other mechanism for locating the roots.
> >
>
> You mean we cannot add /restconf/candidate or /restconf/my-datastore?<= br> > I think an SDO or vendor could define a RESTCONF capability URI to
> indicate a new datastore was supported.
>

Andy,

I think Dale used "datastore" in a wider sense, i.e., as 'RES= TCONF
instance'. For a given (DNS name, port) tuple, there is a restriction of at most one RESTCONF instance.


So why is this a problem?
Run the server o= n abnothe port if you want 2 of them.

=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<http://www.jacobs-university.de/>

--001a113530927a644f053577f93d-- From nobody Fri Jun 17 06:42:39 2016 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 4796112D662 for ; Fri, 17 Jun 2016 06:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 jm1X2L3zIsmc for ; Fri, 17 Jun 2016 06:42:36 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 93EB112D661 for ; Fri, 17 Jun 2016 06:42:36 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 5D928C0AEE5F7 for ; Fri, 17 Jun 2016 13:42:33 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u5HDgZEh012123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 17 Jun 2016 13:42:35 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u5HDgX8k005582 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 17 Jun 2016 13:42:34 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Fri, 17 Jun 2016 09:41:39 -0400 From: "Sterne, Jason (Nokia - CA)" To: "netconf@ietf.org" Thread-Topic: =?Windows-1252?Q?Is_a_=91replace=92_operation_on_the_candidate_datastore_?= =?Windows-1252?Q?always_the_same_as_=91delete=92_+_=91merge=92_=3F?= Thread-Index: AdHInfgKCpxddkN2T9O8LwkomHEPFg== Date: Fri, 17 Jun 2016 13:41:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CCB4BF6US70TWXCHMBA11z_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] =?windows-1252?q?Is_a_=91replace=92_operation_on_the_ca?= =?windows-1252?q?ndidate_datastore_always_the_same_as_=91delete=92_+_=91m?= =?windows-1252?q?erge=92_=3F?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 13:42:38 -0000 --_000_A125E53CE190A749957C19483DC79F9F5CCB4BF6US70TWXCHMBA11z_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, I buried this question in another thread and it had some initial discussion= but we never really clarified it. I mostly want to ignore the running DS = for this specific question and just focus on the candidate. Is a =91replace=92 operation on the candidate datastore always the same as = =91delete=92 + =91merge=92 in all cases ? Are there any corner cases where= the result is not the same (e.g. replace at the top levels, empty values, = NACM, etc) ? i.e. is =91replace=92 (in a candidate config) simply the =93one-step=94 equ= ivalent of doing a =91delete=92 and then a =91merge=92 with: =95 identical data in the =91replace=92 and =91merge=92 =95 the =91replace=92 and =91delete=92 operation on the same node in = the requests ? # Replace: eth0 interface number 1 # Equivalent delete + merge (in two separate requests): <--operation not really necessary = here eth0 interface number 1 Regards, Jason --_000_A125E53CE190A749957C19483DC79F9F5CCB4BF6US70TWXCHMBA11z_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I buried this question in another thread and it had some initial discu= ssion but we never really clarified it.  I mostly want to ignore the r= unning DS for this specific question and just focus on the candidate.
 
Is a =91replace=92 operation on the candidate datastore always the sam= e as =91delete=92 + =91merge=92 in all cases ?  Are there any corn= er cases where the result is not the same (e.g. replace at the top levels, = empty values, NACM, etc) ?
 
i.e. is =91replace=92 (in a candidate config) simply the =93one-step= =94 equivalent of doing a =91delete=92 and then a =91merge=92 with:
=95       identical data in the =91repla= ce=92 and =91merge=92
=95       the =91replace=92 and =91delet= e=92 operation on the same node in the requests ?
 
# Replace:
 
<interfaces xc:operation=3D=94replace=94>
  <interface>
    <name>eth0</name>
    <description>interface number 1</descripti= on>
  </interface>
</interfaces>
 
# Equivalent delete + merge (in two separate <edit-config> r= equests):
 
<interfaces xc:operation=3D=94delete=94/>
 
<interfaces xc:operation=3D=94merge=94>  =DFoperation not really necessary here
  <interface>
    <name>eth0</name>
    <description>interface number 1</descripti= on>
  </interface>
</interfaces>
 
Regards,
Jason
 
 --_000_A125E53CE190A749957C19483DC79F9F5CCB4BF6US70TWXCHMBA11z_-- From nobody Fri Jun 17 08:17:50 2016 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 4476E12D751 for ; Fri, 17 Jun 2016 08:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" 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 3zkBfyU7nIk6 for ; Fri, 17 Jun 2016 08:17:45 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0708.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::708]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2257712D764 for ; Fri, 17 Jun 2016 08:17:44 -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; bh=Cd3AyCED6xoVN5fSTH/BsJgkY3sb6cq/roHGq6BPMS4=; b=ZShvIAF04OgYVY0pYHLsJNxUV2XmYc04nbOjaeHFs39vbtP56eJBeXjSKU9qJoxDfBGatZarXCua6tXZFRt7fDJrU3DEhB3tJZ/VFvyQhWafCFSzLTWT/W0wXv+rzHcCBFRSGjFyEFKS3qxqN6nlbtSW0JYjcVHej2Jh5CEhLKE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.151.165.8) by DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149) with Microsoft SMTP Server (TLS) id 15.1.517.8; Fri, 17 Jun 2016 15:17:27 +0000 Message-ID: <008601d1c8ab$20cfb0e0$4001a8c0@gateway.2wire.net> From: t.petch To: "Sterne, Jason (Nokia - CA)" , References: Date: Fri, 17 Jun 2016 16:11:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.165.8] X-ClientProxiedBy: DB5PR08CA0039.eurprd08.prod.outlook.com (10.163.102.177) To DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149) X-MS-Office365-Filtering-Correlation-Id: 2844c793-72f7-455c-fdf9-08d396c27e3f X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 2:dfSewXnNxWzpJtvnx+5GS8DaXWDvrcc8jx0TS2rd2qoxHQOQLTVmBVQ4e0lm//ZUIpakU9/Uf6bkNgM2Tr0MenIMmhty3DICgcKMD9jrCiw+4GWEsD1sQdf/W8CPm4tAiKE6cVcIL+0Dy+mbRZZ8BthMzlFJOw+ZqRnR34JrbwrVhMiN32WiGyPSWO6flk0Z; 3:s81BwdI5nLf31AThwK6v5JueqATygm1A4dR1vNgI66IRl+z7T/bFUdYiEiGqRHA7iJKrsVoJErDZFU3Z7xA/NYL0MdTEcgTCgXV9Phl2KFclU5Y8SvBepvt3eMsKIfSQ X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR07MB1622; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 25:TduFw1IZ8J6higkBDMUOpBkWw2rzhRoWH7rPy8JIHfCw4S071yYPFI1nTr2YXkCkRQM57fzN9i6T0rpndzNDYMlSM/qSNBpWJWAl7Pl5dfb2ehsW/BOn33cUgUTh+tDcM/7GLhAwkQinfZv+u+sHJA6/IW3vKZpr/vmqFjGUPgf1aSCoMaSsVRdsIVlIjAzd7cAoPmoPkrINvIXHYur0HBG/kpGQEH2iyidjxNns/2NJcwfw7TUbLhIk+zM4Q0V9DNrp5xaMW/+KTEjyA+lU3XzcPUbBuUw6a1/67xl1m45lWAoBU1c6jTwx1qaD6Q6xepIlmOmq59ZEfrlYsba9Q9ignf4qWzQz1ZachGkTr82tAfLlRxCOS6sbKjLvW3Awvgk3V+zvMWCk4LbkyhQnulOE12HB4mmci9vYFWa6QyEtweiO3KEDBGarId3IWawBOZ8NvB5r2ZcWFQqPr2t2HhzuYDg0EfSUN8EIgApLgQNLyVmccn1oR/HiPUT5Y7oUK53yDyNZPR3pjeYebuwXYocKC5cysJHvIdLe8oShOjz7n7LvI4wTW12mp/Amn6uQLUw/kg+ckPEJigJaxpVcBnBp2NEDkM696MTLqwDeq+UDACO5eZUmKGrwMft20Kdy7Jh3niPKWbhBIBeZpOfXWweG3fJWHZsHinqHobVRWco6rs6WH/DeeXgXyMga9SjdnKuCOe4ob+/7xeDuTGYe21iQKOLlCyibwDf4A1gzFeB218V+9KgI5ODNtEPN57eiUfnXjR3gWH5FSbMDHAYE5rQ7SU7Zw6jHFJZ7kW4hL1qb/106JV9OwFigbSMFp/d7 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(82608151540597)(788757137089); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:DB5PR07MB1622; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1622; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 4:m9gzSdi7jhOCVARGDPQ1CpVqxdqByHtD9acXVvGqWLSb+2WQZluXSQlsCCQDhpDWxAuCOBNPc72InlsRFROzoNrIIVM9ZjR62tYotFy0b9tPO60arSG5AZnPBS4USpTU4oBOjWksEBUJOzNg/+nQr/Qfsni9XKLtX7qIXxdiDbsPqkLxYWXr0GvY7FtJ//o1sOnEvXDV3RvrrYF6VJE6z/XFjUBWRD92jBk7yX/g4Gx4Wc30AOqkcsK8oXoR0Wnv/JNZmd0y7LjnI2JmQAgugg/2X9Pd9VBPZHclUs9MKipGXJ1Sp3FriFqojrRjW2GqMI/uoOuZqHC8ET3B74rrClzEXKUVeoHfICBeuQ8irzhEfHyL1Infbncb7A7tyOBcHHX4upqgYGyNHG1DnCZipsF1UXPoJsfCslQJ91Gwa/jj+uqwbRbbtLbYv7yXbxDF X-Forefront-PRVS: 09760A0505 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(53754006)(189002)(377454003)(13464003)(199003)(101416001)(81156014)(106356001)(81166006)(5008740100001)(33646002)(66066001)(77096005)(23746002)(15975445007)(50466002)(105586002)(62236002)(2906002)(44716002)(47776003)(84392002)(86362001)(42186005)(44736004)(2870700001)(81686999)(76176999)(50986999)(50226002)(14496001)(6116002)(3846002)(586003)(19580395003)(61296003)(81816999)(5004730100002)(19580405001)(5001770100001)(97736004)(9686002)(1456003)(107886002)(1556002)(189998001)(68736007)(116806002)(92566002)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1622; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; CAT:NONE; LANG:en; CAT:NONE; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; DB5PR07MB1622; 23:DYJ/Jl59V5W8XT/+7Z3fxah2FI6akK9ExcNcB?= =?Windows-1252?Q?7BAbxslSWj5Azeqig58OvdFmblYAR23znTeQCiEwLu5AqUj8h9Si4nW9?= =?Windows-1252?Q?49Bk/pdjdfOHj7lr7p0WxH1xPLqHLxP1KSkTUjDnJAh5xbWqRsFPIYyA?= =?Windows-1252?Q?hgePZ6dtsjpLvOcMSJFN3lI3s7cZAFO3P9ZwM7G0/ZxNMXNWs7XYx/84?= =?Windows-1252?Q?ylW2B/XlyChcG+34Zz4XKc037hf/qND5920rtEVRkIhhJNaFALKWm8PU?= =?Windows-1252?Q?OwsJuvnlSuKtVpe65rEWOjXry5A2pqcPYifdl3KJW8es3YrsT2Pr2rrO?= =?Windows-1252?Q?Tqv31fD2PGxIHWX2W1M6qNYhrxg7oT20rXLsgYherqRg4VVYVr9S5JE7?= =?Windows-1252?Q?+wxu4WXGnem3DNgOIsuUqWZ8XDyuocBuWo58ZYwHbjdwDg6VLbAbNAwf?= =?Windows-1252?Q?MmFlwdPQaEMUSpdppMIgqJI4rCR5CBdyLznkecN44d8Q4/BW+uSykY5z?= =?Windows-1252?Q?PxQRM36HnclqDwhtJUEv2Rxs89JQOnMszlNNgGXr3xmgjuTydaNIWUEM?= =?Windows-1252?Q?uKUGfcKDwzUhPZESeGOZ/n8pSIhBCwadGfA0uc4Fbb0dgQstIb5Uzi+E?= =?Windows-1252?Q?9wFB/HhzfRg/ocPIrbCiFpOxt3KxdSfA6/z/TEJFf1wfApCgq8C1V5BS?= =?Windows-1252?Q?FBmdqRpkJxmxmSSWhPKzVCv8HIvXDzQZBjeDRw0UOKX2k/IJSNIZLCIO?= =?Windows-1252?Q?0HsdrvpcFNaJRURBouZjG3wpYpRNzeGwE3JggomVm2wSIMQA6aNQvUWA?= =?Windows-1252?Q?rulWjz9u4Ks3slntkvNUOHeOgeUGDDY6iYIkyvO8bu97m8mJBtz0pGIs?= =?Windows-1252?Q?tRI0e3PdNY/oNNEx6f9EfvdHWIDyzt631/xGUQsCpXBec/AXGxQj6Vjg?= =?Windows-1252?Q?RqaosJ41Xb4EbCCRKUfC/ws/EKfLqvrrFzWrHy61Msw/Nmx5UoI0wSlp?= =?Windows-1252?Q?YSFzMOEopf8gAIwlirO4IBifjioUOYtEDXd3H/Cspqz3iOIcjSBimiSb?= =?Windows-1252?Q?XR/Uww5DyaHXhDqiUGlVBlXYWnBBPuqGs+NvJsx0bzSIImtlK3k0AN2g?= =?Windows-1252?Q?zZnLbdaALD8YUPZuHWpk1gApMEP4F5/CklRYrnZA6LoNNjie2gg/FM6p?= =?Windows-1252?Q?z7iokMMuA4XnHHvJitGu9qJ4+BQRhQsD2qsJwJ2df9/wCBQauyzDF0GK?= =?Windows-1252?Q?6/kD7d0liMldcMpexyJDQA1uGHZ4mhjEe48sfClDisqQYUjzL9XSjcdI?= =?Windows-1252?Q?3FB+b9IPtyvBpevXdxJZKTzdIb+aqHIH51yH++emGujAhMW4kiTTlCqO?= =?Windows-1252?Q?TSm5vDPV8EwMYnqQGT+dL3+/sLdct6Yp+yJevMa+g6g68RO+sfiSAwMp?= =?Windows-1252?Q?CciMDpgT3wcfWEkUrAgwsnKDmVHIBFe6mfVKF+i+euzM5d8fa8JA6x3M?= =?Windows-1252?Q?CriU5w=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 6:mVvAe+cCdUaITaYP2xrZxSJeATtqEzdXRCG2hEV/gYKmtr2Yj6Au8FwR6VTgqmr6BTQ170bOpja3jXkWbNMQw45qvuiWyg8SSURE7c1JLbpprCrftioG2pGVCFCMhu9fiETyqCtR14rX50/qVpusid/Qpt5rkFeAZ5d6vp8GMapUHRAwqJzRBrY7b0RUe91UiFz9DomrKtN3XBKy5VxV1fAm0ImdN3RAqMOoZ2U7MozyIUggRiHgaUXMLJL+sWvLhVeszrQw3c4wO4SRMVnY8YUimcqVLxId1CnFO5B3Hdw=; 5:NffDJvPR9S3zcmJILfhl3ukoZaWxyjnWn+VT788q2On6A5nchv96W/6zbDWnbvbXzdEnmOje+qI8Cmn7HFX3K+CsUi0Swm1yxbc2d1UF1WhU4RXLjYh/pCDXiJfVrymKzpot3qSxzWkbrp3ct+C7AQ==; 24:aWyaVDkjoPMrP/mB23yCGb9oEZFT+lUd1864cSvwuT/ZbYiS8ABdwdf+pZeBBKLWPPet4fkloMjd20LRvPEy9IfmA5n0rEEn4p4uo+qrtQc=; 7:BsrXa2hYCUYcUWBhQX51W6nDkILBPxHLvvHjiofTuaUleDDmr/jLj3OL/6BQsisCiPMpzOqVSrRcxA/P/zQId3bnXUEylxMSXdmwYPbxdwjxAUQxWmysRTMrk/694gGxFNLOMZxcIYfGCe0OYOw8VYKpwV7i31VhpK5fvgakufZS9Af/xahZhsinnB/rPm0CsVzvarr2iTvwJ5jVGbIFWw== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2016 15:17:27.3875 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1622 Archived-At: Subject: Re: [Netconf] =?windows-1252?q?Is_a_=91replace=92_operation_on_the_ca?= =?windows-1252?q?ndidate_datastore_always_the_same_as_=91delete=92_+_=91m?= =?windows-1252?q?erge=92_=3F?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 15:17:48 -0000 ---- Original Message ----- From: "Sterne, Jason (Nokia - CA)" To: Sent: Friday, June 17, 2016 2:41 PM Hi all, I buried this question in another thread and it had some initial discussion but we never really clarified it. I mostly want to ignore the running DS for this specific question and just focus on the candidate. Is a ‘replace’ operation on the candidate datastore always the same as ‘delete’ + ‘merge’ in all cases ? Are there any corner cases where the result is not the same (e.g. replace at the top levels, empty values, NACM, etc) ? i.e. is ‘replace’ (in a candidate config) simply the “one-step” equivalent of doing a ‘delete’ and then a ‘merge’ with: • identical data in the ‘replace’ and ‘merge’ • the ‘replace’ and ‘delete’ operation on the same node in the requests ? Simplistically no; delete requires the node to exist else it errors, while replace will accept a non-existent node and create it. Tom Petch # Replace: eth0 interface number 1 # Equivalent delete + merge (in two separate requests): <--operation not really necessary here eth0 interface number 1 Regards, Jason ------------------------------------------------------------------------ -------- > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Fri Jun 17 08:21:18 2016 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 5C77C12D697 for ; Fri, 17 Jun 2016 08:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 6RnH6JFE2EDz for ; Fri, 17 Jun 2016 08:21:16 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (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 1CB0C12D590 for ; Fri, 17 Jun 2016 08:21:16 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id CED42FE0E070D; Fri, 17 Jun 2016 15:18:48 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u5HFLDWI006697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Jun 2016 15:21:14 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u5HFLDk2008933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Jun 2016 15:21:13 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Fri, 17 Jun 2016 11:21:13 -0400 From: "Sterne, Jason (Nokia - CA)" To: "t.petch" , "netconf@ietf.org" Thread-Topic: =?Windows-1252?Q?[Netconf]_Is_a_=91replace=92_operation_on_the_candidate_?= =?Windows-1252?Q?datastore_always_the_same_as_=91remove=92_+_=91merge=92_?= =?Windows-1252?Q?=3F?= Thread-Index: AQHRyKviEn45QgdrIEW3IU8FNjK1VA== Date: Fri, 17 Jun 2016 15:21:13 +0000 Message-ID: References: <008601d1c8ab$20cfb0e0$4001a8c0@gateway.2wire.net> In-Reply-To: <008601d1c8ab$20cfb0e0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] =?windows-1252?q?Is_a_=91replace=92_operation_on_the_ca?= =?windows-1252?q?ndidate_datastore_always_the_same_as_=91remove=92_+_=91m?= =?windows-1252?q?erge=92_=3F?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 15:21:17 -0000 Sorry - I realize I really meant to ask if it is the same as 'remove' + 'me= rge'. Renaming the subject and reforming the example: i.e. is =91replace=92 (in a candidate config) simply the =93one-step=94 equivalent of doing a =91remove and then a =91merge=92 with: =95 identical data in the =91replace=92 and =91merge=92 =95 the =91replace=92 and =91remove' operation on the same node in th= e requests ? # Replace: eth0 interface number 1 # Equivalent remove + merge (in two separate requests): <--operation not really necessary = here eth0 interface number 1 Jason -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com]=20 Sent: Friday, June 17, 2016 11:11 To: Sterne, Jason (Nokia - CA); netconf@ietf.org Subject: Re: [Netconf] Is a =91replace=92 operation on the candidate datast= ore always the same as =91delete=92 + =91merge=92 ? ---- Original Message ----- From: "Sterne, Jason (Nokia - CA)" To: Sent: Friday, June 17, 2016 2:41 PM Hi all, I buried this question in another thread and it had some initial discussion= but we never really clarified it. I mostly want to ignore the running DS = for this specific question and just focus on the candidate. Is a =91replace=92 operation on the candidate datastore always the same as = =91delete=92 + =91merge=92 in all cases ? Are there any corner cases where= the result is not the same (e.g. replace at the top levels, empty values, = NACM, etc) ? i.e. is =91replace=92 (in a candidate config) simply the =93one-step=94 equivalent of doing a =91delete=92 and then a =91merge=92 with: =95 identical data in the =91replace=92 and =91merge=92 =95 the =91replace=92 and =91delete=92 operation on the same node in = the requests ? Simplistically no; delete requires the node to exist else it errors, while = replace will accept a non-existent node and create it. Tom Petch # Replace: eth0 interface number 1 # Equivalent delete + merge (in two separate requests): <--operation not really necessary = here eth0 interface number 1 Regards, Jason ------------------------------------------------------------------------ -------- > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Fri Jun 17 08:24:42 2016 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 AFC8612D590 for ; Fri, 17 Jun 2016 08:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 R8MRs3eBeSlb for ; Fri, 17 Jun 2016 08:24:40 -0700 (PDT) Received: from p3plsmtpa06-09.prod.phx3.secureserver.net (p3plsmtpa06-09.prod.phx3.secureserver.net [173.201.192.110]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ECFE12D761 for ; Fri, 17 Jun 2016 08:24:40 -0700 (PDT) Received: from xiangliToshiba ([24.13.90.46]) by p3plsmtpa06-09.prod.phx3.secureserver.net with id 7rQe1t00N100Es801rQf8l; Fri, 17 Jun 2016 08:24:39 -0700 From: "Xiang Li" To: "'Sterne, Jason \(Nokia - CA\)'" , "'t.petch'" , References: <008601d1c8ab$20cfb0e0$4001a8c0@gateway.2wire.net> In-Reply-To: Date: Fri, 17 Jun 2016 10:24:33 -0500 Message-ID: <01d901d1c8ac$5a381510$0ea83f30$@seguesoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKkH1DtykJXErBBPixX1pTJQ3Mb0gIFBx9ZATl9gLyeLyU+UA== Content-Language: en-us Archived-At: Subject: Re: [Netconf] Is a 'replace' operation on the candidate datastore always the same as 'remove' + 'merge' ? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 15:24:42 -0000 I think even woth "remove", these two examples are not equivalent at all, specifically: Would remove everything under the container interfaces. For 'replace' in , only the configuration actually present in the parameter is affected. Thus if you send the following request( assuming leat name is list key): eth0 interface number 1 and If the existing instance data in the server is: eth0 interface number 9999999 eth1 interface number 2 Then after replacing, it would become eth0 interface number 1 eth1 interface number 2 Note the data on the server eth1 interface number 2 Would never be removed for this edit-config. -Xiang > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Sterne, > Jason (Nokia - CA) > Sent: Friday, June 17, 2016 10:21 AM > To: t.petch ; netconf@ietf.org > Subject: Re: [Netconf] Is a 'replace' operation on the candidate datastore > always the same as 'remove' + 'merge' ? > > Sorry - I realize I really meant to ask if it is the same as 'remove' + 'merge'. > Renaming the subject and reforming the example: > > i.e. is 'replace' (in a candidate config) simply the "one-step" > equivalent of doing a 'remove and then a 'merge' with: > . identical data in the 'replace' and 'merge' > . the 'replace' and 'remove' operation on the same node in the > requests ? > > # Replace: > > > > eth0 > interface number 1 > > > > # Equivalent remove + merge (in two separate requests): > > > > <--operation not really necessary here > > eth0 > interface number 1 > > > > Jason > > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Friday, June 17, 2016 11:11 > To: Sterne, Jason (Nokia - CA); netconf@ietf.org > Subject: Re: [Netconf] Is a 'replace' operation on the candidate datastore > always the same as 'delete' + 'merge' ? > > ---- Original Message ----- > From: "Sterne, Jason (Nokia - CA)" > To: > Sent: Friday, June 17, 2016 2:41 PM > > Hi all, > > I buried this question in another thread and it had some initial discussion but > we never really clarified it. I mostly want to ignore the running DS for this > specific question and just focus on the candidate. > > Is a 'replace' operation on the candidate datastore always the same as > 'delete' + 'merge' in all cases ? Are there any corner cases where the result > is not the same (e.g. replace at the top levels, empty values, NACM, etc) ? > > i.e. is 'replace' (in a candidate config) simply the "one-step" > equivalent of doing a 'delete' and then a 'merge' with: > . identical data in the 'replace' and 'merge' > . the 'replace' and 'delete' operation on the same node in the > requests ? > > > Simplistically no; delete requires the node to exist else it errors, while replace > will accept a non-existent node and create it. > > Tom Petch > > > # Replace: > > > > eth0 > interface number 1 > > > > # Equivalent delete + merge (in two separate requests): > > > > <--operation not really necessary here > > eth0 > interface number 1 > > > > Regards, > Jason > > > > > ------------------------------------------------------------------------ > -------- > > > > _______________________________________________ > > 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 Fri Jun 17 11:02:26 2016 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 53CF712D94E for ; Fri, 17 Jun 2016 11:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 DlNByMe49rPP for ; Fri, 17 Jun 2016 11:02:14 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (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 964C812D946 for ; Fri, 17 Jun 2016 11:02:14 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id E2D24E2064AF4; Fri, 17 Jun 2016 17:59:46 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u5HI2BZ2024559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Jun 2016 18:02:11 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u5HI29Zt021551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Jun 2016 18:02:11 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Fri, 17 Jun 2016 14:00:59 -0400 From: "Sterne, Jason (Nokia - CA)" To: Xiang Li , "'t.petch'" , "netconf@ietf.org" Thread-Topic: [Netconf] Is a 'replace' operation on the candidate datastore always the same as 'remove' + 'merge' ? Thread-Index: AQHRyKxgMhQMARZrw0CAohXUTf+4j5/t71xA Date: Fri, 17 Jun 2016 18:00:59 +0000 Message-ID: References: <008601d1c8ab$20cfb0e0$4001a8c0@gateway.2wire.net> <01d901d1c8ac$5a381510$0ea83f30$@seguesoft.com> In-Reply-To: <01d901d1c8ac$5a381510$0ea83f30$@seguesoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Is a 'replace' operation on the candidate datastore always the same as 'remove' + 'merge' ? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 18:02:17 -0000 Hi Xiang Li, I was referencing the ietf interfaces model. is a container. = I'm pretty sure that a replace operation at a container node removes all d= escendants of that container and replaces them with the data provided. I didn't show the full but for clarity here it is: =20 eth0 interface number 1 ]]>]]> If my request was this instead then only eth0 would be affected: > eth0 interface number 1 What if my original datastore contained the following: eth0 interface number 9999999 enabled and then I did the following : eth0 interface number 1 would the resulting datastore have the link-up-down-trap-enable leaf or not= ? The link-up-down-trap-enable was not in the parameter so by yo= ur definition it isn't affected. But I think the result is this: eth0 interface number 1 Regards, Jason -----Original Message----- From: Xiang Li [mailto:xiangli@seguesoft.com]=20 Sent: Friday, June 17, 2016 11:25 To: Sterne, Jason (Nokia - CA); 't.petch'; netconf@ietf.org Subject: RE: [Netconf] Is a 'replace' operation on the candidate datastore = always the same as 'remove' + 'merge' ? I think even woth "remove", these two examples are not equivalent at all, specifically: Would remove everything under the container interfaces. For 'replace' in , only the configuration actually present in= the parameter is affected. Thus if you send the following request( assuming leat name is list key): eth0 interface number 1 and If the existing instance data in the server is: eth0 interface number 9999999 eth1 interface number 2 Then after replacing, it would become eth0 interface number 1 eth1 interface number 2 Note the data on the server eth1 interface number 2 Would never be removed for this edit-config. -Xiang > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Sterne,=20 > Jason (Nokia - CA) > Sent: Friday, June 17, 2016 10:21 AM > To: t.petch ; netconf@ietf.org > Subject: Re: [Netconf] Is a 'replace' operation on the candidate=20 > datastore always the same as 'remove' + 'merge' ? >=20 > Sorry - I realize I really meant to ask if it is the same as 'remove'=20 > + 'merge'. > Renaming the subject and reforming the example: >=20 > i.e. is 'replace' (in a candidate config) simply the "one-step" > equivalent of doing a 'remove and then a 'merge' with: > . identical data in the 'replace' and 'merge' > . the 'replace' and 'remove' operation on the same node in the > requests ? >=20 > # Replace: >=20 > > > eth0 > interface number 1 > > >=20 > # Equivalent remove + merge (in two separate requests): >=20 > >=20 > <--operation not really necessary he= re > > eth0 > interface number 1 > > >=20 > Jason >=20 > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Friday, June 17, 2016 11:11 > To: Sterne, Jason (Nokia - CA); netconf@ietf.org > Subject: Re: [Netconf] Is a 'replace' operation on the candidate=20 > datastore always the same as 'delete' + 'merge' ? >=20 > ---- Original Message ----- > From: "Sterne, Jason (Nokia - CA)" > To: > Sent: Friday, June 17, 2016 2:41 PM >=20 > Hi all, >=20 > I buried this question in another thread and it had some initial discussion but > we never really clarified it. I mostly want to ignore the running DS=20 > for this > specific question and just focus on the candidate. >=20 > Is a 'replace' operation on the candidate datastore always the same as=20 > 'delete' + 'merge' in all cases ? Are there any corner cases where=20 > the result > is not the same (e.g. replace at the top levels, empty values, NACM,=20 > etc) ? >=20 > i.e. is 'replace' (in a candidate config) simply the "one-step" > equivalent of doing a 'delete' and then a 'merge' with: > . identical data in the 'replace' and 'merge' > . the 'replace' and 'delete' operation on the same node in the > requests ? >=20 > > Simplistically no; delete requires the node to exist else it errors,=20 > while replace > will accept a non-existent node and create it. >=20 > Tom Petch >=20 >=20 > # Replace: >=20 > > > eth0 > interface number 1 > > >=20 > # Equivalent delete + merge (in two separate requests): >=20 > >=20 > <--operation not really necessary he= re > > eth0 > interface number 1 > > >=20 > Regards, > Jason >=20 >=20 >=20 >=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 From nobody Fri Jun 17 14:59:11 2016 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 6EF2612DBCB for ; Fri, 17 Jun 2016 14:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 iXWnCiB767pV for ; Fri, 17 Jun 2016 14:59:07 -0700 (PDT) Received: from p3plsmtpa09-06.prod.phx3.secureserver.net (p3plsmtpa09-06.prod.phx3.secureserver.net [173.201.193.235]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02BA12DBD7 for ; Fri, 17 Jun 2016 14:59:06 -0700 (PDT) Received: from xiangliToshiba ([24.13.90.46]) by p3plsmtpa09-06.prod.phx3.secureserver.net with id 7xz41t00B100Es801xz4qT; Fri, 17 Jun 2016 14:59:06 -0700 From: "Xiang Li" To: "'Sterne, Jason \(Nokia - CA\)'" , "'t.petch'" , References: <008601d1c8ab$20cfb0e0$4001a8c0@gateway.2wire.net> <01d901d1c8ac$5a381510$0ea83f30$@seguesoft.com> In-Reply-To: Date: Fri, 17 Jun 2016 16:58:57 -0500 Message-ID: <000b01d1c8e3$73723150$5a5693f0$@seguesoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKkH1DtykJXErBBPixX1pTJQ3Mb0gIFBx9ZATl9gLwCcFiGAAGTjmQ1ng9zrgA= Content-Language: en-us Archived-At: Subject: Re: [Netconf] Is a 'replace' operation on the candidate datastore always the same as 'remove' + 'merge' ? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 21:59:10 -0000 Hi > -----Original Message----- > From: Sterne, Jason (Nokia - CA) [mailto:jason.sterne@nokia.com] > Sent: Friday, June 17, 2016 1:01 PM > To: Xiang Li ; 't.petch' ; > netconf@ietf.org > Subject: RE: [Netconf] Is a 'replace' operation on the candidate datastore > always the same as 'remove' + 'merge' ? > > Hi Xiang Li, > > I was referencing the ietf interfaces model. is a container. I'm > pretty sure that a replace operation at a container node removes all > descendants of that container and replaces them with the data provided. Ok...I misread the place where the "replace" attribute appears. > > If my request was this instead then only eth0 would be affected: > > > > eth0 > interface number 1 > > > Ok > What if my original datastore contained the following: > > > > eth0 > interface number 9999999 > enabled > > > > and then I did the following : > > > > eth0 > interface number 1 > > > > would the resulting datastore have the link-up-down-trap-enable leaf or not ? No Regards -Xiang > -----Original Message----- > From: Sterne, Jason (Nokia - CA) [mailto:jason.sterne@nokia.com] > Sent: Friday, June 17, 2016 1:01 PM > To: Xiang Li ; 't.petch' ; > netconf@ietf.org > Subject: RE: [Netconf] Is a 'replace' operation on the candidate datastore > always the same as 'remove' + 'merge' ? > > Hi Xiang Li, > > I was referencing the ietf interfaces model. is a container. I'm > pretty sure that a replace operation at a container node removes all > descendants of that container and replaces them with the data provided. > > I didn't show the full but for clarity here it is: > > > > > > > > > > > eth0 > interface number 1 > > > > > > ]]>]]> > > If my request was this instead then only eth0 would be affected: > > > > eth0 > interface number 1 > > > > What if my original datastore contained the following: > > > > eth0 > interface number 9999999 > enabled > > > > and then I did the following : > > > > eth0 > interface number 1 > > > > would the resulting datastore have the link-up-down-trap-enable leaf or not ? > The link-up-down-trap-enable was not in the parameter so by your > definition it isn't affected. But I think the result is this: > > > > eth0 > interface number 1 > > > > Regards, > Jason > > -----Original Message----- > From: Xiang Li [mailto:xiangli@seguesoft.com] > Sent: Friday, June 17, 2016 11:25 > To: Sterne, Jason (Nokia - CA); 't.petch'; netconf@ietf.org > Subject: RE: [Netconf] Is a 'replace' operation on the candidate datastore > always the same as 'remove' + 'merge' ? > > I think even woth "remove", these two examples are not equivalent at all, > specifically: > > > > Would remove everything under the container interfaces. > > For 'replace' in , only the configuration actually present in the > parameter is affected. > > Thus if you send the following request( assuming leat name is list key): > > > eth0 > interface number 1 > > > > > and If the existing instance data in the server is: > > > > eth0 > interface number 9999999 > > > eth1 > interface number 2 > > > > > Then after replacing, it would become > > > > eth0 > interface number 1 > > > > eth1 > interface number 2 > > > Note the data on the server > > eth1 > interface number 2 > > > Would never be removed for this edit-config. > > -Xiang > > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Sterne, > > Jason (Nokia - CA) > > Sent: Friday, June 17, 2016 10:21 AM > > To: t.petch ; netconf@ietf.org > > Subject: Re: [Netconf] Is a 'replace' operation on the candidate > > datastore always the same as 'remove' + 'merge' ? > > > > Sorry - I realize I really meant to ask if it is the same as 'remove' > > + > 'merge'. > > Renaming the subject and reforming the example: > > > > i.e. is 'replace' (in a candidate config) simply the "one-step" > > equivalent of doing a 'remove and then a 'merge' with: > > . identical data in the 'replace' and 'merge' > > . the 'replace' and 'remove' operation on the same node in the > > requests ? > > > > # Replace: > > > > > > > > eth0 > > interface number 1 > > > > > > > > # Equivalent remove + merge (in two separate requests): > > > > > > > > <--operation not really necessary here > > > > eth0 > > interface number 1 > > > > > > > > Jason > > > > -----Original Message----- > > From: t.petch [mailto:ietfc@btconnect.com] > > Sent: Friday, June 17, 2016 11:11 > > To: Sterne, Jason (Nokia - CA); netconf@ietf.org > > Subject: Re: [Netconf] Is a 'replace' operation on the candidate > > datastore always the same as 'delete' + 'merge' ? > > > > ---- Original Message ----- > > From: "Sterne, Jason (Nokia - CA)" > > To: > > Sent: Friday, June 17, 2016 2:41 PM > > > > Hi all, > > > > I buried this question in another thread and it had some initial > discussion but > > we never really clarified it. I mostly want to ignore the running DS > > for > this > > specific question and just focus on the candidate. > > > > Is a 'replace' operation on the candidate datastore always the same as > > 'delete' + 'merge' in all cases ? Are there any corner cases where > > the > result > > is not the same (e.g. replace at the top levels, empty values, NACM, > > etc) > ? > > > > i.e. is 'replace' (in a candidate config) simply the "one-step" > > equivalent of doing a 'delete' and then a 'merge' with: > > . identical data in the 'replace' and 'merge' > > . the 'replace' and 'delete' operation on the same node in the > > requests ? > > > > > > Simplistically no; delete requires the node to exist else it errors, > > while > replace > > will accept a non-existent node and create it. > > > > Tom Petch > > > > > > # Replace: > > > > > > > > eth0 > > interface number 1 > > > > > > > > # Equivalent delete + merge (in two separate requests): > > > > > > > > <--operation not really necessary here > > > > eth0 > > interface number 1 > > > > > > > > Regards, > > Jason > > > > > > > > > > ---------------------------------------------------------------------- > > -- > > -------- > > > > > > > _______________________________________________ > > > 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 Sun Jun 19 10:57:11 2016 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 AC86B12D66B for ; Sun, 19 Jun 2016 10:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 7tC9ew9rjike for ; Sun, 19 Jun 2016 10:57:08 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7B07912D667 for ; Sun, 19 Jun 2016 10:57:08 -0700 (PDT) Received: from localhost (h-46-190.a165.priv.bahnhof.se [46.59.46.190]) by mail.tail-f.com (Postfix) with ESMTPSA id 5B54A1AE018A; Sun, 19 Jun 2016 19:57:06 +0200 (CEST) Date: Sun, 19 Jun 2016 19:57:05 +0200 (CEST) Message-Id: <20160619.195705.1793240147923185529.mbj@tail-f.com> To: worley@ariadne.com From: Martin Bjorklund In-Reply-To: <87d1niszr5.fsf@hobgoblin.ariadne.com> References: <87d1niszr5.fsf@hobgoblin.ariadne.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] Comments on draft-ietf-netconf-restconf-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 17:57:10 -0000 worley@ariadne.com (Dale R. Worley) wrote: > - Any identifier that is materialized as an XML element or attribute > can't start with "xml" (with any case). This includes the data > nodes that are materialized in XML and extension keywords. But this > restriction isn't specified in draft-ietf-netmod-rfc6020. In section 14 (grammar) 6020bis says: ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l')) /martin From nobody Sun Jun 19 18:33:39 2016 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 A297512D897 for ; Sun, 19 Jun 2016 18:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 RW8PlhHwvz4T for ; Sun, 19 Jun 2016 18:33:35 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 0F3CA12D89D for ; Sun, 19 Jun 2016 18:33:34 -0700 (PDT) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7E2C322E255 for ; Sun, 19 Jun 2016 21:33:27 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Mon, 20 Jun 2016 11:33:24 +1000 To: netconf@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Netconf] RESTConf feedback X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 01:33:37 -0000 Pinging the list with some feedback I put into github: https://github.com/netconf-wg/restconf/issues/63 Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Sun Jun 19 22:41:37 2016 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 321E012D8E5; Sun, 19 Jun 2016 20:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.355 X-Spam-Level: X-Spam-Status: No, score=-14.355 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 noz5FKahEUVw; Sun, 19 Jun 2016 20:19:18 -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 E28B012D8DA; Sun, 19 Jun 2016 20:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4369; q=dns/txt; s=iport; t=1466392757; x=1467602357; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=6tsgS9zVU9zjpKS5/XFShMqQWUfYovAsZ3BO4+HZ28A=; b=d8beE8LymkW1qBncMUY9BlIrImj6+joLv1jmyMfIhr8qHuUmgT6v5LBU yPM5f1EVZ+kkX2Oh4yzLQSjm5UjfQzDMX0ExB4ZBquwi+0Adl54CRi7XK FrODAPlOkQBdgW6vCSI1yQYnI1B1UZvEEVSV45dUtIYOUr9/0JHP7ex6H k=; X-IronPort-AV: E=Sophos;i="5.26,496,1459814400"; d="scan'208";a="114633310" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jun 2016 03:19:17 +0000 Received: from [10.24.70.9] ([10.24.70.9]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u5K3JEeC027978; Mon, 20 Jun 2016 03:19:14 GMT To: Liaison Statement Management Tool , =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= , Joel Jaeggli , Tom Nadeau , Mahesh Jethanandani , Mehmet Ersue References: <20160518204443.14700.50752.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: Date: Sun, 19 Jun 2016 14:33:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160518204443.14700.50752.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Sun, 19 Jun 2016 22:41:36 -0700 Cc: NETMOD Working Group , "\\\"Kent Watsen\\\"" <"kwatsen@junip\""@ietfa.amsl.co>, joelja@bogus.com, IETF Chair , NETCONF , David Sinicrope Subject: Re: [Netconf] New Liaison Statement, "Liaison to IETF on YANG Models to enable G.fast deployments" X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 03:19:20 -0000 Dear all, The NETMOD and NETCONF WGs thank you for referencing the work of the IETF and contributing to the drafts you mention through the IETF process. This is by far the best way to complete the work in a timely manner and continues to foster the open and cooperative working relationship between the IETF and the Broadband Forum. In the mean time, the two drafts you note became WG documents: draft-ietf-netmod-entity and draft-ietf-netmod-intf-ext-yang-00. We encourage you to follow progress on data tracker https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/ and https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/ and through the participation you have noted. Regarding your interest to work on "forwarding/QoS and required protocols (e.g. layer 2 multicast model & DHCP)", please note that there are already a couple of forwarding related YANG data models, mainly L3 forwarding. There is also a QoS related YANG data model, draft-asechoud-netmod-qos-model, which we believe could become a WG document. And finally, a YANG multicast design team, https://trac.tools.ietf.org/wg/pim/trac/wiki/yang, focuses on producing PIM and IGMP/MLD YANG data models. Please work with the respective contributors so that the layer 2 specific data model aspects nicely fit in the overall data models. If you have interest in other related IETF work please don't hesitate to let us know. Please continue to keep us apprised of your work noted. Regards, Benoit (OPS AD) > Title: Liaison to IETF on YANG Models to enable G.fast deployments > Submission Date: 2016-05-18 > URL of the IETF Web page: https://datatracker.ietf.org/liaison/1476/ > > From: "Michael Fargano" > To: Benoit Claise ,Joel Jaeggli ,Mahesh Jethanandani ,Mehmet Ersue ,Jürgen Schönwälder , Tom Nadeau > Cc: Joel Jaeggli ,Mahesh Jethanandani ,David Sinicrope ,Jürgen Schönwälder ,Kent Watsen ,Mehmet Ersue ,NETCONF Data Modeling Language Discussion List ,The IETF Chair ,Lou Berger ,Benoit Claise ,Network Configuration Discussion List , > Response Contacts: > Technical Contacts: > Purpose: For information > > Body: The Broadband Forum is developing YANG models to meet the end 2016/early 2017 > G.fast deployment timeline announced by several service providers. Broadband Forum > practice is to base its YANG work on existing IETF YANG models and expertise. > > In the Broadband Forum meeting of 18-22 April, the Fiber to the Distribution Point (FTTdp) > Work Area agreed to work on developing YANG models based on draft-entitydt-netmodentity > & draft-wilton-netmod-intf-ext-yang for G.fast deployments meeting the above > timelines. Given our interest in these drafts, participants will work within the IETF > according to IETF processes, to help progress them. Please keep us apprised of progress > of these drafts. > > Further, we would like to inform you that our FTTdp Work Area is defining YANG models > for Broadband Forum specific context and use cases for : > > - forwarding/QoS and required protocols (e.g. layer 2 multicast model & DHCP) > - bulk data collection (evaluating draft-ietf-netconf-yang-push and related work), > - software image management, > - operational states (evaluating draft-ietf-netmod-opstate-reqs and related work) > > Once the models reach a level of maturity we plan to share these with IETF for review and > comment. Comments from IETF may be made via a liaison or BBF members may > comment directly. > > Please see below for information on our next meetings. > > Sincerely, > Michael Fargano, > Broadband Forum Technical Committee Chair > Attachments: > > Liaison to IETF on YANG Models to enable G.fast deployments > https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-05-18-broadband-forum-ops-netconf-netmod-liaison-to-ietf-on-yang-models-to-enable-gfast-deployments-attachment-1.pdf > > . > From nobody Mon Jun 20 07:14:31 2016 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 B08211288B8 for ; Mon, 20 Jun 2016 07:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 zvRztU3-gFiP for ; Mon, 20 Jun 2016 07:14:27 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 F03ED127058 for ; Mon, 20 Jun 2016 07:14:26 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 668B381FD06CB; Mon, 20 Jun 2016 14:14:24 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u5KEEPBj012220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Jun 2016 14:14:25 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u5KEENYT000687 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Jun 2016 14:14:25 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Mon, 20 Jun 2016 10:13:59 -0400 From: "Sterne, Jason (Nokia - CA)" To: Xiang Li , "'t.petch'" , "netconf@ietf.org" Thread-Topic: [Netconf] Is a 'replace' operation on the candidate datastore always the same as 'remove' + 'merge' ? Thread-Index: AQHRyKxgMhQMARZrw0CAohXUTf+4j5/t71xAgACJPYCAA/FQsA== Date: Mon, 20 Jun 2016 14:13:59 +0000 Message-ID: References: <008601d1c8ab$20cfb0e0$4001a8c0@gateway.2wire.net> <01d901d1c8ac$5a381510$0ea83f30$@seguesoft.com> <000b01d1c8e3$73723150$5a5693f0$@seguesoft.com> In-Reply-To: <000b01d1c8e3$73723150$5a5693f0$@seguesoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Is a 'replace' operation on the candidate datastore always the same as 'remove' + 'merge' ? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 14:14:30 -0000 OK - thanks. So I think you and I are in sync now on the behavior of 'repl= ace'. So the question is still open to the group -> does anyone know of cases whe= re a 'replace' in a candidate config doesn't have the same result as a 'rem= ove' + 'merge' ? Regards, Jason=20 -----Original Message----- From: Xiang Li [mailto:xiangli@seguesoft.com]=20 Sent: Friday, June 17, 2016 17:59 To: Sterne, Jason (Nokia - CA); 't.petch'; netconf@ietf.org Subject: RE: [Netconf] Is a 'replace' operation on the candidate datastore = always the same as 'remove' + 'merge' ? Hi > -----Original Message----- > From: Sterne, Jason (Nokia - CA) [mailto:jason.sterne@nokia.com] > Sent: Friday, June 17, 2016 1:01 PM > To: Xiang Li ; 't.petch' ;=20 > netconf@ietf.org > Subject: RE: [Netconf] Is a 'replace' operation on the candidate=20 > datastore always the same as 'remove' + 'merge' ? >=20 > Hi Xiang Li, >=20 > I was referencing the ietf interfaces model. is a container= . I'm > pretty sure that a replace operation at a container node removes all=20 > descendants of that container and replaces them with the data provided. Ok...I misread the place where the "replace" attribute appears. >=20 > If my request was this instead then only eth0 would be affected: > > > > eth0 > interface number 1 > > >=20 Ok > What if my original datastore contained the following: >=20 > > > eth0 > interface number 9999999 > enabled > > >=20 > and then I did the following : >=20 > > > eth0 > interface number 1 > > >=20 > would the resulting datastore have the link-up-down-trap-enable leaf=20 > or not ? No Regards -Xiang > -----Original Message----- > From: Sterne, Jason (Nokia - CA) [mailto:jason.sterne@nokia.com] > Sent: Friday, June 17, 2016 1:01 PM > To: Xiang Li ; 't.petch' ;=20 > netconf@ietf.org > Subject: RE: [Netconf] Is a 'replace' operation on the candidate=20 > datastore always the same as 'remove' + 'merge' ? >=20 > Hi Xiang Li, >=20 > I was referencing the ietf interfaces model. is a container= . I'm > pretty sure that a replace operation at a container node removes all=20 > descendants of that container and replaces them with the data provided. >=20 > I didn't show the full but for clarity here it is: >=20 > > > > > > > > > > eth0 > interface number 1 > > > > > > ]]>]]> >=20 > If my request was this instead then only eth0 would be affected: > > > > eth0 > interface number 1 > > >=20 > What if my original datastore contained the following: >=20 > > > eth0 > interface number 9999999 > enabled > > >=20 > and then I did the following : >=20 > > > eth0 > interface number 1 > > >=20 > would the resulting datastore have the link-up-down-trap-enable leaf=20 > or not ? > The link-up-down-trap-enable was not in the parameter so by your > definition it isn't affected. But I think the result is this: >=20 > > > eth0 > interface number 1 > > >=20 > Regards, > Jason >=20 > -----Original Message----- > From: Xiang Li [mailto:xiangli@seguesoft.com] > Sent: Friday, June 17, 2016 11:25 > To: Sterne, Jason (Nokia - CA); 't.petch'; netconf@ietf.org > Subject: RE: [Netconf] Is a 'replace' operation on the candidate=20 > datastore always the same as 'remove' + 'merge' ? >=20 > I think even woth "remove", these two examples are not equivalent at=20 > all, > specifically: >=20 > >=20 > Would remove everything under the container interfaces. >=20 > For 'replace' in , only the configuration actually=20 > present in the > parameter is affected. >=20 > Thus if you send the following request( assuming leat name is list key): > > > eth0 > interface number 1 > > >=20 >=20 > and If the existing instance data in the server is: >=20 > > > eth0 > interface number 9999999 > > > eth1 > interface number 2 > >=20 > >=20 > Then after replacing, it would become >=20 > > > eth0 > interface number 1 > > > > eth1 > interface number 2 > >=20 > Note the data on the server > > eth1 > interface number 2 > >=20 > Would never be removed for this edit-config. >=20 > -Xiang >=20 > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Sterne,=20 > > Jason (Nokia - CA) > > Sent: Friday, June 17, 2016 10:21 AM > > To: t.petch ; netconf@ietf.org > > Subject: Re: [Netconf] Is a 'replace' operation on the candidate=20 > > datastore always the same as 'remove' + 'merge' ? > > > > Sorry - I realize I really meant to ask if it is the same as 'remove' > > + > 'merge'. > > Renaming the subject and reforming the example: > > > > i.e. is 'replace' (in a candidate config) simply the "one-step" > > equivalent of doing a 'remove and then a 'merge' with: > > . identical data in the 'replace' and 'merge' > > . the 'replace' and 'remove' operation on the same node in the > > requests ? > > > > # Replace: > > > > > > > > eth0 > > interface number 1 > > > > > > > > # Equivalent remove + merge (in two separate requests): > > > > > > > > <--operation not really necessary here > > > > eth0 > > interface number 1 > > > > > > > > Jason > > > > -----Original Message----- > > From: t.petch [mailto:ietfc@btconnect.com] > > Sent: Friday, June 17, 2016 11:11 > > To: Sterne, Jason (Nokia - CA); netconf@ietf.org > > Subject: Re: [Netconf] Is a 'replace' operation on the candidate=20 > > datastore always the same as 'delete' + 'merge' ? > > > > ---- Original Message ----- > > From: "Sterne, Jason (Nokia - CA)" > > To: > > Sent: Friday, June 17, 2016 2:41 PM > > > > Hi all, > > > > I buried this question in another thread and it had some initial > discussion but > > we never really clarified it. I mostly want to ignore the running=20 > > DS for > this > > specific question and just focus on the candidate. > > > > Is a 'replace' operation on the candidate datastore always the same=20 > > as 'delete' + 'merge' in all cases ? Are there any corner cases=20 > > where the > result > > is not the same (e.g. replace at the top levels, empty values, NACM, > > etc) > ? > > > > i.e. is 'replace' (in a candidate config) simply the "one-step" > > equivalent of doing a 'delete' and then a 'merge' with: > > . identical data in the 'replace' and 'merge' > > . the 'replace' and 'delete' operation on the same node in the > > requests ? > > > > > > Simplistically no; delete requires the node to exist else it errors,=20 > > while > replace > > will accept a non-existent node and create it. > > > > Tom Petch > > > > > > # Replace: > > > > > > > > eth0 > > interface number 1 > > > > > > > > # Equivalent delete + merge (in two separate requests): > > > > > > > > <--operation not really necessary here > > > > eth0 > > interface number 1 > > > > > > > > Regards, > > Jason > > > > > > > > > > -------------------------------------------------------------------- > > -- > > -- > > -------- > > > > > > > _______________________________________________ > > > 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 Mon Jun 20 12:47:09 2016 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 13F5D12D749 for ; Mon, 20 Jun 2016 12:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 lU6_bJXhLZnt for ; Mon, 20 Jun 2016 12:47:07 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (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 28F9612D747 for ; Mon, 20 Jun 2016 12:47:07 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-02v.sys.comcast.net with SMTP id F595bs8MKQRyhF5A2buLeg; Mon, 20 Jun 2016 19:47:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466452026; bh=kMdiGtE9vtrjTXuPeTrU1848d9CRLaCjAqmqweczcK4=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=lH5lJigGf99Wgp2IDl9Ufb+ApFQNLknbT7vA1CAwqSQ1MAx7HbjR+3m/ylO6ygO5e uuCNt8cO14kHYaeAdiTLoZownW1EjMcstueNV0G+d7GXkUyPUTZsfKKNbfNOsBrrh1 QYft8Az9ypxEDfY47Uz4qDABofvrSVdNjGWLGKopUsZYfC/9avxjAoG4x2FVfG6tSp Kdfpm1i5xqGu4yflR6NSObpc2kFLDtaerbiQNm6SE1BNHuZVVHwvIBAg5sqz/0xymL lgjYV+wYh0G5S0WFmsRWLZnQ9cqfhM2XNfYtmj8hI8SuuRIn4Vsr+FgX/AYjSrsC4e 2rvAPRZS8UmZw== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-12v.sys.comcast.net with comcast id 97n51t00K1nMCLR017n5Mp; Mon, 20 Jun 2016 19:47:06 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5KJl4wY031776; Mon, 20 Jun 2016 15:47:04 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5KJl45F031773; Mon, 20 Jun 2016 15:47:04 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Andy Bierman In-Reply-To: (andy@yumaworks.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 20 Jun 2016 15:47:04 -0400 Message-ID: <87wpljprrb.fsf@hobgoblin.ariadne.com> Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] FW: [netmod] The Restconf root X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 19:47:08 -0000 Andy Bierman writes: > So why is this a problem? > Run the server on [another] port if you want 2 of them. True, but what if you want to run an arbitrary number of them? That is, if the Restconf instances don't correspond to "devices" that have distinct network addresses. Say the Restconf server is the front-end for a large number of devices which are accessed using a non-IP protocol. Dale From nobody Mon Jun 20 13:25:40 2016 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 3298912DA0B for ; Mon, 20 Jun 2016 13:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 3sKuod6soQA9 for ; Mon, 20 Jun 2016 13:25:35 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 0D6A312DA06 for ; Mon, 20 Jun 2016 13:25:35 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id j2so210570140vkg.2 for ; Mon, 20 Jun 2016 13:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=n1oCWxF5XtupVqVlqbx8gSK0B/E0SibHr2cbjSg9i8A=; b=FVoj1zibgldcKn0Oab1JctrlWxpdviNCSkGiy37YJx/hlbjUzhXMt4PtZOJoeXDYCu QzwPP3E5TiMTcM9OSp37+ZZLEvpgWXRm9otuzP3uocFtxX5GEL7dPhAh0WT1QXO/gXZD TFMtROrJWym6WfcgtKtw6DZZSGae+80AwceX70WLVDZo2Mg+lesHZ0TdLwjcXt1oyrNt k2/kcbb/X3s9UoEVKeGN1n1MT3ClF0uELFX+OJvtB2v/WNCQeg/90M3Hrr7VicGTwVnX 9qi+TzxZ0TexBhG1CMNlGw6RHyrEFi4DpgzJH7BRYtJR23KrfHtWTfzOdcoN5r/jvWeF 7Nyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=n1oCWxF5XtupVqVlqbx8gSK0B/E0SibHr2cbjSg9i8A=; b=kgFGzogFVszX5+tIB9Hyll3XiWNZcUpIvLslsyd9OzKmmUa0r5Z3oXSjkm8Nm8Gfpt YRccTjTALYxlCd1EqL5ftm9KSI3akTxNeKJwuj7DTV21m4dcMlNhw9i4RvJhfN8F+BOT ccJS6cJ9Z867Q2zn9wwLJc4HzbnNVl390xAT6PZLkXSEmTW9p3qMx9h1Y52TQ8UpWsI5 Tis2wNEeD3wFWKgTwyA4V9wYh1/p8/14A+6jZzAGGQVn8aWW3T7df8kQVRrd/jcNzIlB JcytZ6J97TRpRdHIU9kDQLI7ys0zBOy8TIBYM4kkgc3R2yibvTL7x1wBDHLWQ8God/TB r/Xw== X-Gm-Message-State: ALyK8tKq+SZSL3J7gXu4ecwQS0Fc9qYYKzp637dq03syakCwZeIMnEfCAGKa0UJ59EJbrlTXBxzjTkTAzCmlGw== MIME-Version: 1.0 X-Received: by 10.31.132.77 with SMTP id g74mr8138260vkd.121.1466454334142; Mon, 20 Jun 2016 13:25:34 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Mon, 20 Jun 2016 13:25:33 -0700 (PDT) In-Reply-To: <87wpljprrb.fsf@hobgoblin.ariadne.com> References: <87wpljprrb.fsf@hobgoblin.ariadne.com> Date: Mon, 20 Jun 2016 13:25:33 -0700 Message-ID: From: Andy Bierman To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a1144f9d8aaab070535bb8129 Archived-At: Cc: Netconf Subject: Re: [Netconf] FW: [netmod] The Restconf root X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 20:25:39 -0000 --001a1144f9d8aaab070535bb8129 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 20, 2016 at 12:47 PM, Dale R. Worley wrote: > Andy Bierman writes: > > So why is this a problem? > > Run the server on [another] port if you want 2 of them. > > True, but what if you want to run an arbitrary number of them? That is, > if the Restconf instances don't correspond to "devices" that have > distinct network addresses. Say the Restconf server is the front-end > for a large number of devices which are accessed using a non-IP > protocol. > This is not supported. I suppose you could write a draft proposing standard support for non-IP protocols. > > Dale > Andy --001a1144f9d8aaab070535bb8129 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 20, 2016 at 12:47 PM, Dale R. Worley <= worley@ariadne.com<= /a>> wrote:
Andy Bierman <andy@yumaworks.com> writes:
> So why is this a problem?
> Run the server on [another] port if you want 2 of them.

True, but what if you want to run an arbitrary number of them?=C2=A0 That i= s,
if the Restconf instances don't correspond to "devices" that = have
distinct network addresses.=C2=A0 Say the Restconf server is the front-end<= br> for a large number of devices which are accessed using a non-IP
protocol.

This is not supported.
<= div>I suppose you could write a draft proposing standard support for non-IP= protocols.

=C2=A0

Dale

Andy
=C2= =A0

--001a1144f9d8aaab070535bb8129-- From nobody Mon Jun 20 17:11:31 2016 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 7B86912DAB2 for ; Mon, 20 Jun 2016 17:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 d31-fhYxaWMg for ; Mon, 20 Jun 2016 17:11:28 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 C3A4E12D7C9 for ; Mon, 20 Jun 2016 17:11:27 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id j2so423941vkg.2 for ; Mon, 20 Jun 2016 17:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=OMrcvu5g3igDpoFNI+YbRtssctZ2Qx+Os9E95gJz6iQ=; b=ojwPnbme+u36rfJnGdh9j9jqWO3jLkyT44ElcPs79utpyqckukQFG4VMeOW87O1S+R G1Ixuc7E6FFcsjRzvdeiyTNPyRcoU5jck3rdtXNwlROTfuxQYUINklSIXEm4I+IuqIKn YB5kpSNwysg1jdNdbN69HmqteqNG4ro0sW8uJbev1CGqfY2eZMQODp9iFSbo6VzFhjiH tZyaqAkTLrImRQKOG5FBw6IIQw+3ZGU4Z/lADOa9O7VMAxJonrtVWyhfPhYV4XsLrh9p Uco20otPEBqq+Tj+2IfSVoSksGXMOOgTuWpCo8LWtmIkqPkRDFc9TqxCiuqywDDba+9P P06g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=OMrcvu5g3igDpoFNI+YbRtssctZ2Qx+Os9E95gJz6iQ=; b=hV1BOClFhXYNI/81LZSmLCJJUirIASKpSNfvRgNMB9HgwpxUU93uvGBgYbzq/Odt5W wJ1T7iSElLNYwd8seB6von8ChwOXNGvLbw473OmrO5ABp7c9kpekdVtHLNgyaTFPweI8 IPp6XB+HV3iswZXu9PWsd+cbAPYdPpT8pmtmZJ1gop7JqMShOZpfJiPNLvhNWrf8xGoc vAoj43ZLVYgGbEoLDnKau51VU/4RtbbmwHiMaVObHAlwk80RfvsFdl+Jt+HmcQxWUGE9 nG3+QqjdbbkXooTmbvwsZkS8g2iD6isdOUlAb5jzcv/Tq2bABzUBfq6yYEoW/PmW0lEt 2+Yg== X-Gm-Message-State: ALyK8tLrX0TLowg49GA6BbXAjW1cC1NV2rE64rcvzp+YnIxbk9mqeHnzozf4zCLVTMVHJOxqgxnzpWDbPnJsLA== MIME-Version: 1.0 X-Received: by 10.176.67.37 with SMTP id k34mr1367901uak.47.1466467886695; Mon, 20 Jun 2016 17:11:26 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Mon, 20 Jun 2016 17:11:26 -0700 (PDT) Date: Mon, 20 Jun 2016 17:11:26 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=94eb2c05a69a76212b0535bea9e2 Archived-At: Subject: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 00:11:29 -0000 --94eb2c05a69a76212b0535bea9e2 Content-Type: text/plain; charset=UTF-8 Hi, The media type definitions in RESTCONF-13 are incorrect. We cannot make subtypes for application/yang. Each RESTCONF (and YANG Patch) media type has to be registered. Approach 1) hard-wired types RESTCONF would register 10 media types and YANG Patch 4 media types if we use the hardwired approach. application/yang-api+xml application/yang-api+json application/yang-datastore+xml application/yang-datastore+json application/yang-data+xml application/yang-data+json application/yang-errors+xml application/yang-errors+json application/yang-operation+xml application/yang-operations+json application/yang-patch+xml application/yang-patch+json application/yang-patch-status+xml application/yang-patch-status+json Any new media types would need to be registered. No usage of the restconf-media-type is possible besides this list of media types for RESTCONF and YANG Patch without additional registrations. Approach 2) generic types with a parameter A parameter approach would allow YANG to be used to define any message content schema. E.g., a mandatory "type" parameter that specifies the module and name of the restconf-media-type. Only 2 media type need to be registered for every media-type that could ever be specified (SDO or vendor) application/yang-data-xml;type=: application/yang-data-json;type=: application/yang-data-xml;type=ietf-restconf:api application/yang-data-json;type=ietf-restconf:api application/yang-data-xml;type=ietf-restconf:datastore application/yang-data-json;type=ietf-restconf:datastore application/yang-data-xml;type=ietf-restconf:data application/yang-data-json;type=ietf-restconf:data application/yang-data-xml;type=ietf-restconf:errors application/yang-data-json;type=ietf-restconf:errors application/yang-data-xml;type=ietf-restconf:operation application/yang-data-json;type=ietf-restconf:operation application/yang-data-xml;type=ietf-yang-patch:yang-patch application/yang-data-json;type=ietf-yang-patch:yang-patch application/yang-data-xml;type=ietf-yang-patch:yang-patch-status application/yang-data-json;type=ietf-yang-patch:yang-patch-status If you have a preference how this issue is resolved, send comments. Andy --94eb2c05a69a76212b0535bea9e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The media type definitions in RESTC= ONF-13 are incorrect.
We cannot make subtypes for application/yang.=
Each RESTCONF (and YANG Patch) media type has
to be re= gistered.


Approach 1) hard-wired ty= pes


RESTCONF would register 10 media types and YANG= Patch 4 media types
if we use the har= dwired approach.

=C2=A0 =C2=A0application/yang-api+xml
=C2=A0 =C2=A0application/yang-api+json
=C2=A0 =C2=A0application/yang-datastore+xml
=C2=A0 = =C2=A0application/yang-datastore+json
=C2=A0 =C2=A0application/yang-da= ta+xml
=C2=A0 =C2=A0application/yang-data+json
=C2=A0 =C2=A0application/yang-errors+xml
=C2=A0 =C2=A0appl= ication/yang-errors+json
=C2=A0 =C2=A0application/yang-operation+xml
=C2=A0 =C2=A0application/ya= ng-operations+json
=C2=A0 =C2=A0application/yang-patch+xml
=C2=A0 =C2=A0application/yang-patch+json
=C2=A0 =C2=A0application/yang-patch-sta= tus+xml
=C2=A0 =C2=A0application/yang-patch-status+json

Any new medi= a types would need to be registered.
N= o usage of the restconf-media-type is possible besides
this list of media types for RESTCONF and YANG Patch
=
without additional registrations.

Appro= ach 2) generic types with a parameter
=
A parameter approach would allow = YANG to be used to define any
message = content schema.=C2=A0 E.g., a mandatory "type" parameter
that specifies the module=C2=A0and name of the restconf-media-type.

Only 2 me= dia type need to be registered for every media-type
that could ever be specified (SDO or vendor)

=C2=A0 =C2=A0application/yang-data-xml;type=3D<mod= ule>:<name>
=C2=A0 =C2=A0appl= ication/yang-data-json;type=3D<module>:<name>

=C2= =A0 =C2=A0application/yang-data-xml;type=3Dietf-restconf:api
=C2=A0 =C2=A0application/yang-data-json;type=3Dietf-= restconf:api
=C2=A0 =C2=A0application/yang-data-xml;type=3Dietf-restconf:datastor= e
=C2=A0 =C2=A0application/yang-data-j= son;type=3Dietf-restconf:datastore
=C2=A0 =C2=A0application/yang-data-xml;type=3D= ietf-restconf:data
=C2=A0 =C2=A0applic= ation/yang-data-json;type=3Dietf-restconf:data
=C2=A0 =C2=A0application/yang-data-xml;type=3Dietf-restconf:e= rrors
=C2=A0 =C2=A0application/yang-da= ta-json;type=3Dietf-restconf:errors
=C2=A0 = =C2=A0application/yang-data-xml;type=3Dietf-restconf:operation
=C2=A0 =C2=A0application/yang-data-json;type=3Diet= f-restconf:operation
=C2=A0 =C2=A0application/yang-data-xml;type=3Dietf-yang-patc= h:yang-patch
=C2=A0 =C2=A0application/yang-data-json;type=3Dietf-yang-patch:yang-patch
=C2=A0 =C2=A0applica= tion/yang-data-xml;type=3Dietf-yang= -patch:yang-patch-status
=C2=A0 =C2=A0application/yang-data-json;<= span style=3D"font-size:12.8px">type=3Dietf-yang-patch:yang-patch-status
=C2=A0 =C2=A0

<= /div>
If you have a preference how thi= s issue is resolved, send comments.


Andy


<= /div>


<= /div>
--94eb2c05a69a76212b0535bea9e2-- From nobody Tue Jun 21 00:39:21 2016 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 DF6D212D828 for ; Tue, 21 Jun 2016 00:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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, RP_MATCHES_RCVD=-1.426] 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 OiW4RDcDx2kP for ; Tue, 21 Jun 2016 00:39:18 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90B7F12D0DC for ; Tue, 21 Jun 2016 00:39:18 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:1d26:3c9:e0f4:a092] (unknown [IPv6:2001:718:1a02:1:1d26:3c9:e0f4:a092]) by mail.nic.cz (Postfix) with ESMTPSA id 349AA617DE; Tue, 21 Jun 2016 09:39:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1466494757; bh=2EA0UFZFbFgf88HCTNclO+kYWQtAsO9Z1l+eJbk47KA=; h=From:Date:To; b=Z75jwmvx4/djNwwAdh8AP6gtITuPXMsW2rqkUkPc6HgcUV0AxvpU8aoUr9zyjSYuk +gOBqR4Mmdu4j5zTevjXdFux4OtxlmOvihQfA9BYX9UyuW1MFrxxZy5vGV62khoPxv 7msM/VZtm9E/pjhohNDmCejb0Fj5PDCnkyuK+XKc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 21 Jun 2016 09:39:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5F59F1E8-62E8-4AE9-9E51-DB4E506C3C80@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 07:39:21 -0000 > On 21 Jun 2016, at 02:11, Andy Bierman wrote: >=20 > Hi, >=20 > The media type definitions in RESTCONF-13 are incorrect. > We cannot make subtypes for application/yang. > Each RESTCONF (and YANG Patch) media type has > to be registered. >=20 >=20 > Approach 1) hard-wired types >=20 >=20 > RESTCONF would register 10 media types and YANG Patch 4 media types > if we use the hardwired approach. >=20 > application/yang-api+xml > application/yang-api+json > application/yang-datastore+xml > application/yang-datastore+json > application/yang-data+xml > application/yang-data+json > application/yang-errors+xml > application/yang-errors+json > application/yang-operation+xml > application/yang-operations+json > application/yang-patch+xml > application/yang-patch+json > application/yang-patch-status+xml > application/yang-patch-status+json >=20 > Any new media types would need to be registered. > No usage of the restconf-media-type is possible besides > this list of media types for RESTCONF and YANG Patch > without additional registrations. >=20 > Approach 2) generic types with a parameter >=20 > A parameter approach would allow YANG to be used to define any > message content schema. E.g., a mandatory "type" parameter > that specifies the module and name of the restconf-media-type. >=20 > Only 2 media type need to be registered for every media-type > that could ever be specified (SDO or vendor) >=20 > application/yang-data-xml;type=3D: > application/yang-data-json;type=3D: >=20 > application/yang-data-xml;type=3Dietf-restconf:api > application/yang-data-json;type=3Dietf-restconf:api > application/yang-data-xml;type=3Dietf-restconf:datastore > application/yang-data-json;type=3Dietf-restconf:datastore > application/yang-data-xml;type=3Dietf-restconf:data > application/yang-data-json;type=3Dietf-restconf:data > application/yang-data-xml;type=3Dietf-restconf:errors > application/yang-data-json;type=3Dietf-restconf:errors > application/yang-data-xml;type=3Dietf-restconf:operation > application/yang-data-json;type=3Dietf-restconf:operation > application/yang-data-xml;type=3Dietf-yang-patch:yang-patch > application/yang-data-json;type=3Dietf-yang-patch:yang-patch > application/yang-data-xml;type=3Dietf-yang-patch:yang-patch-status > application/yang-data-json;type=3Dietf-yang-patch:yang-patch-status > =20 >=20 > If you have a preference how this issue is resolved, send comments. I prefer #1, as media types aren't supposed to carry schema information = (and we do have it elsewhere). One thing to consider though is to reduce = the number of media types. For example, it's IMO not necessary to have = separate media types "application/yang-data" and = "application/yang-operation" because they can be easily discriminated = via the URI. Lada >=20 >=20 >=20 > Andy >=20 >=20 >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jun 21 01:08:25 2016 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 B0E4F12D922 for ; Tue, 21 Jun 2016 01:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 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, RP_MATCHES_RCVD=-1.426] 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 cpQ9BWdABr55 for ; Tue, 21 Jun 2016 01:08:22 -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 B7DF312D094 for ; Tue, 21 Jun 2016 01:08:21 -0700 (PDT) Received: from [10.137.1.13] (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id 0D9DB244CD3 for ; Tue, 21 Jun 2016 10:08:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1466496500; bh=RALjqQMnOWP01deGehDGdacZifAMj4QzAaIyTTaYeDU=; h=From:Subject:To:Date; b=En5/u0YprxFrRSu007Wnv5OA2nVWEGxzjqKAknNhGr0QZpTJ8U9dCgJf5iGlx1VZj 6yHDkPEUFOGoDllwpZAHUDrsbNgLbN8Odx/tX/lAzOxZHgykejY7dIVaFdlbsjaelK gu3Qt/jRRUQRAz+7elKALg9my2JfAr4qq94cDSVQ= From: Robert Varga To: netconf@ietf.org Message-ID: <7a655427-0625-744a-1e5e-7e07aea4e11c@hq.sk> Date: Tue, 21 Jun 2016 10:08:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1VLGeDChLL2QFJRMUiMdaJDkBC988qmjv" Archived-At: Subject: [Netconf] RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 08:08:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1VLGeDChLL2QFJRMUiMdaJDkBC988qmjv Content-Type: multipart/mixed; boundary="xA3iDCh2MU0HTqdvTKgO4sTlC52NbeNkC" From: Robert Varga To: netconf@ietf.org Message-ID: <7a655427-0625-744a-1e5e-7e07aea4e11c@hq.sk> Subject: RESTCONF content=all on conflicts? --xA3iDCh2MU0HTqdvTKgO4sTlC52NbeNkC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, Reading through section 4.8.1 and D.3.1, it seems that in case of content=3Dall there is no guidance what the server should do if it encounters a leaf which has different values in config and oper. Would this constitute an error, or should one of them take precedence? Thanks, Robert --xA3iDCh2MU0HTqdvTKgO4sTlC52NbeNkC-- --1VLGeDChLL2QFJRMUiMdaJDkBC988qmjv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXaPXzAAoJECsDwSqgzwDT6csP/2j6Qg8BuWK+1M0KHqctG+Cx zM7+r7kGbpicAIFjLBFSrtyOotFUrF9Abbc89FCeS7QeIdSwyLARTUeMXGb/wK5/ 6/HGbsSRvvbF50yFRWOUCAhvjBA8DFgePuS/JzIci2yluIpe8Vr3AGCZ9dxjBeWt HoSO/kHz+vVYPPxoxx7Vm9gqJ4xI1IM6EM+nEsMv2w6MQbd+zRYR/CvkuGdjH3Qh 6yxpHYj6mxVUUccR7CG8cI7VkQ/naUleVWuVtgj3bGyisVpR9NfnZNtXms0QEulG 29TcoWp2V1Bc1NXHtO4bLA0wUNLS0CdtL8ykHTX9nGzshoWB799ttkGrzX8nXngn e3VFHhkEpB7K/se9V+UNIigYtXJmzEFPc3PmPC9dq+b7cFdglR9mAPWX11bueuSD 2aTiXKajojVDZ33evoQ+Aqsx97fiuV+/ZzI0pvdnQYGfSKLwswozNpbgu3uatQzD WCL1bZW/QDANF1FURosW/5BbYEP48a+OuCqwUP4VI2NF771pXuXG9/RivPOKAGCz 7qo3MY65BKUzXOxO4bdBqj2pOjS8p5KasCwmLEle+E4BWpZfrXaicWH44lgK2ZGJ +onpe1YBklMy8XA/tpXZmsgy1UY7JvGmecfSJ4Lr8KUje0Ftc3ihxWSZuGqanaoy p0DIzMNHbGXKHq47NM0g =eZbQ -----END PGP SIGNATURE----- --1VLGeDChLL2QFJRMUiMdaJDkBC988qmjv-- From nobody Tue Jun 21 01:43:23 2016 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 AE90F12D18B for ; Tue, 21 Jun 2016 01:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 wN4KXj6FyG0f for ; Tue, 21 Jun 2016 01:43:20 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6A65D12D0E6 for ; Tue, 21 Jun 2016 01:43:20 -0700 (PDT) Received: from localhost (unknown [173.38.220.44]) by mail.tail-f.com (Postfix) with ESMTPSA id 4E1821AE0198; Tue, 21 Jun 2016 10:43:19 +0200 (CEST) Date: Tue, 21 Jun 2016 10:43:43 +0200 (CEST) Message-Id: <20160621.104343.179630048330976700.mbj@tail-f.com> To: nite@hq.sk From: Martin Bjorklund In-Reply-To: <7a655427-0625-744a-1e5e-7e07aea4e11c@hq.sk> References: <7a655427-0625-744a-1e5e-7e07aea4e11c@hq.sk> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 08:43:22 -0000 Robert Varga wrote: > Hello, > > Reading through section 4.8.1 and D.3.1, it seems that in case of > content=all there is no guidance what the server should do if it > encounters a leaf which has different values in config and oper. Note that the 'data' resource contains "the combined configuration and state data". This has the same problem as NETCONF . If we introduce separate datastores for intended, applied, operational-state as proposed in draft-schoenw-netmod-revised-datastores (which I think your question sort of implies), we will need to update this model both in NETCONF and RESTCONF. draft-schoenw-netmod-revised-datastores suggests how this can be done. The WG should be aware of this though. If we introduce the separare datastores (which I think we should do), NETCONF won't work properly, and plain RESTCONF GET w/o additional query parameters would also not work properly, just as you indicate. Maybe we can solve this by saying that one of them takes precedence. /martin From nobody Tue Jun 21 02:13:19 2016 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 5F40A12D0B8 for ; Tue, 21 Jun 2016 02:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 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, RP_MATCHES_RCVD=-1.426] 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 ciMErGcWDWJF for ; Tue, 21 Jun 2016 02:13:17 -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 503CD12D099 for ; Tue, 21 Jun 2016 02:13:17 -0700 (PDT) Received: from [10.137.1.13] (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id ACF55244CD2; Tue, 21 Jun 2016 11:13:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1466500393; bh=WsEZtnznOJDuDap8gR8wuz006nMb88Dst70mxOZblWc=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=DRq0+Io+bYDdoqVVg5aqNHqXsYyWTuCoVK2CEz2JRPUFswn06GqhVnxt8VzeXzUZI ry1gsdb/dZcyyQxLu8YVaxAbXErv+PmeQJos21o7Aec6ls7WGetOEmvYBYGGBOZFTU w7daWR1RVGWEnv5LdN4k6rlhQPuEAuOobMAfP6lk= To: Martin Bjorklund References: <7a655427-0625-744a-1e5e-7e07aea4e11c@hq.sk> <20160621.104343.179630048330976700.mbj@tail-f.com> From: Robert Varga Message-ID: <061501d9-33ce-691f-dd40-0341405b67e3@hq.sk> Date: Tue, 21 Jun 2016 11:13:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160621.104343.179630048330976700.mbj@tail-f.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JO1H0i96a3X0ANrF2CgQHE4CX3dcVjoOn" Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 09:13:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JO1H0i96a3X0ANrF2CgQHE4CX3dcVjoOn Content-Type: multipart/mixed; boundary="nlFJnjtaxsAt2bfSjPFroPAkIpOnLarDW" From: Robert Varga To: Martin Bjorklund Cc: netconf@ietf.org Message-ID: <061501d9-33ce-691f-dd40-0341405b67e3@hq.sk> Subject: Re: [Netconf] RESTCONF content=all on conflicts? References: <7a655427-0625-744a-1e5e-7e07aea4e11c@hq.sk> <20160621.104343.179630048330976700.mbj@tail-f.com> In-Reply-To: <20160621.104343.179630048330976700.mbj@tail-f.com> --nlFJnjtaxsAt2bfSjPFroPAkIpOnLarDW Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 06/21/2016 10:43 AM, Martin Bjorklund wrote: > If we > introduce separate datastores for intended, applied, operational-state > as proposed in draft-schoenw-netmod-revised-datastores (which I think > your question sort of implies), we will need to update this model both > in NETCONF and RESTCONF. draft-schoenw-netmod-revised-datastores > suggests how this can be done. Right, sorry about silent implication, this comes from ODL implementation, which has an in-between architecture with separate config and oper stores, but without running/intended/applied separation. Thanks for the pointer. Bye, Robert --nlFJnjtaxsAt2bfSjPFroPAkIpOnLarDW-- --JO1H0i96a3X0ANrF2CgQHE4CX3dcVjoOn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXaQUiAAoJECsDwSqgzwDTYD8QALSH2Ls1zykZtd59KGsmfwT3 Fz42dScIBF8uPy1VtyedjPekhuCnwH+BFG69ArXa2AH3dIf/WMNi2DT34Qw8i/36 jS4BxFNlVOchR2YxaYtno0UINuzbQo997VfduvbkRrC+GhLsbq9Zl6xSxJZqwtNR KKwu8Q14PVIQWJBoyZFK3dyo0dpfODg0i0WApydr/7m4xC8tgzgEyymyckaeTSnx HkWLyDOU3PQlat98jTo+sQlfWJw5aGcTlMynG4eEqfaaOZ8AnyNuXcmJ5NQiiiUC knq8ZA7VFqd7tEZrkx7CQe7UFw6rIQuOMJrnJnJp8Lx+12DOOiY+L63swmnYqnjp 7hlayWLdQraq3RQ0Ty5YWKvWBYLWGGGs4GsQtatT+KzpgIV+TEY76ahsBlH5CWe5 s2MCE9s1bYSO655JIOAwgweOtJe9IE3FVumTOSybxmFs+P7VDuGJFVfm6EFWtFYt 1/YWZ4zGsqmxbWx898QUWLgUj6OEwk9iJttewDmkxaeLn6LFjJzOxuWG18fOontw UGpczim8Nw84nllmOWdcjOI3fBWntalYE8DkVYrMzTwVw9TxGI6eXFsv7lxUUobM ZK+khJVy23/KaMomi4wSUCSLSN/A6zXfk8SuSaiYHQyS53px8zlUvb7aE/wVvGgV OyJcsTMcLmtjAec5Q188 =P9eg -----END PGP SIGNATURE----- --JO1H0i96a3X0ANrF2CgQHE4CX3dcVjoOn-- From nobody Tue Jun 21 02:19:55 2016 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 15B5D12D0B8 for ; Tue, 21 Jun 2016 02:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 19MuAxYW2hA9 for ; Tue, 21 Jun 2016 02:19:53 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F3AC41200A0 for ; Tue, 21 Jun 2016 02:19:52 -0700 (PDT) Received: from localhost (unknown [173.38.220.44]) by mail.tail-f.com (Postfix) with ESMTPSA id 48B6E1AE0198; Tue, 21 Jun 2016 11:19:51 +0200 (CEST) Date: Tue, 21 Jun 2016 11:20:15 +0200 (CEST) Message-Id: <20160621.112015.1076159141397928039.mbj@tail-f.com> To: nite@hq.sk From: Martin Bjorklund In-Reply-To: <061501d9-33ce-691f-dd40-0341405b67e3@hq.sk> References: <7a655427-0625-744a-1e5e-7e07aea4e11c@hq.sk> <20160621.104343.179630048330976700.mbj@tail-f.com> <061501d9-33ce-691f-dd40-0341405b67e3@hq.sk> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF content=all on conflicts?, Re: RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 09:19:54 -0000 Robert Varga wrote: > On 06/21/2016 10:43 AM, Martin Bjorklund wrote: > > If we > > introduce separate datastores for intended, applied, operational-state > > as proposed in draft-schoenw-netmod-revised-datastores (which I think > > your question sort of implies), we will need to update this model both > > in NETCONF and RESTCONF. draft-schoenw-netmod-revised-datastores > > suggests how this can be done. > > Right, sorry about silent implication, this comes from ODL > implementation, which has an in-between architecture with separate > config and oper stores So does the schema for the oper store contain also all config true nodes? If it doesn't there's no risk for a conflict, right? How does ODL handle this case for NETCONF ? /martin From nobody Tue Jun 21 02:20:59 2016 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 A6CB512D099 for ; Tue, 21 Jun 2016 02:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 Mw_2P3NavETo for ; Tue, 21 Jun 2016 02:20:55 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17901200A0 for ; Tue, 21 Jun 2016 02:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4729; q=dns/txt; s=iport; t=1466500854; x=1467710454; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=6m7iDXrEXbUejNYbNHgbg9OJxW+gAZ01KwjLy/WBGis=; b=N4vGgi8mBPg+hYoTDInMx/xADCs9Nk+dlmd3kIWDil8tbfN9nyurfxu1 Trp4tY1WrqhE9D3T49KqB8Zl0ucJAxIghhBe9nUeQmw9Bzdor67ErLJ0b gDb35FJ7kN8VFdUft1EFMdDhGr+AP7MeXbBLX5R2n+hHYdhHKOOErqHTw o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CHAwCkBWlX/xbLJq1dhBQrUrV2hQGBe?= =?us-ascii?q?hcBCoUrSgKBahQBAQEBAQEBZSeETAEBBAEBAWsbCwQKBAYuJyIOBgEMBgIBAYg?= =?us-ascii?q?sDsEdAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGJ4F3glaEKoVxBZh5jiyJRoVdj?= =?us-ascii?q?3geNoNxOzKKSAEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,503,1459814400"; d="scan'208,217";a="635283921" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2016 09:20:52 +0000 Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u5L9Kqul021515; Tue, 21 Jun 2016 09:20:52 GMT To: Robert Varga , netconf@ietf.org References: <7a655427-0625-744a-1e5e-7e07aea4e11c@hq.sk> From: Robert Wilton Message-ID: <769525d0-205a-a57b-a173-89842a0492df@cisco.com> Date: Tue, 21 Jun 2016 10:20:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <7a655427-0625-744a-1e5e-7e07aea4e11c@hq.sk> Content-Type: multipart/alternative; boundary="------------C974FBD19D840FD3E3E82658" Archived-At: Subject: Re: [Netconf] RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 09:20:57 -0000 This is a multi-part message in MIME format. --------------C974FBD19D840FD3E3E82658 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Robert, The existing definition of the datastores as defined in NETCONF (RFC 6241) doesn't allow a config=true leaf to have a different value in config and oper. There is only one leaf with one value. As Martin has indicated, Juergen (with Martin input) has written up a revised datastore proposal as one way of splitting the configuration into the intended and applied values and defining an operational state datastore. I've also written up an alternative architecture for splitting up the datastores (based on the opstate discussions), as draft-wilton-netmod-refined-datastores. In the model that I propose, a NETCONF get-config request would return the intended configuration sent by the client, and a NETCONF get request would return the operational state (which includes the applied configuration). For servers that don't support a split between intended vs applied configuration then they can be regarded as having the same values, and hence the behaviour is identical to the NETCONF behaviour today. My proposed refinement in GET semantics for clients may not be acceptable, in which case the existing GET operation would probably need to be superseded by a new GET-0PER operation. Thanks, Rob On 21/06/2016 09:08, Robert Varga wrote: > Hello, > > Reading through section 4.8.1 and D.3.1, it seems that in case of > content=all there is no guidance what the server should do if it > encounters a leaf which has different values in config and oper. > > Would this constitute an error, or should one of them take precedence? > > Thanks, > Robert > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------C974FBD19D840FD3E3E82658 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Robert,

The existing definition of the datastores as defined in NETCONF (RFC 6241) doesn't allow a config=true leaf to have a different value in config and oper.  There is only one leaf with one value.

As Martin has indicated, Juergen (with Martin input) has written up a revised datastore proposal as one way of splitting the configuration into the intended and applied values and defining an operational state datastore.

I've also written up an alternative architecture for splitting up the datastores (based on the opstate discussions), as    
draft-wilton-netmod-refined-datastores.  In the model that I propose, a NETCONF get-config request would return the intended configuration sent by the client, and a NETCONF get request would return the operational state (which includes the applied configuration).   For servers that don't support a split between intended vs applied configuration then they can be regarded as having the same values, and hence the behaviour is identical to the NETCONF behaviour today.

My proposed refinement in GET semantics for clients may not be acceptable, in which case the existing GET operation would probably need to be superseded by a new GET-0PER operation.

Thanks,
Rob


On 21/06/2016 09:08, Robert Varga wrote:
Hello,

Reading through section 4.8.1 and  D.3.1, it seems that in case of
content=all there is no guidance what the server should do if it
encounters a leaf which has different values in config and oper.

Would this constitute an error, or should one of them take precedence?

Thanks,
Robert




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

--------------C974FBD19D840FD3E3E82658-- From nobody Tue Jun 21 02:46:38 2016 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 1D5D912B004 for ; Tue, 21 Jun 2016 02:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 E-B95tcw5Zsa for ; Tue, 21 Jun 2016 02:46:35 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049D712B026 for ; Tue, 21 Jun 2016 02:46:34 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 88AC377D; Tue, 21 Jun 2016 11:46:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 7ELG0KSFblMV; Tue, 21 Jun 2016 11:46:30 +0200 (CEST) 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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 21 Jun 2016 11:46:31 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7A5F320054; Tue, 21 Jun 2016 11:46:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LrI61LTO_Mbk; Tue, 21 Jun 2016 11:46:30 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B27F20055; Tue, 21 Jun 2016 11:46:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7A20F3B2DF66; Tue, 21 Jun 2016 11:46:28 +0200 (CEST) Date: Tue, 21 Jun 2016 11:46:28 +0200 From: Juergen Schoenwaelder To: Robert Varga Message-ID: <20160621094628.GA41804@elstar.local> Mail-Followup-To: Robert Varga , netconf@ietf.org References: <7a655427-0625-744a-1e5e-7e07aea4e11c@hq.sk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7a655427-0625-744a-1e5e-7e07aea4e11c@hq.sk> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 09:46:37 -0000 On Tue, Jun 21, 2016 at 10:08:13AM +0200, Robert Varga wrote: > Hello, > > Reading through section 4.8.1 and D.3.1, it seems that in case of > content=all there is no guidance what the server should do if it > encounters a leaf which has different values in config and oper. > > Would this constitute an error, or should one of them take precedence? > The notion of "all" may prove problematic depending on how we move forward with multiple datastore. However, I think the most pressing issue to address before RESTCONF goes to the RFC editor is to move the default of the content query parameter back to 'config' instead of 'all'. Having the content parameter default to 'all' makes it hard to possibly deprecate 'all' in the future. Note that the current RESTCONF I-D is also inconsistent: 4.8.1. The "content" Query Parameter If this query parameter is not present, the default value is "all". This query parameter MUST be supported by the server. D.3.1. "content" Parameter To retrieve only the configuration child resources, the "content" parameter is set to "config" or omitted since this is the default value. Note that the "ETag" and "Last-Modified" headers are only returned if the content parameter value is "config". /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 Jun 21 03:20:57 2016 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 59AE612B017 for ; Tue, 21 Jun 2016 03:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 FgnS2coOI7e8 for ; Tue, 21 Jun 2016 03:20:55 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB221200A0 for ; Tue, 21 Jun 2016 03:20:55 -0700 (PDT) Received: from localhost (unknown [173.38.220.44]) by mail.tail-f.com (Postfix) with ESMTPSA id 8C2501AE0198; Tue, 21 Jun 2016 12:20:53 +0200 (CEST) Date: Tue, 21 Jun 2016 12:21:17 +0200 (CEST) Message-Id: <20160621.122117.332960881532664788.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160621094628.GA41804@elstar.local> References: <7a655427-0625-744a-1e5e-7e07aea4e11c@hq.sk> <20160621094628.GA41804@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 10:20:56 -0000 Juergen Schoenwaelder wrote: > On Tue, Jun 21, 2016 at 10:08:13AM +0200, Robert Varga wrote: > > Hello, > > > > Reading through section 4.8.1 and D.3.1, it seems that in case of > > content=all there is no guidance what the server should do if it > > encounters a leaf which has different values in config and oper. > > > > Would this constitute an error, or should one of them take precedence? > > > > The notion of "all" may prove problematic depending on how we move > forward with multiple datastore. However, I think the most pressing > issue to address before RESTCONF goes to the RFC editor is to move the > default of the content query parameter back to 'config' instead of > 'all'. Having the content parameter default to 'all' makes it hard to > possibly deprecate 'all' in the future. I don't think this change would help. Suppose we introduce intended/applied/operational-state as proposed in your draft. Config true nodes would then exist in all three. So which one would be returned w/o any 'content' param (or 'content=config')? IMO the problem is that 'data' contains *combined* config and state, which doesn't really work if the same schema nodes can exist in both config and state. /martin From nobody Tue Jun 21 03:50:46 2016 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 0DE0E12D19B for ; Tue, 21 Jun 2016 03:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 gq3hhkSwON_Y for ; Tue, 21 Jun 2016 03:50:42 -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 2F64512D18B for ; Tue, 21 Jun 2016 03:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2107; q=dns/txt; s=iport; t=1466506242; x=1467715842; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=x4lZlYeTAHxhklVYpuT9iTnMtu6OeDijk+UoXc4pGms=; b=RauGHCgEASl6q0tSE2hCWLbT2mpKo3am6elh+v9kRcNV6o9IBfwDTMXH H8dbhRRTOGAe+j2RBQwM/Ec7gMaaYZ4d1kYPvIgYnTnAiomMn7CUiTmmU we6ENAuc3n+fjNKEHUgL5uZIvN+xqqt5chmMUIPW8SCgyrwPX1X/tbt61 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBAAwG2lX/xbLJq1dhBQrUrxxFwuFK?= =?us-ascii?q?0oCgX4BAQEBAQFmJ4RMAQEEAQEBNTYLEAsOAgguJzAGAQwGAgEBiCwOwSkBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEXBYYngXcIgk6EKoVxBZh5jiwCiUSFXY94VINxO?= =?us-ascii?q?zKKSAEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,503,1459814400"; d="scan'208";a="636303985" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2016 10:50:40 +0000 Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u5LAoeOp026062; Tue, 21 Jun 2016 10:50:40 GMT To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de References: <7a655427-0625-744a-1e5e-7e07aea4e11c@hq.sk> <20160621094628.GA41804@elstar.local> <20160621.122117.332960881532664788.mbj@tail-f.com> From: Robert Wilton Message-ID: <34773154-f55f-9085-35fb-13e44d5b535a@cisco.com> Date: Tue, 21 Jun 2016 11:50:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160621.122117.332960881532664788.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 10:50:44 -0000 On 21/06/2016 11:21, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Tue, Jun 21, 2016 at 10:08:13AM +0200, Robert Varga wrote: >>> Hello, >>> >>> Reading through section 4.8.1 and D.3.1, it seems that in case of >>> content=all there is no guidance what the server should do if it >>> encounters a leaf which has different values in config and oper. >>> >>> Would this constitute an error, or should one of them take precedence? >>> >> The notion of "all" may prove problematic depending on how we move >> forward with multiple datastore. However, I think the most pressing >> issue to address before RESTCONF goes to the RFC editor is to move the >> default of the content query parameter back to 'config' instead of >> 'all'. Having the content parameter default to 'all' makes it hard to >> possibly deprecate 'all' in the future. > I don't think this change would help. Suppose we introduce > intended/applied/operational-state as proposed in your draft. Config > true nodes would then exist in all three. So which one would be > returned w/o any 'content' param (or 'content=config')? > > IMO the problem is that 'data' contains *combined* config and state, > which doesn't really work if the same schema nodes can exist in both > config and state. This is one of the reasons why I prefer having only 2 datastores (i.e. intended + operational state (inc applied config)) rather than the 3 described above. The content=all operation can then return the contents of the operational state datastore which happens to include the applied configuration, and is also the same as what would be returned from a RESTCONF device today. Full clean access to the separate datastores will require datastore awareness in the REST API, but I can imagine that for a lot of simple devices a simple combined view is useful. Thanks, Rob > > > /martin > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > . > From nobody Tue Jun 21 03:59:11 2016 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 A918F12B02F for ; Tue, 21 Jun 2016 03:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 Um3U4OsBqH8T for ; Tue, 21 Jun 2016 03:59:08 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 80DCB12B01B for ; Tue, 21 Jun 2016 03:59:08 -0700 (PDT) Received: from localhost (unknown [173.38.220.44]) by mail.tail-f.com (Postfix) with ESMTPSA id 56E0D1AE0198; Tue, 21 Jun 2016 12:59:07 +0200 (CEST) Date: Tue, 21 Jun 2016 12:59:31 +0200 (CEST) Message-Id: <20160621.125931.365562743647782974.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <34773154-f55f-9085-35fb-13e44d5b535a@cisco.com> References: <20160621094628.GA41804@elstar.local> <20160621.122117.332960881532664788.mbj@tail-f.com> <34773154-f55f-9085-35fb-13e44d5b535a@cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 10:59:10 -0000 Robert Wilton wrote: > > > On 21/06/2016 11:21, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > >> On Tue, Jun 21, 2016 at 10:08:13AM +0200, Robert Varga wrote: > >>> Hello, > >>> > >>> Reading through section 4.8.1 and D.3.1, it seems that in case of > >>> content=all there is no guidance what the server should do if it > >>> encounters a leaf which has different values in config and oper. > >>> > >>> Would this constitute an error, or should one of them take precedence? > >>> > >> The notion of "all" may prove problematic depending on how we move > >> forward with multiple datastore. However, I think the most pressing > >> issue to address before RESTCONF goes to the RFC editor is to move the > >> default of the content query parameter back to 'config' instead of > >> 'all'. Having the content parameter default to 'all' makes it hard to > >> possibly deprecate 'all' in the future. > > I don't think this change would help. Suppose we introduce > > intended/applied/operational-state as proposed in your draft. Config > > true nodes would then exist in all three. So which one would be > > returned w/o any 'content' param (or 'content=config')? > > > > IMO the problem is that 'data' contains *combined* config and state, > > which doesn't really work if the same schema nodes can exist in both > > config and state. > This is one of the reasons why I prefer having only 2 datastores > (i.e. intended + operational state (inc applied config)) rather than > the 3 described above. > > The content=all operation can then return the contents of the > operational state datastore This would be fine, but this is NOT how the content parameter is defined today. Hmmm, maybe it is not clear what the "content" parameter actually does. It says: | config | Return only configuration descendant data nodes | | nonconfig | Return only non-configuration descendant data nodes | | all | Return all descendant data nodes | Whatever this means, it seems to imply that: GET(content=config) + GET(content=nonconfig) = GET(content=all) It is just a simple filter to select one subset of all data. This means that the "content" parameter does not affect the source of the data; the source is still the "combination of config ans state". > which happens to include the applied > configuration, and is also the same as what would be returned from a > RESTCONF device today. > > Full clean access to the separate datastores will require datastore > awareness in the REST API, but I can imagine that for a lot of simple > devices a simple combined view is useful. This would be ok. /martin From nobody Tue Jun 21 04:28:52 2016 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 C304A12D178 for ; Tue, 21 Jun 2016 04:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 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, RP_MATCHES_RCVD=-1.426] 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 ns52Nc_y1QJS for ; Tue, 21 Jun 2016 04:28:49 -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 1B06F12D16B for ; Tue, 21 Jun 2016 04:28:49 -0700 (PDT) Received: from [10.137.1.13] (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id 63DEF24443B; Tue, 21 Jun 2016 13:28:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1466508526; bh=6ZpyggywqKIobUxC+6wiEFLEspetNSWYrnhOB/VeyOw=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=t58nDR+T4NZyOqDGlR7iEdlszp/Jh0HhGc9zh8XJbl2RkaGxXBt7I77bSiXVFprmo wyS2ogvERKka/XUdbgXht0cODzXK9yGBOsY+2C4R+bDLFeXdSkethwMHek9tm2dQYt PHHBbRzchHeQKD7DD0zk1xR2BTEJMFxDZegEPI8Y= To: Martin Bjorklund References: <7a655427-0625-744a-1e5e-7e07aea4e11c@hq.sk> <20160621.104343.179630048330976700.mbj@tail-f.com> <061501d9-33ce-691f-dd40-0341405b67e3@hq.sk> <20160621.112015.1076159141397928039.mbj@tail-f.com> From: Robert Varga Message-ID: Date: Tue, 21 Jun 2016 13:28:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160621.112015.1076159141397928039.mbj@tail-f.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5FfRdsbidK8R0Jr8rFHHEUd4BGDn96thE" Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF content=all on conflicts?, Re: RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 11:28:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5FfRdsbidK8R0Jr8rFHHEUd4BGDn96thE Content-Type: multipart/mixed; boundary="DfbrOJ9D7LDotPw9rge3gksjMJX3geJ9x" From: Robert Varga To: Martin Bjorklund Cc: netconf@ietf.org Message-ID: Subject: Re: [Netconf] RESTCONF content=all on conflicts?,Re: [Netconf] RESTCONF content=all on conflicts? References: <7a655427-0625-744a-1e5e-7e07aea4e11c@hq.sk> <20160621.104343.179630048330976700.mbj@tail-f.com> <061501d9-33ce-691f-dd40-0341405b67e3@hq.sk> <20160621.112015.1076159141397928039.mbj@tail-f.com> In-Reply-To: <20160621.112015.1076159141397928039.mbj@tail-f.com> --DfbrOJ9D7LDotPw9rge3gksjMJX3geJ9x Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 06/21/2016 11:20 AM, Martin Bjorklund wrote: > Robert Varga wrote: >> On 06/21/2016 10:43 AM, Martin Bjorklund wrote: >>> If we >>> introduce separate datastores for intended, applied, operational-stat= e >>> as proposed in draft-schoenw-netmod-revised-datastores (which I think= >>> your question sort of implies), we will need to update this model bot= h >>> in NETCONF and RESTCONF. draft-schoenw-netmod-revised-datastores >>> suggests how this can be done. >> >> Right, sorry about silent implication, this comes from ODL >> implementation, which has an in-between architecture with separate >> config and oper stores >=20 > So does the schema for the oper store contain also all config true > nodes? If it doesn't there's no risk for a conflict, right? Yes, it does, but the config -> oper propagation is done asynchronously by individual plugins, hence there is a window when the two are not consistent. > How does ODL handle this case for NETCONF ? That is a good question, I had to look this one up -- it takes just the oper state (and assumes config was already mirrored). That feels like something that should be changed. Bye, Robert --DfbrOJ9D7LDotPw9rge3gksjMJX3geJ9x-- --5FfRdsbidK8R0Jr8rFHHEUd4BGDn96thE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXaSToAAoJECsDwSqgzwDTbMIP/2q3lfgqiSKTOuFITWRl0eP0 91CDzNgMMVMVhTMP/Wl5/YVbQQyFPvh/4yGxvxskx7eSUw0y5nycJA6Ynjnxh7B9 H7Uz9IIg95wOkxuShMeczHtq72lR+2Q3/eHOkEfuZ90UrtjGFmfPG8iwShwAbtw1 07AqYoYc3qOG3tyrtUar2fL31IjkZKSBr9x3w741rD5u1Sti3BWe5j0FIAwKl5wc ReRNFndMxArlp9cjFYv92sglokU76vSqFzqSYP2CiMkUd8+ENkjeg+LEPfnTG6Pu v8/TJmVJw4Fgbq1Lt4xB+jyVkJ3cFdpsFXi4JcmLaJ2A1WlCeIruj5T7c86Ajk1G LVrMt4VEAHstBcBFwhLEIASsBwHLt1SnCkOByL+WdKJ/YztBK8mHc3BXI220mXQq 4WlCqir3OIAXwlXgMxQaTPd2KV5dqhSBbY4nv7wZcqokZQrctWfHsBIa6PZ1zozS JipWuYPK5zvVm+y2U7zwP6M0ZUoy1UEapaYPQnfhWBXeE1/f56gVwjLSbkL7EZiv n4vrh0OBB/KNEfFoYoBzb8Ky//bPLCf4vkCDPQBUxJjXjxL4DtYjtwEUc4qJOUnY U+xmOxAVfxlG1fhblAwRtfbRsrEr4HSUtxAy++KGVelrNxXF67o++nYjZWVTPsr+ BkEXOYzZwEv73tcxCQgE =6Nvl -----END PGP SIGNATURE----- --5FfRdsbidK8R0Jr8rFHHEUd4BGDn96thE-- From nobody Tue Jun 21 04:58:30 2016 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 96A0412B00E for ; Tue, 21 Jun 2016 04:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46TtS9v2TlRp for ; Tue, 21 Jun 2016 04:58:26 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0091.outbound.protection.outlook.com [104.47.0.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 81C0712B008 for ; Tue, 21 Jun 2016 04:58:25 -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; bh=D2I7q8T7lJBxW1WH69qBqqu/9TSHkRX9VR7kcSD0hQc=; b=Zk2pwARQWlm2vvehjc9gITMVmy8QAYORgWGw3EyVKXqXfVM34bhQLy5Me9lbYj9ylVAknvDHVNZlqbttbwJMKfqa2WlDLaWoCPjmEizxfua04cwXuYE4lzJITZ5vFvrQavdXEK409SDd0rYo+pMM5ABU0EXHFwMTmt4dkXmfGMQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.151.165.8) by DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149) with Microsoft SMTP Server (TLS) id 15.1.523.12; Tue, 21 Jun 2016 11:58:13 +0000 Message-ID: <00a601d1cbb3$f2751940$4001a8c0@gateway.2wire.net> From: t.petch To: , Martin Bjorklund References: <20160621094628.GA41804@elstar.local> <20160621.122117.332960881532664788.mbj@tail-f.com> <34773154-f55f-9085-35fb-13e44d5b535a@cisco.com> <20160621.125931.365562743647782974.mbj@tail-f.com> Date: Tue, 21 Jun 2016 12:55:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.165.8] X-ClientProxiedBy: HE1PR06CA0052.eurprd06.prod.outlook.com (10.164.28.148) To DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149) X-MS-Office365-Filtering-Correlation-Id: 55fe6d3a-0a84-408f-c17c-08d399cb52ee X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 2:KmbMWwrm71ggkshL13iIImgcTmDfx6OX4js4SWgGBDfSxC0PoPyDGIzUfug6lXHoRHUEouQ/CVV9VhopkR8XEcx0kfcGd8uzFMPB1GKIaGVcFOG6Af08IJrq+1RnBuLgjcsCtG454egBRms7iK+zvLCWHTO1OybR41T6DTT0BFrnZTs3Fqnpt6BZDGGiEURL; 3:VB1G/ytl+Zm18nSneUkaRONzO7MBUfh0/q3tA2TCvIAWb7fnmxjlBO8TOwFIMuoRjdN2hHyl2EoKnAYLIhArBk8RsNTmFOY+hbMIJPAnUh4W+R9Q0eJ+Aqs4BYnsZOaV X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR07MB1622; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 25:dB9Vx9m3519lazo/5wXdf+3d4ZtCqsE0XJOWrGe1FVYItOP9/dtjCPZVeolqOe8bPbtM9FPS/XZcS4IuT1StNM7Tr/dQRV1NtXg4Mvzg3n84u3WuWq3leQHcUzBGhkbR2lslxe40bJPl+m5AwgMSBQYJXPprMMprgSjzEZC4I7cQIs8NONICeOuedWfH4s5rttzOKgExcKD2PButxpbeDjfJgUhqLJqJqmFc2qVjH2IO1PmS/O315sJiU79ctXOx5b2LojqQCnfyI5n/8AL4G1K7z8OcRmT+fYbtcM780awoE+k9q9enl45JJcxdoD3XtduBzrA3ICGzQwTCSCIXebTggw3GSgFV+4iL0OKHONVl5N2IsXlcA7eRlVYaNPRqGKYsr3KmymYvZ/SYCxYzO+NM7kJ4VEIpLZckCb+tEC5JcotZoT/e/FM7PEiqEVRMElb7DrEJEhDoMLZsQ/HlNrsL/12h69yq/y5YI0qd83cNWsJnqSSbMB5UYsQ+3s8ZKo6MQlGuI/DsT9PTf6SaMFJufuAPliIaNk9hbWNAYppHI/WUUfS9RnAWOoWyaU8RUoEv87LMBE1Ti9Hxh+zqEFCf7TBZ84kMdEyWylc55ou11oXYKTz9yGzwN16UKW6ITbNCvLi4VfD+obUT7LE8gOsXqTLB99UDO1kXzUlK9eatUgvMETzuZPulVHtxfWE9mGv7AKhN1O8fik7t1j/N/kdLcRyL0ftrt0wU5ldjaiw= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB5PR07MB1622; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1622; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 4:TbDN8+ny4scliQuk1mMoo7Q4N0+GUl/umcDcE55xDVYADoV3RItEwC11zrLUAoLym/2XjXqhq1Q5UkY6A4ZZSfSSGznElB0MP6IRHlfDgJNDKYLeDvLDal3dOS+SftRqPXz4rSyRDLPpti7JLb0uwSMTpptFGejt+Tad8WQUYXZQjTQtSG1MWJy3Ab9ceWy3KQaTiPWds5ZivqqVXaZ7T/ThKGdlpVzoW/NGQOJDFeRKxJElZXet898WLMcEdblBB90epevJ41SFf0ukcrxyCzJQh+HOSrQEkmCfkAgob9/L90SvFJXzGc1Y85vL7Ujod+5DRe/ErSKE8Fgp6EUxyAdgtVbqHUo8LFS06/k2iTaCEhMv6C0U/fQC9ZmJRX4NlIcGuLs85pjMPsvN2F9KBS1rNZx5wHmAIn9o1hZJU7ti1B+wcJNQmW72AHLg+oUR X-Forefront-PRVS: 098076C36C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(189002)(51444003)(13464003)(24454002)(199003)(377454003)(54094003)(4326007)(189998001)(66066001)(84392002)(47776003)(105586002)(62236002)(44716002)(97736004)(77096005)(7736002)(2906002)(92566002)(7846002)(50226002)(106356001)(8676002)(81156014)(81166006)(68736007)(5001770100001)(81686999)(76176999)(81816999)(6116002)(586003)(3846002)(50986999)(230700001)(1556002)(116806002)(93886004)(19580405001)(19580395003)(14496001)(42186005)(44736004)(86362001)(1456003)(50466002)(33646002)(101416001)(23756003)(9686002)(61296003)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1622; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB5PR07MB1622; 23:yWQgykZ6mxLtStI7B+KuA9Azq4RuRiHO220JGKk?= =?iso-8859-1?Q?iKSO4jGuy5KOVyShAlZneT58VFmuyEqEK+bgCdwRyoGT9VEjhCz9XRjOlB?= =?iso-8859-1?Q?wlN0qMF+Q/09EtLR666CCqvawCiNQSIRdHw+jQZyqbB2iEWtNwXLVgZUQD?= =?iso-8859-1?Q?Rjle5cArDFjrmDWwp+yLg551uEr+7H4vCtxkeQpOZL/e2mpt8r4tG4AMVw?= =?iso-8859-1?Q?5hUE7WFQlyr06mSBN16PR7yA67nu+1G7S0G6tpXDKugMFipTanWMHzXa5m?= =?iso-8859-1?Q?ACWhiOweWTnFB2SvL+sF1iKi+Jti41Kmczki59mgmww1+RkHRaB6EWSIC3?= =?iso-8859-1?Q?JlLeObepVxemSjQt8/KAVCh3WqqiuUklu6W0M+FQCmxPtlQlJeXGuzIZRE?= =?iso-8859-1?Q?Dz59ImHNtLi0w9XsvcsZHYbL2+3vRwHjQbWIRv93BGN2njctiAirrx3xfR?= =?iso-8859-1?Q?P08cXihEpoMOlZCUxt/w1vnSCkidzZnLotfVYm/PHWJ2SgSUZNclYQbYot?= =?iso-8859-1?Q?g3uWo0eZd36G/7li8UgF/kUwxvilcyGoTUFgKQcjwvNkGESiSBqiykmkrZ?= =?iso-8859-1?Q?6rpeXbRHs/zW4EGaUI1HAk1bia5bRycUPMEY8p82w2+n9Q+ngPDbeO0PsW?= =?iso-8859-1?Q?96J8/KSJlNYJ4GHG5B6c/YAt+Y82ew32fZywQBIbP3BOEZYeigfwIDFfxT?= =?iso-8859-1?Q?DqPCy5ew63CJyfywEuJG9q+djqkEBNNg9z0+rzW5TJy5EeOz3gnewjtYBY?= =?iso-8859-1?Q?4iHXI0zpQ8e/it/R1jNWgVK1I1NFSfYvLvZ9A8Y+onC13PxpvB76r5wyjY?= =?iso-8859-1?Q?T5XmNkgrM9lJMuakYt5eJeYkwfKaJUsmpSZMVVUJ94OGSD+EYfrgvo/3Eh?= =?iso-8859-1?Q?jqxuy/cSklPLAaC44TQ0ChBWv4ur2QfuhoH5gs9xNmbsP9l+F8xDOjfsg3?= =?iso-8859-1?Q?3E0+XzgBx2IT3Ny0FWt6Pvh8T219pnOWmsr2C3meAfTjycHlyfHbIbJG6s?= =?iso-8859-1?Q?LyDYbzzXa7eI5Y65seLH2FsrNKhyoOwTg6oRVaThDEemjya3F3tS7h5pm6?= =?iso-8859-1?Q?pg6zvIXEBkwgcxgGKmtW7jEyNpPhjLmFI9H3aI0Hdb2p3QwcsngE41ukf8?= =?iso-8859-1?Q?lLmCYg67LU0wdm97crF+MzYnw5gD/NJReJjGM+KMnRplij+4OQyjoYG943?= =?iso-8859-1?Q?0mEu1oru2jnoXSwrH4b6cAgts+/lycEntP7GUuuT4CNeOfgMnl1cpgyrM6?= =?iso-8859-1?Q?ZPopfl25UfE7kz9w0k9Lkcr99KMQTHH3vQpjqo6QnXP+SYMEZBlMrrKkni?= =?iso-8859-1?Q?XEx90iA46otbjqmY6JX2DfCLVGPGJQeeXnWUD4GIPrrmZcE32YOKXFNe/S?= =?iso-8859-1?Q?XMIHfvl/EfgCXS1DcZg+/XzDktinowi7JCgBCg3QcrVMtUZQ7iWtWJ+24S?= =?iso-8859-1?Q?GMkGOxtmL3h8nJ+IkkhvgSMWP2To6TAFByD?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 6:Msyu8VcIoomAc2o1SmYsiQkAQhbkN1r3/kaojuZo6lOi3gI7fCCiMe0uYRTF06SV9xgV+8BLG8sGImZhUWK7CAOVGhdtusVSaRiyV6Jk87kTSg+Cpl263W/4swqJpM+ob/AEMyASqPZiU4761J9dRNx2Ob5jqUTD6PdrLRaK8XgYblPfw0vYwiRYdnsFAyEeElQ1kZ4LE0OaYJPDxZ6DfUdukfFZ+kMa/df+d2x3R60+SIV3x26NE3JWXV31emTVfwzd2Q4ccPR7smx7qG6E2p9U/WNyugblpOnJ+NgcGHc=; 5:3qtiIPFhxuZSEYkqxFLebeqyO4HaQVMkdfXxsWYISpC3A675Jij6nl/auV4yBFycj+WzRvPkycsTLKThnsK3+pJA2btOFGstLX7/DZ8SEt8vFiLW6JcgSaaXOQ0eKdxnZjuW2lauDhJIBuPm4UN88w==; 24:eUyxB4pZQKqFaijOcAsbnn7vrsRdypZIe7r1wceH9PcOT7QmGHyKYtRYJKIrmjm7tBojHcl29RLcX/cVp8VBtg+t7/O0nr3h6fNtNwChcCo=; 7:8Ry9wRAACIIF7aBV46dWZD7LF9LYWfM4yWMcVsvyvUzFgVbXsigrrI9lnsUh6ROX0GUSot759iFsa/BUrgnMsCogNk9T02j905hPMnsOSXcJE1qH5NgJXlmo4uptN5F6usoJtvYYinEtkr9Kxpg8W+fXOHQRleyOEfre/F2RCG6pPyUNQeqqyEDYZClx7jcGlTHXbX2Dn61XhxQ9pl92vxucaYg5kIhb79KgWJM/Q/e2WSz7ez6Wt6ZkOkPjP4la SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2016 11:58:13.2606 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1622 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 11:58:28 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Tuesday, June 21, 2016 11:59 AM > Robert Wilton wrote: > > > > On 21/06/2016 11:21, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > >> On Tue, Jun 21, 2016 at 10:08:13AM +0200, Robert Varga wrote: > > >>> > > >>> Reading through section 4.8.1 and D.3.1, it seems that in case of > > >>> content=all there is no guidance what the server should do if it > > >>> encounters a leaf which has different values in config and oper. > > >>> > > >>> Would this constitute an error, or should one of them take precedence? > > >>> > > >> The notion of "all" may prove problematic depending on how we move > > >> forward with multiple datastore. However, I think the most pressing > > >> issue to address before RESTCONF goes to the RFC editor is to move the > > >> default of the content query parameter back to 'config' instead of > > >> 'all'. Having the content parameter default to 'all' makes it hard to > > >> possibly deprecate 'all' in the future. > > > I don't think this change would help. Suppose we introduce > > > intended/applied/operational-state as proposed in your draft. Config > > > true nodes would then exist in all three. So which one would be > > > returned w/o any 'content' param (or 'content=config')? > > > > > > IMO the problem is that 'data' contains *combined* config and state, > > > which doesn't really work if the same schema nodes can exist in both > > > config and state. > > This is one of the reasons why I prefer having only 2 datastores > > (i.e. intended + operational state (inc applied config)) rather than > > the 3 described above. > > > > The content=all operation can then return the contents of the > > operational state datastore > > This would be fine, but this is NOT how the content parameter is > defined today. Hmmm, maybe it is not clear what the "content" > parameter actually does. It says: > > | config | Return only configuration descendant data nodes | > | nonconfig | Return only non-configuration descendant data nodes | > | all | Return all descendant data nodes | > > Whatever this means, it seems to imply that: > > GET(content=config) + GET(content=nonconfig) = GET(content=all) > > It is just a simple filter to select one subset of all data. > > > This means that the "content" parameter does not affect the source of > the data; the source is still the "combination of config ans state". Martin I think that it is sort of clear. I did comment earlier on the non-use of the term 'state' in this I-D and it has been changed in most places, but not here. I would prefer the choice to be 'config' 'state' 'all' to be in line with NETCONF. There is a further ambiguity in this thread that NETCONF discarded the term operational state and uses state for both data learnt by other means, such as a hot-plugged card or a routing protocol, and statistics. When someone uses the term operational state, are they including statistics? According to NETCONF yes, but I wonder if they understand that. An unfiltered 'get' 'all' could be big. Tom Petch From nobody Tue Jun 21 05:05:28 2016 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 87ED412B022 for ; Tue, 21 Jun 2016 05:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 BARgvkT-6_p1 for ; Tue, 21 Jun 2016 05:05:25 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 4D44012B008 for ; Tue, 21 Jun 2016 05:05:25 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id u64so17108239vkf.3 for ; Tue, 21 Jun 2016 05:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=rF6WJlfmIKPOQ2/a+LQxQn6Mwp2w3o1+T4/SubZcoX8=; b=MwdGbvSgd+uxp7HhLK0ETLGSBrzQjajowdi5hxWdP+SH2/bWz7YC2i0TeQZnwPse3y z0lFBE8vUIeN6XMufOUGSXZDwEAcunP7REOXQOLonKwojG+57G+IsHnqpH86ArbvAwYn TkH8VSPsRQViFMasi/uvfNGO8utSaGMmbR0TSeaMtEkEfyHj+NInukMhBY9W3xBX0i/r C7oqJMUHeBo+kKBSVvV5Y9ia/4NnFljHResyK5TVa74pQtUOgUJ4maLWkwOa7gmOUMV2 d8EgR0zKCwnf1kY87Bt+eiLzrZ5Q4Ny2O/eSCbygGo/jxhX6bbh0J+dzuvUo7dEkuFcR SZ0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=rF6WJlfmIKPOQ2/a+LQxQn6Mwp2w3o1+T4/SubZcoX8=; b=g4L1ZvIEb6aUsz0yX3+AjrfU4McZxHS2Oqz51DdMj9XHeYPNbJ2Q2JsZ7IBSxthFDR qNyChLWIjhedYMzqxsKA3K5n2tk1G4Ygh/QuaIl3HTDr32C1jBWD1vGK/XhUUxfPjxx8 piFbk9gsiSuDFokmzfTbAZo/vGLZWVSkhXtQWrwvDF+XrmrauBI1QarGfgLUwAtMHHKB pbqoEZ4Os0GwWEDzkOtIG5sfQP26UZaUo5GlNF76xFuxO14aCBu48aV1IX9vCzSxuM+P /oId8bJLlI3qP9DLP5VhMifPhbjW6J8PIVvpxzcoETFQTxqHYA6A0Pr5p6R8W99iLP5u L9Sw== X-Gm-Message-State: ALyK8tItYDU92EBUMO9NFJuae7BKFBEFVLxWQV/uOxtoUt4QizJHNpKVA+VkPcC8RfZDVhaeU/he4OIOffAq+g== MIME-Version: 1.0 X-Received: by 10.176.64.166 with SMTP id i35mr8888617uad.105.1466510724092; Tue, 21 Jun 2016 05:05:24 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Tue, 21 Jun 2016 05:05:24 -0700 (PDT) In-Reply-To: <00a601d1cbb3$f2751940$4001a8c0@gateway.2wire.net> References: <20160621094628.GA41804@elstar.local> <20160621.122117.332960881532664788.mbj@tail-f.com> <34773154-f55f-9085-35fb-13e44d5b535a@cisco.com> <20160621.125931.365562743647782974.mbj@tail-f.com> <00a601d1cbb3$f2751940$4001a8c0@gateway.2wire.net> Date: Tue, 21 Jun 2016 05:05:24 -0700 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=94eb2c1243b2c4ec4a0535c8a252 Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 12:05:27 -0000 --94eb2c1243b2c4ec4a0535c8a252 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 21, 2016 at 4:55 AM, t.petch wrote: > ----- Original Message ----- > From: "Martin Bjorklund" > To: > Cc: > Sent: Tuesday, June 21, 2016 11:59 AM > > > Robert Wilton wrote: > > > > > > On 21/06/2016 11:21, Martin Bjorklund wrote: > > > > Juergen Schoenwaelder > wrote: > > > >> On Tue, Jun 21, 2016 at 10:08:13AM +0200, Robert Varga wrote: > > > >>> > > > >>> Reading through section 4.8.1 and D.3.1, it seems that in case > of > > > >>> content=all there is no guidance what the server should do if it > > > >>> encounters a leaf which has different values in config and oper. > > > >>> > > > >>> Would this constitute an error, or should one of them take > precedence? > > > >>> > > > >> The notion of "all" may prove problematic depending on how we > move > > > >> forward with multiple datastore. However, I think the most > pressing > > > >> issue to address before RESTCONF goes to the RFC editor is to > move the > > > >> default of the content query parameter back to 'config' instead > of > > > >> 'all'. Having the content parameter default to 'all' makes it > hard to > > > >> possibly deprecate 'all' in the future. > > > > I don't think this change would help. Suppose we introduce > > > > intended/applied/operational-state as proposed in your draft. > Config > > > > true nodes would then exist in all three. So which one would be > > > > returned w/o any 'content' param (or 'content=config')? > > > > > > > > IMO the problem is that 'data' contains *combined* config and > state, > > > > which doesn't really work if the same schema nodes can exist in > both > > > > config and state. > > > This is one of the reasons why I prefer having only 2 datastores > > > (i.e. intended + operational state (inc applied config)) rather than > > > the 3 described above. > > > > > > The content=all operation can then return the contents of the > > > operational state datastore > > > > This would be fine, but this is NOT how the content parameter is > > defined today. Hmmm, maybe it is not clear what the "content" > > parameter actually does. It says: > > > > | config | Return only configuration descendant data nodes > | > > | nonconfig | Return only non-configuration descendant data nodes > | > > | all | Return all descendant data nodes > | > > > > Whatever this means, it seems to imply that: > > > > GET(content=config) + GET(content=nonconfig) = GET(content=all) > > > > It is just a simple filter to select one subset of all data. > > > > > > This means that the "content" parameter does not affect the source of > > the data; the source is still the "combination of config ans state". > > Martin > > I think that it is sort of clear. I did comment earlier on the non-use > of the term 'state' in this I-D and it has been changed in most places, > but not here. I would prefer the choice to be 'config' 'state' 'all' to > be in line with NETCONF. > > There is a further ambiguity in this thread that NETCONF discarded the > term operational state and uses state for both data learnt by other > means, such as a hot-plugged card or a routing protocol, and statistics. > When someone uses the term operational state, are they including > statistics? According to NETCONF yes, but I wonder if they understand > that. An unfiltered 'get' 'all' could be big. > > The config parameter simply provides a filter based on the YANG config-stmt. It is not a datastore filter. RESTCONF does not expose datastores. You keep seeing proof that NETCONF is in chaos because some people want to refine the datastore model wo support new features. It doesn't look that way to me. > Tom Petch > > > Andy > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --94eb2c1243b2c4ec4a0535c8a252 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 21, 2016 at 4:55 AM, t.petch <ietfc@btconnect.com&g= t; wrote:
----- Original Message -= ----
From: "Martin Bjorklund" <mb= j@tail-f.com>
To: <rwilton@cisco.com>
Cc: <netconf@ietf.org>
Sent: Tuesday, June 21, 2016 11:59 AM

> Robert Wilton <rwilton@cisco.c= om> wrote:
> >
> > On 21/06/2016 11:21, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
wrote:
> > >> On Tue, Jun 21, 2016 at 10:08:13AM +0200, Robert Varga w= rote:
> > >>>
> > >>> Reading through section 4.8.1 and=C2=A0 D.3.1, it se= ems that in case
of
> > >>> content=3Dall there is no guidance what the server s= hould do if it
> > >>> encounters a leaf which has different values in conf= ig and oper.
> > >>>
> > >>> Would this constitute an error, or should one of the= m take
precedence?
> > >>>
> > >> The notion of "all" may prove problematic depe= nding on how we
move
> > >> forward with multiple datastore. However, I think the mo= st
pressing
> > >> issue to address before RESTCONF goes to the RFC editor = is to
move the
> > >> default of the content query parameter back to 'conf= ig' instead
of
> > >> 'all'. Having the content parameter default to &= #39;all' makes it
hard to
> > >> possibly deprecate 'all' in the future.
> > > I don't think this change would help.=C2=A0 Suppose we i= ntroduce
> > > intended/applied/operational-state as proposed in your draft= .
Config
> > > true nodes would then exist in all three.=C2=A0 So which one= would be
> > > returned w/o any 'content' param (or 'content=3D= config')?
> > >
> > > IMO the problem is that 'data' contains *combined* c= onfig and
state,
> > > which doesn't really work if the same schema nodes can e= xist in
both
> > > config and state.
> > This is one of the reasons why I prefer having only 2 datastores<= br> > > (i.e. intended + operational state (inc applied config)) rather t= han
> > the 3 described above.
> >
> > The content=3Dall operation can then return the contents of the > > operational state datastore
>
> This would be fine, but this is NOT how the content parameter is
> defined today.=C2=A0 =C2=A0Hmmm, maybe it is not clear what the "= content"
> parameter actually does.=C2=A0 It says:
>
>=C2=A0 =C2=A0 =C2=A0| config=C2=A0 =C2=A0 | Return only configuration d= escendant data nodes
|
>=C2=A0 =C2=A0 =C2=A0| nonconfig | Return only non-configuration descend= ant data nodes
|
>=C2=A0 =C2=A0 =C2=A0| all=C2=A0 =C2=A0 =C2=A0 =C2=A0| Return all descen= dant data nodes
|
>
> Whatever this means, it seems to imply that:
>
>=C2=A0 =C2=A0GET(content=3Dconfig) + GET(content=3Dnonconfig) =3D GET(c= ontent=3Dall)
>
> It is just a simple filter to select one subset of all data.
>
>
> This means that the "content" parameter does not affect the = source of
> the data; the source is still the "combination of config ans stat= e".

Martin

I think that it is sort of clear.=C2=A0 I did comment earlier on the non-us= e
of the term 'state' in this I-D and it has been changed in most pla= ces,
but not here.=C2=A0 I would prefer the choice to be 'config' 's= tate' 'all' to
be in line with NETCONF.

There is a further ambiguity in this thread that=C2=A0 NETCONF discarded th= e
term operational state and uses state for both data learnt by other
means, such as a hot-plugged card or a routing protocol, and statistics. When someone uses the term operational state, are they including
statistics?=C2=A0 According to NETCONF yes, but I wonder if they understand=
that.=C2=A0 An unfiltered 'get' 'all' could be big.



The config parameter si= mply provides a filter based on the YANG config-stmt.
It is not a= datastore filter.=C2=A0 RESTCONF does not expose datastores.
You keep seeing proof that NETCONF is in chaos because some peo= ple
want to refine the datastore model wo support new features.= =C2=A0 It doesn't
look that way to me.

=C2=A0
Tom Petch




Andy
=C2=A0
<snip>

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

--94eb2c1243b2c4ec4a0535c8a252-- From nobody Tue Jun 21 05:16:35 2016 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 34B2D12B063 for ; Tue, 21 Jun 2016 05:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 xMX0yXTC3d4E for ; Tue, 21 Jun 2016 05:16:27 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EAF412D098 for ; Tue, 21 Jun 2016 05:16:27 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id j2so17512816vkg.2 for ; Tue, 21 Jun 2016 05:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ZUJFfccMl0xxJRcRrhE7Bp1CTHjKhNojx9yrYAS6TLs=; b=banoApVzzLLAHeSMz/6T7e1jEBwwGryfUF2GDsiZCx27i8lOGlkLPmbMF+HIauAciv 2ZNfWCjPADv1Vf0e2m/bAH08huba4bwLg2/rbzEGCZSeaOMxW/9JkqyRV/5uDe6QuG9w /enzLCKkFoA1r/nKfRur7Yp5Tk8GyIi1pAs6HUIQY5ZEbt+WbM827DvHbRdD6NZPsueT PedLPZsMDgBXvxmX0BFKKaT9vD9pi06qCv26pE5lBTdv+1QRRcngEgWGT0tdcbzNBWs4 Cemv7ZG1J9J6k2AiZJaawaQaLkwZl9kyb61WEE9MyfyQWCavdkA18B34H6X6n5Soox+B XsSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ZUJFfccMl0xxJRcRrhE7Bp1CTHjKhNojx9yrYAS6TLs=; b=WwlYp8KTIkFQUnbOrNzZCZ5n+nt2lZJVwSYq2lHGxi5N5qsUwINU+qmvJmqEFYTeJN FeBYvE4tbFTpii0jVWwf/MRTAUZRVQPCvMlJC9hRyPPH9rn5NxDznBD7KoY9slwBeSQ8 wsDH0sQ4+pvFnteyDt1rq/+DWc1/2gHF8Eodxr/g6xWEckeDOLXE5aDdidTGuZLZYHMZ tDfovKYWJw6VdkgOdbcwSqA3hBdC+grTYQjBIYDGuzpjS0r9Wl8G3ZPVjNbcRHImXZSX ++1wpV9JFuX65Ffe/D1au0P/NT8qSrOQwaF2x1Rh7935QMc/Ys5JD+1j8NR1vTlx2PLA /vjw== X-Gm-Message-State: ALyK8tLQyv42RA3M8TtOCbcazqVWlP8L9whwI2sh6H5peb9ZDDjPl29S5xfgC2JCW/dxrei/VvazxN4Y4w+mcA== MIME-Version: 1.0 X-Received: by 10.31.201.194 with SMTP id z185mr9454112vkf.13.1466511386439; Tue, 21 Jun 2016 05:16:26 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Tue, 21 Jun 2016 05:16:26 -0700 (PDT) In-Reply-To: <5F59F1E8-62E8-4AE9-9E51-DB4E506C3C80@nic.cz> References: <5F59F1E8-62E8-4AE9-9E51-DB4E506C3C80@nic.cz> Date: Tue, 21 Jun 2016 05:16:26 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a114dde843f86df0535c8ca81 Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 12:16:34 -0000 --001a114dde843f86df0535c8ca81 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 21, 2016 at 12:39 AM, Ladislav Lhotka wrote: > > > On 21 Jun 2016, at 02:11, Andy Bierman wrote: > > > > Hi, > > > > The media type definitions in RESTCONF-13 are incorrect. > > We cannot make subtypes for application/yang. > > Each RESTCONF (and YANG Patch) media type has > > to be registered. > > > > > > Approach 1) hard-wired types > > > > > > RESTCONF would register 10 media types and YANG Patch 4 media types > > if we use the hardwired approach. > > > > application/yang-api+xml > > application/yang-api+json > > application/yang-datastore+xml > > application/yang-datastore+json > > application/yang-data+xml > > application/yang-data+json > > application/yang-errors+xml > > application/yang-errors+json > > application/yang-operation+xml > > application/yang-operations+json > > application/yang-patch+xml > > application/yang-patch+json > > application/yang-patch-status+xml > > application/yang-patch-status+json > > > > Any new media types would need to be registered. > > No usage of the restconf-media-type is possible besides > > this list of media types for RESTCONF and YANG Patch > > without additional registrations. > > > > Approach 2) generic types with a parameter > > > > A parameter approach would allow YANG to be used to define any > > message content schema. E.g., a mandatory "type" parameter > > that specifies the module and name of the restconf-media-type. > > > > Only 2 media type need to be registered for every media-type > > that could ever be specified (SDO or vendor) > > > > application/yang-data-xml;type=: > > application/yang-data-json;type=: > > > > application/yang-data-xml;type=ietf-restconf:api > > application/yang-data-json;type=ietf-restconf:api > > application/yang-data-xml;type=ietf-restconf:datastore > > application/yang-data-json;type=ietf-restconf:datastore > > application/yang-data-xml;type=ietf-restconf:data > > application/yang-data-json;type=ietf-restconf:data > > application/yang-data-xml;type=ietf-restconf:errors > > application/yang-data-json;type=ietf-restconf:errors > > application/yang-data-xml;type=ietf-restconf:operation > > application/yang-data-json;type=ietf-restconf:operation > > application/yang-data-xml;type=ietf-yang-patch:yang-patch > > application/yang-data-json;type=ietf-yang-patch:yang-patch > > application/yang-data-xml;type=ietf-yang-patch:yang-patch-status > > application/yang-data-json;type=ietf-yang-patch:yang-patch-status > > > > > > If you have a preference how this issue is resolved, send comments. > > I prefer #1, as media types aren't supposed to carry schema information > (and we do have it elsewhere). One thing to consider though is to reduce > the number of media types. For example, it's IMO not necessary to have > separate media types "application/yang-data" and > "application/yang-operation" because they can be easily discriminated via > the URI. > > I think #1 is simpler to implement. I don't agree we should make operation and data resources the same media type. It is useful in implementation to tell POST data from POST operation before parsing the message-body. Lada > > > > > > Andy > > > > Andy > > > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a114dde843f86df0535c8ca81 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 21, 2016 at 12:39 AM, Ladislav Lhotka <= ;lhotka@nic.cz> wrote:

> On 21 Jun 2016, at 02:11, Andy Bierman <andy@yumaworks.com> wrote:
>
> Hi,
>
> The media type definitions in RESTCONF-13 are incorrect.
> We cannot make subtypes for application/yang.
> Each RESTCONF (and YANG Patch) media type has
> to be registered.
>
>
> Approach 1) hard-wired types
>
>
> RESTCONF would register 10 media types and YANG Patch 4 media types > if we use the hardwired approach.
>
>=C2=A0 =C2=A0 application/yang-api+xml
>=C2=A0 =C2=A0 application/yang-api+json
>=C2=A0 =C2=A0 application/yang-datastore+xml
>=C2=A0 =C2=A0 application/yang-datastore+json
>=C2=A0 =C2=A0 application/yang-data+xml
>=C2=A0 =C2=A0 application/yang-data+json
>=C2=A0 =C2=A0 application/yang-errors+xml
>=C2=A0 =C2=A0 application/yang-errors+json
>=C2=A0 =C2=A0 application/yang-operation+xml
>=C2=A0 =C2=A0 application/yang-operations+json
>=C2=A0 =C2=A0 application/yang-patch+xml
>=C2=A0 =C2=A0 application/yang-patch+json
>=C2=A0 =C2=A0 application/yang-patch-status+xml
>=C2=A0 =C2=A0 application/yang-patch-status+json
>
> Any new media types would need to be registered.
> No usage of the restconf-media-type is possible besides
> this list of media types for RESTCONF and YANG Patch
> without additional registrations.
>
> Approach 2) generic types with a parameter
>
> A parameter approach would allow YANG to be used to define any
> message content schema.=C2=A0 E.g., a mandatory "type" param= eter
> that specifies the module and name of the restconf-media-type.
>
> Only 2 media type need to be registered for every media-type
> that could ever be specified (SDO or vendor)
>
>=C2=A0 =C2=A0 application/yang-data-xml;type=3D<module>:<name&= gt;
>=C2=A0 =C2=A0 application/yang-data-json;type=3D<module>:<name= >
>
>=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-restconf:api
>=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-restconf:api
>=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-restconf:datastore<= br> >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-restconf:datastore=
>=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-restconf:data
>=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-restconf:data
>=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-restconf:errors
>=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-restconf:errors >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-restconf:operation<= br> >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-restconf:operation=
>=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-yang-patch:yang-pat= ch
>=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-yang-patch:yang-pa= tch
>=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-yang-patch:yang-pat= ch-status
>=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-yang-patch:yang-pa= tch-status
>
>
> If you have a preference how this issue is resolved, send comments.
I prefer #1, as media types aren't supposed to carry schema information= (and we do have it elsewhere). One thing to consider though is to reduce t= he number of media types. For example, it's IMO not necessary to have s= eparate media types "application/yang-data" and "application= /yang-operation" because they can be easily discriminated via the URI.=



I think #1 is simpler t= o implement.
I don't agree we should make operation and data = resources the same media type.
It is useful in implementation to = tell POST data from POST operation before parsing
the message-bod= y.

Lada

>
>


Andy
=C2= =A0
>
> Andy
>
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf<= br>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--001a114dde843f86df0535c8ca81-- From nobody Tue Jun 21 05:19:22 2016 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 2C96B12D098 for ; Tue, 21 Jun 2016 05:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 9Rv4f5RkuupT for ; Tue, 21 Jun 2016 05:19:18 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B58C912B02B for ; Tue, 21 Jun 2016 05:19:18 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 856F1726; Tue, 21 Jun 2016 14:19:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id W5SstM1FqytZ; Tue, 21 Jun 2016 14:19:15 +0200 (CEST) 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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 21 Jun 2016 14:19:16 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A99F120054; Tue, 21 Jun 2016 14:19:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id M3Zv502ZDdId; Tue, 21 Jun 2016 14:19:15 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DCCAE20047; Tue, 21 Jun 2016 14:19:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1A3CC3B2E3C3; Tue, 21 Jun 2016 14:19:14 +0200 (CEST) Date: Tue, 21 Jun 2016 14:19:14 +0200 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20160621121914.GA42059@elstar.local> Mail-Followup-To: Robert Wilton , Martin Bjorklund , netconf@ietf.org References: <7a655427-0625-744a-1e5e-7e07aea4e11c@hq.sk> <20160621094628.GA41804@elstar.local> <20160621.122117.332960881532664788.mbj@tail-f.com> <34773154-f55f-9085-35fb-13e44d5b535a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34773154-f55f-9085-35fb-13e44d5b535a@cisco.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 12:19:20 -0000 On Tue, Jun 21, 2016 at 11:50:38AM +0100, Robert Wilton wrote: > > This is one of the reasons why I prefer having only 2 datastores (i.e. > intended + operational state (inc applied config)) rather than the 3 > described above. I fail to see why the # of datastores matters. If the 'content' parameter really just filters by the YANG config true|false property, then using config true data nodes to also report state in a different datastore won't work, regardless what the number is. > The content=all operation can then return the contents of the operational > state datastore which happens to include the applied configuration, and is > also the same as what would be returned from a RESTCONF device today. But this is not how the parameter is defined. /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 Jun 21 05:19:31 2016 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 2F09712D552 for ; Tue, 21 Jun 2016 05:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 w1zaGd8WtmG4 for ; Tue, 21 Jun 2016 05:19:21 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B28212B008 for ; Tue, 21 Jun 2016 05:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3494; q=dns/txt; s=iport; t=1466511561; x=1467721161; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=J+DpLVDzuAiTCWH9WOSNSCryOqnpjfjEmHQuFQhSzDA=; b=e6rBgN0KJ+WgAYZyBWw9PIh1hEN8uwVleIRUepnrOMg0Nf4cFiu3i3Ln k2WxB6739r34l43Iw7esLfBMOzXKFf+ezA/xUvpC0r+eMK/ulbqRfzaT1 9ErKVBlVP7Q13jEoxOLCwHVCAaZla0BLcoUMXjjj80N4ghP+Ru9dI0ayc Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBAByMGlX/xbLJq1dhD9SuGiECYYXA?= =?us-ascii?q?oF/AQEBAQEBZieESwEBAQMBOEEQCw4CCC5XBg0GAgEBiCQIwUIBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEfhieBdwiCToQqhXEFmHmOLIlGhV2PeFSDcTsyikgBAQE?= X-IronPort-AV: E=Sophos;i="5.26,503,1459814400"; d="scan'208";a="638130259" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2016 12:19:19 +0000 Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u5LCJIqp032554; Tue, 21 Jun 2016 12:19:19 GMT To: Martin Bjorklund References: <20160621094628.GA41804@elstar.local> <20160621.122117.332960881532664788.mbj@tail-f.com> <34773154-f55f-9085-35fb-13e44d5b535a@cisco.com> <20160621.125931.365562743647782974.mbj@tail-f.com> From: Robert Wilton Message-ID: <97fe11c4-027c-9835-00ed-518ce3b1827e@cisco.com> Date: Tue, 21 Jun 2016 13:19:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160621.125931.365562743647782974.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 12:19:23 -0000 On 21/06/2016 11:59, Martin Bjorklund wrote: > Robert Wilton wrote: >> >> On 21/06/2016 11:21, Martin Bjorklund wrote: >>> Juergen Schoenwaelder wrote: >>>> On Tue, Jun 21, 2016 at 10:08:13AM +0200, Robert Varga wrote: >>>>> Hello, >>>>> >>>>> Reading through section 4.8.1 and D.3.1, it seems that in case of >>>>> content=all there is no guidance what the server should do if it >>>>> encounters a leaf which has different values in config and oper. >>>>> >>>>> Would this constitute an error, or should one of them take precedence? >>>>> >>>> The notion of "all" may prove problematic depending on how we move >>>> forward with multiple datastore. However, I think the most pressing >>>> issue to address before RESTCONF goes to the RFC editor is to move the >>>> default of the content query parameter back to 'config' instead of >>>> 'all'. Having the content parameter default to 'all' makes it hard to >>>> possibly deprecate 'all' in the future. >>> I don't think this change would help. Suppose we introduce >>> intended/applied/operational-state as proposed in your draft. Config >>> true nodes would then exist in all three. So which one would be >>> returned w/o any 'content' param (or 'content=config')? >>> >>> IMO the problem is that 'data' contains *combined* config and state, >>> which doesn't really work if the same schema nodes can exist in both >>> config and state. >> This is one of the reasons why I prefer having only 2 datastores >> (i.e. intended + operational state (inc applied config)) rather than >> the 3 described above. >> >> The content=all operation can then return the contents of the >> operational state datastore > This would be fine, but this is NOT how the content parameter is > defined today. Hmmm, maybe it is not clear what the "content" > parameter actually does. It says: > > | config | Return only configuration descendant data nodes | > | nonconfig | Return only non-configuration descendant data nodes | > | all | Return all descendant data nodes | > > Whatever this means, it seems to imply that: > > GET(content=config) + GET(content=nonconfig) = GET(content=all) > > It is just a simple filter to select one subset of all data. > > > This means that the "content" parameter does not affect the source of > the data; the source is still the "combination of config ans state". OK, so perhaps refine/redefine that GET requests on "/restconf/data" are always against the operational state (inc applied config) datastore. I.e. with the content=config filter you just get applied-config. POST/POST/etc requests would write to what I have labelled as the persistent config ds. Semantically, this doesn't seem to be that different to writing to the candidate ds under the covers if necessary that RESTCONF does today. I appreciate that this is not how this is defined at the moment, but this would still seem to be backwards compatible refinement. Thanks, Rob > >> which happens to include the applied >> configuration, and is also the same as what would be returned from a >> RESTCONF device today. >> >> Full clean access to the separate datastores will require datastore >> awareness in the REST API, but I can imagine that for a lot of simple >> devices a simple combined view is useful. > This would be ok. > > > /martin > . > From nobody Tue Jun 21 05:23:05 2016 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 2EBBB128E18 for ; Tue, 21 Jun 2016 05:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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, RP_MATCHES_RCVD=-1.426] 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 Ju8T-KvYzz4K for ; Tue, 21 Jun 2016 05:22:59 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8836D128874 for ; Tue, 21 Jun 2016 05:22:59 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 2195260810; Tue, 21 Jun 2016 14:22:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1466511778; bh=Cnly4l3IhGzV4bnIl5K44MFfG5IwcYWsOW4dlZMRd08=; h=From:Date:To; b=OU1yQ6y2O58e5htBWi6ZCbQ1BhWVZP9qiv0QeO6VjS/H6ID6SEWKBMZHqognWA1kR k053671ljUmpa7Ks0R83DBbZVLRQ/bUg6U4vJUj0v1w4XK5IS4Ms/DpPb5uZ3Ld/Wd eAW9rwZhETYl24bRhhIBncinR6SRF0ZZzpTyS0vQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 21 Jun 2016 14:23:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5F59F1E8-62E8-4AE9-9E51-DB4E506C3C80@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 12:23:02 -0000 > On 21 Jun 2016, at 14:16, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Jun 21, 2016 at 12:39 AM, Ladislav Lhotka = wrote: >=20 > > On 21 Jun 2016, at 02:11, Andy Bierman wrote: > > > > Hi, > > > > The media type definitions in RESTCONF-13 are incorrect. > > We cannot make subtypes for application/yang. > > Each RESTCONF (and YANG Patch) media type has > > to be registered. > > > > > > Approach 1) hard-wired types > > > > > > RESTCONF would register 10 media types and YANG Patch 4 media types > > if we use the hardwired approach. > > > > application/yang-api+xml > > application/yang-api+json > > application/yang-datastore+xml > > application/yang-datastore+json > > application/yang-data+xml > > application/yang-data+json > > application/yang-errors+xml > > application/yang-errors+json > > application/yang-operation+xml > > application/yang-operations+json > > application/yang-patch+xml > > application/yang-patch+json > > application/yang-patch-status+xml > > application/yang-patch-status+json > > > > Any new media types would need to be registered. > > No usage of the restconf-media-type is possible besides > > this list of media types for RESTCONF and YANG Patch > > without additional registrations. > > > > Approach 2) generic types with a parameter > > > > A parameter approach would allow YANG to be used to define any > > message content schema. E.g., a mandatory "type" parameter > > that specifies the module and name of the restconf-media-type. > > > > Only 2 media type need to be registered for every media-type > > that could ever be specified (SDO or vendor) > > > > application/yang-data-xml;type=3D: > > application/yang-data-json;type=3D: > > > > application/yang-data-xml;type=3Dietf-restconf:api > > application/yang-data-json;type=3Dietf-restconf:api > > application/yang-data-xml;type=3Dietf-restconf:datastore > > application/yang-data-json;type=3Dietf-restconf:datastore > > application/yang-data-xml;type=3Dietf-restconf:data > > application/yang-data-json;type=3Dietf-restconf:data > > application/yang-data-xml;type=3Dietf-restconf:errors > > application/yang-data-json;type=3Dietf-restconf:errors > > application/yang-data-xml;type=3Dietf-restconf:operation > > application/yang-data-json;type=3Dietf-restconf:operation > > application/yang-data-xml;type=3Dietf-yang-patch:yang-patch > > application/yang-data-json;type=3Dietf-yang-patch:yang-patch > > application/yang-data-xml;type=3Dietf-yang-patch:yang-patch-status > > application/yang-data-json;type=3Dietf-yang-patch:yang-patch-status= > > > > > > If you have a preference how this issue is resolved, send comments. >=20 > I prefer #1, as media types aren't supposed to carry schema = information (and we do have it elsewhere). One thing to consider though = is to reduce the number of media types. For example, it's IMO not = necessary to have separate media types "application/yang-data" and = "application/yang-operation" because they can be easily discriminated = via the URI. >=20 >=20 >=20 > I think #1 is simpler to implement. > I don't agree we should make operation and data resources the same = media type. > It is useful in implementation to tell POST data from POST operation = before parsing > the message-body. Parsing and resolving the RequestURI should be sufficient to tell them = apart, no? Lada >=20 > Lada >=20 > > > > >=20 >=20 > Andy > =20 > > > > Andy > > > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jun 21 05:32:18 2016 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 D165B12D08F for ; Tue, 21 Jun 2016 05:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 4YbKYxuwihZn for ; Tue, 21 Jun 2016 05:32:13 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 3241B12B078 for ; Tue, 21 Jun 2016 05:32:13 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id d185so18070717vkg.0 for ; Tue, 21 Jun 2016 05:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=2sQvmtK2XloYI/bR3H4ojesaduclrdVj2RiI6PsRaMU=; b=GBD9/njE3eYJadradjhl7AKqIdT9/iNd6BwJ5xfc8Gw/kXZ3BU7O5crmKIuzdL+Vsj Hn2AHO+O4JCLmxqZfGQ42W32vo1U+3aLDMHVXF4dIaF8nsNWWnROrMb9NTceBXzd2e6y a/yaJwsggRrFXhXFrJTQbH+kxFsoS7TBeAQKfp364AhcaRT46uu58sO3Rcc8odQctJw2 9tqX7dbH9JvzPW4YKwQrT/ZuPtEl2rjtwVCkI24Obi2+dihWsYT50x+lcTl6pLtRLLPA jQ9bZ/VaBwkPvpBfeB8sKofdIupq85R7C84TiXZ/Z4SKcfnL8UaSaOQWTiFJxStoAzSK ltAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2sQvmtK2XloYI/bR3H4ojesaduclrdVj2RiI6PsRaMU=; b=OX685bgZ7g/rI7XdkGcq3qrADdPFa9z46Wwd//4dn5ruyGcGBQEpl3qxo2uEp557mX BqS8bub5OXyNMpMivN//qC5I+uXXsXM5B2Z8pwLzlr4IW3dYTY3gpWwyzMsp8D3RV5jQ vabr8kq4JnfOFf+3cbauuLtFu6AT7huC+SLBx6nvWAdWDOTG3NN5MKlIqzuKoiQmBWKl jc1EticdtX8MJ3Z6ZxF/5v3Zr64BBj+WB95Uy0WovNE2YbOGyjlIn7c60D5iUp7s9k8J dlhdbf1u5RmIpor9wkWJqc3AbQIV4egnXJ4cDZJve/rNx5IO/O5BqOB0dd0Z9hQyrN9X nZrQ== X-Gm-Message-State: ALyK8tLoI1RdZOSle98Ql1HFW164LB6TB86TkI8razpMm9d3T6F/QG/MB8STCqVmlvxcVn82kYc6gAaIANDOBg== MIME-Version: 1.0 X-Received: by 10.176.69.243 with SMTP id u106mr9155546uau.135.1466512332258; Tue, 21 Jun 2016 05:32:12 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Tue, 21 Jun 2016 05:32:12 -0700 (PDT) In-Reply-To: References: <5F59F1E8-62E8-4AE9-9E51-DB4E506C3C80@nic.cz> Date: Tue, 21 Jun 2016 05:32:12 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=94eb2c11be749f9bf10535c9021c Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 12:32:16 -0000 --94eb2c11be749f9bf10535c9021c Content-Type: text/plain; charset=UTF-8 On Tue, Jun 21, 2016 at 5:23 AM, Ladislav Lhotka wrote: > > > On 21 Jun 2016, at 14:16, Andy Bierman wrote: > > > > > > > > On Tue, Jun 21, 2016 at 12:39 AM, Ladislav Lhotka wrote: > > > > > On 21 Jun 2016, at 02:11, Andy Bierman wrote: > > > > > > Hi, > > > > > > The media type definitions in RESTCONF-13 are incorrect. > > > We cannot make subtypes for application/yang. > > > Each RESTCONF (and YANG Patch) media type has > > > to be registered. > > > > > > > > > Approach 1) hard-wired types > > > > > > > > > RESTCONF would register 10 media types and YANG Patch 4 media types > > > if we use the hardwired approach. > > > > > > application/yang-api+xml > > > application/yang-api+json > > > application/yang-datastore+xml > > > application/yang-datastore+json > > > application/yang-data+xml > > > application/yang-data+json > > > application/yang-errors+xml > > > application/yang-errors+json > > > application/yang-operation+xml > > > application/yang-operations+json > > > application/yang-patch+xml > > > application/yang-patch+json > > > application/yang-patch-status+xml > > > application/yang-patch-status+json > > > > > > Any new media types would need to be registered. > > > No usage of the restconf-media-type is possible besides > > > this list of media types for RESTCONF and YANG Patch > > > without additional registrations. > > > > > > Approach 2) generic types with a parameter > > > > > > A parameter approach would allow YANG to be used to define any > > > message content schema. E.g., a mandatory "type" parameter > > > that specifies the module and name of the restconf-media-type. > > > > > > Only 2 media type need to be registered for every media-type > > > that could ever be specified (SDO or vendor) > > > > > > application/yang-data-xml;type=: > > > application/yang-data-json;type=: > > > > > > application/yang-data-xml;type=ietf-restconf:api > > > application/yang-data-json;type=ietf-restconf:api > > > application/yang-data-xml;type=ietf-restconf:datastore > > > application/yang-data-json;type=ietf-restconf:datastore > > > application/yang-data-xml;type=ietf-restconf:data > > > application/yang-data-json;type=ietf-restconf:data > > > application/yang-data-xml;type=ietf-restconf:errors > > > application/yang-data-json;type=ietf-restconf:errors > > > application/yang-data-xml;type=ietf-restconf:operation > > > application/yang-data-json;type=ietf-restconf:operation > > > application/yang-data-xml;type=ietf-yang-patch:yang-patch > > > application/yang-data-json;type=ietf-yang-patch:yang-patch > > > application/yang-data-xml;type=ietf-yang-patch:yang-patch-status > > > application/yang-data-json;type=ietf-yang-patch:yang-patch-status > > > > > > > > > If you have a preference how this issue is resolved, send comments. > > > > I prefer #1, as media types aren't supposed to carry schema information > (and we do have it elsewhere). One thing to consider though is to reduce > the number of media types. For example, it's IMO not necessary to have > separate media types "application/yang-data" and > "application/yang-operation" because they can be easily discriminated via > the URI. > > > > > > > > I think #1 is simpler to implement. > > I don't agree we should make operation and data resources the same media > type. > > It is useful in implementation to tell POST data from POST operation > before parsing > > the message-body. > > Parsing and resolving the RequestURI should be sufficient to tell them > apart, no? > > no... container foo { container input { leaf X { type string; } } action bar { input { leaf X { type string; } } } } POST /restconf/data/foo { "input" : { "X" : "so is this an invocation of action bar or a creation of container input?" } } What problem are you solving by combining them? > Lada > Andy > > > > > Lada > > > > > > > > > > > > > > Andy > > > > > > > > Andy > > > > > > > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --94eb2c11be749f9bf10535c9021c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 21, 2016 at 5:23 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 21 Jun 2016, at 14:16, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Tue, Jun 21, 2016 at 12:39 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 21 Jun 2016, at 02:11, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > Hi,
> >
> > The media type definitions in RESTCONF-13 are incorrect.
> > We cannot make subtypes for application/yang.
> > Each RESTCONF (and YANG Patch) media type has
> > to be registered.
> >
> >
> > Approach 1) hard-wired types
> >
> >
> > RESTCONF would register 10 media types and YANG Patch 4 media typ= es
> > if we use the hardwired approach.
> >
> >=C2=A0 =C2=A0 application/yang-api+xml
> >=C2=A0 =C2=A0 application/yang-api+json
> >=C2=A0 =C2=A0 application/yang-datastore+xml
> >=C2=A0 =C2=A0 application/yang-datastore+json
> >=C2=A0 =C2=A0 application/yang-data+xml
> >=C2=A0 =C2=A0 application/yang-data+json
> >=C2=A0 =C2=A0 application/yang-errors+xml
> >=C2=A0 =C2=A0 application/yang-errors+json
> >=C2=A0 =C2=A0 application/yang-operation+xml
> >=C2=A0 =C2=A0 application/yang-operations+json
> >=C2=A0 =C2=A0 application/yang-patch+xml
> >=C2=A0 =C2=A0 application/yang-patch+json
> >=C2=A0 =C2=A0 application/yang-patch-status+xml
> >=C2=A0 =C2=A0 application/yang-patch-status+json
> >
> > Any new media types would need to be registered.
> > No usage of the restconf-media-type is possible besides
> > this list of media types for RESTCONF and YANG Patch
> > without additional registrations.
> >
> > Approach 2) generic types with a parameter
> >
> > A parameter approach would allow YANG to be used to define any > > message content schema.=C2=A0 E.g., a mandatory "type" = parameter
> > that specifies the module and name of the restconf-media-type. > >
> > Only 2 media type need to be registered for every media-type
> > that could ever be specified (SDO or vendor)
> >
> >=C2=A0 =C2=A0 application/yang-data-xml;type=3D<module>:<= name>
> >=C2=A0 =C2=A0 application/yang-data-json;type=3D<module>:<= ;name>
> >
> >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-restconf:api > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-restconf:api<= br> > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-restconf:datas= tore
> >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-restconf:data= store
> >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-restconf:data<= br> > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-restconf:data=
> >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-restconf:error= s
> >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-restconf:erro= rs
> >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-restconf:opera= tion
> >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-restconf:oper= ation
> >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-yang-patch:yan= g-patch
> >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-yang-patch:ya= ng-patch
> >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-yang-patch:yan= g-patch-status
> >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-yang-patch:ya= ng-patch-status
> >
> >
> > If you have a preference how this issue is resolved, send comment= s.
>
> I prefer #1, as media types aren't supposed to carry schema inform= ation (and we do have it elsewhere). One thing to consider though is to red= uce the number of media types. For example, it's IMO not necessary to h= ave separate media types "application/yang-data" and "applic= ation/yang-operation" because they can be easily discriminated via the= URI.
>
>
>
> I think #1 is simpler to implement.
> I don't agree we should make operation and data resources the same= media type.
> It is useful in implementation to tell POST data from POST operation b= efore parsing
> the message-body.

Parsing and resolving the RequestURI should be sufficient to tell them apar= t, no?


no...


container foo {
=C2=A0 =C2=A0container input {
= =C2=A0 =C2=A0 =C2=A0 leaf X { type string; }
=C2=A0 =C2=A0}
=
=C2=A0 =C2=A0action bar {
=C2=A0 =C2=A0 =C2=A0 input {
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf X { type string; }
= =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0}


POST /restconf/data/foo

{ "input" : {
=C2=A0 =C2=A0 =C2=A0"X" := "so is this an invocation of action bar or a creation of container in= put?"
=C2=A0 =C2=A0}
}

What problem are you solving by combining them?

=
=C2=A0
Lada


Andy
=C2= =A0

>
> Lada
>
> >
> >
>
>
> Andy
>
> >
> > Andy
> >
> >
> >
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf=
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--94eb2c11be749f9bf10535c9021c-- From nobody Tue Jun 21 05:35:28 2016 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 043E3128874 for ; Tue, 21 Jun 2016 05:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 AjDJ9cVUIYnY for ; Tue, 21 Jun 2016 05:35:20 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 2644512B008 for ; Tue, 21 Jun 2016 05:35:20 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id j2so18133437vkg.2 for ; Tue, 21 Jun 2016 05:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=JqPCoD9swN5nsTcRDbuviGOc7holZbCA7y6wAe4TfWM=; b=af2H2kMZMRnaaGFsGq4qaZpEaWMp917CJaWlTyGe4jkR17z4QBxlc4ibQp+OarYWfc MqgEznn0udu+qxwwMn3SiPltKFDtT2HHcte64K0eNR4PQFtSKrC8MuR7fNy2xlTJXiNO 2uYkiOuk7eyBS6jsmclS6l9JXp7CPX2LD6p0d7gZFqT9c9AdEDAJ2QfsUpCxeWy6gcPM ALTkAVKEQK9efCPYa/BdX5xIPt8F7+gtjHKC8Ie2BX6hjVkaBJRsGkQI12r9d5Ro6i/C VYsH4x6yNVavB/eX5J0BaEfMD5zA+jaA+e6rtiYHAKQEOjpLzzKIlO8OVZKw8FE91J5c L8bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=JqPCoD9swN5nsTcRDbuviGOc7holZbCA7y6wAe4TfWM=; b=cmjhJFpRCb23BdI8myHYnYRBQHgV8TlQdMJqnHo7jxzb7BqAQSeWb/JfMYyYOWUBlh uU0kbgKBQhBVBiQ9GG1/mbYmZzo/8SYhihzISu+b7pXxBtT/lRY+oGrMRu/F4bx4gce7 Vlbt1+Q9PRTeG6WjBBIapqnkFXFQ//yUTfQO6VP41sMf7NtsL9LADuoy2NEtSdxKQ/qh E/f1so1EPDQT6SA+RO9CBiko4xMLkT0nM2nYbIy6ja3JJ3SbuEn0JczwjQxJmkmYo+xI pfu8956VKwwZyVeqZKA0klYghOMm8xeF+JJOF9qrgzj+yvwfK/5YfaAXWZYFhcRpufxj jp/w== X-Gm-Message-State: ALyK8tImZKb/ZBF6DiDGHDcsrpBZjB7cD2J0yChSGkUYyGT8TxUSYxnzSY5BjQZgsVlJAT0NphHifBMhvlfY5A== MIME-Version: 1.0 X-Received: by 10.176.64.166 with SMTP id i35mr8957175uad.105.1466512519018; Tue, 21 Jun 2016 05:35:19 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Tue, 21 Jun 2016 05:35:18 -0700 (PDT) In-Reply-To: References: <5F59F1E8-62E8-4AE9-9E51-DB4E506C3C80@nic.cz> Date: Tue, 21 Jun 2016 05:35:18 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=94eb2c1243b2c14c8c0535c90d58 Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 12:35:27 -0000 --94eb2c1243b2c14c8c0535c90d58 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 21, 2016 at 5:32 AM, Andy Bierman wrote: > > > On Tue, Jun 21, 2016 at 5:23 AM, Ladislav Lhotka wrote: > >> >> > On 21 Jun 2016, at 14:16, Andy Bierman wrote: >> > >> > >> > >> > On Tue, Jun 21, 2016 at 12:39 AM, Ladislav Lhotka >> wrote: >> > >> > > On 21 Jun 2016, at 02:11, Andy Bierman wrote: >> > > >> > > Hi, >> > > >> > > The media type definitions in RESTCONF-13 are incorrect. >> > > We cannot make subtypes for application/yang. >> > > Each RESTCONF (and YANG Patch) media type has >> > > to be registered. >> > > >> > > >> > > Approach 1) hard-wired types >> > > >> > > >> > > RESTCONF would register 10 media types and YANG Patch 4 media types >> > > if we use the hardwired approach. >> > > >> > > application/yang-api+xml >> > > application/yang-api+json >> > > application/yang-datastore+xml >> > > application/yang-datastore+json >> > > application/yang-data+xml >> > > application/yang-data+json >> > > application/yang-errors+xml >> > > application/yang-errors+json >> > > application/yang-operation+xml >> > > application/yang-operations+json >> > > application/yang-patch+xml >> > > application/yang-patch+json >> > > application/yang-patch-status+xml >> > > application/yang-patch-status+json >> > > >> > > Any new media types would need to be registered. >> > > No usage of the restconf-media-type is possible besides >> > > this list of media types for RESTCONF and YANG Patch >> > > without additional registrations. >> > > >> > > Approach 2) generic types with a parameter >> > > >> > > A parameter approach would allow YANG to be used to define any >> > > message content schema. E.g., a mandatory "type" parameter >> > > that specifies the module and name of the restconf-media-type. >> > > >> > > Only 2 media type need to be registered for every media-type >> > > that could ever be specified (SDO or vendor) >> > > >> > > application/yang-data-xml;type=: >> > > application/yang-data-json;type=: >> > > >> > > application/yang-data-xml;type=ietf-restconf:api >> > > application/yang-data-json;type=ietf-restconf:api >> > > application/yang-data-xml;type=ietf-restconf:datastore >> > > application/yang-data-json;type=ietf-restconf:datastore >> > > application/yang-data-xml;type=ietf-restconf:data >> > > application/yang-data-json;type=ietf-restconf:data >> > > application/yang-data-xml;type=ietf-restconf:errors >> > > application/yang-data-json;type=ietf-restconf:errors >> > > application/yang-data-xml;type=ietf-restconf:operation >> > > application/yang-data-json;type=ietf-restconf:operation >> > > application/yang-data-xml;type=ietf-yang-patch:yang-patch >> > > application/yang-data-json;type=ietf-yang-patch:yang-patch >> > > application/yang-data-xml;type=ietf-yang-patch:yang-patch-status >> > > application/yang-data-json;type=ietf-yang-patch:yang-patch-status >> > > >> > > >> > > If you have a preference how this issue is resolved, send comments. >> > >> > I prefer #1, as media types aren't supposed to carry schema information >> (and we do have it elsewhere). One thing to consider though is to reduce >> the number of media types. For example, it's IMO not necessary to have >> separate media types "application/yang-data" and >> "application/yang-operation" because they can be easily discriminated via >> the URI. >> > >> > >> > >> > I think #1 is simpler to implement. >> > I don't agree we should make operation and data resources the same >> media type. >> > It is useful in implementation to tell POST data from POST operation >> before parsing >> > the message-body. >> >> Parsing and resolving the RequestURI should be sufficient to tell them >> apart, no? >> >> > no... > > > container foo { > container input { > leaf X { type string; } > } > action bar { > input { > leaf X { type string; } > } > } > } > > > POST /restconf/data/foo > oops -- the action would include input in the URI POST /restconf/data/foo (data) POST /restconf/data/foo/input (operation) IMO is is still clearer to use separate media type for operations and data. > { "input" : { > "X" : "so is this an invocation of action bar or a creation of > container input?" > } > } > > > What problem are you solving by combining them? > > > >> Lada >> > > > Andy > > >> >> > >> > Lada >> > >> > > >> > > >> > >> > >> > Andy >> > >> > > >> > > Andy >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > Netconf mailing list >> > > Netconf@ietf.org >> > > https://www.ietf.org/mailman/listinfo/netconf >> > >> > -- >> > Ladislav Lhotka, CZ.NIC Labs >> > PGP Key ID: E74E8C0C >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> > --94eb2c1243b2c14c8c0535c90d58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 21, 2016 at 5:32 AM, Andy Bierman <andy@yumaworks.com= > wrote:


On Tue, Jun 21, 2016 at 5:23 AM,= Ladislav Lhotka <lhotka@nic.cz> wrote:

> On 21 Jun 2016, at 14:16, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Tue, Jun 21, 2016 at 12:39 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 21 Jun 2016, at 02:11, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > Hi,
> >
> > The media type definitions in RESTCONF-13 are incorrect.
> > We cannot make subtypes for application/yang.
> > Each RESTCONF (and YANG Patch) media type has
> > to be registered.
> >
> >
> > Approach 1) hard-wired types
> >
> >
> > RESTCONF would register 10 media types and YANG Patch 4 media typ= es
> > if we use the hardwired approach.
> >
> >=C2=A0 =C2=A0 application/yang-api+xml
> >=C2=A0 =C2=A0 application/yang-api+json
> >=C2=A0 =C2=A0 application/yang-datastore+xml
> >=C2=A0 =C2=A0 application/yang-datastore+json
> >=C2=A0 =C2=A0 application/yang-data+xml
> >=C2=A0 =C2=A0 application/yang-data+json
> >=C2=A0 =C2=A0 application/yang-errors+xml
> >=C2=A0 =C2=A0 application/yang-errors+json
> >=C2=A0 =C2=A0 application/yang-operation+xml
> >=C2=A0 =C2=A0 application/yang-operations+json
> >=C2=A0 =C2=A0 application/yang-patch+xml
> >=C2=A0 =C2=A0 application/yang-patch+json
> >=C2=A0 =C2=A0 application/yang-patch-status+xml
> >=C2=A0 =C2=A0 application/yang-patch-status+json
> >
> > Any new media types would need to be registered.
> > No usage of the restconf-media-type is possible besides
> > this list of media types for RESTCONF and YANG Patch
> > without additional registrations.
> >
> > Approach 2) generic types with a parameter
> >
> > A parameter approach would allow YANG to be used to define any > > message content schema.=C2=A0 E.g., a mandatory "type" = parameter
> > that specifies the module and name of the restconf-media-type. > >
> > Only 2 media type need to be registered for every media-type
> > that could ever be specified (SDO or vendor)
> >
> >=C2=A0 =C2=A0 application/yang-data-xml;type=3D<module>:<= name>
> >=C2=A0 =C2=A0 application/yang-data-json;type=3D<module>:<= ;name>
> >
> >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-restconf:api > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-restconf:api<= br> > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-restconf:datas= tore
> >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-restconf:data= store
> >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-restconf:data<= br> > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-restconf:data=
> >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-restconf:error= s
> >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-restconf:erro= rs
> >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-restconf:opera= tion
> >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-restconf:oper= ation
> >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-yang-patch:yan= g-patch
> >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-yang-patch:ya= ng-patch
> >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-yang-patch:yan= g-patch-status
> >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-yang-patch:ya= ng-patch-status
> >
> >
> > If you have a preference how this issue is resolved, send comment= s.
>
> I prefer #1, as media types aren't supposed to carry schema inform= ation (and we do have it elsewhere). One thing to consider though is to red= uce the number of media types. For example, it's IMO not necessary to h= ave separate media types "application/yang-data" and "applic= ation/yang-operation" because they can be easily discriminated via the= URI.
>
>
>
> I think #1 is simpler to implement.
> I don't agree we should make operation and data resources the same= media type.
> It is useful in implementation to tell POST data from POST operation b= efore parsing
> the message-body.

Parsing and resolving the RequestURI should be sufficient to tell them apar= t, no?


no...


container foo {
=C2=A0 =C2=A0container input {
= =C2=A0 =C2=A0 =C2=A0 leaf X { type string; }
=C2=A0 =C2=A0}
=
=C2=A0 =C2=A0action bar {
=C2=A0 =C2=A0 =C2=A0 input {
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf X { type string; }
= =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0}


POST /restconf/data/foo


oops -- the action woul= d include input in the URI
=C2=A0
POST /restconf/da= ta/foo =C2=A0(data)

POST /restconf/data/foo/in= put =C2=A0(operation)

IMO is is still clearer to u= se separate media type for operations and data.


{ "input" : {
= =C2=A0 =C2=A0 =C2=A0"X" : "so is this an invocation of actio= n bar or a creation of container input?"
=C2=A0 =C2=A0}
}


What problem are you solvin= g by combining them?

=C2=A0
Lada


Andy
=C2= =A0

>
> Lada
>
> >
> >
>
>
> Andy
>
> >
> > Andy
> >
> >
> >
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@iet= f.org
> > https://www.ietf.org/mailman/listinfo/netconf=
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C






--94eb2c1243b2c14c8c0535c90d58-- From nobody Tue Jun 21 05:44:23 2016 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 7082912D563 for ; Tue, 21 Jun 2016 05:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 2ObtRjFHRPfE for ; Tue, 21 Jun 2016 05:44:21 -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 7A0C812D1D3 for ; Tue, 21 Jun 2016 05:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1931; q=dns/txt; s=iport; t=1466513060; x=1467722660; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=1jWMbp9xI19aIRlJvBAG/RDABdSj8cvQxmG4r4El+kg=; b=O+CK2IEW0AVr9BYw8EoGafsKTKsaZamYEo+AeSa7SKP+ZPmBo1rGqhac dEV7eW4STzXandi1x13GsBZQKKuZDfag/K7QeFwmKiVioKIYfkzzyJKIR Wth82WwYRXHJbhAGPuhn+7YhUhijxjkNycpV+4Lz55a2OS03yh9pwJmMB I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpBABoNmlX/xbLJq1dhD+5OoQJhhcCg?= =?us-ascii?q?gABAQEBAQFmJ4RLAQEBAwE4RgsLGC5XEwgBAYgkCME+AQEBAQYBAQEBI4YngXc?= =?us-ascii?q?Igk6EKglZhQ8FmHmOLIlGhV2PeFSDcTuJOIFCAQEB?= X-IronPort-AV: E=Sophos;i="5.26,504,1459814400"; d="scan'208";a="636306461" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2016 12:44:18 +0000 Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u5LCiID3018542 for ; Tue, 21 Jun 2016 12:44:18 GMT To: netconf@ietf.org References: <7a655427-0625-744a-1e5e-7e07aea4e11c@hq.sk> <20160621094628.GA41804@elstar.local> <20160621.122117.332960881532664788.mbj@tail-f.com> <34773154-f55f-9085-35fb-13e44d5b535a@cisco.com> <20160621121914.GA42059@elstar.local> From: Robert Wilton Message-ID: <35929fa6-fa32-9406-fc2c-47c83ed02307@cisco.com> Date: Tue, 21 Jun 2016 13:44:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160621121914.GA42059@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 12:44:22 -0000 On 21/06/2016 13:19, Juergen Schoenwaelder wrote: > On Tue, Jun 21, 2016 at 11:50:38AM +0100, Robert Wilton wrote: >> This is one of the reasons why I prefer having only 2 datastores (i.e. >> intended + operational state (inc applied config)) rather than the 3 >> described above. > I fail to see why the # of datastores matters. Because if you regard that for an existing server intended=applied, and ignore system created config, then for the definition that I propose: running config + config=false nodes == operational state ds. As such, I think that it should be possible to find a viable upgrade path from an existing NETCONF/RESTCONF server to the new datastore definitions. I believe that with the definition of the operational-state ds that you have proposed, this is not true, i.e. running config + config=false nodes != operational state ds. I might be missing something, but it looks like upgrading to NETCONF/RESTCONF to the definition that you propose is significantly more work because the operational state ds doesn't necessarily reflect the actual running configuration at all (or certainly not in a way that a client can even programmatically rely on). > If the 'content' > parameter really just filters by the YANG config true|false property, > then using config true data nodes to also report state in a different > datastore won't work, regardless what the number is. > >> The content=all operation can then return the contents of the operational >> state datastore which happens to include the applied configuration, and is >> also the same as what would be returned from a RESTCONF device today. > But this is not how the parameter is defined. Yes, thanks. But RESTCONF GET requests could be refined to always be against the operational-state datastore in which case the filtering would work exactly as specified. Thanks, Rob > > /js > From nobody Tue Jun 21 05:46:38 2016 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 69F8512D5FB for ; Tue, 21 Jun 2016 05:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 dCGsDmIJB44S for ; Tue, 21 Jun 2016 05:46:36 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C7FF912D5DB for ; Tue, 21 Jun 2016 05:46:35 -0700 (PDT) Received: from localhost (unknown [173.38.220.44]) by mail.tail-f.com (Postfix) with ESMTPSA id E69A11AE0198; Tue, 21 Jun 2016 14:46:34 +0200 (CEST) Date: Tue, 21 Jun 2016 14:46:59 +0200 (CEST) Message-Id: <20160621.144659.998339534128110444.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <97fe11c4-027c-9835-00ed-518ce3b1827e@cisco.com> References: <34773154-f55f-9085-35fb-13e44d5b535a@cisco.com> <20160621.125931.365562743647782974.mbj@tail-f.com> <97fe11c4-027c-9835-00ed-518ce3b1827e@cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 12:46:37 -0000 Robert Wilton wrote: > > > On 21/06/2016 11:59, Martin Bjorklund wrote: > > Robert Wilton wrote: > >> > >> On 21/06/2016 11:21, Martin Bjorklund wrote: > >>> Juergen Schoenwaelder wrote: > >>>> On Tue, Jun 21, 2016 at 10:08:13AM +0200, Robert Varga wrote: > >>>>> Hello, > >>>>> > >>>>> Reading through section 4.8.1 and D.3.1, it seems that in case of > >>>>> content=all there is no guidance what the server should do if it > >>>>> encounters a leaf which has different values in config and oper. > >>>>> > >>>>> Would this constitute an error, or should one of them take precedence? > >>>>> > >>>> The notion of "all" may prove problematic depending on how we move > >>>> forward with multiple datastore. However, I think the most pressing > >>>> issue to address before RESTCONF goes to the RFC editor is to move the > >>>> default of the content query parameter back to 'config' instead of > >>>> 'all'. Having the content parameter default to 'all' makes it hard to > >>>> possibly deprecate 'all' in the future. > >>> I don't think this change would help. Suppose we introduce > >>> intended/applied/operational-state as proposed in your draft. Config > >>> true nodes would then exist in all three. So which one would be > >>> returned w/o any 'content' param (or 'content=config')? > >>> > >>> IMO the problem is that 'data' contains *combined* config and state, > >>> which doesn't really work if the same schema nodes can exist in both > >>> config and state. > >> This is one of the reasons why I prefer having only 2 datastores > >> (i.e. intended + operational state (inc applied config)) rather than > >> the 3 described above. > >> > >> The content=all operation can then return the contents of the > >> operational state datastore > > This would be fine, but this is NOT how the content parameter is > > defined today. Hmmm, maybe it is not clear what the "content" > > parameter actually does. It says: > > > > | config | Return only configuration descendant data nodes | > > | nonconfig | Return only non-configuration descendant data nodes | > > | all | Return all descendant data nodes | > > > > Whatever this means, it seems to imply that: > > > > GET(content=config) + GET(content=nonconfig) = GET(content=all) > > > > It is just a simple filter to select one subset of all data. > > > > > > This means that the "content" parameter does not affect the source of > > the data; the source is still the "combination of config ans state". > OK, so perhaps refine/redefine that GET requests on "/restconf/data" > are always against the operational state (inc applied config) > datastore. I.e. with the content=config filter you just get > applied-config. So how would you read what you call "persistent config db" below? > POST/POST/etc requests would write to what I have labelled as the > persistent config ds. Semantically, this doesn't seem to be that > different to writing to the candidate ds under the covers if necessary > that RESTCONF does today. /martin > > I appreciate that this is not how this is defined at the moment, but > this would still seem to be backwards compatible refinement. > > Thanks, > Rob > > > > > >> which happens to include the applied > >> configuration, and is also the same as what would be returned from a > >> RESTCONF device today. > >> > >> Full clean access to the separate datastores will require datastore > >> awareness in the REST API, but I can imagine that for a lot of simple > >> devices a simple combined view is useful. > > This would be ok. > > > > > > /martin > > . > > > From nobody Tue Jun 21 05:49:27 2016 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 BEA9012D5FB for ; Tue, 21 Jun 2016 05:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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, RP_MATCHES_RCVD=-1.426] 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 H8f3X0vx_wzp for ; Tue, 21 Jun 2016 05:49:24 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02E1012D5DB for ; Tue, 21 Jun 2016 05:49:24 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:1d26:3c9:e0f4:a092] (unknown [IPv6:2001:718:1a02:1:1d26:3c9:e0f4:a092]) by mail.nic.cz (Postfix) with ESMTPSA id 9AD4761699; Tue, 21 Jun 2016 14:49:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1466513362; bh=FzmEw0tLY6uSO/tZCH/rtVhWpRLOcJEquZDMxforLhA=; h=From:Date:To; b=HPtQnewFhmCCKpQpf2K+QPPSn8zVo4CSeEqcd6qhC6CJuOndXl8dzRaLtSQxgWkBe y8po/KhNMoORZNhsX99yBxzeMN59AzaHHbBTAnJVaXcKbFUViHcRCYWvOhFe4t9fKs g9ScyP5KlCakfNXYaz5WfvbM6+eqCKuXMmUIRbyU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 21 Jun 2016 14:49:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <326DE836-9AD6-4132-9F7C-938BAA729D71@nic.cz> References: <5F59F1E8-62E8-4AE9-9E51-DB4E506C3C80@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 12:49:26 -0000 > On 21 Jun 2016, at 14:32, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Jun 21, 2016 at 5:23 AM, Ladislav Lhotka = wrote: >=20 > > On 21 Jun 2016, at 14:16, Andy Bierman wrote: > > > > > > > > On Tue, Jun 21, 2016 at 12:39 AM, Ladislav Lhotka = wrote: > > > > > On 21 Jun 2016, at 02:11, Andy Bierman wrote: > > > > > > Hi, > > > > > > The media type definitions in RESTCONF-13 are incorrect. > > > We cannot make subtypes for application/yang. > > > Each RESTCONF (and YANG Patch) media type has > > > to be registered. > > > > > > > > > Approach 1) hard-wired types > > > > > > > > > RESTCONF would register 10 media types and YANG Patch 4 media = types > > > if we use the hardwired approach. > > > > > > application/yang-api+xml > > > application/yang-api+json > > > application/yang-datastore+xml > > > application/yang-datastore+json > > > application/yang-data+xml > > > application/yang-data+json > > > application/yang-errors+xml > > > application/yang-errors+json > > > application/yang-operation+xml > > > application/yang-operations+json > > > application/yang-patch+xml > > > application/yang-patch+json > > > application/yang-patch-status+xml > > > application/yang-patch-status+json > > > > > > Any new media types would need to be registered. > > > No usage of the restconf-media-type is possible besides > > > this list of media types for RESTCONF and YANG Patch > > > without additional registrations. > > > > > > Approach 2) generic types with a parameter > > > > > > A parameter approach would allow YANG to be used to define any > > > message content schema. E.g., a mandatory "type" parameter > > > that specifies the module and name of the restconf-media-type. > > > > > > Only 2 media type need to be registered for every media-type > > > that could ever be specified (SDO or vendor) > > > > > > application/yang-data-xml;type=3D: > > > application/yang-data-json;type=3D: > > > > > > application/yang-data-xml;type=3Dietf-restconf:api > > > application/yang-data-json;type=3Dietf-restconf:api > > > application/yang-data-xml;type=3Dietf-restconf:datastore > > > application/yang-data-json;type=3Dietf-restconf:datastore > > > application/yang-data-xml;type=3Dietf-restconf:data > > > application/yang-data-json;type=3Dietf-restconf:data > > > application/yang-data-xml;type=3Dietf-restconf:errors > > > application/yang-data-json;type=3Dietf-restconf:errors > > > application/yang-data-xml;type=3Dietf-restconf:operation > > > application/yang-data-json;type=3Dietf-restconf:operation > > > application/yang-data-xml;type=3Dietf-yang-patch:yang-patch > > > application/yang-data-json;type=3Dietf-yang-patch:yang-patch > > > = application/yang-data-xml;type=3Dietf-yang-patch:yang-patch-status > > > = application/yang-data-json;type=3Dietf-yang-patch:yang-patch-status > > > > > > > > > If you have a preference how this issue is resolved, send = comments. > > > > I prefer #1, as media types aren't supposed to carry schema = information (and we do have it elsewhere). One thing to consider though = is to reduce the number of media types. For example, it's IMO not = necessary to have separate media types "application/yang-data" and = "application/yang-operation" because they can be easily discriminated = via the URI. > > > > > > > > I think #1 is simpler to implement. > > I don't agree we should make operation and data resources the same = media type. > > It is useful in implementation to tell POST data from POST operation = before parsing > > the message-body. >=20 > Parsing and resolving the RequestURI should be sufficient to tell them = apart, no? >=20 >=20 > no... >=20 >=20 > container foo { > container input { > leaf X { type string; } > } > action bar { > input { > leaf X { type string; } > } > } > } >=20 >=20 > POST /restconf/data/foo >=20 > { "input" : { > "X" : "so is this an invocation of action bar or a creation of = container input?" > } > } Shouldn't the action be invoked with POST /restconf/data/foo/bar Section 3.6 says An action is invoked as: POST {+restconf}/data// >=20 >=20 > What problem are you solving by combining them? Media types should not be multiplied unnecessarily. Lada >=20 > =20 > Lada >=20 >=20 > Andy > =20 >=20 > > > > Lada > > > > > > > > > > > > > > Andy > > > > > > > > Andy > > > > > > > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jun 21 05:49:41 2016 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 7A95112D5DB for ; Tue, 21 Jun 2016 05:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 Q07FbrBr5G-a for ; Tue, 21 Jun 2016 05:49:38 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::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 A7EA912D7B8 for ; Tue, 21 Jun 2016 05:49:33 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id t129so18666054vka.1 for ; Tue, 21 Jun 2016 05:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=mDkJ0Ht+qlrBsVgX32ZSGQdiiurbSnrqevW13ssITf0=; b=089b8hJ3wBbqgX6bLBlBvS+vsrRHyEooTU87CM2JksiNN1Sz3D8BqngcQsEgM2fOjj 5ZRPzTWvJ1cAGkvRHAizUzU5nAs5+2tQC7ucWJoXIRP+6oa+T0dEUsBNklJMYJeqIQvZ Vwl9wKhqKMJaWv+WZQssHuDHUrCDSIz+RYpvCt6oDymTsbp34A8QfEpwmrS3pUCFulkD IDCdiRJXJ4rQkm79Q85wKBqS0GPd6/KR21wBpRXL/V/joF7BAZvqkNRt5fbskKIpO4Fr i7rvq8Oiy9LmkpgL8U9oouaMMsLHr8RVi+UxyDZBzRTJ1aaEU+j0d1cyXUfBmkFfRDfA h0Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=mDkJ0Ht+qlrBsVgX32ZSGQdiiurbSnrqevW13ssITf0=; b=cb+JzR/3crJxkIyFdGVYpelVB0tvV0qrdlor5C7XsI8dcfznlzZtVuNKWGxsSwu3xU gONqO0EpH/TYCA8RBg7eYm+f46HzQrsul+i9ZicWz0aT2iYrRdW8Tc5V5DmhbiwBC/CC 9IqoN+VFpF2vhra/ixwFpKMlU4Xor479TpMhwpIGlZWc7ushdFjttxsgWPlkkW0go6zk PudCpnydrTOswzZYAUP3iuDuBM6CZuzQj50PmQYqk1DPRB9ZfFtBhXwKD5LqM7dYwCOA gjICIgQ4HSLAv+51Cw/4wO6cHfATfgiSyM4ZP/7NvRkMx9NKSehHtYwLv6MgJBp33eLa 1SwA== X-Gm-Message-State: ALyK8tLjqeF3gbT2sSG3s2pl4FOLw+ZL7nBFyv7CABzfLYAM8yU66MRE//3rBMc4RdnQzgVn6rMFM0cpHvW9Vw== MIME-Version: 1.0 X-Received: by 10.159.55.204 with SMTP id q70mr7613327uaq.16.1466513372840; Tue, 21 Jun 2016 05:49:32 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Tue, 21 Jun 2016 05:49:32 -0700 (PDT) In-Reply-To: References: <5F59F1E8-62E8-4AE9-9E51-DB4E506C3C80@nic.cz> Date: Tue, 21 Jun 2016 05:49:32 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=94eb2c04cbfaa5acfe0535c94089 Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 12:49:39 -0000 --94eb2c04cbfaa5acfe0535c94089 Content-Type: text/plain; charset=UTF-8 > ... >> no... >> >> >> container foo { >> container input { >> leaf X { type string; } >> } >> action bar { >> input { >> leaf X { type string; } >> } >> } >> } >> >> >> POST /restconf/data/foo >> > > > oops -- the action would include input in the URI > > Andy > POST /restconf/data/foo (data) > > POST /restconf/data/foo/input (operation) > > I was right the first time. The URI does not contain "input", just the message. So the media type is needed to distinguish actions from data. > IMO is is still clearer to use separate media type for operations and data. > > > >> { "input" : { >> "X" : "so is this an invocation of action bar or a creation of >> container input?" >> } >> } >> >> >> What problem are you solving by combining them? >> >> >> >>> Lada >>> >> >> >> Andy >> >> >>> >>> > >>> > Lada >>> > >>> > > >>> > > >>> > >>> > >>> > Andy >>> > >>> > > >>> > > Andy >>> > > >>> > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > Netconf mailing list >>> > > Netconf@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/netconf >>> > >>> > -- >>> > Ladislav Lhotka, CZ.NIC Labs >>> > PGP Key ID: E74E8C0C >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> >> > --94eb2c04cbfaa5acfe0535c94089 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
<= div class=3D"gmail_quote">
...
no...


container foo {
=C2=A0 =C2=A0container input {
=C2=A0 =C2=A0 =C2=A0 leaf X { type string; }
=C2=A0 =C2= =A0}
=C2=A0 =C2=A0action bar {
=C2=A0 =C2=A0 =C2=A0 inp= ut {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf X { type string; }
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0}<= /div>


POST /restconf/data/foo
=


oops -- the act= ion would include input in the URI
=C2=A0



Andy
=C2=A0
POST /restconf/data/foo= =C2=A0(data)

POST /restconf/data/foo/input = =C2=A0(operation)

<= br>

I was right the first time.
The URI = does not contain "input", just the message.
So the medi= a type is needed to distinguish actions from data.


=C2=A0
IMO is is still cl= earer to use separate media type for operations and data.



{ "input" : {<= /div>
=C2=A0 =C2=A0 =C2=A0"X" : "so is this an invocatio= n of action bar or a creation of container input?"
=C2=A0 = =C2=A0}
}


What problem ar= e you solving by combining them?

=C2=A0
Lada


Andy
=C2= =A0

>
> Lada
>
> >
> >
>
>
> Andy
>
> >
> > Andy
> >
> >
> >
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@iet= f.org
> > https://www.ietf.org/mailman/listinfo/netconf=
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C







--94eb2c04cbfaa5acfe0535c94089-- From nobody Tue Jun 21 05:55:13 2016 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 2A26E128B44 for ; Tue, 21 Jun 2016 05:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 eOu4CoIIG7QA for ; Tue, 21 Jun 2016 05:55:10 -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 D7D2A126B6D for ; Tue, 21 Jun 2016 05:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4512; q=dns/txt; s=iport; t=1466513710; x=1467723310; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=LntgoGqe4yjROJe0squyQYtyd0OQ9TylDAKgmmKD+jQ=; b=DVYn2DS6JYBISzIU3hSIrt8PBR0NvLSlTDPGgJ0h33EJJ1nUmx2wq3Az H9z7tua9j4mozqbu1xVSBU/KuaAym807Udb6ytNkCRchWjiiEGan4TWex Vi/HTSszfY3ecx9UqsBGyES3Ns56mxM/3XyDenpOkaGPxIMxGySfKIqpq E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBACIOGlX/xbLJq1dhD9SuGiECYYXA?= =?us-ascii?q?oIAAQEBAQEBZieETAEBBDhBEAsOAgguVwYNBgIBAYgswUIBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEfhieBd4JWhCqFcQWYeY4sgWmHXSOFOo94VINxOzKKSAEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,504,1459814400"; d="scan'208";a="636306615" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2016 12:55:08 +0000 Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u5LCt7TN025373; Tue, 21 Jun 2016 12:55:07 GMT To: Martin Bjorklund References: <34773154-f55f-9085-35fb-13e44d5b535a@cisco.com> <20160621.125931.365562743647782974.mbj@tail-f.com> <97fe11c4-027c-9835-00ed-518ce3b1827e@cisco.com> <20160621.144659.998339534128110444.mbj@tail-f.com> From: Robert Wilton Message-ID: <1f8ace67-706d-c1f9-b56e-2caaa7572b45@cisco.com> Date: Tue, 21 Jun 2016 13:55:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160621.144659.998339534128110444.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 12:55:12 -0000 On 21/06/2016 13:46, Martin Bjorklund wrote: > Robert Wilton wrote: >> >> On 21/06/2016 11:59, Martin Bjorklund wrote: >>> Robert Wilton wrote: >>>> On 21/06/2016 11:21, Martin Bjorklund wrote: >>>>> Juergen Schoenwaelder wrote: >>>>>> On Tue, Jun 21, 2016 at 10:08:13AM +0200, Robert Varga wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Reading through section 4.8.1 and D.3.1, it seems that in case of >>>>>>> content=all there is no guidance what the server should do if it >>>>>>> encounters a leaf which has different values in config and oper. >>>>>>> >>>>>>> Would this constitute an error, or should one of them take precedence? >>>>>>> >>>>>> The notion of "all" may prove problematic depending on how we move >>>>>> forward with multiple datastore. However, I think the most pressing >>>>>> issue to address before RESTCONF goes to the RFC editor is to move the >>>>>> default of the content query parameter back to 'config' instead of >>>>>> 'all'. Having the content parameter default to 'all' makes it hard to >>>>>> possibly deprecate 'all' in the future. >>>>> I don't think this change would help. Suppose we introduce >>>>> intended/applied/operational-state as proposed in your draft. Config >>>>> true nodes would then exist in all three. So which one would be >>>>> returned w/o any 'content' param (or 'content=config')? >>>>> >>>>> IMO the problem is that 'data' contains *combined* config and state, >>>>> which doesn't really work if the same schema nodes can exist in both >>>>> config and state. >>>> This is one of the reasons why I prefer having only 2 datastores >>>> (i.e. intended + operational state (inc applied config)) rather than >>>> the 3 described above. >>>> >>>> The content=all operation can then return the contents of the >>>> operational state datastore >>> This would be fine, but this is NOT how the content parameter is >>> defined today. Hmmm, maybe it is not clear what the "content" >>> parameter actually does. It says: >>> >>> | config | Return only configuration descendant data nodes | >>> | nonconfig | Return only non-configuration descendant data nodes | >>> | all | Return all descendant data nodes | >>> >>> Whatever this means, it seems to imply that: >>> >>> GET(content=config) + GET(content=nonconfig) = GET(content=all) >>> >>> It is just a simple filter to select one subset of all data. >>> >>> >>> This means that the "content" parameter does not affect the source of >>> the data; the source is still the "combination of config ans state". >> OK, so perhaps refine/redefine that GET requests on "/restconf/data" >> are always against the operational state (inc applied config) >> datastore. I.e. with the content=config filter you just get >> applied-config. > So how would you read what you call "persistent config db" below? Via a GET operation on new datastore specific RESTCONF path. E.g. "/restconf/ds/persistent/" I would also allow, and recommend, POST/PUT requests on "/restconf/ds/persistent/". POST/PUT requests on "/restconf/data" would be handled by the server as if the request had been made on "/restconf/ds/persistent/". Similarly, a datastore specific path would be defined for the opstate datastore (e.g. /restconf/ds/opstate/): - POST/PUT requests to this datastore are not allowed (it is read-only) - GET requests to "/restconf/data" would be handled by the server as if the request had been made on "/restconf/ds/opstate/" instead. Thanks, Rob > > >> POST/POST/etc requests would write to what I have labelled as the >> persistent config ds. Semantically, this doesn't seem to be that >> different to writing to the candidate ds under the covers if necessary >> that RESTCONF does today. > > /martin > > >> I appreciate that this is not how this is defined at the moment, but >> this would still seem to be backwards compatible refinement. >> >> Thanks, >> Rob >> >> >>>> which happens to include the applied >>>> configuration, and is also the same as what would be returned from a >>>> RESTCONF device today. >>>> >>>> Full clean access to the separate datastores will require datastore >>>> awareness in the REST API, but I can imagine that for a lot of simple >>>> devices a simple combined view is useful. >>> This would be ok. >>> >>> >>> /martin >>> . >>> > . > From nobody Tue Jun 21 05:55:58 2016 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 1B76E126B6D for ; Tue, 21 Jun 2016 05:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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, RP_MATCHES_RCVD=-1.426] 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 ZlXAXQmy2v9G for ; Tue, 21 Jun 2016 05:55:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 165F2128B44 for ; Tue, 21 Jun 2016 05:55:55 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:1d26:3c9:e0f4:a092] (unknown [IPv6:2001:718:1a02:1:1d26:3c9:e0f4:a092]) by mail.nic.cz (Postfix) with ESMTPSA id A0BE661770; Tue, 21 Jun 2016 14:55:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1466513753; bh=1BD646zRh2R42Xv+7Va1slqR2jvOuA/yODzqpGKbiU4=; h=From:Date:To; b=xXECrNGOM0YJ+trXxRW2SY45Arltm8iU9GBInmvgXfKZyTLGZV3ZXwOMBR8I1hQm3 mi8AxA6x7jSUiBoTi1iP1dj8pFjbHBf4YEk9vlrbCl0HP/vzJQKEl7DReeoNA1wkiG eBATYs2di5eXIUXKa1pymwS/hPHwFSTrJm4zjow4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 21 Jun 2016 14:56:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <453998DA-22C5-4A92-B415-4F8A96011529@nic.cz> References: <5F59F1E8-62E8-4AE9-9E51-DB4E506C3C80@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 12:55:57 -0000 > On 21 Jun 2016, at 14:49, Andy Bierman wrote: >=20 >=20 > ... > no... >=20 >=20 > container foo { > container input { > leaf X { type string; } > } > action bar { > input { > leaf X { type string; } > } > } > } >=20 >=20 > POST /restconf/data/foo >=20 >=20 > oops -- the action would include input in the URI > =20 >=20 >=20 >=20 > Andy > =20 > POST /restconf/data/foo (data) >=20 > POST /restconf/data/foo/input (operation) >=20 >=20 >=20 > I was right the first time. > The URI does not contain "input", just the message. IMO it should contain the action name. Lada > So the media type is needed to distinguish actions from data. >=20 >=20 > =20 > IMO is is still clearer to use separate media type for operations and = data. >=20 >=20 >=20 > { "input" : { > "X" : "so is this an invocation of action bar or a creation of = container input?" > } > } >=20 >=20 > What problem are you solving by combining them? >=20 > =20 > Lada >=20 >=20 > Andy > =20 >=20 > > > > Lada > > > > > > > > > > > > > > Andy > > > > > > > > Andy > > > > > > > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jun 21 05:57:03 2016 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 E25FC128B44 for ; Tue, 21 Jun 2016 05:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 kJEd5nVbohvQ for ; Tue, 21 Jun 2016 05:57:00 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::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 4E781126B6D for ; Tue, 21 Jun 2016 05:57:00 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id j2so18867288vkg.2 for ; Tue, 21 Jun 2016 05:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=MbUNZ377p2CW4ZwrTe+D5V5jgSTLjMAqU2kyKLfHuQg=; b=si09lDZtWaUfkR/iTLQAd/tY7LL0CkNQQP82FPLmZcTtsj4InXZPzS7DdUIPpWCvbi UaKTGtMoE1WGWU7gaiNQiybgl/4in9oqVw4zZyEXsEgpEKfZGB+b/4Llsh49yS6n8A0m NyciASBHhfVSk3UDgO92GJAdSno0FsnMnjEJo3SN/FZxRHWXtlV6phQxQHgKtfbXXHrX ViwP7bmnMq7dQ2yM4jBH70qaHtxVj4YUzF021I4ZwubTafclJZsrrFSkzIOEQsazTfyS CEZ0SQYIXorIMN9irARoBd3S3EwLSLmK//zLciWYoRq40D5yq3vJwmLWTfbStuHHVFaL ppKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=MbUNZ377p2CW4ZwrTe+D5V5jgSTLjMAqU2kyKLfHuQg=; b=INVs/5dDIcCV9mIEiYOSOYtyCX6kZQ56u27BXMWWDL7GmWNLFgXvsXEPWLFVu4gc2H uHtXFQZrSNyF0npytJ8h59SgnRyorGSLMqWgnc2wodCc0nwWLtxMEb88id4suaaOWqcn eK4bL17KJQikSuI62Lo5GiYl8m/fU+ADU3uDRCPQqD99+OB7aTQm5rd3yijIA4KAGJ6T ML2W/3IAysBvxt3QvF24pV1waMgWUQkGkSBAe+P3/dIRsOaRA1tsV0x8C+rxxxkFIdib zuFNaSk6utYh8iDx/MhfnPQCbK8LIxrTc1yANfBBwTwWcikCm3jRiC8c4HdJTDMPvO9p 4atA== X-Gm-Message-State: ALyK8tKeK0qou/r6+h/VkMjon6euxxF4jalSMkXCTct70QfPuh6HrvoGCubUBobDUEFpSuius9LP8xRWjarpLA== MIME-Version: 1.0 X-Received: by 10.176.64.166 with SMTP id i35mr9001332uad.105.1466513819387; Tue, 21 Jun 2016 05:56:59 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Tue, 21 Jun 2016 05:56:59 -0700 (PDT) In-Reply-To: <326DE836-9AD6-4132-9F7C-938BAA729D71@nic.cz> References: <5F59F1E8-62E8-4AE9-9E51-DB4E506C3C80@nic.cz> <326DE836-9AD6-4132-9F7C-938BAA729D71@nic.cz> Date: Tue, 21 Jun 2016 05:56:59 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=94eb2c1243b2435dad0535c95b35 Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 12:57:02 -0000 --94eb2c1243b2435dad0535c95b35 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 21, 2016 at 5:49 AM, Ladislav Lhotka wrote: > > > On 21 Jun 2016, at 14:32, Andy Bierman wrote: > > > > > > > > On Tue, Jun 21, 2016 at 5:23 AM, Ladislav Lhotka wrote: > > > > > On 21 Jun 2016, at 14:16, Andy Bierman wrote: > > > > > > > > > > > > On Tue, Jun 21, 2016 at 12:39 AM, Ladislav Lhotka > wrote: > > > > > > > On 21 Jun 2016, at 02:11, Andy Bierman wrote: > > > > > > > > Hi, > > > > > > > > The media type definitions in RESTCONF-13 are incorrect. > > > > We cannot make subtypes for application/yang. > > > > Each RESTCONF (and YANG Patch) media type has > > > > to be registered. > > > > > > > > > > > > Approach 1) hard-wired types > > > > > > > > > > > > RESTCONF would register 10 media types and YANG Patch 4 media types > > > > if we use the hardwired approach. > > > > > > > > application/yang-api+xml > > > > application/yang-api+json > > > > application/yang-datastore+xml > > > > application/yang-datastore+json > > > > application/yang-data+xml > > > > application/yang-data+json > > > > application/yang-errors+xml > > > > application/yang-errors+json > > > > application/yang-operation+xml > > > > application/yang-operations+json > > > > application/yang-patch+xml > > > > application/yang-patch+json > > > > application/yang-patch-status+xml > > > > application/yang-patch-status+json > > > > > > > > Any new media types would need to be registered. > > > > No usage of the restconf-media-type is possible besides > > > > this list of media types for RESTCONF and YANG Patch > > > > without additional registrations. > > > > > > > > Approach 2) generic types with a parameter > > > > > > > > A parameter approach would allow YANG to be used to define any > > > > message content schema. E.g., a mandatory "type" parameter > > > > that specifies the module and name of the restconf-media-type. > > > > > > > > Only 2 media type need to be registered for every media-type > > > > that could ever be specified (SDO or vendor) > > > > > > > > application/yang-data-xml;type=: > > > > application/yang-data-json;type=: > > > > > > > > application/yang-data-xml;type=ietf-restconf:api > > > > application/yang-data-json;type=ietf-restconf:api > > > > application/yang-data-xml;type=ietf-restconf:datastore > > > > application/yang-data-json;type=ietf-restconf:datastore > > > > application/yang-data-xml;type=ietf-restconf:data > > > > application/yang-data-json;type=ietf-restconf:data > > > > application/yang-data-xml;type=ietf-restconf:errors > > > > application/yang-data-json;type=ietf-restconf:errors > > > > application/yang-data-xml;type=ietf-restconf:operation > > > > application/yang-data-json;type=ietf-restconf:operation > > > > application/yang-data-xml;type=ietf-yang-patch:yang-patch > > > > application/yang-data-json;type=ietf-yang-patch:yang-patch > > > > application/yang-data-xml;type=ietf-yang-patch:yang-patch-status > > > > application/yang-data-json;type=ietf-yang-patch:yang-patch-status > > > > > > > > > > > > If you have a preference how this issue is resolved, send comments. > > > > > > I prefer #1, as media types aren't supposed to carry schema > information (and we do have it elsewhere). One thing to consider though is > to reduce the number of media types. For example, it's IMO not necessary to > have separate media types "application/yang-data" and > "application/yang-operation" because they can be easily discriminated via > the URI. > > > > > > > > > > > > I think #1 is simpler to implement. > > > I don't agree we should make operation and data resources the same > media type. > > > It is useful in implementation to tell POST data from POST operation > before parsing > > > the message-body. > > > > Parsing and resolving the RequestURI should be sufficient to tell them > apart, no? > > > > > > no... > > > > > > container foo { > > container input { > > leaf X { type string; } > > } > > action bar { > > input { > > leaf X { type string; } > > } > > } > > } > > > > > > POST /restconf/data/foo > > > > { "input" : { > > "X" : "so is this an invocation of action bar or a creation of > container input?" > > } > > } > > Shouldn't the action be invoked with > > POST /restconf/data/foo/bar > > yes -- the URIs will be different. I don't see what problem it solves to change it now. Either we think RESTCONF-specific media types help or they should all be removed. To take this argument to the logical conclusion, we could dump all the media types and just use application/xml and application/json. In fact, we support that in our server, proving the RESTCONF media types can be ignored because there is enough context in the request to deduce the schema. I think the media types add some strong typing. Not sure if that is important or not. Andy Section 3.6 says > > An action is invoked as: > > POST {+restconf}/data// > > > > > > > > What problem are you solving by combining them? > > Media types should not be multiplied unnecessarily. > > Lada > > > > > > > Lada > > > > > > Andy > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Netconf mailing list > > > > Netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --94eb2c1243b2435dad0535c95b35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 21, 2016 at 5:49 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 21 Jun 2016, at 14:32, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Tue, Jun 21, 2016 at 5:23 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 21 Jun 2016, at 14:16, Andy Bierman <andy@yumaworks.com> wrote:
> >
> >
> >
> > On Tue, Jun 21, 2016 at 12:39 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > > On 21 Jun 2016, at 02:11, Andy Bierman <andy@yumaworks.com> wrote:
> > >
> > > Hi,
> > >
> > > The media type definitions in RESTCONF-13 are incorrect.
> > > We cannot make subtypes for application/yang.
> > > Each RESTCONF (and YANG Patch) media type has
> > > to be registered.
> > >
> > >
> > > Approach 1) hard-wired types
> > >
> > >
> > > RESTCONF would register 10 media types and YANG Patch 4 medi= a types
> > > if we use the hardwired approach.
> > >
> > >=C2=A0 =C2=A0 application/yang-api+xml
> > >=C2=A0 =C2=A0 application/yang-api+json
> > >=C2=A0 =C2=A0 application/yang-datastore+xml
> > >=C2=A0 =C2=A0 application/yang-datastore+json
> > >=C2=A0 =C2=A0 application/yang-data+xml
> > >=C2=A0 =C2=A0 application/yang-data+json
> > >=C2=A0 =C2=A0 application/yang-errors+xml
> > >=C2=A0 =C2=A0 application/yang-errors+json
> > >=C2=A0 =C2=A0 application/yang-operation+xml
> > >=C2=A0 =C2=A0 application/yang-operations+json
> > >=C2=A0 =C2=A0 application/yang-patch+xml
> > >=C2=A0 =C2=A0 application/yang-patch+json
> > >=C2=A0 =C2=A0 application/yang-patch-status+xml
> > >=C2=A0 =C2=A0 application/yang-patch-status+json
> > >
> > > Any new media types would need to be registered.
> > > No usage of the restconf-media-type is possible besides
> > > this list of media types for RESTCONF and YANG Patch
> > > without additional registrations.
> > >
> > > Approach 2) generic types with a parameter
> > >
> > > A parameter approach would allow YANG to be used to define a= ny
> > > message content schema.=C2=A0 E.g., a mandatory "type&q= uot; parameter
> > > that specifies the module and name of the restconf-media-typ= e.
> > >
> > > Only 2 media type need to be registered for every media-type=
> > > that could ever be specified (SDO or vendor)
> > >
> > >=C2=A0 =C2=A0 application/yang-data-xml;type=3D<module>= :<name>
> > >=C2=A0 =C2=A0 application/yang-data-json;type=3D<module>= ;:<name>
> > >
> > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-restconf:= api
> > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-restconf= :api
> > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-restconf:= datastore
> > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-restconf= :datastore
> > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-restconf:= data
> > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-restconf= :data
> > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-restconf:= errors
> > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-restconf= :errors
> > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-restconf:= operation
> > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-restconf= :operation
> > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-yang-patc= h:yang-patch
> > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-yang-pat= ch:yang-patch
> > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-yang-patc= h:yang-patch-status
> > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-yang-pat= ch:yang-patch-status
> > >
> > >
> > > If you have a preference how this issue is resolved, send co= mments.
> >
> > I prefer #1, as media types aren't supposed to carry schema i= nformation (and we do have it elsewhere). One thing to consider though is t= o reduce the number of media types. For example, it's IMO not necessary= to have separate media types "application/yang-data" and "a= pplication/yang-operation" because they can be easily discriminated vi= a the URI.
> >
> >
> >
> > I think #1 is simpler to implement.
> > I don't agree we should make operation and data resources the= same media type.
> > It is useful in implementation to tell POST data from POST operat= ion before parsing
> > the message-body.
>
> Parsing and resolving the RequestURI should be sufficient to tell them= apart, no?
>
>
> no...
>
>
> container foo {
>=C2=A0 =C2=A0 container input {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf X { type string; }
>=C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 action bar {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0input {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf X { type string; }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 }
>
>
> POST /restconf/data/foo
>
> { "input" : {
>=C2=A0 =C2=A0 =C2=A0 "X" : "so is this an invocation of = action bar or a creation of container input?"
>=C2=A0 =C2=A0 }
> }

Shouldn't the action be invoked with

POST /restconf/data/foo/bar



yes -- the URIs will be= different.

I don't see what problem it solves= to change it now.
Either we think RESTCONF-specific media types = help or they should all be removed.

To take this a= rgument to the logical conclusion, we could dump all the media types
<= div>and just use application/xml and application/json.

=
In fact, we support that in our server, proving the RESTCONF media typ= es can be ignored
because there is enough context in the request = to deduce the schema.

I think the media types = add some strong typing.
Not sure if that is important or not.


Andy

Section 3.6 says

=C2=A0 =C2=A0An action is invoked as:

=C2=A0 =C2=A0POST {+restconf}/data/<data-resource-identifier>/<act= ion>


>
>
> What problem are you solving by combining them?

Media types should not be multiplied unnecessarily.

Lada

>
>
> Lada
>
>
> Andy
>
>
> >
> > Lada
> >
> > >
> > >
> >
> >
> > Andy
> >
> > >
> > > Andy
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > Netconf@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ne= tconf
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--94eb2c1243b2435dad0535c95b35-- From nobody Tue Jun 21 05:59:18 2016 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 3555C12B03E for ; Tue, 21 Jun 2016 05:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 juAX00Uc2eus for ; Tue, 21 Jun 2016 05:59:15 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 45892126B6D for ; Tue, 21 Jun 2016 05:59:15 -0700 (PDT) Received: from localhost (unknown [173.38.220.44]) by mail.tail-f.com (Postfix) with ESMTPSA id 473231AE0198; Tue, 21 Jun 2016 14:59:14 +0200 (CEST) Date: Tue, 21 Jun 2016 14:59:38 +0200 (CEST) Message-Id: <20160621.145938.1306668416816797863.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <1f8ace67-706d-c1f9-b56e-2caaa7572b45@cisco.com> References: <97fe11c4-027c-9835-00ed-518ce3b1827e@cisco.com> <20160621.144659.998339534128110444.mbj@tail-f.com> <1f8ace67-706d-c1f9-b56e-2caaa7572b45@cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 12:59:17 -0000 Robert Wilton wrote: > > > On 21/06/2016 13:46, Martin Bjorklund wrote: > > Robert Wilton wrote: > >> > >> On 21/06/2016 11:59, Martin Bjorklund wrote: > >>> Robert Wilton wrote: > >>>> On 21/06/2016 11:21, Martin Bjorklund wrote: > >>>>> Juergen Schoenwaelder wrote: > >>>>>> On Tue, Jun 21, 2016 at 10:08:13AM +0200, Robert Varga wrote: > >>>>>>> Hello, > >>>>>>> > >>>>>>> Reading through section 4.8.1 and D.3.1, it seems that in case of > >>>>>>> content=all there is no guidance what the server should do if it > >>>>>>> encounters a leaf which has different values in config and oper. > >>>>>>> > >>>>>>> Would this constitute an error, or should one of them take precedence? > >>>>>>> > >>>>>> The notion of "all" may prove problematic depending on how we move > >>>>>> forward with multiple datastore. However, I think the most pressing > >>>>>> issue to address before RESTCONF goes to the RFC editor is to move the > >>>>>> default of the content query parameter back to 'config' instead of > >>>>>> 'all'. Having the content parameter default to 'all' makes it hard to > >>>>>> possibly deprecate 'all' in the future. > >>>>> I don't think this change would help. Suppose we introduce > >>>>> intended/applied/operational-state as proposed in your draft. Config > >>>>> true nodes would then exist in all three. So which one would be > >>>>> returned w/o any 'content' param (or 'content=config')? > >>>>> > >>>>> IMO the problem is that 'data' contains *combined* config and state, > >>>>> which doesn't really work if the same schema nodes can exist in both > >>>>> config and state. > >>>> This is one of the reasons why I prefer having only 2 datastores > >>>> (i.e. intended + operational state (inc applied config)) rather than > >>>> the 3 described above. > >>>> > >>>> The content=all operation can then return the contents of the > >>>> operational state datastore > >>> This would be fine, but this is NOT how the content parameter is > >>> defined today. Hmmm, maybe it is not clear what the "content" > >>> parameter actually does. It says: > >>> > >>> | config | Return only configuration descendant data nodes | > >>> | nonconfig | Return only non-configuration descendant data nodes | > >>> | all | Return all descendant data nodes | > >>> > >>> Whatever this means, it seems to imply that: > >>> > >>> GET(content=config) + GET(content=nonconfig) = GET(content=all) > >>> > >>> It is just a simple filter to select one subset of all data. > >>> > >>> > >>> This means that the "content" parameter does not affect the source of > >>> the data; the source is still the "combination of config ans state". > >> OK, so perhaps refine/redefine that GET requests on "/restconf/data" > >> are always against the operational state (inc applied config) > >> datastore. I.e. with the content=config filter you just get > >> applied-config. > > So how would you read what you call "persistent config db" below? > Via a GET operation on new datastore specific RESTCONF path. > E.g. "/restconf/ds/persistent/" So this is clearly not backwards compatible either. I don't think the wilton solution is better in this regard than the schoenwaelder solution. /martin > > I would also allow, and recommend, POST/PUT requests on > "/restconf/ds/persistent/". POST/PUT requests on "/restconf/data" > would be handled by the server as if the request had been made on > "/restconf/ds/persistent/". > > Similarly, a datastore specific path would be defined for the opstate > datastore (e.g. /restconf/ds/opstate/): > - POST/PUT requests to this datastore are not allowed (it is read-only) > - GET requests to "/restconf/data" would be handled by the server as if > - the request had been made on "/restconf/ds/opstate/" instead. > > Thanks, > Rob > > > > > > >> POST/POST/etc requests would write to what I have labelled as the > >> persistent config ds. Semantically, this doesn't seem to be that > >> different to writing to the candidate ds under the covers if necessary > >> that RESTCONF does today. > > > > /martin > > > > > >> I appreciate that this is not how this is defined at the moment, but > >> this would still seem to be backwards compatible refinement. > >> > >> Thanks, > >> Rob > >> > >> > >>>> which happens to include the applied > >>>> configuration, and is also the same as what would be returned from a > >>>> RESTCONF device today. > >>>> > >>>> Full clean access to the separate datastores will require datastore > >>>> awareness in the REST API, but I can imagine that for a lot of simple > >>>> devices a simple combined view is useful. > >>> This would be ok. > >>> > >>> > >>> /martin > >>> . > >>> > > . > > > From nobody Tue Jun 21 06:08:06 2016 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 DFD6212B00F for ; Tue, 21 Jun 2016 06:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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, RP_MATCHES_RCVD=-1.426] 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 EQ2ebVyHtqj9 for ; Tue, 21 Jun 2016 06:08:03 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC292126B6D for ; Tue, 21 Jun 2016 06:08:02 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:1d26:3c9:e0f4:a092] (unknown [IPv6:2001:718:1a02:1:1d26:3c9:e0f4:a092]) by mail.nic.cz (Postfix) with ESMTPSA id 0FEDC617FF; Tue, 21 Jun 2016 15:08:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1466514481; bh=LfdzK/q3p3ilXyL7O4mJHaNtvKxW6L003x22a/FQxBk=; h=From:Date:To; b=NflCnKUteFQEybiWqLodjccJSrQpJEdsnA9cw2YimL30DHlvU7xJs9nEped/ciEUM oIn+2Ij1E94/7Ef52Hhi8JtfCad4V0BdVG6dH9SvPN6V+BFh/+vGv3mnHHN1ZCMfjS 94tAds0uO+oCfi6sS/jUE4HZ2M6dHRuEGN+q8a8Y= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 21 Jun 2016 15:08:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <07F10BFB-8989-4038-AB75-539D82C5A5F3@nic.cz> References: <5F59F1E8-62E8-4AE9-9E51-DB4E506C3C80@nic.cz> <326DE836-9AD6-4132-9F7C-938BAA729D71@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 13:08:05 -0000 > On 21 Jun 2016, at 14:56, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Jun 21, 2016 at 5:49 AM, Ladislav Lhotka = wrote: >=20 > > On 21 Jun 2016, at 14:32, Andy Bierman wrote: > > > > > > > > On Tue, Jun 21, 2016 at 5:23 AM, Ladislav Lhotka = wrote: > > > > > On 21 Jun 2016, at 14:16, Andy Bierman wrote: > > > > > > > > > > > > On Tue, Jun 21, 2016 at 12:39 AM, Ladislav Lhotka = wrote: > > > > > > > On 21 Jun 2016, at 02:11, Andy Bierman = wrote: > > > > > > > > Hi, > > > > > > > > The media type definitions in RESTCONF-13 are incorrect. > > > > We cannot make subtypes for application/yang. > > > > Each RESTCONF (and YANG Patch) media type has > > > > to be registered. > > > > > > > > > > > > Approach 1) hard-wired types > > > > > > > > > > > > RESTCONF would register 10 media types and YANG Patch 4 media = types > > > > if we use the hardwired approach. > > > > > > > > application/yang-api+xml > > > > application/yang-api+json > > > > application/yang-datastore+xml > > > > application/yang-datastore+json > > > > application/yang-data+xml > > > > application/yang-data+json > > > > application/yang-errors+xml > > > > application/yang-errors+json > > > > application/yang-operation+xml > > > > application/yang-operations+json > > > > application/yang-patch+xml > > > > application/yang-patch+json > > > > application/yang-patch-status+xml > > > > application/yang-patch-status+json > > > > > > > > Any new media types would need to be registered. > > > > No usage of the restconf-media-type is possible besides > > > > this list of media types for RESTCONF and YANG Patch > > > > without additional registrations. > > > > > > > > Approach 2) generic types with a parameter > > > > > > > > A parameter approach would allow YANG to be used to define any > > > > message content schema. E.g., a mandatory "type" parameter > > > > that specifies the module and name of the restconf-media-type. > > > > > > > > Only 2 media type need to be registered for every media-type > > > > that could ever be specified (SDO or vendor) > > > > > > > > application/yang-data-xml;type=3D: > > > > application/yang-data-json;type=3D: > > > > > > > > application/yang-data-xml;type=3Dietf-restconf:api > > > > application/yang-data-json;type=3Dietf-restconf:api > > > > application/yang-data-xml;type=3Dietf-restconf:datastore > > > > application/yang-data-json;type=3Dietf-restconf:datastore > > > > application/yang-data-xml;type=3Dietf-restconf:data > > > > application/yang-data-json;type=3Dietf-restconf:data > > > > application/yang-data-xml;type=3Dietf-restconf:errors > > > > application/yang-data-json;type=3Dietf-restconf:errors > > > > application/yang-data-xml;type=3Dietf-restconf:operation > > > > application/yang-data-json;type=3Dietf-restconf:operation > > > > application/yang-data-xml;type=3Dietf-yang-patch:yang-patch > > > > application/yang-data-json;type=3Dietf-yang-patch:yang-patch > > > > = application/yang-data-xml;type=3Dietf-yang-patch:yang-patch-status > > > > = application/yang-data-json;type=3Dietf-yang-patch:yang-patch-status > > > > > > > > > > > > If you have a preference how this issue is resolved, send = comments. > > > > > > I prefer #1, as media types aren't supposed to carry schema = information (and we do have it elsewhere). One thing to consider though = is to reduce the number of media types. For example, it's IMO not = necessary to have separate media types "application/yang-data" and = "application/yang-operation" because they can be easily discriminated = via the URI. > > > > > > > > > > > > I think #1 is simpler to implement. > > > I don't agree we should make operation and data resources the same = media type. > > > It is useful in implementation to tell POST data from POST = operation before parsing > > > the message-body. > > > > Parsing and resolving the RequestURI should be sufficient to tell = them apart, no? > > > > > > no... > > > > > > container foo { > > container input { > > leaf X { type string; } > > } > > action bar { > > input { > > leaf X { type string; } > > } > > } > > } > > > > > > POST /restconf/data/foo > > > > { "input" : { > > "X" : "so is this an invocation of action bar or a creation of = container input?" > > } > > } >=20 > Shouldn't the action be invoked with >=20 > POST /restconf/data/foo/bar >=20 >=20 >=20 > yes -- the URIs will be different. >=20 > I don't see what problem it solves to change it now. > Either we think RESTCONF-specific media types help or they should all = be removed. >=20 > To take this argument to the logical conclusion, we could dump all the = media types > and just use application/xml and application/json. >=20 > In fact, we support that in our server, proving the RESTCONF media = types can be ignored > because there is enough context in the request to deduce the schema. >=20 > I think the media types add some strong typing. > Not sure if that is important or not. The granularity of media types seems to be a controversial topic (feed = Google with "media type explosion"). I'd suggest to consult APPS folks. Lada >=20 >=20 > Andy >=20 > Section 3.6 says >=20 > An action is invoked as: >=20 > POST {+restconf}/data// >=20 >=20 > > > > > > What problem are you solving by combining them? >=20 > Media types should not be multiplied unnecessarily. >=20 > Lada >=20 > > > > > > Lada > > > > > > Andy > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Netconf mailing list > > > > Netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jun 21 07:31:08 2016 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 B306112B055 for ; Tue, 21 Jun 2016 07:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 GnLN_U4K3yQq for ; Tue, 21 Jun 2016 07:31:04 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 3C16C12B01E for ; Tue, 21 Jun 2016 07:31:04 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id j2so22628063vkg.2 for ; Tue, 21 Jun 2016 07:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=I3n7u1sWZiq0a4FmvgH6vwAG1qDF+H0UMMKtOtE5bZU=; b=O+hhmWuUKKmSVvlwoWEluCbcWyx4NozVHp6F2V2heM07r9XJR2UcDaK4PD0mtME1P2 0TWd3NyUe5FaXNzcxSt2VyrplAALrckEvxA0o2tfZfHlrLS9zALMdBW4DNZNTWPg/KQ1 jGNMOSE0A7aonVnQL/XEaSt3r6oj+fSQlFWXbF9zud3SYKBSmVSk1JcKEtOzpkYs+Wut dCs3Fn8U0BQ/NxUri502rff6dT7j2eVA/vKgr+QwaUIDTuzwU2Mz89XvcbHoZgaWB5Qv Fvox0VixqnVOoXZgQ3ipFtFW7icx4VueFtGf1/xn3qakcYS1uDtDJeJwDFWp4ridndcO YCAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=I3n7u1sWZiq0a4FmvgH6vwAG1qDF+H0UMMKtOtE5bZU=; b=eiD9Q9YRNbcTJjIKfuOtOQ5Mjf1aLfeCKUU9p9VtnVNhNFhQ/Gl8glb6ROqeE1YkDw 0NC/VUHQYZG61XVafpGpDsQZlibWt6Fqw9Zn56kcS2Te6pvDnlKxZzKPZll1JHS81Kmd tETSdFbQIg+TkHR6BUIJ6G6tQl9B3EqsmnhA5feHcurM7IPAprKGUS+1Vmgai4J1uQrk mSci0T/aEJjYkV7D7vZsWBkdch+cU98cu81kGWyORAexopKAH+4QqrsfCwIY8EK5HmxI 8rDz9yXVocKIimXvEwvZw7SyElvLlWvgUuQ1r+FK8zrRwg2+te1iZOfVClBcVdzXAIKk c8CA== X-Gm-Message-State: ALyK8tLUxzM0W8YzHihgOdhzGN15FnH2Qn6QdEsgfkn41smQVNUCcV70yKyMGbvdZMLFQBD76IAgjpJisY4bVw== MIME-Version: 1.0 X-Received: by 10.31.108.216 with SMTP id j85mr9539174vki.68.1466519463288; Tue, 21 Jun 2016 07:31:03 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Tue, 21 Jun 2016 07:31:03 -0700 (PDT) In-Reply-To: <07F10BFB-8989-4038-AB75-539D82C5A5F3@nic.cz> References: <5F59F1E8-62E8-4AE9-9E51-DB4E506C3C80@nic.cz> <326DE836-9AD6-4132-9F7C-938BAA729D71@nic.cz> <07F10BFB-8989-4038-AB75-539D82C5A5F3@nic.cz> Date: Tue, 21 Jun 2016 07:31:03 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka , media-types@iana.org Content-Type: multipart/alternative; boundary=001a11478f34aaa7ed0535caab57 Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 14:31:06 -0000 --001a11478f34aaa7ed0535caab57 Content-Type: text/plain; charset=UTF-8 Hi, I forgot to CC: the media-types list ask Benoit asked. Maybe they have an opinion on removing the operation media type. Andy On Tue, Jun 21, 2016 at 6:08 AM, Ladislav Lhotka wrote: > > > On 21 Jun 2016, at 14:56, Andy Bierman wrote: > > > > > > > > On Tue, Jun 21, 2016 at 5:49 AM, Ladislav Lhotka wrote: > > > > > On 21 Jun 2016, at 14:32, Andy Bierman wrote: > > > > > > > > > > > > On Tue, Jun 21, 2016 at 5:23 AM, Ladislav Lhotka > wrote: > > > > > > > On 21 Jun 2016, at 14:16, Andy Bierman wrote: > > > > > > > > > > > > > > > > On Tue, Jun 21, 2016 at 12:39 AM, Ladislav Lhotka > wrote: > > > > > > > > > On 21 Jun 2016, at 02:11, Andy Bierman wrote: > > > > > > > > > > Hi, > > > > > > > > > > The media type definitions in RESTCONF-13 are incorrect. > > > > > We cannot make subtypes for application/yang. > > > > > Each RESTCONF (and YANG Patch) media type has > > > > > to be registered. > > > > > > > > > > > > > > > Approach 1) hard-wired types > > > > > > > > > > > > > > > RESTCONF would register 10 media types and YANG Patch 4 media types > > > > > if we use the hardwired approach. > > > > > > > > > > application/yang-api+xml > > > > > application/yang-api+json > > > > > application/yang-datastore+xml > > > > > application/yang-datastore+json > > > > > application/yang-data+xml > > > > > application/yang-data+json > > > > > application/yang-errors+xml > > > > > application/yang-errors+json > > > > > application/yang-operation+xml > > > > > application/yang-operations+json > > > > > application/yang-patch+xml > > > > > application/yang-patch+json > > > > > application/yang-patch-status+xml > > > > > application/yang-patch-status+json > > > > > > > > > > Any new media types would need to be registered. > > > > > No usage of the restconf-media-type is possible besides > > > > > this list of media types for RESTCONF and YANG Patch > > > > > without additional registrations. > > > > > > > > > > Approach 2) generic types with a parameter > > > > > > > > > > A parameter approach would allow YANG to be used to define any > > > > > message content schema. E.g., a mandatory "type" parameter > > > > > that specifies the module and name of the restconf-media-type. > > > > > > > > > > Only 2 media type need to be registered for every media-type > > > > > that could ever be specified (SDO or vendor) > > > > > > > > > > application/yang-data-xml;type=: > > > > > application/yang-data-json;type=: > > > > > > > > > > application/yang-data-xml;type=ietf-restconf:api > > > > > application/yang-data-json;type=ietf-restconf:api > > > > > application/yang-data-xml;type=ietf-restconf:datastore > > > > > application/yang-data-json;type=ietf-restconf:datastore > > > > > application/yang-data-xml;type=ietf-restconf:data > > > > > application/yang-data-json;type=ietf-restconf:data > > > > > application/yang-data-xml;type=ietf-restconf:errors > > > > > application/yang-data-json;type=ietf-restconf:errors > > > > > application/yang-data-xml;type=ietf-restconf:operation > > > > > application/yang-data-json;type=ietf-restconf:operation > > > > > application/yang-data-xml;type=ietf-yang-patch:yang-patch > > > > > application/yang-data-json;type=ietf-yang-patch:yang-patch > > > > > application/yang-data-xml;type=ietf-yang-patch:yang-patch-status > > > > > > application/yang-data-json;type=ietf-yang-patch:yang-patch-status > > > > > > > > > > > > > > > If you have a preference how this issue is resolved, send comments. > > > > > > > > I prefer #1, as media types aren't supposed to carry schema > information (and we do have it elsewhere). One thing to consider though is > to reduce the number of media types. For example, it's IMO not necessary to > have separate media types "application/yang-data" and > "application/yang-operation" because they can be easily discriminated via > the URI. > > > > > > > > > > > > > > > > I think #1 is simpler to implement. > > > > I don't agree we should make operation and data resources the same > media type. > > > > It is useful in implementation to tell POST data from POST operation > before parsing > > > > the message-body. > > > > > > Parsing and resolving the RequestURI should be sufficient to tell them > apart, no? > > > > > > > > > no... > > > > > > > > > container foo { > > > container input { > > > leaf X { type string; } > > > } > > > action bar { > > > input { > > > leaf X { type string; } > > > } > > > } > > > } > > > > > > > > > POST /restconf/data/foo > > > > > > { "input" : { > > > "X" : "so is this an invocation of action bar or a creation of > container input?" > > > } > > > } > > > > Shouldn't the action be invoked with > > > > POST /restconf/data/foo/bar > > > > > > > > yes -- the URIs will be different. > > > > I don't see what problem it solves to change it now. > > Either we think RESTCONF-specific media types help or they should all be > removed. > > > > To take this argument to the logical conclusion, we could dump all the > media types > > and just use application/xml and application/json. > > > > In fact, we support that in our server, proving the RESTCONF media types > can be ignored > > because there is enough context in the request to deduce the schema. > > > > I think the media types add some strong typing. > > Not sure if that is important or not. > > The granularity of media types seems to be a controversial topic (feed > Google with "media type explosion"). > I'd suggest to consult APPS folks. > > Lada > > > > > > > Andy > > > > Section 3.6 says > > > > An action is invoked as: > > > > POST {+restconf}/data// > > > > > > > > > > > > > What problem are you solving by combining them? > > > > Media types should not be multiplied unnecessarily. > > > > Lada > > > > > > > > > > > Lada > > > > > > > > > Andy > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Netconf mailing list > > > > > Netconf@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > -- > > > > Ladislav Lhotka, CZ.NIC Labs > > > > PGP Key ID: E74E8C0C > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11478f34aaa7ed0535caab57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I forgot to CC: the media-types lis= t ask Benoit asked.
Maybe they have an opinion on removing the op= eration media type.



= Andy


On Tue, Jun 21, 2016 at 6:08 AM, Ladislav Lhotka <lhotka@nic.cz<= /a>> wrote:

> On 21 Jun 2016, at 14:56, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Tue, Jun 21, 2016 at 5:49 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 21 Jun 2016, at 14:32, Andy Bierman <andy@yumaworks.com> wrote:
> >
> >
> >
> > On Tue, Jun 21, 2016 at 5:23 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > > On 21 Jun 2016, at 14:16, Andy Bierman <andy@yumaworks.com> wrote:
> > >
> > >
> > >
> > > On Tue, Jun 21, 2016 at 12:39 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > >
> > > > On 21 Jun 2016, at 02:11, Andy Bierman <andy@yumaworks.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > The media type definitions in RESTCONF-13 are incorrect= .
> > > > We cannot make subtypes for application/yang.
> > > > Each RESTCONF (and YANG Patch) media type has
> > > > to be registered.
> > > >
> > > >
> > > > Approach 1) hard-wired types
> > > >
> > > >
> > > > RESTCONF would register 10 media types and YANG Patch 4= media types
> > > > if we use the hardwired approach.
> > > >
> > > >=C2=A0 =C2=A0 application/yang-api+xml
> > > >=C2=A0 =C2=A0 application/yang-api+json
> > > >=C2=A0 =C2=A0 application/yang-datastore+xml
> > > >=C2=A0 =C2=A0 application/yang-datastore+json
> > > >=C2=A0 =C2=A0 application/yang-data+xml
> > > >=C2=A0 =C2=A0 application/yang-data+json
> > > >=C2=A0 =C2=A0 application/yang-errors+xml
> > > >=C2=A0 =C2=A0 application/yang-errors+json
> > > >=C2=A0 =C2=A0 application/yang-operation+xml
> > > >=C2=A0 =C2=A0 application/yang-operations+json
> > > >=C2=A0 =C2=A0 application/yang-patch+xml
> > > >=C2=A0 =C2=A0 application/yang-patch+json
> > > >=C2=A0 =C2=A0 application/yang-patch-status+xml
> > > >=C2=A0 =C2=A0 application/yang-patch-status+json
> > > >
> > > > Any new media types would need to be registered.
> > > > No usage of the restconf-media-type is possible besides=
> > > > this list of media types for RESTCONF and YANG Patch > > > > without additional registrations.
> > > >
> > > > Approach 2) generic types with a parameter
> > > >
> > > > A parameter approach would allow YANG to be used to def= ine any
> > > > message content schema.=C2=A0 E.g., a mandatory "t= ype" parameter
> > > > that specifies the module and name of the restconf-medi= a-type.
> > > >
> > > > Only 2 media type need to be registered for every media= -type
> > > > that could ever be specified (SDO or vendor)
> > > >
> > > >=C2=A0 =C2=A0 application/yang-data-xml;type=3D<modul= e>:<name>
> > > >=C2=A0 =C2=A0 application/yang-data-json;type=3D<modu= le>:<name>
> > > >
> > > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-rest= conf:api
> > > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-res= tconf:api
> > > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-rest= conf:datastore
> > > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-res= tconf:datastore
> > > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-rest= conf:data
> > > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-res= tconf:data
> > > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-rest= conf:errors
> > > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-res= tconf:errors
> > > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-rest= conf:operation
> > > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-res= tconf:operation
> > > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-yang= -patch:yang-patch
> > > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-yan= g-patch:yang-patch
> > > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-yang= -patch:yang-patch-status
> > > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-yan= g-patch:yang-patch-status
> > > >
> > > >
> > > > If you have a preference how this issue is resolved, se= nd comments.
> > >
> > > I prefer #1, as media types aren't supposed to carry sch= ema information (and we do have it elsewhere). One thing to consider though= is to reduce the number of media types. For example, it's IMO not nece= ssary to have separate media types "application/yang-data" and &q= uot;application/yang-operation" because they can be easily discriminat= ed via the URI.
> > >
> > >
> > >
> > > I think #1 is simpler to implement.
> > > I don't agree we should make operation and data resource= s the same media type.
> > > It is useful in implementation to tell POST data from POST o= peration before parsing
> > > the message-body.
> >
> > Parsing and resolving the RequestURI should be sufficient to tell= them apart, no?
> >
> >
> > no...
> >
> >
> > container foo {
> >=C2=A0 =C2=A0 container input {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf X { type string; }
> >=C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 action bar {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0input {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf X { type string; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 }
> >
> >
> > POST /restconf/data/foo
> >
> > { "input" : {
> >=C2=A0 =C2=A0 =C2=A0 "X" : "so is this an invocatio= n of action bar or a creation of container input?"
> >=C2=A0 =C2=A0 }
> > }
>
> Shouldn't the action be invoked with
>
> POST /restconf/data/foo/bar
>
>
>
> yes -- the URIs will be different.
>
> I don't see what problem it solves to change it now.
> Either we think RESTCONF-specific media types help or they should all = be removed.
>
> To take this argument to the logical conclusion, we could dump all the= media types
> and just use application/xml and application/json.
>
> In fact, we support that in our server, proving the RESTCONF media typ= es can be ignored
> because there is enough context in the request to deduce the schema. >
> I think the media types add some strong typing.
> Not sure if that is important or not.

The granularity of media types seems to be a controversial topic (feed Goog= le with "media type explosion").
I'd suggest to consult APPS folks.

Lada

>
>
> Andy
>
> Section 3.6 says
>
>=C2=A0 =C2=A0 An action is invoked as:
>
>=C2=A0 =C2=A0 POST {+restconf}/data/<data-resource-identifier>/&l= t;action>
>
>
> >
> >
> > What problem are you solving by combining them?
>
> Media types should not be multiplied unnecessarily.
>
> Lada
>
> >
> >
> > Lada
> >
> >
> > Andy
> >
> >
> > >
> > > Lada
> > >
> > > >
> > > >
> > >
> > >
> > > Andy
> > >
> > > >
> > > > Andy
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Netconf mailing list
> > > > Netconf@ietf.org
> > > > https://www.ietf.org/mailman/listin= fo/netconf
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--001a11478f34aaa7ed0535caab57-- From nobody Tue Jun 21 07:45:26 2016 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 64FB412D128 for ; Tue, 21 Jun 2016 07:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 QrpyouoT0XYS for ; Tue, 21 Jun 2016 07:45:23 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 6AF2112D11A for ; Tue, 21 Jun 2016 07:45:22 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-08v.sys.comcast.net with SMTP id FMuYbfWkhlVqIFMvZbrp3j; Tue, 21 Jun 2016 14:45:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466520321; bh=LXZGE0UKmPFM6X5u4RgokcaExfpDlWRWcZTPsshG0SM=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=GYufHyooznDhgAjdt5QqrcljBU0IGgFeEqKvt7YGo8eR22jgp8vA398i5d/e6awHk 0aPaQ83UFomb2zp2JDWlaHU75lCn9LHr/qGa9pZZnZkbzaPBydPcTq4zMPRNL/6nv2 SFgzFPkZzykz6PCvtJCta+G5KjfvP4kBstQ3dpjEl4Q3RQHkzMFV3139mjvfU9Qr2N srfvTaQxbn+Vht0czOnrkqDCu1TR6tOM8/69eI+mEoTGFciXtz2Vc1UFKGzI9WIdJM wAp+SPJmANW2hl4qkbOLo8GoREoSt+axMsCvhe06fkcsZfXeYD6BjeJrSl6ar3EGuc ML3DTrMlbqF2w== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-08v.sys.comcast.net with comcast id 9SlL1t00d1nMCLR01SlM58; Tue, 21 Jun 2016 14:45:21 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5LEjKaU018612; Tue, 21 Jun 2016 10:45:20 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5LEjKjj018609; Tue, 21 Jun 2016 10:45:20 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Ladislav Lhotka In-Reply-To: (lhotka@nic.cz) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 21 Jun 2016 10:45:19 -0400 Message-ID: <87eg7qppmo.fsf@hobgoblin.ariadne.com> Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 14:45:24 -0000 Ladislav Lhotka writes: > Parsing and resolving the RequestURI should be sufficient to tell them > apart, no? That does seem to be the natural way to me -- We are trying to distinguish what the request is going to do, and the resource it is going to do it to. That's the role of the URI and the method. The media type should be to tell how the body is "encoded" (in the highest-level semantic sense). One test we can apply is this: Can you imagine the media type being used in requests used in entirely unrelated applications? Most of these media types seem to be intended to be used in only one or a few methods applied to only one URI of a Restconf instance. And if we define further things Restconf can do, there will be many more media types added. It seems to me the natural media types are just "XML" and "JSON". Dale From nobody Tue Jun 21 07:47:19 2016 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 1BED512D12E for ; Tue, 21 Jun 2016 07:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 oUcOrrSBCC9b for ; Tue, 21 Jun 2016 07:47:16 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 3753812D53A for ; Tue, 21 Jun 2016 07:47:12 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-06v.sys.comcast.net with SMTP id FMwhbyXslE8zeFMxLbFZii; Tue, 21 Jun 2016 14:47:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466520431; bh=FpFd5XG8yt5y5Sep04FgPbfw5Rq2N53RgxtDBpnYotU=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=nFWCsAKi2Atj8ozxCH13kwXJnVfpO6WheOEG52nrOSlV6KXlai3r6RPrL6VpqXsm4 vZjHwT2q3dL3HKlp674n994zdozemHk5ow7foCgc2vRrZQc13QBzw6XRzSFHviJ8cm BHMeGyPEJqjjtF4EhrpB2f61/AHIwq4CNW7MwanIJXVVKE06ImcwsqGkqxtJZLmy9Q RVIGHHd21iRCy4vXNAKc8KIZhbimeikhuM0EgWL5kTMgRdXhY/jF3d0TmDSnWczKbM TluiIeRVUh8YM+PgGxHywLgLHJMQXVNE+m5ddy2aXpbWT89+s4MjTelit6fIG6yxRD SFvVuws/P+17w== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-14v.sys.comcast.net with comcast id 9SnA1t00c1nMCLR01SnBCe; Tue, 21 Jun 2016 14:47:11 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5LElAC9018802; Tue, 21 Jun 2016 10:47:10 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5LElAig018799; Tue, 21 Jun 2016 10:47:10 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Andy Bierman In-Reply-To: (andy@yumaworks.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 21 Jun 2016 10:47:09 -0400 Message-ID: <87bn2uppjm.fsf@hobgoblin.ariadne.com> Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 14:47:17 -0000 Andy Bierman writes: > I was right the first time. > The URI does not contain "input", just the message. > So the media type is needed to distinguish actions from data. It seems to me this is an argument for changing the URI so it tells that the request is an action, and *what* the action is (since the methods is fixed as POST). Dale From nobody Tue Jun 21 08:10:00 2016 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 B913F12D942 for ; Tue, 21 Jun 2016 08:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 6VXACRGwCd4J for ; Tue, 21 Jun 2016 08:09:59 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 197A712D941 for ; Tue, 21 Jun 2016 08:09:59 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-04v.sys.comcast.net with SMTP id FNIjbnQtL8RcDFNJObBx0U; Tue, 21 Jun 2016 15:09:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466521798; bh=K25+hYBh1dKuG4jIFs+zBa9JUHb6ea8IWTK66h9OcyA=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Zna8naPRihA+9oudO/GnDMtPLRggPSuFlcjC2o1/WtHO43kKkbrrzFuXG3EKisRqQ q9WmZ7PCF8bq8zDFrDg+tQOZqT+emPXCFGPHDnmG0NBCJnvtrE26ThwYtJZCqyYZ9k N80v+zLGELtjtAtJUivgStwosEv+EXUhvZVTJlevq3qc2/XBjylnVInbPZJsjJMMJf StRVqKnFYuNsa90Vkbny+jHPo+/rqxuauXfDEGJORfg1nNOZONevXAlvyRNES6wBkj eCG9anQsSea9sflHPGMGWESsU+Ix5iyL1osK3FA/7EhUiB92cpfzANAOZcfGmYzkMf LOOhnMHT2kE2w== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-20v.sys.comcast.net with comcast id 9T9x1t00G1nMCLR01T9xRm; Tue, 21 Jun 2016 15:09:58 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5LF9u6L021095; Tue, 21 Jun 2016 11:09:56 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5LF9tK6021091; Tue, 21 Jun 2016 11:09:55 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Robert Varga In-Reply-To: (nite@hq.sk) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 21 Jun 2016 11:09:55 -0400 Message-ID: <8760t2poho.fsf@hobgoblin.ariadne.com> Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF content=all on conflicts?, Re: RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 15:09:59 -0000 Robert Varga writes: > That is a good question, I had to look this one up -- it takes just the > oper state (and assumes config was already mirrored). That feels like > something that should be changed. Speaking based only on reading 6020bis and restconf, it seems to me that the "device" has a "running" data tree, some items of which are "configuration" (settable by Netconf et al.) and some of which are "state" (set by the device). There's also a concept of a "new" data tree of configuration, which can be created in steps by protocol operations by modifying an implicitly-created copy of the running configuration data. When the "new" tree is committed, it is checked for consistency (the infamous "constraints"!) and written into the running data tree. I can see the value of this model, because it solves a lot of messy problems arising from consistency requirements. Within this model, Restconf never really sees this split between the "running" and the "new" configuration, because after each Restconf operation a commit is done. (Which I take to imply that Restconf operations edit a fresh copy of the running data tree.) I can see the value of this model, because it means that Restconf doesn't incorporate the complexity of managing transactions. Within this, the meaning of the "content" parameter is simple, because Restconf can't address a "new" data tree. Dale From nobody Tue Jun 21 08:13:39 2016 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 653C812D957 for ; Tue, 21 Jun 2016 08:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 dRqV3tIuHIb1 for ; Tue, 21 Jun 2016 08:13:36 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 4542C12D954 for ; Tue, 21 Jun 2016 08:13:36 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-04v.sys.comcast.net with SMTP id FNIjbnQtK8RcDFNMtbBxti; Tue, 21 Jun 2016 15:13:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466522015; bh=Ll4bUTokLpj0VrJMkvop8FHxCOZWxPXCbDqi7g1T9iU=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=IMcK17EEaGDj7mfCm7daMrNpEeo2Zl+jZFHNmDt7Lm7LvU4XaYnBzQclA7tKHSby6 CiaIT2e6Ub6j4IFosRL1Q4x8w4+S7y22p6E++ahWNqmkXI4nVCwiPfOhmejBFUTYlQ WMihgwn3LHI8rKfPYyDSyloD/wldDOLtlFOW78oBO4NkZw7Qy4ENX7pzvvjiFQy53B n/evId1Xr9+FK1C/nHGGpfyLsnUVkcXYUOYLQ5DfPg0EHCa4RinYlUHhNtigKQeEvn Fv06HUQslwn3LBOarsOZLea1H9BrWIxTCu+NpJefkXNyu9klFDQ47Ddsm08nBGX4mb ZoAVzeIFkfV3Q== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-20v.sys.comcast.net with comcast id 9TDb1t0011nMCLR01TDbNz; Tue, 21 Jun 2016 15:13:35 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5LFDYRe021487; Tue, 21 Jun 2016 11:13:34 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5LFDY9f021484; Tue, 21 Jun 2016 11:13:34 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Martin Bjorklund In-Reply-To: <20160619.195705.1793240147923185529.mbj@tail-f.com> Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 21 Jun 2016 11:13:34 -0400 Message-ID: <871t3qpobl.fsf@hobgoblin.ariadne.com> Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] Comments on draft-ietf-netconf-restconf-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 15:13:37 -0000 Martin Bjorklund writes: > In section 14 (grammar) 6020bis says: > > ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l')) Good. It might be worth mentioning that in the prose as well. Dale From nobody Tue Jun 21 09:40:25 2016 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 2163D12D1B8 for ; Tue, 21 Jun 2016 09:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 4mC0Ut0X5l4u for ; Tue, 21 Jun 2016 09:40:19 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 3BE4A12B05D for ; Tue, 21 Jun 2016 09:40:19 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2E3D950A86 for ; Tue, 21 Jun 2016 12:40:18 -0400 (EDT) To: netconf@ietf.org References: <5F59F1E8-62E8-4AE9-9E51-DB4E506C3C80@nic.cz> <326DE836-9AD6-4132-9F7C-938BAA729D71@nic.cz> From: Sean Leonard Message-ID: <5f5ccb91-69c5-8677-0906-e62800535394@seantek.com> Date: Tue, 21 Jun 2016 09:40:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 16:40:24 -0000 On 6/21/2016, people said: > The media type definitions in RESTCONF-13 are incorrect. We cannot make subtypes for application/yang. Each RESTCONF (and YANG Patch) media type has to be registered. Approach 1) hard-wired types RESTCONF would register 10 media types and YANG Patch 4 media types if we use the hardwired approach. application/yang-api+xml application/yang-api+json application/yang-datastore+xml application/yang-datastore+json [etc.] Any new media types would need to be registered. No usage of the restconf-media-type is possible besides this list of media types for RESTCONF and YANG Patch without additional registrations. Approach 2) generic types with a parameter A parameter approach would allow YANG to be used to define any message content schema. E.g., a mandatory "type" parameter that specifies the module and name of the restconf-media-type. Only 2 media type need to be registered for every media-type that could ever be specified (SDO or vendor) application/yang-data-xml;type=3D: application/yang-data-json;type=3D: application/yang-data-xml;type=3Dietf-restconf:api application/yang-data-json;type=3Dietf-restconf:api [etc.] If you have a preference how this issue is resolved, send comments. > Then people said: >> Shouldn't the action be invoked with >> >> POST /restconf/data/foo/bar > yes -- the URIs will be different. > > I don't see what problem it solves to change it now. > Either we think RESTCONF-specific media types help or they should all b= e > removed. > > To take this argument to the logical conclusion, we could dump all the > media types > and just use application/xml and application/json. > > In fact, we support that in our server, proving the RESTCONF media type= s > can be ignored > because there is enough context in the request to deduce the schema. > > I think the media types add some strong typing. > Not sure if that is important or not. Hello, I wanted to take the opportunity to address the Netconf list... First of all: The way that 2) is proposed has a typo. It should be=20 application/yang-data+xml and application/yang-data+json, not -xml and=20 -json. + is for "structured syntax suffixes", which applies here. Officially (from the media-types perspective) either 1) or 2) could=20 work, depending on various engineering and administrative=20 considerations. In this case, those considerations are about module=20 routing, protocol advertisement, and effort to register new types. You could, theoretically, dump all media types and use application/xml=20 and application/json. But that invites a performance impact in that all=20 data received as /xml or /json has to be routed through a generic XML or = JSON processor that has to content-sniff for the data type inside the=20 payload. XML and JSON are generic data formats; they apply as a=20 structured syntax to innumerable content types that semantically have=20 nothing to do with each other. That is one reason why + structured=20 syntax suffixes were created. There ought to be a performance increase=20 by moving the data routing to a different part of the parsing chain,=20 discriminating based solely on the media type (a single case-insensitive = string comparison operation). Registering additional media types means you have to fill out (and have=20 approved) a registration template for each new media type. Therefore,=20 there is additional administrative overhead. Sometimes it's a formality=20 and sometimes it invites nitpicking. As there are more than 4 types,=20 this weighs against including specific schema information inside the=20 media type name. Whether you put the schema in application/yang-NAME or in a parameter=20 application/yang-data; module=3DNAME (or whatever), it's clear that the=20 module name is duplicated inside the payload. This invites conflict.=20 What if the response is labeled application/yang-operation+json but the=20 content is "ietf-restconf:errors"? What is the proper behavior? Having reviewed the RESTCONF drafts closely, my engineering opinion is=20 in favor of 2), making the type parameter OPTIONAL (unless it can be=20 shown that the payload is not sufficient to discriminate the YANG data=20 type). The registration of application/yang-data is well-justified because it=20 is instance data while application/yang is (apparently) schema data. Once you know it's "YANG Data", you know that a YANG processor has to=20 grok the data anyway; a robust YANG processor ought to be able to handle = all of the proposed types (or conversely, be aware of its own=20 limitations). By making the YANG type/sub-type optional, you're saying=20 that it's a hint. At the same time, your workflow can do some=20 preliminary routing based on the parameter without needing to invoke XML = or JSON parsing, so there is operational value in defining the=20 parameter. Compare with application/cms, RFC 7193 (and predecessor,=20 application/pkcs7-mime). In some formats, a type parameter might be REQUIRED. For example, I=20 understand that CBOR is being considered as a data format. If you decide = not to put the discriminator in the CBOR payload, then the type=20 parameter would be REQUIRED for +cbor, rather than OPTIONAL. Regards, Sean From nobody Tue Jun 21 14:20:21 2016 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 DAC2D12D7B2 for ; Tue, 21 Jun 2016 14:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 yqBMZmF1Mp1q for ; Tue, 21 Jun 2016 14:20:17 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 573F912DA1D for ; Tue, 21 Jun 2016 14:20:17 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id d185so37667097vkg.0 for ; Tue, 21 Jun 2016 14:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=naLCfOGRJ3VDt7tM5XBmAXAHW0J7rY2pRWOEBRl+dmw=; b=xzw2hJBfCruJyh9PejInm4HxC3SaX7AI9T0ZbBahpp890uHgYKDrL6nU60n/rEmfdw kVKEGn4Uy8jOtTa6esGavQku13obz/ReCJAiwIqQnJo4brd5BzdnWK2GVhHlvVYxFblS FF5VMMoKlrE8ud5oHzB5arnqp/cQ1GiEFHvGL2X895wYXe/8YHzMy4yxvYzcpT1jAv3v 6dEJyCSiqBveRr73TGJh7CbAtoloLBPW/+ZJ9LGepWU+/gCP19s4TshGpi9u0Il7FJsU JLkbSD3f07aH6ynPTyenknX03pqvoE5dH5arguEHDEOFuI1oob/btMMrv9FvVnuovVf/ Zp1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=naLCfOGRJ3VDt7tM5XBmAXAHW0J7rY2pRWOEBRl+dmw=; b=LolBd+pxnCCd9s5x0n063IBCdQ7SLSE7USKyjJ13W4J9O4NhFoFLoKU+l5V3CyGozD fvoGa8E7kNfD338LtZT2gAiOoiYt482qUM/7yHhO6PYH8UEbn3UcTOLl9GYPxvVufcGX PhY4Q4VdnkR7MifUNNZKxC7KAUCDTmd26d3KfTV+gqSqbiwPBygPhEFngnvcsHdTFb0I zhMOCTaIqaPXdXNzauksfcTWXLMC5I5JdRj6O1c309LrftPXNg33vR0/Gz8nx+I5ZXGV lUr9TSCdZifYOsKB9UuD9L8pcGk+eug9LRvngR2cLYd3x/7rJDBkqM/d4BtzPw4axpR4 JoZQ== X-Gm-Message-State: ALyK8tKKPqR9c1kTsSmBSMzY1xo7rZfYuqo2C8RWErB/ai+9+Agal+mLRopFABfJqJVY5N+HY1yh84k4ipHRtA== MIME-Version: 1.0 X-Received: by 10.31.132.77 with SMTP id g74mr11185863vkd.121.1466544015898; Tue, 21 Jun 2016 14:20:15 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Tue, 21 Jun 2016 14:20:15 -0700 (PDT) In-Reply-To: <5f5ccb91-69c5-8677-0906-e62800535394@seantek.com> References: <5F59F1E8-62E8-4AE9-9E51-DB4E506C3C80@nic.cz> <326DE836-9AD6-4132-9F7C-938BAA729D71@nic.cz> <5f5ccb91-69c5-8677-0906-e62800535394@seantek.com> Date: Tue, 21 Jun 2016 14:20:15 -0700 Message-ID: From: Andy Bierman To: Sean Leonard Content-Type: multipart/alternative; boundary=001a1144f9d81d908d0535d06325 Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 21:20:20 -0000 --001a1144f9d81d908d0535d06325 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 21, 2016 at 9:40 AM, Sean Leonard wrote: > On 6/21/2016, people said: > > > > > The media type definitions in RESTCONF-13 are incorrect. > We cannot make subtypes for application/yang. > Each RESTCONF (and YANG Patch) media type has > to be registered. > > > Approach 1) hard-wired types > > > RESTCONF would register 10 media types and YANG Patch 4 media types > if we use the hardwired approach. > > application/yang-api+xml > application/yang-api+json > application/yang-datastore+xml > application/yang-datastore+json > [etc.] > > Any new media types would need to be registered. > No usage of the restconf-media-type is possible besides > this list of media types for RESTCONF and YANG Patch > without additional registrations. > > Approach 2) generic types with a parameter > > A parameter approach would allow YANG to be used to define any > message content schema. E.g., a mandatory "type" parameter > that specifies the module and name of the restconf-media-type. > > Only 2 media type need to be registered for every media-type > that could ever be specified (SDO or vendor) > > application/yang-data-xml;type=: > application/yang-data-json;type=: > > application/yang-data-xml;type=ietf-restconf:api > application/yang-data-json;type=ietf-restconf:api > [etc.] > > If you have a preference how this issue is resolved, send comments. > > > > > Then people said: > >> Shouldn't the action be invoked with >>> >>> POST /restconf/data/foo/bar >>> >> yes -- the URIs will be different. >> >> I don't see what problem it solves to change it now. >> Either we think RESTCONF-specific media types help or they should all be >> removed. >> >> To take this argument to the logical conclusion, we could dump all the >> media types >> and just use application/xml and application/json. >> >> In fact, we support that in our server, proving the RESTCONF media types >> can be ignored >> because there is enough context in the request to deduce the schema. >> >> I think the media types add some strong typing. >> Not sure if that is important or not. >> > > Hello, I wanted to take the opportunity to address the Netconf list... > > First of all: The way that 2) is proposed has a typo. It should be > application/yang-data+xml and application/yang-data+json, not -xml and > -json. + is for "structured syntax suffixes", which applies here. > > Officially (from the media-types perspective) either 1) or 2) could work, > depending on various engineering and administrative considerations. In this > case, those considerations are about module routing, protocol > advertisement, and effort to register new types. > > You could, theoretically, dump all media types and use application/xml and > application/json. But that invites a performance impact in that all data > received as /xml or /json has to be routed through a generic XML or JSON > processor that has to content-sniff for the data type inside the payload. > XML and JSON are generic data formats; they apply as a structured syntax to > innumerable content types that semantically have nothing to do with each > other. That is one reason why + structured syntax suffixes were created. > There ought to be a performance increase by moving the data routing to a > different part of the parsing chain, discriminating based solely on the > media type (a single case-insensitive string comparison operation). > > Registering additional media types means you have to fill out (and have > approved) a registration template for each new media type. Therefore, there > is additional administrative overhead. Sometimes it's a formality and > sometimes it invites nitpicking. As there are more than 4 types, this > weighs against including specific schema information inside the media type > name. > > Whether you put the schema in application/yang-NAME or in a parameter > application/yang-data; module=NAME (or whatever), it's clear that the > module name is duplicated inside the payload. This invites conflict. What > if the response is labeled application/yang-operation+json but the content > is "ietf-restconf:errors"? What is the proper behavior? > > Having reviewed the RESTCONF drafts closely, my engineering opinion is in > favor of 2), making the type parameter OPTIONAL (unless it can be shown > that the payload is not sufficient to discriminate the YANG data type). > > The registration of application/yang-data is well-justified because it is > instance data while application/yang is (apparently) schema data. > > Once you know it's "YANG Data", you know that a YANG processor has to grok > the data anyway; a robust YANG processor ought to be able to handle all of > the proposed types (or conversely, be aware of its own limitations). By > making the YANG type/sub-type optional, you're saying that it's a hint. At > the same time, your workflow can do some preliminary routing based on the > parameter without needing to invoke XML or JSON parsing, so there is > operational value in defining the parameter. Compare with application/cms, > RFC 7193 (and predecessor, application/pkcs7-mime). > > In some formats, a type parameter might be REQUIRED. For example, I > understand that CBOR is being considered as a data format. If you decide > not to put the discriminator in the CBOR payload, then the type parameter > would be REQUIRED for +cbor, rather than OPTIONAL. > > I just had a meeting with our developer who wrote our RESTCONF server code that processes the HTTP request. Only the suffix is relevant in the Content-Type. There are no cases where the RESTCONF media type is needed because the request URI and/or message-body is ambiguous. It is only used to return an error if it is wrong. Option 3: Register 2 media types: application/yang-data+xml application/yang-data+json No parameters are needed The +xml is not equivalent to application/xml. It is usually "anydata", not "anyxml". Unless the YANG node really is from an anyxml-stmt. (Valid application/yang-data+xml is also valid XML) The +json is not equivalent to application/json. It requires draft-ietf-netmod-yang-json and draft-ietf-netmod-yang-metadata syntax. (Valid application/yang-data+json is also valid JSON) Regards, > > Sean > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a1144f9d81d908d0535d06325 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 21, 2016 at 9:40 AM, Sean Leonard <dev+ietf@seantek.com= > wrote:
On 6/21/2016, people said:

>

The media type definitions in RESTCONF-13 are incorrect.
We cannot make subtypes for application/yang.
Each RESTCONF (and YANG Patch) media type has
to be registered.


Approach 1) hard-wired types


RESTCONF would register 10 media types and YANG Patch 4 media types
if we use the hardwired approach.

=C2=A0 =C2=A0application/yang-api+xml
=C2=A0 =C2=A0application/yang-api+json
=C2=A0 =C2=A0application/yang-datastore+xml
=C2=A0 =C2=A0application/yang-datastore+json
[etc.]

Any new media types would need to be registered.
No usage of the restconf-media-type is possible besides
this list of media types for RESTCONF and YANG Patch
without additional registrations.

Approach 2) generic types with a parameter

A parameter approach would allow YANG to be used to define any
message content schema.=C2=A0 E.g., a mandatory "type" parameter<= br> that specifies the module and name of the restconf-media-type.

Only 2 media type need to be registered for every media-type
that could ever be specified (SDO or vendor)

=C2=A0 =C2=A0application/yang-data-xml;type=3D<module>:<name> =C2=A0 =C2=A0application/yang-data-json;type=3D<module>:<name><= br>
=C2=A0 =C2=A0application/yang-data-xml;type=3Dietf-restconf:api
=C2=A0 =C2=A0application/yang-data-json;type=3Dietf-restconf:api
[etc.]

If you have a preference how this issue is resolved, send comments.

>

Then people said:
Shouldn't the action be invoked with

POST /restconf/data/foo/bar
yes -- the URIs will be different.

I don't see what problem it solves to change it now.
Either we think RESTCONF-specific media types help or they should all be removed.

To take this argument to the logical conclusion, we could dump all the
media types
and just use application/xml and application/json.

In fact, we support that in our server, proving the RESTCONF media types can be ignored
because there is enough context in the request to deduce the schema.

I think the media types add some strong typing.
Not sure if that is important or not.

Hello, I wanted to take the opportunity to address the Netconf list...

First of all: The way that 2) is proposed has a typo. It should be applicat= ion/yang-data+xml and application/yang-data+json, not -xml and -json. + is = for "structured syntax suffixes", which applies here.

Officially (from the media-types perspective) either 1) or 2) could work, d= epending on various engineering and administrative considerations. In this = case, those considerations are about module routing, protocol advertisement= , and effort to register new types.

You could, theoretically, dump all media types and use application/xml and = application/json. But that invites a performance impact in that all data re= ceived as /xml or /json has to be routed through a generic XML or JSON proc= essor that has to content-sniff for the data type inside the payload. XML a= nd JSON are generic data formats; they apply as a structured syntax to innu= merable content types that semantically have nothing to do with each other.= That is one reason why + structured syntax suffixes were created. There ou= ght to be a performance increase by moving the data routing to a different = part of the parsing chain, discriminating based solely on the media type (a= single case-insensitive string comparison operation).

Registering additional media types means you have to fill out (and have app= roved) a registration template for each new media type. Therefore, there is= additional administrative overhead. Sometimes it's a formality and som= etimes it invites nitpicking. As there are more than 4 types, this weighs a= gainst including specific schema information inside the media type name.
Whether you put the schema in application/yang-NAME or in a parameter appli= cation/yang-data; module=3DNAME (or whatever), it's clear that the modu= le name is duplicated inside the payload. This invites conflict. What if th= e response is labeled application/yang-operation+json but the content is &q= uot;ietf-restconf:errors"? What is the proper behavior?

Having reviewed the RESTCONF drafts closely, my engineering opinion is in f= avor of 2), making the type parameter OPTIONAL (unless it can be shown that= the payload is not sufficient to discriminate the YANG data type).

The registration of application/yang-data is well-justified because it is i= nstance data while application/yang is (apparently) schema data.

Once you know it's "YANG Data", you know that a YANG processo= r has to grok the data anyway; a robust YANG processor ought to be able to = handle all of the proposed types (or conversely, be aware of its own limita= tions). By making the YANG type/sub-type optional, you're saying that i= t's a hint. At the same time, your workflow can do some preliminary rou= ting based on the parameter without needing to invoke XML or JSON parsing, = so there is operational value in defining the parameter. Compare with appli= cation/cms, RFC 7193 (and predecessor, application/pkcs7-mime).

In some formats, a type parameter might be REQUIRED. For example, I underst= and that CBOR is being considered as a data format. If you decide not to pu= t the discriminator in the CBOR payload, then the type parameter would be R= EQUIRED for +cbor, rather than OPTIONAL.



I just had a meeting wi= th our developer who wrote our RESTCONF server code
that processe= s the HTTP request.=C2=A0 Only the suffix is relevant in the Content-Type.<= /div>
There are no cases where the RESTCONF media type is needed becaus= e the
request URI and/or message-body is ambiguous.=C2=A0 It is o= nly used to return an error if it is wrong.

Option= 3:

=C2=A0 =C2=A0Register 2 media types:
=C2=A0 =C2=A0 =C2=A0 =C2=A0application/yang-data+xml
=C2=A0 =C2= =A0 =C2=A0 =C2=A0application/yang-data+json

=C2=A0= =C2=A0No parameters are needed


The= +xml is not equivalent to application/xml. It is usually "anydata&quo= t;, not "anyxml".
Unless the YANG node really is from a= n anyxml-stmt.
(Valid application/yang-data+xml is also valid XML= )

The +json is not equivalent to application/json.=
It requires draft-ietf-netmod-yang-json and draft-ietf-netmod-ya= ng-metadata syntax.
(Valid application/yang-data+json is als= o valid JSON)



Regards,

Sean



Andy
=C2=A0

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

--001a1144f9d81d908d0535d06325-- From nobody Wed Jun 22 04:15:47 2016 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 BC8B812D0C0 for ; Wed, 22 Jun 2016 04:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 Zb-RBNn0QOT4 for ; Wed, 22 Jun 2016 04:15:44 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C52812D0B9 for ; Wed, 22 Jun 2016 04:15:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 31B349D4; Wed, 22 Jun 2016 13:15:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id yeF7go5o315Z; Wed, 22 Jun 2016 13:15:40 +0200 (CEST) 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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 22 Jun 2016 13:15:42 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6BABB20054; Wed, 22 Jun 2016 13:15:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id t2jlNl4uQpRF; Wed, 22 Jun 2016 13:15:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 45FB220047; Wed, 22 Jun 2016 13:15:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7C86E3B302D0; Wed, 22 Jun 2016 13:15:39 +0200 (CEST) Date: Wed, 22 Jun 2016 13:15:39 +0200 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20160622111539.GA43905@elstar.local> Mail-Followup-To: Robert Wilton , netconf@ietf.org References: <7a655427-0625-744a-1e5e-7e07aea4e11c@hq.sk> <20160621094628.GA41804@elstar.local> <20160621.122117.332960881532664788.mbj@tail-f.com> <34773154-f55f-9085-35fb-13e44d5b535a@cisco.com> <20160621121914.GA42059@elstar.local> <35929fa6-fa32-9406-fc2c-47c83ed02307@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <35929fa6-fa32-9406-fc2c-47c83ed02307@cisco.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 11:15:46 -0000 On Tue, Jun 21, 2016 at 01:44:15PM +0100, Robert Wilton wrote: > > > On 21/06/2016 13:19, Juergen Schoenwaelder wrote: > > On Tue, Jun 21, 2016 at 11:50:38AM +0100, Robert Wilton wrote: > > > This is one of the reasons why I prefer having only 2 datastores (i.e. > > > intended + operational state (inc applied config)) rather than the 3 > > > described above. > > I fail to see why the # of datastores matters. > Because if you regard that for an existing server intended=applied, and > ignore system created config, then for the definition that I propose: > > running config + config=false nodes == operational state ds. > I meant to say it is not relevant for this thread. I am not sure we should hijack this thread to discuss different datastore proposals. > As such, I think that it should be possible to find a viable upgrade path > from an existing NETCONF/RESTCONF server to the new datastore definitions. > > I believe that with the definition of the operational-state ds that you have > proposed, this is not true, i.e. > running config + config=false nodes != operational state ds. > > I might be missing something, but it looks like upgrading to > NETCONF/RESTCONF to the definition that you propose is significantly more > work because the operational state ds doesn't necessarily reflect the actual > running configuration at all (or certainly not in a way that a client can > even programmatically rely on). I think "my" proposed definition of an operational state datastore pretty much matches what is called so far 'operational state' in the NETCONF/YANG world. /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 Wed Jun 22 04:19:18 2016 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 2AE1912D0BD for ; Wed, 22 Jun 2016 04:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 gPguqijZn60l for ; Wed, 22 Jun 2016 04:19:15 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8168012D099 for ; Wed, 22 Jun 2016 04:19:15 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4AEAFE7D; Wed, 22 Jun 2016 13:19:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id QPbxFCp5e5Wd; Wed, 22 Jun 2016 13:19:11 +0200 (CEST) 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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 22 Jun 2016 13:19:13 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6BFF820054; Wed, 22 Jun 2016 13:19:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5vGRNL6LAgqG; Wed, 22 Jun 2016 13:19:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8BEAC20047; Wed, 22 Jun 2016 13:19:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6411A3B3031A; Wed, 22 Jun 2016 13:19:12 +0200 (CEST) Date: Wed, 22 Jun 2016 13:19:12 +0200 From: Juergen Schoenwaelder To: "Dale R. Worley" Message-ID: <20160622111912.GB43905@elstar.local> Mail-Followup-To: "Dale R. Worley" , Robert Varga , netconf@ietf.org References: <8760t2poho.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8760t2poho.fsf@hobgoblin.ariadne.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF content=all on conflicts?, Re: RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 11:19:17 -0000 On Tue, Jun 21, 2016 at 11:09:55AM -0400, Dale R. Worley wrote: > Robert Varga writes: > > That is a good question, I had to look this one up -- it takes just the > > oper state (and assumes config was already mirrored). That feels like > > something that should be changed. > > Speaking based only on reading 6020bis and restconf, it seems to me that > the "device" has a "running" data tree, some items of which are > "configuration" (settable by Netconf et al.) and some of which are > "state" (set by the device). This is not 100% correct. See the definitions of configuration data and configuration datastore imported from RFC 6241. /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 Wed Jun 22 04:29:23 2016 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 2CCE112D0E6 for ; Wed, 22 Jun 2016 04:29:22 -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 o1XcQEf2fjqY for ; Wed, 22 Jun 2016 04:29:19 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3D96D12D0CF for ; Wed, 22 Jun 2016 04:29:19 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 691381CC02C8; Wed, 22 Jun 2016 13:29:18 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Sean Leonard In-Reply-To: References: <5F59F1E8-62E8-4AE9-9E51-DB4E506C3C80@nic.cz> <326DE836-9AD6-4132-9F7C-938BAA729D71@nic.cz> <5f5ccb91-69c5-8677-0906-e62800535394@seantek.com> User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 22 Jun 2016 13:29:27 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 11:29:22 -0000 Andy Bierman writes: > On Tue, Jun 21, 2016 at 9:40 AM, Sean Leonard wrote: > >> On 6/21/2016, people said: >> >> > >> >> The media type definitions in RESTCONF-13 are incorrect. >> We cannot make subtypes for application/yang. >> Each RESTCONF (and YANG Patch) media type has >> to be registered. >> >> >> Approach 1) hard-wired types >> >> >> RESTCONF would register 10 media types and YANG Patch 4 media types >> if we use the hardwired approach. >> >> application/yang-api+xml >> application/yang-api+json >> application/yang-datastore+xml >> application/yang-datastore+json >> [etc.] >> >> Any new media types would need to be registered. >> No usage of the restconf-media-type is possible besides >> this list of media types for RESTCONF and YANG Patch >> without additional registrations. >> >> Approach 2) generic types with a parameter >> >> A parameter approach would allow YANG to be used to define any >> message content schema. E.g., a mandatory "type" parameter >> that specifies the module and name of the restconf-media-type. >> >> Only 2 media type need to be registered for every media-type >> that could ever be specified (SDO or vendor) >> >> application/yang-data-xml;type=: >> application/yang-data-json;type=: >> >> application/yang-data-xml;type=ietf-restconf:api >> application/yang-data-json;type=ietf-restconf:api >> [etc.] >> >> If you have a preference how this issue is resolved, send comments. >> >> > >> >> Then people said: >> >>> Shouldn't the action be invoked with >>>> >>>> POST /restconf/data/foo/bar >>>> >>> yes -- the URIs will be different. >>> >>> I don't see what problem it solves to change it now. >>> Either we think RESTCONF-specific media types help or they should all be >>> removed. >>> >>> To take this argument to the logical conclusion, we could dump all the >>> media types >>> and just use application/xml and application/json. >>> >>> In fact, we support that in our server, proving the RESTCONF media types >>> can be ignored >>> because there is enough context in the request to deduce the schema. >>> >>> I think the media types add some strong typing. >>> Not sure if that is important or not. >>> >> >> Hello, I wanted to take the opportunity to address the Netconf list... >> >> First of all: The way that 2) is proposed has a typo. It should be >> application/yang-data+xml and application/yang-data+json, not -xml and >> -json. + is for "structured syntax suffixes", which applies here. >> >> Officially (from the media-types perspective) either 1) or 2) could work, >> depending on various engineering and administrative considerations. In this >> case, those considerations are about module routing, protocol >> advertisement, and effort to register new types. >> >> You could, theoretically, dump all media types and use application/xml and >> application/json. But that invites a performance impact in that all data >> received as /xml or /json has to be routed through a generic XML or JSON >> processor that has to content-sniff for the data type inside the payload. >> XML and JSON are generic data formats; they apply as a structured syntax to >> innumerable content types that semantically have nothing to do with each >> other. That is one reason why + structured syntax suffixes were created. >> There ought to be a performance increase by moving the data routing to a >> different part of the parsing chain, discriminating based solely on the >> media type (a single case-insensitive string comparison operation). >> >> Registering additional media types means you have to fill out (and have >> approved) a registration template for each new media type. Therefore, there >> is additional administrative overhead. Sometimes it's a formality and >> sometimes it invites nitpicking. As there are more than 4 types, this >> weighs against including specific schema information inside the media type >> name. >> >> Whether you put the schema in application/yang-NAME or in a parameter >> application/yang-data; module=NAME (or whatever), it's clear that the >> module name is duplicated inside the payload. This invites conflict. What >> if the response is labeled application/yang-operation+json but the content >> is "ietf-restconf:errors"? What is the proper behavior? >> >> Having reviewed the RESTCONF drafts closely, my engineering opinion is in >> favor of 2), making the type parameter OPTIONAL (unless it can be shown >> that the payload is not sufficient to discriminate the YANG data type). >> >> The registration of application/yang-data is well-justified because it is >> instance data while application/yang is (apparently) schema data. >> >> Once you know it's "YANG Data", you know that a YANG processor has to grok >> the data anyway; a robust YANG processor ought to be able to handle all of >> the proposed types (or conversely, be aware of its own limitations). By >> making the YANG type/sub-type optional, you're saying that it's a hint. At >> the same time, your workflow can do some preliminary routing based on the >> parameter without needing to invoke XML or JSON parsing, so there is >> operational value in defining the parameter. Compare with application/cms, >> RFC 7193 (and predecessor, application/pkcs7-mime). >> >> In some formats, a type parameter might be REQUIRED. For example, I >> understand that CBOR is being considered as a data format. If you decide >> not to put the discriminator in the CBOR payload, then the type parameter >> would be REQUIRED for +cbor, rather than OPTIONAL. >> >> > > I just had a meeting with our developer who wrote our RESTCONF server code > that processes the HTTP request. Only the suffix is relevant in the > Content-Type. > There are no cases where the RESTCONF media type is needed because the > request URI and/or message-body is ambiguous. It is only used to return an > error if it is wrong. > > Option 3: > > Register 2 media types: > application/yang-data+xml > application/yang-data+json Whilst I proposed a reduction of media types, this seems too much to me. For one, "application/yang-patch" is IMO needed because (presumably) other patch format may be used with the PATCH method, and without getting the proper media type the receiving application can only try to guess the format. Lada > > No parameters are needed > > > The +xml is not equivalent to application/xml. It is usually "anydata", not > "anyxml". > Unless the YANG node really is from an anyxml-stmt. > (Valid application/yang-data+xml is also valid XML) > > The +json is not equivalent to application/json. > It requires draft-ietf-netmod-yang-json and draft-ietf-netmod-yang-metadata > syntax. > (Valid application/yang-data+json is also valid JSON) > > > > Regards, >> >> Sean >> >> > > Andy > > >> >> _______________________________________________ >> 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jun 22 07:00:48 2016 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 E8DBA12D523 for ; Wed, 22 Jun 2016 07:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 t1IavMIB1wGx for ; Wed, 22 Jun 2016 07:00:43 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 C362C12D51D for ; Wed, 22 Jun 2016 07:00:42 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id d185so63047335vkg.0 for ; Wed, 22 Jun 2016 07:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vyWVc1R0UEadPNkFv5QtO4JZK+5kM/ccv8ws/NnfxH8=; b=fe1EZIhm3wWIYWx2fAwB3m5fs4hmFtLsAw9cIqyiMLKgo9RcFJgEyatqSXDHckT7b4 ThHzveo+aeJay8lVmGfkreRFHTC4GoGbmrdvvocH+aaWyjnd71ygD9+5TmvvLLGcdRhm LDSir01wJ8KI04CKcwcV3FddpLDOhtPKn1FWFcGFGui+D9W1l71Aggka8WTqgxfEAcqH VoM+RawB6jgoZQN4SRLrntb3rHCdBfjmsH+4y8a08Z4vYLQiSM7SXUXX+3ZixdqyYYse UE9N+RVFNjWNuP9v8HvzXzEfGkBpUrz2bK/WHPNCEHdUjcqWNco2QsPBV4J3v3aWWhm8 t2pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vyWVc1R0UEadPNkFv5QtO4JZK+5kM/ccv8ws/NnfxH8=; b=fQOPUzxK2cpeCAE7Bm+FPjQytQNkGMVlQj5flW6JjmRZJdmlVlqytgpu+Blpl75RJb ZHfCbCGcWCV694SJjaGMeOLa3NuEHA3giaDsE6Hs2S6Bp8kPupNU291DR9TK+5dkUB9r LcrCGxstwacARhAD/+ydwVDaNbkWY/0TcMBMwbukbXkGOH0RozI4HsqJT6SN+SIxU/mP C3AA/8brYttY5ZRQeYO+NrmrPWJ4Bif9Uis29+wtJayeS5qBDhyqjJLRjSwFWTszRmSb +TkHDKhfT2ionk2tYNDP9G3bNy1G15t8C+hQPQA8PhbhVSkRS30LmP3WA5uDq6PM6/fS eYhA== X-Gm-Message-State: ALyK8tJtquh25jvawZywRQocrgKF7Kq0aYqJ6QGcvzfgH4voO5h+8BHE7ucpaI5uHunZMS4SvUY9J7knHTvRtA== X-Received: by 10.31.5.80 with SMTP id 77mr12550321vkf.132.1466604041471; Wed, 22 Jun 2016 07:00:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Wed, 22 Jun 2016 07:00:40 -0700 (PDT) In-Reply-To: References: <5F59F1E8-62E8-4AE9-9E51-DB4E506C3C80@nic.cz> <326DE836-9AD6-4132-9F7C-938BAA729D71@nic.cz> <5f5ccb91-69c5-8677-0906-e62800535394@seantek.com> From: Andy Bierman Date: Wed, 22 Jun 2016 07:00:40 -0700 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1143db92eb502b0535de5c2e Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 14:00:47 -0000 --001a1143db92eb502b0535de5c2e Content-Type: text/plain; charset=UTF-8 On Wed, Jun 22, 2016 at 4:29 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Tue, Jun 21, 2016 at 9:40 AM, Sean Leonard > wrote: > > > >> On 6/21/2016, people said: > >> > >> > > >> > >> The media type definitions in RESTCONF-13 are incorrect. > >> We cannot make subtypes for application/yang. > >> Each RESTCONF (and YANG Patch) media type has > >> to be registered. > >> > >> > >> Approach 1) hard-wired types > >> > >> > >> RESTCONF would register 10 media types and YANG Patch 4 media types > >> if we use the hardwired approach. > >> > >> application/yang-api+xml > >> application/yang-api+json > >> application/yang-datastore+xml > >> application/yang-datastore+json > >> [etc.] > >> > >> Any new media types would need to be registered. > >> No usage of the restconf-media-type is possible besides > >> this list of media types for RESTCONF and YANG Patch > >> without additional registrations. > >> > >> Approach 2) generic types with a parameter > >> > >> A parameter approach would allow YANG to be used to define any > >> message content schema. E.g., a mandatory "type" parameter > >> that specifies the module and name of the restconf-media-type. > >> > >> Only 2 media type need to be registered for every media-type > >> that could ever be specified (SDO or vendor) > >> > >> application/yang-data-xml;type=: > >> application/yang-data-json;type=: > >> > >> application/yang-data-xml;type=ietf-restconf:api > >> application/yang-data-json;type=ietf-restconf:api > >> [etc.] > >> > >> If you have a preference how this issue is resolved, send comments. > >> > >> > > >> > >> Then people said: > >> > >>> Shouldn't the action be invoked with > >>>> > >>>> POST /restconf/data/foo/bar > >>>> > >>> yes -- the URIs will be different. > >>> > >>> I don't see what problem it solves to change it now. > >>> Either we think RESTCONF-specific media types help or they should all > be > >>> removed. > >>> > >>> To take this argument to the logical conclusion, we could dump all the > >>> media types > >>> and just use application/xml and application/json. > >>> > >>> In fact, we support that in our server, proving the RESTCONF media > types > >>> can be ignored > >>> because there is enough context in the request to deduce the schema. > >>> > >>> I think the media types add some strong typing. > >>> Not sure if that is important or not. > >>> > >> > >> Hello, I wanted to take the opportunity to address the Netconf list... > >> > >> First of all: The way that 2) is proposed has a typo. It should be > >> application/yang-data+xml and application/yang-data+json, not -xml and > >> -json. + is for "structured syntax suffixes", which applies here. > >> > >> Officially (from the media-types perspective) either 1) or 2) could > work, > >> depending on various engineering and administrative considerations. In > this > >> case, those considerations are about module routing, protocol > >> advertisement, and effort to register new types. > >> > >> You could, theoretically, dump all media types and use application/xml > and > >> application/json. But that invites a performance impact in that all data > >> received as /xml or /json has to be routed through a generic XML or JSON > >> processor that has to content-sniff for the data type inside the > payload. > >> XML and JSON are generic data formats; they apply as a structured > syntax to > >> innumerable content types that semantically have nothing to do with each > >> other. That is one reason why + structured syntax suffixes were created. > >> There ought to be a performance increase by moving the data routing to a > >> different part of the parsing chain, discriminating based solely on the > >> media type (a single case-insensitive string comparison operation). > >> > >> Registering additional media types means you have to fill out (and have > >> approved) a registration template for each new media type. Therefore, > there > >> is additional administrative overhead. Sometimes it's a formality and > >> sometimes it invites nitpicking. As there are more than 4 types, this > >> weighs against including specific schema information inside the media > type > >> name. > >> > >> Whether you put the schema in application/yang-NAME or in a parameter > >> application/yang-data; module=NAME (or whatever), it's clear that the > >> module name is duplicated inside the payload. This invites conflict. > What > >> if the response is labeled application/yang-operation+json but the > content > >> is "ietf-restconf:errors"? What is the proper behavior? > >> > >> Having reviewed the RESTCONF drafts closely, my engineering opinion is > in > >> favor of 2), making the type parameter OPTIONAL (unless it can be shown > >> that the payload is not sufficient to discriminate the YANG data type). > >> > >> The registration of application/yang-data is well-justified because it > is > >> instance data while application/yang is (apparently) schema data. > >> > >> Once you know it's "YANG Data", you know that a YANG processor has to > grok > >> the data anyway; a robust YANG processor ought to be able to handle all > of > >> the proposed types (or conversely, be aware of its own limitations). By > >> making the YANG type/sub-type optional, you're saying that it's a hint. > At > >> the same time, your workflow can do some preliminary routing based on > the > >> parameter without needing to invoke XML or JSON parsing, so there is > >> operational value in defining the parameter. Compare with > application/cms, > >> RFC 7193 (and predecessor, application/pkcs7-mime). > >> > >> In some formats, a type parameter might be REQUIRED. For example, I > >> understand that CBOR is being considered as a data format. If you decide > >> not to put the discriminator in the CBOR payload, then the type > parameter > >> would be REQUIRED for +cbor, rather than OPTIONAL. > >> > >> > > > > I just had a meeting with our developer who wrote our RESTCONF server > code > > that processes the HTTP request. Only the suffix is relevant in the > > Content-Type. > > There are no cases where the RESTCONF media type is needed because the > > request URI and/or message-body is ambiguous. It is only used to return > an > > error if it is wrong. > > > > Option 3: > > > > Register 2 media types: > > application/yang-data+xml > > application/yang-data+json > > Whilst I proposed a reduction of media types, this seems too much to > me. For one, "application/yang-patch" is IMO needed because (presumably) > other patch format may be used with the PATCH method, and without > getting the proper media type the receiving application can only try to > guess the format. > > I agree application/yang-patch is needed. Option 3: Register 4 media types: application/yang-data+xml application/yang-data+json application/yang-patch+xml application/yang-patch+json > Lada > > Andy > > > > No parameters are needed > > > > > > The +xml is not equivalent to application/xml. It is usually "anydata", > not > > "anyxml". > > Unless the YANG node really is from an anyxml-stmt. > > (Valid application/yang-data+xml is also valid XML) > > > > The +json is not equivalent to application/json. > > It requires draft-ietf-netmod-yang-json and > draft-ietf-netmod-yang-metadata > > syntax. > > (Valid application/yang-data+json is also valid JSON) > > > > > > > > Regards, > >> > >> Sean > >> > >> > > > > Andy > > > > > >> > >> _______________________________________________ > >> 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 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --001a1143db92eb502b0535de5c2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 22, 2016 at 4:29 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Andy Bierman <andy@yumaworks.com> writes:

> On Tue, Jun 21, 2016 at 9:40 AM, Sean Leonard <dev+ietf@seantek.com> wrote:
>
>> On 6/21/2016, people said:
>>
>> >
>>
>> The media type definitions in RESTCONF-13 are incorrect.
>> We cannot make subtypes for application/yang.
>> Each RESTCONF (and YANG Patch) media type has
>> to be registered.
>>
>>
>> Approach 1) hard-wired types
>>
>>
>> RESTCONF would register 10 media types and YANG Patch 4 media type= s
>> if we use the hardwired approach.
>>
>>=C2=A0 =C2=A0 application/yang-api+xml
>>=C2=A0 =C2=A0 application/yang-api+json
>>=C2=A0 =C2=A0 application/yang-datastore+xml
>>=C2=A0 =C2=A0 application/yang-datastore+json
>> [etc.]
>>
>> Any new media types would need to be registered.
>> No usage of the restconf-media-type is possible besides
>> this list of media types for RESTCONF and YANG Patch
>> without additional registrations.
>>
>> Approach 2) generic types with a parameter
>>
>> A parameter approach would allow YANG to be used to define any
>> message content schema.=C2=A0 E.g., a mandatory "type" p= arameter
>> that specifies the module and name of the restconf-media-type.
>>
>> Only 2 media type need to be registered for every media-type
>> that could ever be specified (SDO or vendor)
>>
>>=C2=A0 =C2=A0 application/yang-data-xml;type=3D<module>:<n= ame>
>>=C2=A0 =C2=A0 application/yang-data-json;type=3D<module>:<= name>
>>
>>=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-restconf:api >>=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-restconf:api >> [etc.]
>>
>> If you have a preference how this issue is resolved, send comments= .
>>
>> >
>>
>> Then people said:
>>
>>> Shouldn't the action be invoked with
>>>>
>>>> POST /restconf/data/foo/bar
>>>>
>>> yes -- the URIs will be different.
>>>
>>> I don't see what problem it solves to change it now.
>>> Either we think RESTCONF-specific media types help or they sho= uld all be
>>> removed.
>>>
>>> To take this argument to the logical conclusion, we could dump= all the
>>> media types
>>> and just use application/xml and application/json.
>>>
>>> In fact, we support that in our server, proving the RESTCONF m= edia types
>>> can be ignored
>>> because there is enough context in the request to deduce the s= chema.
>>>
>>> I think the media types add some strong typing.
>>> Not sure if that is important or not.
>>>
>>
>> Hello, I wanted to take the opportunity to address the Netconf lis= t...
>>
>> First of all: The way that 2) is proposed has a typo. It should be=
>> application/yang-data+xml and application/yang-data+json, not -xml= and
>> -json. + is for "structured syntax suffixes", which appl= ies here.
>>
>> Officially (from the media-types perspective) either 1) or 2) coul= d work,
>> depending on various engineering and administrative considerations= . In this
>> case, those considerations are about module routing, protocol
>> advertisement, and effort to register new types.
>>
>> You could, theoretically, dump all media types and use application= /xml and
>> application/json. But that invites a performance impact in that al= l data
>> received as /xml or /json has to be routed through a generic XML o= r JSON
>> processor that has to content-sniff for the data type inside the p= ayload.
>> XML and JSON are generic data formats; they apply as a structured = syntax to
>> innumerable content types that semantically have nothing to do wit= h each
>> other. That is one reason why + structured syntax suffixes were cr= eated.
>> There ought to be a performance increase by moving the data routin= g to a
>> different part of the parsing chain, discriminating based solely o= n the
>> media type (a single case-insensitive string comparison operation)= .
>>
>> Registering additional media types means you have to fill out (and= have
>> approved) a registration template for each new media type. Therefo= re, there
>> is additional administrative overhead. Sometimes it's a formal= ity and
>> sometimes it invites nitpicking. As there are more than 4 types, t= his
>> weighs against including specific schema information inside the me= dia type
>> name.
>>
>> Whether you put the schema in application/yang-NAME or in a parame= ter
>> application/yang-data; module=3DNAME (or whatever), it's clear= that the
>> module name is duplicated inside the payload. This invites conflic= t. What
>> if the response is labeled application/yang-operation+json but the= content
>> is "ietf-restconf:errors"? What is the proper behavior?<= br> >>
>> Having reviewed the RESTCONF drafts closely, my engineering opinio= n is in
>> favor of 2), making the type parameter OPTIONAL (unless it can be = shown
>> that the payload is not sufficient to discriminate the YANG data t= ype).
>>
>> The registration of application/yang-data is well-justified becaus= e it is
>> instance data while application/yang is (apparently) schema data.<= br> >>
>> Once you know it's "YANG Data", you know that a YANG= processor has to grok
>> the data anyway; a robust YANG processor ought to be able to handl= e all of
>> the proposed types (or conversely, be aware of its own limitations= ). By
>> making the YANG type/sub-type optional, you're saying that it&= #39;s a hint. At
>> the same time, your workflow can do some preliminary routing based= on the
>> parameter without needing to invoke XML or JSON parsing, so there = is
>> operational value in defining the parameter. Compare with applicat= ion/cms,
>> RFC 7193 (and predecessor, application/pkcs7-mime).
>>
>> In some formats, a type parameter might be REQUIRED. For example, = I
>> understand that CBOR is being considered as a data format. If you = decide
>> not to put the discriminator in the CBOR payload, then the type pa= rameter
>> would be REQUIRED for +cbor, rather than OPTIONAL.
>>
>>
>
> I just had a meeting with our developer who wrote our RESTCONF server = code
> that processes the HTTP request.=C2=A0 Only the suffix is relevant in = the
> Content-Type.
> There are no cases where the RESTCONF media type is needed because the=
> request URI and/or message-body is ambiguous.=C2=A0 It is only used to= return an
> error if it is wrong.
>
> Option 3:
>
>=C2=A0 =C2=A0 Register 2 media types:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 application/yang-data+xml
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 application/yang-data+json

Whilst I proposed a reduction of media types, this seems too much to
me. For one, "application/yang-patch" is IMO needed because (pres= umably)
other patch format may be used with the PATCH method, and without
getting the proper media type the receiving application can only try to
guess the format.


I agree application/yang-patch is need= ed.

=C2=A0 Option 3:
=C2=A0
=C2=A0 =C2=A0 = =C2=A0 Register 4 media types:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0applica= tion/yang-data+xml
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0application/yang-da= ta+json
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0application/ya= ng-patch+xml
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0application/yang-patch+js= on


=C2=A0
Lada



Andy
=C2=A0
>
>=C2=A0 =C2=A0 No parameters are needed
>
>
> The +xml is not equivalent to application/xml. It is usually "any= data", not
> "anyxml".
> Unless the YANG node really is from an anyxml-stmt.
> (Valid application/yang-data+xml is also valid XML)
>
> The +json is not equivalent to application/json.
> It requires draft-ietf-netmod-yang-json and draft-ietf-netmod-yang-met= adata
> syntax.
> (Valid application/yang-data+json is also valid JSON)
>
>
>
> Regards,
>>
>> Sean
>>
>>
>
> Andy
>
>
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf<= /a>
>>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf<= br>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

--001a1143db92eb502b0535de5c2e-- From nobody Wed Jun 22 08:15:01 2016 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 2A0E512DDAD for ; Wed, 22 Jun 2016 08:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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, RP_MATCHES_RCVD=-1.426] 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 P1CJilVcYs3E for ; Wed, 22 Jun 2016 08:14:56 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E5912DB16 for ; Wed, 22 Jun 2016 08:02:34 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:f93f:b923:db7b:bd00] (unknown [IPv6:2001:718:1a02:1:f93f:b923:db7b:bd00]) by mail.nic.cz (Postfix) with ESMTPSA id 556836083D; Wed, 22 Jun 2016 17:02:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1466607753; bh=sBdP/eK3yGwGm9FluOEZtc1mmaIeLP7EzvTuIDl3WiE=; h=From:Date:To; b=qIl7rBAcq2vWsHMIXG1INi0JKQ4orqHV7xAAZme3YrXViyJZLykeH173ufgsKZTJA FxYSCl64tDRm3fEmXwk16oXHPriYPaj9U+O5dv0xtoVh1SV2guNJmqVDbL7zfNEJRH LY6TnxircN2l6GBu6kEUY6QDDiAnLT2Ky2qTIN5g= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 22 Jun 2016 17:02:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6BB6C342-5EAA-4934-B48A-889CFBE3E118@nic.cz> References: <5F59F1E8-62E8-4AE9-9E51-DB4E506C3C80@nic.cz> <326DE836-9AD6-4132-9F7C-938BAA729D71@nic.cz> <5f5ccb91-69c5-8677-0906-e62800535394@seantek.com> To: Andy Bierman X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 15:14:59 -0000 > On 22 Jun 2016, at 16:00, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Jun 22, 2016 at 4:29 AM, Ladislav Lhotka = wrote: > Andy Bierman writes: >=20 > > On Tue, Jun 21, 2016 at 9:40 AM, Sean Leonard = wrote: > > > >> On 6/21/2016, people said: > >> > >> > > >> > >> The media type definitions in RESTCONF-13 are incorrect. > >> We cannot make subtypes for application/yang. > >> Each RESTCONF (and YANG Patch) media type has > >> to be registered. > >> > >> > >> Approach 1) hard-wired types > >> > >> > >> RESTCONF would register 10 media types and YANG Patch 4 media types > >> if we use the hardwired approach. > >> > >> application/yang-api+xml > >> application/yang-api+json > >> application/yang-datastore+xml > >> application/yang-datastore+json > >> [etc.] > >> > >> Any new media types would need to be registered. > >> No usage of the restconf-media-type is possible besides > >> this list of media types for RESTCONF and YANG Patch > >> without additional registrations. > >> > >> Approach 2) generic types with a parameter > >> > >> A parameter approach would allow YANG to be used to define any > >> message content schema. E.g., a mandatory "type" parameter > >> that specifies the module and name of the restconf-media-type. > >> > >> Only 2 media type need to be registered for every media-type > >> that could ever be specified (SDO or vendor) > >> > >> application/yang-data-xml;type=3D: > >> application/yang-data-json;type=3D: > >> > >> application/yang-data-xml;type=3Dietf-restconf:api > >> application/yang-data-json;type=3Dietf-restconf:api > >> [etc.] > >> > >> If you have a preference how this issue is resolved, send comments. > >> > >> > > >> > >> Then people said: > >> > >>> Shouldn't the action be invoked with > >>>> > >>>> POST /restconf/data/foo/bar > >>>> > >>> yes -- the URIs will be different. > >>> > >>> I don't see what problem it solves to change it now. > >>> Either we think RESTCONF-specific media types help or they should = all be > >>> removed. > >>> > >>> To take this argument to the logical conclusion, we could dump all = the > >>> media types > >>> and just use application/xml and application/json. > >>> > >>> In fact, we support that in our server, proving the RESTCONF media = types > >>> can be ignored > >>> because there is enough context in the request to deduce the = schema. > >>> > >>> I think the media types add some strong typing. > >>> Not sure if that is important or not. > >>> > >> > >> Hello, I wanted to take the opportunity to address the Netconf = list... > >> > >> First of all: The way that 2) is proposed has a typo. It should be > >> application/yang-data+xml and application/yang-data+json, not -xml = and > >> -json. + is for "structured syntax suffixes", which applies here. > >> > >> Officially (from the media-types perspective) either 1) or 2) could = work, > >> depending on various engineering and administrative considerations. = In this > >> case, those considerations are about module routing, protocol > >> advertisement, and effort to register new types. > >> > >> You could, theoretically, dump all media types and use = application/xml and > >> application/json. But that invites a performance impact in that all = data > >> received as /xml or /json has to be routed through a generic XML or = JSON > >> processor that has to content-sniff for the data type inside the = payload. > >> XML and JSON are generic data formats; they apply as a structured = syntax to > >> innumerable content types that semantically have nothing to do with = each > >> other. That is one reason why + structured syntax suffixes were = created. > >> There ought to be a performance increase by moving the data routing = to a > >> different part of the parsing chain, discriminating based solely on = the > >> media type (a single case-insensitive string comparison operation). > >> > >> Registering additional media types means you have to fill out (and = have > >> approved) a registration template for each new media type. = Therefore, there > >> is additional administrative overhead. Sometimes it's a formality = and > >> sometimes it invites nitpicking. As there are more than 4 types, = this > >> weighs against including specific schema information inside the = media type > >> name. > >> > >> Whether you put the schema in application/yang-NAME or in a = parameter > >> application/yang-data; module=3DNAME (or whatever), it's clear that = the > >> module name is duplicated inside the payload. This invites = conflict. What > >> if the response is labeled application/yang-operation+json but the = content > >> is "ietf-restconf:errors"? What is the proper behavior? > >> > >> Having reviewed the RESTCONF drafts closely, my engineering opinion = is in > >> favor of 2), making the type parameter OPTIONAL (unless it can be = shown > >> that the payload is not sufficient to discriminate the YANG data = type). > >> > >> The registration of application/yang-data is well-justified because = it is > >> instance data while application/yang is (apparently) schema data. > >> > >> Once you know it's "YANG Data", you know that a YANG processor has = to grok > >> the data anyway; a robust YANG processor ought to be able to handle = all of > >> the proposed types (or conversely, be aware of its own = limitations). By > >> making the YANG type/sub-type optional, you're saying that it's a = hint. At > >> the same time, your workflow can do some preliminary routing based = on the > >> parameter without needing to invoke XML or JSON parsing, so there = is > >> operational value in defining the parameter. Compare with = application/cms, > >> RFC 7193 (and predecessor, application/pkcs7-mime). > >> > >> In some formats, a type parameter might be REQUIRED. For example, I > >> understand that CBOR is being considered as a data format. If you = decide > >> not to put the discriminator in the CBOR payload, then the type = parameter > >> would be REQUIRED for +cbor, rather than OPTIONAL. > >> > >> > > > > I just had a meeting with our developer who wrote our RESTCONF = server code > > that processes the HTTP request. Only the suffix is relevant in the > > Content-Type. > > There are no cases where the RESTCONF media type is needed because = the > > request URI and/or message-body is ambiguous. It is only used to = return an > > error if it is wrong. > > > > Option 3: > > > > Register 2 media types: > > application/yang-data+xml > > application/yang-data+json >=20 > Whilst I proposed a reduction of media types, this seems too much to > me. For one, "application/yang-patch" is IMO needed because = (presumably) > other patch format may be used with the PATCH method, and without > getting the proper media type the receiving application can only try = to > guess the format. >=20 >=20 > I agree application/yang-patch is needed. >=20 > Option 3: > =20 > Register 4 media types: > application/yang-data+xml > application/yang-data+json > application/yang-patch+xml > application/yang-patch+json OK, this looks good to me. Lada >=20 >=20 > =20 > Lada >=20 >=20 >=20 > Andy > =20 > > > > No parameters are needed > > > > > > The +xml is not equivalent to application/xml. It is usually = "anydata", not > > "anyxml". > > Unless the YANG node really is from an anyxml-stmt. > > (Valid application/yang-data+xml is also valid XML) > > > > The +json is not equivalent to application/json. > > It requires draft-ietf-netmod-yang-json and = draft-ietf-netmod-yang-metadata > > syntax. > > (Valid application/yang-data+json is also valid JSON) > > > > > > > > Regards, > >> > >> Sean > >> > >> > > > > Andy > > > > > >> > >> _______________________________________________ > >> 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 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jun 22 09:17:34 2016 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 03A2612D6A5 for ; Wed, 22 Jun 2016 09:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 nB1p8WPDBg5K for ; Wed, 22 Jun 2016 09:17:30 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E24712D982 for ; Wed, 22 Jun 2016 09:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6375; q=dns/txt; s=iport; t=1466611982; x=1467821582; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=nXC+UBZdY9A8C4yIM6HQALpmtG4L6odMgxjBB9cS0AY=; b=HPWWrr84MTUb8MxzsrU21bsgxVKStUVXny4CPaohs6+I/0Dkj6PfunZz kQMrfYZH99WTLfGORjpZ8gEmEFLKH33d0LkfX2jMrx6+n73xMq3yGTMIa ubbwPGMq27qBo00Pp3F43ybfFqC7YX/fslxvFCSoCs7rzN2AtOj9/8yea 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgAquGpX/xbLJq1egnCBT7YFgnKCD?= =?us-ascii?q?4F6hhcCgWUUAQEBAQEBAWUnhE0BAQSBCQsYLlcTCAEBiCzEVQEBAQEGAQEBAQE?= =?us-ascii?q?BASCGJ4F3CIJOhCoJhWgFmH2OLYFph10jhTqPfB42g3E7iWGBQgEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,509,1459814400"; d="scan'208,217";a="635312110" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jun 2016 16:13:00 +0000 Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u5MGD0oF022229 for ; Wed, 22 Jun 2016 16:13:00 GMT To: netconf@ietf.org References: <7a655427-0625-744a-1e5e-7e07aea4e11c@hq.sk> <20160621094628.GA41804@elstar.local> <20160621.122117.332960881532664788.mbj@tail-f.com> <34773154-f55f-9085-35fb-13e44d5b535a@cisco.com> <20160621121914.GA42059@elstar.local> <35929fa6-fa32-9406-fc2c-47c83ed02307@cisco.com> <20160622111539.GA43905@elstar.local> From: Robert Wilton Message-ID: <6fdb30f4-5354-07cd-0ecd-7fe0ea8f91e4@cisco.com> Date: Wed, 22 Jun 2016 17:13:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160622111539.GA43905@elstar.local> Content-Type: multipart/alternative; boundary="------------816BB7A86D86781FACC7C6C8" Archived-At: Subject: Re: [Netconf] RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 16:17:33 -0000 This is a multi-part message in MIME format. --------------816BB7A86D86781FACC7C6C8 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 22/06/2016 12:15, Juergen Schoenwaelder wrote: > On Tue, Jun 21, 2016 at 01:44:15PM +0100, Robert Wilton wrote: >> >> On 21/06/2016 13:19, Juergen Schoenwaelder wrote: >>> On Tue, Jun 21, 2016 at 11:50:38AM +0100, Robert Wilton wrote: >>>> This is one of the reasons why I prefer having only 2 datastores (i.e. >>>> intended + operational state (inc applied config)) rather than the 3 >>>> described above. >>> I fail to see why the # of datastores matters. >> Because if you regard that for an existing server intended=applied, and >> ignore system created config, then for the definition that I propose: >> >> running config + config=false nodes == operational state ds. >> > I meant to say it is not relevant for this thread. I am not sure we > should hijack this thread to discuss different datastore proposals. > >> As such, I think that it should be possible to find a viable upgrade path >> from an existing NETCONF/RESTCONF server to the new datastore definitions. >> >> I believe that with the definition of the operational-state ds that you have >> proposed, this is not true, i.e. >> running config + config=false nodes != operational state ds. >> >> I might be missing something, but it looks like upgrading to >> NETCONF/RESTCONF to the definition that you propose is significantly more >> work because the operational state ds doesn't necessarily reflect the actual >> running configuration at all (or certainly not in a way that a client can >> even programmatically rely on). > I think "my" proposed definition of an operational state datastore > pretty much matches what is called so far 'operational state' in the > NETCONF/YANG world. Sorry, I don't understand this. draft-ietf-netmod-opstate-reqs defines Operational State as: Operational State: Operational State is the current state of the system as known to the various components of the system (e.g., control plane daemons, operating system kernels, line cards). The operational state includes both applied configuration and derived state. The definition in draft-schoenw excludes the applied configuration as part of the operational state datastore which I would read as being inconsistent with the definition above. Thanks, Rob > > /js > --------------816BB7A86D86781FACC7C6C8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit



On 22/06/2016 12:15, Juergen Schoenwaelder wrote:
On Tue, Jun 21, 2016 at 01:44:15PM +0100, Robert Wilton wrote:


On 21/06/2016 13:19, Juergen Schoenwaelder wrote:

On Tue, Jun 21, 2016 at 11:50:38AM +0100, Robert Wilton wrote:

This is one of the reasons why I prefer having only 2 datastores (i.e.
intended + operational state (inc applied config)) rather than the 3
described above.

I fail to see why the # of datastores matters.

Because if you regard that for an existing server intended=applied, and
ignore system created config, then for the definition that I propose:

running config + config=false nodes == operational state ds.


I meant to say it is not relevant for this thread. I am not sure we
should hijack this thread to discuss different datastore proposals.


As such, I think that it should be possible to find a viable upgrade path
from an existing NETCONF/RESTCONF server to the new datastore definitions.

I believe that with the definition of the operational-state ds that you have
proposed, this is not true, i.e.
running config + config=false nodes != operational state ds.

I might be missing something, but it looks like upgrading to
NETCONF/RESTCONF to the definition that you propose is significantly more
work because the operational state ds doesn't necessarily reflect the actual
running configuration at all (or certainly not in a way that a client can
even programmatically rely on).

I think "my" proposed definition of an operational state datastore
pretty much matches what is called so far 'operational state' in the
NETCONF/YANG world.
Sorry, I don't understand this.

draft-ietf-netmod-opstate-reqs defines Operational State as:

   Operational State:  Operational State is the current state of the
       system as known to the various components of the system (e.g.,
       control plane daemons, operating system kernels, line cards).
       The operational state includes both applied configuration and
       derived state.

The definition in draft-schoenw excludes the applied configuration as part of the operational state datastore which I would read as being inconsistent with the definition above.

Thanks,
Rob



/js

--------------816BB7A86D86781FACC7C6C8-- From nobody Wed Jun 22 18:25:41 2016 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 8BB5A12DE4E for ; Wed, 22 Jun 2016 18:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 KGs4af2tygPT for ; Wed, 22 Jun 2016 18:25:36 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 447EF12DAEC for ; Wed, 22 Jun 2016 18:25:36 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id u64so85938820vkf.3 for ; Wed, 22 Jun 2016 18:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T4ZMdKgeOFotqSC5UB/Wtuv9VeSKmtnEH4078lIbOSw=; b=2Fjj8u1LmfJRPCOQhm3eMEPf9TefhKzIG+AQMfzDJo8CSWHdjqXg7rFuxW3tvEhVHg W9tw8Pgu/qak6FzFg2/C0RgFMCnEgO4d6oi5pzRqfxVffmIUKkOZa7JKlPWIRbuiPNdI I/y0JhzGuHhQ/IuspDrsCsceTMn8/Ze6+dHJgfYs0l/c375EcmQw96RhE7Dfa7PV5Cju jM29cIVLA6pM/NxcYRpQKWMXeYb9KJ8GZLamyPfNm3baWqTiPQZ5Pl6FjLrFgp4Bql1o tre6bmOIXrQAijvi/NFZiykUChvlyuOBZjMCbzr6EGeH8Q5sw5ppBapLxas8A5GCNuz9 w/pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T4ZMdKgeOFotqSC5UB/Wtuv9VeSKmtnEH4078lIbOSw=; b=jeRAbeRAfBmhgBPI4ImqvLPEqZRr7NjtyxYUZMu1sg+IHD/6g4IVbjyTmy+WWu/jdf PJ4R5QtTeL/Qyg1MvAuOMmTNx9B1GdWwxE/ptDEavJPOYn+Nff4O6+7B5i6ZRUeTC+uP qTXMNF1wzwOtia4kuvZ+3Ivxx2deGX4VyAAVuRzh/8wkcl5mTy/0Eg2UG0XqGOBDNVQc J4iR/ADXFAhj2SpNPYs314bTUPyxbFFJP2Wuu0VDnekYjBZ++yHWZ55IZLrHTdKalRy9 rnx51H9U8acP3+7v6AK9/AE1R8wfu8OyGnzaoiXZfFbZ9JLPeLjC8pzf8vrVo5F6eded yDDw== X-Gm-Message-State: ALyK8tKwl3qiP/8oXrL+dSdiJrDOPoVNdXI2bxbNemCTnOgC8fvb8VEzz82goXhhRqLaW5VXhZpgS9zPnvaZtQ== X-Received: by 10.176.67.37 with SMTP id k34mr7500757uak.47.1466645134959; Wed, 22 Jun 2016 18:25:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Wed, 22 Jun 2016 18:25:33 -0700 (PDT) In-Reply-To: <6BB6C342-5EAA-4934-B48A-889CFBE3E118@nic.cz> References: <5F59F1E8-62E8-4AE9-9E51-DB4E506C3C80@nic.cz> <326DE836-9AD6-4132-9F7C-938BAA729D71@nic.cz> <5f5ccb91-69c5-8677-0906-e62800535394@seantek.com> <6BB6C342-5EAA-4934-B48A-889CFBE3E118@nic.cz> From: Andy Bierman Date: Wed, 22 Jun 2016 18:25:33 -0700 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=94eb2c05a69a48003a0535e7ee23 Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 01:25:39 -0000 --94eb2c05a69a48003a0535e7ee23 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 22, 2016 at 8:02 AM, Ladislav Lhotka wrote: > > > On 22 Jun 2016, at 16:00, Andy Bierman wrote: > > > > > > > > On Wed, Jun 22, 2016 at 4:29 AM, Ladislav Lhotka wrote: > > Andy Bierman writes: > > > > > On Tue, Jun 21, 2016 at 9:40 AM, Sean Leonard > wrote: > > > > > >> On 6/21/2016, people said: > > >> > > >> > > > >> > > >> The media type definitions in RESTCONF-13 are incorrect. > > >> We cannot make subtypes for application/yang. > > >> Each RESTCONF (and YANG Patch) media type has > > >> to be registered. > > >> > > >> > > >> Approach 1) hard-wired types > > >> > > >> > > >> RESTCONF would register 10 media types and YANG Patch 4 media types > > >> if we use the hardwired approach. > > >> > > >> application/yang-api+xml > > >> application/yang-api+json > > >> application/yang-datastore+xml > > >> application/yang-datastore+json > > >> [etc.] > > >> > > >> Any new media types would need to be registered. > > >> No usage of the restconf-media-type is possible besides > > >> this list of media types for RESTCONF and YANG Patch > > >> without additional registrations. > > >> > > >> Approach 2) generic types with a parameter > > >> > > >> A parameter approach would allow YANG to be used to define any > > >> message content schema. E.g., a mandatory "type" parameter > > >> that specifies the module and name of the restconf-media-type. > > >> > > >> Only 2 media type need to be registered for every media-type > > >> that could ever be specified (SDO or vendor) > > >> > > >> application/yang-data-xml;type=: > > >> application/yang-data-json;type=: > > >> > > >> application/yang-data-xml;type=ietf-restconf:api > > >> application/yang-data-json;type=ietf-restconf:api > > >> [etc.] > > >> > > >> If you have a preference how this issue is resolved, send comments. > > >> > > >> > > > >> > > >> Then people said: > > >> > > >>> Shouldn't the action be invoked with > > >>>> > > >>>> POST /restconf/data/foo/bar > > >>>> > > >>> yes -- the URIs will be different. > > >>> > > >>> I don't see what problem it solves to change it now. > > >>> Either we think RESTCONF-specific media types help or they should > all be > > >>> removed. > > >>> > > >>> To take this argument to the logical conclusion, we could dump all > the > > >>> media types > > >>> and just use application/xml and application/json. > > >>> > > >>> In fact, we support that in our server, proving the RESTCONF media > types > > >>> can be ignored > > >>> because there is enough context in the request to deduce the schema. > > >>> > > >>> I think the media types add some strong typing. > > >>> Not sure if that is important or not. > > >>> > > >> > > >> Hello, I wanted to take the opportunity to address the Netconf list... > > >> > > >> First of all: The way that 2) is proposed has a typo. It should be > > >> application/yang-data+xml and application/yang-data+json, not -xml and > > >> -json. + is for "structured syntax suffixes", which applies here. > > >> > > >> Officially (from the media-types perspective) either 1) or 2) could > work, > > >> depending on various engineering and administrative considerations. > In this > > >> case, those considerations are about module routing, protocol > > >> advertisement, and effort to register new types. > > >> > > >> You could, theoretically, dump all media types and use > application/xml and > > >> application/json. But that invites a performance impact in that all > data > > >> received as /xml or /json has to be routed through a generic XML or > JSON > > >> processor that has to content-sniff for the data type inside the > payload. > > >> XML and JSON are generic data formats; they apply as a structured > syntax to > > >> innumerable content types that semantically have nothing to do with > each > > >> other. That is one reason why + structured syntax suffixes were > created. > > >> There ought to be a performance increase by moving the data routing > to a > > >> different part of the parsing chain, discriminating based solely on > the > > >> media type (a single case-insensitive string comparison operation). > > >> > > >> Registering additional media types means you have to fill out (and > have > > >> approved) a registration template for each new media type. Therefore, > there > > >> is additional administrative overhead. Sometimes it's a formality and > > >> sometimes it invites nitpicking. As there are more than 4 types, this > > >> weighs against including specific schema information inside the media > type > > >> name. > > >> > > >> Whether you put the schema in application/yang-NAME or in a parameter > > >> application/yang-data; module=NAME (or whatever), it's clear that the > > >> module name is duplicated inside the payload. This invites conflict. > What > > >> if the response is labeled application/yang-operation+json but the > content > > >> is "ietf-restconf:errors"? What is the proper behavior? > > >> > > >> Having reviewed the RESTCONF drafts closely, my engineering opinion > is in > > >> favor of 2), making the type parameter OPTIONAL (unless it can be > shown > > >> that the payload is not sufficient to discriminate the YANG data > type). > > >> > > >> The registration of application/yang-data is well-justified because > it is > > >> instance data while application/yang is (apparently) schema data. > > >> > > >> Once you know it's "YANG Data", you know that a YANG processor has to > grok > > >> the data anyway; a robust YANG processor ought to be able to handle > all of > > >> the proposed types (or conversely, be aware of its own limitations). > By > > >> making the YANG type/sub-type optional, you're saying that it's a > hint. At > > >> the same time, your workflow can do some preliminary routing based on > the > > >> parameter without needing to invoke XML or JSON parsing, so there is > > >> operational value in defining the parameter. Compare with > application/cms, > > >> RFC 7193 (and predecessor, application/pkcs7-mime). > > >> > > >> In some formats, a type parameter might be REQUIRED. For example, I > > >> understand that CBOR is being considered as a data format. If you > decide > > >> not to put the discriminator in the CBOR payload, then the type > parameter > > >> would be REQUIRED for +cbor, rather than OPTIONAL. > > >> > > >> > > > > > > I just had a meeting with our developer who wrote our RESTCONF server > code > > > that processes the HTTP request. Only the suffix is relevant in the > > > Content-Type. > > > There are no cases where the RESTCONF media type is needed because the > > > request URI and/or message-body is ambiguous. It is only used to > return an > > > error if it is wrong. > > > > > > Option 3: > > > > > > Register 2 media types: > > > application/yang-data+xml > > > application/yang-data+json > > > > Whilst I proposed a reduction of media types, this seems too much to > > me. For one, "application/yang-patch" is IMO needed because (presumably) > > other patch format may be used with the PATCH method, and without > > getting the proper media type the receiving application can only try to > > guess the format. > > > > > > I agree application/yang-patch is needed. > > > > Option 3: > > > > Register 4 media types: > > application/yang-data+xml > > application/yang-data+json > > application/yang-patch+xml > > application/yang-patch+json > > OK, this looks good to me. > > Almost... Remember that we created the hack called "restconf-media-type" because you complained that we could not just declare a grouping. The goal here is to use YANG to define message content, so that it is easy to write but also precise and encoding-independent. This saves a lot of cut-and-paste every time a new serialization format is created for YANG. (e.g., CBOR). So now the deleted media types do not have YANG templates. I propose changing the "restconf-media-type" extension so it is called "restconf-data". It will just have a unique name as the argument, not a media-type OLD: rc:restconf-media-type "application/yang-errors" { uses errors; } rc:restconf-media-type "application/yang-api" { uses restconf; } NEW: rc:restconf-data "yang-errors" { uses errors; } rc:restconf-data "yang-api" { uses restconf; } (Similar change in YANG Patch) Lada > > Andy > > > > > > > > Lada > > > > > > > > Andy > > > > > > > > No parameters are needed > > > > > > > > > The +xml is not equivalent to application/xml. It is usually > "anydata", not > > > "anyxml". > > > Unless the YANG node really is from an anyxml-stmt. > > > (Valid application/yang-data+xml is also valid XML) > > > > > > The +json is not equivalent to application/json. > > > It requires draft-ietf-netmod-yang-json and > draft-ietf-netmod-yang-metadata > > > syntax. > > > (Valid application/yang-data+json is also valid JSON) > > > > > > > > > > > > Regards, > > >> > > >> Sean > > >> > > >> > > > > > > Andy > > > > > > > > >> > > >> _______________________________________________ > > >> 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 > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --94eb2c05a69a48003a0535e7ee23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 22, 2016 at 8:02 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 22 Jun 2016, at 16:00, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Wed, Jun 22, 2016 at 4:29 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Andy Bierman <andy@yumaworks.= com> writes:
>
> > On Tue, Jun 21, 2016 at 9:40 AM, Sean Leonard <dev+ietf@seantek.com> wrote:
> >
> >> On 6/21/2016, people said:
> >>
> >> >
> >>
> >> The media type definitions in RESTCONF-13 are incorrect.
> >> We cannot make subtypes for application/yang.
> >> Each RESTCONF (and YANG Patch) media type has
> >> to be registered.
> >>
> >>
> >> Approach 1) hard-wired types
> >>
> >>
> >> RESTCONF would register 10 media types and YANG Patch 4 media= types
> >> if we use the hardwired approach.
> >>
> >>=C2=A0 =C2=A0 application/yang-api+xml
> >>=C2=A0 =C2=A0 application/yang-api+json
> >>=C2=A0 =C2=A0 application/yang-datastore+xml
> >>=C2=A0 =C2=A0 application/yang-datastore+json
> >> [etc.]
> >>
> >> Any new media types would need to be registered.
> >> No usage of the restconf-media-type is possible besides
> >> this list of media types for RESTCONF and YANG Patch
> >> without additional registrations.
> >>
> >> Approach 2) generic types with a parameter
> >>
> >> A parameter approach would allow YANG to be used to define an= y
> >> message content schema.=C2=A0 E.g., a mandatory "type&qu= ot; parameter
> >> that specifies the module and name of the restconf-media-type= .
> >>
> >> Only 2 media type need to be registered for every media-type<= br> > >> that could ever be specified (SDO or vendor)
> >>
> >>=C2=A0 =C2=A0 application/yang-data-xml;type=3D<module>:= <name>
> >>=C2=A0 =C2=A0 application/yang-data-json;type=3D<module>= :<name>
> >>
> >>=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-restconf:a= pi
> >>=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-restconf:= api
> >> [etc.]
> >>
> >> If you have a preference how this issue is resolved, send com= ments.
> >>
> >> >
> >>
> >> Then people said:
> >>
> >>> Shouldn't the action be invoked with
> >>>>
> >>>> POST /restconf/data/foo/bar
> >>>>
> >>> yes -- the URIs will be different.
> >>>
> >>> I don't see what problem it solves to change it now.<= br> > >>> Either we think RESTCONF-specific media types help or the= y should all be
> >>> removed.
> >>>
> >>> To take this argument to the logical conclusion, we could= dump all the
> >>> media types
> >>> and just use application/xml and application/json.
> >>>
> >>> In fact, we support that in our server, proving the RESTC= ONF media types
> >>> can be ignored
> >>> because there is enough context in the request to deduce = the schema.
> >>>
> >>> I think the media types add some strong typing.
> >>> Not sure if that is important or not.
> >>>
> >>
> >> Hello, I wanted to take the opportunity to address the Netcon= f list...
> >>
> >> First of all: The way that 2) is proposed has a typo. It shou= ld be
> >> application/yang-data+xml and application/yang-data+json, not= -xml and
> >> -json. + is for "structured syntax suffixes", which= applies here.
> >>
> >> Officially (from the media-types perspective) either 1) or 2)= could work,
> >> depending on various engineering and administrative considera= tions. In this
> >> case, those considerations are about module routing, protocol=
> >> advertisement, and effort to register new types.
> >>
> >> You could, theoretically, dump all media types and use applic= ation/xml and
> >> application/json. But that invites a performance impact in th= at all data
> >> received as /xml or /json has to be routed through a generic = XML or JSON
> >> processor that has to content-sniff for the data type inside = the payload.
> >> XML and JSON are generic data formats; they apply as a struct= ured syntax to
> >> innumerable content types that semantically have nothing to d= o with each
> >> other. That is one reason why + structured syntax suffixes we= re created.
> >> There ought to be a performance increase by moving the data r= outing to a
> >> different part of the parsing chain, discriminating based sol= ely on the
> >> media type (a single case-insensitive string comparison opera= tion).
> >>
> >> Registering additional media types means you have to fill out= (and have
> >> approved) a registration template for each new media type. Th= erefore, there
> >> is additional administrative overhead. Sometimes it's a f= ormality and
> >> sometimes it invites nitpicking. As there are more than 4 typ= es, this
> >> weighs against including specific schema information inside t= he media type
> >> name.
> >>
> >> Whether you put the schema in application/yang-NAME or in a p= arameter
> >> application/yang-data; module=3DNAME (or whatever), it's = clear that the
> >> module name is duplicated inside the payload. This invites co= nflict. What
> >> if the response is labeled application/yang-operation+json bu= t the content
> >> is "ietf-restconf:errors"? What is the proper behav= ior?
> >>
> >> Having reviewed the RESTCONF drafts closely, my engineering o= pinion is in
> >> favor of 2), making the type parameter OPTIONAL (unless it ca= n be shown
> >> that the payload is not sufficient to discriminate the YANG d= ata type).
> >>
> >> The registration of application/yang-data is well-justified b= ecause it is
> >> instance data while application/yang is (apparently) schema d= ata.
> >>
> >> Once you know it's "YANG Data", you know that a= YANG processor has to grok
> >> the data anyway; a robust YANG processor ought to be able to = handle all of
> >> the proposed types (or conversely, be aware of its own limita= tions). By
> >> making the YANG type/sub-type optional, you're saying tha= t it's a hint. At
> >> the same time, your workflow can do some preliminary routing = based on the
> >> parameter without needing to invoke XML or JSON parsing, so t= here is
> >> operational value in defining the parameter. Compare with app= lication/cms,
> >> RFC 7193 (and predecessor, application/pkcs7-mime).
> >>
> >> In some formats, a type parameter might be REQUIRED. For exam= ple, I
> >> understand that CBOR is being considered as a data format. If= you decide
> >> not to put the discriminator in the CBOR payload, then the ty= pe parameter
> >> would be REQUIRED for +cbor, rather than OPTIONAL.
> >>
> >>
> >
> > I just had a meeting with our developer who wrote our RESTCONF se= rver code
> > that processes the HTTP request.=C2=A0 Only the suffix is relevan= t in the
> > Content-Type.
> > There are no cases where the RESTCONF media type is needed becaus= e the
> > request URI and/or message-body is ambiguous.=C2=A0 It is only us= ed to return an
> > error if it is wrong.
> >
> > Option 3:
> >
> >=C2=A0 =C2=A0 Register 2 media types:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 application/yang-data+xml
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 application/yang-data+json
>
> Whilst I proposed a reduction of media types, this seems too much to > me. For one, "application/yang-patch" is IMO needed because = (presumably)
> other patch format may be used with the PATCH method, and without
> getting the proper media type the receiving application can only try t= o
> guess the format.
>
>
> I agree application/yang-patch is needed.
>
>=C2=A0 =C2=A0Option 3:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Register 4 media types:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 application/yang-data+xml
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 application/yang-data+json
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 application/yang-patch+xml
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 application/yang-patch+json

OK, this looks good to me.



Almost...
Remember that we created the hack called "restconf-media-t= ype" because you complained
that we could not just declare a= grouping.=C2=A0 The goal here is to use YANG to define message content,
so that it is easy to write but also precise and encoding-independe= nt.=C2=A0 This saves a lot of cut-and-paste
every time a new seri= alization format is created for YANG. (e.g., CBOR).

So now the deleted media types do not have YANG templates.

=
I propose changing the "restconf-media-type" extension= so it is called "restconf-data".

It wil= l just have a unique name as the argument, not a media-type

<= /div>

OLD:

=C2=A0 rc:restc= onf-media-type "application/yang-errors" {
=C2=A0 =C2= =A0 uses errors;
=C2=A0 }

=C2=A0 rc:rest= conf-media-type "application/yang-api" {
=C2=A0 =C2=A0 = uses restconf;
=C2=A0 }


=
NEW:

=C2=A0 rc:restconf-data "yang-= errors" {
=C2=A0 =C2=A0 uses errors;
=C2=A0 }

=C2=A0 rc:restconf-data "yang-api" {
=C2=A0 =C2=A0 uses restconf;
=C2=A0 }


(Similar change in YANG Patch)


Lada



Andy

=C2=A0
>
>
>
> Lada
>
>
>
> Andy
>
> >
> >=C2=A0 =C2=A0 No parameters are needed
> >
> >
> > The +xml is not equivalent to application/xml. It is usually &quo= t;anydata", not
> > "anyxml".
> > Unless the YANG node really is from an anyxml-stmt.
> > (Valid application/yang-data+xml is also valid XML)
> >
> > The +json is not equivalent to application/json.
> > It requires draft-ietf-netmod-yang-json and draft-ietf-netmod-yan= g-metadata
> > syntax.
> > (Valid application/yang-data+json is also valid JSON)
> >
> >
> >
> > Regards,
> >>
> >> Sean
> >>
> >>
> >
> > Andy
> >
> >
> >>
> >> _______________________________________________
> >> Netconf mailing list
> >> Netconf@ietf.org
> >> https://www.ietf.org/mailman/listinfo/net= conf
> >>
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf=
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--94eb2c05a69a48003a0535e7ee23-- From nobody Thu Jun 23 04:15:32 2016 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 E9C8D12E251 for ; Thu, 23 Jun 2016 04:15: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] 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 TzrTQZ-5aolx for ; Thu, 23 Jun 2016 04:15:28 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C5CBD12E2C5 for ; Thu, 23 Jun 2016 04:15:27 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id DDF911CC02C8; Thu, 23 Jun 2016 13:15:27 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <5F59F1E8-62E8-4AE9-9E51-DB4E506C3C80@nic.cz> <326DE836-9AD6-4132-9F7C-938BAA729D71@nic.cz> <5f5ccb91-69c5-8677-0906-e62800535394@seantek.com> <6BB6C342-5EAA-4934-B48A-889CFBE3E118@nic.cz> User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 23 Jun 2016 13:15:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 11:15:31 -0000 Andy Bierman writes: > On Wed, Jun 22, 2016 at 8:02 AM, Ladislav Lhotka wrote: > >> >> > On 22 Jun 2016, at 16:00, Andy Bierman wrote: >> > >> > >> > >> > On Wed, Jun 22, 2016 at 4:29 AM, Ladislav Lhotka wrote: >> > Andy Bierman writes: >> > >> > > On Tue, Jun 21, 2016 at 9:40 AM, Sean Leonard >> wrote: >> > > >> > >> On 6/21/2016, people said: >> > >> >> > >> > >> > >> >> > >> The media type definitions in RESTCONF-13 are incorrect. >> > >> We cannot make subtypes for application/yang. >> > >> Each RESTCONF (and YANG Patch) media type has >> > >> to be registered. >> > >> >> > >> >> > >> Approach 1) hard-wired types >> > >> >> > >> >> > >> RESTCONF would register 10 media types and YANG Patch 4 media types >> > >> if we use the hardwired approach. >> > >> >> > >> application/yang-api+xml >> > >> application/yang-api+json >> > >> application/yang-datastore+xml >> > >> application/yang-datastore+json >> > >> [etc.] >> > >> >> > >> Any new media types would need to be registered. >> > >> No usage of the restconf-media-type is possible besides >> > >> this list of media types for RESTCONF and YANG Patch >> > >> without additional registrations. >> > >> >> > >> Approach 2) generic types with a parameter >> > >> >> > >> A parameter approach would allow YANG to be used to define any >> > >> message content schema. E.g., a mandatory "type" parameter >> > >> that specifies the module and name of the restconf-media-type. >> > >> >> > >> Only 2 media type need to be registered for every media-type >> > >> that could ever be specified (SDO or vendor) >> > >> >> > >> application/yang-data-xml;type=: >> > >> application/yang-data-json;type=: >> > >> >> > >> application/yang-data-xml;type=ietf-restconf:api >> > >> application/yang-data-json;type=ietf-restconf:api >> > >> [etc.] >> > >> >> > >> If you have a preference how this issue is resolved, send comments. >> > >> >> > >> > >> > >> >> > >> Then people said: >> > >> >> > >>> Shouldn't the action be invoked with >> > >>>> >> > >>>> POST /restconf/data/foo/bar >> > >>>> >> > >>> yes -- the URIs will be different. >> > >>> >> > >>> I don't see what problem it solves to change it now. >> > >>> Either we think RESTCONF-specific media types help or they should >> all be >> > >>> removed. >> > >>> >> > >>> To take this argument to the logical conclusion, we could dump all >> the >> > >>> media types >> > >>> and just use application/xml and application/json. >> > >>> >> > >>> In fact, we support that in our server, proving the RESTCONF media >> types >> > >>> can be ignored >> > >>> because there is enough context in the request to deduce the schema. >> > >>> >> > >>> I think the media types add some strong typing. >> > >>> Not sure if that is important or not. >> > >>> >> > >> >> > >> Hello, I wanted to take the opportunity to address the Netconf list... >> > >> >> > >> First of all: The way that 2) is proposed has a typo. It should be >> > >> application/yang-data+xml and application/yang-data+json, not -xml and >> > >> -json. + is for "structured syntax suffixes", which applies here. >> > >> >> > >> Officially (from the media-types perspective) either 1) or 2) could >> work, >> > >> depending on various engineering and administrative considerations. >> In this >> > >> case, those considerations are about module routing, protocol >> > >> advertisement, and effort to register new types. >> > >> >> > >> You could, theoretically, dump all media types and use >> application/xml and >> > >> application/json. But that invites a performance impact in that all >> data >> > >> received as /xml or /json has to be routed through a generic XML or >> JSON >> > >> processor that has to content-sniff for the data type inside the >> payload. >> > >> XML and JSON are generic data formats; they apply as a structured >> syntax to >> > >> innumerable content types that semantically have nothing to do with >> each >> > >> other. That is one reason why + structured syntax suffixes were >> created. >> > >> There ought to be a performance increase by moving the data routing >> to a >> > >> different part of the parsing chain, discriminating based solely on >> the >> > >> media type (a single case-insensitive string comparison operation). >> > >> >> > >> Registering additional media types means you have to fill out (and >> have >> > >> approved) a registration template for each new media type. Therefore, >> there >> > >> is additional administrative overhead. Sometimes it's a formality and >> > >> sometimes it invites nitpicking. As there are more than 4 types, this >> > >> weighs against including specific schema information inside the media >> type >> > >> name. >> > >> >> > >> Whether you put the schema in application/yang-NAME or in a parameter >> > >> application/yang-data; module=NAME (or whatever), it's clear that the >> > >> module name is duplicated inside the payload. This invites conflict. >> What >> > >> if the response is labeled application/yang-operation+json but the >> content >> > >> is "ietf-restconf:errors"? What is the proper behavior? >> > >> >> > >> Having reviewed the RESTCONF drafts closely, my engineering opinion >> is in >> > >> favor of 2), making the type parameter OPTIONAL (unless it can be >> shown >> > >> that the payload is not sufficient to discriminate the YANG data >> type). >> > >> >> > >> The registration of application/yang-data is well-justified because >> it is >> > >> instance data while application/yang is (apparently) schema data. >> > >> >> > >> Once you know it's "YANG Data", you know that a YANG processor has to >> grok >> > >> the data anyway; a robust YANG processor ought to be able to handle >> all of >> > >> the proposed types (or conversely, be aware of its own limitations). >> By >> > >> making the YANG type/sub-type optional, you're saying that it's a >> hint. At >> > >> the same time, your workflow can do some preliminary routing based on >> the >> > >> parameter without needing to invoke XML or JSON parsing, so there is >> > >> operational value in defining the parameter. Compare with >> application/cms, >> > >> RFC 7193 (and predecessor, application/pkcs7-mime). >> > >> >> > >> In some formats, a type parameter might be REQUIRED. For example, I >> > >> understand that CBOR is being considered as a data format. If you >> decide >> > >> not to put the discriminator in the CBOR payload, then the type >> parameter >> > >> would be REQUIRED for +cbor, rather than OPTIONAL. >> > >> >> > >> >> > > >> > > I just had a meeting with our developer who wrote our RESTCONF server >> code >> > > that processes the HTTP request. Only the suffix is relevant in the >> > > Content-Type. >> > > There are no cases where the RESTCONF media type is needed because the >> > > request URI and/or message-body is ambiguous. It is only used to >> return an >> > > error if it is wrong. >> > > >> > > Option 3: >> > > >> > > Register 2 media types: >> > > application/yang-data+xml >> > > application/yang-data+json >> > >> > Whilst I proposed a reduction of media types, this seems too much to >> > me. For one, "application/yang-patch" is IMO needed because (presumably) >> > other patch format may be used with the PATCH method, and without >> > getting the proper media type the receiving application can only try to >> > guess the format. >> > >> > >> > I agree application/yang-patch is needed. >> > >> > Option 3: >> > >> > Register 4 media types: >> > application/yang-data+xml >> > application/yang-data+json >> > application/yang-patch+xml >> > application/yang-patch+json >> >> OK, this looks good to me. >> >> > > Almost... > > Remember that we created the hack called "restconf-media-type" because you > complained > that we could not just declare a grouping. The goal here is to use YANG to > define message content, > so that it is easy to write but also precise and encoding-independent. > This saves a lot of cut-and-paste > every time a new serialization format is created for YANG. (e.g., > CBOR). I agree it is convenient to be able to use YANG as an encoding-independent schema language, but I'd argue this hack (or similar) should be specified elsewhere because it has nothing to do with RESTCONF the protocol - even if RESTCONF spec uses it for specifying some schemas. > > So now the deleted media types do not have YANG templates. > > I propose changing the "restconf-media-type" extension so it is called > "restconf-data". Due to the above reason, I think the name of such an extension shouldn't contain "restconf". After all, it could be used for other purposes, too. Lada > > It will just have a unique name as the argument, not a media-type > > > OLD: > > rc:restconf-media-type "application/yang-errors" { > uses errors; > } > > rc:restconf-media-type "application/yang-api" { > uses restconf; > } > > > NEW: > > rc:restconf-data "yang-errors" { > uses errors; > } > > rc:restconf-data "yang-api" { > uses restconf; > } > > > (Similar change in YANG Patch) > > > Lada >> >> > > Andy > > > >> > >> > >> > >> > Lada >> > >> > >> > >> > Andy >> > >> > > >> > > No parameters are needed >> > > >> > > >> > > The +xml is not equivalent to application/xml. It is usually >> "anydata", not >> > > "anyxml". >> > > Unless the YANG node really is from an anyxml-stmt. >> > > (Valid application/yang-data+xml is also valid XML) >> > > >> > > The +json is not equivalent to application/json. >> > > It requires draft-ietf-netmod-yang-json and >> draft-ietf-netmod-yang-metadata >> > > syntax. >> > > (Valid application/yang-data+json is also valid JSON) >> > > >> > > >> > > >> > > Regards, >> > >> >> > >> Sean >> > >> >> > >> >> > > >> > > Andy >> > > >> > > >> > >> >> > >> _______________________________________________ >> > >> 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 >> > >> > -- >> > Ladislav Lhotka, CZ.NIC Labs >> > PGP Key ID: E74E8C0C >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jun 23 12:34:43 2016 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 C71D212D78C for ; Thu, 23 Jun 2016 12:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 J7TsEeRkeix7 for ; Thu, 23 Jun 2016 12:34:39 -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 7E58612D786 for ; Thu, 23 Jun 2016 12:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20913; q=dns/txt; s=iport; t=1466710479; x=1467920079; h=from:to:subject:date:message-id:mime-version; bh=7fC3HclXEwSuZagqSV0HQkwpvl5YUY+Tfu3ePedAPLk=; b=WMVVaJLYsUq8O8TOrz6X8LsHXJssulhLDx9xG9I9n8ONJmoVL+dnvqdF rtMJbAEq5hycelVxckzBU3jvOBpO3RP6QHW1aTewZT3uto2zfyFtnaO2u fawurIteJEEOhiy07n2wYjWT42dvNdBkHggWFGIBXMDp1zK1rKwFKyY1H E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgBDOWxX/5FdJa1dgnBOVn0GuCWCD?= =?us-ascii?q?4F6IoUsgXs4FAEBAQEBAQFlHAuEUy1eAS0TQCYBBBuIKA6me6AkAQEBAQEBBAE?= =?us-ascii?q?BAQEBAQEbBYYniHABAYV2BZh/AYYHiCKBcIRTiGiPfQEeNoNwbgGISjZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,518,1459814400"; d="scan'208,217";a="116203810" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jun 2016 19:34:37 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u5NJYbPK011684 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 23 Jun 2016 19:34:37 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.1104.5; Thu, 23 Jun 2016 15:34:36 -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.1104.009; Thu, 23 Jun 2016 15:34:36 -0400 From: "Eric Voit (evoit)" To: "netconf@ietf.org" Thread-Topic: NETCONF Subscription drafts: Open Issues coming soon... Thread-Index: AdHNhkSrJ14nYtYgTjid8d8zX0gQIg== Date: Thu, 23 Jun 2016 19:34:36 +0000 Message-ID: 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.118.56.229] Content-Type: multipart/alternative; boundary="_000_ce1e57996ab947269508544767e2def8XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] NETCONF Subscription drafts: Open Issues coming soon... X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 19:34:42 -0000 --_000_ce1e57996ab947269508544767e2def8XCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It has been a week since the posting of four coupled Event & YANG Datastore= Subscription drafts. To spur discussions beyond those members of NETCONF already participating i= n weekly calls, = we are going to be sending out key issues being worked for each draft. If you have deeper interest, please look at the meeting minutes from our calls since IETF 95. Thanks, Eric --_000_ce1e57996ab947269508544767e2def8XCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It has been a week since = the posting of four coupled Event & YANG Datastore Subscription drafts.<= /p>

 <= /p>

To spur discussions beyon= d those members of NETCONF already parti= cipating in weekly calls, we are going to be sending out key issues bei= ng worked for each draft.

 <= /p>

If you have deeper intere= st, please look at the meeting mi= nutes from our calls since IETF 95.

 <= /p>

Thanks,=

Eric

 <= /p>

--_000_ce1e57996ab947269508544767e2def8XCHRTP013ciscocom_-- From nobody Thu Jun 23 13:49:26 2016 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 F283E12D7E1 for ; Thu, 23 Jun 2016 13:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 nVKay8Z1_iCe for ; Thu, 23 Jun 2016 13:49:23 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 894E312D7DA for ; Thu, 23 Jun 2016 13:49:23 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5922B767; Thu, 23 Jun 2016 22:49:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id T6Vf2csSEjbA; Thu, 23 Jun 2016 22:49:20 +0200 (CEST) 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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 23 Jun 2016 22:49:21 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8224620056; Thu, 23 Jun 2016 22:49:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JQ98XctmOZ4R; Thu, 23 Jun 2016 22:49:20 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B231520047; Thu, 23 Jun 2016 22:49:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7E5A73B37E07; Thu, 23 Jun 2016 22:49:20 +0200 (CEST) Date: Thu, 23 Jun 2016 22:49:19 +0200 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20160623204919.GA46872@elstar.local> Mail-Followup-To: Robert Wilton , netconf@ietf.org References: <7a655427-0625-744a-1e5e-7e07aea4e11c@hq.sk> <20160621094628.GA41804@elstar.local> <20160621.122117.332960881532664788.mbj@tail-f.com> <34773154-f55f-9085-35fb-13e44d5b535a@cisco.com> <20160621121914.GA42059@elstar.local> <35929fa6-fa32-9406-fc2c-47c83ed02307@cisco.com> <20160622111539.GA43905@elstar.local> <6fdb30f4-5354-07cd-0ecd-7fe0ea8f91e4@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6fdb30f4-5354-07cd-0ecd-7fe0ea8f91e4@cisco.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF content=all on conflicts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 20:49:26 -0000 On Wed, Jun 22, 2016 at 05:13:00PM +0100, Robert Wilton wrote: > > > draft-ietf-netmod-opstate-reqs defines Operational State as: > > Operational State: Operational State is the current state of the > system as known to the various components of the system (e.g., > control plane daemons, operating system kernels, line cards). > The operational state includes both applied configuration and > derived state. > > The definition in draft-schoenw excludes the applied configuration as part > of the operational state datastore which I would read as being inconsistent > with the definition above. The datastore in the I-D represents _all_ operational state, irrespective of its origin. I think partitioning the operational state is not useful. Again, this discussion does not really belong into this thread. /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 Jun 23 14:44:34 2016 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 4C7FD12D739 for ; Thu, 23 Jun 2016 14:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 t9UFpwViA7ZF for ; Thu, 23 Jun 2016 14:44:30 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1388512D5E8 for ; Thu, 23 Jun 2016 14:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12027; q=dns/txt; s=iport; t=1466718270; x=1467927870; h=from:to:subject:date:message-id:mime-version; bh=cM0Ztu1337tMQ/gU90Imn22DGTCqjERXs14vTfTKiQk=; b=OJ9MsIa1Rd9T0SJdjpXB1vWeYjdQ5i8TIHM8xNKN/xsDdQbobY2fVyjz YJcxeQpWMaAI2rtgOthglHkfxR/NqXxrVOvVNdgMnPngKwpHnuOMpM2J0 qaMDKmQ+7pKHpbUjqe+3YkywogEudkOfHQcC5ONq2Cac48nE0sEoGA9N2 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgAFV2xX/5tdJa1dgnBOVn0GtTOFA?= =?us-ascii?q?YF6FwEKhyg4FAEBAQEBAQFlHAuEUy1eAS1TJgEEDwwBiCcOpx2gIwEBAQEBBQE?= =?us-ascii?q?BAQEBASGGJ4hfEQEGgl9LgkcFmH8BhgeIIoFwhFODLoU6j30BHjaDcG4GiEU2f?= =?us-ascii?q?wEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,518,1459814400"; d="scan'208,217";a="289367297" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jun 2016 21:44:29 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u5NLiS8w024299 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 23 Jun 2016 21:44:28 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 23 Jun 2016 17:44:27 -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.1104.009; Thu, 23 Jun 2016 17:44:27 -0400 From: "Eric Voit (evoit)" To: "netconf@ietf.org" Thread-Topic: Key Issues: draft-voit-netconf-restconf-notif Thread-Index: AdHNmDeigErMbzRgSyG6869UerXZcwAACA6A Date: Thu, 23 Jun 2016 21:44:27 +0000 Message-ID: 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.118.56.229] Content-Type: multipart/alternative; boundary="_000_c17f826775604b7a9f72a5d73f5b26ceXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] Key Issues: draft-voit-netconf-restconf-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 21:44:32 -0000 --_000_c17f826775604b7a9f72a5d73f5b26ceXCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are four NETCONF subscription drafts recently posted. The scope for = each draft was proposed during the May NETCONF interim. To get people ready to = consider upcoming draft adoption requests, we are going to highlight some i= ssues now being worked. This email describes some recent thinking on draf= t-voit-netconf-restconf-notif. draft-voit-netconf-restconf-notif provides a specification for transporting Subs= criptions and Event notifications Restconf and HTTP. Three top issues curr= ently being discussed are: * We plan on using Event notifications from RESTCONF as a normative = reference. Does the draft include all the augmentations needed? * HTTP native transport option doesn't currently use Server Sent Eve= nts (SSE). Can we adopt SSE? * Do we include support for 3rd party signaled subscriptions over HT= TP native transport? If you read this draft and have questions on these or other issues, please = chime in... Eric Voit (on behalf of the authors and the NETCONF members attending the weekly call= s) --_000_c17f826775604b7a9f72a5d73f5b26ceXCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There are four NETCONF su= bscription drafts recently posted.  The scope for each draft was proposed during the May NETCONF interim.=  To get people ready to consider upcoming draft adoption requests, we= are going to highlight some issues now being worked.   This email describes some recent thinking on draft-voit-netconf-restconf-notif.

 <= /p>

draft-voit-netconf-r= estconf-notif  provides a specification for transporting Subscriptions and Event notifications Restconf and HTTP.  Three top i= ssues currently being discussed are:

·      = ;  We plan on using = Event notifications from RESTCONF as a normative reference.   Doe= s the draft include all the augmentations needed?

·      = ;  HTTP native trans= port option doesn't currently use Server Sent Events (SSE).  Can we ad= opt SSE?

·      = ;  Do we include sup= port for 3rd party signaled subscriptions over HTTP native transport?<= /o:p>

 <= /p>

If you read this draft an= d have questions on these or other issues, please chime in…

 <= /p>

Eric Voit

(on behalf of the authors= and the NETCONF members attending the weekly calls)

 <= /p>

 <= /p>

--_000_c17f826775604b7a9f72a5d73f5b26ceXCHRTP013ciscocom_-- From nobody Thu Jun 23 19:10:34 2016 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 D85DB12D912 for ; Thu, 23 Jun 2016 19:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 ZW_lzn7BZ4ta for ; Thu, 23 Jun 2016 19:10:29 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 7AE3612D92C for ; Thu, 23 Jun 2016 19:10:29 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id c2so102057137vkg.1 for ; Thu, 23 Jun 2016 19:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E/Yzd8nk6TEAYxpPc1wWqtcCRTr38byLLrJe/4CUEtE=; b=Mu2iyvFTcxmG+NMMRO4ARPdwO8YAXnerugZW/NMp/ZL55rnITFY+yH+xxubck9S3Ld xTsGrgUcNb5n0pF0kU46KSpkQ9JztgTVhLjRCn2rnGddeT3s+q9vCn+yuViAX3tz4aYj gjT7Ssj02Jb57V/yxUwamS9k9eWdlXjjDI58NqYmt5smAHR4bC3Vi8ox0xKxXxTVMu6J uM++lql0IyTNQZbfZCsreuc9okewjWToVN0ofwrMMPPYH2rjvGHJ+sXvYmiKqoJxBKQn yRqFwnSr81lI4sdZJHp2AsAEVyrlyBNbsqrWdl4zRBDGK22Lsm+RHikyxacsjey3wVse LarQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=E/Yzd8nk6TEAYxpPc1wWqtcCRTr38byLLrJe/4CUEtE=; b=BvZWx/smpS8rwna3npPPnO0cmiGsBCdWaJuz1rwl3LWpUrqo7pcC1GmGz61JA38pYe Ltb4/lsxMQFzYCpg7jOViMtVNUSnWPYKELFabXNej3DEXYdHOwbV6yNlP377x0zFqxYM nlC2avzmV9dZhELOIOaxQDBrNrmIUGyiGlwB+EkBxz9nQ+uRE4h56rC+TVFgSUpJHymE Tk1dPT3OoWrUZpFs7lVCjGiImX9ux301/NLJVGZy7MS9t6g3UovlQBnH/zhqH9Rf1CCU TSUa02zaF3YcLQ6Yt1HmCI/SBxxLGOMn/GvFUrWe9AMP5IO2pWkhtPNcTAnx10FzeKLc HkVA== X-Gm-Message-State: ALyK8tIr3isSFdfr7BZECl96GpVn3QQzrvvfdJs3nzO22DtNtgaJW22WJnR8CXmvI1xkV3pjk6vglipjfVdVhQ== X-Received: by 10.31.5.80 with SMTP id 77mr1317179vkf.132.1466734228576; Thu, 23 Jun 2016 19:10:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Thu, 23 Jun 2016 19:10:27 -0700 (PDT) In-Reply-To: References: <5F59F1E8-62E8-4AE9-9E51-DB4E506C3C80@nic.cz> <326DE836-9AD6-4132-9F7C-938BAA729D71@nic.cz> <5f5ccb91-69c5-8677-0906-e62800535394@seantek.com> <6BB6C342-5EAA-4934-B48A-889CFBE3E118@nic.cz> From: Andy Bierman Date: Thu, 23 Jun 2016 19:10:27 -0700 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1143db92acb1fb0535fcacac Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 02:10:33 -0000 --001a1143db92acb1fb0535fcacac Content-Type: text/plain; charset=UTF-8 On Thu, Jun 23, 2016 at 4:15 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Wed, Jun 22, 2016 at 8:02 AM, Ladislav Lhotka wrote: > > > ..... > >> > > >> > Option 3: > >> > > >> > Register 4 media types: > >> > application/yang-data+xml > >> > application/yang-data+json > >> > application/yang-patch+xml > >> > application/yang-patch+json > >> > >> OK, this looks good to me. > >> > >> > > > > Almost... > > > > Remember that we created the hack called "restconf-media-type" because > you > > complained > > that we could not just declare a grouping. The goal here is to use YANG > to > > define message content, > > so that it is easy to write but also precise and encoding-independent. > > This saves a lot of cut-and-paste > > every time a new serialization format is created for YANG. (e.g., > > CBOR). > > I agree it is convenient to be able to use YANG as an > encoding-independent schema language, but I'd argue this hack (or > similar) should be specified elsewhere because it has nothing to do with > RESTCONF the protocol - even if RESTCONF spec uses it for specifying > some schemas. > > We were not really chartered to solve the general problem of using YANG to define encoding-independent data abstractions. This is how the IETF turns a 1 year project into 3+ years. > > > > So now the deleted media types do not have YANG templates. > > > > I propose changing the "restconf-media-type" extension so it is called > > "restconf-data". > > Due to the above reason, I think the name of such an extension shouldn't > contain "restconf". After all, it could be used for other purposes, too. > > How about changing the extension name to "yang-data"? > Lada > > Andy > > > > It will just have a unique name as the argument, not a media-type > > > > > > OLD: > > > > rc:restconf-media-type "application/yang-errors" { > > uses errors; > > } > > > > rc:restconf-media-type "application/yang-api" { > > uses restconf; > > } > > > > > > NEW: > > > > rc:restconf-data "yang-errors" { > > uses errors; > > } > > > > rc:restconf-data "yang-api" { > > uses restconf; > > } > > > > > > (Similar change in YANG Patch) > > > > > > Lada > >> > >> > > > > Andy > > > > > > > >> > > >> > > >> > > >> > Lada > >> > > >> > > >> > > >> > Andy > >> > > >> > > > >> > > No parameters are needed > >> > > > >> > > > >> > > The +xml is not equivalent to application/xml. It is usually > >> "anydata", not > >> > > "anyxml". > >> > > Unless the YANG node really is from an anyxml-stmt. > >> > > (Valid application/yang-data+xml is also valid XML) > >> > > > >> > > The +json is not equivalent to application/json. > >> > > It requires draft-ietf-netmod-yang-json and > >> draft-ietf-netmod-yang-metadata > >> > > syntax. > >> > > (Valid application/yang-data+json is also valid JSON) > >> > > > >> > > > >> > > > >> > > Regards, > >> > >> > >> > >> Sean > >> > >> > >> > >> > >> > > > >> > > Andy > >> > > > >> > > > >> > >> > >> > >> _______________________________________________ > >> > >> 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 > >> > > >> > -- > >> > Ladislav Lhotka, CZ.NIC Labs > >> > PGP Key ID: E74E8C0C > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > >> > >> > >> > >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --001a1143db92acb1fb0535fcacac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jun 23, 2016 at 4:15 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Andy Bierman <andy@yumaworks.com> writes:

> On Wed, Jun 22, 2016 at 8:02 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
.....
>> >
>> >=C2=A0 =C2=A0Option 3:
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Register 4 media types:
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 application/yang-data+xml >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 application/yang-data+json<= br> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 application/yang-patch+xml<= br> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 application/yang-patch+json=
>>
>> OK, this looks good to me.
>>
>>
>
> Almost...
>
> Remember that we created the hack called "restconf-media-type&quo= t; because you
> complained
> that we could not just declare a grouping.=C2=A0 The goal here is to u= se YANG to
> define message content,
> so that it is easy to write but also precise and encoding-independent.=
> This saves a lot of cut-and-paste
> every time a new serialization format is created for YANG. (e.g.,
> CBOR).

I agree it is convenient to be able to use YANG as an
encoding-independent schema language, but I'd argue this hack (or
similar) should be specified elsewhere because it has nothing to do with RESTCONF the protocol - even if RESTCONF spec uses it for specifying
some schemas.



We were not really char= tered to solve the general problem of using YANG to
define encodi= ng-independent data abstractions.=C2=A0 This is how the IETF turns
a 1 year project into 3+ years.

=C2=A0
>
> So now the deleted media types do not have YANG templates.
>
> I propose changing the "restconf-media-type" extension so it= is called
> "restconf-data".

Due to the above reason, I think the name of such an extension shouldn'= t
contain "restconf". After all, it could be used for other purpose= s, too.



How about changing the = extension name to "yang-data"?

=C2=A0
Lada



Andy

=C2=A0
>
> It will just have a unique name as the argument, not a media-type
>
>
> OLD:
>
>=C2=A0 =C2=A0rc:restconf-media-type "application/yang-errors"= {
>=C2=A0 =C2=A0 =C2=A0uses errors;
>=C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0rc:restconf-media-type "application/yang-api" {<= br> >=C2=A0 =C2=A0 =C2=A0uses restconf;
>=C2=A0 =C2=A0}
>
>
> NEW:
>
>=C2=A0 =C2=A0rc:restconf-data "yang-errors" {
>=C2=A0 =C2=A0 =C2=A0uses errors;
>=C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0rc:restconf-data "yang-api" {
>=C2=A0 =C2=A0 =C2=A0uses restconf;
>=C2=A0 =C2=A0}
>
>
> (Similar change in YANG Patch)
>
>
> Lada
>>
>>
>
> Andy
>
>
>
>> >
>> >
>> >
>> > Lada
>> >
>> >
>> >
>> > Andy
>> >
>> > >
>> > >=C2=A0 =C2=A0 No parameters are needed
>> > >
>> > >
>> > > The +xml is not equivalent to application/xml. It is usu= ally
>> "anydata", not
>> > > "anyxml".
>> > > Unless the YANG node really is from an anyxml-stmt.
>> > > (Valid application/yang-data+xml is also valid XML)
>> > >
>> > > The +json is not equivalent to application/json.
>> > > It requires draft-ietf-netmod-yang-json and
>> draft-ietf-netmod-yang-metadata
>> > > syntax.
>> > > (Valid application/yang-data+json is also valid JSON) >> > >
>> > >
>> > >
>> > > Regards,
>> > >>
>> > >> Sean
>> > >>
>> > >>
>> > >
>> > > Andy
>> > >
>> > >
>> > >>
>> > >> _______________________________________________
>> > >> Netconf mailing list
>> > >> Netconf@ietf.org=
>> > >> https://www.ietf.org/mailman/lis= tinfo/netconf
>> > >>
>> > > _______________________________________________
>> > > Netconf mailing list
>> > > Netconf@ietf.org=
>> > > https://www.ietf.org/mailman/listinf= o/netconf
>> >
>> > --
>> > Ladislav Lhotka, CZ.NIC Labs
>> > PGP Key ID: E74E8C0C
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

--001a1143db92acb1fb0535fcacac-- From nobody Thu Jun 23 19:56:24 2016 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 33A4C12D73F for ; Thu, 23 Jun 2016 19:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 Vd1-jNiNjFGt for ; Thu, 23 Jun 2016 19:56:21 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 E158112D925 for ; Thu, 23 Jun 2016 19:56:20 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id c2so103050995vkg.1 for ; Thu, 23 Jun 2016 19:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=1LW4ywLg0cF4Sxr7Ntf3EID+LcKWZ9NFTlzEEFjoOzY=; b=UO3gtzoImOfOxrqrPZpOMoXiUrouy0LhlLha2RLPalTdQbdAUhHJ49l0vSQc/3/zku vTY78qa/gp9cbj/S8BT1nIiv8Zt8v9UT7AMCTg2BfTo1/S4+UXq4Nl7ZBmRLyOioK7bB 3WnSHfutB4yIRBBtlvYhVqqcYsD8qTAzFHYulr+F1GM97tT02/uSs5ptfY00oycEoBUg mRvhUK1dcBhar7NcpO4kjxAKGnTQL3Qw7feNTWw6bB1DM1sBl/a4S9dbpPftG5I4ZHAM zS5705nm3YuZ55wQs6bi9rQBcLldYM7ucmySeTMNepuLNJnBJPVFVJzi2GOGFrbpEGYP /DsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1LW4ywLg0cF4Sxr7Ntf3EID+LcKWZ9NFTlzEEFjoOzY=; b=YEklIoSTInSPpMBoA8QEbTG7B5T2RIAgIh3lQxj7sYt+nmaGADexH40XnkUee18swy tD3SdjPJJHE+SbVAYV5IRubrSwCYLtTQmBrL3MLqKLH1zU3TUwiyX797TgUDq7qpKP/e 3hYleDyb5T+04gCxMUeY9YIwLlpKn6knkdzCUje0zLOa79ublU4IMiZPi2n7Oi9oTC0s X87xUqm/USVRh2GfeVB5G9kjnT9fqO285v8bllErtPvLldxlTW8FAh399J2iKhNdOAsF pwIHOZOEL1bCzmaXtA76h80y+YIijjIpfm2QQDe+lUnLlLWiPQ3NtgCJPIPPA1qtFx4X rHPQ== X-Gm-Message-State: ALyK8tIEKqZ5rDD+IhfI7niouplt0PYoY+mC2+fziiak2hznGv4Uby22PvjWgwjwd+SL8jJZDEl6r4nh31iCpw== X-Received: by 10.31.132.77 with SMTP id g74mr1344141vkd.121.1466736979887; Thu, 23 Jun 2016 19:56:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Thu, 23 Jun 2016 19:56:19 -0700 (PDT) From: Andy Bierman Date: Thu, 23 Jun 2016 19:56:19 -0700 Message-ID: To: Juergen Schoenwaelder , Robert Wilton , Netconf Content-Type: multipart/alternative; boundary=001a1144f9d8aa64ad0535fd505f Archived-At: Subject: [Netconf] New Datastores? (was Re: RESTCONF content=all on conflicts?) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 02:56:23 -0000 --001a1144f9d8aa64ad0535fd505f Content-Type: text/plain; charset=UTF-8 On Thu, Jun 23, 2016 at 1:49 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Jun 22, 2016 at 05:13:00PM +0100, Robert Wilton wrote: > > > > > > draft-ietf-netmod-opstate-reqs defines Operational State as: > > > > Operational State: Operational State is the current state of the > > system as known to the various components of the system (e.g., > > control plane daemons, operating system kernels, line cards). > > The operational state includes both applied configuration and > > derived state. > > > > The definition in draft-schoenw excludes the applied configuration as > part > > of the operational state datastore which I would read as being > inconsistent > > with the definition above. > > The datastore in the I-D represents _all_ > operational state, irrespective of its origin. I think partitioning > the operational state is not useful. Again, this discussion does not > really belong into this thread. > > Sorry I do not have time to read all the drafts so I can understand your differences of opinion within the design team. Balazs has asked repeatedly for a way to identify counters as not being operational state. How is this issue solved? Current datastores work with (at least) 3 fundamental rules: 1) datastore child nodes are an implementation-specific collection of top-level YANG data nodes. 2) each datastore shares a common schema tree, such that data is specified exactly the same for any datastore in RPC input parameters 3) datastores are expected to be complete, such that YANG validation tests for all modules will pass for a valid datastore I prefer an RPC approach (is-it-applied-yet) rather than retrieving data from 2 places. The client should keep checking that intended config has not been changed in the running datastore, as well as checking the applied datastore. Metadata can work as well. Retrieving data with metadata about opstate takes 1 round-trip, not N. /js > > Andy > -- > 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 > --001a1144f9d8aa64ad0535fd505f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jun 23, 2016 at 1:49 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Jun 22, 2016 at 05:13:00PM +0100, Robert Wilton wrote:
>
>
> draft-ietf-netmod-opstate-reqs defines Operational State as:
>
>=C2=A0 =C2=A0 Operational State:=C2=A0 Operational State is the current= state of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 system as known to the various components o= f the system (e.g.,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 control plane daemons, operating system ker= nels, line cards).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 The operational state includes both applied= configuration and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 derived state.
>
> The definition in draft-schoenw excludes the applied configuration as = part
> of the operational state datastore which I would read as being inconsi= stent
> with the definition above.

The <operational-state> datastore in the I-D represents _all_
operational state, irrespective of its origin. I think partitioning
the operational state is not useful. Again, this discussion does not
really belong into this thread.


Sorry I do not have time to read all the drafts so I can u= nderstand your
differences of opinion within the design team.

Balazs has asked repeatedly for a way to identify cou= nters
as not being operational state.=C2=A0 How is this issue sol= ved?

Current datastores work with (at least) 3 fun= damental rules:

=C2=A0 1) datastore child nodes ar= e an implementation-specific collection
=C2=A0 =C2=A0 =C2=A0 of t= op-level YANG data nodes.

=C2=A0 2) each datastore= shares a common schema tree, such that data is
=C2=A0 =C2=A0 =C2= =A0 specified exactly the same for any datastore in RPC input parameters

=C2=A0 3) datastores are expected to be complete, su= ch that YANG validation tests
=C2=A0 =C2=A0 =C2=A0 for all module= s will pass for a valid datastore


I= prefer an RPC approach (is-it-applied-yet) rather than retrieving data
from 2 places.=C2=A0 The client should keep checking that intended c= onfig
has not been changed in the running datastore, as well as c= hecking
the applied datastore.

Metadata = can work as well.
Retrieving data with metadata about opstate tak= es 1 round-trip, not N.



<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> /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<http://www.jacobs-university.de/>

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

--001a1144f9d8aa64ad0535fd505f-- From nobody Fri Jun 24 00:34:22 2016 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 09C3112D9AC for ; Fri, 24 Jun 2016 00:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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, RP_MATCHES_RCVD=-1.426] 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 zLRDiEryH2CP for ; Fri, 24 Jun 2016 00:34:18 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3A2912D9B5 for ; Fri, 24 Jun 2016 00:34:17 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:24b9:a211:852b:aa9] (unknown [IPv6:2001:718:1a02:1:24b9:a211:852b:aa9]) by mail.nic.cz (Postfix) with ESMTPSA id DA9616110C; Fri, 24 Jun 2016 09:34:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1466753646; bh=ZNUaUCfYgkia1ZLeneHWK7JdOBIeGFe9PY7RDiAw+NI=; h=From:Date:To; b=Qysb7nY3eLwfSyvsrVMhGcMUz+EfPECRtAA+hKcnXU6WAZv5bUtBgvzqixxpvIzvp sf6z2G1VjD73uhks34UhS3hf+/Mkh7yWeunWEz9rCeYGfFRlNYtmrAypGDTXmh2kMg gTeleEvnD6o+6gpcz+fdZE28sFbcvQFaoRySzceA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 24 Jun 2016 09:34:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5F59F1E8-62E8-4AE9-9E51-DB4E506C3C80@nic.cz> <326DE836-9AD6-4132-9F7C-938BAA729D71@nic.cz> <5f5ccb91-69c5-8677-0906-e62800535394@seantek.com> <6BB6C342-5EAA-4934-B48A-889CFBE3E118@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF media type issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 07:34:21 -0000 > On 24 Jun 2016, at 04:10, Andy Bierman wrote: >=20 >=20 >=20 > On Thu, Jun 23, 2016 at 4:15 AM, Ladislav Lhotka = wrote: > Andy Bierman writes: >=20 > > On Wed, Jun 22, 2016 at 8:02 AM, Ladislav Lhotka = wrote: > > > ..... > >> > > >> > Option 3: > >> > > >> > Register 4 media types: > >> > application/yang-data+xml > >> > application/yang-data+json > >> > application/yang-patch+xml > >> > application/yang-patch+json > >> > >> OK, this looks good to me. > >> > >> > > > > Almost... > > > > Remember that we created the hack called "restconf-media-type" = because you > > complained > > that we could not just declare a grouping. The goal here is to use = YANG to > > define message content, > > so that it is easy to write but also precise and = encoding-independent. > > This saves a lot of cut-and-paste > > every time a new serialization format is created for YANG. (e.g., > > CBOR). >=20 > I agree it is convenient to be able to use YANG as an > encoding-independent schema language, but I'd argue this hack (or > similar) should be specified elsewhere because it has nothing to do = with > RESTCONF the protocol - even if RESTCONF spec uses it for specifying > some schemas. >=20 >=20 >=20 > We were not really chartered to solve the general problem of using = YANG to > define encoding-independent data abstractions. This is how the IETF = turns > a 1 year project into 3+ years. Yes, I know, but I suspect a casual reader of the RESTCONF spec may be = wondering what the extension is about and whether data of that media = type is to be expected on the wire. =20 >=20 > =20 > > > > So now the deleted media types do not have YANG templates. > > > > I propose changing the "restconf-media-type" extension so it is = called > > "restconf-data". >=20 > Due to the above reason, I think the name of such an extension = shouldn't > contain "restconf". After all, it could be used for other purposes, = too. >=20 >=20 >=20 > How about changing the extension name to "yang-data"? Sounds good. Lada >=20 > =20 > Lada >=20 >=20 >=20 > Andy >=20 > =20 > > > > It will just have a unique name as the argument, not a media-type > > > > > > OLD: > > > > rc:restconf-media-type "application/yang-errors" { > > uses errors; > > } > > > > rc:restconf-media-type "application/yang-api" { > > uses restconf; > > } > > > > > > NEW: > > > > rc:restconf-data "yang-errors" { > > uses errors; > > } > > > > rc:restconf-data "yang-api" { > > uses restconf; > > } > > > > > > (Similar change in YANG Patch) > > > > > > Lada > >> > >> > > > > Andy > > > > > > > >> > > >> > > >> > > >> > Lada > >> > > >> > > >> > > >> > Andy > >> > > >> > > > >> > > No parameters are needed > >> > > > >> > > > >> > > The +xml is not equivalent to application/xml. It is usually > >> "anydata", not > >> > > "anyxml". > >> > > Unless the YANG node really is from an anyxml-stmt. > >> > > (Valid application/yang-data+xml is also valid XML) > >> > > > >> > > The +json is not equivalent to application/json. > >> > > It requires draft-ietf-netmod-yang-json and > >> draft-ietf-netmod-yang-metadata > >> > > syntax. > >> > > (Valid application/yang-data+json is also valid JSON) > >> > > > >> > > > >> > > > >> > > Regards, > >> > >> > >> > >> Sean > >> > >> > >> > >> > >> > > > >> > > Andy > >> > > > >> > > > >> > >> > >> > >> _______________________________________________ > >> > >> 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 > >> > > >> > -- > >> > Ladislav Lhotka, CZ.NIC Labs > >> > PGP Key ID: E74E8C0C > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > >> > >> > >> > >> >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jun 24 06:37:24 2016 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 6E79E12DAD8 for ; Fri, 24 Jun 2016 06:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 OQe8rGc3tBDf for ; Fri, 24 Jun 2016 06:37:21 -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 41C3E12DAE9 for ; Fri, 24 Jun 2016 06:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14837; q=dns/txt; s=iport; t=1466775419; x=1467985019; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=VXOJ+PCoLbSEtWdPK1fRg8n4NC1Tbjj8UZ/KIcBizmU=; b=lPmkvZhWzkWXSWYnpCTEreiURFoN5xrIRIigT9xa/i48ejeIB3LJFV7g bBdQqJCRyYOG5RezARx7EXvqU6bgbF/CzoDWSJlX2KdINm6CkgCg+O2VU h0v6my4VzyYrlQ4ZmBY6Tivg094rHYaPTKkLQJE0fkGPFuVCEqyn1+nLw k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DuBgDkNW1X/xbLJq1SBwOEFCtStSWGf?= =?us-ascii?q?BcBCoUsSgKCAgEBAQEBAWYnhEwBAQEDAQEBASBLGQIJAhAIJwMCAhsMHxEGAQw?= =?us-ascii?q?GAgEBF4gNCA6ZLp0dkDkBAQEBAQEBAQEBAQEBAQEBAQEBAQEcBYYjgXeCVoQYE?= =?us-ascii?q?jcmgjqCWgWTTIU0jjSBaYdeI4U5j35Ug3E7ModuK4EXAQEB?= X-IronPort-AV: E=Sophos;i="5.26,521,1459814400"; d="scan'208,217";a="636366779" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jun 2016 13:36:57 +0000 Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u5ODauCm021061; Fri, 24 Jun 2016 13:36:57 GMT To: Andy Bierman , Juergen Schoenwaelder , Netconf , Balazs Lengyel References: From: Robert Wilton Message-ID: <4f1100d2-69c5-e15d-ad41-60169a344b2a@cisco.com> Date: Fri, 24 Jun 2016 14:36:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------17E88C91ED939FE7F0C545F0" Archived-At: Subject: Re: [Netconf] New Datastores? (was Re: RESTCONF content=all on conflicts?) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 13:37:23 -0000 This is a multi-part message in MIME format. --------------17E88C91ED939FE7F0C545F0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 24/06/2016 03:56, Andy Bierman wrote: > > > On Thu, Jun 23, 2016 at 1:49 PM, Juergen Schoenwaelder > > wrote: > > On Wed, Jun 22, 2016 at 05:13:00PM +0100, Robert Wilton wrote: > > > > > > draft-ietf-netmod-opstate-reqs defines Operational State as: > > > > Operational State: Operational State is the current state of the > > system as known to the various components of the system > (e.g., > > control plane daemons, operating system kernels, line cards). > > The operational state includes both applied configuration and > > derived state. > > > > The definition in draft-schoenw excludes the applied > configuration as part > > of the operational state datastore which I would read as being > inconsistent > > with the definition above. > > The datastore in the I-D represents _all_ > operational state, irrespective of its origin. I think partitioning > the operational state is not useful. Again, this discussion does not > really belong into this thread. > If this means the partitioning into separate "abstract" datastores in draft-wilton, this is really just a labeling of the source/semantics of the data in the operational state datastore. > > > Sorry I do not have time to read all the drafts so I can understand your > differences of opinion within the design team. > > Balazs has asked repeatedly for a way to identify counters > as not being operational state. How is this issue solved? At the moment, there is no proposed solution for this, but it hasn't really been discussed. We already have a "config=true" keyword, and "ephemeral" looks as if it is going to be a likely addition from the I2RS requirements, so I think that as least having a "statistics" keyword to label particular nodes as relating to statistics may make sense. Whether these should be a separate user independent datastore to the operational state datastore, or just a labelled part of the "operational state datastore" probably needs to be debated further? > > Current datastores work with (at least) 3 fundamental rules: > > 1) datastore child nodes are an implementation-specific collection > of top-level YANG data nodes. > > 2) each datastore shares a common schema tree, such that data is > specified exactly the same for any datastore in RPC input parameters > > 3) datastores are expected to be complete, such that YANG validation > tests > for all modules will pass for a valid datastore > > > I prefer an RPC approach (is-it-applied-yet) rather than retrieving data > from 2 places. The client should keep checking that intended config > has not been changed in the running datastore, as well as checking > the applied datastore. > > Metadata can work as well. > Retrieving data with metadata about opstate takes 1 round-trip, not N. My proposal is to use metadata. The nodes in the intended config can be labelled as to whether or not they are applied. Clients could query for this using an option (similar to with-defaults). Or what I think is a better solution is for client to be able to register for notification (YANG Pub/Sub) of the intended configuration datastore + metadata annotations. Hence the client would be notified as the configuration gets applied (or if it fails) without having to poll the server at all. I also envisage that similar annotations would be applied to an "operational state datastore" which would indicate where particular values have come from. E.g. are they due to applied configuration, or system created entries (such as interfaces), etc. Thanks, Rob > > > > /js > > > > Andy > > -- > 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 > > --------------17E88C91ED939FE7F0C545F0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 24/06/2016 03:56, Andy Bierman wrote:


On Thu, Jun 23, 2016 at 1:49 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Jun 22, 2016 at 05:13:00PM +0100, Robert Wilton wrote:
>
>
> draft-ietf-netmod-opstate-reqs defines Operational State as:
>
>    Operational State:  Operational State is the current state of the
>        system as known to the various components of the system (e.g.,
>        control plane daemons, operating system kernels, line cards).
>        The operational state includes both applied configuration and
>        derived state.
>
> The definition in draft-schoenw excludes the applied configuration as part
> of the operational state datastore which I would read as being inconsistent
> with the definition above.

The <operational-state> datastore in the I-D represents _all_
operational state, irrespective of its origin. I think partitioning
the operational state is not useful. Again, this discussion does not
really belong into this thread.
If this means the partitioning into separate "abstract" datastores in draft-wilton, this is really just a labeling of the source/semantics of the data in the operational state datastore.



Sorry I do not have time to read all the drafts so I can understand your
differences of opinion within the design team.

Balazs has asked repeatedly for a way to identify counters
as not being operational state.  How is this issue solved?
At the moment, there is no proposed solution for this, but it hasn't really been discussed.

We already have a "config=true" keyword, and "ephemeral" looks as if it is going to be a likely addition from the I2RS requirements, so I think that as least having a "statistics" keyword to label particular nodes as relating to statistics may make sense.

Whether these should be a separate user independent datastore to the operational state datastore, or just a labelled part of the "operational state datastore" probably needs to be debated further?


Current datastores work with (at least) 3 fundamental rules:

  1) datastore child nodes are an implementation-specific collection
      of top-level YANG data nodes.

  2) each datastore shares a common schema tree, such that data is
      specified exactly the same for any datastore in RPC input parameters

  3) datastores are expected to be complete, such that YANG validation tests
      for all modules will pass for a valid datastore


I prefer an RPC approach (is-it-applied-yet) rather than retrieving data
from 2 places.  The client should keep checking that intended config
has not been changed in the running datastore, as well as checking
the applied datastore.

Metadata can work as well.
Retrieving data with metadata about opstate takes 1 round-trip, not N.
My proposal is to use metadata.

The nodes in the intended config can be labelled as to whether or not they are applied.  Clients could query for this using an option (similar to with-defaults).   Or what I think is a better solution is for client to be able to register for notification (YANG Pub/Sub) of the intended configuration datastore + metadata annotations.  Hence the client would be notified as the configuration gets applied (or if it fails) without having to poll the server at all.

I also envisage that similar annotations would be applied to an "operational state datastore" which would indicate where particular values have come from.  E.g. are they due to applied configuration, or system created entries (such as interfaces), etc.

Thanks,
Rob





/js



Andy

 
--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

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


--------------17E88C91ED939FE7F0C545F0-- From nobody Fri Jun 24 09:01:01 2016 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 3D9BC12DC4F; Fri, 24 Jun 2016 09:00:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160038.10933.82845.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:38 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] netconf - Requested session has been scheduled for IETF 96 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:00:38 -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:00) Wednesday, Morning Session I 1000-1230 Room Name: Potsdam II size: 175 --------------------------------------------- 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: 90 Conflicts to Avoid: First Priority: netmod opsarea opsawg Second Priority: i2nsf anima sfc i2rs nmrg lmap radext dime nfvrg sdnrg Third Priority: lwig sacm tls 6lo 6tisch v6ops intarea tsvarea core apparea saag Special Requests: Please schedule session on Thursday. Friday is NOT possible for Netconf. Please avoid a conflict with vnfrg. (added i2nsf as a conflict per Benoit) --------------------------------------------------------- From nobody Tue Jun 28 08:42:41 2016 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 01CBB12D1F0 for ; Tue, 28 Jun 2016 08:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 UU2uegtDVxCz for ; Tue, 28 Jun 2016 08:42:38 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F79712D1AF for ; Tue, 28 Jun 2016 08:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7987; q=dns/txt; s=iport; t=1467128558; x=1468338158; h=from:to:subject:date:message-id:mime-version; bh=qarHuGUWKS+D6Z+X6gTU3i11vlSAH064mkWPGtQM9ww=; b=SAvJhWs0VnHKRfHkGRbYK9TwSWVyNmjvf9k0w4TcJBcqAXNEhnM4LlM2 WeozRCkr3mRHM4hH0nIk6eyccWdUev5NJW+edtLmrz074Pc8v1rom/iz9 vtCWtJ1ydHzsxf7iC9Edqv/wPvtEtrYNUuQhMMtrPcxnIaqoEfPnYBEEH 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgDvmXJX/4cNJK1bgnBOgVm1K4UBg?= =?us-ascii?q?XuHSjgUAQEBAQEBAWUcC4RTdxQBLVMnBIhDo0igGAEBCAIljx+FcQWOM4pPAYE?= =?us-ascii?q?wjQmPJI9+AR42g3CJH38BAQE?= X-IronPort-AV: E=Sophos;i="5.26,541,1459814400"; d="scan'208,217";a="291001897" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2016 15:42:37 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u5SFgaiC017440 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 28 Jun 2016 15:42:37 GMT Received: from xch-rtp-003.cisco.com (64.101.220.143) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 28 Jun 2016 11:42:36 -0400 Received: from xch-rtp-003.cisco.com ([64.101.220.143]) by XCH-RTP-003.cisco.com ([64.101.220.143]) with mapi id 15.00.1210.000; Tue, 28 Jun 2016 11:42:36 -0400 From: "Alberto Gonzalez Prieto (albertgo)" To: "netconf@ietf.org" Thread-Topic: Open issues in draft-gonzalez-netconf-event-notifications-00 Thread-Index: AQHR0VOxq7Htw2loSE+T/ChY2G7Btg== Date: Tue, 28 Jun 2016 15:42:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.117.124] Content-Type: multipart/alternative; boundary="_000_D397E8F87C6E4albertgociscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] Open issues in draft-gonzalez-netconf-event-notifications-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 15:42:40 -0000 --_000_D397E8F87C6E4albertgociscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, draft-gonzalez-netconf-event-notifications-00 is one of the four drafts in = the set "Event Notification + Yang-push " Its scope is transporting Event Notifications over NETCONF. The open issues we are currently focusing on are: - configured subscriptions: - How to realized configured subscription? - The current line of work is based on call-home. - Once a subscription is configured, the server would contact the receiver = using call home. Once the NETCONF session is established, the server would = send a . - From that point on, the server sends notifications to the receiver as per= the subscription configuration. - As for dynamic subscriptions, such a session could be used for multiple s= ubscriptions. This would be controlled by the server - Once the subscription is deleted, the server would send a and drop the session. - and multiple subscriptions on a session - Should multiple create-subscription's over a single NETCONF session be su= pported? - The current thinking is to support multiple subscriptions over a single s= ession only for establish-subscription's - The rationale being to simplify implementations If you have questions/input on these open issues or other aspects of the dr= aft, we will be happy to discuss them. Alberto Gonzalez (on behalf of the draft authors and the NETCONF WG members attending the we= ekly calls) --_000_D397E8F87C6E4albertgociscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hello,

draft-gonzalez-netc= onf-event-notifications-00 is one of the four drafts in the set "Event Notification + Yang= -push “
Its scope is transporting Event Notifications over NETCONF.
The open issues we are currently focusing on are:
- configured subscriptions:
- How to realized configured subscription?
- The current line of work is based on call-home. 
- Once a subscription is configured, the server would contact the re= ceiver using call home. Once the NETCONF session is established, the server would send a <<= span style=3D"font-size: 12px; line-height: 16px; white-space: pre;">subscr= iption-started>. 
- From that point on, the server sends notifications to the receiver= as per the subscription configuration.
- As for dynamic subscriptions, such a session could be used for mul= tiple subscriptions. This would be controlled by the server
- Once the subscription is deleted, the server would send a <subscription-terminated> and drop the session.
- <create-subscription> and multiple subscriptions on a sessio= n
- Should multiple create-subscription's over a single NETCONF sessio= n be supported?
- The current thinking is to support multiple subscriptions over a s= ingle session only for establish-subscription’s
- The rationale being to simplify implementations


If you have questions/input on these open issues or other aspects of t= he draft, we will be happy to discuss them.
 
Alberto Gonzalez
(on behalf of the draft authors and the NETCONF WG members attending t= he weekly calls)
--_000_D397E8F87C6E4albertgociscocom_-- From nobody Tue Jun 28 09:34:06 2016 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 A94F912D51F for ; Tue, 28 Jun 2016 09:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 v2T21lAmOM3b for ; Tue, 28 Jun 2016 09:34:02 -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 3B20812D16B for ; Tue, 28 Jun 2016 09:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13328; q=dns/txt; s=iport; t=1467131642; x=1468341242; h=from:to:subject:date:message-id:mime-version; bh=V7lvmGHpTn+IisiX/Tqz6YGO6vHUD1TqwqMGWLEV5l8=; b=cBb+FKvb9qoeTxhtIYCJ2ySYdUkLtb73mIM1LKOfIZGYVt+r0UfygSOo PN6Vq1TtoQvkmSk4+WERpCDgfO2MpVw/JjLmuaJ20lSI6iCMcPGQKRrwS f5/SkmJ8iffb/2JnO0kcbIe4kgoVMxgcfdDOujZx2vLmBD4t1f7s2XTeS 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAgDepXJX/40NJK1bgnBOVoEDhUSva?= =?us-ascii?q?oUBgXsihBuDDTgUAQEBAQEBAWUnhEwBAQUtShQBCBUQUyYBBAEaiCgOw3EBAQE?= =?us-ascii?q?BAQEBAwEBAQEBAQEbBYYohE2EKoVxBZNNhTUBhgeIK48rj34BHjaDcIkffwEBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.26,541,1459814400"; d="scan'208,217";a="290260282" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2016 16:34:01 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u5SGY0Te031073 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 28 Jun 2016 16:34:01 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 28 Jun 2016 12:34:00 -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.1210.000; Tue, 28 Jun 2016 12:34:00 -0400 From: "Eric Voit (evoit)" To: "Alberto Gonzalez Prieto (albertgo)" , "netconf@ietf.org" Thread-Topic: [Netconf] Open issues in draft-gonzalez-netconf-event-notifications-00 Thread-Index: AdHRWt4cNcCds+avT9OTvCV56gSEsA== Date: Tue, 28 Jun 2016 16:34:00 +0000 Message-ID: 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.118.56.231] Content-Type: multipart/alternative; boundary="_000_cdf916490fd74036bd92639034d787b0XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Open issues in draft-gonzalez-netconf-event-notifications-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 16:34:05 -0000 --_000_cdf916490fd74036bd92639034d787b0XCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To help interpret the meaning of some of the open issues below, the subteam= is evolving a terminology page at: https://github.com/netconf-wg/yang-push/wiki/Terminology Eric From: Alberto Gonzalez Prieto, June 28, 2016 11:43 AM Hello, draft-gonzalez-netconf-event-notifications-00 is one of the four drafts in the set "Event Notification + Yang-push " Its scope is transporting Event Notifications over NETCONF. The open issues we are currently focusing on are: - configured subscriptions: - How to realized configured subscription? - The current line of work is based on call-home. - Once a subscription is configured, the server would contact the receiver = using call home. Once the NETCONF session is established, the server would send a . - From that point on, the server sends notifications to the receiver as per= the subscription configuration. - As for dynamic subscriptions, such a session could be used for multiple s= ubscriptions. This would be controlled by the server - Once the subscription is deleted, the server would send a and drop the session. - and multiple subscriptions on a session - Should multiple create-subscription's over a single NETCONF session be su= pported? - The current thinking is to support multiple subscriptions over a single s= ession only for establish-subscription's - The rationale being to simplify implementations If you have questions/input on these open issues or other aspects of the dr= aft, we will be happy to discuss them. Alberto Gonzalez (on behalf of the draft authors and the NETCONF WG members attending the we= ekly calls) --_000_cdf916490fd74036bd92639034d787b0XCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To help interpret the mea= ning of some of the open issues below, the subteam is evolving a terminolog= y page at:

https://github.com/netconf-wg/y= ang-push/wiki/Terminology

 <= /p>

Eric

 <= /p>

From: Alberto = Gonzalez Prieto, June 28, 2016 11:43 AM

Hello,

 

draft-gonzalez= -netconf-event-notifications-00 is one

of the four drafts in the set "= Event No= tification + Yang-push “

Its scope is transporting Event= Notifications over NETCONF.

The open issues we are currently focusing on are:

- configured subscriptions:<= o:p>

- How to realized configured subscription?

- The current line of work is based on call-home. 

- Once a subscription is config= ured, the server would contact the receiver using call home. Once the NETCO= NF

session is established, the server would send a <subscrip= tion-started>. 

- From that point on, the server sends notifications to the = receiver as per the subscription configuration.

- As for dynamic subscriptions,= such a session could be used for multiple subscriptions. This would be con= trolled

by the server

- Once the subscription is dele= ted, the server would send a <subscription-terminated>

and drop the session.

- <create-subscription> and multiple subscriptions on = a session

- Should m= ultiple create-subscription's over a single NETCONF session be supported?

- The current thinking is to support multiple subscriptions = over a single session only for establish-subscription’s

- The rationale being to simplify implementations





 

If you have questions/input on = these open issues or other aspects of the draft, we will be happy to discus= s them.

 

 

 

Alberto Gonzalez

 

(on behalf of the draft authors= and the NETCONF WG members attending the weekly calls)

 

--_000_cdf916490fd74036bd92639034d787b0XCHRTP013ciscocom_-- From nobody Tue Jun 28 10:22:32 2016 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 A502912D592 for ; Tue, 28 Jun 2016 10:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 KARxIrCURTrC for ; Tue, 28 Jun 2016 10:22:29 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF6E912B048 for ; Tue, 28 Jun 2016 10:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5072; q=dns/txt; s=iport; t=1467134548; x=1468344148; h=from:to:subject:date:message-id:mime-version; bh=HyYgTb7pnjZj5G7dJjmlWqFZPV15R9R45B4HQ5pbFUg=; b=LsVlQSSZj8Smxh9/IF1CXGmNaEFBZpEWxSHrLFPrPUxosgCASXMFr2Wx MJBfa5ffDGXSDRYQZs5bnJ7or3fDstuBHEMaR98S5QboC3RO7mYJrrpr6 L9pvlbBBVoyjjsFWrS8etGD/Rw7B2YZcRSDunnZfRP1B/Kdk6SRule0ro E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BFAgBasXJX/4sNJK1bgnBOgVm1K4UBg?= =?us-ascii?q?XuHSzgUAQEBAQEBAWUcC4RTdxQBLVMnBIhDo2ygHwEBCAEBAQEjhiiOaAWOM4p?= =?us-ascii?q?PAYEwjQmPJI9+AR42g3CJH38BAQE?= X-IronPort-AV: E=Sophos;i="5.26,542,1459814400"; d="scan'208,217";a="291044297" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2016 17:22:27 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u5SHMRj4012747 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 28 Jun 2016 17:22:27 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 28 Jun 2016 12:22:27 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1210.000; Tue, 28 Jun 2016 12:22:27 -0500 From: "Ambika Prasad Tripathy (ambtripa)" To: "netconf@ietf.org" Thread-Topic: Open issues in draft-gonzalez-netconf-event-notifications-00 Thread-Index: AQHR0WGk39E5a6oqSke1XLL2I/Utrg== Date: Tue, 28 Jun 2016 17:22:27 +0000 Message-ID: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.47.130] Content-Type: multipart/alternative; boundary="_000_D398AA7A13785ambtripaciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] Open issues in draft-gonzalez-netconf-event-notifications-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 17:22:31 -0000 --_000_D398AA7A13785ambtripaciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, For Event Notification and YANG-PUSH drafts, on of the transport requiremen= ts is NetConf. One of the open issue, I am currently focussing is the Subscription Priorit= y and QoS over NetConf Transport * We are enabling to create multiple create-subscription over a single = netconf session. * All subscription may not be of same priority. Say, out of multiple su= bscription request placed in a session, security related subscription may b= e of greater priority than counters. * At publisher, there may be multiple session with multiple subscriptio= n. * There should be a way to differentiate between subscription priority = across the sessions at publisher and inside a session at subscriber. * The Publisher should address high priority subscriptions across all t= he session before handling low priority subscription. * What should be the right way to handle priority of subscriptions? If you have questions/input on these open issues or other aspects of the dr= aft, we will be happy to discuss them. - Br, Ambika Prasad Tripathy (on behalf of the draft authors and the NETCONF WG members attending the we= ekly calls) --_000_D398AA7A13785ambtripaciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <4DFD3BD80B63CC4BA2120742B7E6D9F9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,

For Event Notification and YANG-PUSH drafts, on of the transport requi= rements is NetConf.
<= span style=3D"white-space: pre;">One of the open issue, I am c= urrently focussing is the Subscription Priority and QoS over NetConf Transport 
  • We are enabling to create multiple create-subscripti= on over a single netconf session.
  • All subscription may not = be of same priority. Say, out of multiple subscription request placed in a = session, security related subscription may be of greater priority than coun= ters.
  • At publisher, there may be multiple session with multiple su= bscription.
  • There should be a way to differentiate between subscr= iption priority across the sessions at publisher and inside a session = at subscriber. 
  • The Publisher should address high priori= ty subscriptions across all the session before handling low priority subscr= iption.
  • What should be the right way to handle priority of subscri= ptions?
If you have questions/input on these open issues or other aspects of t= he draft, we will be happy to discuss them.
 
&= #8212; 
B= r,
A= mbika Prasad Tripathy
(on behalf of the dra= ft authors and the NETCONF WG members attending the weekly calls)

--_000_D398AA7A13785ambtripaciscocom_-- From nobody Tue Jun 28 11:14:10 2016 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 931BF12D63A for ; Tue, 28 Jun 2016 11:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 M2NUCQItm4aw for ; Tue, 28 Jun 2016 11:14:08 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7EE312D639 for ; Tue, 28 Jun 2016 11:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14105; q=dns/txt; s=iport; t=1467137647; x=1468347247; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ofqqI2kcA4SFUuWnviJjPMdaaP7gh2KIkdu4iOZdnMM=; b=Yvk5+yRv+Y1PH2kjpYgSP2YdsnmSEhxxHH0zWpWF31Mwj8BuhqYHdljb JhxTPQGsrwThOzxA0OxRSVOxaPZJyzV3zEEoNgbZ2NR4+VwYCjQrSCUjp 7saBYViFY7Oi6ucBrkMnVtiVUh5PanTfpsSGegdPNSxNsAxYpqMfqzmiR 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHAgAUvXJX/4wNJK1bgnBOVoEDtSuFA?= =?us-ascii?q?YF7JIV0AoE0OBQBAQEBAQEBZSeETAEBAQQtShICAQgVECEyJQIEARqIKA7ECQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBARcFhiiETYobBZkCAYYHiCuBcI07hlSJKgEeN?= =?us-ascii?q?oNwiR9/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,542,1459814400"; d="scan'208,217";a="291170974" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2016 18:14:06 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u5SIE6R8030026 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 28 Jun 2016 18:14:06 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 28 Jun 2016 14:14:05 -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.1210.000; Tue, 28 Jun 2016 14:14:05 -0400 From: "Eric Voit (evoit)" To: "Ambika Prasad Tripathy (ambtripa)" , "netconf@ietf.org" Thread-Topic: [Netconf] Open issues in draft-gonzalez-netconf-event-notifications-00 Thread-Index: AQHR0WGk39E5a6oqSke1XLL2I/Utrp//KIbg Date: Tue, 28 Jun 2016 18:14:05 +0000 Message-ID: <5ef34b11ff8e4fdaab52b5841eec84fc@XCH-RTP-013.cisco.com> References: In-Reply-To: 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.118.56.231] Content-Type: multipart/alternative; boundary="_000_5ef34b11ff8e4fdaab52b5841eec84fcXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Open issues in draft-gonzalez-netconf-event-notifications-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 18:14:09 -0000 --_000_5ef34b11ff8e4fdaab52b5841eec84fcXCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ambika, I see this question broken in two: (1) For NETCONF transport dequeuing, is there an issue with head-of-line bl= ocking where we should pre-empt a lower priority update in favor of a highe= r priority one? And if yes, is this an issue which is generic to NETCONF t= ransport as a whole rather than being specific to subscriptions? (2) Subscription priority has been defined as an augmentation in YANG-Push<= https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/?include_text= =3D1>. Priority is not available in the base RFC5277bis spec. Ind= ependent of transport (e.g., NETCONF, Restconf, HTTP), is there anyone on t= his alias who has a requirement for subscription priority for generic event= notifications? Eric From: Ambika Prasad Tripathy, June 28, 2016 1:22 PM Hi, For Event Notification and YANG-PUSH drafts, on of the transport requiremen= ts is NetConf. One of the open issue, I am currently focussing is the Subscription Priorit= y and QoS over NetConf Transport * We are enabling to create multiple create-subscription over a single = netconf session. * All subscription may not be of same priority. Say, out of multiple su= bscription request placed in a session, security related subscription may b= e of greater priority than counters. * At publisher, there may be multiple session with multiple subscriptio= n. * There should be a way to differentiate between subscription priority = across the sessions at publisher and inside a session at subscriber. * The Publisher should address high priority subscriptions across all t= he session before handling low priority subscription. * What should be the right way to handle priority of subscriptions? If you have questions/input on these open issues or other aspects of the dr= aft, we will be happy to discuss them. - Br, Ambika Prasad Tripathy (on behalf of the draft authors and the NETCONF WG members attending the we= ekly calls) --_000_5ef34b11ff8e4fdaab52b5841eec84fcXCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ambika,

 <= /p>

I see this question broke= n in two:

 <= /p>

(1) For NETCONF transport= dequeuing, is there an issue with head-of-line blocking where we should pr= e-empt a lower priority update in favor of a higher priority one?  And if yes, is this an issue which is generic to NETCONF transp= ort as a whole rather than being specific to subscriptions?

 <= /p>

(2) Subscription priority= has been defined as an augmentation in YANG-Push.  Priority is not available in the base RFC5277bis spec.  Independent of transport (e.g., NETCONF, Restcon= f, HTTP), is there anyone on this alias who has a requirement for subscript= ion priority for generic event notifications?  

 <= /p>

Eric

 <= /p>

From: Ambika P= rasad Tripathy, June 28, 2016 1:22 PM

Hi,



For Event Notification and YANG-PUSH drafts= , on of the transport requirements is NetConf.

One of the open issue, I am currently focussing is the = Subscription Priority and QoS over NetConf Transport 

  • We are e= nabling to create multiple create-subscription over a single netconf sessio= n.
  • All subs= cription may not be of same priority. Say, out of multiple subscription req= uest placed in a session, security related subscription may be of greater p= riority than counters.
  • At publi= sher, there may be multiple session with multiple subscription.=
  • There sh= ould be a way to differentiate between subscription priority across th= e sessions at publisher and inside a session at subscriber. 
  • The Publ= isher should address high priority subscriptions across all the session bef= ore handling low priority subscription.
  • What sho= uld be the right way to handle priority of subscriptions?=

 

If you have questions/input on = these open issues or other aspects of the draft, we will be happy to discus= s them.

 

 

 

— 

Br,

Ambika Prasad Tripathy

(on behalf of the draft authors and the NETCONF WG members a= ttending the weekly calls)

 

--_000_5ef34b11ff8e4fdaab52b5841eec84fcXCHRTP013ciscocom_-- From nobody Tue Jun 28 19:09:00 2016 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 B0DD312D0D1; Tue, 28 Jun 2016 19:08:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160629020858.22540.14908.idtracker@ietfa.amsl.com> Date: Tue, 28 Jun 2016 19:08:58 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-restconf-14.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 02:08:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : RESTCONF Protocol Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-restconf-14.txt Pages : 123 Date : 2016-06-28 Abstract: This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in NETCONF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-restconf-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 28 19:10:29 2016 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 B897012D9CD; Tue, 28 Jun 2016 19:10:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160629021023.22565.94510.idtracker@ietfa.amsl.com> Date: Tue, 28 Jun 2016 19:10:23 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-patch-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 02:10:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : YANG Patch Media Type Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-yang-patch-09.txt Pages : 34 Date : 2016-06-28 Abstract: This document describes a method for applying patches to configuration datastores using data defined with the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-patch-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 Tue Jun 28 19:15:58 2016 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 3FD2012D9C5 for ; Tue, 28 Jun 2016 19:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 JhXu2yCLiZGh for ; Tue, 28 Jun 2016 19:15:54 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::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 D1A2112D511 for ; Tue, 28 Jun 2016 19:15:53 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id j3so47589712vkb.0 for ; Tue, 28 Jun 2016 19:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TLIgP8TrjPj0KuppVzyRd22UcF+quT5zIHAHYHLGlf4=; b=Jt6fUaN/RBwctBmCZ4yR8VSMt9hHGmg9Y69UfAGVGiJ23zYd1guSsISaJZEtwB85gZ AUyzkDKUsD75c9xoy97W7VQz9ZTR9NJ6IwjOpJhP9Y0WUUgtfz0RaNC9/Dp1cS6MMjDh THvl4L+nj6BVYclHw+siuzFM7s8sZyPQ1uYP6uEKgKWQb1GC5V0JKgPqnu5aVTefeURP fX2khEWq/JzJE1jRm55Y9ihRtKoeQ7XbEoLupk65t7XzTarY4gg3BITMjmMyLfg9VUTv C0hL6A0avYmr5Kqrw0YzJic6u9AqAs1tjdEN+wl0M4IFXliRMElo1hImIubwPnx7cjPU aCeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TLIgP8TrjPj0KuppVzyRd22UcF+quT5zIHAHYHLGlf4=; b=i8zBXRBpveiu9oFEEgkBfJ3ry/xpXYf72AcQPhBNIFCfnmmD05332LgKUzwMQ2IzVo yDXjpkSmUsa6Xb4xvN0EXrZfRKuJ0JF+Q0coQC5uNOxRFMSzxDReX9G72ZmhQl55jol4 ixgyaTyX+hyymOMVf0iy4OoKfdopepkYl2/vqN1+J/dQloJ/Zjqctjp4iJTGLa+vLr5X dbPnbXZ2VDCqvSG5dmjWMob0IqunTy692adyjY2e1mWMDlWiCN2wxc4bOCqXK6+71LSX AxZ8JilExBf3dT3sQUthTkaZXmF+w5ME60TIMNw/3LlL6UQDkqvsvjihE+C/ouJ1yX1d GXJg== X-Gm-Message-State: ALyK8tL17YgyJ0CJzOHgnTuTxK8MMeAIvNBSMXioKIl0ey7SCKKIjE34P30RATZmcbBUBApaRmvv08vXpLw2Eg== X-Received: by 10.176.64.166 with SMTP id i35mr2465552uad.105.1467166552981; Tue, 28 Jun 2016 19:15:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Tue, 28 Jun 2016 19:15:52 -0700 (PDT) In-Reply-To: <20160629020858.22540.14908.idtracker@ietfa.amsl.com> References: <20160629020858.22540.14908.idtracker@ietfa.amsl.com> From: Andy Bierman Date: Tue, 28 Jun 2016 19:15:52 -0700 Message-ID: To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=94eb2c1243b2379d6605366155ee Archived-At: Cc: Netconf , i-d-announce@ietf.org Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-14.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 02:15:57 -0000 --94eb2c1243b2379d6605366155ee Content-Type: text/plain; charset=UTF-8 Hi, This draft addresses almost all issues in all reviews found on github: https://github.com/netconf-wg/restconf/issues Detailed comments about the reviews can be found in the github comment history for each issue. Andy On Tue, Jun 28, 2016 at 7:08 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Network Configuration of the IETF. > > Title : RESTCONF Protocol > Authors : Andy Bierman > Martin Bjorklund > Kent Watsen > Filename : draft-ietf-netconf-restconf-14.txt > Pages : 123 > Date : 2016-06-28 > > Abstract: > This document describes an HTTP-based protocol that provides a > programmatic interface for accessing data defined in YANG, using the > datastore concepts defined in NETCONF. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-netconf-restconf-14 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-14 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --94eb2c1243b2379d6605366155ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Jun 28, 2016 at 7:08 PM, = <internet-drafts@ietf.org> wrote:

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= RESTCONF Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Andy= Bierman
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Martin Bjorklund
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Kent Watsen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-netconf-restconf-14.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 123
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-06-28

Abstract:
=C2=A0 =C2=A0This document describes an HTTP-based protocol that provides a=
=C2=A0 =C2=A0programmatic interface for accessing data defined in YANG, usi= ng the
=C2=A0 =C2=A0datastore concepts defined in NETCONF.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ne= tconf-restconf-14

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


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/

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

--94eb2c1243b2379d6605366155ee-- From nobody Tue Jun 28 19:21:24 2016 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 B4B3112D9C5 for ; Tue, 28 Jun 2016 19:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 fCAsyRnSkova for ; Tue, 28 Jun 2016 19:21:20 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 A910812B049 for ; Tue, 28 Jun 2016 19:21:20 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id k62so37615962vkb.3 for ; Tue, 28 Jun 2016 19:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=0Y13CfbLHnV/0QJx4XJ8JC1zSvhq1ccdaYk8G4QkiuA=; b=zqRMCzJwIEhobwH+mcAOAeLtqC48sEfIW1n1A4Wq4wdbAy7hEAgaFlZFTUTU8PGqVu LLalw0cL5DgN996whdW9H9JyrVSYHfbFN5ZKXRPvpNqBtkrtEiMbuQLkDSHACAvxooaI VpY5eOqN+TRLSDXlOMsCoqOhfO2EvSplKN96BAaPs1shxuRFbfBpyDP0UN+XpI0nj67y T80mwyG8e4cA8JT1LZoGuW8gizdmcIgWhuaPP1vD9yx3SmdtIz4euHip99GBG17uCFXQ kEEM1Ch5nVI4OPjkBXUbAdCicApKt8HArbpGsyt620HgcgTFN5iEZHmyeec4dEhOj1RJ JgKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=0Y13CfbLHnV/0QJx4XJ8JC1zSvhq1ccdaYk8G4QkiuA=; b=ODpo3DNGK3JzxdQQTGt+XPM+qdCz1Sqt7zpJpUJ+5tPjjIPQ4qu/ajbml+GwCHWj1G 9IwV6aQ27exas/5KlwCWck/w+Tm+tamhkF56KfUTn9t94Iq6ViK61tYkAlBWe4NBMkew bKFaGh7ISh0hqChUV8K6jOOLYFczi30ZXeKdOgCKqzuEz6id2nw2L80930wWPCuFsCxc ZhklvtDibxIbwBjvCE0omLQC+RQYbMkOwNZSl3AAUB/k9TBk+iKBEufYLLGvhkrjpZNX vsR/jZOlG0L2+mC/VKIqcWqeO434fhTDk9bua6N4txjDBDA38ECiZV911eHCkjzdpKjt 1bfg== X-Gm-Message-State: ALyK8tKdTirlxpw9alXH93MJGU+ZBBrt9USW2s2Ax7ViNxvpqjEl4w3kZOXozkiAqLjvg2LLc1brW52Fy+2u9w== X-Received: by 10.176.7.7 with SMTP id h7mr2519301uah.9.1467166879796; Tue, 28 Jun 2016 19:21:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Tue, 28 Jun 2016 19:21:19 -0700 (PDT) In-Reply-To: <20160629021023.22565.94510.idtracker@ietfa.amsl.com> References: <20160629021023.22565.94510.idtracker@ietfa.amsl.com> From: Andy Bierman Date: Tue, 28 Jun 2016 19:21:19 -0700 Message-ID: Cc: Netconf Content-Type: multipart/alternative; boundary=94eb2c1229d8b2c7a80536616800 Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-yang-patch-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 02:21:23 -0000 --94eb2c1229d8b2c7a80536616800 Content-Type: text/plain; charset=UTF-8 This draft addresses all issues found on github: https://github.com/netconf-wg/yang-patch/issues Andy On Tue, Jun 28, 2016 at 7:10 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Network Configuration of the IETF. > > Title : YANG Patch Media Type > Authors : Andy Bierman > Martin Bjorklund > Kent Watsen > Filename : draft-ietf-netconf-yang-patch-09.txt > Pages : 34 > Date : 2016-06-28 > > Abstract: > This document describes a method for applying patches to > configuration datastores using data defined with the YANG data > modeling language. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-patch-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/ > > _______________________________________________ > 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 > --94eb2c1229d8b2c7a80536616800 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

This d= raft addresses all issues found on github:


https://g= ithub.com/netconf-wg/yang-patch/issues



Andy


On Tue, Jun 28, 2016 at 7:10 PM, <= internet-draf= ts@ietf.org> wrote:

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= YANG Patch Media Type
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Andy= Bierman
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Martin Bjorklund
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Kent Watsen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-netconf-yang-patch-09.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 34
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-06-28

Abstract:
=C2=A0 =C2=A0This document describes a method for applying patches to
=C2=A0 =C2=A0configuration datastores using data defined with the YANG data=
=C2=A0 =C2=A0modeling language.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draf= t-ietf-netconf-yang-patch/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-n= etconf-yang-patch-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url= 2=3Ddraft-ietf-netconf-yang-patch-09


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/listinf= o/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--94eb2c1229d8b2c7a80536616800-- From nobody Tue Jun 28 19:25:04 2016 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 7736E12D9C5 for ; Tue, 28 Jun 2016 19:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 t3G4E7WTYGiA for ; Tue, 28 Jun 2016 19:25:01 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 9C0F012B049 for ; Tue, 28 Jun 2016 19:25:01 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id u68so5076201vkf.2 for ; Tue, 28 Jun 2016 19:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=O328n+BKy1AKldgjLibm8P9OIf5dgi0VRngcRRYxans=; b=BylvGEsl6JoEQX/AitX5YCBaabSRuXzCUGYn66BDgaNLJxkGLqGf5/G/vvSzjzcoWL 2CUmtvU0L3voZInekSdPGSDRXEpVK1BHmdRTyQg3IYfslftzsmudp/ZqXpHLEapHXUW0 jy7enN4q+wfyACbQ+YQrPICfbG+Ty1qww0EI5jJ1Ax3e3z8RGPaEYKBA37vZgVIWiPXf LFtn6yODcrLJFFKkxTbrOdLTXaLr4wef3Fpwd4X0aIfjVNorGMx9VZ02Cvgd0ld2yD6O ICUpAS/cgfz7XvCIl4cnNDo1WJxSetbeahOFdu0kgAcZHVD4lGD9VBghEWYcKw/LaiHv KLRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=O328n+BKy1AKldgjLibm8P9OIf5dgi0VRngcRRYxans=; b=SPlOd1rnq3E3N9vTJ/6kip86WZ/R/84qybBDDHFSwOIvxHOWlid85Nm4yjOqiWFCK1 +8Uuo9FEuWbzxpD71glspsMAiHu0wApIX/0ub0d449LK4Rt47ZKQGtGmDsv0XdJSIH6N QPRJhoMfEUmICPq0lk0F6BuWt5LwhNngswM+hBTqKlT3qcmwrwEJQ3stMvrbhuUgdE8v nfwB7wwH/P9dNqI/vspKfE25pZgRNZ9m5jWAkK6uITezT4EWofJGnnUfmEkkIO0aAQzc WnonRNdxNx0n2dz3vw7RdgYqxJlF62uZjzk17QyE8BiAHFdImpQZYQ3el4S/pfF9cc9a 1g2A== X-Gm-Message-State: ALyK8tJusAZyJmrkpeeJUisYqu96hnfm/in8KisPBJ5iuxXw6T+Xvus+6qIdS44TvyPM+kudDZQaK6q8vlLpAw== X-Received: by 10.176.64.166 with SMTP id i35mr2479403uad.105.1467167100790; Tue, 28 Jun 2016 19:25:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Tue, 28 Jun 2016 19:24:59 -0700 (PDT) From: Andy Bierman Date: Tue, 28 Jun 2016 19:24:59 -0700 Message-ID: To: media-types@iana.org Content-Type: multipart/alternative; boundary=94eb2c1243b2de909d0536617539 Archived-At: Cc: Netconf Subject: [Netconf] request review of media type application/yang-data+xml X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 02:25:03 -0000 --94eb2c1243b2de909d0536617539 Content-Type: text/plain; charset=UTF-8 Hi, Please review and provide feedback on the revised media type registration for the RESTCONF protocol. https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-11.3.1 thanks, Andy --94eb2c1243b2de909d0536617539 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please review and provide feedback = on the revised media type registration
for the RESTCONF protocol.=




thanks,
Andy

--94eb2c1243b2de909d0536617539-- From nobody Tue Jun 28 19:27:10 2016 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 9B4CD12D1DC for ; Tue, 28 Jun 2016 19:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 82XImhQYZgsH for ; Tue, 28 Jun 2016 19:27:07 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 D9CC012D9C5 for ; Tue, 28 Jun 2016 19:27:06 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id u68so5121265vkf.2 for ; Tue, 28 Jun 2016 19:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=e4AP5xFuUw/loBVRWqgDq3KiKGttsPoko0MaYmlhjjQ=; b=s7pb0qL+Jz31suB/Ow/Sof1RfkJ33ZNA66b+Trl+7FRRlaBDrhgs2EnLL8Dpp2sKRz FkOr+aZC1prLtgDfuZJV1eayQl3wpJOpeb6htObDSH5VFL3OzZBejK54oNjkOHCKDV2Z CHFfQN8hqY0qywfz9PcISd28YHwBfGKRNisZLlS49EyI/Yb0itkDgy92rpqW/cg1SHw+ /xRprgBVTrWNJ1kIWMCXPBLzuoGHmybxpEBY00FHoy3qnVSI0KJiR33MLKv5q0fwI9oB qlM5n24nkuIWSokox0klZglMPDTam53DMYcu4JFdqutgFj5qq2JYTKn7sBlA6hr7o7Fp xWNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=e4AP5xFuUw/loBVRWqgDq3KiKGttsPoko0MaYmlhjjQ=; b=aiiY21owNckhsqtvrYdsEFQ8YR56/gTIWf4h/+uKgewu/93q/ALt7DAH0X1YB/OvPN NQvKzey+Mxq1ecYUMPaX7GwT27nR+/5TGjH/h/9IE8p+XYvZHVBdwTpHSzzDCD+Ixsyr nLjcMxQ80kOVXrZO3uyg+Bddhmw10khqIVeh3Ey4yuFX3zzu3tkI1g85XL2lFS7wtuE/ aihVtusVm5mQ5yvob/JJFc5q7ct/ulCesRxdVhxstkuKkcwtYztA/WiOU4jJfLc0WU3D 0SRkpwplrXwvNSiKzosYHec6a5uLPWnBlLnaAqeRrgyEvVPQHmZTYMsnIMlsTOQ+dycz u8rg== X-Gm-Message-State: ALyK8tI+ls7JpElwrWg5+PNHQRljUZ37ucimkt944qL36naU+L3lLJcmZTns7Y6N5AWSqu9gfoC/lqDV6VYuPQ== X-Received: by 10.159.36.245 with SMTP id 108mr2544649uar.121.1467167226027; Tue, 28 Jun 2016 19:27:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Tue, 28 Jun 2016 19:27:05 -0700 (PDT) From: Andy Bierman Date: Tue, 28 Jun 2016 19:27:05 -0700 Message-ID: To: media-types@iana.org Content-Type: multipart/alternative; boundary=001a11398fe655aa750536617d16 Archived-At: Cc: Netconf Subject: [Netconf] request review of media type application/yang-data+json X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 02:27:08 -0000 --001a11398fe655aa750536617d16 Content-Type: text/plain; charset=UTF-8 Hi, Please review and provide feedback on the revised media type registration for the RESTCONF protocol. https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-11.3.2 thanks, Andy --001a11398fe655aa750536617d16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please review and provide feedback = on the revised media type registration
for the RESTCONF protocol.=




thanks,
Andy

--001a11398fe655aa750536617d16-- From nobody Tue Jun 28 19:30:04 2016 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 6EAC812D1DC for ; Tue, 28 Jun 2016 19:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 rLQ3IEWtwdxV for ; Tue, 28 Jun 2016 19:30:01 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 7857F12D15F for ; Tue, 28 Jun 2016 19:30:01 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id u68so5185633vkf.2 for ; Tue, 28 Jun 2016 19:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=5TxSTFcih7jxuz3ehwsm3KuKjQPuxYPaw7iEECf9+r8=; b=i2bMiUEVmIqJPjsZo14LJb9JwXA+SdvqnaQ8t7aQSzt0pLY+Ie1YgfkQHjrLBAqvdn bAh5Nz3NCsgztaOmOkOPk3JBcfQMQd8UQ/X/nZFuD0MZcCQ0L3FO7pgVPp78z2joypBH 3KGCLgh2TMHiu9JL8dwzsPHYttvmMUXQcbhf8tMWWjV5hfg25eRQLG51c9Jd98zq7TEG wwz0dr9OD+gpkTiqn+xPL5uQKRBTgm3MdS8dcfYsbgugSaafa37NbHuOp4XobRSDtOU7 CDtsYRTblWIbwkd9FMOUSDxVsigu90OwllcE9PqygxM8azSagqjS5iI7tCrY+HKyOKK9 +QCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=5TxSTFcih7jxuz3ehwsm3KuKjQPuxYPaw7iEECf9+r8=; b=ZiPfM4eZC6pwBJoOdPtahsTFHCIOUqVeI0RO04MO11Y/b5y6QC9dWTRWiQhHntT1ki mq86KsW5Nyo2T7OntSgpkEKXsa3dwpDNoyEfUG4SdNA1M0lsAoTtypTK62JLYAUZiCdN lpMVxS9hdqGq+s3JuIc/uImwlm210i19e1s19r4IXavo9bg1quZtJt66j2qqJxx7nG8P JV1Qh1mT0vpdaBmzhwNTJdT8/GVVzs1oiM0rs85mrN58tDJj89EUMQGhW6dEbL0g84l+ 7fWIOak7nq00wPHyARzZtAvyWh46i716o36cTUuUi+cOpT8jvjN+cWDu+fcPoMQ0htVB jYOA== X-Gm-Message-State: ALyK8tJgDApPTgsLQdhD6fwQU2MxRKs2FACZe92OTlF73oUfWZNHzAFHFFNZcukJ6UJ9nP3RMBiYrynpeQ+sPA== X-Received: by 10.159.35.72 with SMTP id 66mr2512348uae.55.1467167400608; Tue, 28 Jun 2016 19:30:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Tue, 28 Jun 2016 19:29:59 -0700 (PDT) From: Andy Bierman Date: Tue, 28 Jun 2016 19:29:59 -0700 Message-ID: To: media-types@iana.org Content-Type: multipart/alternative; boundary=001a11353092bd60cf0536618731 Archived-At: Cc: Netconf Subject: [Netconf] request review of media type application/yang-patch+xml X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 02:30:03 -0000 --001a11353092bd60cf0536618731 Content-Type: text/plain; charset=UTF-8 Hi, Please review and provide feedback on the media type registration for YANG Patch media type for the PATCH method. This is used by the RESTCONF protocol. https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-09#section-4.2.1 thanks, Andy --001a11353092bd60cf0536618731 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please review an= d provide feedback on the media type registration
for =C2=A0YANG Patch media type for the PATCH method.=C2=A0 Thi= s is used by
the RESTCONF protocol.




thanks,
Andy

--001a11353092bd60cf0536618731-- From nobody Tue Jun 28 19:32:17 2016 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 DD88D12D9C5 for ; Tue, 28 Jun 2016 19:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 AH4iUR9tr6Z4 for ; Tue, 28 Jun 2016 19:32:14 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 0E99A12D1E6 for ; Tue, 28 Jun 2016 19:32:14 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id k62so37853914vkb.3 for ; Tue, 28 Jun 2016 19:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=LSSSPXRY54nu5aFo3/CVHYghuWgVecBu9Iw4vymDQhU=; b=c4x+PGJQWLhSPKSYsJp5qP8/MVmYbRLt1PayBEOpYGqqLruii/h5Ub6WcMsA2hvVnF A50tb2vg2AuLGnedBC9IBlkdDGWlj0DwykMOne3/kFKCn/43MEdbbQmUQpuTwQCWvNb6 w1jyxBUudpHHkohg3q3GmJp5x+3Fv5u2YqEOs7frxOssaA3/fAXHLGFKv6mCBP2OdrZS EtSsS4WmGTlssjkUG4Upt8s8gCeJuE5qsS4HXvEVnUcmo5AHcUNYMqFIhZY/17D7mVt0 YueoE+4fyEh5fpUL3f3jRdC5Xs2WLzOrO7EzyLUxO/jwsWfe2fKz4FoD1xZeIw/DKggb Qxlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=LSSSPXRY54nu5aFo3/CVHYghuWgVecBu9Iw4vymDQhU=; b=XgHXnky+dQIgpK5Q6sqKEf3WKGapll1gGZF97pXOpCGrcsFtm5JnDj6hm6AAAEHq43 kYe1Y5UFQSCzusKLpREA0zLqY4zeEiKDaOOwi0mCF/CCCIlqOWW/RVum1edaXAMrXLo3 YsaNAEFTvS5vAq7in29MFZtLK+BbSR926i+WTxd9SMHgiEZIuTEZVXQZnTu+OyIWUSeu ZuSHygG8bNQs+Enkau65Ii/wt2drayq6i7dfPJjkbXjNehW5kJVCNgNBl7UTYLmNY6DM YkByhkfRqtaScPSxijFBPm68WlEMD6/qx1QdkI3LMevETi8K/dHdkZdWGX3I+QtBIJFg z1eQ== X-Gm-Message-State: ALyK8tLoNGl/7NOJPh3KnWyM9BXPZk8syhLr7SiyZyfDKDUqb6qKesf0oDCK8Jj11S62aUmnL7q3X2TKmhkMuA== X-Received: by 10.159.36.245 with SMTP id 108mr2553152uar.121.1467167533247; Tue, 28 Jun 2016 19:32:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Tue, 28 Jun 2016 19:32:12 -0700 (PDT) From: Andy Bierman Date: Tue, 28 Jun 2016 19:32:12 -0700 Message-ID: To: media-types@iana.org Content-Type: multipart/alternative; boundary=001a11398fe6a543170536618fed Archived-At: Cc: Netconf Subject: [Netconf] request review of media type application/yang-patch+json X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 02:32:16 -0000 --001a11398fe6a543170536618fed Content-Type: text/plain; charset=UTF-8 Hi, Please review and provide feedback on the media type registration for the YANG Patch media type for the PATCH method. This is used by the RESTCONF protocol. https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-09#section-4.2.2 thanks, Andy --001a11398fe6a543170536618fed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please review an= d provide feedback on the media type registration
for =C2=A0the YANG Patch media type for the PATCH method.=C2=A0= This is used by
the RESTCONF protocol= .



thanks,
Andy

--001a11398fe6a543170536618fed-- From nobody Tue Jun 28 20:06:54 2016 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 25E0A12D9DA for ; Tue, 28 Jun 2016 20:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 Ik_LwiGXhVS5 for ; Tue, 28 Jun 2016 20:06:50 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 6E8D312D9C6 for ; Tue, 28 Jun 2016 20:06:46 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3C212509B6; Tue, 28 Jun 2016 23:06:44 -0400 (EDT) To: Andy Bierman , media-types@iana.org References: From: Sean Leonard Message-ID: Date: Tue, 28 Jun 2016 20:06:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Netconf Subject: Re: [Netconf] request review of media type application/yang-data+xml X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 03:06:52 -0000 It is considered customary to copy and paste *just* the registration text in this mailing list. Here you go: Type name: application Subtype name: yang-data+xml Required parameters: none Optional parameters: none // RFC Ed.: replace draft-ietf-netmod-rfc6020bis with // the actual RFC reference for YANG 1.1, and remove this note. Encoding considerations: 8-bit Each conceptual YANG data node is encoded according to XML Encoding Rules and Canonical Format for the specific YANG data node type defined in [draft-ietf-netmod-rfc6020bis]. // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the // section number for Security Considerations // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual // RFC number, and remove this note. Security considerations: Security considerations related to the generation and consumption of RESTCONF messages are discussed in Section NN of [RFCXXXX]. Additional security considerations are specific to the semantics of particular YANG data models. Each YANG module is expected to specify security considerations for the YANG data defined in that module. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Interoperability considerations: [RFCXXXX] specifies format of conforming messages and the interpretation thereof. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Published specification: RFC XXXX Applications that use this media type: Instance document data parsers used within a protocol or automation tool that utilizes YANG defined data structures. Fragment identifier considerations: The fragment field in the request URI has no defined purpose. Additional information: Deprecated alias names for this type: n/a Magic number(s): n/a File extension(s): .xml Macintosh file type code(s): "TEXT" // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Person & email address to contact for further information: See Authors' Addresses section of [RFCXXXX]. Intended usage: COMMON (One of COMMON, LIMITED USE, or OBSOLETE.) Restrictions on usage: n/a // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Author: See Authors' Addresses section of [RFCXXXX]. Change controller: Internet Engineering Task Force (mailto:iesg&ietf.org). Provisional registration? (standards tree only): no On 6/28/2016 7:24 PM, Andy Bierman wrote: > Hi, > > Please review and provide feedback on the revised media type registration > for the RESTCONF protocol. > > https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-11.3.1 > From nobody Tue Jun 28 20:07:53 2016 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 11BD712D544 for ; Tue, 28 Jun 2016 20:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 3dPI4_P-0WsL for ; Tue, 28 Jun 2016 20:07:50 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 7096612D1DC for ; Tue, 28 Jun 2016 20:07:50 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5D8C6509B5; Tue, 28 Jun 2016 23:07:49 -0400 (EDT) To: Andy Bierman , media-types@iana.org References: From: Sean Leonard Message-ID: Date: Tue, 28 Jun 2016 20:07:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Netconf Subject: Re: [Netconf] request review of media type application/yang-data+json X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 03:07:52 -0000 For application/yang-data+json: Type name: application Subtype name: yang-data+json Required parameters: none Optional parameters: none // RFC Ed.: replace draft-ietf-netmod-yang-json with // the actual RFC reference for JSON Encoding of YANG Data, // and remove this note. // RFC Ed.: replace draft-ietf-netmod-yang-metadata with // the actual RFC reference for JSON Encoding of YANG Data, // and remove this note. Encoding considerations: 8-bit Each conceptual YANG data node is encoded according to [draft-ietf-netmod-yang-json]. A data annotation is encoded according to [draft-ietf-netmod-yang-metadata] // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the // section number for Security Considerations // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual // RFC number, and remove this note. Security considerations: Security considerations related to the generation and consumption of RESTCONF messages are discussed in Section NN of [RFCXXXX]. Additional security considerations are specific to the semantics of particular YANG data models. Each YANG module is expected to specify security considerations for the YANG data defined in that module. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Interoperability considerations: [RFCXXXX] specifies format of conforming messages and the interpretation thereof. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Published specification: RFC XXXX Applications that use this media type: Instance document data parsers used within a protocol or automation tool that utilizes YANG defined data structures. Fragment identifier considerations: The fragment field in the request URI has no defined purpose. Additional information: Deprecated alias names for this type: n/a Magic number(s): n/a File extension(s): .json Macintosh file type code(s): "TEXT" // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Person & email address to contact for further information: See Authors' Addresses section of [RFCXXXX]. Intended usage: COMMON (One of COMMON, LIMITED USE, or OBSOLETE.) Restrictions on usage: n/a // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Author: See Authors' Addresses section of [RFCXXXX]. Change controller: Internet Engineering Task Force (mailto:iesg&ietf.org). Provisional registration? (standards tree only): no On 6/28/2016 7:27 PM, Andy Bierman wrote: > Hi, > > Please review and provide feedback on the revised media type registration > for the RESTCONF protocol. > > https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-11.3.2 > From nobody Tue Jun 28 20:18:20 2016 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 4016412D1DC for ; Tue, 28 Jun 2016 20:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 eQoG_0Um2pVK for ; Tue, 28 Jun 2016 20:18:15 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 5E72B12B00E for ; Tue, 28 Jun 2016 20:18:15 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1651150A73; Tue, 28 Jun 2016 23:18:13 -0400 (EDT) To: Andy Bierman , media-types@iana.org References: From: Sean Leonard Message-ID: <8f8db9b8-9917-4b26-25f6-ee0c19492bb9@seantek.com> Date: Tue, 28 Jun 2016 20:17:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E768ED3CFACB771DBCC98671" Archived-At: Cc: Netconf Subject: Re: [Netconf] request review of media type application/yang-data+xml X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 03:18:18 -0000 This is a multi-part message in MIME format. --------------E768ED3CFACB771DBCC98671 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Based on the discussion on media-types@ and netconf@ that I have=20 observed, the registration is in pretty good substantive shape. I have=20 no substantive comments except for the fragment identifier, which I=20 understand is not of consequence to YANG processors. What follows below=20 are mostly editorial edits: On 6/28/2016 8:06 PM, Sean Leonard wrote: > It is considered customary to copy and paste *just* the registration=20 > text in this mailing list. > Here you go: > > Type name: application > > Subtype name: yang-data+xml > > Required parameters: none Usually I see this written "None." Purely editorial preference. > > Optional parameters: none Ditto. > > // RFC Ed.: replace draft-ietf-netmod-rfc6020bis with > // the actual RFC reference for YANG 1.1, and remove this note. > > Encoding considerations: 8-bit > Each conceptual YANG data node is encoded according to > XML Encoding Rules and Canonical Format for the specific > YANG data node type defined in [draft-ietf-netmod-rfc6020bis]. "is encoded according to the XML Encoding Rules"... > > // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the > // section number for Security Considerations > // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual > // RFC number, and remove this note. > > Security considerations: Security considerations related > to the generation and consumption of RESTCONF messages > are discussed in Section NN of [RFCXXXX]. > Additional security considerations are specific to the > semantics of particular YANG data models. Each YANG module > is expected to specify security considerations for the > YANG data defined in that module. > > // RFC Ed.: replace XXXX with actual RFC number and remove this > // note. > > Interoperability considerations: [RFCXXXX] specifies format of > conforming messages and the interpretation thereof. "[RFCXXXX] specifies the format of"... > > // RFC Ed.: replace XXXX with actual RFC number and remove this > // note. > > Published specification: RFC XXXX > > Applications that use this media type: Instance document > data parsers used within a protocol or automation tool > that utilizes YANG defined data structures. "Instance document data parsers used within a protocol or automation tool= that utilize YANG-defined data structures." Change utilizes -> utilize. It's plural. I think YANG-defined is correct due to being stacked noun phrases, or=20 something. > > Fragment identifier considerations: The fragment field in the > request URI has no defined purpose. From the perspective of NETCONF this is probably correct. However,=20 Section 4.11 of RFC 6838 says: Media types are encouraged to adopt fragment identifier schemes that are used with semantically similar media types. In particular, media= types that use a named structured syntax with a registered "+suffix" MUST follow whatever fragment identifier rules are given in the structured syntax suffix registration. There are some things about +xml things: http://www.iana.org/assignments/media-type-structured-suffix/media-type-s= tructured-suffix.xhtml RFC 7303. Look it up. I don't have experience dealing with this, and I would not hold back the = registration on that basis. The Expert Reviewer might. > > Additional information: > > Deprecated alias names for this type: n/a > Magic number(s): n/a > File extension(s): .xml > Macintosh file type code(s): "TEXT" > > // RFC Ed.: replace XXXX with actual RFC number and remove this > // note. > > Person & email address to contact for further information: See > Authors' Addresses section of [RFCXXXX]. > > Intended usage: COMMON > > (One of COMMON, LIMITED USE, or OBSOLETE.) You can remove the parenthetical. It's not part of the template instance.= > > Restrictions on usage: n/a RFC 6838 Section 5.6 says '"N/A", written exactly that way'. Stick with=20 N/A (all-caps). > > // RFC Ed.: replace XXXX with actual RFC number and remove this > // note. > > Author: See Authors' Addresses section of [RFCXXXX]. > > Change controller: Internet Engineering Task Force > (mailto:iesg&ietf.org). > > Provisional registration? (standards tree only): no You can also remove the parenthetical. It's not part of the template=20 instance. Best regards, Sean > > On 6/28/2016 7:24 PM, Andy Bierman wrote: >> Hi, >> >> Please review and provide feedback on the revised media type=20 >> registration >> for the RESTCONF protocol. >> >> https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-11.= 3.1=20 >> >> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------E768ED3CFACB771DBCC98671 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Based on the discussion on media-types@ and netconf@ that I have observed, the registration is in pretty good substantive shape. I have no substantive comments except for the fragment identifier, which I understand is not of consequence to YANG processors. What follows below are mostly editorial edits:

On 6/28/2016 8:06 PM, Sean Leonard wrote:
It is considered customary to copy and paste *just* the registration text in this mailing list.
Here you go:

   Type name: application

   Subtype name: yang-data+xml

   Required parameters: none

Usually I see this written "None." Purely editorial preference.


   Optional parameters: none

Ditto.


  // RFC Ed.: replace draft-ietf-netmod-rfc6020bis with
  // the actual RFC reference for YANG 1.1, and remove this note.

   Encoding considerations: 8-bit
      Each conceptual YANG data node is encoded according to
      XML Encoding Rules and Canonical Format for the specific
      YANG data node type defined in [draft-ietf-netmod-rfc6020bis].

"is encoded according to the XML Encoding Rules"...


  // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the
  // section number for Security Considerations
  // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual
  // RFC number, and remove this note.

   Security considerations: Security considerations related
      to the generation and consumption of RESTCONF messages
      are discussed in Section NN of [RFCXXXX].
      Additional security considerations are specific to the
      semantics of particular YANG data models. Each YANG module
      is expected to specify security considerations for the
      YANG data defined in that module.

  // RFC Ed.: replace XXXX with actual RFC number and remove this
  // note.

   Interoperability considerations: [RFCXXXX] specifies format of
      conforming messages and the interpretation thereof.

"[RFCXXXX] specifies the format of"...


  // RFC Ed.: replace XXXX with actual RFC number and remove this
  // note.

   Published specification: RFC XXXX

   Applications that use this media type: Instance document
     data parsers used within a protocol or automation tool
     that utilizes YANG defined data structures.

"Instance document data parsers used within a protocol or automation tool
     that utilize YANG-defined data structures."

Change utilizes -> utilize. It's plural.

I think YANG-defined is correct due to being stacked noun phrases, or something.



   Fragment identifier considerations: The fragment field in the
      request URI has no defined purpose.

From the perspective of NETCONF this is probably correct. However, Section 4.11 of RFC 6838 says:

   Media types are encouraged to adopt fragment identifier schemes that
   are used with semantically similar media types.  In particular, media
   types that use a named structured syntax with a registered "+suffix"
   MUST follow whatever fragment identifier rules are given in the
   structured syntax suffix registration.

There are some things about +xml things:
http://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml

RFC 7303.

Look it up.

I don't have experience dealing with this, and I would not hold back the registration on that basis. The Expert Reviewer might.


   Additional information:

     Deprecated alias names for this type: n/a
     Magic number(s): n/a
     File extension(s): .xml
     Macintosh file type code(s): "TEXT"

  // RFC Ed.: replace XXXX with actual RFC number and remove this
  // note.

   Person & email address to contact for further information: See
      Authors' Addresses section of [RFCXXXX].

   Intended usage: COMMON

   (One of COMMON, LIMITED USE, or OBSOLETE.)

You can remove the parenthetical. It's not part of the template instance.


   Restrictions on usage: n/a

RFC 6838 Section 5.6 says '"N/A", written exactly that way'. Stick with N/A (all-caps).


  // RFC Ed.: replace XXXX with actual RFC number and remove this
  // note.

   Author: See Authors' Addresses section of [RFCXXXX].

   Change controller: Internet Engineering Task Force
      (mailto:iesg&ietf.org).

   Provisional registration? (standards tree only): no

You can also remove the parenthetical. It's not part of the template instance.

Best regards,

Sean


On 6/28/2016 7:24 PM, Andy Bierman wrote:
Hi,

Please review and provide feedback on the revised media type registration
for the RESTCONF protocol.

https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-11.3.1


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


--------------E768ED3CFACB771DBCC98671-- From nobody Tue Jun 28 20:23:19 2016 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 C63CB12D0E6 for ; Tue, 28 Jun 2016 20:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 CcHxO4L79nW6 for ; Tue, 28 Jun 2016 20:23:16 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 6E9E712B00E for ; Tue, 28 Jun 2016 20:23:16 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 477D7509B6; Tue, 28 Jun 2016 23:23:15 -0400 (EDT) To: Andy Bierman , media-types@iana.org References: From: Sean Leonard Message-ID: Date: Tue, 28 Jun 2016 20:22:57 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------19A5463E6705832C91FAC000" Archived-At: Cc: Netconf Subject: Re: [Netconf] request review of media type application/yang-data+json X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 03:23:18 -0000 This is a multi-part message in MIME format. --------------19A5463E6705832C91FAC000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit (Mostly a duplicate of application/yang-data+xml) Based on the discussion on media-types@ and netconf@ that I have observed, the registration is in pretty good substantive shape. I have no substantive comments except for the fragment identifier, which I understand is not of consequence to YANG processors. I won't repeat my comments from application/yang-data+xml. Therefore the only thing to talk about is the JSON fragment thing: On 6/28/2016 8:07 PM, Sean Leonard wrote: > For application/yang-data+json: > > ... > Fragment identifier considerations: The fragment field in the > request URI has no defined purpose. > As with application/yang-data+xml, you are supposed to match the +json fragment with how JSON works. RFC 6839 Section 3.1. But currently it (+json) doesn't do anything, in contrast to +xml, which does some stuff with XPointer. Regards, Sean --------------19A5463E6705832C91FAC000 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
(Mostly a duplicate of application/yang-data+xml)

Based on the discussion on media-types@ and netconf@ that I have observed, the registration is in pretty good substantive shape. I have no substantive comments except for the fragment identifier, which I understand is not of consequence to YANG processors. I won't repeat my comments from application/yang-data+xml. Therefore the only thing to talk about is the JSON fragment thing:

On 6/28/2016 8:07 PM, Sean Leonard wrote:
For application/yang-data+json:

...
   Fragment identifier considerations: The fragment field in the
      request URI has no defined purpose.
  

As with application/yang-data+xml, you are supposed to match the +json fragment with how JSON works. RFC 6839 Section 3.1. But currently it (+json) doesn't do anything, in contrast to +xml, which does some stuff with XPointer.

Regards,

Sean
--------------19A5463E6705832C91FAC000-- From nobody Wed Jun 29 06:14:41 2016 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 D14DE12DE4C for ; Wed, 29 Jun 2016 06:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, 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 6lORajJ037CR for ; Wed, 29 Jun 2016 06:14:35 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6957D12DE1B for ; Wed, 29 Jun 2016 06:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25263; q=dns/txt; s=iport; t=1467206032; x=1468415632; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=vT3swCp3xanVdaYdiK+ipoLZiWoKAnYA1RRJ7ATvcdg=; b=P8c0SdSdsU1Ve2KiRrqnyZsqSqaUX++E9huweHPCid+yvFGAKCH0bHSQ vxyBWW169q+jxiZ+C8DqDoRgt2P19QPTloT2QmuOdp+nHHtrdCdfNYtnx XYKGQCGFn2hmLcX0G7GbbmHrZPomkiajBv2VuZZWi/xRqI063P6EwQfaG c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DVAQAVyXNX/xbLJq1agnCBJCtSuUiBe?= =?us-ascii?q?xcBCoUsSgKBaRQBAQEBAQEBZSeETQEBBAEBAWQHGws4DicwBg0GAgEBiCwOw0U?= =?us-ascii?q?BAQEBBgEBAQEBAQEghiiBd4JWhCMBAQWFcQEEjXyLCYYIiDaBaU6EBoMLhV2GV?= =?us-ascii?q?IkvHjaDcjoyAYgIgTUBAQE?= X-IronPort-AV: E=Sophos;i="5.26,546,1459814400"; d="scan'208,217";a="677986573" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2016 13:13:48 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u5TDDmql012136 for ; Wed, 29 Jun 2016 13:13:48 GMT To: NETCONF References: <5612db74-b32b-164d-c71c-daf669e6b142@cisco.com> <2cb94ab9-9c1d-77ae-eb8b-2d41ba39f495@cisco.com> From: Benoit Claise Message-ID: <4e94400e-62fa-c472-9ea1-c606fcbde026@cisco.com> Date: Wed, 29 Jun 2016 15:13:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <2cb94ab9-9c1d-77ae-eb8b-2d41ba39f495@cisco.com> Content-Type: multipart/alternative; boundary="------------D22E8648B5E7152564A8C0A0" Archived-At: Subject: Re: [Netconf] AD review of draft-ietf-netconf-restconf-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 13:14:39 -0000 This is a multi-part message in MIME format. --------------D22E8648B5E7152564A8C0A0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear authors, Thanks for this new draft. I removed the points that are integrated. Note: I wished that the authors had replied with the points (not) addressed, instead of me spending a couple of hours reviewing all comments and diffs. First of, there is an issue with the YANG module extraction xym.py draft-ietf-netconf-restconf-14.txt ERROR: 'draft-ietf-netconf-restconf-14.txt', Line 3930 - 'module' statement within another module Created the following models:: example-ops.yang example-actions.yang example-jukebox.yang example-mod.yang Not an issue with the draft, but with the xym.py that can't deal with a module example in a description: container operations { description "Container for all operation resources (application/yang-operation), Each resource is represented as an empty leaf with the name of the RPC operation from the YANG rpc statement. For example, the 'system-restart' RPC operation defined in the 'ietf-system' module would be represented as an empty leaf in the 'ietf-system' namespace. This is a conceptual leaf, and will not actually be found in the module: module ietf-system { <===== leaf system-reset { type empty; } } Bug filed for xym.py Testing https://github.com/donaldh/yang-extractor (which I learned of today), it works fine on this draft. Currently testing the other drafts. See in-line. > Dear all, > > Here is my draft-ietf-netconf-restconf-13 AD review > [sorry for the delay, it took longer than expected]. > If some of the points have already been discussed, let me know. > > -https://github.com/netconf-wg/restconf/issues?q=is%3Aopen+is%3Aissue > There are still open issues. I would have expected that all issues are closed. Should I be worried? > - From the charter: > The RESTCONF work will consider requirements suggested by the other working groups > (for example I2RS). > > Are we good in terms of I2RS requirements for RESTCONF, if any? I need to follow up with the I2RS chairs and AD on this one. > > - section 1 > RESTCONF is based on HTTP1.1 [RFC7230] > What about HTTP2 [RFC7540]? > I've seen some discussions on the NETCONF mailing but I'm unclear if RESTCONF would work with HTTP2. > A few words are necessary IMO. > background:https://www.ietf.org/mail-archive/web/netconf/current/msg08578.html > I see in section 2.1 > No other versions of HTTP are supported for use with RESTCONF. > Do you mean: > No other versions than HTTP 1.1 are supported for use with RESTCONF. > So: > HTTP2.0 MUST NOT be used with RESTCONF. > If this is the case, some sort of justification is required. > You have to say something about HTTP2 > > - section 1.1.3 > non-presence container (or NP-container) > presence container (or P-container) > > As Lionel Morand mentioned in his OPS-DIR draft-ietf-netmod-rfc6020bis-11 review: > > LM: "non-presence container" is not defined anywhere in the document. > I can assume that it refers to a container that does not have a > "presence" statement. If it is, it could be good to: > define the term in the section 3 and to extend the existing text in > the section 7.5.5 > The idea is to refer to the definitions in RFC6020bis, now that they have been introduced: container: An interior data node that exists in at most one instance in the data tree. A container has no value, but rather a set of child nodes. o non-presence container: A container that has no meaning of its own, existing only to contain child nodes. o presence container: A container where the presence of the container itself carries some meaning. own, existing only to contain child nodes. > > - "Last-Modified" > This is one of those topics whose requirements are all over the place. This is confusing (at least to me) > > Section 3.4.1.1 > The last change time is maintained and the "Last-Modified" > ([RFC7232], Section 2.2 ) header is returned in the response for a > retrieval request. The "If-Unmodified-Since" header can be used in > edit operation requests to cause the server to reject the request if > the resource has been modified since the specified timestamp. > > Section 3.5 > For configuration data resources, the server MAY maintain a last- > modified timestamp for the resource, and return the "Last-Modified" > header when it is retrieved with the GET or HEAD methods. > > Section 9.1 > The server MUST maintain a last-modified timestamp for this > container, and return the "Last-Modified" header when this data node > is retrieved with the GET or HEAD methods. > > Section 10.1 > The server MUST maintain a last-modified timestamp for this > container, and return the "Last-Modified" header when this data node > is retrieved with the GET or HEAD methods. > > Section 10.1.1 > The server SHOULD maintain a last-modified timestamp for each > instance of this list entry, and return the "Last-Modified" header > when this data node is retrieved with the GET or HEAD methods. > > and potentially some more sections > At the minimum, we should have forward references from section 3.4.1.1 as it looks like self-contained. This one has been addressed? > > > Same remark for entity-tag and section 3.4.1.2 And this one? > > - Section 3.6 > OLD: > If the "rpc" or "action" statement has an "input" section, then a > message-body MAY be sent by the client in the request, otherwise the > request message MUST NOT include a message-body. If the "input" > objcet tree contains mandatory parameters, then a message-body MUST > be sent by the client. > > NEW: > > If the "rpc" or "action" statement has an "input" section and the > "input" object tree contains mandatory parameters, then a message-body > MUST be sent by the client in the request. > > If the "rpc" or "action" statement has an "input" section and the > "input" object tree doesn't contain mandatory parameters, then a message-body > MAY be sent by the client in the request. > > If the "rpc" or "action" statement has no "input" section, the > request message MUST NOT include a message-body. If the "rpc" or "action" statement has an "output" section then instances of these_input _parameters are encoded in the module namespace where the "rpc" or "action" statement is defined, in an XML element or JSON object named "output". Input or output? > > - RFC5277 is a normative reference. > I guess that pub/sub will obsolete RFC5277. > So we would have to update this RESTCONF RFC-to-be with the pub/sub publication? And the answer is? > > > > - 5.3.2 Json MetaData Encoding Example > Note thatRFC 6243 defines the "default" attribute with XSD, not > YANG, so_the YANG module name has to be assigned manually_. The value > "ietf-netconf-with-defaults" is assigned for JSON meta-data encoding. > > I don't understand "_the YANG module name has to be assigned manually_" And I still don't understand. Care to reply? > > > - > Since we have many examples around around example-jukebox, this should pass compilation, right? > > pyang --ietf example-jukebox.yang > example-jukebox.yang:1: error: expected keyword "namespace" as child to "module" > example-jukebox.yang:1: error: expected keyword "prefix" as child to "module" > example-jukebox.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-" > example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "contact" substatement > example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "organization" substatement > example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "description" substatement > example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "revision" substatement > > What was the agreed convention for example modules that should pass compilation? care to reply? > > - Security Considerations. > Please includehttps://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines > > > > > Regards, Benoit (OPS AD) > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------D22E8648B5E7152564A8C0A0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Dear authors,

Thanks for this new draft. I removed the points that are integrated.
Note: I wished that the authors had replied with the points (not) addressed, instead of me spending a couple of hours reviewing all comments and diffs.

First of, there is an issue with the YANG module extraction
xym.py draft-ietf-netconf-restconf-14.txt
ERROR: 'draft-ietf-netconf-restconf-14.txt', Line 3930 - 'module' statement within another module
Created the following models::
   example-ops.yang
   example-actions.yang
   example-jukebox.yang
   example-mod.yang
Not an issue with the draft, but with the xym.py that can't deal with a module example in a description:
container operations {
           description
             "Container for all operation resources
              (application/yang-operation),

              Each resource is represented as an empty leaf with the
              name of the RPC operation from the YANG rpc statement.
              For example, the 'system-restart' RPC operation defined
              in the 'ietf-system' module would be represented as
              an empty leaf in the 'ietf-system' namespace. This is
              a conceptual leaf, and will not actually be found in
              the module:

                 module ietf-system {                        <=====
                   leaf system-reset {
                     type empty;
                   }
                 }
 
Bug filed for xym.py
Testing https://github.com/donaldh/yang-extractor (which I learned of today), it works fine on this draft.
Currently testing the other drafts.

See in-line.
Dear all,

Here is my draft-ietf-netconf-restconf-13 AD review
[sorry for the delay, it took longer than expected].
If some of the points have already been discussed, let me know.

- https://github.com/netconf-wg/restconf/issues?q=is%3Aopen+is%3Aissue
There are still open issues. I would have expected that all issues are closed. Should I be worried?    
- From the charter:
   The RESTCONF work will consider requirements suggested by the other working groups 
   (for example I2RS).

Are we good in terms of I2RS requirements for RESTCONF, if any?
I need to follow up with the I2RS chairs and AD on this one.

- section 1
RESTCONF is based on HTTP1.1 [RFC7230]
What about HTTP2 [RFC7540]? 
I've seen some discussions on the NETCONF mailing but I'm unclear if RESTCONF would work with HTTP2.
A few words are necessary IMO.
background: https://www.ietf.org/mail-archive/web/netconf/current/msg08578.html
I see in section 2.1
   No other versions of HTTP are supported for use with RESTCONF.
Do you mean:
   No other versions than HTTP 1.1 are supported for use with RESTCONF.
So:
   HTTP2.0 MUST NOT be used with RESTCONF.
If this is the case, some sort of justification is required.
You have to say something about HTTP2

- section 1.1.3
non-presence container (or NP-container)
presence container (or P-container)

As Lionel Morand mentioned in his OPS-DIR draft-ietf-netmod-rfc6020bis-11 review:

LM: "non-presence container" is not defined anywhere in the document.
    I can assume that it refers to a container that does not have a 
    "presence" statement. If it is, it could be good to:
    define the term in the section 3 and to extend the existing text in 
    the section 7.5.5
The idea is to refer to the definitions in RFC6020bis, now that they have been introduced:
container: An interior data node that exists in at most one
      instance in the data tree.  A container has no value, but rather a
      set of child nodes.

   o  non-presence container: A container that has no meaning of its
      own, existing only to contain child nodes.

   o  presence container: A container where the presence of the
      container itself carries some meaning.

      own, existing only to contain child nodes.



- "Last-Modified"
This is one of those topics whose requirements are all over the place. This is confusing (at least to me)

Section 3.4.1.1 
   The last change time is maintained and the "Last-Modified"
   ([RFC7232], Section 2.2) header is returned in the response for a
   retrieval request.  The "If-Unmodified-Since" header can be used in
   edit operation requests to cause the server to reject the request if
   the resource has been modified since the specified timestamp.

Section 3.5
   For configuration data resources, the server MAY maintain a last-
   modified timestamp for the resource, and return the "Last-Modified"
   header when it is retrieved with the GET or HEAD methods.

Section 9.1
   The server MUST maintain a last-modified timestamp for this
   container, and return the "Last-Modified" header when this data node
   is retrieved with the GET or HEAD methods.

Section 10.1
   The server MUST maintain a last-modified timestamp for this
   container, and return the "Last-Modified" header when this data node
   is retrieved with the GET or HEAD methods.

Section 10.1.1
   The server SHOULD maintain a last-modified timestamp for each
   instance of this list entry, and return the "Last-Modified" header
   when this data node is retrieved with the GET or HEAD methods.

and potentially some more sections
At the minimum, we should have forward references from section 3.4.1.1 as it looks like self-contained.
This one has been addressed?


Same remark for entity-tag and section 3.4.1.2
And this one?

- Section 3.6
OLD:
   If the "rpc" or "action" statement has an "input" section, then a
   message-body MAY be sent by the client in the request, otherwise the
   request message MUST NOT include a message-body.  If the "input"
   objcet tree contains mandatory parameters, then a message-body MUST
   be sent by the client. 

NEW:

   If the "rpc" or "action" statement has an "input" section and the 
   "input" object tree contains mandatory parameters, then a message-body 
   MUST be sent by the client in the request. 

   If the "rpc" or "action" statement has an "input" section and the 
   "input" object tree doesn't contain mandatory parameters, then a message-body 
   MAY be sent by the client in the request. 
   
   If the "rpc" or "action" statement has no "input" section, the
   request message MUST NOT include a message-body.  

   If the "rpc" or "action" statement has an "output" section then
   instances of these input parameters are encoded in the module
   namespace where the "rpc" or "action" statement is defined, in an XML
   element or JSON object named "output".

Input or output?


- RFC5277 is a normative reference. 
I guess that pub/sub will obsolete RFC5277.
So we would have to update this RESTCONF RFC-to-be with the pub/sub publication?
And the answer is? 




 - 5.3.2 Json MetaData Encoding Example
   Note that RFC 6243 defines the "default" attribute with XSD, not
   YANG, so the YANG module name has to be assigned manually.  The value
   "ietf-netconf-with-defaults" is assigned for JSON meta-data encoding.

I don't understand "the YANG module name has to be assigned manually"
And I still don't understand. Care to reply? 
  

- 
Since we have many examples around around example-jukebox, this should pass compilation, right? 

pyang --ietf example-jukebox.yang 
example-jukebox.yang:1: error: expected keyword "namespace" as child to "module"
example-jukebox.yang:1: error: expected keyword "prefix" as child to "module"
example-jukebox.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-"
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "contact" substatement
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "organization" substatement
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "description" substatement
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "revision" substatement

What was the agreed convention for example modules that should pass compilation?
care to reply? 

- Security Considerations.
Please include https://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines




Regards, Benoit (OPS AD)

      


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

--------------D22E8648B5E7152564A8C0A0-- From nobody Wed Jun 29 06:39:19 2016 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 D7D1912DE67 for ; Wed, 29 Jun 2016 06:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 sLUn6HNa3AKA for ; Wed, 29 Jun 2016 06:39:12 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48C4612DE57 for ; Wed, 29 Jun 2016 06:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27816; q=dns/txt; s=iport; t=1467207534; x=1468417134; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=t12dskCjAHWAly45i85DfklofcAr9Rs1k3c/HMf2VEE=; b=INFoJAOG+79OUY5jTkXMOoommY1CF5kWi9ZjOo5Xn/R0zrGT8nmxwP11 R/V3FajCd6KpnxG/yMMIk6rpXWEf0LpmJG3uVfohUkmkK/Lv+fUgg9G/S rfKd+g9oQcTWwRJgtzRO2avlxD45wJBZdbhplJ5Bjv8192reZ14XFae1a 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C9BACaznNX/xbLJq1agnCBJCtSu0QXA?= =?us-ascii?q?QqFLEoCgX0BAQEBAQFmJ4RNAQEDAQEBAWQHGws4DicwBg0GAgEBiCQIDsNAAQE?= =?us-ascii?q?BAQYBAQEBAQEBIIYogXeCVoQjAQEFhXEBBI18iwmGCIg2gWlOhAaDC4VdhlSJL?= =?us-ascii?q?1SDcjoyAYgIgTUBAQE?= X-IronPort-AV: E=Sophos;i="5.26,546,1459814400"; d="scan'208,217";a="638275764" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2016 13:38:50 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u5TDcne6014696 for ; Wed, 29 Jun 2016 13:38:50 GMT To: NETCONF References: <5612db74-b32b-164d-c71c-daf669e6b142@cisco.com> <2cb94ab9-9c1d-77ae-eb8b-2d41ba39f495@cisco.com> <4e94400e-62fa-c472-9ea1-c606fcbde026@cisco.com> From: Benoit Claise Message-ID: <991800b7-d50e-7c22-af96-96bfe6742240@cisco.com> Date: Wed, 29 Jun 2016 15:38:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <4e94400e-62fa-c472-9ea1-c606fcbde026@cisco.com> Content-Type: multipart/alternative; boundary="------------C2D63109379FFDBBC0D28BAC" Archived-At: Subject: Re: [Netconf] AD review of draft-ietf-netconf-restconf-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 13:39:16 -0000 This is a multi-part message in MIME format. --------------C2D63109379FFDBBC0D28BAC Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Btw, list access { key encoding; min-elements 1; description "The server will create an entry in this list for each encoding format that is supported for this stream. The media type 'application/yang-stream' is expected for all event streams. This list identifies the sub-types supported for this stream."; Should this media type be registered? Regards, B. > Dear authors, > > Thanks for this new draft. I removed the points that are integrated. > Note: I wished that the authors had replied with the points (not) > addressed, instead of me spending a couple of hours reviewing all > comments and diffs. > > First of, there is an issue with the YANG module extraction > > xym.py draft-ietf-netconf-restconf-14.txt > ERROR: 'draft-ietf-netconf-restconf-14.txt', Line 3930 - 'module' > statement within another module > Created the following models:: > example-ops.yang > example-actions.yang > example-jukebox.yang > example-mod.yang > > Not an issue with the draft, but with the xym.py that can't deal with > a module example in a description: > > container operations { > description > "Container for all operation resources > (application/yang-operation), > > Each resource is represented as an empty leaf with the > name of the RPC operation from the YANG rpc statement. > For example, the 'system-restart' RPC operation defined > in the 'ietf-system' module would be represented as > an empty leaf in the 'ietf-system' namespace. This is > a conceptual leaf, and will not actually be found in > the module: > > module ietf-system { <===== > leaf system-reset { > type empty; > } > } > > Bug filed for xym.py > Testing https://github.com/donaldh/yang-extractor (which I learned of > today), it works fine on this draft. > Currently testing the other drafts. > > See in-line. >> Dear all, >> >> Here is my draft-ietf-netconf-restconf-13 AD review >> [sorry for the delay, it took longer than expected]. >> If some of the points have already been discussed, let me know. >> >> -https://github.com/netconf-wg/restconf/issues?q=is%3Aopen+is%3Aissue >> There are still open issues. I would have expected that all issues are closed. Should I be worried? >> - From the charter: >> The RESTCONF work will consider requirements suggested by the other working groups >> (for example I2RS). >> >> Are we good in terms of I2RS requirements for RESTCONF, if any? > I need to follow up with the I2RS chairs and AD on this one. >> - section 1 >> RESTCONF is based on HTTP1.1 [RFC7230] >> What about HTTP2 [RFC7540]? >> I've seen some discussions on the NETCONF mailing but I'm unclear if RESTCONF would work with HTTP2. >> A few words are necessary IMO. >> background:https://www.ietf.org/mail-archive/web/netconf/current/msg08578.html >> I see in section 2.1 >> No other versions of HTTP are supported for use with RESTCONF. >> Do you mean: >> No other versions than HTTP 1.1 are supported for use with RESTCONF. >> So: >> HTTP2.0 MUST NOT be used with RESTCONF. >> If this is the case, some sort of justification is required. >> > You have to say something about HTTP2 >> - section 1.1.3 >> non-presence container (or NP-container) >> presence container (or P-container) >> >> As Lionel Morand mentioned in his OPS-DIR draft-ietf-netmod-rfc6020bis-11 review: >> >> LM: "non-presence container" is not defined anywhere in the document. >> I can assume that it refers to a container that does not have a >> "presence" statement. If it is, it could be good to: >> define the term in the section 3 and to extend the existing text in >> the section 7.5.5 >> > The idea is to refer to the definitions in RFC6020bis, now that they > have been introduced: > container: An interior data node that exists in at most one > instance in the data tree. A container has no value, but rather a > set of child nodes. > > o non-presence container: A container that has no meaning of its > own, existing only to contain child nodes. > > o presence container: A container where the presence of the > container itself carries some meaning. > > own, existing only to contain child nodes. > >> >> - "Last-Modified" >> This is one of those topics whose requirements are all over the place. This is confusing (at least to me) >> >> Section 3.4.1.1 >> The last change time is maintained and the "Last-Modified" >> ([RFC7232], Section 2.2 ) header is returned in the response for a >> retrieval request. The "If-Unmodified-Since" header can be used in >> edit operation requests to cause the server to reject the request if >> the resource has been modified since the specified timestamp. >> >> Section 3.5 >> For configuration data resources, the server MAY maintain a last- >> modified timestamp for the resource, and return the "Last-Modified" >> header when it is retrieved with the GET or HEAD methods. >> >> Section 9.1 >> The server MUST maintain a last-modified timestamp for this >> container, and return the "Last-Modified" header when this data node >> is retrieved with the GET or HEAD methods. >> >> Section 10.1 >> The server MUST maintain a last-modified timestamp for this >> container, and return the "Last-Modified" header when this data node >> is retrieved with the GET or HEAD methods. >> >> Section 10.1.1 >> The server SHOULD maintain a last-modified timestamp for each >> instance of this list entry, and return the "Last-Modified" header >> when this data node is retrieved with the GET or HEAD methods. >> >> and potentially some more sections >> At the minimum, we should have forward references from section 3.4.1.1 as it looks like self-contained. > This one has been addressed? >> >> Same remark for entity-tag and section 3.4.1.2 > And this one? >> - Section 3.6 >> OLD: >> If the "rpc" or "action" statement has an "input" section, then a >> message-body MAY be sent by the client in the request, otherwise the >> request message MUST NOT include a message-body. If the "input" >> objcet tree contains mandatory parameters, then a message-body MUST >> be sent by the client. >> >> NEW: >> >> If the "rpc" or "action" statement has an "input" section and the >> "input" object tree contains mandatory parameters, then a message-body >> MUST be sent by the client in the request. >> >> If the "rpc" or "action" statement has an "input" section and the >> "input" object tree doesn't contain mandatory parameters, then a message-body >> MAY be sent by the client in the request. >> >> If the "rpc" or "action" statement has no "input" section, the >> request message MUST NOT include a message-body. > > If the "rpc" or "action" statement has an "output" section then > instances of these_input _parameters are encoded in the module > namespace where the "rpc" or "action" statement is defined, in an XML > element or JSON object named "output". > > Input or output? >> - RFC5277 is a normative reference. >> I guess that pub/sub will obsolete RFC5277. >> So we would have to update this RESTCONF RFC-to-be with the pub/sub publication? > And the answer is? >> >> - 5.3.2 Json MetaData Encoding Example >> Note thatRFC 6243 defines the "default" attribute with XSD, not >> YANG, so_the YANG module name has to be assigned manually_. The value >> "ietf-netconf-with-defaults" is assigned for JSON meta-data encoding. >> >> I don't understand "_the YANG module name has to be assigned manually_" > And I still don't understand. Care to reply? >> >> >> - >> Since we have many examples around around example-jukebox, this should pass compilation, right? >> >> pyang --ietf example-jukebox.yang >> example-jukebox.yang:1: error: expected keyword "namespace" as child to "module" >> example-jukebox.yang:1: error: expected keyword "prefix" as child to "module" >> example-jukebox.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-" >> example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "contact" substatement >> example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "organization" substatement >> example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "description" substatement >> example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "revision" substatement >> >> What was the agreed convention for example modules that should pass compilation? > care to reply? >> - Security Considerations. >> Please includehttps://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines >> >> >> >> >> Regards, Benoit (OPS AD) >> >> >> >> >> _______________________________________________ >> 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 --------------C2D63109379FFDBBC0D28BAC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Btw,

list access {
             key encoding;
             min-elements 1;
             description
               "The server will create an entry in this list for each
                encoding format that is supported for this stream.
                The media type 'application/yang-stream' is expected
                for all event streams. This list identifies the
                sub-types supported for this stream.";
Should this media type be registered?

Regards, B.
Dear authors,

Thanks for this new draft. I removed the points that are integrated.
Note: I wished that the authors had replied with the points (not) addressed, instead of me spending a couple of hours reviewing all comments and diffs.

First of, there is an issue with the YANG module extraction
xym.py draft-ietf-netconf-restconf-14.txt
ERROR: 'draft-ietf-netconf-restconf-14.txt', Line 3930 - 'module' statement within another module
Created the following models::
   example-ops.yang
   example-actions.yang
   example-jukebox.yang
   example-mod.yang
Not an issue with the draft, but with the xym.py that can't deal with a module example in a description:
container operations {
           description
             "Container for all operation resources
              (application/yang-operation),

              Each resource is represented as an empty leaf with the
              name of the RPC operation from the YANG rpc statement.
              For example, the 'system-restart' RPC operation defined
              in the 'ietf-system' module would be represented as
              an empty leaf in the 'ietf-system' namespace. This is
              a conceptual leaf, and will not actually be found in
              the module:

                 module ietf-system {                        <=====
                   leaf system-reset {
                     type empty;
                   }
                 }
 
Bug filed for xym.py
Testing https://github.com/donaldh/yang-extractor (which I learned of today), it works fine on this draft.
Currently testing the other drafts.

See in-line.
Dear all,

Here is my draft-ietf-netconf-restconf-13 AD review
[sorry for the delay, it took longer than expected].
If some of the points have already been discussed, let me know.

- https://github.com/netconf-wg/restconf/issues?q=is%3Aopen+is%3Aissue
There are still open issues. I would have expected that all issues are closed. Should I be worried?    
- From the charter:
   The RESTCONF work will consider requirements suggested by the other working groups 
   (for example I2RS).

Are we good in terms of I2RS requirements for RESTCONF, if any?
I need to follow up with the I2RS chairs and AD on this one.
- section 1
RESTCONF is based on HTTP1.1 [RFC7230]
What about HTTP2 [RFC7540]? 
I've seen some discussions on the NETCONF mailing but I'm unclear if RESTCONF would work with HTTP2.
A few words are necessary IMO.
background: https://www.ietf.org/mail-archive/web/netconf/current/msg08578.html
I see in section 2.1
   No other versions of HTTP are supported for use with RESTCONF.
Do you mean:
   No other versions than HTTP 1.1 are supported for use with RESTCONF.
So:
   HTTP2.0 MUST NOT be used with RESTCONF.
If this is the case, some sort of justification is required.
You have to say something about HTTP2
- section 1.1.3
non-presence container (or NP-container)
presence container (or P-container)

As Lionel Morand mentioned in his OPS-DIR draft-ietf-netmod-rfc6020bis-11 review:

LM: "non-presence container" is not defined anywhere in the document.
    I can assume that it refers to a container that does not have a 
    "presence" statement. If it is, it could be good to:
    define the term in the section 3 and to extend the existing text in 
    the section 7.5.5
The idea is to refer to the definitions in RFC6020bis, now that they have been introduced:
container: An interior data node that exists in at most one
      instance in the data tree.  A container has no value, but rather a
      set of child nodes.

   o  non-presence container: A container that has no meaning of its
      own, existing only to contain child nodes.

   o  presence container: A container where the presence of the
      container itself carries some meaning.

      own, existing only to contain child nodes.



- "Last-Modified"
This is one of those topics whose requirements are all over the place. This is confusing (at least to me)

Section 3.4.1.1 
   The last change time is maintained and the "Last-Modified"
   ([RFC7232], Section 2.2) header is returned in the response for a
   retrieval request.  The "If-Unmodified-Since" header can be used in
   edit operation requests to cause the server to reject the request if
   the resource has been modified since the specified timestamp.

Section 3.5
   For configuration data resources, the server MAY maintain a last-
   modified timestamp for the resource, and return the "Last-Modified"
   header when it is retrieved with the GET or HEAD methods.

Section 9.1
   The server MUST maintain a last-modified timestamp for this
   container, and return the "Last-Modified" header when this data node
   is retrieved with the GET or HEAD methods.

Section 10.1
   The server MUST maintain a last-modified timestamp for this
   container, and return the "Last-Modified" header when this data node
   is retrieved with the GET or HEAD methods.

Section 10.1.1
   The server SHOULD maintain a last-modified timestamp for each
   instance of this list entry, and return the "Last-Modified" header
   when this data node is retrieved with the GET or HEAD methods.

and potentially some more sections
At the minimum, we should have forward references from section 3.4.1.1 as it looks like self-contained.
This one has been addressed?

Same remark for entity-tag and section 3.4.1.2
And this one?
- Section 3.6
OLD:
   If the "rpc" or "action" statement has an "input" section, then a
   message-body MAY be sent by the client in the request, otherwise the
   request message MUST NOT include a message-body.  If the "input"
   objcet tree contains mandatory parameters, then a message-body MUST
   be sent by the client. 

NEW:

   If the "rpc" or "action" statement has an "input" section and the 
   "input" object tree contains mandatory parameters, then a message-body 
   MUST be sent by the client in the request. 

   If the "rpc" or "action" statement has an "input" section and the 
   "input" object tree doesn't contain mandatory parameters, then a message-body 
   MAY be sent by the client in the request. 
   
   If the "rpc" or "action" statement has no "input" section, the
   request message MUST NOT include a message-body.  

   If the "rpc" or "action" statement has an "output" section then
   instances of these input parameters are encoded in the module
   namespace where the "rpc" or "action" statement is defined, in an XML
   element or JSON object named "output".

Input or output?

- RFC5277 is a normative reference. 
I guess that pub/sub will obsolete RFC5277.
So we would have to update this RESTCONF RFC-to-be with the pub/sub publication?
And the answer is? 

                

              

            

          

        

      

      

        

          

            

              

                

                  

 - 5.3.2 Json MetaData Encoding Example

                  
   Note that RFC 6243 defines the "default" attribute with XSD, not
   YANG, so the YANG module name has to be assigned manually.  The value
   "ietf-netconf-with-defaults" is assigned for JSON meta-data encoding.

I don't understand "the YANG module name has to be assigned manually"

                

              

            

          

        

      

      And I still don't understand. Care to reply?
      

        

          

            

              

                

                  
  

- 
Since we have many examples around around example-jukebox, this should pass compilation, right? 

pyang --ietf example-jukebox.yang 
example-jukebox.yang:1: error: expected keyword "namespace" as child to "module"
example-jukebox.yang:1: error: expected keyword "prefix" as child to "module"
example-jukebox.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-"
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "contact" substatement
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "organization" substatement
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "description" substatement
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "revision" substatement

What was the agreed convention for example modules that should pass compilation?

                

              

            

          

        

      

      care to reply?
      

        

          

            

              

                

                  
- Security Considerations.
Please include https://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines




Regards, Benoit (OPS AD)

      

                

              

            

          

        

        

        

        

        
_______________________________________________
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


    

    

  


--------------C2D63109379FFDBBC0D28BAC--


From nobody Wed Jun 29 09:45:45 2016
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 F2FD512D128 for ; Wed, 29 Jun 2016 09:45:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 gq5sQ5lBQZd5 for ; Wed, 29 Jun 2016 09:45:41 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0753.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:753]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32E5D12D08C for ; Wed, 29 Jun 2016 09:45:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nVkoTN0rcZB4wL5Pg/PWMK56b9q+sVRROtKR21SauR0=; b=Y2xXCRX+2GfLWmcJ28xTKoewL07LmC5XsWY9tI9ALjqR0Q/0TW3kJqMuUZJgyqpNGgDeT1QXz3QR8jwx0YzBSP+RwG9n2ZZAMXfg/1RSVfnqYflcakGnNS/qi8JBiUxnUMMThVeUiHVnp/3PCuB4mSl5X34ZvqAs5rW1lCOrMk4=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) with Microsoft SMTP Server (TLS) id 15.1.528.16; Wed, 29 Jun 2016 16:45:20 +0000
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0528.017; Wed, 29 Jun 2016 16:45:20 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder 
Thread-Topic: [Netconf] zerotouch/14: Removable storage details?
Thread-Index: AQHRq96aoeOBJizsz0Suy3PZsyqGQJ+0zf+AgEvicgA=
Date: Wed, 29 Jun 2016 16:45:19 +0000
Message-ID: 
References: <633A61C1-905D-4C4E-98D6-4C864FD752A7@juniper.net> <20160512055519.GA54966@elstar.local>
In-Reply-To: <20160512055519.GA54966@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.17.0.160611
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.13]
x-ms-office365-filtering-correlation-id: 918fa584-07b0-4271-c46d-08d3a03cc1e4
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1450; 6:gX3quBXCd6IAnT5ZxTqcWF1mpnoOR7DLQl0/fXaE7WsEsS9mvY0BaDtqkolD+ojzkvsOXTlYp+DphbyqYm5EWFQZgm67o1ybOCwR8yXj6li49j5CZohjRa7liBrPgsV8C/YkU2F/vwWQ4uQtswhkPLLrA5TAUt7y9ZYeHivLNcqJkbBEcP7N14JZWvlV3DI8Pg38yNRuyRT/DEXlIoqHxJHW1cW3cl9aXx8/kmknqtJ02kPgH/npaJTq8W+Pgzm/40WHbJB3cwTcnjEPVnJIMHG46lwbJtAVJKtL9pIvm4zYJur9I4k27O/lPUyBVB5so3KeAZsU4qVijr6TvxlF1Q==; 5:+259ZtjOjAHHrnMe/HBDEYX+f+zkJNvuJcLQYh3ZdFwrDL9ZXE0XfJhNHZN9gm3cfyu+CzUKPrcBhyHmElhHNg+cwTHgX3YNT53M+/qasMw2bwBHDIlkfJ0AoxPWCXYLIUy0G2ceHRbV/aOfQPiONw==; 24:QHGJKhVUbH/UFR2HT+wylxN1gTkKsf7E+O6aNdZO768y1s/8puUjtiDUganu+76Kxuhdh01F4Y8H3bzdKSr053er/QCGhL4GbkhuCA12H3w=; 7:trKKAvPlyKuJojydt5Gm5zWlMiVERm9Pp0TbszNfTCysv8kee8cnp+y/AaagPaud7VplKspAy8I4SSL+SjB9wJ4AMmclqJ/YB2P+EZmQwm342XtspwZSuDf4qQyw9r51xjH6vsBfpPibL4/nl8rI5zdIN3Jf63gLk+EPjL/Sjo9Ffq1onsR/LTRYLr64K3gricddPUkKCNO7TKuy4gaIYiUBBuirNODlsZ7JMtwnVA2pOpadpHkAVQ5cGAy/wCS8
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1450;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(166708455590820);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026);  SRVR:CY1PR0501MB1450; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1450; 
x-forefront-prvs: 09888BC01D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(24454002)(199003)(51444003)(97736004)(106356001)(99286002)(77096005)(101416001)(105586002)(82746002)(83716003)(110136002)(3280700002)(4001350100001)(50986999)(33656002)(83506001)(54356999)(36756003)(19580405001)(86362001)(19580395003)(76176999)(189998001)(5002640100001)(586003)(106116001)(102836003)(11100500001)(122556002)(8936002)(4326007)(81156014)(3660700001)(7846002)(6116002)(10400500002)(305945005)(81166006)(2906002)(68736007)(7736002)(66066001)(92566002)(2900100001)(8676002)(15975445007)(87936001)(2950100001)(3846002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1450; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2016 16:45:19.9207 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1450
Archived-At: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] zerotouch/14: Removable storage details?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2016 16:45:44 -0000

DQpQaWNraW5nIHVwIG9uIHRoaXMgdGhyZWFkLCBwZXIgSnVlcmdlbuKAmXMgcmVjb21tZW5kYXRp
b24sIEkgYWRkZWQgYSByZWNvbW1lbmRhdGlvbjoNCg0KT0xEOg0KICAgTm90ZTogZGV0YWlscyBz
dWNoIGFzIHRoZSBmb3JtYXQgb2YgdGhlIGZpbGVzeXN0ZW0gYW5kIHRoZSBuYW1pbmcgb2YNCiAg
IHRoZSBmaWxlcyBhcmUgbGVmdCB0byB0aGUgZGV2aWNlJ3MgbWFudWZhY3R1cmVyIHRvIGRlZmlu
ZS4NCg0KTkVXOg0KICAgTm90ZTogZGV0YWlscyBzdWNoIGFzIHRoZSBmb3JtYXQgb2YgdGhlIGZp
bGVzeXN0ZW0gYW5kIHRoZSBuYW1pbmcgb2YNCiAgIHRoZSBmaWxlcyBhcmUgbGVmdCB0byB0aGUg
ZGV2aWNlJ3MgbWFudWZhY3R1cmVyIHRvIGRlZmluZS4gIEhvd2V2ZXIsDQogICBpbiBvcmRlciB0
byBmYWNpbGl0YXRlIGludGVyb3BlcmFiaWxpdHksIGl0IGlzIFJFQ09NTUVOREVEIHRvIHN1cHBv
cnQNCiAgIG9wZW4vc3RhbmRhcmRzIGJhc2VkIGZpbGVzeXN0ZW1zIGFuZCB0byBoYXZlIGEgZmls
ZSBuYW1pbmcgY29udmVudGlvbg0KICAgdGhhdCBpcyBub3QgbGlrZWx5IHRvIGhhdmUgY29sbGlz
aW9ucyB3aXRoIGZpbGVzIGZyb20gb3RoZXIgdmVuZG9ycy4NCg0KVGhvdWdodHM/DQoNCktlbnQN
Cg0KDQoNCk9uIDUvMTIvMTYsIDE6NTUgQU0sICJKdWVyZ2VuIFNjaG9lbndhZWxkZXIiIDxqLnNj
aG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KDQpPbiBXZWQsIE1heSAx
MSwgMjAxNiBhdCAxMTo0MToxM1BNICswMDAwLCBLZW50IFdhdHNlbiB3cm90ZToNCj4gaHR0cHM6
Ly9naXRodWIuY29tL25ldGNvbmYtd2cvemVyby10b3VjaC9pc3N1ZXMvMTQNCj4gDQo+IFRoZSBj
dXJyZW50IGRyYWZ0IHNheXM6ICJEZXRhaWxzIHN1Y2ggYXMgdGhlIGZvcm1hdCBvZiBmaWxlIHN5
c3RlbSBhbmQgdGhlIG5hbWluZyBvZiB0aGUgZmlsZXMgYXJlIGxlZnQgdG8gdGhlIGRldmljZSdz
IG1hbnVmYWN0dXJlciB0byBkZWZpbmUiLCAgYnV0IGFuIG9uLWxpc3QgcmV2aWV3IHJlY29tbWVu
ZHMgdGhhdCB0aGUgZHJhZnQgYmUgbW9yZSBub3JtYXRpdmUgYWJvdXQgdGhpcy4NCj4gDQo+IFRo
ZSBhYm92ZSBpcyBlc3NlbnRpYWxseSBzbGlkZSAjMTIgZnJvbSB0aGUgSUVURiA5NSBwcmVzZW50
YXRpb24uICBUaGUgbWludXRlcyB0aGVuIGNhcHR1cmUgdGhlIGZvbGxvd2luZyBkaWFsb2c6DQo+
IA0KPiAgIC0gSkg6IHN0b3JhZ2UgZm9ybWF0cyBoYXZlIGNoYW5nZWQgaW1tZW5zZWx5IG92ZXIg
dGhlIHllYXJzLiAgRml4aW5nIHRoZW0gaW4gdGhlIG1vZGVsIHdpbGwgbGlrZWx5IGp1c3QgbWFr
ZSB0aGUgbW9kZWwgb2JzZWxldGUgcXVpY2tseSAuIE1heWJlIGEgcmVnaXN0cnkgPw0KPiAgIC0g
S1c6IFdoYXQgd291bGQgYmUgdGhlIG1vdGl2YXRpb24/DQo+ICAgLSBNQ1I6IE5vdCB0aGF0IHdl
IGRlZmluZSB0aGVtLCB3ZSBzaG91bGQganVzdCByZWZlciB0byB0aGVtLg0KPiAgIC0gUlQ6IHdo
YXQgYXJlIHdlIHRyeWluZyB0byBhY2hpZXZlIGhlcmUgPyAgSnVzdCBiYXNpYyBib290aW5nID8g
IG9yIG1vcmUgPw0KPiANCj4gSSB0aGluayB0aGF0IHRoZXJlIHdhcy9pcyBhIGZ1bmRhbWVudGFs
IG1pc3VuZGVyc3RhbmRpbmcuICBXZSdyZSBub3QgaGVyZSBkaXNjdXNzaW5nIHRoZSBmb3JtYXQg
b2YgdGhlIGZpbGVzeXN0ZW0gZm9yIHRoZSBkZXZpY2UgaXRzZWxmLCB0aGF0IGlzIGNvbXBsZXRl
bHkgb3V0IG9mIHNjb3BlLiAgSW5zdGVhZCwgd2UncmUganVzdCBkaXNjdXNzaW5nIHRoZSBmb3Jt
YXQgb2YgdGhlIGZpbGVzeXN0ZW0gZm9yIHRoZSByZW1vdmFibGUgc3RvcmFnZSBkZXZpY2UgKGUu
Zy4sIGEgVVNCIGZsYXNoIGRyaXZlKSwgYW5kL29yIHRoZSBuYW1lcyBvZiB0aGUgZmlsZXMgdGhh
dCB0aGUgZGV2aWNlIG1pZ2h0IGxvb2sgZm9yIG9uIHRoZSBzdG9yYWdlIGRldmljZS4NCj4gDQo+
IE15IHZpZXcgaXMgdGhhdCB3ZSBzaG91bGQgbGV0IGVhY2ggdmVuZG9yIGRlY2lkZSBmb3IgdGhl
bXNlbHZlcy4gIElmIHRoZXkgd2FudCB0byBzdXBwb3J0IGV4dDMsIG1zZG9zLCBudGZzLCBoZmYr
LCBvciB3aGF0ZXZlciAtIGl0J3MgdXAgdG8gdGhlbSB0byBkZWNpZGUuIEZ1cnRoZXIsIHRoZXkg
c2hvdWxkIGJlIGFsbG93ZWQgdG8gZGVmaW5lIHRoZSBmaWxlIG5hbWVzIGFuZCBmb3JtYXRzIGFz
IHdlbGwuICAgTXkgdGhvdWdodCBpdHMgdGhhdCB0aGVyZSBpcyBsaXR0bGUgbmVlZCB0byBwbHVn
IGEgc3BlY2lmaWMgcmVtb3ZhYmxlIHN0b3JhZ2UgZGV2aWNlIGluc3RhbmNlIGludG8gbW9yZSB0
aGFuIG9uZSBkZXZpY2UsIHRodXMgdGhlIG11bHRpLXZlbmRvciBhc3BlY3Qgb2YgdGhpcyBpdCBu
b3QgdmVyeSBzdHJvbmcsIGFuZCBzbyB3ZSBzaG91bGQgZGVjbGFyZSBpdCBhcyBvdXQtb2Ytc2Nv
cGUuDQo+DQoNCkkgdGhpbmsgaXQgaXMgdXNlZnVsIHRvIGhhdmUgYSBmb3JtYXQgdGhhdCBpcyBy
ZWFkYWJsZSBhbmQgd3JpdGFibGUgYnkNCidyZWd1bGFyJyBjb21wdXRlcnM7IGlmIHZlbmRvcnMg
c3RhcnQgdG8gcHJvZHVjZSBzdG9yYWdlIHN0aWNrcyB0aGF0DQpjYW4ndCBiZSByZWFkIG9yIGNv
cGllZCB1c2luZyAncmVndWxhcicgY29tcHV0ZXJzLCBJIHdvdWxkIGJlIHNvbWV3aGF0DQp1bmhh
cHB5LiBUaGF0IHNhaWQsIEkgYW0gbm90IHN1cmUgYSBzdGFuZGFyZCBjYW4gcmVhbGx5IHByZXZl
bnQgdGhpcw0KZnJvbSBoYXBwZW5pbmcgYnV0IGdpdmluZyBzb21lIGFkdmljZSB0aGF0IHVzaW5n
IG9wZW4gZm9ybWF0cyBpcyBhDQpnb29kIHRoaW5nIG1heSBiZSB1c2VmdWwuIChBbiBvcGVuIGZv
cm1hdCBtYXkgYWxsb3cgbWUgdG8gY3JlYXRlDQpjb21iaW5lZCBib290IHN0aWNrcyB0aGF0IGNh
biBib290IG1vcmUgdGhhbiBhIHNpbmdsZSBkZXZpY2UgdHlwZS4pDQoNCi9qcw0KDQotLSANCkp1
ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdH
bWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1
OSBCcmVtZW4gfCBHZXJtYW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRw
Oi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg0KDQo=


From nobody Wed Jun 29 12:26:08 2016
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 9FB6B12D66A for ; Wed, 29 Jun 2016 12:26:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 fP059bD2-8jd for ; Wed, 29 Jun 2016 12:26:05 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0121.outbound.protection.outlook.com [65.55.169.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 A1CC212D643 for ; Wed, 29 Jun 2016 12:26:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Q4LAzY/9hPOmuZWFeh9Q26s65HoELBaulRv6qGrs8NE=; b=cIcHeWPpaErLGcFiYf5uuP0Qk5Snr3AB67ttS9jpDaWddfUd6+W5+1tYTU4FnwkTVrpcCPVb+kN1H+AmirmdeD0oA7ccr4SyP3si1xAzWTjGklhanN0H/7lKe9oKLzT+8JBJV3qqXHop+oRYgKBOXvL1t+XXSpV94TkHrwy6n/g=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1449.namprd05.prod.outlook.com (10.160.148.155) with Microsoft SMTP Server (TLS) id 15.1.528.16; Wed, 29 Jun 2016 19:26:02 +0000
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0528.017; Wed, 29 Jun 2016 19:26:02 +0000
From: Kent Watsen 
To: "jernej.tuljak@mg-soft.si" , Netconf 
Thread-Topic: [Netconf] restconf-11 ordered by user leaf-list entry insertion
Thread-Index: AQHRli9gMU8pfbT2okSY21yKrdHwjqABCLaA
Date: Wed, 29 Jun 2016 19:26:02 +0000
Message-ID: <60E7C658-AAF1-415D-8C61-9E29B7C10EEF@juniper.net>
References: <570F61A3.7010804@mg-soft.si>
In-Reply-To: <570F61A3.7010804@mg-soft.si>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.17.0.160611
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.13]
x-ms-office365-filtering-correlation-id: 33d6008e-bb3d-4b8d-e4b7-08d3a0533536
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1449; 6:WRExC7yFhK9wvQsvVxPRfGsv1F7x51kaPgodyC1H2V820CfJa33XB1U1JGCGcvPZBKZUzADlM3wqgFTFx7XlxiNDRTjF7mlkWNoNPHieDeQdFYy7nP5oEfhBm8W7jBogY6T+pSb0WgEboevX3FWgaTgeFY/i55MShbM9jruQss1qaD2HnNx23DQms6Al0wemm3xNv7YEpX8QGZpRv4jL/oCq5MJ8IcEDVJWmN/KMCIg5qAFq9yEW9xJUJZBYCbavQ3zTsRd8lM58MWPoXX6bpDr5Q1eUwSlGKNNQZNLGZUM7jx28AOVDlX10/AQRALR4ZvCNH6wFCqTeNtNukKQN/g==; 5:poSMncVY5dxfpQCluGjBG3UV2L3uA+kq66UZfpEB9Hsh42oVk8sYNU4ReuD+FkpKq7WYqRrZjSW+2W3rZKMOPdP5tGnAQQZ4d/BIofwEhfw+eYYAuNVSKi4VzT2dqMpglRCBDzrGp8E9H7VaK9J4ag==; 24:2OBwuRN3WB0dBxyBjIHc1rfablMxSTyY5tKOxPCT1E0G93odK3akot6+fjEUPXbBy3swfA+3ikHH7dpcehten1cQb5v6caYjv4xkgUCdIig=; 7:xXYwB27eEQy5sRxwmL1WuB3y6k+JPcPLo46QzB+JLKSqA2AtFy/tIBw4IWxCO7nbbx1fbPtpv2RCpEFXQlrfFhoZ0AhSaalloHtv/4b0mzUka2dOTFqi0RuBiMKsE8QWlCtTXZzdlPU3R2NP9EN1PdsR7uv6+0AhpzNwZI58tBAifdtGZMsscNJHVY8g9auSPLSSlpAgndhikZCrJSZMGOutv5sW+xABaHR5YUDI416QGzomF/UgP5DNsXWQv6u9
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1449;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026);  SRVR:CY1PR0501MB1449; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1449; 
x-forefront-prvs: 09888BC01D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(377454003)(189002)(24454002)(5002640100001)(122556002)(83716003)(305945005)(7846002)(86362001)(19580405001)(8936002)(19580395003)(99286002)(2906002)(50986999)(10400500002)(68736007)(54356999)(7736002)(82746002)(105586002)(97736004)(106356001)(33656002)(66066001)(189998001)(81156014)(106116001)(2900100001)(3280700002)(3660700001)(2501003)(81166006)(102836003)(3846002)(6116002)(586003)(92566002)(107886002)(5001770100001)(15975445007)(76176999)(8676002)(2950100001)(77096005)(4001350100001)(36756003)(87936001)(101416001)(11100500001)(83506001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1449; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2016 19:26:02.3410 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1449
Archived-At: 
Subject: Re: [Netconf] restconf-11 ordered by user leaf-list entry insertion
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2016 19:26:06 -0000

DQpBZGFwdGluZyBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25m
LXJlc3Rjb25mLTEzI2FwcGVuZGl4LUQuMy41LCBhbmQgcmVtb3ZpbmcgYWxsIHRoZSBVUkwgZXNj
YXBpbmcsIEnigJlkIHNheToNCg0KICAgICAgUE9TVCAvcmVzdGNvbmYvZGF0YS94OnkvP2luc2Vy
dD1hZnRlciZwb2ludD0veDp5L3o9YiAgSFRUUC8xLjENCiAgICAgIEhvc3Q6IGV4YW1wbGUuY29t
DQogICAgICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3lhbmcuZGF0YStqc29uDQoNCiAgICAg
IHsNCiAgICAgICAgIng6eiIgOiAiYyINCiAgICAgIH0NCg0KDQpLZW50DQoNCg0KT24gNC8xNC8x
NiwgNToyMyBBTSwgIk5ldGNvbmYgb24gYmVoYWxmIG9mIEplcm5laiBUdWxqYWsiIDxuZXRjb25m
LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGplcm5lai50dWxqYWtAbWctc29mdC5zaT4g
d3JvdGU6DQoNCkZvciB0aGUgZm9sbG93aW5nIG1vZHVsZToNCg0KbW9kdWxlIHggew0KICAgbmFt
ZXNwYWNlICJleGFtcGxlOnVyaSI7DQogICBwcmVmaXggZXg7DQoNCiAgIGNvbnRhaW5lciB5IHsN
CiAgICAgbGVhZi1saXN0IHogew0KICAgICAgIHR5cGUgc3RyaW5nOw0KICAgICAgIG9yZGVyZWQt
YnkgdXNlcjsNCiAgICAgfQ0KICAgfQ0KfQ0KDQphbmQgYSBkYXRhc3RvcmUgY29udGFpbmluZzoN
Cg0KICAgPGV4OnkgeG1sbnM6ZXg9ImV4YW1wbGU6dXJpIj4NCiAgICAgPGV4Ono+YTwvZXg6ej4N
CiAgICAgPGV4Ono+YjwvZXg6ej4NCiAgICAgPGV4Ono+ZDwvZXg6ej4NCiAgIDwvZXg6eT4NCg0K
d2hhdCBpcyB0aGUgY29ycmVjdCByZXN0Y29uZiByZXF1ZXN0ICh1c2luZyAiaW5zZXJ0IiBhbmQg
InBvaW50IikgdG8gDQppbnNlcnQgbGVhZi1saXN0IGVudHJ5ICJjIiBhZnRlciBlbnRyeSAiYiIs
IGZvciBib3RoIFhNTCBhbmQgSlNPTiBlbmNvZGluZz8NCg0KSmVybmVqDQoNCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpOZXRjb25mIG1haWxpbmcgbGlz
dA0KTmV0Y29uZkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9uZXRjb25mDQoNCg0K


From nobody Wed Jun 29 13:06:39 2016
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 4599712D67A for ; Wed, 29 Jun 2016 13:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.892
X-Spam-Level: 
X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 RSp0VkgLilG8 for ; Wed, 29 Jun 2016 13:06:36 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0103.outbound.protection.outlook.com [207.46.100.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8521B12D674 for ; Wed, 29 Jun 2016 13:06:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=t7oyJiwAe0SEEuEJt2g2YVnWrb8u8/oxRfa9Adp6oVM=; b=hrjmfUZmh3kDsOOgCa058CSIRBf3btEDeGnoHau9KIYOMeDDcyzaagyfQZM6h/fg3mK01UfqCuCF5tYVAdVmJPsdvCceBnAw+EFhiwexy9EbeDGaDJISSCobNhtWS2mPNnj3o+ZN+GABNode128XSLq5817k4CE2+JbGLybbHNY=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1449.namprd05.prod.outlook.com (10.160.148.155) with Microsoft SMTP Server (TLS) id 15.1.528.16; Wed, 29 Jun 2016 20:06:33 +0000
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0528.017; Wed, 29 Jun 2016 20:06:33 +0000
From: Kent Watsen 
To: "fengchong (C)" , Andy Bierman 
Thread-Topic: [Netconf] Some questions about restconf
Thread-Index: AQHR0kG7IkFli6wgo0KvAoCIAdF1Rg==
Date: Wed, 29 Jun 2016 20:06:33 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.17.0.160611
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.13]
x-ms-office365-filtering-correlation-id: c7a44052-27cb-4c1c-684f-08d3a058de57
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1449; 6:Z3xNTscBu6YFPhv+7hL/TGc8bS8zuGMqw4bueJ0iyw+Vy62RPZB8Xm3POCgeWxMZvbkL03TVhFzISha7ZBFhFRTfvWEAm62n1s6HSjO7bpBbKv39D5ynaSfgG8v+GGL/tH5tshx0x6Z2sj5xkgrvjl2gxo3kyXaclzfLWdyVHAcoup39MX2tHvTL28QD9Upnf4tbzDOuilH7sJmrGNRXbDeekaVXGNpu7o6z3cfme/A345e0Vtshu4+TZxbz6XzWpDaXj6mJUg87Zk4IWAD9NvhbyDcUxNw0SFC+J84DsPPs7wbs9aTUcAW3XKxPkFZCNTEc4+f2sxIepZWZoKT2RQ==; 5:SJvDohC8QNxka8VPSGjvCT/5qnW8xTSlrXAcutJbo1V0EE2pu1816f48fz0xVFgV7i58lBiO7OKuAQ05fUJkdA43BwtsIin11VxcrOvJPL8T2s7ET91Dld1f6dPDBXj0D7BUUGbaqFVbDQB/r889Uw==; 24:IP4ugyTcK86sYDOVYI91HGcOTEumjVe21Gm3QGRopolsIbUnfusD5QvMuUiPmS/A35rqme1TKIH7fm84KhGjAjoFDCPaJl1/sft/rRoipQ0=; 7:RuiQfFJGYOW4itC4bZGmJQeY70zgTa4o32gF45pdaNQw2Wq0svSOcHYibMZEKaQunvs3UW75ZwZ0UHBn8Shp35IjF9KxQwDkpaQpG5DXljKvix4Cik1h/0ptnms8FPWL+crrWl+RmFkikEvoEYpkL8Tc4DbqF5I/pEf+0yzBWX2xUTwLb7fSlt3j9NFAFwoLiexns4BB05M6EMKWLcU9vhnSbg6UvIfhRTlE+2FkWZ0HPFtUoUvg5fXXYW7x54IK
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1449;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(50582790962513)(88738726483465)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415321)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CY1PR0501MB1449; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1449; 
x-forefront-prvs: 09888BC01D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(252514010)(199003)(377454003)(189002)(81166006)(2900100001)(3280700002)(3660700001)(6116002)(16601075003)(102836003)(3846002)(97736004)(106356001)(105586002)(82746002)(189998001)(81156014)(106116001)(33656002)(66066001)(87936001)(4001350100001)(99936001)(36756003)(11100500001)(101416001)(83506001)(18206015028)(5001770100001)(7906003)(586003)(92566002)(77096005)(15975445007)(4326007)(861006)(8676002)(16236675004)(19617315012)(83716003)(5002640100001)(122556002)(19300405004)(50986999)(2906002)(19627595001)(19625215002)(54356999)(10400500002)(68736007)(7736002)(19580405001)(7846002)(86362001)(99286002)(19580395003)(17760045003)(8936002)(7099028)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1449; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/related; boundary="_004_B304EE46154E4C6BA623211FD070E886junipernet_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2016 20:06:33.5817 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1449
Archived-At: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] Some questions about restconf
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2016 20:06:38 -0000

--_004_B304EE46154E4C6BA623211FD070E886junipernet_
Content-Type: multipart/alternative;
	boundary="_000_B304EE46154E4C6BA623211FD070E886junipernet_"

--_000_B304EE46154E4C6BA623211FD070E886junipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

UGxlYXNlIHNlZSByZXNwb25zZXMgaW5saW5lLg0KDQpLZW50DQoNCkZyb206IE5ldGNvbmYgPG5l
dGNvbmYtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mICJmZW5nY2hvbmcgKEMpIiA8ZnJh
bmsuZmVuZ2Nob25nQGh1YXdlaS5jb20+DQpEYXRlOiBNb25kYXksIE1heSAyLCAyMDE2IGF0IDEw
OjA3IFBNDQpUbzogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+DQpDYzogIm5ldGNv
bmZAaWV0Zi5vcmciIDxuZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogW05ldGNvbmZdIFNvbWUg
cXVlc3Rpb25zIGFib3V0IHJlc3Rjb25mDQoNCkhpIGFuZHksDQoNCkkgaGF2ZSBzb21lIHF1ZXN0
aW9ucyBhYm91dCByZXN0Y29uZi4NCg0KDQox77yOTGVhZi9sZWFmLWxpc3QgY2FuIGJlIGRlbGV0
ZWQgYnkgcmVzdGNvbmY/DQoNCklmIGEgbW9kZWwgZGVmaW5lZCBhczoNCg0KQ29udGFpbmVyIGEg
ew0KDQpMaXN0IGIgew0KDQogICAgIEtleSBjOw0KDQogICAgTGVhZiBjIHvigKZ9DQoNCiAgICBM
ZWFmIGQge+KApn0NCg0KICAgIExlYWYgZSB74oCmfQ0KDQp9DQoNCn0NCg0KDQoNCklmIEkgd2Fu
dCB0byBkZWxldGUgbGVhZiBkLHRoZSB1cmwgc2hvdWxkIGJlOg0KDQovYS9iPTEvZA0KDQpPcg0K
DQovYS9iPTEgew0KDQogICA8ZC8+DQoNCn0NCg0KS0VOVD4gaXTigJlzIHRoZSBmb3JtZXIgKHNl
ZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25m
LTEzI3NlY3Rpb24tNC43KQ0KDQoNCg0KDQoyLiBJZiBJIHdhbnQgdG8gZGVsZXRlIG1vcmUgdGhh
biBvbmUgbGVhZnMsICBzaG91bGQgSSBzZW5kIG1hbnkgcmVxdWVzdHMgZm9yIGVhY2ggbGVhZj8g
SXMgdGhlcmUgYSB3YXkgb25lIHJlcXVlc3QgdG8gZGVsZXRlIG1hbnkgbGVhZnM/DQoNCktFTlQ+
IERFTEVURSBjYW4gb25seSB0YXJnZXQgb25lIHJlc291cmNlIGF0IGEgdGltZSwgdGhvdWdoIGh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtMTMj
c2VjdGlvbi00LjcgaGludHMgYXQgcG9zc2libGUgY29sbGVjdGlvbnMtb3JpZW50ZWQgZXh0ZW5z
aW9uIHRoYXQgbWlnaHQgYWxsb3cgZm9yIG1vcmUuICBUaGUgYmVzdCB3YXkgdG8gZG8gdGhpcyBu
b3cgaXMgdG8gdXNlIFlBTkctcGF0Y2ggaW5zdGVhZC4NCg0KDQoNCjMuIGNhbiBkZWxldGUgcmVx
dWVzdCBoYXZlIGJvZHk/DQogICBGb3IgZXhhbXBsZToNCiAgRGVsZXRlICBhL2I9MQ0Kew0KICA8
ZD4xPC9kPg0KPGU+MjwvZT4NCn0NCg0KSWYgYm9keSBjYW4gYmUgYWxsb3dlZCwgdGhlbiB0aGUg
Y29udGVudCBvZiBib2R5IHNob3VsZCBiZSBpZ25vcmVkIG9yIGJlIGludGVycHJldGVkIGFzIHN1
YnRyZWUgZmlsdGVyPw0KDQoNCktFTlQ+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3
MjMxI3NlY3Rpb24tNC4zLjUgc2F5czoNCg0KICAgQSBwYXlsb2FkIHdpdGhpbiBhIERFTEVURSBy
ZXF1ZXN0IG1lc3NhZ2UgaGFzIG5vIGRlZmluZWQgc2VtYW50aWNzOw0KICAgc2VuZGluZyBhIHBh
eWxvYWQgYm9keSBvbiBhIERFTEVURSByZXF1ZXN0IG1pZ2h0IGNhdXNlIHNvbWUgZXhpc3RpbmcN
CiAgIGltcGxlbWVudGF0aW9ucyB0byByZWplY3QgdGhlIHJlcXVlc3QuDQoNCkZyb20gd2hpY2gg
aXQgY2FuIGJlIGluZmVycmVkIHRoYXQgYSBzZXJ2ZXIgU0hPVUxEIGlnbm9yZSB0aGUgbWVzc2Fn
ZSBib2R5LCBpZiBwYXNzZWQuICBUaGlzIGlzIHdoYXQgUkZDIDI2MTYsIFNlY3Rpb24gNC4zIHNh
eXM6DQoNCiAgICBJZiB0aGUgcmVxdWVzdCBtZXRob2QgZG9lcyBub3QgaW5jbHVkZSBkZWZpbmVk
IHNlbWFudGljcyBmb3IgYW4NCiAgICBlbnRpdHktYm9keSwgdGhlbiB0aGUgbWVzc2FnZS1ib2R5
IFNIT1VMRCBiZSBpZ25vcmVkIHdoZW4NCiAgICBoYW5kbGluZyB0aGUgcmVxdWVzdC4NCg0KQnV0
IFJGQyA3MjMwIChTZWN0aW9uIDMuMykgZGlkbuKAmXQgY2FycnkgdGhpcyBsYW5ndWFnZSBvdmVy
IChkb27igJl0IGtub3cgd2h5KS4NCg0KDQpLZW50DQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQrlhq/lhrINCuWNjuS4uuaKgOacr+aciemZkOWFrOWPuCBIdWF3ZWkgVGVjaG5v
bG9naWVzIENvLiwgTHRkLg0KW29tcGFueV9sb2dvXQ0KDQpQaG9uZToNCkZheDoNCk1vYmlsZTog
MTg1MTkxMTczMTYNCkVtYWlsOiBmcmFuay5mZW5nY2hvbmdAaHVhd2VpLmNvbQ0K5Zyw5Z2A77ya
5Y2X5Lqs5biC6L2v5Lu25aSn6YGTMTAx5Y+35Y2O5Li65Y2X5Lqs5Z+65ZywIOmCrue8lu+8mjIx
MDAwMQ0KSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIEx0ZC4NCg0KaHR0cDovL3d3dy5odWF3ZWku
Y29tDQo=

--_000_B304EE46154E4C6BA623211FD070E886junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj
aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+
DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh
cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9
IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN
aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHls
ZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwo
I2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hh
cGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0
eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p
bHk65a6L5L2TO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJ
cGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5
OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpTVEhlaXRpOw0KCXBhbm9zZS0xOjIgMSA2IDAgNCAxIDEgMSAxIDE7fQ0K
LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N
c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z
aXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy
bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv
bjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk
aXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luOjBp
bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1pbmRlbnQ6MjEuMHB0Ow0KCWZvbnQt
c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uaG9lbnpiDQoJe21zby1z
dHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpw
ZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p
bHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlv
bjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt
dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u
MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4yNWluIDEuMGluIDEuMjVp
bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm
aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjExNDg1NDg1NzU7DQoJbXNvLWxp
c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE3NjA1ODA5NDggMTUyMTUy
NDcwMCA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcw
MyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6
JTHvvI47DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0Oi4yNWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA
bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2
ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28t
bGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1z
dG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDozLjBpbjsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N
CkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps
ZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21z
by1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJ
e21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+
DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI4Ii8+DQo8L3htbD48
IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0
PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIi8+DQo8L286c2hhcGVsYXlv
dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i
Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
Q2FsaWJyaSI+UGxlYXNlIHNlZSByZXNwb25zZXMgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh
bGlicmkiPktlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w
OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpi
bGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp
O2NvbG9yOmJsYWNrIj5OZXRjb25mICZsdDtuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9u
IGJlaGFsZiBvZiAmcXVvdDtmZW5nY2hvbmcgKEMpJnF1b3Q7ICZsdDtmcmFuay5mZW5nY2hvbmdA
aHVhd2VpLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBNYXkgMiwgMjAxNiBhdCAx
MDowNyBQTTxicj4NCjxiPlRvOiA8L2I+QW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5j
b20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtuZXRjb25mQGlldGYub3JnJnF1b3Q7ICZsdDtu
ZXRjb25mQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bTmV0Y29uZl0gU29tZSBx
dWVzdGlvbnMgYWJvdXQgcmVzdGNvbmY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0
LWxhbmd1YWdlOlpILUNOIj5IaSBhbmR5LDwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt
bGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29s
b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFu
IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u
dC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO
Ij5JIGhhdmUgc29tZSBxdWVzdGlvbnMgYWJvdXQgcmVzdGNvbmYuPC9zcGFuPjxzcGFuIHN0eWxl
PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p
bHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJz
cDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp
bi1sZWZ0Oi4yNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+
DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6
WkgtQ04iPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjHvvI48L3NwYW4+PC9zcGFuPjwh
W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJp
O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkxlYWYvbGVhZi1saXN0
IGNhbiBiZSBkZWxldGVkIGJ5IHJlc3Rjb25mPzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh
c3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M
aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW47dGV4dC1pbmRlbnQ6MGluIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMx
RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPklmIGEgbW9kZWwgZGVmaW5lZCBhczo8
L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi4yNWluO3RleHQtaW5kZW50OjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7
Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpI
LUNOIj5Db250YWluZXIgYSB7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn
ZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh
cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDouMjVpbjt0ZXh0LWluZGVudDo5LjBwdCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEO21z
by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5MaXN0IGIgezwvc3Bhbj48c3BhbiBzdHlsZT0ibXNv
LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW47dGV4dC1pbmRlbnQ6
OS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7
Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IEtleSBjOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6
WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo
IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW47dGV4dC1pbmRlbnQ6OS4wcHQiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RDttc28t
ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IExlYWYgYyB74oCmfTwv
c3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl
ZnQ6LjI1aW47dGV4dC1pbmRlbnQ6OS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0
O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpa
SC1DTiI+Jm5ic3A7Jm5ic3A7ICZuYnNwO0xlYWYgZCB74oCmfTwvc3Bhbj48c3BhbiBzdHlsZT0i
bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW47dGV4dC1pbmRl
bnQ6OS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGli
cmk7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7
ICZuYnNwO0xlYWYgZSB74oCmfQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n
dWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh
Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDouMjVpbjt0ZXh0LWluZGVudDo5LjBwdCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdE
O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj59PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFy
ZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDouMjVpbjt0ZXh0LWluZGVudDowaW4i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6
IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+fTwvc3Bhbj48c3BhbiBzdHlsZT0i
bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW47dGV4dC1pbmRl
bnQ6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJp
O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48
c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1
aW47dGV4dC1pbmRlbnQ6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPklm
IEkgd2FudCB0byBkZWxldGUgbGVhZiBkLHRoZSB1cmwgc2hvdWxkIGJlOjwvc3Bhbj48c3BhbiBz
dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW47dGV4
dC1pbmRlbnQ6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpD
YWxpYnJpO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPi9hL2I9MS9k
PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t
bGVmdDouMjVpbjt0ZXh0LWluZGVudDowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0
O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpa
SC1DTiI+T3I8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9
Im1hcmdpbi1sZWZ0Oi4yNWluO3RleHQtaW5kZW50OjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh
bmd1YWdlOlpILUNOIj4vYS9iPTEgezwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy
YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW47dGV4dC1pbmRlbnQ6MGluIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0Q7
bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOyZuYnNwOyAmbHQ7ZC8mZ3Q7PC9zcGFu
PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDou
MjVpbjt0ZXh0LWluZGVudDowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+
fTwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s
YW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJy
aTtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5LRU5UJmd0OyBpdOKA
mXMgdGhlIGZvcm1lciAoc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm
LW5ldGNvbmYtcmVzdGNvbmYtMTMjc2VjdGlvbi00LjcpPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m
YW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0Q7
bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdE
O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1z
by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpD
YWxpYnJpO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjIuIElmIEkg
d2FudCB0byBkZWxldGUgbW9yZSB0aGFuIG9uZSBsZWFmcywgJm5ic3A7c2hvdWxkIEkgc2VuZCBt
YW55IHJlcXVlc3RzIGZvciBlYWNoIGxlYWY/IElzIHRoZXJlIGEgd2F5IG9uZSByZXF1ZXN0IHRv
IGRlbGV0ZSBtYW55IGxlYWZzPzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh
Z2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFG
NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7
Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpI
LUNOIj5LRU5UJmd0OyBERUxFVEUgY2FuIG9ubHkgdGFyZ2V0IG9uZSByZXNvdXJjZSBhdCBhIHRp
bWUsIHRob3VnaA0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll
dGYtbmV0Y29uZi1yZXN0Y29uZi0xMyNzZWN0aW9uLTQuNyI+DQpodHRwczovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLTEzI3NlY3Rpb24tNC43PC9hPiBo
aW50cyBhdCBwb3NzaWJsZSBjb2xsZWN0aW9ucy1vcmllbnRlZCBleHRlbnNpb24gdGhhdCBtaWdo
dCBhbGxvdyBmb3IgbW9yZS4mbmJzcDsgVGhlIGJlc3Qgd2F5IHRvIGRvIHRoaXMgbm93IGlzIHRv
IHVzZSBZQU5HLXBhdGNoIGluc3RlYWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2Fs
aWJyaTtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv
LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D
TiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0
OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4zLiBjYW4gZGVsZXRlIHJlcXVlc3QgaGF2
ZSBib2R5Pzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RDttc28tZmFy
ZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7IEZvciBleGFtcGxlOjwvc3Bhbj48c3Bh
biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv
bnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D
TiI+Jm5ic3A7IERlbGV0ZSAmbmJzcDthL2I9MQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFy
ZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJy
aTtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj57PC9zcGFuPjxzcGFu
IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u
dC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO
Ij4mbmJzcDsgJmx0O2QmZ3Q7MSZsdDsvZCZndDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJl
YXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJp
O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZsdDtlJmd0OzImbHQ7
L2UmZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEO21zby1mYXJl
YXN0LWxhbmd1YWdlOlpILUNOIj59PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n
dWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjoj
MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw
dDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6
WkgtQ04iPklmIGJvZHkgY2FuIGJlIGFsbG93ZWQsIHRoZW4gdGhlIGNvbnRlbnQgb2YgYm9keSBz
aG91bGQgYmUgaWdub3JlZCBvciBiZSBpbnRlcnByZXRlZCBhcyBzdWJ0cmVlIGZpbHRlcj88L3Nw
YW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjVwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh
Z2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29s
b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1
YWdlOlpILUNOIj5LRU5UJmd0Ow0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s
L3JmYzcyMzEjc2VjdGlvbi00LjMuNSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcy
MzEjc2VjdGlvbi00LjMuNTwvYT4gc2F5czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpD
YWxpYnJpO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RDttc28tZmFy
ZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7IEEgcGF5bG9hZCB3aXRoaW4gYSBERUxF
VEUgcmVxdWVzdCBtZXNzYWdlIGhhcyBubyBkZWZpbmVkIHNlbWFudGljczs8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjVwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh
Z2U6WkgtQ04iPiZuYnNwOyZuYnNwOyBzZW5kaW5nIGEgcGF5bG9hZCBib2R5IG9uIGEgREVMRVRF
IHJlcXVlc3QgbWlnaHQgY2F1c2Ugc29tZSBleGlzdGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+
Jm5ic3A7Jm5ic3A7IGltcGxlbWVudGF0aW9ucyB0byByZWplY3QgdGhlIHJlcXVlc3QuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0
LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxp
YnJpO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZyb20gd2hpY2gg
aXQgY2FuIGJlIGluZmVycmVkIHRoYXQgYSBzZXJ2ZXIgU0hPVUxEIGlnbm9yZSB0aGUgbWVzc2Fn
ZSBib2R5LCBpZiBwYXNzZWQuJm5ic3A7IFRoaXMgaXMgd2hhdCBSRkMgMjYxNiwgU2VjdGlvbiA0
LjMgc2F5czoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFG
NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7
Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpI
LUNOIj4mbmJzcDsmbmJzcDsmbmJzcDsgSWYgdGhlIHJlcXVlc3QgbWV0aG9kIGRvZXMgbm90IGlu
Y2x1ZGUgZGVmaW5lZCBzZW1hbnRpY3MgZm9yIGFuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwO2VudGl0eS1ib2R5LCB0aGVuIHRoZSBtZXNzYWdlLWJvZHkg
U0hPVUxEIGJlIGlnbm9yZWQgd2hlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGli
cmk7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7
ICZuYnNwO2hhbmRsaW5nIHRoZSByZXF1ZXN0Ljwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh
c3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7
Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxz
cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7
Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpI
LUNOIj5CdXQgUkZDIDcyMzAgKFNlY3Rpb24gMy4zKSBkaWRu4oCZdCBjYXJyeSB0aGlzIGxhbmd1
YWdlIG92ZXIgKGRvbuKAmXQga25vdyB3aHkpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6WkgtQ04iPktlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIg
c3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28t
ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWdu
PSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNUSGVpdGk7Y29s
b3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuWGr+WGsjwvc3Bhbj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTVEhlaXRpO2NvbG9yOmJsYWNrO21z
by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48YnI+DQo8c3BhbiBsYW5nPSJaSC1DTiI+5Y2O5Li6
5oqA5pyv5pyJ6ZmQ5YWs5Y+4PC9zcGFuPiBIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLjxi
cj4NCjwvc3Bhbj48IS0tW2lmIGd0ZSB2bWwgMV0+PHY6c2hhcGV0eXBlIGlkPSJfeDAwMDBfdDc1
IiBjb29yZHNpemU9IjIxNjAwLDIxNjAwIiBvOnNwdD0iNzUiIG86cHJlZmVycmVsYXRpdmU9InQi
IHBhdGg9Im1ANEA1bEA0QDExQDlAMTFAOUA1eGUiIGZpbGxlZD0iZiIgc3Ryb2tlZD0iZiI+DQo8
djpzdHJva2Ugam9pbnN0eWxlPSJtaXRlciIvPg0KPHY6Zm9ybXVsYXM+DQo8djpmIGVxbj0iaWYg
bGluZURyYXduIHBpeGVsTGluZVdpZHRoIDAiLz4NCjx2OmYgZXFuPSJzdW0gQDAgMSAwIi8+DQo8
djpmIGVxbj0ic3VtIDAgMCBAMSIvPg0KPHY6ZiBlcW49InByb2QgQDIgMSAyIi8+DQo8djpmIGVx
bj0icHJvZCBAMyAyMTYwMCBwaXhlbFdpZHRoIi8+DQo8djpmIGVxbj0icHJvZCBAMyAyMTYwMCBw
aXhlbEhlaWdodCIvPg0KPHY6ZiBlcW49InN1bSBAMCAwIDEiLz4NCjx2OmYgZXFuPSJwcm9kIEA2
IDEgMiIvPg0KPHY6ZiBlcW49InByb2QgQDcgMjE2MDAgcGl4ZWxXaWR0aCIvPg0KPHY6ZiBlcW49
InN1bSBAOCAyMTYwMCAwIi8+DQo8djpmIGVxbj0icHJvZCBANyAyMTYwMCBwaXhlbEhlaWdodCIv
Pg0KPHY6ZiBlcW49InN1bSBAMTAgMjE2MDAgMCIvPg0KPC92OmZvcm11bGFzPg0KPHY6cGF0aCBv
OmV4dHJ1c2lvbm9rPSJmIiBncmFkaWVudHNoYXBlb2s9InQiIG86Y29ubmVjdHR5cGU9InJlY3Qi
Lz4NCjxvOmxvY2sgdjpleHQ9ImVkaXQiIGFzcGVjdHJhdGlvPSJ0Ii8+DQo8L3Y6c2hhcGV0eXBl
Pjx2OnNoYXBlIGlkPSJfeDAwMDBfczEwMjYiIHR5cGU9IiNfeDAwMDBfdDc1IiBhbHQ9Im9tcGFu
eV9sb2dvIiBzdHlsZT0ncG9zaXRpb246YWJzb2x1dGU7bWFyZ2luLWxlZnQ6MDttYXJnaW4tdG9w
OjA7d2lkdGg6NzYuNXB0O2hlaWdodDoyNHB0O3otaW5kZXg6MjUxNjU4MjQwO21zby13cmFwLWRp
c3RhbmNlLWxlZnQ6MDttc28td3JhcC1kaXN0YW5jZS10b3A6MDttc28td3JhcC1kaXN0YW5jZS1y
aWdodDowO21zby13cmFwLWRpc3RhbmNlLWJvdHRvbTowO21zby1wb3NpdGlvbi1ob3Jpem9udGFs
OmxlZnQ7bXNvLXBvc2l0aW9uLWhvcml6b250YWwtcmVsYXRpdmU6dGV4dDttc28tcG9zaXRpb24t
dmVydGljYWwtcmVsYXRpdmU6bGluZScgbzphbGxvd292ZXJsYXA9ImYiPg0KPHY6aW1hZ2VkYXRh
IHNyYz0iY2lkOmltYWdlMDAxLmpwZ0AwMUQxRDIyMC4zM0M2ODY1MCIgbzp0aXRsZT0iaW1hZ2Uw
MDEuanBnQDAxRDFBNTIzLjlGNzNGNDcwIi8+DQo8dzp3cmFwIHR5cGU9InNxdWFyZSIvPg0KPC92
OnNoYXBlPjwhW2VuZGlmXS0tPjwhW2lmICF2bWxdPjxpbWcgd2lkdGg9IjEwMiIgaGVpZ2h0PSIz
MiIgc3JjPSJjaWQ6aW1hZ2UwMDEuanBnQDAxRDFEMjIwLjMzQzY4NjUwIiBhbGlnbj0ibGVmdCIg
YWx0PSJvbXBhbnlfbG9nbyIgdjpzaGFwZXM9Il94MDAwMF9zMTAyNiI+PCFbZW5kaWZdPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNUSGVpdGk7Y29sb3I6YmxhY2s7
bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxicj4NCjxicj4NClBob25lOiA8YnI+DQpGYXg6
IDxicj4NCk1vYmlsZTogMTg1MTkxMTczMTY8YnI+DQpFbWFpbDogZnJhbmsuZmVuZ2Nob25nQGh1
YXdlaS5jb208YnI+DQo8c3BhbiBsYW5nPSJaSC1DTiI+5Zyw5Z2A77ya5Y2X5Lqs5biC6L2v5Lu2
5aSn6YGTPC9zcGFuPjEwMTxzcGFuIGxhbmc9IlpILUNOIj7lj7fljY7kuLrljZfkuqzln7rlnLAg
6YKu57yW77yaPC9zcGFuPjIxMDAwMTxicj4NCkh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQu
PGJyPg0KPGJyPg0KaHR0cDovL3d3dy5odWF3ZWkuY29tPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv
cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4NCjwvc3Bhbj48c3BhbiBzdHls
ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_B304EE46154E4C6BA623211FD070E886junipernet_--

--_004_B304EE46154E4C6BA623211FD070E886junipernet_
Content-Type: image/jpeg; name="image001.jpg"
Content-Description: image001.jpg
Content-Disposition: inline; filename="image001.jpg"; size=6738;
	creation-date="Wed, 29 Jun 2016 20:06:32 GMT";
	modification-date="Wed, 29 Jun 2016 20:06:32 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA
AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA
AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA
AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB
AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A
AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA////////
/////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD/////////
////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA
AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A
AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB
AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA
AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA
AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg
AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS
AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF
U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA
AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA
TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA
AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA
AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB
bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA
AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl
QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u
ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN
BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA
AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM
QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT
ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O
Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB
IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB
AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR
obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF
tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR
AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV
NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA
AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6
6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs
VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns
U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9
w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh
fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX
146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh
SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t
bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo
JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb
qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv
/QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F
ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4
HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v
6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m
+u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6
tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ
JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r
WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z
OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB
AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA
AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq
AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8
CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox
ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA
BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB
AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf
Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM
DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM
DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED
EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA
AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV
UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0
pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB
UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz
hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/
APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3
0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl
/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP
UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+
qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW
9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq
FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp
VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku
cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf
Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0
PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C
OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us
XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j
QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6
jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n
0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT
gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf
UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj
Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI
BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04
MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA
AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh
CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp
anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV
1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK
C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy
0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD
hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm
5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge
ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn
yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr
aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g
dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf
03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l
6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo
9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai
uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45
RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV
zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc
TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM
v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S
reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8
V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM
qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/
thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le
LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x
ke3tRX0lRQB//9kA

--_004_B304EE46154E4C6BA623211FD070E886junipernet_--


From nobody Wed Jun 29 13:30:44 2016
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 CDAE312D5E3 for ; Wed, 29 Jun 2016 13:30:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level: 
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 om9B3DxclYxe for ; Wed, 29 Jun 2016 13:30:41 -0700 (PDT)
Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 E514612D648 for ; Wed, 29 Jun 2016 13:30:40 -0700 (PDT)
Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-08v.sys.comcast.net with SMTP id IM85brm0PlVqIIM87bHf56; Wed, 29 Jun 2016 20:30:39 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467232239; bh=kcckooD5TuS0R1UuzI/Xu8MfH0Ws+aPQuMRv6kDfq8s=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=wWhL/CXduUW5gEGyFvv4oN0Kkd9yXsWJuyNkUAgtFdyrQReTjfGrV6wh8xL/MFa0T Ck7Fi9Sa+hPM1rxXWskRSYOzJ7j5Ck/UQRA+6tMMQpQ9VJYV2lx55pgBFn81k1HP/z FUYgkN9n6xhvl+usR1cEd+73PRS7L4jkwMg86JAxSgCgof4O6XtYH66jkoeDJ/ka6P XUsSQPisKqS1CXOlO/eelqLf5GYAOQLEnjZSoVgjY9DFlznQZWwiZMLUpvErCgjsrQ JbFjoWaFSzYMiLd9GYYGrenb7y0v14+NRxc6CzjhWiLKm/44aflDLqG5YPmM3n5nHB Y66fMOS4ZcTUw==
Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-08v.sys.comcast.net with comcast id CkWe1t00G1nMCLR01kWfid; Wed, 29 Jun 2016 20:30:39 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5TKUcma013258 for ; Wed, 29 Jun 2016 16:30:38 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5TKUbBG013255; Wed, 29 Jun 2016 16:30:37 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: netconf@ietf.org
Sender: worley@ariadne.com (Dale R. Worley)
Date: Wed, 29 Jun 2016 16:30:37 -0400
Message-ID: <87mvm3d9g2.fsf@hobgoblin.ariadne.com>
Archived-At: 
Subject: [Netconf] Comments on draft-ietf-netconf-restconf-14
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2016 20:30:43 -0000

These are derived from my "Comments on draft-ietf-netconf-restconf-13",
updated based on the -14 draft.

3.6

In 3.6.1 is:

   

This means the 'input' element of an RPC body is in the namespace of
the module.  Similarly for 'output' elements.  This is not specified
anywhere.  (Errors is specified to be in "ietf-restconf" in section
7.1.)

Perhaps the way to clarify this is to change this paragraph

   If the "rpc" or "action" statement has an "input" section then
   instances of these input parameters are encoded in the module
   namespace where the "rpc" or "action" statement is defined, in an XML
   element or JSON object named "input".

into, perhaps, this

   If the "rpc" or "action" statement has an "input" section then
   instances of these input parameters are encoded in an XML element
   or JSON object named "input", which is in the module namespace
   where the "rpc" or "action" statement is defined.

The parallel change for "output" is (also correcting the typo "input"
to "output")

   If the "rpc" or "action" statement has an "output" section then
   instances of these >>output<< parameters are encoded in an XML element
   or JSON object named "output", which is in the module namespace
   where the "rpc" or "action" statement is defined.

This is just a rearrangement of the phrases of these sentences, but
they put the "input"/"output" element/object in the specified
namespace (and by implication, the input/output parameters are also).

3.6.1

   If the "rpc" or "action" statement has an "input" section, then the
   "input" node is provided in the message-body, corresponding to the
   YANG data definition statements within the "input" section.

This paragraph is an almost-clone of a paragraph in 3.6.  If
repetition is intended, it should probably be updated from the changed
wording in 3.6

3.6.2

   If the "rpc" or "action" statement has an "output" section, then the
   "output" node is provided in the message-body, corresponding to the
   YANG data definition statements within the "output" section.

This paragraph is an almost-clone of a paragraph in 3.6.  If
repetition is intended, it should probably be updated from the changed
wording in 3.6

4.3

   Note that the way that access control is applied to data resources is
   completely incompatible with HTTP caching.  The Last-Modified and
   ETag headers maintained for a data resource are not affected by
   changes to the access control rules for that data resource.  It is
   possible for the representation of a data resource that is visible to
   a particular client to be changed without detection via the Last-
   Modified or ETag values.

Note that it's possible for the client to detect changes in
configuration data that it is not allowed to read by detecting changes
in the Last-Modified/ETag values.  This probably isn't a security
problem, but the authors should be aware of it.

4.6

   Each patch mechanism needs a unique media type.  Zero or more patch
   media types MAY be supported by the server.  The media types
   supported by a server can be discovered by the client by sending an
   OPTIONS request (see Section 4.1).

To prevent the reader from making the mistake I just made, it would be
helpful to explicitly state that it is the Accept-Patch header in the
OPTIONS response, rather than an enumeration of the allowed content
types generally, that should be examined.  (An enumeration of allowed
content types generally doesn't exist in HTTP, but does in SIP.)

   A server's response to an OPTIONS request (see Section 4.1) lists
   the patch media types it supports in the Accept-Patch header.

4.6

Yang has been extended to allow non-unique key values.  The result is
that URLs may identify multiple data instances.  This seems to be
specified for GET (if JSON is used, GET can return multiple instances;
if XML is used, a 400 response is given) and DELETE (only one instance
(arbitrarily chosen) is deleted; this may be modified by query
parameters).  But PATCH does not seem to specify the behavior if
multiple instances are selected.

4.8.2

   By default, the server will include all sub-resources within a
   retrieved resource, which have the same resource type as the
   requested resource.  Only one level of sub-resources with a different
   media type than the target resource will be returned.  The exception
   is the datastore resource.  If this resource type is retrieved then
   by default the datastore and all child data resources are returned.

[Note for the -13 draft:]  Does the second sentence do anything?  The
only instance I know of of a node whose media type is different from
that of its child nodes is the the datastore resource, and that is
specifically exempted from the effect of the 2nd sentence.

With the -14 draft, there are only two media types, and which one is
used to report the contents of a resource is determined by the client,
as a choice of encoding, rather than as an attribute of the resource.
So I think this paragraph has no effect any more.

12.  Security Considerations

    The lowest NETCONF layer is the secure transport layer,
   and the mandatory-to-implement secure transport is Secure Shell
   (SSH) ^RFC6242^. The NETCONF access control model ^RFC6536^
   provides the means to restrict access for particular NETCONF users
   to a pre-configured subset of all available NETCONF protocol
   operations and content.

The formatting of this paragraph is damaged:  There is an extra space
at its beginning, and references are marked ^...^ rather than [...].

13

Who is The Space & Terrestrial Communications Directorate?  Maybe it
would add to the credit of the S&TCD by prefixing the country that
funds it ... which seems to be "United States Army".

Dale


From nobody Wed Jun 29 13:36:27 2016
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 B174412D58C for ; Wed, 29 Jun 2016 13:36:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 ARWvgLW7YQmN for ; Wed, 29 Jun 2016 13:36:21 -0700 (PDT)
Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F0E112D775 for ; Wed, 29 Jun 2016 13:36:20 -0700 (PDT)
Received: by mail-vk0-x22f.google.com with SMTP id c2so82390238vkg.1 for ; Wed, 29 Jun 2016 13:36:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3X8g5Br5OyRBjQocg1HHxAAWWTljj53VtjaPXKpjW0w=; b=qSzhseyK8f2aMuhSM4t4WMaMsyIhumPS9XUCQwzNOqWf1XzUaJHLQoLMYSCyGoqQJH jMm2B+wpxs58VsTiLVJM/B65O8s2kGKQnwZ0/Kozz55mc1IfjpR653GLUchOI/R7h4Ag iyu1QVujZKd6Rv4g8UK4cNdPowmpApN/H/r/5/oWfNbQWDCnGHt9w6+0IJVn8YR6gg9o Yw+lrQNQmi5zQRbkN7GoOa3BoCGGP4bsEEVKEO5XVfOrkbUnflecxj8tsOK4G/a1A2kQ FYuK3+jfZsT/U+lh+MKbyTfQrDnS3G/mRb4pWos4bVoROWvKnimLCtwhOUNdG3FhBjTl /chQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3X8g5Br5OyRBjQocg1HHxAAWWTljj53VtjaPXKpjW0w=; b=WMKoTs2CeDilY4WogpghR/wU15IaM8YFYvEkkkQ/U4EWLRamECEYvHY0PeCBvNgvXC aj/p5Df/483BtDsfFCbxV8pNCtvgv/BMlgoQoRqUZbPiXOrKuLvgH2qSGeAPuyXjwCgV mkvHQW1GCMxlXFY45yHhoHpVyiIH5TROjC9SFH5sbNS3RtW5TfEUoxewtqW3BTjr+Kgf /2ybtdDVVL5b3Zpp3nSK7u9BRyCg9WRqP4cyB1agCE7CDRcLVRRKQNufSbqA3jSqw4LZ U0HAfQJBm8nXz0PU1Q/OX1OuCys1bLXeD5bOT2R3V3bJBVcqvf+p/w6SDD7Cvm6pFShW uhZg==
X-Gm-Message-State: ALyK8tIjGuHzG/urFWjKNm8iPt1Lmeo7Z0EedAD+1p6YBxTxbBi0hjoYYvSNX3S1zbgBzpacwCl+tqizRr/E3g==
X-Received: by 10.176.7.7 with SMTP id h7mr4825724uah.9.1467232579109; Wed, 29 Jun 2016 13:36:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Wed, 29 Jun 2016 13:36:18 -0700 (PDT)
In-Reply-To: <87mvm3d9g2.fsf@hobgoblin.ariadne.com>
References: <87mvm3d9g2.fsf@hobgoblin.ariadne.com>
From: Andy Bierman 
Date: Wed, 29 Jun 2016 13:36:18 -0700
Message-ID: 
To: "Dale R. Worley" 
Content-Type: multipart/alternative; boundary=94eb2c1229d8ae7468053670b445
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] Comments on draft-ietf-netconf-restconf-14
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2016 20:36:25 -0000

--94eb2c1229d8ae7468053670b445
Content-Type: text/plain; charset=UTF-8

On Wed, Jun 29, 2016 at 1:30 PM, Dale R. Worley  wrote:

> These are derived from my "Comments on draft-ietf-netconf-restconf-13",
> updated based on the -14 draft.
>
> 3.6
>
> In 3.6.1 is:
>
>    
>
> This means the 'input' element of an RPC body is in the namespace of
> the module.  Similarly for 'output' elements.  This is not specified
> anywhere.  (Errors is specified to be in "ietf-restconf" in section
> 7.1.)
>


But this would just restate normative text from YANG, right?
RESTCONF does not need to define the module namespace for the input-stmt.


Andy


> Perhaps the way to clarify this is to change this paragraph
>
>    If the "rpc" or "action" statement has an "input" section then
>    instances of these input parameters are encoded in the module
>    namespace where the "rpc" or "action" statement is defined, in an XML
>    element or JSON object named "input".
>
> into, perhaps, this
>
>    If the "rpc" or "action" statement has an "input" section then
>    instances of these input parameters are encoded in an XML element
>    or JSON object named "input", which is in the module namespace
>    where the "rpc" or "action" statement is defined.
>
> The parallel change for "output" is (also correcting the typo "input"
> to "output")
>
>    If the "rpc" or "action" statement has an "output" section then
>    instances of these >>output<< parameters are encoded in an XML element
>    or JSON object named "output", which is in the module namespace
>    where the "rpc" or "action" statement is defined.
>
> This is just a rearrangement of the phrases of these sentences, but
> they put the "input"/"output" element/object in the specified
> namespace (and by implication, the input/output parameters are also).
>
> 3.6.1
>
>    If the "rpc" or "action" statement has an "input" section, then the
>    "input" node is provided in the message-body, corresponding to the
>    YANG data definition statements within the "input" section.
>
> This paragraph is an almost-clone of a paragraph in 3.6.  If
> repetition is intended, it should probably be updated from the changed
> wording in 3.6
>
> 3.6.2
>
>    If the "rpc" or "action" statement has an "output" section, then the
>    "output" node is provided in the message-body, corresponding to the
>    YANG data definition statements within the "output" section.
>
> This paragraph is an almost-clone of a paragraph in 3.6.  If
> repetition is intended, it should probably be updated from the changed
> wording in 3.6
>
> 4.3
>
>    Note that the way that access control is applied to data resources is
>    completely incompatible with HTTP caching.  The Last-Modified and
>    ETag headers maintained for a data resource are not affected by
>    changes to the access control rules for that data resource.  It is
>    possible for the representation of a data resource that is visible to
>    a particular client to be changed without detection via the Last-
>    Modified or ETag values.
>
> Note that it's possible for the client to detect changes in
> configuration data that it is not allowed to read by detecting changes
> in the Last-Modified/ETag values.  This probably isn't a security
> problem, but the authors should be aware of it.
>
> 4.6
>
>    Each patch mechanism needs a unique media type.  Zero or more patch
>    media types MAY be supported by the server.  The media types
>    supported by a server can be discovered by the client by sending an
>    OPTIONS request (see Section 4.1).
>
> To prevent the reader from making the mistake I just made, it would be
> helpful to explicitly state that it is the Accept-Patch header in the
> OPTIONS response, rather than an enumeration of the allowed content
> types generally, that should be examined.  (An enumeration of allowed
> content types generally doesn't exist in HTTP, but does in SIP.)
>
>    A server's response to an OPTIONS request (see Section 4.1) lists
>    the patch media types it supports in the Accept-Patch header.
>
> 4.6
>
> Yang has been extended to allow non-unique key values.  The result is
> that URLs may identify multiple data instances.  This seems to be
> specified for GET (if JSON is used, GET can return multiple instances;
> if XML is used, a 400 response is given) and DELETE (only one instance
> (arbitrarily chosen) is deleted; this may be modified by query
> parameters).  But PATCH does not seem to specify the behavior if
> multiple instances are selected.
>
> 4.8.2
>
>    By default, the server will include all sub-resources within a
>    retrieved resource, which have the same resource type as the
>    requested resource.  Only one level of sub-resources with a different
>    media type than the target resource will be returned.  The exception
>    is the datastore resource.  If this resource type is retrieved then
>    by default the datastore and all child data resources are returned.
>
> [Note for the -13 draft:]  Does the second sentence do anything?  The
> only instance I know of of a node whose media type is different from
> that of its child nodes is the the datastore resource, and that is
> specifically exempted from the effect of the 2nd sentence.
>
> With the -14 draft, there are only two media types, and which one is
> used to report the contents of a resource is determined by the client,
> as a choice of encoding, rather than as an attribute of the resource.
> So I think this paragraph has no effect any more.
>
> 12.  Security Considerations
>
>     The lowest NETCONF layer is the secure transport layer,
>    and the mandatory-to-implement secure transport is Secure Shell
>    (SSH) ^RFC6242^. The NETCONF access control model ^RFC6536^
>    provides the means to restrict access for particular NETCONF users
>    to a pre-configured subset of all available NETCONF protocol
>    operations and content.
>
> The formatting of this paragraph is damaged:  There is an extra space
> at its beginning, and references are marked ^...^ rather than [...].
>
> 13
>
> Who is The Space & Terrestrial Communications Directorate?  Maybe it
> would add to the credit of the S&TCD by prefixing the country that
> funds it ... which seems to be "United States Army".
>
> Dale
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

--94eb2c1229d8ae7468053670b445
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Jun 29, 2016 at 1:30 PM, Dale R. Worley <<=
a href=3D"mailto:worley@ariadne.com" target=3D"_blank">worley@ariadne.com> wrote:
These are derived fr=
om my "Comments on draft-ietf-netconf-restconf-13",

updated based on the -14 draft.



3.6



In 3.6.1 is:



=C2=A0 =C2=A0<input xmlns=3D"https://example.com/ns/exampl=
e-ops">



This means the 'input' element of an RPC body is in the namespace o=
f

the module.=C2=A0 Similarly for 'output' elements.=C2=A0 This is no=
t specified

anywhere.=C2=A0 (Errors is specified to be in "ietf-restconf" in =
section

7.1.)


But this would jus=
t restate normative text from YANG, right?
RESTCONF does not need=
 to define the module namespace for the input-stmt.

=C2=A0
Andy




Perhaps the way to clarify this is to change this paragraph



=C2=A0 =C2=A0If the "rpc" or "action" statement has an =
"input" section then

=C2=A0 =C2=A0instances of these input parameters are encoded in the module<=
br>
=C2=A0 =C2=A0namespace where the "rpc" or "action" stat=
ement is defined, in an XML

=C2=A0 =C2=A0element or JSON object named "input".



into, perhaps, this



=C2=A0 =C2=A0If the "rpc" or "action" statement has an =
"input" section then

=C2=A0 =C2=A0instances of these input parameters are encoded in an XML elem=
ent

=C2=A0 =C2=A0or JSON object named "input", which is in the module=
 namespace

=C2=A0 =C2=A0where the "rpc" or "action" statement is d=
efined.



The parallel change for "output" is (also correcting the typo &qu=
ot;input"

to "output")



=C2=A0 =C2=A0If the "rpc" or "action" statement has an =
"output" section then

=C2=A0 =C2=A0instances of these >>output<< parameters are encod=
ed in an XML element

=C2=A0 =C2=A0or JSON object named "output", which is in the modul=
e namespace

=C2=A0 =C2=A0where the "rpc" or "action" statement is d=
efined.



This is just a rearrangement of the phrases of these sentences, but

they put the "input"/"output" element/object in the spe=
cified

namespace (and by implication, the input/output parameters are also).



3.6.1



=C2=A0 =C2=A0If the "rpc" or "action" statement has an =
"input" section, then the

=C2=A0 =C2=A0"input" node is provided in the message-body, corres=
ponding to the

=C2=A0 =C2=A0YANG data definition statements within the "input" s=
ection.



This paragraph is an almost-clone of a paragraph in 3.6.=C2=A0 If

repetition is intended, it should probably be updated from the changed

wording in 3.6



3.6.2



=C2=A0 =C2=A0If the "rpc" or "action" statement has an =
"output" section, then the

=C2=A0 =C2=A0"output" node is provided in the message-body, corre=
sponding to the

=C2=A0 =C2=A0YANG data definition statements within the "output" =
section.



This paragraph is an almost-clone of a paragraph in 3.6.=C2=A0 If

repetition is intended, it should probably be updated from the changed

wording in 3.6



4.3



=C2=A0 =C2=A0Note that the way that access control is applied to data resou=
rces is

=C2=A0 =C2=A0completely incompatible with HTTP caching.=C2=A0 The Last-Modi=
fied and

=C2=A0 =C2=A0ETag headers maintained for a data resource are not affected b=
y

=C2=A0 =C2=A0changes to the access control rules for that data resource.=C2=
=A0 It is

=C2=A0 =C2=A0possible for the representation of a data resource that is vis=
ible to

=C2=A0 =C2=A0a particular client to be changed without detection via the La=
st-

=C2=A0 =C2=A0Modified or ETag values.



Note that it's possible for the client to detect changes in

configuration data that it is not allowed to read by detecting changes

in the Last-Modified/ETag values.=C2=A0 This probably isn't a security<=
br>
problem, but the authors should be aware of it.



4.6



=C2=A0 =C2=A0Each patch mechanism needs a unique media type.=C2=A0 Zero or =
more patch

=C2=A0 =C2=A0media types MAY be supported by the server.=C2=A0 The media ty=
pes

=C2=A0 =C2=A0supported by a server can be discovered by the client by sendi=
ng an

=C2=A0 =C2=A0OPTIONS request (see Section 4.1).



To prevent the reader from making the mistake I just made, it would be

helpful to explicitly state that it is the Accept-Patch header in the

OPTIONS response, rather than an enumeration of the allowed content

types generally, that should be examined.=C2=A0 (An enumeration of allowed<=
br>
content types generally doesn't exist in HTTP, but does in SIP.)



=C2=A0 =C2=A0A server's response to an OPTIONS request (see Section 4.1=
) lists

=C2=A0 =C2=A0the patch media types it supports in the Accept-Patch header.<=
br>


4.6



Yang has been extended to allow non-unique key values.=C2=A0 The result is<=
br>
that URLs may identify multiple data instances.=C2=A0 This seems to be

specified for GET (if JSON is used, GET can return multiple instances;

if XML is used, a 400 response is given) and DELETE (only one instance

(arbitrarily chosen) is deleted; this may be modified by query

parameters).=C2=A0 But PATCH does not seem to specify the behavior if

multiple instances are selected.



4.8.2



=C2=A0 =C2=A0By default, the server will include all sub-resources within a=


=C2=A0 =C2=A0retrieved resource, which have the same resource type as the
=C2=A0 =C2=A0requested resource.=C2=A0 Only one level of sub-resources with=
 a different

=C2=A0 =C2=A0media type than the target resource will be returned.=C2=A0 Th=
e exception

=C2=A0 =C2=A0is the datastore resource.=C2=A0 If this resource type is retr=
ieved then

=C2=A0 =C2=A0by default the datastore and all child data resources are retu=
rned.



[Note for the -13 draft:]=C2=A0 Does the second sentence do anything?=C2=A0=
 The

only instance I know of of a node whose media type is different from

that of its child nodes is the the datastore resource, and that is

specifically exempted from the effect of the 2nd sentence.



With the -14 draft, there are only two media types, and which one is

used to report the contents of a resource is determined by the client,

as a choice of encoding, rather than as an attribute of the resource.

So I think this paragraph has no effect any more.



12.=C2=A0 Security Considerations



=C2=A0 =C2=A0 The lowest NETCONF layer is the secure transport layer,

=C2=A0 =C2=A0and the mandatory-to-implement secure transport is Secure Shel=
l

=C2=A0 =C2=A0(SSH) ^RFC6242^. The NETCONF access control model ^RFC6536^
=C2=A0 =C2=A0provides the means to restrict access for particular NETCONF u=
sers

=C2=A0 =C2=A0to a pre-configured subset of all available NETCONF protocol
=C2=A0 =C2=A0operations and content.



The formatting of this paragraph is damaged:=C2=A0 There is an extra space<=
br>
at its beginning, and references are marked ^...^ rather than [...].



13



Who is The Space & Terrestrial Communications Directorate?=C2=A0 Maybe =
it

would add to the credit of the S&TCD by prefixing the country that

funds it ... which seems to be "United States Army".



Dale



_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf





--94eb2c1229d8ae7468053670b445--


From nobody Wed Jun 29 15:38:39 2016
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 4A43712D0A0 for ; Wed, 29 Jun 2016 15:38:37 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 lPjbWxohDux6 for ; Wed, 29 Jun 2016 15:38:34 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0795.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::795]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657D212D111 for ; Wed, 29 Jun 2016 15:38:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DQtnNnxo0jXY4srXvpTlkRKLUvg5McOA6Roqy0+j/wY=; b=Oj5l2skHG3iPs7qxbpTplPa8qDfNXxWYU8qDC/6isRzrowq1l5NEW1dojwSqyPUnORx2Mp1j9hEsxo1eiLiTJUSQRUDth968ToklIgQJC7Zy6vJ99aAGp1FZd55ofylCqUYRgurB2PrM2ouA03nva3AtDx/f15lDF90c7H1mZdw=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1452.namprd05.prod.outlook.com (10.160.149.13) with Microsoft SMTP Server (TLS) id 15.1.528.16; Wed, 29 Jun 2016 22:38:11 +0000
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0528.017; Wed, 29 Jun 2016 22:38:11 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: [Netconf] zerotouch/13: Signature over YANG data?
Thread-Index: AQHR0lbqRF2CE0HA502XoIUgUCHuKg==
Date: Wed, 29 Jun 2016 22:38:11 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.17.0.160611
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.13]
x-ms-office365-filtering-correlation-id: 70c29d2d-b8ca-491e-65b2-08d3a06e0cff
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1452; 6:ZSaOms6QLyq0tFXyst/vDATVag288BKRkSDWn/Y0/pwabtWdq8ZQADs3xXL5mFbf8tEnAxS6YAiVeOtaze7NMQTQAo7o2bI/wO/THui7NPGdDCMWHCSgqc28OrmWOeYWPwKLd2M4gPmDN+291V9sVmj7JEUxaItLkBUrpWa6W3n/DiBCPo4LCwSLnUxsZJD2/SjjcU6cQBlHKkDUsNi5G4vKgntnbrCZYQfcxISNmL+XwV3HtAoRtB1ckDZMyoxhRwsr+XzP89PehNAsyXC/A8es6lMe2cm7c7k5HsGq5nSxvdE4kUn010ZeUJKbTaPE5oZPX7njXqww1lT/VnUUFg==; 5:ng+CqEJjSrAJteN/lMchOG1MORLCdURQPpGFnRfx7jDSYGl3SwsPfhScJuIo9Fj2KtCN/Dtpms1vTdKyBr3BYfpRJamjmH4H0lxnAoqkCktGkwahPplvg2QJ19nIOSVPJZC4MbB+p5XKh62HMuCy0w==; 24:uG+ExwKxKAst6FgrB53YlFbRPFp52g8mu5zU2HwwcTV/WH5Xd8nWK0Uxww0G/TMTkJEmwatrAtYkpLC1oFPq0uDN3MtgHIpIDT0RkL3Ph8k=; 7:Mjyk/Wy5b8fTy8+XyZiTFEAJkycLtYKYl1GRV7De3OjVt3H6K27G8qnlnC12Ndr7kdWE6deDvz897yt702gCiXzLn7eQ5bl4/RVeRkBk1mZTfjuRXC4q/N+F25cqdDg3b0roeYz3tqi19LqvLka64FJPTYqVogqdGcR83lhqJSDI8R0OX1qy03+t/T3dXgPRT+jwSAXeoqkiz+WDwJ3LyS6W7sIuq3oSJgjFe3AW1RfnOdK5d6neyXW/IJRur7wE
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1452;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(131327999870524)(138986009662008)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026);  SRVR:CY1PR0501MB1452; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1452; 
x-forefront-prvs: 09888BC01D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(43544003)(377454003)(199003)(189002)(2501003)(19625215002)(19580405001)(19580395003)(102836003)(6116002)(586003)(101416001)(3846002)(99286002)(16236675004)(50986999)(11100500001)(36756003)(83716003)(450100001)(10400500002)(54356999)(82746002)(122556002)(8676002)(83506001)(92566002)(5640700001)(1730700003)(81156014)(33656002)(3280700002)(2900100001)(106356001)(19617315012)(189998001)(105586002)(15975445007)(5002640100001)(77096005)(68736007)(2351001)(3660700001)(81166006)(7906003)(87936001)(4001350100001)(86362001)(2906002)(7846002)(110136002)(66066001)(107886002)(97736004)(8936002)(106116001)(19300405004)(7736002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1452; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_E013CD61F1C648F196C8E26DCD8E69DEjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2016 22:38:11.2781 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1452
Archived-At: 
Subject: Re: [Netconf] zerotouch/13: Signature over YANG data?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2016 22:38:37 -0000

--_000_E013CD61F1C648F196C8E26DCD8E69DEjunipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VHJ5aW5nIHRvIG1vdmUgdGhpcyBkaXNjdXNzaW9uIGZvcndhcmQuLi4NCg0KQW4gaWRlYSBub3Qg
bGlzdGVkIGJlbG93IGlzIGZvciB0aGUg4oCYc2lnbmF0dXJl4oCZIHZhbHVlIChpLmUuIGEgcGtj
cyM3IHN0cnVjdHVyZSkgdG8gYWx3YXlzIGVudmVsb3AgdGhlIGJvb3RzdHJhcHBpbmcgZGF0YS4g
IFRoYXQgaXMsIHdl4oCZZCByZW1vdmUgdGhlIOKAnHJlZGlyZWN0LWluZm9ybWF0aW9u4oCdIGFu
ZCDigJxib290c3RyYXAtaW5mb3JtYXRpb27igJ0gZnJvbSB0aGUgZGF0YS1tb2RlbCAvIEFQSS4g
IE1vcmUgc3BlY2lmaWNhbGx5Og0KDQpPTEQ6DQoNCiAgbW9kdWxlOiBpZXRmLXplcm90b3VjaC1i
b290c3RyYXAtc2VydmVyDQogICAgICArLS1ybyBkZXZpY2VzDQogICAgICAgICArLS1ybyBkZXZp
Y2UqIFt1bmlxdWUtaWRdDQogICAgICAgICAgICArLS1ybyB1bmlxdWUtaWQgICAgICAgICBzdHJp
bmcNCiAgICAgICAgICAgICstLXJvICh0eXBlKT8NCiAgICAgICAgICAgIHwgICstLToocmVkaXJl
Y3QtaW5mb3JtYXRpb24pDQogICAgICAgICAgICB8ICB8ICArLS0uLi4NCiAgICAgICAgICAgIHwg
ICstLTooYm9vdHN0cmFwLWluZm9ybWF0aW9uKQ0KICAgICAgICAgICAgfCAgICAgKy0tLi4uDQog
ICAgICAgICAgICArLS1ybyBzaWduYXR1cmU/ICAgICAgICBiaW5hcnkgIC8vIGFuIG9wdGlvbmFs
IGRldGFjaGVkIHNpZ25hdHVyZSB1c2luZyBwa2NzIzcNCiAgICAgICAgICAgIC4uLg0KDQpORVc6
DQoNCiAgbW9kdWxlOiBpZXRmLXplcm90b3VjaC1ib290c3RyYXAtc2VydmVyDQogICAgICArLS1y
byBkZXZpY2VzDQogICAgICAgICArLS1ybyBkZXZpY2UqIFt1bmlxdWUtaWRdDQogICAgICAgICAg
ICArLS1ybyB1bmlxdWUtaWQgICAgICAgICBzdHJpbmcNCiAgICAgICAgICAgICstLXJvIGJvb3Rz
dHJhcC1kYXRhICAgIGJpbmFyeSAgLy8gYSBtYW5kYXRvcnkgcGtjcyM3IHN0cnVjdHVyZSB0aGF0
IHdyYXBzIHRoZSBzYW1lIGRhdGENCiAgICAgICAgICAgIC4uLg0KDQpTb21lIGNvbW1lbnRzOg0K
DQoxKSB0aGlzIEFQSSBpcyBmb3IgdGhlIGJvb3RzdHJhcCBzZXJ2ZXLigJlzIFNCSSAoc291dGhi
b3VuZCBhcGkpIGZhY2luZyBkZXZpY2VzOyBpdCBpcyByZWFkLW9ubHkgYW5kIHRodXMgZG9lcyBu
b3QgaGF2ZSB0byBiZSB1c2VyLWZyaWVuZGx5Lg0KDQoyKSBUaG91Z2ggdGhlIHplcm90b3VjaCBk
cmFmdCBzYXlzIHRoZSBub3J0aGJvdW5kIGludGVyZmFjZSBpcyBvdXQtb2Ytc2NvcGUsIGl0IHdv
dWxkIHNlZW0gdXNlZnVsIGZvciBhIGJvb3RzdHJhcCBzZXJ2ZXLigJlzIE5CSSB0byB0YWtlIGNh
cmUgb2YgZ2VuZXJhdGluZyB0aGUgcHJpdmF0ZS1rZXkgYW5kIENTUiBhbmQsIGxhdGVyLCBzaWdu
aW5nIGJvb3RzdHJhcHBpbmcgZGF0YS4gIFRoYXQgaXMsIHRoZSBOQkkgZm9yIGEgYm9vdHN0cmFw
IHNlcnZlciBtaWdodCByZXRhaW4gdGhlIOKAnHVzZXItZnJpZW5kbHnigJ0gQVBJIGRlZmluZWQg
YnkgdGhlIGN1cnJlbnQgWUFORyBtb2RlbCAod2hlcmUgdGhlIHRyZWUtc3RydWN0dXJlIGVsZW1l
bnRzIGFyZSB3cml0YWJsZSkgd2hpbGUgaW50ZXJuYWxseSBoYXZpbmcgbG9naWMgdG8gZHluYW1p
Y2FsbHkgY3JlYXRlIChzaWduZWQgb3IgdW5zaWduZWQpIHBrY3MjNyBzdHJ1Y3R1cmVzIGZvciBk
ZXZpY2VzIHRvIG9idGFpbi4NCg0KMykgdGhpcyBhcHByb2FjaCBoYXMgdGhlIGRvd25zaWRlIG9m
IGZvcmNpbmcgYm9vdHN0cmFwIHNlcnZlcnMgdG8gYWx3YXlzIHNlcnZlIHBrY3MjNyBzdHJ1Y3R1
cmVzLCBldmVuIHdoZW4gdGhlIGRhdGEgaXMgdW5zaWduZWQsIGFzIG9wcG9zZWQgdG8gb25seSB3
aGVuIHNpZ25lZCBkYXRhIGlzIG5lZWRlZCAoYXMgdGhlIGN1cnJlbnQgZHJhZnQgaGFzIGl0KS4g
IFBlcmhhcHMgbm90IGEgYmlnIGRlYWwsIGJ1dCBpdCBkb2VzIGluY3JlYXNlIHVwZnJvbnQgZGV2
ZWxvcG1lbnQgY29zdHMuDQoNCjQpIHRoaXMgYXBwcm9hY2ggaGFzIHRoZSB1cHNpZGUgb2YgZGVm
aW5pbmcgYSBuaWNlIGFydGlmYWN0IGVuY29kaW5nIGZvciBib3RoIHJlbW92YWJsZSBtZWRpYSBh
bmQgREhDUCwgYnV0IHdpdGggdGhlIGRvd25zaWRlIG9mIGNvbXBsaWNhdGluZyBETlMgbWFwcGlu
Z3MuICBTaW1wbGUgaXMgdGhlIHNvbHV0aW9uIGRlc2NyaWJlZCBpbiBodHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXplcm90b3VjaC0wOCNzZWN0aW9uLTQuMiwg
YnV0IHdlIGNvdWxkIGJpdGUgdGhlIGJ1bGxldCBhbmQgaW5zdGVhZCAqcmVwbGFjZSogdGhlIGZp
cnN0IGZvdXIgZW50cmllcyBsaXN0ZWQgKGhvc3RuYW1lICsgcG9ydCArIGFuY2hvciArIHNpZ25h
dHVyZSkgd2l0aCBhIHNpbmdsZSBUWFQgcmVjb3JkIGVuY29kaW5nIHRoZSBmb3VyIHZhbHVlcyBp
bnRvIGEgcGtjcyM3IHN0cnVjdHVyZS4gIFRoYXQgaXMsIHRoZXJlIHdvdWxkIGJlICpubyogU1JW
IHJlY29yZHMsLiAgQWx0ZXJuYXRpdmVseSwgd2UgY291bGQgYWxsb3cgZm9yIHJlZHVuZGFudCBk
YXRhIGluIFNSViByZWNvcmRzLCB3aGljaCB3b3VsZCBiZSBuaWNlIGZvciB3aGVuIHRoZSBkYXRh
IGlzIHVuc2lnbmVkLg0KDQpUaG91Z2h0cz8NCg0KS2VudA0KDQoNCkZyb206IE5ldGNvbmYgPG5l
dGNvbmYtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuIDxrd2F0c2Vu
QGp1bmlwZXIubmV0Pg0KRGF0ZTogV2VkbmVzZGF5LCBNYXkgMTEsIDIwMTYgYXQgNzoyMCBQTQ0K
VG86ICJuZXRjb25mQGlldGYub3JnIiA8bmV0Y29uZkBpZXRmLm9yZz4NClN1YmplY3Q6IFtOZXRj
b25mXSB6ZXJvdG91Y2gvMTM6IFNpZ25hdHVyZSBvdmVyIFlBTkcgZGF0YT8NCg0KaHR0cHM6Ly9n
aXRodWIuY29tL25ldGNvbmYtd2cvemVyby10b3VjaC9pc3N1ZXMvMTMNCg0KDQoNClNsaWRlICMx
MSBwcmVzZW50ZWQgZHVyaW5nIHRoZSBJRVRGIDk1IG1lZXRpbmcgc2FpZDoNCg0KPT09PT1TVEFS
VD09PT09DQpDdXJyZW50IHRleHQgc2F5cyB0aGF0IHRoZSBzaWduYXR1cmUgaXMgb3ZlciB0aGUg
ZGF0YSBpbiB3aGF0ZXZlciBmb3JtIGl04oCZcyBwcm92aWRlZCAoWE1MIG9yIEpTT04pDQoNClRo
aXMgd29ya3MgZ3JlYXQgZm9yIGFsbCBzb3VyY2VzIG9mIGJvb3RzdHJhcHBpbmcgZGF0YSBidXQs
IGZvciB0aGUgYm9vdHN0cmFwIHNlcnZlciwgcmVxdWlyZXMgdGhhdCBib3RoIHRoZSBub3J0aGJv
dW5kIGFwcGxpY2F0aW9uIGFuZCB0aGUgZGV2aWNlIGFjY2VzcyBzcGVjaWZpYyBVUkwgcmVzb3Vy
Y2VzOg0KL2lldGYtemVyb3RvdWNoLWJvb3RzdHJhcC1zZXJ2ZXI6ZGV2aWNlcy9kZXZpY2U9MTIz
NDU2L3JlZGlyZWN0LWluZm9ybWF0aW9uDQovaWV0Zi16ZXJvdG91Y2gtYm9vdHN0cmFwLXNlcnZl
cjpkZXZpY2VzL2RldmljZT0xMjM0NTYvYm9vdHN0cmFwLWluZm9ybWF0aW9uDQoNCkJ1dCB0aGlz
IGFwcHJvYWNoIGhhcyBpc3N1ZXM6DQoNCiAgKiAgIFNlcnZlciBNVVNUIE5PVCBjaGFuZ2UgaXRz
IGVuY29kaW5nIGluIGFueSB3YXkgYmV0d2VlbiB0aGUgdGltZSB0aGUgZGF0YSB3YXMgc2F2ZWQg
YW5kIHdoZW4gdGhlIGRldmljZSByZXRyaWV2ZXMgdGhlIGRhdGENCiAgKiAgIFRoZXNlIHR3byBy
ZXNvdXJjZXMgYXJlIHVuZGVyIGEgY2hvaWNlIG5vZGUsIGFuZCB0aGUgZGV2aWNlIGRvZXNu4oCZ
dCBrbm93IHVwIGZyb250IHdoaWNoIHdpbGwgYmUgcHJlc2VudC4NCiAgKiAgIEl0IGlzIGRlc2ly
YWJsZSBmb3IgZGV2aWNlIHRvIGp1c3QgZmV0Y2ggdGhlIHRvcC1sZXZlbCDigJxkZXZpY2XigJ0g
cmVzb3VyY2UsIHRvIGdldCBldmVyeXRoaW5nIGluIG9uZSByZXF1ZXN0DQoNCk9wdGlvbnM6DQoN
CiAgKiAgIEtlZXAgYXMgaXMgKGUuZy4sIGZvcmNlIGRldmljZSB0byB0cnkgYm90aCBVUkwgcmVz
b3VyY2VzKSAvLyB1cCB0byAzIHJvdW5kIHRyaXBzIGluc3RlYWQgb2YganVzdCBvbmUNCiAgKiAg
IERlZmluZSBhIGNhbm9uaWNhbCBmb3JtYXQgZm9yIFhNTCBhbmQgSlNPTiBlbmNvZGluZ3MgLy8g
Tm90IHN1cmUgaWYgdGhpcyBpcyBldmVuIHBvc3NpYmxl4oCmDQogICogICBEZWZpbmUgYW4gZW5j
b2RpbmctaW5kZXBlbmRlbnQgc2lnbmF0dXJlIGFsZ29yaXRobSAgICAgIC8vIHRyaWNreSB0byBk
ZWZpbmUsIG5vdCBlYXN5IHRvIGltcGxlbWVudA0KICAqICAgRW5jb2RlIGJvdGggcmVzb3VyY2Vz
IGluIGEgbGVhZiBoYXZpbmcgdHlwZSDigJxzdHJpbmfigJ0gICAgICAgLy8gZXZlbiB0aG91Z2gg
aXTigJlzIFlBTkctZW5jb2RlZCBkYXRhDQoNClRob3VnaHRzPw0KPT09PT1TVE9QPT09PT0NCg0K
SW4gdGhlIGRpc2N1c3Npb24gb24gdGhpcyBzbGlkZSwgSmVmZiBIYWFzIG5vdGVkIHRoYXQgUEtD
UyM5IGlzIHBvcHVsYXIgaW4gdGhlIElFVEYgYW5kIHRoYXQgaGUgZmVsdCB0aGF0IGNhbm9uaWNh
bGl6YXRpb24gbWlnaHQgYmUgYSByZXF1aXJlbWVudC4gQnV0IEtlbnQgbm90ZWQgdGhhdCBjYW5v
bmljYWxpemF0aW9uIGlzIHByYWN0aWNhbGx5IGltcG9zc2libGUgZ2l2ZW4gdGhhdCBYTUwvSlNP
TiBoYXMgbm8gZ3VhcmFudGVlZCBvcmRlcmluZyBvZiB0cmVlIG5vZGVzLg0KDQpJIGRvbid0IHRo
aW5rIHdlIGhhdmUgYSBnb29kIHNvbHV0aW9uIHlldC4uLg0KDQoNCg0KDQoNCktlbnQNCg0KDQo=

--_000_E013CD61F1C648F196C8E26DCD8E69DEjunipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg
MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K
CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250
LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EgTmV1ZSI7DQoJcGFu
b3NlLTE6MiAwIDUgMyAwIDAgMCAyIDAgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv
bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmlu
aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h
cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ
Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu
aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRp
b246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4t
dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p
bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFy
YWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJ
bWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsN
CgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6
MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnNwYW4uRW1haWxTdHls
ZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGli
cmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpl
eHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw
b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6
ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X
b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq
Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NTQ0NzU5Nzg4Ow0KCW1zby1saXN0LXRlbXBsYXRl
LWlkczoxOTAzNDkyNTM4O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDou
NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1
aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K
QGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt
c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250
LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5
OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN
Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA
bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s
ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250
LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYN
Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN
Cgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K
CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp
bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs
bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt
c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz
dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl
bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJl
ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp
emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlz
dC1pZDo4NzAwNzQ4NzY7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjkzODg5NDM5MDt9DQpAbGlz
dCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl
bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6
ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h
biI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu
c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6
bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4
dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw
LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh
bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu
MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1
aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7
fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt
c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt
Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2
ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv
gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp
b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw
dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls
eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTUyMjg2NDE4MTsNCgltc28t
bGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE4MzA0NTk1NCAtMTY2
NjgzOTU4NCA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5
ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLXRl
eHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMi41cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
O30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl
cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NTguNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz
dCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN
CgltYXJnaW4tbGVmdDo5NC41cHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwyOmxl
dmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTMwLjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K
QGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K
CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgltYXJnaW4tbGVmdDoxNjYuNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs
MjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCglt
YXJnaW4tbGVmdDoyMDIuNXB0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMjpsZXZl
bDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIzOC41cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs
aXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJbWFyZ2luLWxlZnQ6Mjc0LjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6
bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZl
bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJbWFy
Z2luLWxlZnQ6MzEwLjVwdDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDMNCgl7bXNv
LWxpc3QtaWQ6MjA3OTM5ODY2MDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10
ZW1wbGF0ZS1pZHM6MjAzMzQ3MzM3OCA0NjEwMTYxOTggNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3
MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3Qg
bDM6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6
bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjIu
NXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjU4LjVwdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6OTQuNXB0Ow0KCXRleHQtaW5k
ZW50Oi05LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEzMC41cHQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTY2LjVwdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6MjAyLjVwdDsNCgl0ZXh0LWluZGVu
dDotOS4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMzguNXB0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjI3NC41cHQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjMxMC41cHQ7DQoJdGV4dC1pbmRlbnQ6
LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206
MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0i
RU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRT
ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UcnlpbmcgdG8gbW92ZSB0aGlzIGRpc2N1c3Npb24g
Zm9yd2FyZC4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkFuIGlkZWEgbm90IGxpc3RlZCBi
ZWxvdyBpcyBmb3IgdGhlIOKAmHNpZ25hdHVyZeKAmSB2YWx1ZSAoaS5lLiBhIHBrY3MjNyBzdHJ1
Y3R1cmUpIHRvIGFsd2F5cyBlbnZlbG9wIHRoZSBib290c3RyYXBwaW5nIGRhdGEuJm5ic3A7IFRo
YXQgaXMsIHdl4oCZZCByZW1vdmUgdGhlIOKAnHJlZGlyZWN0LWluZm9ybWF0aW9u4oCdIGFuZCDi
gJxib290c3RyYXAtaW5mb3JtYXRpb27igJ0NCiBmcm9tIHRoZSBkYXRhLW1vZGVsIC8gQVBJLiZu
YnNwOyBNb3JlIHNwZWNpZmljYWxseTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp
YnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5PTEQ6PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw
dDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7IG1vZHVsZTogaWV0Zi16ZXJvdG91Y2gtYm9v
dHN0cmFwLXNlcnZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcm8gZGV2aWNlczxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcm8gZGV2aWNlKiBbdW5pcXVlLWlkXTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOy0tcm8gdW5pcXVlLWlk
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO3N0cmluZzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcm8g
KHR5cGUpPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8
Jm5ic3A7ICYjNDM7LS06KHJlZGlyZWN0LWluZm9ybWF0aW9uKTxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLS4uLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYj
NDM7LS06KGJvb3RzdHJhcC1pbmZvcm1hdGlvbik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLi4u
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1y
byBzaWduYXR1cmU/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJp
bmFyeSZuYnNwOyAvLyBhbiBvcHRpb25hbCBkZXRhY2hlZCBzaWduYXR1cmUgdXNpbmcgcGtjcyM3
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4uLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OkNhbGlicmkiPk5FVzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD
YWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJz
cDsgbW9kdWxlOiBpZXRmLXplcm90b3VjaC1ib290c3RyYXAtc2VydmVyPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw
dDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYj
NDM7LS1ybyBkZXZpY2VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ybyBk
ZXZpY2UqIFt1bmlxdWUtaWRdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyYjNDM7LS1ybyB1bmlxdWUtaWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgc3RyaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpD
b25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ybyBib290c3RyYXAtZGF0YSZuYnNwOyAmbmJzcDsm
bmJzcDtiaW5hcnkmbmJzcDsgLy8gYSBtYW5kYXRvcnkgcGtjcyM3IHN0cnVjdHVyZSB0aGF0IHdy
YXBzIHRoZSBzYW1lIGRhdGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+U29tZSBjb21tZW50czo8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTpDYWxpYnJpIj4xKSB0aGlzIEFQSSBpcyBmb3IgdGhlIGJvb3RzdHJhcCBz
ZXJ2ZXLigJlzIFNCSSAoc291dGhib3VuZCBhcGkpIGZhY2luZyBkZXZpY2VzOyBpdCBpcyByZWFk
LW9ubHkgYW5kIHRodXMgZG9lcyBub3QgaGF2ZSB0byBiZSB1c2VyLWZyaWVuZGx5LiZuYnNwOw0K
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+MikgVGhvdWdoIHRoZSB6ZXJvdG91Y2ggZHJhZnQg
c2F5cyB0aGUgbm9ydGhib3VuZCBpbnRlcmZhY2UgaXMgb3V0LW9mLXNjb3BlLCBpdCB3b3VsZCBz
ZWVtIHVzZWZ1bCBmb3IgYSBib290c3RyYXAgc2VydmVy4oCZcyBOQkkgdG8gdGFrZSBjYXJlIG9m
IGdlbmVyYXRpbmcgdGhlIHByaXZhdGUta2V5IGFuZCBDU1IgYW5kLCBsYXRlciwNCiBzaWduaW5n
IGJvb3RzdHJhcHBpbmcgZGF0YS4mbmJzcDsgVGhhdCBpcywgdGhlIE5CSSBmb3IgYSBib290c3Ry
YXAgc2VydmVyIG1pZ2h0IHJldGFpbiB0aGUg4oCcdXNlci1mcmllbmRseeKAnSBBUEkgZGVmaW5l
ZCBieSB0aGUgY3VycmVudCBZQU5HIG1vZGVsICh3aGVyZSB0aGUgdHJlZS1zdHJ1Y3R1cmUgZWxl
bWVudHMgYXJlIHdyaXRhYmxlKSB3aGlsZSBpbnRlcm5hbGx5IGhhdmluZyBsb2dpYyB0byBkeW5h
bWljYWxseSBjcmVhdGUgKHNpZ25lZCBvciB1bnNpZ25lZCkNCiBwa2NzIzcgc3RydWN0dXJlcyBm
b3IgZGV2aWNlcyB0byBvYnRhaW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy
aSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+MykgdGhpcyBh
cHByb2FjaCBoYXMgdGhlIGRvd25zaWRlIG9mIGZvcmNpbmcgYm9vdHN0cmFwIHNlcnZlcnMgdG8g
YWx3YXlzIHNlcnZlIHBrY3MjNyBzdHJ1Y3R1cmVzLCBldmVuIHdoZW4gdGhlIGRhdGEgaXMgdW5z
aWduZWQsIGFzIG9wcG9zZWQgdG8gb25seSB3aGVuIHNpZ25lZCBkYXRhIGlzIG5lZWRlZCAoYXMg
dGhlIGN1cnJlbnQNCiBkcmFmdCBoYXMgaXQpLiZuYnNwOyBQZXJoYXBzIG5vdCBhIGJpZyBkZWFs
LCBidXQgaXQgZG9lcyBpbmNyZWFzZSB1cGZyb250IGRldmVsb3BtZW50IGNvc3RzLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OkNhbGlicmkiPjQpIHRoaXMgYXBwcm9hY2ggaGFzIHRoZSB1cHNpZGUgb2YgZGVm
aW5pbmcgYSBuaWNlIGFydGlmYWN0IGVuY29kaW5nIGZvciBib3RoIHJlbW92YWJsZSBtZWRpYSBh
bmQgREhDUCwgYnV0IHdpdGggdGhlIGRvd25zaWRlIG9mIGNvbXBsaWNhdGluZyBETlMgbWFwcGlu
Z3MuJm5ic3A7IFNpbXBsZSBpcyB0aGUgc29sdXRpb24gZGVzY3JpYmVkDQogaW4gPGEgaHJlZj0i
aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi16ZXJvdG91Y2gt
MDgjc2VjdGlvbi00LjIiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt
bmV0Y29uZi16ZXJvdG91Y2gtMDgjc2VjdGlvbi00LjI8L2E+LCBidXQgd2UgY291bGQgYml0ZSB0
aGUgYnVsbGV0IGFuZCBpbnN0ZWFkICpyZXBsYWNlKiB0aGUgZmlyc3QgZm91ciBlbnRyaWVzIGxp
c3RlZCAoaG9zdG5hbWUgJiM0MzsgcG9ydCAmIzQzOyBhbmNob3IgJiM0Mzsgc2lnbmF0dXJlKSB3
aXRoIGEgc2luZ2xlIFRYVCByZWNvcmQgZW5jb2RpbmcgdGhlIGZvdXIgdmFsdWVzIGludG8gYSBw
a2NzIzcNCiBzdHJ1Y3R1cmUuJm5ic3A7IFRoYXQgaXMsIHRoZXJlIHdvdWxkIGJlICpubyogU1JW
IHJlY29yZHMsLiZuYnNwOyBBbHRlcm5hdGl2ZWx5LCB3ZSBjb3VsZCBhbGxvdyBmb3IgcmVkdW5k
YW50IGRhdGEgaW4gU1JWIHJlY29yZHMsIHdoaWNoIHdvdWxkIGJlIG5pY2UgZm9yIHdoZW4gdGhl
IGRhdGEgaXMgdW5zaWduZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhvdWdodHM/PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+S2VudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl
ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2Nv
bG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh
bGlicmk7Y29sb3I6YmxhY2siPk5ldGNvbmYgJmx0O25ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyZn
dDsgb24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuICZsdDtrd2F0c2VuQGp1bmlwZXIubmV0Jmd0Ozxi
cj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIE1heSAxMSwgMjAxNiBhdCA3OjIwIFBNPGJyPg0K
PGI+VG86IDwvYj4mcXVvdDtuZXRjb25mQGlldGYub3JnJnF1b3Q7ICZsdDtuZXRjb25mQGlldGYu
b3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bTmV0Y29uZl0gemVyb3RvdWNoLzEzOiBTaWdu
YXR1cmUgb3ZlciBZQU5HIGRhdGE/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFj
ayI+aHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvemVyby10b3VjaC9pc3N1ZXMvMTM8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJs
YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpD
YWxpYnJpO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7Ym94LXNpemluZzogYm9yZGVy
LWJveCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzMzMzMzMyI+U2xpZGUgIzExJm5ic3A7cHJlc2VudGVk
IGR1cmluZyB0aGUgSUVURiA5NSBtZWV0aW5nIHNhaWQ6PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t
Ym90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowaW47Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Eg
TmV1ZSZxdW90Oztjb2xvcjojMzMzMzMzIj49PT09PVNUQVJUPT09PT08YnI+DQpDdXJyZW50IHRl
eHQgc2F5cyB0aGF0IHRoZSBzaWduYXR1cmUgaXMgb3ZlciB0aGUgZGF0YSBpbiB3aGF0ZXZlciBm
b3JtIGl04oCZcyBwcm92aWRlZCAoWE1MIG9yIEpTT04pPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t
Ym90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowaW47Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Eg
TmV1ZSZxdW90Oztjb2xvcjojMzMzMzMzIj5UaGlzIHdvcmtzIGdyZWF0IGZvciBhbGwgc291cmNl
cyBvZiBib290c3RyYXBwaW5nIGRhdGEgYnV0LCBmb3IgdGhlIGJvb3RzdHJhcCBzZXJ2ZXIsIHJl
cXVpcmVzIHRoYXQgYm90aCB0aGUgbm9ydGhib3VuZCBhcHBsaWNhdGlvbiBhbmQgdGhlIGRldmlj
ZSBhY2Nlc3Mgc3BlY2lmaWMgVVJMIHJlc291cmNlczo8YnI+DQovaWV0Zi16ZXJvdG91Y2gtYm9v
dHN0cmFwLXNlcnZlcjpkZXZpY2VzL2RldmljZT0xMjM0NTYvcmVkaXJlY3QtaW5mb3JtYXRpb248
YnI+DQovaWV0Zi16ZXJvdG91Y2gtYm9vdHN0cmFwLXNlcnZlcjpkZXZpY2VzL2RldmljZT0xMjM0
NTYvYm9vdHN0cmFwLWluZm9ybWF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEy
LjBwdDttYXJnaW4tbGVmdDowaW47Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90
Oztjb2xvcjojMzMzMzMzIj5CdXQgdGhpcyBhcHByb2FjaCBoYXMgaXNzdWVzOjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0iY29sb3I6IzMzMzMzMzttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMTtib3gtc2l6aW5nOiBib3JkZXItYm94
Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl
dGljYSBOZXVlJnF1b3Q7Ij5TZXJ2ZXIgTVVTVCBOT1QgY2hhbmdlIGl0cyBlbmNvZGluZyBpbiBh
bnkgd2F5IGJldHdlZW4gdGhlIHRpbWUgdGhlIGRhdGEgd2FzIHNhdmVkIGFuZCB3aGVuIHRoZSBk
ZXZpY2UgcmV0cmlldmVzIHRoZSBkYXRhPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMzMzMzMzM7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7Ym94LXNp
emluZzogYm9yZGVyLWJveCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+VGhlc2UgdHdvIHJlc291cmNlcyBhcmUg
dW5kZXIgYSBjaG9pY2Ugbm9kZSwgYW5kIHRoZSBkZXZpY2UgZG9lc27igJl0IGtub3cgdXAgZnJv
bnQgd2hpY2ggd2lsbCBiZSBwcmVzZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMzMzMzO21zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xO2JveC1z
aXppbmc6IGJvcmRlci1ib3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPkl0IGlzIGRlc2lyYWJsZSBmb3IgZGV2
aWNlIHRvIGp1c3QgZmV0Y2ggdGhlIHRvcC1sZXZlbCDigJxkZXZpY2XigJ0gcmVzb3VyY2UsIHRv
IGdldCBldmVyeXRoaW5nIGluIG9uZSByZXF1ZXN0PG86cD48L286cD48L3NwYW4+PC9saT48L3Vs
Pg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJn
aW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowaW47Ym94LXNpemluZzogYm9yZGVyLWJveCI+
DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EgTmV1ZSZxdW90Oztjb2xvcjojMzMzMzMzIj5PcHRpb25zOjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6
IzMzMzMzMzttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMjtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVl
JnF1b3Q7Ij5LZWVwIGFzIGlzIChlLmcuLCBmb3JjZSBkZXZpY2UgdG8gdHJ5IGJvdGggVVJMIHJl
c291cmNlcykgLy8gdXAgdG8gMyByb3VuZCB0cmlwcyBpbnN0ZWFkIG9mIGp1c3Qgb25lPG86cD48
L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMzMzMz
MzM7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNv
LWxpc3Q6bDEgbGV2ZWwxIGxmbzI7Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90
OyI+RGVmaW5lIGEgY2Fub25pY2FsIGZvcm1hdCBmb3IgWE1MIGFuZCBKU09OIGVuY29kaW5ncyAv
LyBOb3Qgc3VyZSBpZiB0aGlzIGlzIGV2ZW4gcG9zc2libGXigKY8bzpwPjwvbzpwPjwvc3Bhbj48
L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZl
bDEgbGZvMjtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5EZWZpbmUgYW4g
ZW5jb2RpbmctaW5kZXBlbmRlbnQgc2lnbmF0dXJlIGFsZ29yaXRobSAmbmJzcDsgJm5ic3A7ICZu
YnNwOy8vIHRyaWNreSB0byBkZWZpbmUsIG5vdCBlYXN5IHRvIGltcGxlbWVudDxvOnA+PC9vOnA+
PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMzMzMzO21z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0
OmwxIGxldmVsMSBsZm8yO2JveC1zaXppbmc6IGJvcmRlci1ib3giPg0KPHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPkVu
Y29kZSBib3RoIHJlc291cmNlcyBpbiBhIGxlYWYgaGF2aW5nIHR5cGUg4oCcc3RyaW5n4oCdICZu
YnNwOyAmbmJzcDsgJm5ic3A7IC8vIGV2ZW4gdGhvdWdoIGl04oCZcyBZQU5HLWVuY29kZWQgZGF0
YTxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6
MGluO2JveC1zaXppbmc6IGJvcmRlci1ib3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzMzMzMzMyI+
VGhvdWdodHM/PGJyPg0KPT09PT1TVE9QPT09PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0
b206MTIuMHB0O21hcmdpbi1sZWZ0OjBpbjtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVl
JnF1b3Q7O2NvbG9yOiMzMzMzMzMiPkluIHRoZSBkaXNjdXNzaW9uIG9uIHRoaXMgc2xpZGUsIEpl
ZmYgSGFhcyBub3RlZCB0aGF0IFBLQ1MjOSBpcyBwb3B1bGFyIGluIHRoZSBJRVRGIGFuZCB0aGF0
IGhlIGZlbHQgdGhhdCBjYW5vbmljYWxpemF0aW9uIG1pZ2h0IGJlIGEgcmVxdWlyZW1lbnQuIEJ1
dCBLZW50IG5vdGVkIHRoYXQgY2Fub25pY2FsaXphdGlvbg0KIGlzIHByYWN0aWNhbGx5IGltcG9z
c2libGUgZ2l2ZW4gdGhhdCBYTUwvSlNPTiBoYXMgbm8gZ3VhcmFudGVlZCBvcmRlcmluZyBvZiB0
cmVlIG5vZGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjBp
bjtib3gtc2l6aW5nOiBib3JkZXItYm94Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMzMzMzMzIj5JIGRv
bid0IHRoaW5rIHdlIGhhdmUgYSBnb29kIHNvbHV0aW9uIHlldC4uLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjBpbjtib3gtc2l6aW5nOiBib3JkZXItYm94Ij48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Eg
TmV1ZSZxdW90Oztjb2xvcjojMzMzMzMzIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBzdHlsZT0ibWFyZ2luLXRvcDowaW47Ym94LXNpemluZzogYm9yZGVyLWJveCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVv
dDs7Y29sb3I6IzMzMzMzMyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9
Im1hcmdpbi10b3A6MGluO2JveC1zaXppbmc6IGJvcmRlci1ib3giPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9y
OiMzMzMzMzMiPktlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRv
cDowaW47Ym94LXNpemluZzogYm9yZGVyLWJveCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzMzMzMzMyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_E013CD61F1C648F196C8E26DCD8E69DEjunipernet_--


From nobody Wed Jun 29 15:53:35 2016
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 1185912D8ED for ; Wed, 29 Jun 2016 15:53:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 i9d96Cc4L0Cx for ; Wed, 29 Jun 2016 15:53:31 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0124.outbound.protection.outlook.com [65.55.169.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DB5D12D58D for ; Wed, 29 Jun 2016 15:53:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VGkRxSqV3uXVnB7ndu7n5qmfQzB+nhnMvIC8g8Tfj0Q=; b=Tq+T8xKn93eksksFmQ/mr+Ull8lKgyNpCmIypA77Y8MGcuNspf4nSVooIgww6QLSNpeQVAVqaunPRLIVDm4ieucMmFdd4lPPersaIz64ZV8PSAciK35xH1G8nS1P/PFZoNR5QX7ruAL94lK594UfEax4AngY/tTFkg+gCAc73Vw=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1451.namprd05.prod.outlook.com (10.160.149.12) with Microsoft SMTP Server (TLS) id 15.1.528.16; Wed, 29 Jun 2016 22:53:29 +0000
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0528.017; Wed, 29 Jun 2016 22:53:29 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: [Netconf] zerotouch/12: How to commit config? Merge/replace?
Thread-Index: AQHR0lkNTjORHFXcL06wK5dz8frwDA==
Date: Wed, 29 Jun 2016 22:53:29 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.17.0.160611
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.13]
x-ms-office365-filtering-correlation-id: 296e3dc3-a184-4777-29e7-08d3a0703002
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1451; 6:P5VIckvesauzUy/zrTP0l7l1LrxmtBiy0BEcgRcXVTxccueWNmTTOu6Vu9vx1hFtg/W7HP+MF3cv43zIeFSbCQKNAWwoBL2xoWgHHP21Nk2fQeBXvKC3B+5hsUnq+MDu/1bWwRQiVcK8Xt8c1vpCqRr3qoh43WgaQVMagVhRb38WqTkHfxFxpZstQmBq5zvzseT7WmKZSmAp0h/k4vZthcguFpZrHbDrPl8GTLbzry3vdDMNWJashG7eivghGn5IYWLPAV92z5Ka8Rqy1z0UFNmk63+V7xhFmkahJ9wiJsXprVy0xUBaFecjmL6dI4QclZkCHYKDz1ZHp2UH7CR/eg==; 5:ew9E2JMVrgUu9cNMgwQ68oEYIXGU+7kjpEcB377yoXDdcfaU/mYhFq9fHF/19gY18mS6b2RtxudNogn5J/DrBYqjK4bxtTLqk5O7PkaK1VIXUBKrJmZWAxXr9+MEEpBPPVCpPaGIZBGR4iluSl/TrA==; 24:oW/Wjckx7yQjE/Vu5AwW1wBL1PG2hR0q+O2FrthZPqn37X8psOvmYBvNMYfvVIj/JHAmz7rGbh82iLGyTnmJ+BPU6Js+FIYKLqEMJ8QgHfI=; 7:OWisWpyP11wFe8qD6xsYEKzbrrbM0KH+xB+5MDOlc0N1hp+YEnpCqhQfQ/rH4TvkhvYIMqWjSXvttyK3OFMAxXJx7wl53wK4NhOSO9uOZfJWnQZisNbwf2pAMtkjeq3HEKSpHH8OnnUDXbjRWJY48YzdYqVcvA4czrhXlZnMe0yYR3oj5IDNLFfq40RPhvvaW3oYsm62XzU/BCNbAGzIZJ1lAUpHI7YGozLdb85TEqncvyMuC1xSlR2NNzXq/2cA
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1451;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(166708455590820)(138986009662008)(788757137089)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026);  SRVR:CY1PR0501MB1451; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1451; 
x-forefront-prvs: 09888BC01D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(51444003)(189002)(377454003)(199003)(36756003)(5002640100001)(54356999)(19580395003)(15975445007)(5640700001)(77096005)(92566002)(122556002)(99286002)(6116002)(8676002)(2900100001)(3846002)(1730700003)(19625215002)(2906002)(450100001)(102836003)(3660700001)(19580405001)(4001350100001)(86362001)(10400500002)(101416001)(83716003)(81156014)(66066001)(97736004)(586003)(83506001)(189998001)(107886002)(82746002)(33656002)(8936002)(7846002)(106116001)(106356001)(3280700002)(105586002)(11100500001)(2351001)(68736007)(87936001)(7736002)(50986999)(16236675004)(110136002)(81166006)(19300405004)(2501003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1451; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_B0A9F6E4964F46F18DA60D294BD02998junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2016 22:53:29.0910 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1451
Archived-At: 
Subject: Re: [Netconf] zerotouch/12: How to commit config? Merge/replace?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2016 22:53:34 -0000

--_000_B0A9F6E4964F46F18DA60D294BD02998junipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpUcnlpbmcgdG8gbW92ZSB0aGlzIGRpc2N1c3Npb24gZm9yd2FyZC4NCg0KSeKAmW0gc3RpbGwg
cHJlZmVyIChiKSBmb3IgdGhlIHJlYXNvbnMgbGlzdGVkIGJlbG93LCBidXQgaXQgbWF5IGJlIHBv
c3NpYmxlIHRvIGRvIHNvbWV0aGluZyBpbiBiZXR3ZWVuIChiKSBhbmQgKGMpLiAgSW4gcGFydGlj
dWxhciwgYSB0b3AtbGV2ZWwgZmxhZyBjb3VsZCBhbGxvdyBmb3IgZWRpdC1jb25maWcgYW5kIHlh
bmctcGF0Y2ggb3B0aW9ucyBhbHNvLg0KDQpPTEQ6DQogICAgICAgICAgICAgICstLTooYm9vdHN0
cmFwLWluZm9ybWF0aW9uKQ0KICAgICAgICAgICAgICAgICArLS1ybyBib290c3RyYXAtaW5mb3Jt
YXRpb24NCiAgICAgICAgICAgICAgICAgICAgKy0tcm8gYm9vdC1pbWFnZQ0KICAgICAgICAgICAg
ICAgICAgICB8ICAuLi4NCiAgICAgICAgICAgICAgICAgICAgKy0tcm8gY29uZmlndXJhdGlvbg0K
ICAgICAgICAgICAgICAgICAgICArLS1ybyBzY3JpcHQ/ICAgICAgICAgIHN0cmluZw0KDQpORVc6
DQogICAgICAgICAgICAgICstLTooYm9vdHN0cmFwLWluZm9ybWF0aW9uKQ0KICAgICAgICAgICAg
ICAgICArLS1ybyBib290c3RyYXAtaW5mb3JtYXRpb24NCiAgICAgICAgICAgICAgICAgICAgKy0t
cm8gYm9vdC1pbWFnZQ0KICAgICAgICAgICAgICAgICAgICB8ICAuLi4NCiAgICAgICAgICAgICAg
ICAgICAgKy0tcm8gY29uZmlnLWhhbmRsaW5nICBlbnVtIHtyZXBsYWNlLCBtZXJnZSwgZWRpdC1j
b25maWcsIHlhbmctcGF0Y2h9DQogICAgICAgICAgICAgICAgICAgICstLXJvIGNvbmZpZ3VyYXRp
b24NCiAgICAgICAgICAgICAgICAgICArLS1ybyBzY3JpcHQ/ICAgICAgICAgIHN0cmluZw0KDQpU
aG91Z2h0cz8gIC0gaXMgaXQgd29ydGggaXQ/DQoNClRoYW5rcywNCktlbnQNCg0KDQpGcm9tOiBO
ZXRjb25mIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBLZW50IFdhdHNl
biA8a3dhdHNlbkBqdW5pcGVyLm5ldD4NCkRhdGU6IFdlZG5lc2RheSwgTWF5IDExLCAyMDE2IGF0
IDc6MDMgUE0NClRvOiAibmV0Y29uZkBpZXRmLm9yZyIgPG5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJq
ZWN0OiBbTmV0Y29uZl0gemVyb3RvdWNoLzEyOiBIb3cgdG8gY29tbWl0IGNvbmZpZz8gTWVyZ2Uv
cmVwbGFjZT8NCg0KaHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvemVyby10b3VjaC9pc3N1
ZXMvMTINCg0KDQpTbGlkZSAxMCBmcm9tIHRoZSB6ZXJvIHRvdWNoIHByZXNvIEAgOTUgaGFkOg0K
DQogIE9wdGlvbnM6DQpBLiBIYXJkY29kZSDigJ1yZXBsYWNl4oCdICAgICAgICAgICAgICAgICAg
ICAgICAgLy8gYWx3YXlzIHdvcmtzLCBidXQgbGFyZ2UgaW4gc2l6ZQ0KQi4gVXNlIGEgdG9wLWxl
dmVsIGZsYWcgICAgICAgICAgICAgICAgICAgICAgICAgLy8gbGV0IGRlcGxveW1lbnRzIGRlY2lk
ZQ0KQy4gVXNlIGVkaXQtY29uZmlnIG9yIHlhbmctcGF0Y2g/ICAgICAvLyBpcyB0aGlzIG11Y2gg
Z3JhbnVsYXJpdHkgbmVlZGVkPw0KDQpUaGUgbWludXRlcyBub3RlIHRoYXQgUmljayBUYXlsb3Ig
cHJlZmVycyB0aGUgbGFzdCBvcHRpb24sIHN0YXRpbmcgdGhhdCB0aGUgY29uZmlndXJhdGlvbiBj
YW4gYmUgYmlnLg0KDQpCdXQgbGV0J3MgY29uc2lkZXIgb3B0aW9uIChiKSBpbiB0aGUgY29udGV4
dCBvZiB0aGUgY29uZmlnIGJlaW5nIGJpZy4gICBJZiB0aGUgdG9wLWxldmVsIGZsYWcgaXMgJ21l
cmdlJyBhbmQgdGhlIGNvbmZpZyBpcyBodWdlLCB0aGVuIGl0J3MgZWZmZWN0aXZlbHkgdGhlIHNh
bWUgYXMgPGVkaXQtY29uZmlnPi4gICBPdGhlcndpc2UsIGlmIHRoZSB0b3AtbGV2ZWwgZmxhZyBp
cyAncmVwbGFjZScgYW5kIHRoZSBjb25maWcgaXMgaHVnZSwgdGhlbiB0aGUgYW1vdW50IG9mIGZh
Y3RvcnktZGVmYXVsdCBjb25maWcgdGhhdCBnZXRzIHJlcGxhY2VkIGlzIHJlbGF0aXZlbHkgc21h
bGwuICBTbyBpdCBzZWVtcyB0aGF0IG9wdGlvbiAoYikgaXMgZXF1YWxseSB2aWFibGUgaW4gdGhl
IGNvbnRleHQgb2YgaHVnZSBjb25maWdzLg0KDQpJIHBlcnNvbmFsbHkgcHJlZmVyIG9wdGlvbiAo
YiksIGJlY2F1c2UgSSB0aGluayB0aGF0IGl0J3MgYmV0dGVyIGluIHRoaXMgY2FzZSB0byBub3Qg
cmVxdWlyZSB0aGUgY2xpZW50IHRvIGhhdmUgdG8gdW5kZXJzdGFuZCBlZGl0LWNvbmZpZyBvciB5
YW5nLXBhdGNoLiAgUmVjYWxsLCB0aGUgZGV2aWNlIGlzIHRoZSBIVFRQIGNsaWVudCwgYW5kIHRo
ZSBsb2dpYyB0aGF0IGltcGxlbWVudHMgdGhlIGJvb3RzdHJhcHBpbmcgY29kZSBtYXkgYmUgZGlm
ZmVyZW50IHRoYW4gdGhlIGxvZ2ljIHRoYXQga25vd3MgaG93IHRvIHByb2Nlc3MgTkVUQ09ORiBv
ciBSRVNUQ09ORiwgYXQgbGVhc3QgdGhpcyBob3cgSSd2ZSBzZWVuIGl0IGltcGxlbWVudGVkLi4u
DQoNClRob3VnaHRzPw0KDQpLZW50DQoNCg==

--_000_B0A9F6E4964F46F18DA60D294BD02998junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE
ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K
CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0
Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl
cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1k
ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93
ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNv
cmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1l
OmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl
cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9
DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUt
bmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1z
b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw
LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu
OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk
U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBs
YW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i
V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OkNhbGlicmkiPlRyeWluZyB0byBtb3ZlIHRoaXMgZGlzY3Vzc2lvbiBmb3J3YXJk
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPknigJltIHN0aWxsIHByZWZlciAoYikgZm9yIHRo
ZSByZWFzb25zIGxpc3RlZCBiZWxvdywgYnV0IGl0IG1heSBiZSBwb3NzaWJsZSB0byBkbyBzb21l
dGhpbmcgaW4gYmV0d2VlbiAoYikgYW5kIChjKS4mbmJzcDsgSW4gcGFydGljdWxhciwgYSB0b3At
bGV2ZWwgZmxhZyBjb3VsZCBhbGxvdyBmb3IgZWRpdC1jb25maWcgYW5kIHlhbmctcGF0Y2gNCiBv
cHRpb25zIGFsc28uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+T0xEOjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7JiM0MzstLToo
Ym9vdHN0cmFwLWluZm9ybWF0aW9uKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv
bGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JiM0MzstLXJvIGJv
b3RzdHJhcC1pbmZvcm1hdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7JiM0MzstLXJvIGJvb3QtaW1hZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25z
b2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwO3wmbmJzcDsgLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmIzQzOy0tcm8gY29uZmlndXJhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNv
bnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7JiM0MzstLXJvIHNjcmlwdD8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3RyaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+
TkVXOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5i
c3A7Jm5ic3A7JiM0MzstLTooYm9vdHN0cmFwLWluZm9ybWF0aW9uKTxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7JiM0MzstLXJvIGJvb3RzdHJhcC1pbmZvcm1hdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JiM0MzstLXJvIGJvb3QtaW1hZ2U8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsgLi4uPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOy0tcm8gY29uZmlnLWhhbmRsaW5nJm5ic3A7IGVudW0g
e3JlcGxhY2UsIG1lcmdlLCBlZGl0LWNvbmZpZywgeWFuZy1wYXRjaH08bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7LS1ybyBjb25maWd1cmF0aW9uPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7LS1ybyBzY3JpcHQ/Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN0cmluZzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRob3VnaHRzPyZuYnNwOyAtIGlzIGl0IHdvcnRoIGl0Pzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTpDYWxpYnJpIj5LZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp
ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2si
PkZyb206IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xv
cjpibGFjayI+TmV0Y29uZiAmbHQ7bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhh
bGYgb2YgS2VudCBXYXRzZW4gJmx0O2t3YXRzZW5AanVuaXBlci5uZXQmZ3Q7PGJyPg0KPGI+RGF0
ZTogPC9iPldlZG5lc2RheSwgTWF5IDExLCAyMDE2IGF0IDc6MDMgUE08YnI+DQo8Yj5UbzogPC9i
PiZxdW90O25ldGNvbmZAaWV0Zi5vcmcmcXVvdDsgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJy
Pg0KPGI+U3ViamVjdDogPC9iPltOZXRjb25mXSB6ZXJvdG91Y2gvMTI6IEhvdyB0byBjb21taXQg
Y29uZmlnPyBNZXJnZS9yZXBsYWNlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJpO2Nv
bG9yOmJsYWNrIj5odHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy96ZXJvLXRvdWNoL2lzc3Vl
cy8xMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7
Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPlNsaWRlIDEwIGZyb20g
dGhlIHplcm8gdG91Y2ggcHJlc28gQCA5NSBoYWQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+Jm5i
c3A7IE9wdGlvbnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6
Q2FsaWJyaTtjb2xvcjpibGFjayI+QS4gSGFyZGNvZGUg4oCdcmVwbGFjZeKAnSAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOy8vIGFsd2F5cyB3b3JrcywgYnV0IGxhcmdlIGluIHNpemU8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNr
Ij5CLiBVc2UgYSB0b3AtbGV2ZWwgZmxhZyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNw
Oy8vIGxldCBkZXBsb3ltZW50cyBkZWNpZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw
dDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5DLiBVc2UgZWRpdC1jb25maWcgb3Ig
eWFuZy1wYXRjaD8gJm5ic3A7ICZuYnNwOyZuYnNwOy8vIGlzIHRoaXMgbXVjaCBncmFudWxhcml0
eSBuZWVkZWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2Fs
aWJyaTtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7
Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+VGhlIG1pbnV0ZXMgbm90ZSB0aGF0IFJp
Y2sgVGF5bG9yIHByZWZlcnMgdGhlIGxhc3Qgb3B0aW9uLCBzdGF0aW5nIHRoYXQgdGhlIGNvbmZp
Z3VyYXRpb24gY2FuIGJlIGJpZy4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41
cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+QnV0IGxl
dCdzIGNvbnNpZGVyIG9wdGlvbiAoYikgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGNvbmZpZyBiZWlu
ZyBiaWcuICZuYnNwOyBJZiB0aGUgdG9wLWxldmVsIGZsYWcgaXMgJ21lcmdlJyBhbmQgdGhlIGNv
bmZpZyBpcyBodWdlLCB0aGVuIGl0J3MgZWZmZWN0aXZlbHkgdGhlIHNhbWUgYXMgJmx0O2VkaXQt
Y29uZmlnJmd0Oy4NCiAmbmJzcDsgT3RoZXJ3aXNlLCBpZiB0aGUgdG9wLWxldmVsIGZsYWcgaXMg
J3JlcGxhY2UnIGFuZCB0aGUgY29uZmlnIGlzIGh1Z2UsIHRoZW4gdGhlIGFtb3VudCBvZiBmYWN0
b3J5LWRlZmF1bHQgY29uZmlnIHRoYXQgZ2V0cyByZXBsYWNlZCBpcyByZWxhdGl2ZWx5IHNtYWxs
LiAmbmJzcDtTbyBpdCBzZWVtcyB0aGF0IG9wdGlvbiAoYikgaXMgZXF1YWxseSB2aWFibGUgaW4g
dGhlIGNvbnRleHQgb2YgaHVnZSBjb25maWdzLiAmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9y
OmJsYWNrIj5JIHBlcnNvbmFsbHkgcHJlZmVyIG9wdGlvbiAoYiksIGJlY2F1c2UgSSB0aGluayB0
aGF0IGl0J3MgYmV0dGVyIGluIHRoaXMgY2FzZSB0byBub3QgcmVxdWlyZSB0aGUgY2xpZW50IHRv
IGhhdmUgdG8gdW5kZXJzdGFuZCBlZGl0LWNvbmZpZyBvciB5YW5nLXBhdGNoLiAmbmJzcDtSZWNh
bGwsIHRoZSBkZXZpY2UNCiBpcyB0aGUgSFRUUCBjbGllbnQsIGFuZCB0aGUgbG9naWMgdGhhdCBp
bXBsZW1lbnRzIHRoZSBib290c3RyYXBwaW5nIGNvZGUgbWF5IGJlIGRpZmZlcmVudCB0aGFuIHRo
ZSBsb2dpYyB0aGF0IGtub3dzIGhvdyB0byBwcm9jZXNzIE5FVENPTkYgb3IgUkVTVENPTkYsIGF0
IGxlYXN0IHRoaXMgaG93IEkndmUgc2VlbiBpdCBpbXBsZW1lbnRlZC4uLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29s
b3I6YmxhY2siPlRob3VnaHRzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPktlbnQ8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6
YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_B0A9F6E4964F46F18DA60D294BD02998junipernet_--


From nobody Wed Jun 29 16:11:13 2016
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 8E5D012D92A for ; Wed, 29 Jun 2016 16:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 Y0BZVvk6_tY8 for ; Wed, 29 Jun 2016 16:11:08 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0140.outbound.protection.outlook.com [207.46.100.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CA2412D8DC for ; Wed, 29 Jun 2016 16:11:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rMN/kCfREKsgeGTwnkpQEzl5KomUawJpHe2yUYp50rw=; b=bO+lC/2iaX/hHNd1boncvrSaT+j/4jzNrzpvjGv2XCQ5PmWsRXHZ8rO4FDHiYKvdRhArKjYpxxchlyQZ0HYU3Rsswl49zuosam6FFH2gZq86lFQz4WV7WO4zIF1iyBWJczS+pyYW4ifLAh0DIwYHzSCD7ah6ZNyFJvgKoFzNepg=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1451.namprd05.prod.outlook.com (10.160.149.12) with Microsoft SMTP Server (TLS) id 15.1.528.16; Wed, 29 Jun 2016 23:11:06 +0000
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0528.017; Wed, 29 Jun 2016 23:11:07 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: =?utf-8?B?W05ldGNvbmZdIHplcm90b3VjaC8xMTogT3duZXJzaGlwIFZvdWNoZXIg4oCT?= =?utf-8?Q?_formally_define=3F?=
Thread-Index: AQHR0luDrStCCWc4KU2Ev5oCeFbVpg==
Date: Wed, 29 Jun 2016 23:11:06 +0000
Message-ID: <15A40A51-6FBE-4952-98ED-C92EBDFB6373@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.17.0.160611
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.13]
x-ms-office365-filtering-correlation-id: 43217fd1-3245-4c31-7e23-08d3a072a689
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1451; 6:fqw7NCGeg9Q2A0lZBR2rStmhrmr/NOKf35MdWTAJBDOEsJ8BUsdO/P7m7QJELonKw/6+2uG75VClp5MckRwrTZeawa3GpaaJD+xqLdqtdqsChK/LpXkMCl4UHqp1S328Up4G48ho4tQ3imA+KcdR2iikTZWBzn+fFg88g5Y9iJX4Q/mhvjcDJIkDgWDhU529+Ow1qPxg3VweM/wB/5imTRKJ94MOvk82eZq2sIeRJJO7XIlKH3M3fHVrH/fqE0Y2ce/bwS3NlZEXKMk3bP80ZKKmjV3Cdv/HBBr7A6bwWIXqdgUaXg6kDI6P3fwLnM5amVgSdpMpqR1SU4aNAWwoNA==; 5:9BVlMSVu00dstzfzp8cRsNwEp+LAIdjBnSYi1CJHip4dVU+lFsR8D68nFZRZgb8/jFiQM+/Vyt+p+rqPPChWVZU4EfvfJLfDCWej7NoEXMYgd5Y09lkiI7fE1B/azZiCpc8J56KwJXg4oKfW9Ss2/g==; 24:S0X4E3LcXR5+7+6L3WYsa3gj8wTqOsUgAlQHBbzdrbLi9Lf+jkgKBYXKr0MOR8YX0j+tieaoTUhDrLIRosEAZuRBH9dzg6HHbVQz4WqMcSE=; 7:KTYVXH/3GEnXKp9hCCRfkX4LvEQHZY1zM+12dHYG3xGzV6Em2n4NRR/0Aha8FFQl9bu1opNB0GSLoW3SeI7pO4BDmgP6qfzzdpCjpI+x1q+s/+pgeBoMytDQgYO+CRiTKnIejDPNjXhcJONX6Y0VZmnmiOb80Ai6kqW0gaBTm4nMWqArbw9bR1Ar69Mb+RlNL49aB/Wv96sQ+G+asRkhVwuYvPTAwEmH8GXxeD8HlVCTxCdSqsJPBm2aLnTIog1c
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1451;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(60795455431006)(166708455590820)(138986009662008)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026);  SRVR:CY1PR0501MB1451; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1451; 
x-forefront-prvs: 09888BC01D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(199003)(8936002)(7846002)(81156014)(83716003)(97736004)(66066001)(561944003)(33656002)(82746002)(107886002)(586003)(83506001)(189998001)(2501003)(19300405004)(87936001)(2351001)(68736007)(7736002)(106116001)(105586002)(106356001)(3280700002)(110136002)(81166006)(50986999)(16236675004)(2900100001)(99286002)(122556002)(6116002)(3846002)(19580395003)(54356999)(5002640100001)(36756003)(77096005)(92566002)(15975445007)(5640700001)(10400500002)(4001350100001)(86362001)(101416001)(19580405001)(2906002)(1730700003)(19625215002)(3660700001)(450100001)(102836003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1451; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_15A40A516FBE495298EDC92EBDFB6373junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2016 23:11:06.8845 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1451
Archived-At: 
Subject: Re: [Netconf] =?utf-8?q?zerotouch/11=3A_Ownership_Voucher_=E2=80=93_f?= =?utf-8?q?ormally_define=3F?=
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2016 23:11:10 -0000

--_000_15A40A516FBE495298EDC92EBDFB6373junipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpVcGRhdGU6IFRoaXMgaXNzdWUgaGFzIGJlZW4gZGlzY3Vzc2VkIHdpdGggdGhlIEFOSU1BIGZv
bGtzLiAgVGhlIGN1cnJlbnQgcHJvcG9zYWwgaXM6DQoNCk9MRDoNCiAgIG1vZHVsZTogaWV0Zi16
ZXJvdG91Y2gtb3duZXJzaGlwLXZvdWNoZXINCiAgICAgICstLXJ3IHZvdWNoZXINCiAgICAgICAg
ICstLXJ3IG93bmVyLWlkICAgICAgc3RyaW5nDQogICAgICAgICArLS1ydyB1bmlxdWUtaWQqICAg
IHN0cmluZw0KICAgICAgICAgKy0tcncgY3JlYXRlZC1vbiAgICB5YW5nOmRhdGUtYW5kLXRpbWUN
CiAgICAgICAgICstLXJ3IGV4cGlyZXMtb24/ICAgeWFuZzpkYXRlLWFuZC10aW1lDQogICAgICAg
ICArLS1ydyBzaWduYXR1cmUgICAgIHN0cmluZw0KDQpORVc6DQogICAgIG1vZHVsZTogaWV0Zi16
ZXJvdG91Y2gtb3duZXJzaGlwLXZvdWNoZXINCiAgICAgICstLXJ3IHZvdWNoZXINCiAgICAgICAg
ICstLXJ3IG93bmVyLWlkICAgICAgICAgICBzdHJpbmcNCiAgICAgICAgICstLXJ3IHVuaXF1ZS1p
ZCogICAgICAgICBzdHJpbmcgICAgICAgICAgICAgICAgICAgIC8vIEFOSU1BIHdvdWxkIGFsd2F5
cyBoYXZlIGp1c3QgMSBsaXN0IGVudHJ5DQogICAgICAgICArLS1ydyBub25jZT8gICAgICAgICAg
ICAgdW5pdDY0ICAgICAgICAgICAgICAgICAgICAvLyBvbmx5IEFOSU1BIHdvdWxkIHVzZSB0aGlz
IG5vbmNlIGZpZWxkDQogICAgICAgICArLS1ydyB2ZXJpZmljYXRpb24tdHlwZSAgZW51bSB7dmVy
aWZpZWQsIGxvZ2dlZCkgICAvLyBORVRDT05GIHdvdWxkIGFsd2F5cyBiZSBWRVJJRklFRA0KICAg
ICAgICAgKy0tcncgY3JlYXRlZC1vbiAgICAgICAgIHlhbmc6ZGF0ZS1hbmQtdGltZQ0KICAgICAg
ICAgKy0tcncgZXhwaXJlcy1vbj8gICAgICAgIHlhbmc6ZGF0ZS1hbmQtdGltZQ0KDQpBcyBjb21w
YXJlZCB0byBBTklNQeKAmXMgY3VycmVudCDigJh2b3VjaGVy4oCZIGZvcm1hdDoNCiAgIHsNCiAg
ICJub25jZSI6Ijw2NGJpdCBub25jZSB2YWx1ZT4iLA0KICAgInNlcmlhbG51bWJlciI6IjxzdHJp
bmcgdmFsdWU+IiwgICAgLS0+IHVuaXF1ZS1pZA0KICAgImRvbWFpbklEIjo8ZG9tYWluSUQgdmFs
dWU+ICAgICAgICAtLT4gb3duZXItaWQNCiAgICB9DQoNCg0KVGhpcyBvbmUgbGlrZWx5IG5lZWRz
IG1vcmUgZGlzY3Vzc2lvbiwgYnV0IHdvdWxkIGxvdmUgdG8gaGVhciBvcGluaW9ucyBub3cuLi4N
Cg0KS2VudA0KDQoNCg0KRnJvbTogTmV0Y29uZiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPiBv
biBiZWhhbGYgb2YgS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+DQpEYXRlOiBXZWRu
ZXNkYXksIE1heSAxMSwgMjAxNiBhdCA2OjU3IFBNDQpUbzogIm5ldGNvbmZAaWV0Zi5vcmciIDxu
ZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogW05ldGNvbmZdIHplcm90b3VjaC8xMTogT3duZXJz
aGlwIFZvdWNoZXIg4oCTIGZvcm1hbGx5IGRlZmluZT8NCg0KDQpodHRwczovL2dpdGh1Yi5jb20v
bmV0Y29uZi13Zy96ZXJvLXRvdWNoL2lzc3Vlcy8xMQ0KDQpUaGlzIGlzc3VlIHJlZ2FyZHMgdGhl
IGZvcm1hdCBvZiB0aGUgb3duZXJzaGlwIHZvdWNoZXIuICBUaGUgY3VycmVudCBkcmFmdCBkZWZp
bmVzIHRoZSBvd25lcnNoaXAgdm91Y2hlciBhcyBhIHZlbmRvci1zcGVjaWZpYyBmb3JtYXQsIGJ1
dCB0aGVyZSBtYXkgYmUgYSBkZXNpcmUgdG8gZGVmaW5lIGEgbm9ybWF0aXZlIGZvcm1hdCwgc28g
dGhhdCBpdCBoZWxwcyB3aXRoIEROUy1TRCBhcyB3ZWxsIGFzIHdpdGggdGhlIEFOSU1BIGJvb3Rz
dHJhcHBpbmcgYXBwcm9hY2guDQoNCkN1cnJlbnRseSB0aGlzIGl0ZW0gaXMgb24gdGhlIEFOSU1B
IGJvb3RzdHJhcHBpbmcgdGVhbSdzIGFnZW5kYSB0byBkaXNjdXNzIGluIGFuIHVwY29taW5nIG1l
ZXRpbmcuICBJdCdzIHByb2JhYmx5IGJlc3QgdG8gZGVmZXIgZGlzY3Vzc2lvbiBvbiB0aGlzIGlz
c3VlIHVudGlsIGFmdGVyIHRoZSBBTklNQSBmb2xrcyBoYXZlIGRpc2N1c3NlZCBpdC4gIEkgd2ls
bCBzZW5kIGFuIHVwZGF0ZSB0byB0aGUgbGlzdCB3aXRoIHRoZSByZXN1bHRzIG9mIHRoYXQgZGlz
Y3Vzc2lvbiBhcyBzb29uIGFzIEkgY2FuLg0KDQoNCg0KUmVnYXJkcywNCg0KS2VudA0KDQoNCg==

--_000_15A40A516FBE495298EDC92EBDFB6373junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <4FEB630024704D48B7005D1E854DAF12@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eToiSGVsdmV0aWNhIE5ldWUiOw0KCXBhbm9zZS0xOjIgMCA1IDMgMCAwIDAgMiAwIDQ7fQ0KQGZv
bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIg
NCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v
cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw
dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N
CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv
bG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw
YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu
Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250
LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnNwYW4uRW1h
aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5
OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUt
dHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246
dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5
cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN
Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N
CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwv
aGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIg
dmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli
cmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlVwZGF0ZTog
VGhpcyBpc3N1ZSBoYXMgYmVlbiBkaXNjdXNzZWQgd2l0aCB0aGUgQU5JTUEgZm9sa3MuJm5ic3A7
IFRoZSBjdXJyZW50IHByb3Bvc2FsIGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh
bGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPk9MRDo8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7IG1vZHVs
ZTogaWV0Zi16ZXJvdG91Y2gtb3duZXJzaGlwLXZvdWNoZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1y
dyB2b3VjaGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgb3duZXIt
aWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3RyaW5nPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgdW5pcXVlLWlkKiZuYnNwOyZuYnNwOyAmbmJzcDtzdHJp
bmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBjcmVhdGVkLW9uJm5i
c3A7Jm5ic3A7Jm5ic3A7IHlhbmc6ZGF0ZS1hbmQtdGltZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgJiM0MzstLXJ3IGV4cGlyZXMtb24/Jm5ic3A7Jm5ic3A7IHlhbmc6ZGF0ZS1hbmQt
dGltZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHNpZ25hdHVyZSZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdHJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5O
RVc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7ICZuYnNwOyZu
YnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTpDb25zb2xhcyI+bW9kdWxlOiBpZXRmLXplcm90b3VjaC1vd25lcnNoaXAtdm91Y2hlcjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgJiM0MzstLXJ3IHZvdWNoZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD
b25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
ICYjNDM7LS1ydyBvd25lci1pZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzdHJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7ICYjNDM7LS1ydyB1bmlxdWUtaWQqJm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwO3N0cmluZyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsvLyBBTklNQSB3b3VsZCBhbHdheXMgaGF2ZSBqdXN0IDEg
bGlzdCBlbnRyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IG5vbmNl
PyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDt1bml0NjQmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Ly8gb25seSBBTklNQSB3b3VsZCB1c2UgdGhpcyBub25j
ZSBmaWVsZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHZlcmlmaWNh
dGlvbi10eXBlJm5ic3A7IGVudW0ge3ZlcmlmaWVkLCBsb2dnZWQpJm5ic3A7Jm5ic3A7IC8vIE5F
VENPTkYgd291bGQgYWx3YXlzIGJlIFZFUklGSUVEPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyAmIzQzOy0tcncgY3JlYXRlZC1vbiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDt5YW5nOmRhdGUtYW5kLXRpbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7ICYjNDM7LS1ydyBleHBpcmVzLW9uPyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDt5YW5nOmRhdGUtYW5kLXRpbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp
YnJpIj5BcyBjb21wYXJlZCB0byBBTklNQeKAmXMgY3VycmVudCDigJh2b3VjaGVy4oCZIGZvcm1h
dDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsgezxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyAmcXVvdDtu
b25jZSZxdW90OzomcXVvdDsmbHQ7NjRiaXQgbm9uY2UgdmFsdWUmZ3Q7JnF1b3Q7LA0KPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7
c2VyaWFsbnVtYmVyJnF1b3Q7OiZxdW90OyZsdDtzdHJpbmcgdmFsdWUmZ3Q7JnF1b3Q7LCZuYnNw
OyZuYnNwOyZuYnNwOyAtLSZndDsgdW5pcXVlLWlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7ICZxdW90O2RvbWFpbklEJnF1b3Q7OiZsdDtkb21haW5J
RCB2YWx1ZSZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0m
Z3Q7IG93bmVyLWlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaGlzIG9uZSBsaWtlbHkgbmVlZHMgbW9yZSBk
aXNjdXNzaW9uLCBidXQgd291bGQgbG92ZSB0byBoZWFyIG9waW5pb25zIG5vdy4uLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OkNhbGlicmkiPktlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp
YnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0
REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTog
PC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNr
Ij5OZXRjb25mICZsdDtuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBL
ZW50IFdhdHNlbiAmbHQ7a3dhdHNlbkBqdW5pcGVyLm5ldCZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+
V2VkbmVzZGF5LCBNYXkgMTEsIDIwMTYgYXQgNjo1NyBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7
bmV0Y29uZkBpZXRmLm9yZyZxdW90OyAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5T
dWJqZWN0OiA8L2I+W05ldGNvbmZdIHplcm90b3VjaC8xMTogT3duZXJzaGlwIFZvdWNoZXIg4oCT
IGZvcm1hbGx5IGRlZmluZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90
Oztjb2xvcjojMzMzMzMzIj5odHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy96ZXJvLXRvdWNo
L2lzc3Vlcy8xMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tYm90dG9t
OjEyLjBwdDtib3gtc2l6aW5nOiBib3JkZXItYm94Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMzMzMzMz
Ij5UaGlzIGlzc3VlIHJlZ2FyZHMgdGhlIGZvcm1hdCBvZiB0aGUgb3duZXJzaGlwIHZvdWNoZXIu
ICZuYnNwO1RoZSBjdXJyZW50IGRyYWZ0IGRlZmluZXMgdGhlIG93bmVyc2hpcCB2b3VjaGVyIGFz
IGEgdmVuZG9yLXNwZWNpZmljIGZvcm1hdCwNCiBidXQgdGhlcmUgbWF5IGJlIGEgZGVzaXJlIHRv
IGRlZmluZSBhIG5vcm1hdGl2ZSBmb3JtYXQsIHNvIHRoYXQgaXQgaGVscHMgd2l0aCBETlMtU0Qg
YXMgd2VsbCBhcyB3aXRoIHRoZSBBTklNQSBib290c3RyYXBwaW5nIGFwcHJvYWNoLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjBpbjtib3gtc2l6aW5nOiBib3Jk
ZXItYm94Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMzMzMzMzIj5DdXJyZW50bHkgdGhpcyBpdGVtIGlz
IG9uIHRoZSBBTklNQSBib290c3RyYXBwaW5nIHRlYW0ncyBhZ2VuZGEgdG8gZGlzY3VzcyBpbiBh
biB1cGNvbWluZyBtZWV0aW5nLiAmbmJzcDtJdCdzIHByb2JhYmx5IGJlc3QgdG8gZGVmZXIgZGlz
Y3Vzc2lvbg0KIG9uIHRoaXMgaXNzdWUgdW50aWwgYWZ0ZXIgdGhlIEFOSU1BIGZvbGtzIGhhdmUg
ZGlzY3Vzc2VkIGl0LiAmbmJzcDtJIHdpbGwgc2VuZCBhbiB1cGRhdGUgdG8gdGhlIGxpc3Qgd2l0
aCB0aGUgcmVzdWx0cyBvZiB0aGF0IGRpc2N1c3Npb24gYXMgc29vbiBhcyBJIGNhbi48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowaW47Ym94LXNpemluZzogYm9y
ZGVyLWJveCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzMzMzMzMyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MGluO2JveC1zaXppbmc6IGJvcmRlci1ib3gi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSBOZXVlJnF1b3Q7O2NvbG9yOiMzMzMzMzMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MGluO2JveC1zaXppbmc6IGJvcmRlci1ib3giPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVl
JnF1b3Q7O2NvbG9yOiMzMzMzMzMiPktlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHls
ZT0ibWFyZ2luLXRvcDowaW47Ym94LXNpemluZzogYm9yZGVyLWJveCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29s
b3I6IzMzMzMzMyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_15A40A516FBE495298EDC92EBDFB6373junipernet_--


From nobody Wed Jun 29 16:37:01 2016
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 8E51212DD44 for ; Wed, 29 Jun 2016 16:36:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 bTkv7kjvVLoj for ; Wed, 29 Jun 2016 16:36:57 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0116.outbound.protection.outlook.com [207.46.100.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 CDB1A12DBDD for ; Wed, 29 Jun 2016 16:36:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zlyQvoQHYC4+lAhJmgOxqttLIs348YXvhnIjGktqkmA=; b=UaKmxtN5b18l5+dud6KTmXqtTvOVg/mY2OcNJ8W1ZvSvd+79DUQpcUoaQKLxgirVII9w0fQTLBdFxbnVifruMF1jNIXGn2Roe6YbzvF+rx5vKnOeVsovXT9e2u+JwCIXetr+gnZQA/Sg9TG/sUjCh0BnQMYaGN75kNKMwwAtOIg=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1451.namprd05.prod.outlook.com (10.160.149.12) with Microsoft SMTP Server (TLS) id 15.1.528.16; Wed, 29 Jun 2016 23:36:56 +0000
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0528.017; Wed, 29 Jun 2016 23:36:56 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: zerotouch/15: Enhanced script support
Thread-Index: AQHR0l8f+8vihsWqLE60bISXgUFL+w==
Date: Wed, 29 Jun 2016 23:36:56 +0000
Message-ID: <3BEDEBEF-DCCF-45F4-A984-B6C75D6FD9E1@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.17.0.160611
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.13]
x-ms-office365-filtering-correlation-id: b07e15e5-6f26-4e14-ca2e-08d3a0764210
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1451; 6:ebR1yQdNwYUpC5dFoiWZKRjvpjVXVxwoffGb8eWXqWih2cBwkA7Wn6w3F3flHGuYJVl+H+gU6UD2aFXhH8MtqY0jzQvo3paeheUMA5h+lkne8raaTLtV92tC8+lJdBtpQtFAruVnNDdc8PdqzH4+tu3UtSahNvPTTd/AZclmVH0HzfGnT1tkDbo3tLDJ2ppZbizRi1z2Xcsp8aUD1OE12NJVY2wjYmvLSiWh2rQHlkQV5kDSq3bGxIhJQJ9ZoTh5OIksIUKRScdRdM5FNLLH7kyi5xFCcPavr8GCVruDOgz5BGXN+ZnpgfnlT0UY++RI5jBO3lYBkwj3MocRVUCVbA==; 5:5Pb10KkYo9zHkdjNDnWY5CFe/aG70fJ/IGz9mvmHlkXzKKOCeUwbPby3rX9j4GQFyQoqh3cJXLe5qzYxowP2cayu9diA78xucGoFbSXuOIoCh3ied0Y58r+/X9JHYNF8RXOLAQwI0SVBwaOpngxnHw==; 24:y+TQHHTmYif37hSVvYM3r+m2IHIniz7FGjMBrHsMoh41uHtuuoQ1HLXzKmHHUF00ksTBFxTlw2Z5OxHpWJXIXJaGbIcNh9iDHZu+Rj5R9sc=; 7:1DdU20eszrVZveVHtsepeTQNFJZQwLK9pBNxNdl+2dbrd6CuC+OafbbzuONDB6QCjRwnW9sOJpyzVY31puGcZWZkWk0dRaABnmO8gbuY3qL6VcANBUZtf2UohgG7uuaDKAGfhE9wA62FFbmt3QMryPhVp3pNxBCa3juEB1L90nsx6Sx9uzH25JXZ34PXuBQVj1ZRPTWLMZMM/2ZTDlJp/B9bpCUTZTqHdH9c+AEUyGko6PydQd3mQXUOcBy5n14g
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1451;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(166708455590820);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026);  SRVR:CY1PR0501MB1451; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1451; 
x-forefront-prvs: 09888BC01D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(478694002)(189002)(199003)(8936002)(7846002)(81156014)(83716003)(97736004)(66066001)(33656002)(586003)(82746002)(83506001)(107886002)(2501003)(68736007)(2351001)(7736002)(87936001)(229853001)(106116001)(105586002)(11100500001)(106356001)(3280700002)(189998001)(110136002)(81166006)(50986999)(2900100001)(8676002)(99286002)(122556002)(6116002)(3846002)(19580395003)(54356999)(5002640100001)(36756003)(77096005)(92566002)(15975445007)(5640700001)(10400500002)(101416001)(4001350100001)(86362001)(2906002)(1730700003)(305945005)(3660700001)(450100001)(102836003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1451; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <3FB355EAAD43BE40BF736B5DFE93EC9A@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2016 23:36:56.3502 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1451
Archived-At: 
Subject: [Netconf] zerotouch/15: Enhanced script support
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2016 23:36:59 -0000

aHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvemVyby10b3VjaC9pc3N1ZXMvMTUNCg0KVGhl
IGN1cnJlbnQgZHJhZnQgYWxsb3dzIGZvciBhIHNpbmdsZSBzY3JpcHQgdGhhdCB0YWtlcyBubyBj
b21tYW5kLWxpbmUgcGFyYW1ldGVycy4gT24tZ29pbmcgaW1wbGVtZW50YXRpb24gZGlzY3Vzc2lv
bnMgc3VnZ2VzdCB0aGF0Og0KDQoxKSB0aGVyZSBzaG91bGQgYmUgc3VwcG9ydCB0byBydW4gYSBz
Y3JpcHQgYm90aCBiZWZvcmUgYW5kIGFmdGVyIHRoZSBjb25maWd1cmF0aW9uIGlzIGNvbW1pdHRl
ZC4NCiAgICAgICAtIHRoaXMgbWVhbnMgdGhhdCB3ZSdkIG5lZWQgYm90aCAicHJlLXNjcmlwdCIg
YW5kICJwb3N0LXNjcmlwdCIgbGVhdmVzDQogICAgICAgLSBmb3IgaW5zdGFuY2U6DQoNCk9MRDoN
Cg0KICAgICAgICAgICAgICAgICArLS1ybyBib290c3RyYXAtaW5mb3JtYXRpb24NCiAgICAgICAg
ICAgICAgICAgICAgKy0tcm8gYm9vdC1pbWFnZQ0KICAgICAgICAgICAgICAgICAgICB8ICArLS0u
Li4NCiAgICAgICAgICAgICAgICAgICAgKy0tcm8gY29uZmlndXJhdGlvbg0KICAgICAgICAgICAg
ICAgICAgICArLS1ybyBzY3JpcHQ/ICAgICAgICAgIHN0cmluZw0KTkVXOg0KDQogICAgICAgICAg
ICAgICAgICstLXJvIGJvb3RzdHJhcC1pbmZvcm1hdGlvbg0KICAgICAgICAgICAgICAgICAgICAr
LS1ybyBib290LWltYWdlDQogICAgICAgICAgICAgICAgICAgIHwgICstLS4uLg0KICAgICAgICAg
ICAgICAgICAgICArLS1ybyBwcmUtY29uZmlndXJhdGlvbi1zY3JpcHQ/ICAgICAgICAgIHN0cmlu
Zw0KICAgICAgICAgICAgICAgICAgICArLS1ybyBjb25maWd1cmF0aW9uDQogICAgICAgICAgICAg
ICAgICAgICstLXJvIHBvc3QtY29uZmlndXJhdGlvbi1zY3JpcHQ/ICAgICAgICAgU3RyaW5nDQoN
Cg0KDQoyKSB0aGVyZSBzaG91bGQgYmUgc3VwcG9ydCBmb3IgcGFzc2luZyBjb21tYW5kIGxpbmUg
cGFyYW1ldGVycywgc28gdGhhdCB0aGUgc2FtZSBzY3JpcHQgY2FuIGJlIHVzZWQgb24gbWFueSBk
ZXZpY2VzLiBUaGlzIGlzIGVzc2VudGlhbGx5IHNoaWZ0aW5nIHdoZXJlIHZhcmlhYmxlIGJpbmRp
bmdzIG9jY3VyIC0gZWl0aGVyIHRoZSBOTVMgcmVuZGVycyBhIGRldmljZS1zcGVjaWZpYyBzY3Jp
cHQgKGluY29ycG9yYXRpbmcgZGV2aWNlLXNwZWNpZmljIHZhbHVlcyksIG9yIHRoZSBkZXZpY2Ug
cmVuZGVycyBpdCAodXNpbmcgY29tbWFuZC1saW5lIHZhcmlhYmxlcyB0byBrbm93IGhvdyB0byBk
byB0aGUgc3Vic3RpdHV0aW9ucykuIFRoZSBsYXR0ZXIgaXMgaGFyZGVyIG9uIGRldmljZXMsIGJ1
dCB0aGUgZm9ybWVyIG1heSBlbmFibGUgYmV0dGVyIHNjYWxhYmlsaXR5LiBUbyBpbXBsZW1lbnQg
dGhpcywgd2UgbWlnaHQgaGF2ZSBzb21ldGhpbmcgbGlrZToNCg0KTkVXOiAvLyBhZGRpbmcgb250
byB0aGUgYWJvdmUgZXhhbXBsZQ0KDQogICAgICAgICAgICAgICAgICstLXJvIGJvb3RzdHJhcC1p
bmZvcm1hdGlvbg0KICAgICAgICAgICAgICAgICAgICArLS1ybyBib290LWltYWdlDQogICAgICAg
ICAgICAgICAgICAgIHwgICstLS4uLg0KICAgICAgICAgICAgICAgICAgICArLS1ybyBwcmUtY29u
ZmlndXJhdGlvbi1zY3JpcHQNCiAgICAgICAgICAgICAgICAgICAgfCAgKy0tIHNjcmlwdCAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJpbmcNCiAgICAgICAgICAgICAg
ICAgICAgfCAgKy0tIHBhcmFtZXRlcnMgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cmlu
Zw0KICAgICAgICAgICAgICAgICAgICArLS1ybyBjb25maWd1cmF0aW9uDQogICAgICAgICAgICAg
ICAgICAgICstLXJvIHBvc3QtY29uZmlndXJhdGlvbi1zY3JpcHQNCiAgICAgICAgICAgICAgICAg
ICAgICAgKy0tIHNjcmlwdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz
dHJpbmcNCiAgICAgICAgICAgICAgICAgICAgICAgKy0tIHBhcmFtZXRlcnMgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHN0cmluZw0KDQoNCkFueSB0aG91Z2h0cyBvbiB0aGlzIG9uZT8NCg0K
DQpUaGFua3MsDQpLZW50DQoNCg0K


From nobody Thu Jun 30 08:38:53 2016
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 4118B12B059 for ; Thu, 30 Jun 2016 08:38:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level: 
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 DqwGzPI3fZ_Q for ; Thu, 30 Jun 2016 08:38:42 -0700 (PDT)
Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (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 8977E12D193 for ; Thu, 30 Jun 2016 08:38:42 -0700 (PDT)
Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-05v.sys.comcast.net with SMTP id Ie1lb38a28JCNIe37b8N4M; Thu, 30 Jun 2016 15:38:41 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467301121; bh=7R7k3L3APAgzzdv5JnMO97dwg/0jGDYM+fuSl2kW55E=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=rTUJsSwAb1ymqABxugt/XyLuW29j0QqekdZ/emLnzeSUvutAQVAtIEDzAXPyiwmo5 wh9tlUtxd0jGWG6xEdCRGVBfnk3Y2r80ZV4Jj1OG0d0va+4QFDSB+g1CA4pwlgs32q tfaJh/6MEBee6pgcXUgCp7Rzx8NCmph1nS9Q6yZQMvbBHV54U57/Y95lEzdsDI0i+X dDPTBTtWnyjJHjb/3OolFzINQVlPg3nHCjnzecO2Y9ItBE9BynHf7Gy/v2I/iSke9Q cNCwZDmis26TS5+Ki2pOvD+gSvfWQB7aGnosSO7+inrfFVMaRkXtAqLtzsJtrdeayA ZDTNqwHVyjEFQ==
Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-18v.sys.comcast.net with comcast id D3eh1t0021nMCLR013eh7N; Thu, 30 Jun 2016 15:38:41 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5UFcecN023461; Thu, 30 Jun 2016 11:38:40 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5UFcekH023458; Thu, 30 Jun 2016 11:38:40 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: Andy Bierman 
In-Reply-To:  (andy@yumaworks.com)
Sender: worley@ariadne.com (Dale R. Worley)
Date: Thu, 30 Jun 2016 11:38:40 -0400
Message-ID: <87wpl6bsan.fsf@hobgoblin.ariadne.com>
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] Comments on draft-ietf-netconf-restconf-14
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2016 15:38:45 -0000

Andy Bierman  writes:

>> In 3.6.1 is:
>>
>>    
>>
>> This means the 'input' element of an RPC body is in the namespace of
>> the module.  Similarly for 'output' elements.  This is not specified
>> anywhere.  (Errors is specified to be in "ietf-restconf" in section
>> 7.1.)
>
> But this would just restate normative text from YANG, right?
> RESTCONF does not need to define the module namespace for the input-stmt.

Netconf does define the module namespace for the input schema node.  But
Restconf does *not* define that the input element in the RPC request is
an instance of that input schema node -- if you read the text exactly.
What is does say is that the *parameters* are instances of the schema
nodes, which are the children of the input schema node, but it doesn't
say anything about the input element (the parent of the parameters)
*itself*:

>    If the "rpc" or "action" statement has an "input" section then
>    instances of these input parameters are encoded in the module
>    namespace where the "rpc" or "action" statement is defined, in an XML
>    element or JSON object named "input".

Dale


From nobody Thu Jun 30 10:41:55 2016
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 33B2912D526 for ; Thu, 30 Jun 2016 10:41:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 MDL3t_0jxyhy for ; Thu, 30 Jun 2016 10:41:51 -0700 (PDT)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 EE4FB12D1B9 for ; Thu, 30 Jun 2016 10:41:50 -0700 (PDT)
Received: by mail-vk0-x231.google.com with SMTP id k68so33482006vkb.0 for ; Thu, 30 Jun 2016 10:41:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o2CPpuHfN6lrb/kkBrYnTZFXjEBc02z2FmGVQPyjqxg=; b=hhE6Mrl++m0A3PzCBVGO4uj2+h7iJRxEGgU07ViehlT6WS41KwPZu92lmgV4KB3t3i RQPYTPWGjEkYQkTXUSMXW2HXUpjREyKkVSlvWkseuvlBYeoY6CTlVXceO/KiqVkwkRzF iZagCgVhND4n9U/kJpdELTu3YKkTp9DWAlX+/J1i8ONZ2b8CysYtGeW03DgowKN7Qx8W wbOsAE+loKyCXskAa78omBgMxNeJTBuf+crt4je/dBQP9uK7AgxfIz2qgqSsVwhEJlEo pKaGYFKzcMVvXBdcm7b9O9+UGCVLQiEYfm+6GUZbJ8acOn5oUZ03lGr1XGijgwx+ju8Q 85gA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o2CPpuHfN6lrb/kkBrYnTZFXjEBc02z2FmGVQPyjqxg=; b=TDbVktc5F2W1wgJ5CeiqA/JEpFIqbNCRONod8o7CV5Dfq4PKUno0tSveagoO+h1/YZ WDcfm9OrrdzVXCWRzNsAN5tm/Wn12wgnDG4crCzx7vFoEcRGW2Mx7aTH2TxxraBDLpj1 mLNvR3gtxk2NMJ1TtuSHdxJeC9QDeEsfn9BtZalY1Xdr98jTu78eh6sW1D3yOLtVbbml wkLnyH2Ww0uA9/WuYXRJvH/2m7XX1n8t6QU4GxmFc1+MWRlEZbK24BoNhjTXb4U3sey3 YgAvJUA/ol4V/6jBUTuVBblBIJqndkqOmM7i3I2RkKtokIXHxqC1/JvkLXIZHr+DxHvU 8Gow==
X-Gm-Message-State: ALyK8tKd9JWo3KgOZMTxGjKXC1f+BmHxsW6B9iigHxBXn0s2r3kAQ8VG15zZ9HayJc0AEio2CVO7B9lJ9JjVEg==
X-Received: by 10.176.7.7 with SMTP id h7mr7240885uah.9.1467308510093; Thu, 30 Jun 2016 10:41:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Thu, 30 Jun 2016 10:41:49 -0700 (PDT)
In-Reply-To: <87wpl6bsan.fsf@hobgoblin.ariadne.com>
References:  <87wpl6bsan.fsf@hobgoblin.ariadne.com>
From: Andy Bierman 
Date: Thu, 30 Jun 2016 10:41:49 -0700
Message-ID: 
To: "Dale R. Worley" 
Content-Type: multipart/alternative; boundary=94eb2c1229d88539010536826225
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] Comments on draft-ietf-netconf-restconf-14
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2016 17:41:53 -0000

--94eb2c1229d88539010536826225
Content-Type: text/plain; charset=UTF-8

On Thu, Jun 30, 2016 at 8:38 AM, Dale R. Worley  wrote:

> Andy Bierman  writes:
>
> >> In 3.6.1 is:
> >>
> >>    
> >>
> >> This means the 'input' element of an RPC body is in the namespace of
> >> the module.  Similarly for 'output' elements.  This is not specified
> >> anywhere.  (Errors is specified to be in "ietf-restconf" in section
> >> 7.1.)
> >
> > But this would just restate normative text from YANG, right?
> > RESTCONF does not need to define the module namespace for the input-stmt.
>
> Netconf does define the module namespace for the input schema node.  But
> Restconf does *not* define that the input element in the RPC request is
> an instance of that input schema node -- if you read the text exactly.
> What is does say is that the *parameters* are instances of the schema
> nodes, which are the children of the input schema node, but it doesn't
> say anything about the input element (the parent of the parameters)
> *itself*:
>
>
OK -- I think YANG sec.7.14.4 covers the issue, but it can be restated so
the "input" node is mentioned.  Seems obvious to me from the YANG RFC
this is the case.




> >    If the "rpc" or "action" statement has an "input" section then
> >    instances of these input parameters are encoded in the module
> >    namespace where the "rpc" or "action" statement is defined, in an XML
> >    element or JSON object named "input".
>
> Dale
>

Andy

--94eb2c1229d88539010536826225
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Jun 30, 2016 at 8:38 AM, Dale R. Worley <<=
a href=3D"mailto:worley@ariadne.com" target=3D"_blank">worley@ariadne.com> wrote:
Andy Bierman <andy@yumaworks.com> writes:



>> In 3.6.1 is:

>>

>>=C2=A0 =C2=A0 <input xmlns=3D"https://example.com/=
ns/example-ops">

>>

>> This means the 'input' element of an RPC body is in the na=
mespace of

>> the module.=C2=A0 Similarly for 'output' elements.=C2=A0 T=
his is not specified

>> anywhere.=C2=A0 (Errors is specified to be in "ietf-restconf&=
quot; in section

>> 7.1.)

>

> But this would just restate normative text from YANG, right?

> RESTCONF does not need to define the module namespace for the input-st=
mt.



Netconf does define the module namespace for the input schema node.=C2=A0 B=
ut

Restconf does *not* define that the input element in the RPC request is

an instance of that input schema node -- if you read the text exactly.

What is does say is that the *parameters* are instances of the schema

nodes, which are the children of the input schema node, but it doesn't<=
br>
say anything about the input element (the parent of the parameters)

*itself*:



OK -- I think YANG sec.7.14.4 covers t=
he issue, but it can be restated so
the "input" node is=
 mentioned.=C2=A0 Seems obvious to me from the YANG RFC
this is t=
he case.


=C2=A0

>=C2=A0 =C2=A0 If the "rpc" or "action" statement ha=
s an "input" section then

>=C2=A0 =C2=A0 instances of these input parameters are encoded in the mo=
dule

>=C2=A0 =C2=A0 namespace where the "rpc" or "action"=
 statement is defined, in an XML

>=C2=A0 =C2=A0 element or JSON object named "input".



Dale



Andy<=
/div>



--94eb2c1229d88539010536826225--


From nobody Thu Jun 30 10:43:49 2016
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 A50D312D0D3; Thu, 30 Jun 2016 10:43:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.048
X-Spam-Level: 
X-Spam-Status: No, score=-104.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 fZhYPAly6zBa; Thu, 30 Jun 2016 10:43:43 -0700 (PDT)
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 131211288B8; Thu, 30 Jun 2016 10:43:43 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 0C967B80B91; Thu, 30 Jun 2016 10:43:43 -0700 (PDT)
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
Message-Id: <20160630174343.0C967B80B91@rfc-editor.org>
Date: Thu, 30 Jun 2016 10:43:43 -0700 (PDT)
Archived-At: 
Cc: drafts-update-ref@iana.org, netconf@ietf.org, rfc-editor@rfc-editor.org
Subject: [Netconf] RFC 7895 on YANG Module Library
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2016 17:43:46 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7895

        Title:      YANG Module Library 
        Author:     A. Bierman, M. Bjorklund,
                    K. Watsen
        Status:     Standards Track
        Stream:     IETF
        Date:       June 2016
        Mailbox:    andy@yumaworks.com, 
                    mbj@tail-f.com, 
                    kwatsen@juniper.net
        Pages:      13
        Characters: 24164
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-netconf-yang-library-06.txt

        URL:        https://www.rfc-editor.org/info/rfc7895

        DOI:        http://dx.doi.org/10.17487/RFC7895

This document describes a YANG library that provides information
about all the YANG modules used by a network management server (e.g.,
a Network Configuration Protocol (NETCONF) server).  Simple caching
mechanisms are provided to allow clients to minimize retrieval of
this information.

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 Thu Jun 30 15:01:28 2016
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 9003D12B01F for ; Thu, 30 Jun 2016 15:01:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 Gpq1CTNdS1ex for ; Thu, 30 Jun 2016 15:01:25 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 D78D41288B8 for ; Thu, 30 Jun 2016 15:01:24 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id t127so171921734qkf.1 for ; Thu, 30 Jun 2016 15:01:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8Cu42qWl8/svKSTVNcPKrBE2Quarx3X1xOYHFN6JVM4=; b=jPO1sTee14FmI8fhnnjjgoMc+tZRC4He5ZmK5+o/OtKmtQ0wYi2B9L4Jd3PBdS4YKz GmiKT8veCkirrUDeTw+UYiIqSi23CcSvPd8vXSdqAEdiXaPd9OF87Wd+3LUrOAp9t0Bo 444q/jmYztBA0tzqHky1si1KMvab8ReKJ3uCg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8Cu42qWl8/svKSTVNcPKrBE2Quarx3X1xOYHFN6JVM4=; b=OrrIep8zdMWyFpio0LcTbtwsFaTiinkJ1EnLOgtPQwsswQKLtiKjArw5o4Ok9suo95 UT3m7S0aa9Lg9H3yXNDZaS+pO8YMv9YaTrb7dAaz41pdPMds2fMxT6RGDbabawvKUYws EJVVw+ihaMGZ2Ny/2l9NBBc1wScnfXAgfZsQOy72EPp/DrliPzbd3MCzrFmhRCoA2vOC SHXavEZB1uDvkIhFNOW6J+cHT2kC9A7xMeZ0a5oDWhb+tb+yHWuAGR2LTHCwhwIJpj1i 2w6a6e9TkBFebZlzKk0Eelud9vI9dzXJs2fRqkNSRrgg7SyPYOs9aOyY6MZ3zI9qfnLp c39A==
X-Gm-Message-State: ALyK8tLX+NMW4zW8ydoDoIRvfd30Px0hTVHd3Tmj58LEjQIZRmKIw7r6zCw7zR+/3glCSQ==
X-Received: by 10.55.42.78 with SMTP id q75mr22908882qkh.158.1467324083868; Thu, 30 Jun 2016 15:01:23 -0700 (PDT)
Received: from [172.16.0.112] ([96.231.230.69]) by smtp.gmail.com with ESMTPSA id l204sm2274227qke.18.2016.06.30.15.01.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 30 Jun 2016 15:01:22 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner 
In-Reply-To: 
Date: Thu, 30 Jun 2016 18:01:21 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <9040BCE7-A6A7-4134-9258-A27DB3BB0705@sn3rd.com>
References: 
To: Kent Watsen 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] netconf server-model (keychain) draft issues
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2016 22:01:26 -0000

Sorry for completely dropping the ball on this.  Hopefully, I can redeem =
myself here.

> On May 11, 2016, at 15:19, Kent Watsen  wrote:
>=20
> Hi Sean,
>=20
> Thank you again for your review of the server-model draft before, =
primarily focusing on the keychain model.  As you know, I updated the =
draft significantly based on your comments for 95, but one issue =
remains...=20
>=20
> The remaining issue regards 'key-usage' in the generate-private-key =
action listed on page 23 of =
https://tools.ietf.org/html/draft-ietf-netconf-server-model-09.  Below =
is the current (incomplete) definition:
>=20
>           leaf key-usage {
>             type enumeration {
>               enum signing    { description "signing"; }
>               enum encryption { description "encryption"; }
>               // unclear if these should be somehow more
>               // specific or varied.
>             }
>=20
> The question is how to make this key-usage definition complete?  I can =
do the YANG translation, but what are the possible values?  Is it the =
case that the issue only matters when discussing TPMs, which have very =
distinct and specific usage profiles?   As a generic keychain model, it =
shouldn't be specific to network management, but it would be remiss for =
me to not point out that, in network management, the private key seems =
to always have the same key usage (i.e. what's needed to establish a =
SSH/TLS tunnel).   Thoughts?
>=20
> Thanks,
> Kent

As far as completeness goes, it=E2=80=99s going to be hard because one =
of the fields defined to carry key usage in the certificate is open =
ended.  As far as background goes there=E2=80=99s two key usage fields =
in a cert and they both in extensions:

0. Key Usage can be found in s4.2.1.3 of RFC 5280.  It lists some usages =
that the ITU/IETF folks thought were useful (apologies for the ASN.1):

KeyUsage ::=3D BIT STRING {
  digitalSignature  (0),
  nonRepudiation  (1), -- recent editions of X.509 have
                                -- renamed this bit to contentCommitment
  keyEncipherment         (2),
  dataEncipherment        (3),
  keyAgreement            (4),
  keyCertSign             (5),
  cRLSign                 (6),
  encipherOnly            (7),
  decipherOnly            (8) }

1. And because that list isn=E2=80=99t all encompassing they also =
defined an Extended Key Usages extension which is essentially a sequence =
of OIDs.  A bunch have been defined here:
=
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers=
-1.3.6.1.5.5.7.3
Because anybody can get an OID, anybody can define a key usage so that =
list isn=E2=80=99t all encompassing.

As far as what people use, most TLS certificates include both =
id-kp-serverAuth and id-kp-clientAuth.  I=E2=80=99ll need to go dig up =
what ssh-based certificates use.  Does this at least answer some of it?

spt




From nobody Thu Jun 30 16:18:46 2016
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 8A71D127058 for ; Thu, 30 Jun 2016 16:18:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.946
X-Spam-Level: 
X-Spam-Status: No, score=-15.946 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 9eONZkZ-vLT0 for ; Thu, 30 Jun 2016 16:18:43 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3503112B004 for ; Thu, 30 Jun 2016 16:18:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7649; q=dns/txt; s=iport; t=1467328723; x=1468538323; h=from:to:subject:date:message-id:mime-version; bh=qVoiOgmuP7EFcffRAaJ820GP6rvudzwqdGV23KBGYkg=; b=AwBPnl5GpLSUDEZv2vY/uBU3t2wQUZoN2Ker4ovNArUUUM8fUIeQcEFf 0wlLv7HiETshG5aa3nlQRRCV1RO7h8XzZwMDbXzwlt9bmqxXCJxlgnJxA MqQrRfsS3fMP+9vPt1z8X77nicyN0b7sr1FdJCuL2kniwDLSpgSNV5+ns 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BYAgDGp3VX/4UNJK1UB4JwTlaBA7RKg?= =?us-ascii?q?nKCD4F7IocrOBQBAQEBAQEBZSeEUy1eAS1TJgEEG4goDqQXn3kBAQEBAQEEAQE?= =?us-ascii?q?BAQEBAQEaBYwvgnEDhW4FhgWTBgGBMIRXhWyCRoFxhFaIapAEAR42g3CIaykcf?= =?us-ascii?q?wEBAQ?=
X-IronPort-AV: E=Sophos;i="5.26,554,1459814400";  d="scan'208,217";a="292064135"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jun 2016 23:18:42 +0000
Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u5UNIffc016673 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 30 Jun 2016 23:18:42 GMT
Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 30 Jun 2016 19:18:41 -0400
Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Thu, 30 Jun 2016 19:18:41 -0400
From: "Alexander Clemm (alex)" 
To: Netconf 
Thread-Topic: Some discussion points re: RFC 5277bis and YANG push
Thread-Index: AdHTI+FJCpnnOFB2Tg2mLocsIEYh+g==
Date: Thu, 30 Jun 2016 23:18:41 +0000
Message-ID: 
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.41.59.56]
Content-Type: multipart/alternative; boundary="_000_ede3eb47e628458381d3a641083a29ceXCHRTP001ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: [Netconf] Some discussion points re: RFC 5277bis and YANG push
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2016 23:18:45 -0000

--_000_ede3eb47e628458381d3a641083a29ceXCHRTP001ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

draft-gonzalez-netconf-5277bis is another one of the drafts in the set of d=
rafts concerning event notifications and yang-push.

One of the items wort bringing for discussion concerns the notion of contro=
l plane notifications that are used to indicate the status of a notificatio=
n subscription.  Examples of such notifications are "replayComplete", "subs=
cription-modified" (in case case of configured subscriptions), and "subscri=
ption-suspended" (of particular importance for draft-ietf-netconf-yang-push=
, another draft in the set, used by the server to notify a client in case n=
otification updates cannot be sent as promised under various rainy-day scen=
arios).

What makes those notifications different from other notifications is that t=
hey are not of general concern, but of concern only for a particular associ=
ation.  As a subscriber to event notifications, I should only receive those=
 notifications that concern "my" subscription, not those that concern someo=
ne else's subscription.

The way we are planning to address this is through introduction of an exten=
sion "control-plane-notif".  This extension is used to tag definitions of n=
otifications used for control / signaling purposes that are therefore not p=
art of the general NETCONF event stream.  Instead, notifications thus tagge=
d are part of a signaling event stream that is part of the signaling/contro=
l association implied by the subscription.  Like push-notifications themsel=
ves, there is a need to distinguish notifications subscribable by everyone =
and notification instances used by a server to notify items of significance=
 to a specific client, or set of clients.  Please refer also to section 7 o=
f the draft (https://tools.ietf.org/html/draft-gonzalez-netconf-5277bis-02#=
section-7 ).

We have been discussing this issue as part of the weekly calls in which a s=
ubteam of NETCONF WG participants are discussing the set of of related draf=
ts and think this is one of the issues that we should bring to  the attenti=
on of and solicit feedback from the WG as a whole.

Thoughts?
--- Alex
(on behalf of the team)


--_000_ede3eb47e628458381d3a641083a29ceXCHRTP001ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


draft-gonzalez-netconf-5277bis is another one of the=
 drafts in the set of drafts concerning event notifications and yang-push.&=
nbsp;



 


One of the items wort bringing for discussion concer=
ns the notion of control plane notifications that are used to indicate the =
status of a notification subscription.  Examples of such notifications=
 are “replayComplete”, “subscription-modified”
 (in case case of configured subscriptions), and “subscription-suspen=
ded” (of particular importance for draft-ietf-netconf-yang-push, anot=
her draft in the set, used by the server to notify a client in case notific=
ation updates cannot be sent as promised under
 various rainy-day scenarios). 


 


What makes those notifications different from other =
notifications is that they are not of general concern, but of concern only =
for a particular association.  As a subscriber to event notifications,=
 I should only receive those notifications
 that concern “my” subscription, not those that concern someone=
 else’s subscription. 



 


The way we are planning to address this is through i=
ntroduction of an extension “control-plane-notif”.  This e=
xtension is used to tag definitions of notifications used for control / sig=
naling purposes that are therefore not part of the
 general NETCONF event stream.  Instead, notifications thus tagged are=
 part of a signaling event stream that is part of the signaling/control ass=
ociation implied by the subscription.  Like push-notifications themsel=
ves, there is a need to distinguish notifications
 subscribable by everyone and notification instances used by a server to no=
tify items of significance to a specific client, or set of clients.  P=
lease refer also to section 7 of the draft (https://tools.ietf.org=
/html/draft-gonzalez-netconf-5277bis-02#section-7
 ).  


 


We have been discussing this issue as part of the we=
ekly calls in which a subteam of NETCONF WG participants are discussing the=
 set of of related drafts and think this is one of the issues that we shoul=
d bring to  the attention of and solicit
 feedback from the WG as a whole.  


 


Thoughts?  


--- Alex 


(on behalf of the team)


 






--_000_ede3eb47e628458381d3a641083a29ceXCHRTP001ciscocom_--


From nobody Thu Jun 30 17:52:49 2016
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 EDBC712D0B3 for ; Thu, 30 Jun 2016 17:52:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 OO0omUUIJvgM for ; Thu, 30 Jun 2016 17:52:45 -0700 (PDT)
Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 0689F12D0B1 for ; Thu, 30 Jun 2016 17:52:45 -0700 (PDT)
Received: by mail-vk0-x235.google.com with SMTP id u68so91148511vkf.2 for ; Thu, 30 Jun 2016 17:52:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0ub6sle6XlmbNaQnLZTeCVXNsFF1ZwTYL7DlQnn0wSI=; b=trxESyUHGHxjtxajTHzYZQQZy7tZe0zPkkisUX8XVzfutmt9Uk/D2xQLz1kKPocS0b KOviJ6lkd2fDRgArveTJBBM3uX6UQDZtB0TKcne4YdmUHoBbGcGDk91zrv8xR2EXIKCd Y+gIvtsuWOSoiFoBb3FjlJw8X37NjiA6dlTDouhAJNjNwpNaWfYN9sJJeaPE61ytEpnU M0+bPizVS2S/dw+N7jtIzztFfBxMPmZnsA0ZaRIcWKUZiciClxXwAdDNXmT1IIw76mPu r2wMc1ogy8zVJj38gs8wOQ8iqlu9vZuGWvraE/wSitRPIR3IH5yDaBSqoBhgRYSAx805 bE3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0ub6sle6XlmbNaQnLZTeCVXNsFF1ZwTYL7DlQnn0wSI=; b=Jjcb1k3IOxxzKNdKo8Wo5lOh7X3FG5hmjE4PE1/0mOPXnqiy5iap0URS7uVeyRPa0+ 16Un1rAgTufSRJZIMC0Tmh3ofS1pDxtKtpPmhRp4ufQwzQdmStXtgDfRikonUoJ4aRF+ 0TIJoqRdlq4cXAywKjNUJZfVnLoSpMymxuomhi7zItbsMRMrlU3QaHtIMfEtjx39pd7l 5VTznnppOCeNxNEPQW4Xk2UwbFWtjviVVNdmt5QNhmfSc6KQq8jmGV7XULzcz5YZcSJk gi1ucuj7QSe7phvIJ/VQVKu2XKkJTKpSehQ1Wa2AaOhXFjWK8NB8v3SjWhH7OLJct9uZ sGGg==
X-Gm-Message-State: ALyK8tK6kV8byZsE3Dz7WnE1JWLbcQrH6oWmHFwv0JTPwtGr2WtsdI68HSpT9zWOrArxaEVOv9nSk1Y+S/7ByA==
X-Received: by 10.31.9.65 with SMTP id 62mr8158541vkj.89.1467334364043; Thu, 30 Jun 2016 17:52:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Thu, 30 Jun 2016 17:52:43 -0700 (PDT)
In-Reply-To: <8f8db9b8-9917-4b26-25f6-ee0c19492bb9@seantek.com>
References:   <8f8db9b8-9917-4b26-25f6-ee0c19492bb9@seantek.com>
From: Andy Bierman 
Date: Thu, 30 Jun 2016 17:52:43 -0700
Message-ID: 
To: Sean Leonard 
Content-Type: multipart/alternative; boundary=001a11440b648933c105368867f8
Archived-At: 
Cc: media-types@iana.org, Netconf 
Subject: Re: [Netconf] request review of media type application/yang-data+xml
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Jul 2016 00:52:48 -0000

--001a11440b648933c105368867f8
Content-Type: text/plain; charset=UTF-8

On Tue, Jun 28, 2016 at 8:17 PM, Sean Leonard  wrote:



removing all text except the fragment identifier issue....

According to RFC 7303, sec. 5, any usage of +xml requires implementation of
the XPointerFramework
https://www.w3.org/TR/2003/REC-xptr-framework-20030325/

RESTCONF "fragments" are sub-trees within the YANG data structures.
These are accessed by the request URI path and the "fields" query parameter.
XPointer is rather complex and completely redundant for RESTCONF.

So do we have to add text that a RESTCONF server MUST implement the
"element"
scheme?






>
>
>    Fragment identifier considerations: The fragment field in the
>       request URI has no defined purpose.
>
>
> From the perspective of NETCONF this is probably correct. However, Section
> 4.11 of RFC 6838 says:
>
>    Media types are encouraged to adopt fragment identifier schemes that
>    are used with semantically similar media types.  In particular, media
>    types that use a named structured syntax with a registered "+suffix"
>    MUST follow whatever fragment identifier rules are given in the
>    structured syntax suffix registration.
>
>
> There are some things about +xml things:
>
> http://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml
>
> RFC 7303.
>
> Look it up.
>
>



   The syntax and semantics of fragment identifiers for the XML media
   types defined in this specification are based on the
   [XPointerFramework
] W3C
Recommendation.  It allows simple names and
   more complex constructions based on named schemes.  When the syntax
   of a fragment identifier part of any URI or Internationalized
   Resource Identifier (IRI) ([RFC3987
]) with a retrieved media type
   governed by this specification conforms to the syntax specified in
   [XPointerFramework
],
conforming applications MUST interpret such
   fragment identifiers as designating whatever is specified by the
   [XPointerFramework
] together
with any other specifications governing
   the XPointer schemes used in those identifiers that the applications
   support.  Conforming applications MUST support the 'element' scheme
   as defined in [XPointerElement
], but need
not support other schemes.







Registrations which use this '+xml' convention MUST also make
reference to [RFC7303 ], specifically
Section 5, in specifying fragment identifier syntax and semantics, and
they MAY restrict the syntax to a specified subset of schemes, except
that they MUST NOT disallow barenames or 'element' scheme pointers.
They MAY further require support for other registered schemes. They
also MAY add additional syntax (which MUST NOT overlap with
[XPointerFramework
] syntax)
together with associated semantics, and MAY add additional semantics
for barename XPointers which, as provided for in Section 5, will only
apply when [RFC7303 ] does not define
an interpretation.

In practice these constraints imply that for a fragment identifier
addressed to an instance of a specific "xxx/yyy+xml" type, there are
three cases:

For fragment identifiers matching the syntax defined in
[XPointerFramework
], where the
fragment identifier resolves per the rules specified there, then
process as specified there;

For fragment identifiers matching the syntax defined in
[XPointerFramework
], where the
fragment identifier does _not_ resolve per the rules specified there,
then process as specified in "xxx/yyy+xml";

For fragment identifiers _not_ matching the syntax defined in
[XPointerFramework
], then
process as specified in "xxx/ yyy+xml". A fragment identifier of the
form "xywh=160,120,320,240", as defined in [MediaFrags
], which might be
used in a URI for an XML-encoded image, would fall in this category.
See Section 10, [RFC7303 ].









> I don't have experience dealing with this, and I would not hold back the
> registration on that basis. The Expert Reviewer might.
>
>


Andy

--001a11440b648933c105368867f8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue, Jun 28, 2016 at 8:17 PM, Sean Leonard <dev+ietf@seantek.com=
> wrote:



removing all text except the fragment identifier issue....

<=
/div>
According to RFC 7303, sec. 5, any usage of +xml requires impleme=
ntation of
the XPointerFramework

RESTCONF "=
fragments" are sub-trees within the YANG data structures.
Th=
ese are accessed by the request URI path and the "fields" query p=
arameter.
XPointer is rather complex and completely redundant for=
 RESTCONF.

So do we have to add text that a RESTCO=
NF server MUST implement the "element"
scheme?




=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex">

    

    

      

      =C2=A0=C2=A0 Fragment identifier considerations: The fragment field i=
n the
      

      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 request URI has no defined purpose.
      

    

    

    From the perspective of NETCONF this is probably correct. However,
    Section 4.11 of RFC 6838 says:

    

    
   Media types are encouraged to adopt frag=
ment identifier schemes that
   are used with semantically similar media types.  In particular, media
   types that use a named structured syntax with a registered "+suffix=
"
   MUST follow whatever fragment identifier rules are given in the
   structured syntax suffix registration.

    

    There are some things about +xml things:

http://www.iana.org/assi=
gnments/media-type-structured-suffix/media-type-structured-suffix.xhtml=


    

    RFC 7303.

    

    Look it up.

    




   The syntax and semantics of fragment identifiers for the XML media
   types defined in this specification are based on the
   [X=
PointerFramework] W3C Recommendation.  It allows simple names and
   more complex constructions based on named schemes.  When the syntax
   of a fragment identifier part of any URI or Internationalized
   Resource Identifier (IRI) ([RFC=
3987]) with a retrieved media type
   governed by this specification conforms to the syntax specified in
   [X=
PointerFramework], conforming applications MUST interpret such
   fragment identifiers as designating whatever is specified by the
   [X=
PointerFramework] together with any other specifications governing
   the XPointer schemes used in those identifiers that the applications
   support.  Conforming applications MUST support the 'element' sch=
eme
   as defined in [XPointerElement], but need not support other schemes.
<=
pre class=3D"" style=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0p=
x;color:rgb(0,0,0)">





<=
td style=3D"padding-left:0.5em;padding-right:0.5em;vertical-align:top">See =
Section 10, [RFC7303].



Registrations which use this '+xml&#=
39; convention MUST also make reference to [RFC7303], specifically Section 5, in specifying fragment id=
entifier syntax and semantics, and they MAY restrict the syntax to a specif=
ied subset of schemes, except that they MUST NOT disallow barenames or '=
;element' scheme pointers. They MAY further require support for other r=
egistered schemes. They also MAY add additional syntax (which MUST NOT over=
lap with [XPointerFramework] syntax) together with associated semantics, and MA=
Y add additional semantics for barename XPointers which, as provided for in=
 Section 5, will only apply when [RFC7303] does not define an interpretation.
In practice these constraints imply that for a fragment identifie=
r addressed to an instance of a specific "xxx/yyy+xml" type, ther=
e are three cases:
For fragment identifi=
ers matching the syntax defined in [XPointerFramework], where the fragment iden=
tifier resolves per the rules specified there, then process as specified th=
ere;
For fragment identifiers matching t=
he syntax defined in [XPointerFramework], where the fragment identifier does _n=
ot_ resolve per the rules specified there, then process as specified in &qu=
ot;xxx/yyy+xml";
For fragment ident=
ifiers _not_ matching the syntax defined in [XPointerFramework], then process a=
s specified in "xxx/ yyy+xml". A fragment identifier of the form =
"xywh=3D160,120,320,240", as defined in [MediaFrags], which might be use=
d in a URI for an XML-encoded image, would fall in this category.



=C2=A0

    I don't have experience dealing with this, and I would not hold bac=
k
    the registration on that basis. The Expert Reviewer might.

    

    



Andy
=




--001a11440b648933c105368867f8--


From nobody Thu Jun 30 19:33:22 2016
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 5F74E12B077 for ; Thu, 30 Jun 2016 19:33:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 lwL6NcixQ1KW for ; Thu, 30 Jun 2016 19:33:18 -0700 (PDT)
Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::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 6F18312D0D3 for ; Thu, 30 Jun 2016 19:33:18 -0700 (PDT)
Received: by mail-vk0-x22d.google.com with SMTP id u68so93397997vkf.2 for ; Thu, 30 Jun 2016 19:33:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MKPUbZAjArjub57JZ7cZD1KKKsv0X5Ixdahqqo+99F4=; b=Z0JVGtWQMh2AnZHVRjZZUASkIG3UuiNhv2aNkASlJH6X0NujQU/rDmlIPZYQNTMtQk nNIukdKtssO2IlO2zg7DT+yqf8PhALgUzCehpFnhzTf4/9xkG53d0+zEoeZj2LBgqPVo ZaBwvaYXHrwNBvR5PlrP+wehgKYkjELPdZ09+8RBId1SG7Ebs+AKEM1Nb1Wi0yL6UHYw u9+DzB+IP4RDLAksLe3M/0lbceZEB1g6WhsCM765P8R2TDclUMvgaO/fFB0HfOAKMsOt p0vVYj0TVVQhiNwdER25+oegKyRMQDasN0V5+JKND/1cWpgj8YNBSSrBYoeeu5erollP 49oA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MKPUbZAjArjub57JZ7cZD1KKKsv0X5Ixdahqqo+99F4=; b=NbrmPeEDVscCPAkl7uHaBQDGZ9AA8efzPjsZP9U5VQYqZUMs2ZbVYRVHLeCwE8wJBS EvMivL/UCWfJYJSuq1CzgeMtXj9U28kvAUXc3tzJBqGzvA7/l3PLUHLE/mzaj9A2brCK ZuReHztFClxl20eMax1GNEHvYyQYvJgoGuEjftDrY8ItZ7g6CD7zf3RDRjiyU6raT6lB YzWLS/Hd5HbdBTwwPlWl98YQSQqJH5gx10pL05bKgrbyeo/OlWd/RVD/vLOaXpYDvO/6 k7jxS0vv3JK+EWGfX1nxWW/dOmdXP7PeHxJCFftXO4FKVdd3R7oj8S8QSLe8pV0zx4Ik odGQ==
X-Gm-Message-State: ALyK8tIkl2sT0Nj6Y8v1bR3X9YHq+0Re13uoK2xgeqSAU/54c/rBbgp6OJYDhYFtOE1ToBefgFG9uUU/hJUSVQ==
X-Received: by 10.159.36.245 with SMTP id 108mr8520736uar.121.1467340397345; Thu, 30 Jun 2016 19:33:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Thu, 30 Jun 2016 19:33:16 -0700 (PDT)
In-Reply-To: <87mvm3d9g2.fsf@hobgoblin.ariadne.com>
References: <87mvm3d9g2.fsf@hobgoblin.ariadne.com>
From: Andy Bierman 
Date: Thu, 30 Jun 2016 19:33:16 -0700
Message-ID: 
To: "Dale R. Worley" 
Content-Type: multipart/alternative; boundary=001a11398fe6263f5b053689cff6
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] Comments on draft-ietf-netconf-restconf-14
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Jul 2016 02:33:21 -0000

--001a11398fe6263f5b053689cff6
Content-Type: text/plain; charset=UTF-8

Hi,

I have made all the edits except the 2nd 4.6 below


Andy


On Wed, Jun 29, 2016 at 1:30 PM, Dale R. Worley  wrote:

> These are derived from my "Comments on draft-ietf-netconf-restconf-13",
> updated based on the -14 draft.
>
> 3.6
>
> In 3.6.1 is:
>
>    
>
> This means the 'input' element of an RPC body is in the namespace of
> the module.  Similarly for 'output' elements.  This is not specified
> anywhere.  (Errors is specified to be in "ietf-restconf" in section
> 7.1.)
>
> Perhaps the way to clarify this is to change this paragraph
>
>    If the "rpc" or "action" statement has an "input" section then
>    instances of these input parameters are encoded in the module
>    namespace where the "rpc" or "action" statement is defined, in an XML
>    element or JSON object named "input".
>
> into, perhaps, this
>
>    If the "rpc" or "action" statement has an "input" section then
>    instances of these input parameters are encoded in an XML element
>    or JSON object named "input", which is in the module namespace
>    where the "rpc" or "action" statement is defined.
>
>

done


> The parallel change for "output" is (also correcting the typo "input"
> to "output")
>
>    If the "rpc" or "action" statement has an "output" section then
>    instances of these >>output<< parameters are encoded in an XML element
>    or JSON object named "output", which is in the module namespace
>    where the "rpc" or "action" statement is defined.
>
> This is just a rearrangement of the phrases of these sentences, but
> they put the "input"/"output" element/object in the specified
> namespace (and by implication, the input/output parameters are also).
>
>
done


> 3.6.1
>
>    If the "rpc" or "action" statement has an "input" section, then the
>    "input" node is provided in the message-body, corresponding to the
>    YANG data definition statements within the "input" section.
>
> This paragraph is an almost-clone of a paragraph in 3.6.  If
> repetition is intended, it should probably be updated from the changed
> wording in 3.6
>
>

done; added clarification


> 3.6.2
>
>    If the "rpc" or "action" statement has an "output" section, then the
>    "output" node is provided in the message-body, corresponding to the
>    YANG data definition statements within the "output" section.
>
> This paragraph is an almost-clone of a paragraph in 3.6.  If
> repetition is intended, it should probably be updated from the changed
> wording in 3.6
>
>

done; added clarification


> 4.3
>
>    Note that the way that access control is applied to data resources is
>    completely incompatible with HTTP caching.  The Last-Modified and
>    ETag headers maintained for a data resource are not affected by
>    changes to the access control rules for that data resource.  It is
>    possible for the representation of a data resource that is visible to
>    a particular client to be changed without detection via the Last-
>    Modified or ETag values.
>
> Note that it's possible for the client to detect changes in
> configuration data that it is not allowed to read by detecting changes
> in the Last-Modified/ETag values.  This probably isn't a security
> problem, but the authors should be aware of it.
>
>

done; added security considerations note


> 4.6
>
>    Each patch mechanism needs a unique media type.  Zero or more patch
>    media types MAY be supported by the server.  The media types
>    supported by a server can be discovered by the client by sending an
>    OPTIONS request (see Section 4.1).
>
> To prevent the reader from making the mistake I just made, it would be
> helpful to explicitly state that it is the Accept-Patch header in the
> OPTIONS response, rather than an enumeration of the allowed content
> types generally, that should be examined.  (An enumeration of allowed
> content types generally doesn't exist in HTTP, but does in SIP.)
>
>    A server's response to an OPTIONS request (see Section 4.1) lists
>    the patch media types it supports in the Accept-Patch header.
>
>

done; added clarification



> 4.6
>
> Yang has been extended to allow non-unique key values.  The result is
> that URLs may identify multiple data instances.  This seems to be
> specified for GET (if JSON is used, GET can return multiple instances;
> if XML is used, a 400 response is given) and DELETE (only one instance
> (arbitrarily chosen) is deleted; this may be modified by query
> parameters).  But PATCH does not seem to specify the behavior if
> multiple instances are selected.
>
>

*** not sure what the previous comment is requested... perhaps sec. #  is
wrong



> 4.8.2
>
>    By default, the server will include all sub-resources within a
>    retrieved resource, which have the same resource type as the
>    requested resource.  Only one level of sub-resources with a different
>    media type than the target resource will be returned.  The exception
>    is the datastore resource.  If this resource type is retrieved then
>    by default the datastore and all child data resources are returned.
>
> [Note for the -13 draft:]  Does the second sentence do anything?  The
> only instance I know of of a node whose media type is different from
> that of its child nodes is the the datastore resource, and that is
> specifically exempted from the effect of the 2nd sentence.
>
>

done; 2nd sentence remoted



> With the -14 draft, there are only two media types, and which one is
> used to report the contents of a resource is determined by the client,
> as a choice of encoding, rather than as an attribute of the resource.
> So I think this paragraph has no effect any more.
>
>
Only the 2nd sentence mentioned media type, which is now removed.
It is relevant for resource types.  We don't want a GET of the entry point
to return all the data resources.



> 12.  Security Considerations
>
>     The lowest NETCONF layer is the secure transport layer,
>    and the mandatory-to-implement secure transport is Secure Shell
>    (SSH) ^RFC6242^. The NETCONF access control model ^RFC6536^
>    provides the means to restrict access for particular NETCONF users
>    to a pre-configured subset of all available NETCONF protocol
>    operations and content.
>
> The formatting of this paragraph is damaged:  There is an extra space
> at its beginning, and references are marked ^...^ rather than [...].
>
>
done; also caused the reference to RFC 6242 to be missed


> 13
>
> Who is The Space & Terrestrial Communications Directorate?  Maybe it
> would add to the credit of the S&TCD by prefixing the country that
> funds it ... which seems to be "United States Army".
>
>

done



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

--001a11398fe6263f5b053689cff6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I have made all the edits except th=
e 2nd 4.6 below


Andy

=


On Wed, Jun 29, 2=
016 at 1:30 PM, Dale R. Worley <worley@ariadne.com> wrote:<=
br>
These are derived from my "Comments on draft-ietf-=
netconf-restconf-13",

updated based on the -14 draft.



3.6



In 3.6.1 is:



=C2=A0 =C2=A0<input xmlns=3D"https://example.com/ns/exampl=
e-ops">



This means the 'input' element of an RPC body is in the namespace o=
f

the module.=C2=A0 Similarly for 'output' elements.=C2=A0 This is no=
t specified

anywhere.=C2=A0 (Errors is specified to be in "ietf-restconf" in =
section

7.1.)



Perhaps the way to clarify this is to change this paragraph



=C2=A0 =C2=A0If the "rpc" or "action" statement has an =
"input" section then

=C2=A0 =C2=A0instances of these input parameters are encoded in the module<=
br>
=C2=A0 =C2=A0namespace where the "rpc" or "action" stat=
ement is defined, in an XML

=C2=A0 =C2=A0element or JSON object named "input".



into, perhaps, this



=C2=A0 =C2=A0If the "rpc" or "action" statement has an =
"input" section then

=C2=A0 =C2=A0instances of these input parameters are encoded in an XML elem=
ent

=C2=A0 =C2=A0or JSON object named "input", which is in the module=
 namespace

=C2=A0 =C2=A0where the "rpc" or "action" statement is d=
efined.




done
=C2=A0

The parallel change for "output" is (also correcting the typo &qu=
ot;input"

to "output")



=C2=A0 =C2=A0If the "rpc" or "action" statement has an =
"output" section then

=C2=A0 =C2=A0instances of these >>output<< parameters are encod=
ed in an XML element

=C2=A0 =C2=A0or JSON object named "output", which is in the modul=
e namespace

=C2=A0 =C2=A0where the "rpc" or "action" statement is d=
efined.



This is just a rearrangement of the phrases of these sentences, but

they put the "input"/"output" element/object in the spe=
cified

namespace (and by implication, the input/output parameters are also).



done
=C2=A0

3.6.1



=C2=A0 =C2=A0If the "rpc" or "action" statement has an =
"input" section, then the

=C2=A0 =C2=A0"input" node is provided in the message-body, corres=
ponding to the

=C2=A0 =C2=A0YANG data definition statements within the "input" s=
ection.



This paragraph is an almost-clone of a paragraph in 3.6.=C2=A0 If

repetition is intended, it should probably be updated from the changed

wording in 3.6




done; added clarificati=
on
=C2=A0

3.6.2



=C2=A0 =C2=A0If the "rpc" or "action" statement has an =
"output" section, then the

=C2=A0 =C2=A0"output" node is provided in the message-body, corre=
sponding to the

=C2=A0 =C2=A0YANG data definition statements within the "output" =
section.



This paragraph is an almost-clone of a paragraph in 3.6.=C2=A0 If

repetition is intended, it should probably be updated from the changed

wording in 3.6




done; added clarificati=
on
=C2=A0

4.3



=C2=A0 =C2=A0Note that the way that access control is applied to data resou=
rces is

=C2=A0 =C2=A0completely incompatible with HTTP caching.=C2=A0 The Last-Modi=
fied and

=C2=A0 =C2=A0ETag headers maintained for a data resource are not affected b=
y

=C2=A0 =C2=A0changes to the access control rules for that data resource.=C2=
=A0 It is

=C2=A0 =C2=A0possible for the representation of a data resource that is vis=
ible to

=C2=A0 =C2=A0a particular client to be changed without detection via the La=
st-

=C2=A0 =C2=A0Modified or ETag values.



Note that it's possible for the client to detect changes in

configuration data that it is not allowed to read by detecting changes

in the Last-Modified/ETag values.=C2=A0 This probably isn't a security<=
br>
problem, but the authors should be aware of it.




done; added security co=
nsiderations note
=C2=A0

4.6



=C2=A0 =C2=A0Each patch mechanism needs a unique media type.=C2=A0 Zero or =
more patch

=C2=A0 =C2=A0media types MAY be supported by the server.=C2=A0 The media ty=
pes

=C2=A0 =C2=A0supported by a server can be discovered by the client by sendi=
ng an

=C2=A0 =C2=A0OPTIONS request (see Section 4.1).



To prevent the reader from making the mistake I just made, it would be

helpful to explicitly state that it is the Accept-Patch header in the

OPTIONS response, rather than an enumeration of the allowed content

types generally, that should be examined.=C2=A0 (An enumeration of allowed<=
br>
content types generally doesn't exist in HTTP, but does in SIP.)



=C2=A0 =C2=A0A server's response to an OPTIONS request (see Section 4.1=
) lists

=C2=A0 =C2=A0the patch media types it supports in the Accept-Patch header.<=
br>



done; added clarificati=
on

=C2=A0

4.6



Yang has been extended to allow non-unique key values.=C2=A0 The result is<=
br>
that URLs may identify multiple data instances.=C2=A0 This seems to be

specified for GET (if JSON is used, GET can return multiple instances;

if XML is used, a 400 response is given) and DELETE (only one instance

(arbitrarily chosen) is deleted; this may be modified by query

parameters).=C2=A0 But PATCH does not seem to specify the behavior if

multiple instances are selected.




*** not sure what the p=
revious comment is requested... perhaps sec. # =C2=A0is wrong
=C2=A0

4.8.2



=C2=A0 =C2=A0By default, the server will include all sub-resources within a=


=C2=A0 =C2=A0retrieved resource, which have the same resource type as the
=C2=A0 =C2=A0requested resource.=C2=A0 Only one level of sub-resources with=
 a different

=C2=A0 =C2=A0media type than the target resource will be returned.=C2=A0 Th=
e exception

=C2=A0 =C2=A0is the datastore resource.=C2=A0 If this resource type is retr=
ieved then

=C2=A0 =C2=A0by default the datastore and all child data resources are retu=
rned.



[Note for the -13 draft:]=C2=A0 Does the second sentence do anything?=C2=A0=
 The

only instance I know of of a node whose media type is different from

that of its child nodes is the the datastore resource, and that is

specifically exempted from the effect of the 2nd sentence.




done; 2nd sentence remo=
ted

=C2=A0

With the -14 draft, there are only two media types, and which one is

used to report the contents of a resource is determined by the client,

as a choice of encoding, rather than as an attribute of the resource.

So I think this paragraph has no effect any more.



Only the 2nd sentence mentioned media =
type, which is now removed.
It is relevant for resource types.=C2=
=A0 We don't want a GET of the entry point
to return all the =
data resources.

=C2=A0

12.=C2=A0 Security Considerations



=C2=A0 =C2=A0 The lowest NETCONF layer is the secure transport layer,

=C2=A0 =C2=A0and the mandatory-to-implement secure transport is Secure Shel=
l

=C2=A0 =C2=A0(SSH) ^RFC6242^. The NETCONF access control model ^RFC6536^
=C2=A0 =C2=A0provides the means to restrict access for particular NETCONF u=
sers

=C2=A0 =C2=A0to a pre-configured subset of all available NETCONF protocol
=C2=A0 =C2=A0operations and content.



The formatting of this paragraph is damaged:=C2=A0 There is an extra space<=
br>
at its beginning, and references are marked ^...^ rather than [...].



done; also caused the reference to RFC=
 6242 to be missed
=C2=A0

13



Who is The Space & Terrestrial Communications Directorate?=C2=A0 Maybe =
it

would add to the credit of the S&TCD by prefixing the country that

funds it ... which seems to be "United States Army".




done

=C2=A0

Dale



_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf





--001a11398fe6263f5b053689cff6--


From nobody Thu Jun 30 21:13:32 2016
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 4430312D0D1 for ; Thu, 30 Jun 2016 21:13:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 7S5BgKUzjv-h for ; Thu, 30 Jun 2016 21:13:26 -0700 (PDT)
Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 2251112D0C5 for ; Thu, 30 Jun 2016 21:13:26 -0700 (PDT)
Received: by mail-vk0-x22c.google.com with SMTP id u68so95500251vkf.2 for ; Thu, 30 Jun 2016 21:13:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SLiwGwVn648n5CSUrGKGssvHZr3Q2B8z4aqDLOv2/U4=; b=chX3QwCqFht8fzRuqwnG9/zJ0m7PGjT+/rsi7BMVed9m86dpykNahd7c/3VGukP3dR w3UoimOpukv7J4UuhinKht+KQ9f5BIVo6RkCFiCx+qhLs2TFPgiAaH28/y7396D0Nm4X XzrN75SXBSr4fc4ORFqjmUNnwDZ2n1cIW7+hkqo46aSOB5w5/3hEWoTywMWcZcDTNioZ tPW5Hts6Jf3UkhRzN8cSG06ozMQTF2YpQBCcDfkMIn+pMbz+dNKltbp94reVkIRCHcrF 3OiAkXloGdTdRPgJ6bLY7Dsskne2fiBmMxy2azzZFdz+1DLEwQKYJKwqURGMFUe1JRrQ yV5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SLiwGwVn648n5CSUrGKGssvHZr3Q2B8z4aqDLOv2/U4=; b=kgJ0KtvVIIb0rIQANEwby4+Ku8F3B3unvMr8c0UoRJeix692sBd+M0RWk9SgTnt9za g3I3xABh6yIp0V6XKQYsEQgxMqTxVGJIOGXEXlWwccc/3HUvilSM8KitHw987L4BtiR8 O2ZIfHtawDxxl9c9YptjTLurCo8e1C1hORQ3S6HeqmSJtM2LC/8NJmVYrTsw+fBLx2ec /SZC46U3trPx3TkDqArZITwY0hsVorQLANuUX86C7R/2JrbUWEz9kdZlrUAri90D7K+O Io1uXHARY2pJN5GoMBbjxy+YjHEqAPUrJEKBCy0Es2gJqluxZeXJI0Hc+EnflpEC+gll m00g==
X-Gm-Message-State: ALyK8tI7Jcu+ihEJCzq2KUB5CLvbu5w269tA+Pg3m9lC7BxxBGSj33gBb0KgYcdaGZz9PZbZ3Zazdz7Sb3KeEg==
X-Received: by 10.31.232.67 with SMTP id f64mr7292022vkh.44.1467346405122; Thu, 30 Jun 2016 21:13:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Thu, 30 Jun 2016 21:13:23 -0700 (PDT)
In-Reply-To: <4e94400e-62fa-c472-9ea1-c606fcbde026@cisco.com>
References: <5612db74-b32b-164d-c71c-daf669e6b142@cisco.com> <2cb94ab9-9c1d-77ae-eb8b-2d41ba39f495@cisco.com> <4e94400e-62fa-c472-9ea1-c606fcbde026@cisco.com>
From: Andy Bierman 
Date: Thu, 30 Jun 2016 21:13:23 -0700
Message-ID: 
To: Benoit Claise 
Content-Type: multipart/alternative; boundary=94eb2c09493a3d7c3905368b3513
Archived-At: 
Cc: NETCONF 
Subject: Re: [Netconf] AD review of draft-ietf-netconf-restconf-13
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Jul 2016 04:13:30 -0000

--94eb2c09493a3d7c3905368b3513
Content-Type: text/plain; charset=UTF-8

On Wed, Jun 29, 2016 at 6:13 AM, Benoit Claise  wrote:

> Dear authors,
>
> Thanks for this new draft. I removed the points that are integrated.
> Note: I wished that the authors had replied with the points (not)
> addressed, instead of me spending a couple of hours reviewing all comments
> and diffs.
>
> First of, there is an issue with the YANG module extraction
>
> xym.py draft-ietf-netconf-restconf-14.txt
> ERROR: 'draft-ietf-netconf-restconf-14.txt', Line 3930 - 'module'
> statement within another module
> Created the following models::
>    example-ops.yang
>    example-actions.yang
>    example-jukebox.yang
>    example-mod.yang
>
>
I did not get any YANG errors in idnits.
It is true that we validate the example modules without the --ietf option.
IMO, this MUST only be for modules enclosed in  

We never resolved the issue of  
There was no consensus that it was needed or how to do it.
So let's decide now.





Not an issue with the draft, but with the xym.py that can't deal with a
> module example in a description:
>
> container operations {
>            description
>              "Container for all operation resources
>               (application/yang-operation),
>
>               Each resource is represented as an empty leaf with the
>               name of the RPC operation from the YANG rpc statement.
>               For example, the 'system-restart' RPC operation defined
>               in the 'ietf-system' module would be represented as
>               an empty leaf in the 'ietf-system' namespace. This is
>               a conceptual leaf, and will not actually be found in
>               the module:
>
>                  module ietf-system {                        <=====
>                    leaf system-reset {
>                      type empty;
>                    }
>                  }
>
>
>
> Bug filed for xym.py
> Testing https://github.com/donaldh/yang-extractor (which I learned of
> today), it works fine on this draft.
> Currently testing the other drafts.
>
> See in-line.
>
> Dear all,
>
> Here is my draft-ietf-netconf-restconf-13 AD review
> [sorry for the delay, it took longer than expected].
> If some of the points have already been discussed, let me know.
>
> - https://github.com/netconf-wg/restconf/issues?q=is%3Aopen+is%3Aissue
> There are still open issues. I would have expected that all issues are closed. Should I be worried?
>
> - From the charter:
>    The RESTCONF work will consider requirements suggested by the other working groups
>    (for example I2RS).
>
> Are we good in terms of I2RS requirements for RESTCONF, if any?
>
> I need to follow up with the I2RS chairs and AD on this one.
>

OK


> - section 1
> RESTCONF is based on HTTP1.1 [RFC7230]
> What about HTTP2 [RFC7540]?
> I've seen some discussions on the NETCONF mailing but I'm unclear if RESTCONF would work with HTTP2.
> A few words are necessary IMO.
> background: https://www.ietf.org/mail-archive/web/netconf/current/msg08578.html
> I see in section 2.1
>    No other versions of HTTP are supported for use with RESTCONF.
> Do you mean:
>    No other versions than HTTP 1.1 are supported for use with RESTCONF.
> So:
>    HTTP2.0 MUST NOT be used with RESTCONF.
> If this is the case, some sort of justification is required.
>
>
> You have to say something about HTTP2
>


The WG needs to decide what to say, and what section needs to be updated.
There is a lot of text that cites HTTP 1.1.

I would prefer a small number of edits; MUST support HTTP 1.1; MAY support
HTTP/2






> - section 1.1.3
> non-presence container (or NP-container)
> presence container (or P-container)
>
> As Lionel Morand mentioned in his OPS-DIR draft-ietf-netmod-rfc6020bis-11 review:
>
> LM: "non-presence container" is not defined anywhere in the document.
>     I can assume that it refers to a container that does not have a
>     "presence" statement. If it is, it could be good to:
>     define the term in the section 3 and to extend the existing text in
>     the section 7.5.5
>
> The idea is to refer to the definitions in RFC6020bis, now that they have
> been introduced:
>
> container: An interior data node that exists in at most one
>       instance in the data tree.  A container has no value, but rather a
>       set of child nodes.
>
>    o  non-presence container: A container that has no meaning of its
>       own, existing only to contain child nodes.
>
>    o  presence container: A container where the presence of the
>       container itself carries some meaning.
>
>       own, existing only to contain child nodes.
>
>
>
>

I removed terms that were not actually used in draft-13




> - "Last-Modified"
> This is one of those topics whose requirements are all over the place. This is confusing (at least to me)
>
>

You are right.  It needs more work.
I want to make sure we can support datastore-specific timestamps and entity
tags
for ephemeral and other datastores.




    RT                                   Last-Modified              ETag

    API                                       none                      none

    Operation                              none                    none

    Datastore                               SHOULD            MUST

    Data                                        MAY                   SHOULD

    restconf-state/capabilities      MAY                    SHOULD


(Examples show Last-Modified returned for API)

Section 3.4.1.1
>    The last change time is maintained and the "Last-Modified"
>    ([RFC7232], Section 2.2 ) header is returned in the response for a
>    retrieval request.  The "If-Unmodified-Since" header can be used in
>    edit operation requests to cause the server to reject the request if
>    the resource has been modified since the specified timestamp.
>
>
edit detection


> Section 3.5
>    For configuration data resources, the server MAY maintain a last-
>    modified timestamp for the resource, and return the "Last-Modified"
>    header when it is retrieved with the GET or HEAD methods.
>
>
data resource


> Section 9.1
>    The server MUST maintain a last-modified timestamp for this
>    container, and return the "Last-Modified" header when this data node
>    is retrieved with the GET or HEAD methods.
>
>

/restconf-state/capabilities  (this is MAY/SHOULD in draft-14)



> Section 10.1
>    The server MUST maintain a last-modified timestamp for this
>    container, and return the "Last-Modified" header when this data node
>    is retrieved with the GET or HEAD methods.
>
>

this was removed in draft-14


>
> Section 10.1.1
>    The server SHOULD maintain a last-modified timestamp for each
>    instance of this list entry, and return the "Last-Modified" header
>    when this data node is retrieved with the GET or HEAD methods.
>
>

this was removed in draft-14


> and potentially some more sections
>
>

I checked but cannot find more



> At the minimum, we should have forward references from section 3.4.1.1 as it looks like self-contained.
>
> This one has been addressed?
>


done (in -15)


> Same remark for entity-tag and section 3.4.1.2
>
> And this one?
>


done  (in -15)



> - Section 3.6
> OLD:
>    If the "rpc" or "action" statement has an "input" section, then a
>    message-body MAY be sent by the client in the request, otherwise the
>    request message MUST NOT include a message-body.  If the "input"
>    objcet tree contains mandatory parameters, then a message-body MUST
>    be sent by the client.
>
> NEW:
>
>    If the "rpc" or "action" statement has an "input" section and the
>    "input" object tree contains mandatory parameters, then a message-body
>    MUST be sent by the client in the request.
>
>    If the "rpc" or "action" statement has an "input" section and the
>    "input" object tree doesn't contain mandatory parameters, then a message-body
>    MAY be sent by the client in the request.
>
>    If the "rpc" or "action" statement has no "input" section, the
>    request message MUST NOT include a message-body.
>
>
>

this edit is done except exact replacement text not used.
Will be modified in -15 related to Dale's comments.



>    If the "rpc" or "action" statement has an "output" section then
>    instances of these *input *parameters are encoded in the module
>    namespace where the "rpc" or "action" statement is defined, in an XML
>    element or JSON object named "output".
>
>

fixed cut-and-paste 'input' (in -15)




> Input or output?
>
> - RFC5277 is a normative reference.
> I guess that pub/sub will obsolete RFC5277.
> So we would have to update this RESTCONF RFC-to-be with the pub/sub publication?
>
> And the answer is?
>


I certainly do not agree that RFC 5277 is going to be obsolete.
Adding new features should not make existing deployed functionality
obsolete.
IMO, the new work must update 5277, not replace it.



>  - 5.3.2 Json MetaData Encoding Example
>
>    Note that RFC 6243  defines the "default" attribute with XSD, not
>    YANG, so *the YANG module name has to be assigned manually*.  The value
>    "ietf-netconf-with-defaults" is assigned for JSON meta-data encoding.
>
> I don't understand "*the YANG module name has to be assigned manually*"
>
> And I still don't understand. Care to reply?
>
>


fixed (in -15)
assigned instead of derived from a YANG module name.



>
>
> -
> Since we have many examples around around example-jukebox, this should pass compilation, right?
>
> pyang --ietf example-jukebox.yang
>
>


I disagree that --ietf should be added to the validation of non-normative
modules.



> example-jukebox.yang:1: error: expected keyword "namespace" as child to "module"
> example-jukebox.yang:1: error: expected keyword "prefix" as child to "module"
> example-jukebox.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-"
> example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "contact" substatement
> example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "organization" substatement
> example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "description" substatement
> example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "revision" substatement
>
> What was the agreed convention for example modules that should pass compilation?
>
> care to reply?
>
- Security Considerations.
> Please include https://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines
>
>
this was done in -14




>
>
>
> Regards, Benoit (OPS AD)
>
>
>
>
>


Andy

--94eb2c09493a3d7c3905368b3513
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Jun 29, 2016 at 6:13 AM, Benoit Claise <bclaise@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    
Dear authors,

      

      Thanks for this new draft. I removed the points that are
      integrated.

      Note: I wished that the authors had replied with the points (not)
      addressed, instead of me spending a couple of hours reviewing all
      comments and diffs.

      

      First of, there is an issue with the YANG module extraction

      
xym.py draft-ietf-netconf-restconf-14.txt 

        ERROR: 'draft-ietf-netconf-restconf-14.txt', Line 3930 -
        'module' statement within another module

        Created the following models::

        =C2=A0=C2=A0 example-ops.yang

        =C2=A0=C2=A0 example-actions.yang

        =C2=A0=C2=A0 example-jukebox.yang

        =C2=A0=C2=A0 example-mod.yang

I did not get any YANG errors in idnits.
=
It is true that we validate the example modules without the --ietf option.<=
/div>
IMO, this MUST only be for modules enclosed in <CODE BEGINS>=
; <CODE ENDS>

We never resolved the issue of=
 <EXAMPLE-BEGINS> <EXAMPLE-ENDS>
There was no consens=
us that it was needed or how to do it.
So let's decide now.






      

      Not an issue with the draft, but with the xym.py that can't deal
      with a module example in a description:

      

        
container operations {
           description
             "Container for all operation resources
              (application/yang-operation),

              Each resource is represented as an empty leaf with the
              name of the RPC operation from the YANG rpc statement.
              For example, the 'system-restart' RPC operation defin=
ed
              in the 'ietf-system' module would be represented as
              an empty leaf in the 'ietf-system' namespace. This is
              a conceptual leaf, and will not actually be found in
              the module:

                 module ietf-system {                        <=3D=3D=3D=
=3D=3D
                   leaf system-reset {
                     type empty;
                   }
                 }

        =C2=A0

      Bug filed for xym.py

      Testing https://github.com/donaldh/yang-extractor (which I learned
      of today), it works fine on this draft.

      Currently testing the other drafts.

      

      See in-line.

    

    

     =20
      Dear all,

      
 

        Here is my draft-ietf-netconf-restconf-13 AD review 

        [sorry for the delay, it took longer than expected].

        If some of the points have already been discussed, let me know.

        

        

          
- https://github.com/netconf-wg/re=
stconf/issues?q=3Dis%3Aopen+is%3Aissue
There are still open issues. I would have expected that all issues are clos=
ed. Should I be worried?    

          

            

              

                
- From the charter:
   The RESTCONF work will consider requirements suggested by the other work=
ing groups=20
   (for example I2RS).

Are we good in terms of I2RS requirements for RESTCONF, if any?

              

            

          

        

      

    

    I need to follow up with the I2RS chairs and AD on this one.
<=
/blockquote>

OK
=C2=A0

    

      

        

          

            

              

                
- section 1
RESTCONF is based on HTTP1.1 [RFC7230]
What about HTTP2 [RFC7540]?=20
I've seen some discussions on the NETCONF mailing but I'm unclear i=
f RESTCONF would work with HTTP2.
A few words are necessary IMO.
background: https://www.ietf.org/mail-archive/web/ne=
tconf/current/msg08578.html
I see in section 2.1
   No other versions of HTTP are supported for use with RESTCONF.
Do you mean:
   No other versions than HTTP 1.1 are supported for use with RESTCONF.
So:
   HTTP2.0 MUST NOT be used with RESTCONF.
If this is the case, some sort of justification is required.



              

            

          

        

      

    

    You have to say something about HTTP2


The WG needs to decide what to say, and what sectio=
n needs to be updated.
There is a lot of text that cites HTTP 1.1=
.

I would prefer a small number of edits; MUST sup=
port HTTP 1.1; MAY support HTTP/2


<=
br>

=C2=A0

    

      

        

          

            

              

                
- section 1.1.3
non-presence container (or NP-container)
presence container (or P-container)

As Lionel Morand mentioned in his OPS-DIR draft-ietf-netmod-rfc6020bis-11 r=
eview:


                

                  
LM: "non-presence container" is not define=
d anywhere in the document.
    I can assume that it refers to a container that does not have a=20
    "presence" statement. If it is, it could be good to:
    define the term in the section 3 and to extend the existing text in=20
    the section 7.5.5

                

              

            

          

        

      

    

    The idea is to refer to the definitions in RFC6020bis, now that they
    have been introduced:

    
container: An interior data node that exists in at most one
      instance in the data tree.  A container has no value, but rather a
      set of child nodes.

   o  non-presence container: A container that has no meaning of its
      own, existing only to contain child nodes.

   o  presence container: A container where the presence of the
      container itself carries some meaning.

      own, existing only to contain child nodes.



    

      

        

          

            

              



I removed terms t=
hat were not actually used in draft-13


<=
div>=C2=A0

                
- "Last-Modified"
This is one of those topics whose requirements are all over the place. This=
 is confusing (at least to me)


You are right.=C2=A0 It needs more work.
<=
div>I want to make sure we can support datastore-specific timestamps and en=
tity tags
for ephemeral and other datastores.




=C2=A0 =C2=A0 RT =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Last-Modified =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0ETag

=C2=A0 =C2=A0 API =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 none =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0none

=C2=A0 =C2=A0 Operation =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0none =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0none

=C2=A0 =C2=A0 Datastore =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 SHOULD =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST

=C2=A0 =C2=A0 Data =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 SHOULD

=C2=A0 =C2=A0 restconf=
-state/capabilities =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SHOULD


<=
/div>
(Examples show Last-Modified returned for API)

=

Section 3.4.1.1=20
   The last change time is maintained and the "Last-Modified"
   ([RFC7232], Section=C2=A02.2) header is returned in the response =
for a
   retrieval request.  The "If-Unmodified-Since" header can be us=
ed in
   edit operation requests to cause the server to reject the request if
   the resource has been modified since the specified timestamp.

edit detection
=C2=A0
<=
div>
Section 3.5
   For configuration data resources, the server MAY maintain a last-
   modified timestamp for the resource, and return the "Last-Modified&=
quot;
   header when it is retrieved with the GET or HEAD methods.

data resource
=C2=A0
Section 9.1
   The server MUST maintain a last-modified timestamp for this
   container, and return the "Last-Modified" header when this dat=
a node
   is retrieved with the GET or HEAD methods.


/restconf-state/capabilities =C2=A0(this is MAY=
/SHOULD in draft-14)

=C2=A0
Section 10.1
   The server MUST maintain a last-modified timestamp for this
   container, and return the "Last-Modified" header when this dat=
a node
   is retrieved with the GET or HEAD methods.
=



th=
is was removed in draft-14
=C2=A0
Section 10.1.1
   The server SHOULD maintain a last-modified timestamp for each
   instance of this list entry, and return the "Last-Modified" he=
ader
   when this data node is retrieved with the GET or HEAD methods.


this was removed in draft-14
=C2=A0
and potentially s=
ome more sections


I checked but cannot find more=


=C2=A0
At the minimum, we should have forward references from sec=
tion 3.4.1.1 as it looks like self-contained.

              

            

          

        

      

    

    This one has been addressed?
=C2=A0
=C2=A0
done (in -15)
=C2=A0
Same remark for entity-tag and section 3.=
4.1.2

              

            

          

        

      

    

    And this one?


=
done =C2=A0(in -15)

=C2=A0

    

      

        

          

            

              

                
- Section 3.6
OLD:
   If the "rpc" or "action" statement has an "inpu=
t" section, then a
   message-body MAY be sent by the client in the request, otherwise the
   request message MUST NOT include a message-body.  If the "input&quo=
t;
   objcet tree contains mandatory parameters, then a message-body MUST
   be sent by the client.=20

NEW:

   If the "rpc" or "action" statement has an "inpu=
t" section and the=20
   "input" object tree contains mandatory parameters, then a mess=
age-body=20
   MUST be sent by the client in the request.=20

   If the "rpc" or "action" statement has an "inpu=
t" section and the=20
   "input" object tree doesn't contain mandatory parameters, =
then a message-body=20
   MAY be sent by the client in the request.=20
  =20
   If the "rpc" or "action" statement has no "inpu=
t" section, the
   request message MUST NOT include a message-body.  

              

            

          

        

      

    

    


this edit is =
done except exact replacement text not used.
Will be modified in =
-15 related to Dale's comments.

=C2=A0

    
   If the "rpc" or "action" statement has an &=
quot;output" section then
   instances of these input parameters are encoded in the module
   namespace where the "rpc" or "action" statement is d=
efined, in an XML
   element or JSON object named "output".



fixed cut-and-p=
aste 'input' (in -15)


=C2=
=A0
Input or output?


    

      

        

          

            

              

                
- RFC5277 is a normative reference.=20
I guess that pub/sub will obsolete RFC5277.
So we would have to update this RESTCONF RFC-to-be with the pub/sub publica=
tion? 

              

            

          

        

      

    

    And the answer is?


I certainly do not agree that RFC 5277 is going to be obsolete.=C2=A0
Adding new features should not make existing deployed functionality o=
bsolete.
IMO, the new work must update 5277, not replace it.

=C2=A0

    

      

        

          

            

              

                

              

            

          

        

      

    

    

      

        

          

            

              

                
=C2=A0- 5.3.2 Json MetaData Encoding Example

                
   Note that RFC 6243 defines the "default" attri=
bute with XSD, not
   YANG, so the YANG module name has to be assigned manually.  The v=
alue
   "ietf-netconf-with-defaults" is assigned for JSON meta-data en=
coding.

I don't understand "the YANG module name has to be assigned man=
ually"

              

            

          

        

      

    

    And I still don't understand. Care to reply?
    

      

        

          

            

              

                



fixed (in -=
15)
assigned instead of derived from a YANG module name.

=C2=A0
 =20

-=20
Since we have many examples around around example-jukebox, this should pass=
 compilation, right?=20

pyang --ietf example-jukebox.yang 



I disagree that --ietf should be added to the validation of non-normative=
 modules.

=C2=A0
example-jukebox.yang:1: error: expected keyword &=
quot;namespace" as child to "module"
example-jukebox.yang:1: error: expected keyword "prefix" as child=
 to "module"
example-jukebox.yang:1: warning: RFC 6087: 4.1: the module name should star=
t with one of the strings "ietf-" or "iana-"
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" =
must have a "contact" substatement
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" =
must have a "organization" substatement
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" =
must have a "description" substatement
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" =
must have a "revision" substatement

What was the agreed convention for example modules that should pass compila=
tion?

              

            

          

        

      

    

    care to reply?
this was done in -14


=
=C2=A0


Regards, Benoit (OPS AD)

      

              

            

          

        

      

      



Andy
=C2=A0


--94eb2c09493a3d7c3905368b3513--


From nobody Thu Jun 30 21:21:51 2016
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 0E77912D0C5 for ; Thu, 30 Jun 2016 21:21:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 Ab20bqojgU_v for ; Thu, 30 Jun 2016 21:21:46 -0700 (PDT)
Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 5482712B049 for ; Thu, 30 Jun 2016 21:21:45 -0700 (PDT)
Received: by mail-vk0-x22b.google.com with SMTP id m127so78727401vkb.3 for ; Thu, 30 Jun 2016 21:21:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=agJI2uV6fDdu7EChUuH7zcf6mdCUoeH0DuENXiEsbVE=; b=vtaIomHVRhRIyDxToXp2dvtZ8gMrAIRMuh23jqHU78C+ZVnEbQ3nb/QlmHlT1uiu+k ElxqpIT6KiVoliWYoC1qU4jpRzG01vKS1pCy5+Vp0SfaYO9gro/8/nBUN2Rbr210vYbR q2IZbKhm/U+BXBuBA5KH6yxOZI0QnSS9U8CyeLrGtn6sWMgADbnpXQm0cXNmhflEgR1A 6KElkFTiOPL5S2ZWRqXPeT9IbLkvkBGQydVzfDjZQPCD7flgO2R7EbrRVHo1Jll9fL01 hLrwhRS8YncjBifKMIZI9n4AmW0lwgcyDgorkpmfe/C8JxUtMxD8EvPJZhwWpL2GeW0y Va1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=agJI2uV6fDdu7EChUuH7zcf6mdCUoeH0DuENXiEsbVE=; b=hbAggUeCTGa5TwRZJNb/UMueENaB6c9wD2qB8T2uw0uSG/PjIXJTWd1LpRFp8NdNOv A6vtQVoueW/UW4mg5vnfAaqaHgZuFUG8518gXnEvqzcYz2BXsT31k5af4NaxwvyRl66s xZSUtrWajWC5mtu6VRaZNn8dkGr4ja/bxXpgNlOJgSlM3vEVt2vTww+Hi3oTFN81NCd6 5kczAfAw7cKeMAT6KQy6Fg5++Djjsc7MuxddanfE01zkMLZHc4uKvwU4BwoLPphO39ZY pQ1ECJbWDDbDvZGSEdGZKJgQHqzab4BU4Hk3d2z3koI4QrCSLfQwa+5J3gzrCdMpSod3 81rg==
X-Gm-Message-State: ALyK8tKJa3ydVbVMyVvagyzlrX5+ROJxu6X9gYKkHYffQKUO6XBuOQOuqjx2IAwXnKFd+AH6xWdwhQD1wHUv6w==
X-Received: by 10.159.36.245 with SMTP id 108mr8657664uar.121.1467346904448; Thu, 30 Jun 2016 21:21:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Thu, 30 Jun 2016 21:21:43 -0700 (PDT)
In-Reply-To: <991800b7-d50e-7c22-af96-96bfe6742240@cisco.com>
References: <5612db74-b32b-164d-c71c-daf669e6b142@cisco.com> <2cb94ab9-9c1d-77ae-eb8b-2d41ba39f495@cisco.com> <4e94400e-62fa-c472-9ea1-c606fcbde026@cisco.com> <991800b7-d50e-7c22-af96-96bfe6742240@cisco.com>
From: Andy Bierman 
Date: Thu, 30 Jun 2016 21:21:43 -0700
Message-ID: 
To: Benoit Claise 
Content-Type: multipart/alternative; boundary=001a11398fe6009a7a05368b53be
Archived-At: 
Cc: NETCONF 
Subject: Re: [Netconf] AD review of draft-ietf-netconf-restconf-13
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Jul 2016 04:21:50 -0000

--001a11398fe6009a7a05368b53be
Content-Type: text/plain; charset=UTF-8

On Wed, Jun 29, 2016 at 6:38 AM, Benoit Claise  wrote:

> Btw,
>
> list access {
>              key encoding;
>              min-elements 1;
>              description
>                "The server will create an entry in this list for each
>                 encoding format that is supported for this stream.
>                 The media type 'application/yang-stream' is expected
>                 for all event streams. This list identifies the
>                 sub-types supported for this stream.";
>
> Should this media type be registered?
>


This is a typo.  It should be text/event-stream. (fixed ni -15)

The references to the media type application/yang-stream+xml
and application/yang-stream+json in the "encoding" leaf will be removed in
-15.




>
> Regards, B.
>


Andy



> Dear authors,
>
> Thanks for this new draft. I removed the points that are integrated.
> Note: I wished that the authors had replied with the points (not)
> addressed, instead of me spending a couple of hours reviewing all comments
> and diffs.
>
> First of, there is an issue with the YANG module extraction
>
> xym.py draft-ietf-netconf-restconf-14.txt
> ERROR: 'draft-ietf-netconf-restconf-14.txt', Line 3930 - 'module'
> statement within another module
> Created the following models::
>    example-ops.yang
>    example-actions.yang
>    example-jukebox.yang
>    example-mod.yang
>
> Not an issue with the draft, but with the xym.py that can't deal with a
> module example in a description:
>
> container operations {
>            description
>              "Container for all operation resources
>               (application/yang-operation),
>
>               Each resource is represented as an empty leaf with the
>               name of the RPC operation from the YANG rpc statement.
>               For example, the 'system-restart' RPC operation defined
>               in the 'ietf-system' module would be represented as
>               an empty leaf in the 'ietf-system' namespace. This is
>               a conceptual leaf, and will not actually be found in
>               the module:
>
>                  module ietf-system {                        <=====
>                    leaf system-reset {
>                      type empty;
>                    }
>                  }
>
>
>
> Bug filed for xym.py
> Testing https://github.com/donaldh/yang-extractor (which I learned of
> today), it works fine on this draft.
> Currently testing the other drafts.
>
> See in-line.
>
> Dear all,
>
> Here is my draft-ietf-netconf-restconf-13 AD review
> [sorry for the delay, it took longer than expected].
> If some of the points have already been discussed, let me know.
>
> - https://github.com/netconf-wg/restconf/issues?q=is%3Aopen+is%3Aissue
> There are still open issues. I would have expected that all issues are closed. Should I be worried?
>
> - From the charter:
>    The RESTCONF work will consider requirements suggested by the other working groups
>    (for example I2RS).
>
> Are we good in terms of I2RS requirements for RESTCONF, if any?
>
> I need to follow up with the I2RS chairs and AD on this one.
>
> - section 1
> RESTCONF is based on HTTP1.1 [RFC7230]
> What about HTTP2 [RFC7540]?
> I've seen some discussions on the NETCONF mailing but I'm unclear if RESTCONF would work with HTTP2.
> A few words are necessary IMO.
> background: https://www.ietf.org/mail-archive/web/netconf/current/msg08578.html
> I see in section 2.1
>    No other versions of HTTP are supported for use with RESTCONF.
> Do you mean:
>    No other versions than HTTP 1.1 are supported for use with RESTCONF.
> So:
>    HTTP2.0 MUST NOT be used with RESTCONF.
> If this is the case, some sort of justification is required.
>
>
> You have to say something about HTTP2
>
> - section 1.1.3
> non-presence container (or NP-container)
> presence container (or P-container)
>
> As Lionel Morand mentioned in his OPS-DIR draft-ietf-netmod-rfc6020bis-11 review:
>
> LM: "non-presence container" is not defined anywhere in the document.
>     I can assume that it refers to a container that does not have a
>     "presence" statement. If it is, it could be good to:
>     define the term in the section 3 and to extend the existing text in
>     the section 7.5.5
>
> The idea is to refer to the definitions in RFC6020bis, now that they have
> been introduced:
>
> container: An interior data node that exists in at most one
>       instance in the data tree.  A container has no value, but rather a
>       set of child nodes.
>
>    o  non-presence container: A container that has no meaning of its
>       own, existing only to contain child nodes.
>
>    o  presence container: A container where the presence of the
>       container itself carries some meaning.
>
>       own, existing only to contain child nodes.
>
>
>
> - "Last-Modified"
> This is one of those topics whose requirements are all over the place. This is confusing (at least to me)
>
> Section 3.4.1.1
>    The last change time is maintained and the "Last-Modified"
>    ([RFC7232], Section 2.2 ) header is returned in the response for a
>    retrieval request.  The "If-Unmodified-Since" header can be used in
>    edit operation requests to cause the server to reject the request if
>    the resource has been modified since the specified timestamp.
>
> Section 3.5
>    For configuration data resources, the server MAY maintain a last-
>    modified timestamp for the resource, and return the "Last-Modified"
>    header when it is retrieved with the GET or HEAD methods.
>
> Section 9.1
>    The server MUST maintain a last-modified timestamp for this
>    container, and return the "Last-Modified" header when this data node
>    is retrieved with the GET or HEAD methods.
>
> Section 10.1
>    The server MUST maintain a last-modified timestamp for this
>    container, and return the "Last-Modified" header when this data node
>    is retrieved with the GET or HEAD methods.
>
> Section 10.1.1
>    The server SHOULD maintain a last-modified timestamp for each
>    instance of this list entry, and return the "Last-Modified" header
>    when this data node is retrieved with the GET or HEAD methods.
>
> and potentially some more sections
> At the minimum, we should have forward references from section 3.4.1.1 as it looks like self-contained.
>
> This one has been addressed?
>
> Same remark for entity-tag and section 3.4.1.2
>
> And this one?
>
> - Section 3.6
> OLD:
>    If the "rpc" or "action" statement has an "input" section, then a
>    message-body MAY be sent by the client in the request, otherwise the
>    request message MUST NOT include a message-body.  If the "input"
>    objcet tree contains mandatory parameters, then a message-body MUST
>    be sent by the client.
>
> NEW:
>
>    If the "rpc" or "action" statement has an "input" section and the
>    "input" object tree contains mandatory parameters, then a message-body
>    MUST be sent by the client in the request.
>
>    If the "rpc" or "action" statement has an "input" section and the
>    "input" object tree doesn't contain mandatory parameters, then a message-body
>    MAY be sent by the client in the request.
>
>    If the "rpc" or "action" statement has no "input" section, the
>    request message MUST NOT include a message-body.
>
>
>    If the "rpc" or "action" statement has an "output" section then
>    instances of these *input *parameters are encoded in the module
>    namespace where the "rpc" or "action" statement is defined, in an XML
>    element or JSON object named "output".
>
> Input or output?
>
> - RFC5277 is a normative reference.
> I guess that pub/sub will obsolete RFC5277.
> So we would have to update this RESTCONF RFC-to-be with the pub/sub publication?
>
> And the answer is?
>
>  - 5.3.2 Json MetaData Encoding Example
>
>    Note that RFC 6243  defines the "default" attribute with XSD, not
>    YANG, so *the YANG module name has to be assigned manually*.  The value
>    "ietf-netconf-with-defaults" is assigned for JSON meta-data encoding.
>
> I don't understand "*the YANG module name has to be assigned manually*"
>
> And I still don't understand. Care to reply?
>
>
>
> -
> Since we have many examples around around example-jukebox, this should pass compilation, right?
>
> pyang --ietf example-jukebox.yang
> example-jukebox.yang:1: error: expected keyword "namespace" as child to "module"
> example-jukebox.yang:1: error: expected keyword "prefix" as child to "module"
> example-jukebox.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-"
> example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "contact" substatement
> example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "organization" substatement
> example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "description" substatement
> example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "revision" substatement
>
> What was the agreed convention for example modules that should pass compilation?
>
> care to reply?
>
> - Security Considerations.
> Please include https://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines
>
>
>
>
> Regards, Benoit (OPS AD)
>
>
>
>
>
> _______________________________________________
> Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf
>
>
>
>
> _______________________________________________
> Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>

--001a11398fe6009a7a05368b53be
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Jun 29, 2016 at 6:38 AM, Benoit Claise <bclaise@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    
Btw,

      

      
list access {
             key encoding;
             min-elements 1;
             description
               "The server will create an entry in this list for each
                encoding format that is supported for this stream.
                The media type 'application/yang-stream' is expecte=
d
                for all event streams. This list identifies the
                sub-types supported for this stream.";

      Should this media type be registered?
=C2=A0

This is a typo.=C2=A0 It should be text/e=
vent-stream. (fixed ni -15)

The references to the =
media type application/yang-stream+xml
and application/yang-strea=
m+json in the "encoding" leaf will be removed in -15.
<=
br>

=C2=A0

      

      Regards, B.


Andy

=C2=A0

    

    

     =20
      
Dear authors,

        

        Thanks for this new draft. I removed the points that are
        integrated.

        Note: I wished that the authors had replied with the points
        (not) addressed, instead of me spending a couple of hours
        reviewing all comments and diffs.

        

        First of, there is an issue with the YANG module extraction

        
xym.py draft-ietf-netconf-restconf-14.txt 

          ERROR: 'draft-ietf-netconf-restconf-14.txt', Line 3930 -
          'module' statement within another module

          Created the following models::

          =C2=A0=C2=A0 example-ops.yang

          =C2=A0=C2=A0 example-actions.yang

          =C2=A0=C2=A0 example-jukebox.yang

          =C2=A0=C2=A0 example-mod.yang

        

        Not an issue with the draft, but with the xym.py that can't dea=
l
        with a module example in a description:

        

          
container operations {
           description
             "Container for all operation resources
              (application/yang-operation),

              Each resource is represented as an empty leaf with the
              name of the RPC operation from the YANG rpc statement.
              For example, the 'system-restart' RPC operation defin=
ed
              in the 'ietf-system' module would be represented as
              an empty leaf in the 'ietf-system' namespace. This is
              a conceptual leaf, and will not actually be found in
              the module:

                 module ietf-system {                        <=3D=3D=3D=
=3D=3D
                   leaf system-reset {
                     type empty;
                   }
                 }

          =C2=A0

        Bug filed for xym.py

        Testing https://github.com/donaldh/yang-extractor
        (which I learned of today), it works fine on this draft.

        Currently testing the other drafts.

        

        See in-line.

      

      
 Dear all,

        
 

          Here is my draft-ietf-netconf-restconf-13 AD review 

          [sorry for the delay, it took longer than expected].

          If some of the points have already been discussed, let me
          know.

          

          

            
- https://github.com/netconf-wg/=
restconf/issues?q=3Dis%3Aopen+is%3Aissue
There are still open issues. I would have expected that all issues are clos=
ed. Should I be worried?    

            

              

                

                  
- From the charter:
   The RESTCONF work will consider requirements suggested by the other work=
ing groups=20
   (for example I2RS).

Are we good in terms of I2RS requirements for RESTCONF, if any?

                

              

            

          

        

      

      I need to follow up with the I2RS chairs and AD on this one.

      

        

          

            

              

                

                  
- section 1
RESTCONF is based on HTTP1.1 [RFC7230]
What about HTTP2 [RFC7540]?=20
I've seen some discussions on the NETCONF mailing but I'm unclear i=
f RESTCONF would work with HTTP2.
A few words are necessary IMO.
background: https://www.ietf.org/mail-archive/web/ne=
tconf/current/msg08578.html
I see in section 2.1
   No other versions of HTTP are supported for use with RESTCONF.
Do you mean:
   No other versions than HTTP 1.1 are supported for use with RESTCONF.
So:
   HTTP2.0 MUST NOT be used with RESTCONF.
If this is the case, some sort of justification is required.



                

              

            

          

        

      

      You have to say something about HTTP2

      

        

          

            

              

                

                  
- section 1.1.3
non-presence container (or NP-container)
presence container (or P-container)

As Lionel Morand mentioned in his OPS-DIR draft-ietf-netmod-rfc6020bis-11 r=
eview:


                  

                    
LM: "non-presence container" is not defi=
ned anywhere in the document.
    I can assume that it refers to a container that does not have a=20
    "presence" statement. If it is, it could be good to:
    define the term in the section 3 and to extend the existing text in=20
    the section 7.5.5

                  

                

              

            

          

        

      

      The idea is to refer to the definitions in RFC6020bis, now that
      they have been introduced:

      
container: An interior data node that exists in at most one
      instance in the data tree.  A container has no value, but rather a
      set of child nodes.

   o  non-presence container: A container that has no meaning of its
      own, existing only to contain child nodes.

   o  presence container: A container where the presence of the
      container itself carries some meaning.

      own, existing only to contain child nodes.



      

        

          

            

              

                


                  
- "Last-Modified"
This is one of those topics whose requirements are all over the place. This=
 is confusing (at least to me)

Section 3.4.1.1=20
   The last change time is maintained and the "Last-Modified"
   ([RFC7232], Section=C2=A02.2) header is returned in the response =
for a
   retrieval request.  The "If-Unmodified-Since" header can be us=
ed in
   edit operation requests to cause the server to reject the request if
   the resource has been modified since the specified timestamp.

Section 3.5
   For configuration data resources, the server MAY maintain a last-
   modified timestamp for the resource, and return the "Last-Modified&=
quot;
   header when it is retrieved with the GET or HEAD methods.

Section 9.1
   The server MUST maintain a last-modified timestamp for this
   container, and return the "Last-Modified" header when this dat=
a node
   is retrieved with the GET or HEAD methods.

Section 10.1
   The server MUST maintain a last-modified timestamp for this
   container, and return the "Last-Modified" header when this dat=
a node
   is retrieved with the GET or HEAD methods.

Section 10.1.1
   The server SHOULD maintain a last-modified timestamp for each
   instance of this list entry, and return the "Last-Modified" he=
ader
   when this data node is retrieved with the GET or HEAD methods.

and potentially some more sections
At the minimum, we should have forward references from section 3.4.1.1 as i=
t looks like self-contained.

                

              

            

          

        

      

      This one has been addressed?

      

        

          

            

              

                

                  
Same remark for entity-tag and section 3.4.1.2

                

              

            

          

        

      

      And this one?

      

        

          

            

              

                

                  
- Section 3.6
OLD:
   If the "rpc" or "action" statement has an "inpu=
t" section, then a
   message-body MAY be sent by the client in the request, otherwise the
   request message MUST NOT include a message-body.  If the "input&quo=
t;
   objcet tree contains mandatory parameters, then a message-body MUST
   be sent by the client.=20

NEW:

   If the "rpc" or "action" statement has an "inpu=
t" section and the=20
   "input" object tree contains mandatory parameters, then a mess=
age-body=20
   MUST be sent by the client in the request.=20

   If the "rpc" or "action" statement has an "inpu=
t" section and the=20
   "input" object tree doesn't contain mandatory parameters, =
then a message-body=20
   MAY be sent by the client in the request.=20
  =20
   If the "rpc" or "action" statement has no "inpu=
t" section, the
   request message MUST NOT include a message-body.  

                

              

            

          

        

      

      

      
   If the "rpc" or "action" statement has an=
 "output" section then
   instances of these input parameters are encoded in the module
   namespace where the "rpc" or "action" statement is d=
efined, in an XML
   element or JSON object named "output".

Input or output?


      

        

          

            

              

                

                  
- RFC5277 is a normative reference.=20
I guess that pub/sub will obsolete RFC5277.
So we would have to update this RESTCONF RFC-to-be with the pub/sub publica=
tion? 

                

              

            

          

        

      

      And the answer is?
      

        

          

            

              

                

                  

                

              

            

          

        

      

      

        

          

            

              

                

                  
=C2=A0- 5.3.2 Json MetaData Encoding Example

                  
   Note that RFC 6243 defines the "default" att=
ribute with XSD, not
   YANG, so the YANG module name has to be assigned manually.  The v=
alue
   "ietf-netconf-with-defaults" is assigned for JSON meta-data en=
coding.

I don't understand "the YANG module name has to be assigned man=
ually"

                

              

            

          

        

      

      And I still don't understand. Care to reply?
      

        

          

            

              

                

                  
 =20

-=20
Since we have many examples around around example-jukebox, this should pass=
 compilation, right?=20

pyang --ietf example-jukebox.yang=20
example-jukebox.yang:1: error: expected keyword "namespace" as ch=
ild to "module"
example-jukebox.yang:1: error: expected keyword "prefix" as child=
 to "module"
example-jukebox.yang:1: warning: RFC 6087: 4.1: the module name should star=
t with one of the strings "ietf-" or "iana-"
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" =
must have a "contact" substatement
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" =
must have a "organization" substatement
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" =
must have a "description" substatement
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" =
must have a "revision" substatement

What was the agreed convention for example modules that should pass compila=
tion?

                

              

            

          

        

      

      care to reply?
      

        

          

            

              

                

                  
- Security Considerations.
Please include https://trac.tools.ietf.org/area/=
ops/trac/wiki/yang-security-guidelines




Regards, Benoit (OPS AD)

      

                

              

            

          

        

        

        

        

        
_______________________________________________
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





--001a11398fe6009a7a05368b53be--