From nobody Tue Apr 2 08:22:49 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF8F120180; Tue, 2 Apr 2019 08:22:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Wesley Eddy via Datatracker To: Cc: draft-ietf-netconf-yang-push.all@ietf.org, ietf@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Wesley Eddy Message-ID: <155421856789.6325.9786625701476465519@ietfa.amsl.com> Date: Tue, 02 Apr 2019 08:22:47 -0700 Archived-At: Subject: [netconf] Tsvart last call review of draft-ietf-netconf-yang-push-22 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 15:22:48 -0000 Reviewer: Wesley Eddy Review result: Ready This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. I reviewed this in conjunction with the set of related WG documents on NETCONF/RESTCONF subscriptions and event notifications. On this specific document, I didn't find any issues, though I do have comments that will be send on other documents in the set, some of which may influence this once, since they are closely related. From nobody Tue Apr 2 09:32:16 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C02DF120166; Tue, 2 Apr 2019 09:32:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Wesley Eddy via Datatracker To: Cc: draft-ietf-netconf-netconf-event-notifications.all@ietf.org, ietf@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Wesley Eddy Message-ID: <155422272574.6262.7757640015847252701@ietfa.amsl.com> Date: Tue, 02 Apr 2019 09:32:05 -0700 Archived-At: Subject: [netconf] Tsvart last call review of draft-ietf-netconf-netconf-event-notifications-17 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 16:32:06 -0000 Reviewer: Wesley Eddy Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. I reviewed this in conjunction with the set of related WG documents on NETCONF/RESTCONF subscriptions and event notifications. I also have some comments on other documents in the set, some of which may influence this once, since they are closely related. In figure 3, and text on page 11, there is an example with a DiffServ codepoint value of "10". This could be interpreted as binary, decimal, hexadecimal, etc. It should be clear what the base is supposed to be. It seemed pretty ambiguous in this and the related documents, so it's not apparent that an implementer would be sure to get it right or for it to be compatible. I have other broad comments on the DSCP usage that will be in review comments for the subscribed-notifications draft where it is more appropriate. From nobody Tue Apr 2 09:42:46 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E968120169; Tue, 2 Apr 2019 09:42:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Wesley Eddy via Datatracker To: Cc: netconf@ietf.org, ietf@ietf.org, draft-ietf-netconf-restconf-notif.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Wesley Eddy Message-ID: <155422336508.6258.5897033458248231423@ietfa.amsl.com> Date: Tue, 02 Apr 2019 09:42:45 -0700 Archived-At: Subject: [netconf] Tsvart last call review of draft-ietf-netconf-restconf-notif-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 16:42:45 -0000 Reviewer: Wesley Eddy Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. I reviewed this in conjunction with the set of related WG documents on NETCONF/RESTCONF subscriptions and event notifications. I have comments that will be sent on other documents in the set, some of which may influence this once, since they are closely related. Figure 3 shows a DSCP value of 10, but it isn't clear what the number base is supposed to be, and this should be specified for this protocol, since many examples can be found in other material of DSCP values indicated in binary, decimal, or hexadecimal. In section 4, the first bullet discusses taking a "priority" and copying it into a "weighting" field. Since priority and weight can be different, though are closely related, this seems a bit confusing. I think the intention here for HTTP2 effects that are trying to be achieved should be discussed more so that it is clear to implementers and users what more specific effects this should have. From nobody Tue Apr 2 10:03:51 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8D7120181; Tue, 2 Apr 2019 10:03:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Wesley Eddy via Datatracker To: Cc: draft-ietf-netconf-subscribed-notifications.all@ietf.org, ietf@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Wesley Eddy Message-ID: <155422462845.6404.8212061582804708160@ietfa.amsl.com> Date: Tue, 02 Apr 2019 10:03:48 -0700 Archived-At: Subject: [netconf] Tsvart last call review of draft-ietf-netconf-subscribed-notifications-23 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 17:03:49 -0000 Reviewer: Wesley Eddy Review result: Almost Ready This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. The document includes a way intended to ask for a particular DiffServ Code Point (DSCP) value to be used by a publisher. This is missing some context. Why would a subscriber do this? Is it asking for DSCP values that it assumes are honored and not bleached or altered all the way between it and the publisher? Are there conditions normal for the use of this protocol where that assumption usually holds? By asking for a particular DSCP to be set, the subscriber is maybe attempting to optimize the behavior during some type of overload, where they really want some notifications quickly, but others aren't as important, and may be fine to drop and have retransmitted by TCP, etc. This all seems to be implicit though, with no deep discussion of what the protocol is attempting to enable with this option or how it would be productively used. It seems to be considered fatal if a publisher can't write a requested DSCP value. The requests fail with "dscp-unavailable". This seems too drastic, since the DSCP is anyways advisory to nodes on the path, and may be altered anyways. I'm not sure why this would be considered a fatal issue to the subscription. The feature description for "dscp" mischaracterizes it as a pure priority mechanism, rather than a more general indication of class of service treatment: "This feature indicates a publisher supports the placement of suggested prioritization levels for network transport within notification messages." It could be more correct to say something like "This feature indicates that a publisher supports the ability to set the DiffServ Code Point (DSCP) value in outgoing packets." The same comment is applicable in the dscp leaf description on page 45. It is mischaracterized as a pure priority mechanism, which is not how the IETF has defined DSCP. The weighting feature seems to need a little bit more work. It allows values between 0 and 255, and there is some description that bandwidth is supposed to be allocated somehow proportional to the weighting, but it's not really clear how this would be done or that it makes sense. Is it assumed that the publisher has some fixed bandwidth limit that it's trying to stay within, and that it can choose messages from streams (based on their size, frequency, etc) in some way to honor the weights? What is the method to compute the proportions? Is it purely linear? What if there is no contention? What if there is no inherrent bandwidth limit known to the publisher (since generally there probably wouldn't be)? The intention and detail of what this is trying to achieve seems to need to be worked through a bit more to avoid just having a complex feature that might not really achieve much real result, depending on how its implemented. Is there any thought on phase effects, with regard to events that have many subscribers, causing a large number of simultaneous writes on different streams? Overall, there could be low bandwidth utilization for notifications, but then sudden spikes when there is a coupling in the notifications going out on multiple streams. This could lead to some connections seeing losses and others not, for instance, and there might be a reason to try to dither the writes or have other logic encouraged to handle surges of outgoing notifications. Since the underlying transports are TCP-based, losses will be recovered eventually, but there could be latency created in the meantime. This might motivate some of the QoS features that are cursorily discussed, but its not clear how they would be effective. From nobody Wed Apr 3 04:18:25 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DE01200C3 for ; Wed, 3 Apr 2019 04:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpdMn5jqBB3c for ; Wed, 3 Apr 2019 04:18:21 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10046.outbound.protection.outlook.com [40.107.1.46]) (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 8848F120111 for ; Wed, 3 Apr 2019 04:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WUqw5hoossB8R6JZjbTfI182kkbH8tj6ebbcpBljRAk=; b=MiungL3VrRz44/7QzKrvwPzylAIiKW9Odo59VC4vsMV2g4sIsU0NzLGEQZYi46fumXM4DWBxWFEwPx5zV0mhe2RwYvICV35BVVi43wgVXeA02j8HqyMdtvlfl9+fIUb8j+suY5GcUFjqd11ZKFuZn6LHEVW1mAAI2uEWAQWEGR4= Received: from VI1PR07MB4735.eurprd07.prod.outlook.com (20.177.57.146) by VI1PR07MB3117.eurprd07.prod.outlook.com (10.175.242.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.8; Wed, 3 Apr 2019 11:18:17 +0000 Received: from VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::209a:6999:a1c2:ba2]) by VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::209a:6999:a1c2:ba2%2]) with mapi id 15.20.1771.006; Wed, 3 Apr 2019 11:18:17 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Kov=E1cs?= To: Juergen Schoenwaelder , Kent Watsen , tom petch , "netconf@ietf.org" Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpABvbIeAAFYG6nAA2eMuAAAA+NkAAOYBpZA= Date: Wed, 3 Apr 2019 11:18:17 +0000 Message-ID: References: <20190321152920.jdkny7szk7ik3sp4@anna.jacobs.jacobs-university.de> <00b701d4e0cb$e79e9660$4001a8c0@gateway.2wire.net> <01000169ac01ff08-27f75526-1e78-461a-be8e-9737cf762edf-000000@email.amazonses.com> <01000169cb20ec39-94187bed-9312-4e19-a91f-466db763ee7e-000000@email.amazonses.com> <20190329205316.tcjzicuythyd4gvm@anna.jacobs.jacobs-university.de> In-Reply-To: <20190329205316.tcjzicuythyd4gvm@anna.jacobs.jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 28bb3c8f-8500-4fa9-cc20-08d6b826126c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1PR07MB3117; x-ms-traffictypediagnostic: VI1PR07MB3117: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(366004)(396003)(346002)(39860400002)(51444003)(13464003)(199004)(189003)(561944003)(316002)(486006)(7736002)(14444005)(86362001)(229853002)(256004)(33656002)(446003)(11346002)(478600001)(6116002)(97736004)(3846002)(66066001)(105586002)(52536014)(53546011)(106356001)(102836004)(6436002)(25786009)(26005)(6306002)(2906002)(110136005)(7696005)(76176011)(476003)(186003)(9686003)(305945005)(93886005)(2501003)(55016002)(71200400001)(81156014)(81166006)(5660300002)(53936002)(14454004)(66574012)(966005)(8676002)(71190400001)(6246003)(68736007)(99286004)(8936002)(74316002)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3117; H:VI1PR07MB4735.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: u1vAMINLqEoE42eDPqQnMvN1Lz/COVvtK3zlywCXhspbyEZ9kpwUGBjBPulrqQhgn6j0NbIO83O6eePJqE/qXI+QpbTxa9m87qvquh/daLDSlKMxKdyFfVirnHWnRbc/SDZqUv+DrbSeU0cXOA+PHFzk5GuJHdifWBVUeYgWIBz5K9s5OCUgX1zmSh0aVpqaZwIaQcVq6JWRFQ2AoehCggqdHOn3KduP2KifKrv9POSPy4FjMHSpjDc8L9cySAslsF148ws/WwqeagBjvZQxlf++st1veYqxRrCGUGDRPCQeOnn5Yxw3wEAkdg7csNN+B3E2K5j6EpHspTFtM6CL7Q/41er573o8ONIhCG9sgGB10KutlcSZU9o72MGiATEA3ikymwDGjWb/dSLwm2eJGVG+lRungBrhlV+32dflhb4= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 28bb3c8f-8500-4fa9-cc20-08d6b826126c X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2019 11:18:17.5160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3117 Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 11:18:24 -0000 Hi, I agree with Juergen's view to add possibility of generating keys with an a= ction that becomes (protected) configuration. See more below. /Balazs > -----Original Message----- > From: Juergen Schoenwaelder > Sent: Friday, March 29, 2019 9:53 PM > To: Kent Watsen > Cc: Bal=E1zs Kov=E1cs ; tom petch > ; netconf@ietf.org > Subject: Re: [netconf] ietf crypto types - permanently hidden >=20 > I agree, I think we need to distinguish >=20 > - upload of keys > - generation of keys on the box that become (protected) configuration > - generation of keys on the box that will to into hardware protected > storage (and never be accessible) >=20 > and the creation of a private key that becomes (protected) configuration = is > similar to the creation of a user account, where an unused uid is allocat= ed > that becomes configuration. >=20 > /js >=20 > On Fri, Mar 29, 2019 at 08:25:26PM +0000, Kent Watsen wrote: > > Hi Balazs, > > > > > In some implementations I can understand that backup/restore is via > YANG interface, but backup/restore is possible by other methods too. On > the other hand, the private key material should be created and kept on th= e > owner device according to best security practices and certification done = by > for example a certificate signing request. > > > > > > In that sense the generate-hidden-key action and the CSR creation act= ion > are solving the most common need for handling keys, and that is really > regardless if the key is stored in a TPM, a file system, or centralized K= MS. > > > > True. > > > > > I personally was fine with 'hidden' and I was also ok with the curren= t > actions, it was only the descriptions that seemed to be restrictive to TP= M > usage, thus I was asking some clarification. However, if 'hidden' is not = true > this way, then just call it 'generate-key'. Would that then create a bina= ry > string for the 'private-key' in operational too instead of 'permanently-h= idden' > thus you are referring to a 3rd option? > > > > As I understand it, your intention is to have users 1) use actions to g= enerate > private keys and CSRs and 2) that the private-key value is otherwise > inaccessible to the users. I don't believe you have a concern with the = keys > being "configuration" (since the nacm:default-deny-all makes the value > inaccessible), and that the only bad part with the current model is that = the > user has to pass the private key value, which is bad because a) they are > aware of the private key value and also it's possible that the private ke= y value > they generate is poor quality (e.g. having low entropy). Yes. Correct.=20 > > > > This is effectively what was defined on page 22 in > https://tools.ietf.org/html/draft-ietf-netconf-keystore-00 > (we moved to > the current strategy in the next version of that draft where (surprise!) = the > enum was called "INACCESSIBLE". Some more history is here: > https://mailarchive.ietf.org/arch/msg/netconf/OtYAlqLmlErfCr3Z4mcXqRvez > 48 > z48>. > > > > The main problem with this is actions don't typically create configurat= ion, > though we certainly could define this action as doing so (i.e., it locks > when called)...and we might even see ourselves doing this even > for keys that are *interactively* generated by a cryptographic processor.= Of > course, any keys generated by the vendor during manufacturing (i.e., the > IDevID key) would still be operational state. > > > > In order to support systems that have crypto processors, since it may n= ot > be desirable to use the cryptographic processor for all keys, we need eit= her a > parameter or another action to direct the system to use the crypto proces= sor > to generate the key. > > > > Regarding what does "inaccessible" mean, the intention is that the valu= e is > not accessible for reasons beyond access control, with this driving use-c= ase > being a cryptographic processor. Since the term (inaccessible) is being= used > in a YANG module, it stands to reason that it applies to all YANG-driven > interfaces and that there is no statement regarding how it may or may not= be > "inaccessible" in other interfaces. That said, the goal of YANG modules = is to > model reality, not just a view presented by YANG-driven interfaces, and I > imagine great confusion ensuing if mismatches exist across interfaces. I see, and agree. With the suggestion to make it mean "inaccessible via YAN= G interface" I think I rather meant all interface exposed to the same type = of actor. For example if YANG interface is an external operator interface, = then the key should of course be consistently inaccessible on all other typ= e of external operator interface. > > > > I agree that the description statement for the "permanently-hidden" > enumeration can be improved, how about this? > > > > leaf private-key { > > nacm:default-deny-all; > > type union { > > type binary; > > type enumeration { > > enum permanently-hidden { > > description > > "The private key is inaccessible due to being > > protected by the system (e.g., a cryptographic > > hardware module)."; > > } > > } > > } > > ... > > } > > > > Notes: > > > > 1) I removed the "It is not possible to configure a permanently hidden = key, > as a real private key value must be set." text because it was confusing a= nd > yet what's intended is self-evident (i.e., the leaf is a union of a value= and an > enum, only one can be passed). > > OK. > > 2) I removed "Permanently hidden keys cannot be archived or backed up." > text because it was a bit overreaching. As mentioned, even TPM-protected > keys can be backed-up/restored if shrouded and the restoration is to the > same machine. The more correct statement is "RMA workflows are limited", > but it doesn't need to be said here. > > > > OK. > > If the goal is to open up these actions for general use, I think that w= e > SHOULD update them to generate *configuration*. Clearly the intent is t= hat > keys are configuration, use of the action should be seen as supporting a = best > practice, but otherwise shouldn't change the characteristic that interact= ively- > generated keys are configuration. > > I'm fine with your proposal. I have no issues with actions generating confi= guration (but I never followed the discussions about actions and datastores= ) --that is relevant for backup--and we see the example of this keystore us= e case and also the user management use case Juergen brought up. > > Thoughts? > > > > Kent // contributor > > > > > > >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Wed Apr 3 04:44:38 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19691201DB for ; Wed, 3 Apr 2019 04:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZD0r41EmZWv for ; Wed, 3 Apr 2019 04:44:25 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9161204B3 for ; Wed, 3 Apr 2019 04:44:25 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 041951AE02BD; Wed, 3 Apr 2019 13:44:22 +0200 (CEST) Date: Wed, 03 Apr 2019 13:44:24 +0200 (CEST) Message-Id: <20190403.134424.1377386644961079970.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: kent+ietf@watsen.net, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <20190329205316.tcjzicuythyd4gvm@anna.jacobs.jacobs-university.de> References: <01000169cb20ec39-94187bed-9312-4e19-a91f-466db763ee7e-000000@email.amazonses.com> <20190329205316.tcjzicuythyd4gvm@anna.jacobs.jacobs-university.de> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 11:44:36 -0000 Hi, Juergen Schoenwaelder wrote: > I agree, I think we need to distinguish > > - upload of keys > - generation of keys on the box that become (protected) configuration > - generation of keys on the box that will to into hardware protected > storage (and never be accessible) So, the current model supports 1 and 3 above. Do we have to support 2? (and what does "(protected) configuration" mean? is this different from "configuration"?) > and the creation of a private key that becomes (protected) > configuration is similar to the creation of a user account, where an > unused uid is allocated that becomes configuration. AFAIK there is no standard model defined that actually do this. The closest thing we have is the "type" of an interface: When an interface entry is created, a server MAY initialize the type leaf with a valid value, e.g., if it is possible to derive the type from the name of the interface. If private keys are handled like this, then I can accept it. But we should NOT introduce special actions/rpcs that manipulate the configuration. /martin > > /js > > On Fri, Mar 29, 2019 at 08:25:26PM +0000, Kent Watsen wrote: > > Hi Balazs, > > > > > In some implementations I can understand that backup/restore is via YANG interface, but backup/restore is possible by other methods too. On the other hand, the private key material should be created and kept on the owner device according to best security practices and certification done by for example a certificate signing request. > > > > > > In that sense the generate-hidden-key action and the CSR creation action are solving the most common need for handling keys, and that is really regardless if the key is stored in a TPM, a file system, or centralized KMS. > > > > True. > > > > > I personally was fine with 'hidden' and I was also ok with the current actions, it was only the descriptions that seemed to be restrictive to TPM usage, thus I was asking some clarification. However, if 'hidden' is not true this way, then just call it 'generate-key'. Would that then create a binary string for the 'private-key' in operational too instead of 'permanently-hidden' thus you are referring to a 3rd option? > > > > As I understand it, your intention is to have users 1) use actions to generate private keys and CSRs and 2) that the private-key value is otherwise inaccessible to the users. I don't believe you have a concern with the keys being "configuration" (since the nacm:default-deny-all makes the value inaccessible), and that the only bad part with the current model is that the user has to pass the private key value, which is bad because a) they are aware of the private key value and also it's possible that the private key value they generate is poor quality (e.g. having low entropy). > > > > This is effectively what was defined on page 22 in https://tools.ietf.org/html/draft-ietf-netconf-keystore-00 (we moved to the current strategy in the next version of that draft where (surprise!) the enum was called "INACCESSIBLE". Some more history is here: https://mailarchive.ietf.org/arch/msg/netconf/OtYAlqLmlErfCr3Z4mcXqRvez48 . > > > > The main problem with this is actions don't typically create configuration, though we certainly could define this action as doing so (i.e., it locks when called)...and we might even see ourselves doing this even for keys that are *interactively* generated by a cryptographic processor. Of course, any keys generated by the vendor during manufacturing (i.e., the IDevID key) would still be operational state. > > > > In order to support systems that have crypto processors, since it may not be desirable to use the cryptographic processor for all keys, we need either a parameter or another action to direct the system to use the crypto processor to generate the key. > > > > Regarding what does "inaccessible" mean, the intention is that the value is not accessible for reasons beyond access control, with this driving use-case being a cryptographic processor. Since the term (inaccessible) is being used in a YANG module, it stands to reason that it applies to all YANG-driven interfaces and that there is no statement regarding how it may or may not be "inaccessible" in other interfaces. That said, the goal of YANG modules is to model reality, not just a view presented by YANG-driven interfaces, and I imagine great confusion ensuing if mismatches exist across interfaces. > > > > I agree that the description statement for the "permanently-hidden" enumeration can be improved, how about this? > > > > leaf private-key { > > nacm:default-deny-all; > > type union { > > type binary; > > type enumeration { > > enum permanently-hidden { > > description > > "The private key is inaccessible due to being > > protected by the system (e.g., a cryptographic > > hardware module)."; > > } > > } > > } > > ... > > } > > > > Notes: > > > > 1) I removed the "It is not possible to configure a permanently hidden key, as a real private key value must be set." text because it was confusing and yet what's intended is self-evident (i.e., the leaf is a union of a value and an enum, only one can be passed). > > > > 2) I removed "Permanently hidden keys cannot be archived or backed up." text because it was a bit overreaching. As mentioned, even TPM-protected keys can be backed-up/restored if shrouded and the restoration is to the same machine. The more correct statement is "RMA workflows are limited", but it doesn't need to be said here. > > > > > > If the goal is to open up these actions for general use, I think that we SHOULD update them to generate *configuration*. Clearly the intent is that keys are configuration, use of the action should be seen as supporting a best practice, but otherwise shouldn't change the characteristic that interactively-generated keys are configuration. > > > > Thoughts? > > > > Kent // contributor > > > > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Wed Apr 3 05:10:08 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA109120145 for ; Wed, 3 Apr 2019 05:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITyP_RPh1c33 for ; Wed, 3 Apr 2019 05:10:03 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02A4120111 for ; Wed, 3 Apr 2019 05:10:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id B1EA7E07; Wed, 3 Apr 2019 14:10:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id ZCQ-AqxSYDYd; Wed, 3 Apr 2019 14:10:00 +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 atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 3 Apr 2019 14:10:00 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A779200BA; Wed, 3 Apr 2019 14:10:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id M_6G44-CGq74; Wed, 3 Apr 2019 14:10:00 +0200 (CEST) Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 57F8F200B8; Wed, 3 Apr 2019 14:10:00 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Wed, 3 Apr 2019 14:09:59 +0200 Received: by anna.localdomain (Postfix, from userid 501) id 5C8653007AE1D3; Wed, 3 Apr 2019 14:09:58 +0200 (CEST) Date: Wed, 3 Apr 2019 14:09:58 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund CC: , Message-ID: <20190403120958.lxngun7asrc7bt7a@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Martin Bjorklund , kent+ietf@watsen.net, netconf@ietf.org References: <01000169cb20ec39-94187bed-9312-4e19-a91f-466db763ee7e-000000@email.amazonses.com> <20190329205316.tcjzicuythyd4gvm@anna.jacobs.jacobs-university.de> <20190403.134424.1377386644961079970.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20190403.134424.1377386644961079970.mbj@tail-f.com> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 12:10:06 -0000 On Wed, Apr 03, 2019 at 01:44:24PM +0200, Martin Bjorklund wrote: > Hi, > > Juergen Schoenwaelder wrote: > > I agree, I think we need to distinguish > > > > - upload of keys > > - generation of keys on the box that become (protected) configuration > > - generation of keys on the box that will to into hardware protected > > storage (and never be accessible) > > So, the current model supports 1 and 3 above. > > Do we have to support 2? (and what does "(protected) configuration" > mean? is this different from "configuration"?) My understanding is that this is being done. Protected configuration means that the private key becomes configuration (config true) but the private config true key is protected via nacm:default-deny-all. /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 Apr 4 07:12:45 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4811206B4; Thu, 4 Apr 2019 07:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wYZxJexmlb0; Thu, 4 Apr 2019 07:12:39 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 1D6901200EC; Thu, 4 Apr 2019 07:12:39 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id j26so1317942pgl.5; Thu, 04 Apr 2019 07:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2uH+X1agomnppXaPLr4DgNZ0y28hLFvwp8I324wvwaA=; b=tN1qBwSUE77omoJkUYPkXLjpHvO7IeqKtDbNx4axMHodggDXJ4iIWJY/zGMw0E7Y3I HV+SzIXcnGOzJZkXe7OpRIL3uERDierpeu0JlVhkUY5dSK5GHA1t0878hHpsvJQ6EbB5 JWRWTN7qBIqcN7CMKdPHqSxdedDmpwJpWngNdAk32A1YFkVEg0SOWvco3Fxs+ih2yihk J3jHZV8UtiAxrrC/von3HLMj4rRYop8VATU9xm14lF0xRZF3rZnGOqxqEwRbHu7h8gEC Dd8Z5ul6y3H8NZwDrRlfMgGLy++c2fmFvYmVJIVKJh4TRavHaonA35p7k5JYttrBS5me 3ulg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2uH+X1agomnppXaPLr4DgNZ0y28hLFvwp8I324wvwaA=; b=fFdMIYvyTNh/8gdP2fv6bihHD/cX3AX/sYC2bMU1QR0hlU6zNmaR4LZKPLJI4V9XNf Mcg/qNVgyLVDqbssxHwE4rkzmpkxnjNEhH3GG8SzMR5PAadbNyDvzivuxiLjCE8+dZ04 MAdrQ7QYu0XsZT4sQRryrPhIKlM6BShlPs67qVu6FknFcsBNekkOEzWhbl9djKE14m7D 8qEzDu2rldgwY/hKgU02HYYIsRTXXK3QSzt9ZOAgTtzb5OwLGMQS3AnE4r4GOW1NNQt5 6T+rhNe4vPWGnM70VEQ64O2x18njImvxSiXhD7EzrkqqLf/2QFz8Tt/r8opc0/sm3TyB H+vQ== X-Gm-Message-State: APjAAAUg+YUUVqBdP8yQAH7ZevLqNDYex5QQc9i1Vli9kSthomZi95ud TYXb85zt8iFHGWntHHbbBoI= X-Google-Smtp-Source: APXvYqyNBjQIrbU5fRmljw7dYqHDxePfne4mA3GVkjnVOLpgQL/3WX/QQ5MyWLp2LYxtlJl9afDZaA== X-Received: by 2002:a63:ff18:: with SMTP id k24mr6023022pgi.140.1554387158299; Thu, 04 Apr 2019 07:12:38 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:78c9:4ec8:b2c9:94e4? ([2601:647:5600:5020:78c9:4ec8:b2c9:94e4]) by smtp.gmail.com with ESMTPSA id i1sm42820985pgc.63.2019.04.04.07.12.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Apr 2019 07:12:37 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-52B2AC0F-F923-49C1-B3B8-711B82CDDA81 Mime-Version: 1.0 (1.0) From: Mahesh Jethanandani X-Mailer: iPad Mail (16A404) In-Reply-To: Date: Thu, 4 Apr 2019 07:12:36 -0700 Cc: Kent Watsen , httpbis-chairs@ietf.org, "netconf-chairs@ietf.org" , netconf@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <56E946DC-A690-4B1E-8FB5-683473955C5D@gmail.com> References: <01000169bf4bb1d5-f6fc0ffc-70e0-439d-9b96-59540b334d0f-000000@email.amazonses.com> <01000169cb48a8fe-2012b30c-b858-4b9f-aeea-7c22802b96d9-000000@email.amazonses.com> <01000169cc22f874-10931e3c-eedd-41f9-a0e6-ff051c7d2002-000000@email.amazonses.com> <01000169def07790-5f902f1b-ddce-438b-8e05-d4b7e82818bc-000000@email.amazonses.com> To: Patrick McManus Archived-At: Subject: Re: [netconf] time to meet today after 5pm X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 14:12:43 -0000 --Apple-Mail-52B2AC0F-F923-49C1-B3B8-711B82CDDA81 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable What started as a thread to figure out how to handle Kent=E2=80=99s I-D on H= TTP configuration for RESTCONF, has resulted in an extensive discussion on t= he model itself. This discussion belongs to the WG mailing list, and as such= I am adding the WG to the discussion. See inline > On Apr 4, 2019, at 6:09 AM, Patrick McManus wrote: >=20 > Hi Kent, I am indeed a YANG novice. I apologize if that continues to add t= o the confusion. At least I know a thing or two about HTTP :) >=20 > it seems one of the high level problems we have is that restconf is using H= TTP as a stateful connection oriented transport, when you simply cannot defi= ne an http application that way. see 4.10 of bcp56bis https://datatracker.ie= tf.org/doc/draft-ietf-httpbis-bcp56bis/?include_text=3D1 .. this in turn cre= ates your need for tcp keep alive configurations.. because restconf state re= sides at least partially in the connection rather than statelessly in the ex= changes, do I have that right? >=20 > I would strongly advise staying away from the term keep-alive. It is a dep= recated term of art that is not exactly what you are trying to do at the HTT= P level. In the past it has both been a header field as well as a token on t= he Connection header - and it seems you are describing some kind of message e= xchange? >=20 > on the client side.. module ietf-http-client { > [..] > the aliveness of the HTTP server. An unresponsive > HTTP server is dropped after approximately max-wait > * max-attempts seconds."; >=20 > what is the point of max-attempts? In what scenarios does N+1 generate a r= eply that N does not due to connectivity timeout? > isn't the server dropped after max-wait * (max-attempts + 1) seconds.. bec= ause you use the max-wait timeout to trigger the first test > as well as timeout the final test? >=20 > "Sets the amount of time in seconds after which if no > data has been received from the HTTP server, a HTTP >=20 > what is data? TCP? HTTP protocol elements like HTTP/2 SETTINGS frames? HTT= P headers? HTTP message bodies in all or part? HTTP > message bodies to a particular one of your keep-alive requests? any of the= m? all of them? The answers are different if you're trying to > test e2e. >=20 > what message is supposed to the sent to the server? any guidance? and for t= he server: >=20 > "Sets the amount of time in seconds after which if no > data has been received from the HTTP client, a HTTP > level message will be sent to test the aliveness of > the HTTP client."; >=20 > I don't understand what kind of message is initiated by the HTTP server, a= t least in a version portable fashion, to accomplish this. >=20 >=20 >> On Tue, Apr 2, 2019 at 6:44 PM Kent Watsen wrote: >>=20 >>=20 >> But we must do something, this is a real issue. We have to be able to co= nfigure RESTCONF clients and servers. >=20 > It sounds like this is a restconf yang model, not a base http yang model. The intent has been to describe the minimum number of HTTP parameters for th= e explicit configuration of RESTCONF client/server.=20 But based on this thread, I am assuming that the chairs for httpbis WG do no= t regard the parameters or the approach to achieve =E2=80=9Cpersistence=E2=80= =9D either correct or part of the HTTP protocol. While it casts doubt on the= proposed solution, it is now a decision for the NETCONF WG to decide whethe= r they want to recast the draft as a RESTCONF HTTP module or go back to the d= rawing board. Thanks. >=20 >>> Keepalives as well are a really tricky topic.. the mechanism you are usi= ng is not really used on the Internet much these days and when it is used it= is used to manage persistence, not really timeouts and NAT rebindings which= I think is what you're getting at... I can think of 3 other techniques that= are used to try and manage rebindings. >>=20 >> Actually, "managing persistence" is exactly what we're trying to achieve h= ere. Our show-stopping driving use-case regards RESTCONF Call Home (RFC 807= 1) and, in particular, point "S7" on page 8 of that document, without which a= remote device may become a "brick" and require a technician to perform on-s= ite repair. >=20 > please see the bcp56bis reference I made as well as the opening to 7230. H= TTP is a stateless protocol, applications that are using it cannot be built a= round other assumptions about the thransport - they lack version portability= and don't survive integration into the ecosystem of libraries, firewalls, r= outers, load balancers, etc that are the strongest reason to base applicatio= ns on http. > =20 >>=20 >>> I'm also a little concerned about the thinking in the other protocols di= scussion - http the protocol carries a variety of schemes beyond http:// and= https:// and that probably needs to be explored. >>=20 >> Could you provide an example? I'm aware that there are many other URI sc= hemes (ldap, mailto, etc.), but they are not HTTP. Are you saying there are= some URI schemes (e.g., "myhttp:") that are like an application-layer proto= col on top of HTTP? Or do you mean that HTTP may have different transport b= indings besides TCP and TLS? =20 >=20 > ftp:// ws:// wss:// are the most common schemes carried on http other than= http:// and https://. but the protocol is can carry most of what you can st= ructure as a URI and content. > =20 >>=20 >>> Which brings me to my question about what HTTP implementations might wan= t to co-author. That wasn't meant as some kind of Not-Invented-Here comment.= . rather it was trying to see if we are solving an interop problem or engagi= ng in hope based standardization. HTTPbis tries hard to pursue work that ena= bles interoperation between at least 2 parties that wish to interoperate and= that at least some part of that group of implementations is driving the sta= ndard. I'm having trouble figuring out who those HTTP parties are here and I= 'm cautious about proceeding without that. >>=20 >> As mentioned before, this work began as an effort to define the configura= tion models for RESTCONF clients and servers. The desire to have a *standar= ds-based* way to do this is especially supported when thinking about deployi= ng networks of heterogeneous devices to perform zerotouch bootstrapping (thi= nk autonomic networking). =20 >>=20 >=20 > then perhaps a restconf yang model is what you are defining? > =20 >>=20 >> With regards to the HTTP configuration model, it's not so much *if* there= will be an HTTP model, but to what extent you (your WG) would like to or de= mand to be part of the effort to define it. As the HTTP domain experts, an= d we being the YANG experts, the ideal scenario is for us to strike a collab= oration. In particular, given that we're trying to put an end to this near= ly 5-year long effort, we politely request that you give us the blessing to p= roceed roughly as planned (i.e., defining a minimal skeleton with as many "f= eature" statements as needed). We envision this as a very short engagement= (Last Call immediately after Montreal), after which the HTTP model would li= kely only be touched again when needed. If history is a guide, I'd guess th= at might not happen for 3-5 years. >>=20 >> Would a collaboration be okay? If yes, then is there someone in particul= ar that I (as a contributor/author) can buddy up with in HTTPBIS to get expe= rt-level advice? >>=20 >=20 > This puts us in a tough spot. The -00 draft does not do a good job of desc= ribing HTTP so I don't feel we can endorse it. The working group has an exte= nsive set of adopted drafts right now and I don't believe it is the right pr= iority to put this in front of them too in order to put the work in to make i= t appropriately expressive - it would distract from the priorities the group= has decided on. >=20 > What do you think of recasting this as a model limited to restconf based a= pplications? >=20 > -Patrick Mahesh Jethanandani mjethanandani@gmail.com >=20 --Apple-Mail-52B2AC0F-F923-49C1-B3B8-711B82CDDA81 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable What started as a thread to figure out how t= o handle Kent=E2=80=99s I-D on HTTP configuration for RESTCONF, has resulted= in an extensive discussion on the model itself. This discussion belongs to t= he WG mailing list, and as such I am adding the WG to the discussion.
See inline

On Apr 4, 2019, at 6:09 AM, P= atrick McManus <mcmanus@ducksong.= com> wrote:

<= div dir=3D"ltr">
Hi Kent, I am indeed a YANG novice. I apolo= gize if that continues to add to the confusion. At least I know a thing or t= wo about HTTP :)

it seems one of the high level problems w= e have is that restconf is using HTTP as a stateful connection oriented tran= sport, when you simply cannot define an http application that way. see 4.10 o= f bcp56bis https://datatracker.ietf.org/doc/draft-ietf-h= ttpbis-bcp56bis/?include_text=3D1 .. this in turn creates your need= for tcp keep alive configurations.. because restconf state resides at least= partially in the connection rather than statelessly in the exchanges, do I h= ave that right?

I would strongly advise staying awa= y from the term keep-alive. It is a deprecated term of art that is not exact= ly what you are trying to do at the HTTP level. In the past it has both been= a header field as well as a token on the Connection header - and it seems y= ou are describing some kind of message exchange?

on the client side.. module ietf-http-client { [..]
            the aliveness of the HTTP server.  An unresponsive
            HTTP server is dropped after approximately max-wait
            * max-attempts seconds.";

 what is the point of max-att=
empts? In what scenarios does N+1 generate a reply that N does not due to co=
nnectivity timeout?
isn't the server drop=
ped after max-wait * (max-attempts + 1) seconds.. because you use the max-wa=
it timeout to trigger the first test
as well a=
s timeout the final test?

  =
           "Sets the amount of time in seconds after which if no
              data has been received from the HTTP server, a HTTP

what is data? TCP? HTTP protocol elements like H=
TTP/2 SETTINGS frames? HTTP headers? HTTP message bodies in all or part? HTT=
P
message bodies to a particular one of your ke=
ep-alive requests? any of them? all of them?  The answers are different if y=
ou're trying to

test e2e.

=

what message is supposed to the sent to the s=
erver? any guidance? and for the server:

=

             "Sets the amount of time in seconds after which if no
              data has been received from the HTTP client, a HTTP
              level message will be sent to test the aliveness of
              the HTTP client.";

I don't understand what kind=
 of message is initiated by the HTTP server, at least in a version portable f=
ashion, to accomplish this.


On Tue, Apr 2, 20= 19 at 6:44 PM Kent Watsen <kent= +ietf@watsen.net> wrote:

=
But we must do something, this is a real issue.  We= have to be able to configure RESTCONF clients and servers.

It sounds like this is a restconf yang mod= el, not a base http yang model.
The intent has been to describe the minimum number of HTTP parameters= for the explicit configuration of RESTCONF client/server. 

But based on this thread, I am assuming that the chairs for httpbis W= G do not regard the parameters or the approach to achieve =E2=80=9Cpersisten= ce=E2=80=9D either correct or part of the HTTP protocol. While it casts doub= t on the proposed solution, it is now a decision for the NETCONF WG to decid= e whether they want to recast the draft as a RESTCONF HTTP module or go back= to the drawing board.

Thanks.


Keepaliv= es as well are a really tricky topic.. the mechanism you are using is not re= ally used on the Internet much these days and when it is used it is used to m= anage persistence, not really timeouts and NAT rebindings which I think is w= hat you're getting at... I can think of 3 other techniques that are used to t= ry and manage rebindings.

Actually, "= managing persistence" is exactly what we're trying to achieve here.  Ou= r show-stopping driving use-case regards RESTCONF Call Home (RFC 8071) and, i= n particular, point "S7" on page 8 of that document, without which a remote d= evice may become a "brick" and require a technician to perform on-site repai= r.

please see the bcp56bis= reference I made as well as the opening to 7230. HTTP is a stateless protoc= ol, applications that are using it cannot be built around other assumptions a= bout the thransport - they lack version portability and don't survive integr= ation into the ecosystem of libraries, firewalls, routers, load balancers, e= tc that are the strongest reason to base applications on http.
&nb= sp;

=
I'm also a little concerned about the thinking in the other protoc= ols discussion - http the protocol carries a variety of schemes beyond http:= // and https:// and that probably needs to be explored.

Could you provide an example?  I'm aware t= hat there are many other URI schemes (ldap, mailto, etc.), but they are not H= TTP.  Are you saying there are some URI schemes (e.g., "myhttp:") that a= re like an application-layer protocol on top of HTTP?   Or do you mean t= hat HTTP may have different transport bindings besides TCP and TLS?  &n= bsp;

ftp:// ws:// wss:// a= re the most common schemes carried on http other than http:// and https://. b= ut the protocol is can carry most of what you can structure as a URI and con= tent.
 

Which brings me to my question a= bout what HTTP implementations might want to co-author. That wasn't meant as= some kind of Not-Invented-Here comment.. rather it was trying to see if we a= re solving an interop problem or engaging in hope based standardization. HTT= Pbis tries hard to pursue work that enables interoperation between at least 2= parties that wish to interoperate and that at least some part of that group= of implementations is driving the standard. I'm having trouble figuring out= who those HTTP parties are here and I'm cautious about proceeding without t= hat.

As mentioned be= fore, this work began as an effort to define the configuration models for RE= STCONF clients and servers.  The desire to have a *standards-based* way= to do this is especially supported when thinking about deploying networks o= f heterogeneous devices to perform zerotouch bootstrapping (think autonomic n= etworking).  


then perhaps a restconf yang model is what you are defining?
 

With regard= s to the HTTP configuration model, it's not so much *if* there will be an HT= TP model, but to what extent you (your WG) would like to or demand to be par= t of the effort to define it.   As the HTTP domain experts, and we bein= g the YANG experts, the ideal scenario is for us to strike a collaboration. &= nbsp; In particular, given that we're trying to put an end to this nearly 5-= year long effort, we politely request that you give us the blessing to proce= ed roughly as planned (i.e., defining a minimal skeleton with as many "featu= re" statements as needed).   We envision this as a very short engagemen= t (Last Call immediately after Montreal), after which the HTTP model would l= ikely only be touched again when needed.  If history is a guide, I'd gu= ess that might not happen for 3-5 years.

Would a co= llaboration be okay?  If yes, then is there someone in particular that I= (as a contributor/author) can buddy up with in HTTPBIS to get expert-level a= dvice?


This= puts us in a tough spot. The -00 draft does not do a good job of describing= HTTP so I don't feel we can endorse it. The working group has an extensive s= et of adopted drafts right now and I don't believe it is the right priority t= o put this in front of them too in order to put the work in to make it appro= priately expressive - it would distract from the priorities the group has de= cided on.

What do you think of recasting this as a m= odel limited to restconf based applications?

-Patri= ck

Mahesh Jethanandani

=
= --Apple-Mail-52B2AC0F-F923-49C1-B3B8-711B82CDDA81-- From nobody Thu Apr 4 07:33:51 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966B212002F; Thu, 4 Apr 2019 07:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xhi5Qc37MpT; Thu, 4 Apr 2019 07:33:47 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA30120368; Thu, 4 Apr 2019 07:33:46 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 7AB3A1AE018B; Thu, 4 Apr 2019 16:33:44 +0200 (CEST) Date: Thu, 04 Apr 2019 16:33:46 +0200 (CEST) Message-Id: <20190404.163346.857364419603319540.mbj@tail-f.com> To: mjethanandani@gmail.com Cc: mcmanus@ducksong.com, httpbis-chairs@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <56E946DC-A690-4B1E-8FB5-683473955C5D@gmail.com> References: <01000169def07790-5f902f1b-ddce-438b-8e05-d4b7e82818bc-000000@email.amazonses.com> <56E946DC-A690-4B1E-8FB5-683473955C5D@gmail.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] time to meet today after 5pm X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 14:33:50 -0000 SGksDQoNCkl0IHdhcyBhIGJpdCBkaWZmaWN1bHQgdG8gZmlndXJlIG91dCB3aGF0IHRoaXMgZGlj dXNzaW9uIGxlZCB0bywgYnV0DQpzZWUgb25lIHNpbXBsZSBjb21tZW50IGJlbG93Lg0KDQoNCk1h aGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPiB3cm90ZToNCj4gV2hh dCBzdGFydGVkIGFzIGEgdGhyZWFkIHRvIGZpZ3VyZSBvdXQgaG93IHRvIGhhbmRsZSBLZW504oCZ cyBJLUQgb24NCj4gSFRUUCBjb25maWd1cmF0aW9uIGZvciBSRVNUQ09ORiwgaGFzIHJlc3VsdGVk IGluIGFuIGV4dGVuc2l2ZQ0KPiBkaXNjdXNzaW9uIG9uIHRoZSBtb2RlbCBpdHNlbGYuIFRoaXMg ZGlzY3Vzc2lvbiBiZWxvbmdzIHRvIHRoZSBXRw0KPiBtYWlsaW5nIGxpc3QsIGFuZCBhcyBzdWNo IEkgYW0gYWRkaW5nIHRoZSBXRyB0byB0aGUgZGlzY3Vzc2lvbi4NCj4gDQo+IFNlZSBpbmxpbmUN Cj4gDQo+ID4gT24gQXByIDQsIDIwMTksIGF0IDY6MDkgQU0sIFBhdHJpY2sgTWNNYW51cyA8bWNt YW51c0BkdWNrc29uZy5jb20+DQo+ID4gd3JvdGU6DQo+ID4gDQo+ID4gSGkgS2VudCwgSSBhbSBp bmRlZWQgYSBZQU5HIG5vdmljZS4gSSBhcG9sb2dpemUgaWYgdGhhdCBjb250aW51ZXMgdG8NCj4g PiBhZGQgdG8gdGhlIGNvbmZ1c2lvbi4gQXQgbGVhc3QgSSBrbm93IGEgdGhpbmcgb3IgdHdvIGFi b3V0IEhUVFAgOikNCj4gPiANCj4gPiBpdCBzZWVtcyBvbmUgb2YgdGhlIGhpZ2ggbGV2ZWwgcHJv YmxlbXMgd2UgaGF2ZSBpcyB0aGF0IHJlc3Rjb25mIGlzDQo+ID4gdXNpbmcgSFRUUCBhcyBhIHN0 YXRlZnVsIGNvbm5lY3Rpb24gb3JpZW50ZWQgdHJhbnNwb3J0DQoNCkkgZG9uJ3QgdGhpbmsgdGhp cyBpcyBjb3JyZWN0LiAgSW4gd2hhdCB3YXkgZG8geW91IHRoaW5rIFJFU1RDT05GDQp0cmllcyB0 byB1c2UgSFRUUCBhcyBhIHN0YXRlZnVsIHRyYW5zcG9ydD8NCg0KDQovbWFydGluDQoNCg0KPiA+ ICwgd2hlbiB5b3UNCj4gPiBzaW1wbHkgY2Fubm90IGRlZmluZSBhbiBodHRwIGFwcGxpY2F0aW9u IHRoYXQgd2F5LiBzZWUgNC4xMCBvZg0KPiA+IGJjcDU2YmlzDQo+ID4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1odHRwYmlzLWJjcDU2YmlzLz9pbmNsdWRlX3Rl eHQ9MQ0KPiA+IC4uIHRoaXMgaW4gdHVybiBjcmVhdGVzIHlvdXIgbmVlZCBmb3IgdGNwIGtlZXAg YWxpdmUNCj4gPiBjb25maWd1cmF0aW9ucy4uIGJlY2F1c2UgcmVzdGNvbmYgc3RhdGUgcmVzaWRl cyBhdCBsZWFzdCBwYXJ0aWFsbHkgaW4NCj4gPiB0aGUgY29ubmVjdGlvbiByYXRoZXIgdGhhbiBz dGF0ZWxlc3NseSBpbiB0aGUgZXhjaGFuZ2VzLCBkbyBJIGhhdmUNCj4gPiB0aGF0IHJpZ2h0Pw0K PiA+IA0KPiA+IEkgd291bGQgc3Ryb25nbHkgYWR2aXNlIHN0YXlpbmcgYXdheSBmcm9tIHRoZSB0 ZXJtIGtlZXAtYWxpdmUuIEl0IGlzIGENCj4gPiBkZXByZWNhdGVkIHRlcm0gb2YgYXJ0IHRoYXQg aXMgbm90IGV4YWN0bHkgd2hhdCB5b3UgYXJlIHRyeWluZyB0byBkbw0KPiA+IGF0IHRoZSBIVFRQ IGxldmVsLiBJbiB0aGUgcGFzdCBpdCBoYXMgYm90aCBiZWVuIGEgaGVhZGVyIGZpZWxkIGFzIHdl bGwNCj4gPiBhcyBhIHRva2VuIG9uIHRoZSBDb25uZWN0aW9uIGhlYWRlciAtIGFuZCBpdCBzZWVt cyB5b3UgYXJlIGRlc2NyaWJpbmcNCj4gPiBzb21lIGtpbmQgb2YgbWVzc2FnZSBleGNoYW5nZT8N Cj4gPiANCj4gPiBvbiB0aGUgY2xpZW50IHNpZGUuLiAgIG1vZHVsZSBpZXRmLWh0dHAtY2xpZW50 IHsNCj4gPiBbLi5dDQo+ID4gICAgICAgICAgICAgdGhlIGFsaXZlbmVzcyBvZiB0aGUgSFRUUCBz ZXJ2ZXIuICBBbiB1bnJlc3BvbnNpdmUNCj4gPiAgICAgICAgICAgICBIVFRQIHNlcnZlciBpcyBk cm9wcGVkIGFmdGVyIGFwcHJveGltYXRlbHkgbWF4LXdhaXQNCj4gPiAgICAgICAgICAgICAqIG1h eC1hdHRlbXB0cyBzZWNvbmRzLiI7DQo+ID4gDQo+ID4gIHdoYXQgaXMgdGhlIHBvaW50IG9mIG1h eC1hdHRlbXB0cz8gSW4gd2hhdCBzY2VuYXJpb3MgZG9lcyBOKzEgZ2VuZXJhdGUNCj4gPiAgYSBy ZXBseSB0aGF0IE4gZG9lcyBub3QgZHVlIHRvIGNvbm5lY3Rpdml0eSB0aW1lb3V0Pw0KPiA+IGlz bid0IHRoZSBzZXJ2ZXIgZHJvcHBlZCBhZnRlciBtYXgtd2FpdCAqIChtYXgtYXR0ZW1wdHMgKyAx KQ0KPiA+IHNlY29uZHMuLiBiZWNhdXNlIHlvdSB1c2UgdGhlIG1heC13YWl0IHRpbWVvdXQgdG8g dHJpZ2dlciB0aGUgZmlyc3QNCj4gPiB0ZXN0DQo+ID4gYXMgd2VsbCBhcyB0aW1lb3V0IHRoZSBm aW5hbCB0ZXN0Pw0KPiA+IA0KPiA+ICAgICAgICAgICAgICAiU2V0cyB0aGUgYW1vdW50IG9mIHRp bWUgaW4gc2Vjb25kcyBhZnRlciB3aGljaCBpZiBubw0KPiA+ICAgICAgICAgICAgICAgZGF0YSBo YXMgYmVlbiByZWNlaXZlZCBmcm9tIHRoZSBIVFRQIHNlcnZlciwgYSBIVFRQDQo+ID4gDQo+ID4g d2hhdCBpcyBkYXRhPyBUQ1A/IEhUVFAgcHJvdG9jb2wgZWxlbWVudHMgbGlrZSBIVFRQLzIgU0VU VElOR1MgZnJhbWVzPw0KPiA+IEhUVFAgaGVhZGVycz8gSFRUUCBtZXNzYWdlIGJvZGllcyBpbiBh bGwgb3IgcGFydD8gSFRUUA0KPiA+IG1lc3NhZ2UgYm9kaWVzIHRvIGEgcGFydGljdWxhciBvbmUg b2YgeW91ciBrZWVwLWFsaXZlIHJlcXVlc3RzPyBhbnkgb2YNCj4gPiB0aGVtPyBhbGwgb2YgdGhl bT8gIFRoZSBhbnN3ZXJzIGFyZSBkaWZmZXJlbnQgaWYgeW91J3JlIHRyeWluZyB0bw0KPiA+IHRl c3QgZTJlLg0KPiA+IA0KPiA+IHdoYXQgbWVzc2FnZSBpcyBzdXBwb3NlZCB0byB0aGUgc2VudCB0 byB0aGUgc2VydmVyPyBhbnkgZ3VpZGFuY2U/IGFuZA0KPiA+IGZvciB0aGUgc2VydmVyOg0KPiA+ IA0KPiA+ICAgICAgICAgICAgICAiU2V0cyB0aGUgYW1vdW50IG9mIHRpbWUgaW4gc2Vjb25kcyBh ZnRlciB3aGljaCBpZiBubw0KPiA+ICAgICAgICAgICAgICAgZGF0YSBoYXMgYmVlbiByZWNlaXZl ZCBmcm9tIHRoZSBIVFRQIGNsaWVudCwgYSBIVFRQDQo+ID4gICAgICAgICAgICAgICBsZXZlbCBt ZXNzYWdlIHdpbGwgYmUgc2VudCB0byB0ZXN0IHRoZSBhbGl2ZW5lc3Mgb2YNCj4gPiAgICAgICAg ICAgICAgIHRoZSBIVFRQIGNsaWVudC4iOw0KPiA+IA0KPiA+IEkgZG9uJ3QgdW5kZXJzdGFuZCB3 aGF0IGtpbmQgb2YgbWVzc2FnZSBpcyBpbml0aWF0ZWQgYnkgdGhlIEhUVFANCj4gPiBzZXJ2ZXIs IGF0IGxlYXN0IGluIGEgdmVyc2lvbiBwb3J0YWJsZSBmYXNoaW9uLCB0byBhY2NvbXBsaXNoIHRo aXMuDQo+ID4gDQo+ID4gDQo+ID4+IE9uIFR1ZSwgQXByIDIsIDIwMTkgYXQgNjo0NCBQTSBLZW50 IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ+DQo+ID4+IHdyb3RlOg0KPiA+PiANCj4gPj4g DQo+ID4+IEJ1dCB3ZSBtdXN0IGRvIHNvbWV0aGluZywgdGhpcyBpcyBhIHJlYWwgaXNzdWUuICBX ZSBoYXZlIHRvIGJlIGFibGUgdG8NCj4gPj4gY29uZmlndXJlIFJFU1RDT05GIGNsaWVudHMgYW5k IHNlcnZlcnMuDQo+ID4gDQo+ID4gSXQgc291bmRzIGxpa2UgdGhpcyBpcyBhIHJlc3Rjb25mIHlh bmcgbW9kZWwsIG5vdCBhIGJhc2UgaHR0cCB5YW5nDQo+ID4gbW9kZWwuDQo+IA0KPiBUaGUgaW50 ZW50IGhhcyBiZWVuIHRvIGRlc2NyaWJlIHRoZSBtaW5pbXVtIG51bWJlciBvZiBIVFRQIHBhcmFt ZXRlcnMNCj4gZm9yIHRoZSBleHBsaWNpdCBjb25maWd1cmF0aW9uIG9mIFJFU1RDT05GIGNsaWVu dC9zZXJ2ZXIuDQo+IA0KPiBCdXQgYmFzZWQgb24gdGhpcyB0aHJlYWQsIEkgYW0gYXNzdW1pbmcg dGhhdCB0aGUgY2hhaXJzIGZvciBodHRwYmlzIFdHDQo+IGRvIG5vdCByZWdhcmQgdGhlIHBhcmFt ZXRlcnMgb3IgdGhlIGFwcHJvYWNoIHRvIGFjaGlldmUg4oCccGVyc2lzdGVuY2XigJ0NCj4gZWl0 aGVyIGNvcnJlY3Qgb3IgcGFydCBvZiB0aGUgSFRUUCBwcm90b2NvbC4gV2hpbGUgaXQgY2FzdHMg ZG91YnQgb24NCj4gdGhlIHByb3Bvc2VkIHNvbHV0aW9uLCBpdCBpcyBub3cgYSBkZWNpc2lvbiBm b3IgdGhlIE5FVENPTkYgV0cgdG8NCj4gZGVjaWRlIHdoZXRoZXIgdGhleSB3YW50IHRvIHJlY2Fz dCB0aGUgZHJhZnQgYXMgYSBSRVNUQ09ORiBIVFRQIG1vZHVsZQ0KPiBvciBnbyBiYWNrIHRvIHRo ZSBkcmF3aW5nIGJvYXJkLg0KPiANCj4gVGhhbmtzLg0KPiANCj4gPiANCj4gPj4+IEtlZXBhbGl2 ZXMgYXMgd2VsbCBhcmUgYSByZWFsbHkgdHJpY2t5IHRvcGljLi4gdGhlIG1lY2hhbmlzbSB5b3Ug YXJlDQo+ID4+PiB1c2luZyBpcyBub3QgcmVhbGx5IHVzZWQgb24gdGhlIEludGVybmV0IG11Y2gg dGhlc2UgZGF5cyBhbmQgd2hlbiBpdA0KPiA+Pj4gaXMgdXNlZCBpdCBpcyB1c2VkIHRvIG1hbmFn ZSBwZXJzaXN0ZW5jZSwgbm90IHJlYWxseSB0aW1lb3V0cyBhbmQgTkFUDQo+ID4+PiByZWJpbmRp bmdzIHdoaWNoIEkgdGhpbmsgaXMgd2hhdCB5b3UncmUgZ2V0dGluZyBhdC4uLiBJIGNhbiB0aGlu ayBvZiAzDQo+ID4+PiBvdGhlciB0ZWNobmlxdWVzIHRoYXQgYXJlIHVzZWQgdG8gdHJ5IGFuZCBt YW5hZ2UgcmViaW5kaW5ncy4NCj4gPj4gDQo+ID4+IEFjdHVhbGx5LCAibWFuYWdpbmcgcGVyc2lz dGVuY2UiIGlzIGV4YWN0bHkgd2hhdCB3ZSdyZSB0cnlpbmcgdG8NCj4gPj4gYWNoaWV2ZSBoZXJl LiAgT3VyIHNob3ctc3RvcHBpbmcgZHJpdmluZyB1c2UtY2FzZSByZWdhcmRzIFJFU1RDT05GDQo+ ID4+IENhbGwgSG9tZSAoUkZDIDgwNzEpIGFuZCwgaW4gcGFydGljdWxhciwgcG9pbnQgIlM3IiBv biBwYWdlIDggb2YgdGhhdA0KPiA+PiBkb2N1bWVudCwgd2l0aG91dCB3aGljaCBhIHJlbW90ZSBk ZXZpY2UgbWF5IGJlY29tZSBhICJicmljayIgYW5kDQo+ID4+IHJlcXVpcmUgYSB0ZWNobmljaWFu IHRvIHBlcmZvcm0gb24tc2l0ZSByZXBhaXIuDQo+ID4gDQo+ID4gcGxlYXNlIHNlZSB0aGUgYmNw NTZiaXMgcmVmZXJlbmNlIEkgbWFkZSBhcyB3ZWxsIGFzIHRoZSBvcGVuaW5nIHRvDQo+ID4gNzIz MC4gSFRUUCBpcyBhIHN0YXRlbGVzcyBwcm90b2NvbCwgYXBwbGljYXRpb25zIHRoYXQgYXJlIHVz aW5nIGl0DQo+ID4gY2Fubm90IGJlIGJ1aWx0IGFyb3VuZCBvdGhlciBhc3N1bXB0aW9ucyBhYm91 dCB0aGUgdGhyYW5zcG9ydCAtIHRoZXkNCj4gPiBsYWNrIHZlcnNpb24gcG9ydGFiaWxpdHkgYW5k IGRvbid0IHN1cnZpdmUgaW50ZWdyYXRpb24gaW50byB0aGUNCj4gPiBlY29zeXN0ZW0gb2YgbGli cmFyaWVzLCBmaXJld2FsbHMsIHJvdXRlcnMsIGxvYWQgYmFsYW5jZXJzLCBldGMgdGhhdA0KPiA+ IGFyZSB0aGUgc3Ryb25nZXN0IHJlYXNvbiB0byBiYXNlIGFwcGxpY2F0aW9ucyBvbiBodHRwLg0K PiA+ICANCj4gPj4gDQo+ID4+PiBJJ20gYWxzbyBhIGxpdHRsZSBjb25jZXJuZWQgYWJvdXQgdGhl IHRoaW5raW5nIGluIHRoZSBvdGhlciBwcm90b2NvbHMNCj4gPj4+IGRpc2N1c3Npb24gLSBodHRw IHRoZSBwcm90b2NvbCBjYXJyaWVzIGEgdmFyaWV0eSBvZiBzY2hlbWVzIGJleW9uZA0KPiA+Pj4g aHR0cDovLyBhbmQgaHR0cHM6Ly8gYW5kIHRoYXQgcHJvYmFibHkgbmVlZHMgdG8gYmUgZXhwbG9y ZWQuDQo+ID4+IA0KPiA+PiBDb3VsZCB5b3UgcHJvdmlkZSBhbiBleGFtcGxlPyAgSSdtIGF3YXJl IHRoYXQgdGhlcmUgYXJlIG1hbnkgb3RoZXIgVVJJDQo+ID4+IHNjaGVtZXMgKGxkYXAsIG1haWx0 bywgZXRjLiksIGJ1dCB0aGV5IGFyZSBub3QgSFRUUC4gIEFyZSB5b3Ugc2F5aW5nDQo+ID4+IHRo ZXJlIGFyZSBzb21lIFVSSSBzY2hlbWVzIChlLmcuLCAibXlodHRwOiIpIHRoYXQgYXJlIGxpa2Ug YW4NCj4gPj4gYXBwbGljYXRpb24tbGF5ZXIgcHJvdG9jb2wgb24gdG9wIG9mIEhUVFA/ICBPciBk byB5b3UgbWVhbiB0aGF0IEhUVFANCj4gPj4gbWF5IGhhdmUgZGlmZmVyZW50IHRyYW5zcG9ydCBi aW5kaW5ncyBiZXNpZGVzIFRDUCBhbmQgVExTPw0KPiA+IA0KPiA+IGZ0cDovLyB3czovLyB3c3M6 Ly8gYXJlIHRoZSBtb3N0IGNvbW1vbiBzY2hlbWVzIGNhcnJpZWQgb24gaHR0cCBvdGhlcg0KPiA+ IHRoYW4gaHR0cDovLyBhbmQgaHR0cHM6Ly8uIGJ1dCB0aGUgcHJvdG9jb2wgaXMgY2FuIGNhcnJ5 IG1vc3Qgb2Ygd2hhdA0KPiA+IHlvdSBjYW4gc3RydWN0dXJlIGFzIGEgVVJJIGFuZCBjb250ZW50 Lg0KPiA+ICANCj4gPj4gDQo+ID4+PiBXaGljaCBicmluZ3MgbWUgdG8gbXkgcXVlc3Rpb24gYWJv dXQgd2hhdCBIVFRQIGltcGxlbWVudGF0aW9ucyBtaWdodA0KPiA+Pj4gd2FudCB0byBjby1hdXRo b3IuIFRoYXQgd2Fzbid0IG1lYW50IGFzIHNvbWUga2luZCBvZiBOb3QtSW52ZW50ZWQtSGVyZQ0K PiA+Pj4gY29tbWVudC4uLiByYXRoZXIgaXQgd2FzIHRyeWluZyB0byBzZWUgaWYgd2UgYXJlIHNv bHZpbmcgYW4gaW50ZXJvcA0KPiA+Pj4gcHJvYmxlbSBvciBlbmdhZ2luZyBpbiBob3BlIGJhc2Vk IHN0YW5kYXJkaXphdGlvbi4gSFRUUGJpcyB0cmllcyBoYXJkDQo+ID4+PiB0byBwdXJzdWUgd29y ayB0aGF0IGVuYWJsZXMgaW50ZXJvcGVyYXRpb24gYmV0d2VlbiBhdCBsZWFzdCAyIHBhcnRpZXMN Cj4gPj4+IHRoYXQgd2lzaCB0byBpbnRlcm9wZXJhdGUgYW5kIHRoYXQgYXQgbGVhc3Qgc29tZSBw YXJ0IG9mIHRoYXQgZ3JvdXAgb2YNCj4gPj4+IGltcGxlbWVudGF0aW9ucyBpcyBkcml2aW5nIHRo ZSBzdGFuZGFyZC4gSSdtIGhhdmluZyB0cm91YmxlIGZpZ3VyaW5nDQo+ID4+PiBvdXQgd2hvIHRo b3NlIEhUVFAgcGFydGllcyBhcmUgaGVyZSBhbmQgSSdtIGNhdXRpb3VzIGFib3V0IHByb2NlZWRp bmcNCj4gPj4+IHdpdGhvdXQgdGhhdC4NCj4gPj4gDQo+ID4+IEFzIG1lbnRpb25lZCBiZWZvcmUs IHRoaXMgd29yayBiZWdhbiBhcyBhbiBlZmZvcnQgdG8gZGVmaW5lIHRoZQ0KPiA+PiBjb25maWd1 cmF0aW9uIG1vZGVscyBmb3IgUkVTVENPTkYgY2xpZW50cyBhbmQgc2VydmVycy4gIFRoZSBkZXNp cmUgdG8NCj4gPj4gaGF2ZSBhICpzdGFuZGFyZHMtYmFzZWQqIHdheSB0byBkbyB0aGlzIGlzIGVz cGVjaWFsbHkgc3VwcG9ydGVkIHdoZW4NCj4gPj4gdGhpbmtpbmcgYWJvdXQgZGVwbG95aW5nIG5l dHdvcmtzIG9mIGhldGVyb2dlbmVvdXMgZGV2aWNlcyB0byBwZXJmb3JtDQo+ID4+IHplcm90b3Vj aCBib290c3RyYXBwaW5nICh0aGluayBhdXRvbm9taWMgbmV0d29ya2luZykuDQo+ID4+IA0KPiA+ IA0KPiA+IHRoZW4gcGVyaGFwcyBhIHJlc3Rjb25mIHlhbmcgbW9kZWwgaXMgd2hhdCB5b3UgYXJl IGRlZmluaW5nPw0KPiA+ICANCj4gPj4gDQo+ID4+IFdpdGggcmVnYXJkcyB0byB0aGUgSFRUUCBj b25maWd1cmF0aW9uIG1vZGVsLCBpdCdzIG5vdCBzbyBtdWNoICppZioNCj4gPj4gdGhlcmUgd2ls bCBiZSBhbiBIVFRQIG1vZGVsLCBidXQgdG8gd2hhdCBleHRlbnQgeW91ICh5b3VyIFdHKSB3b3Vs ZA0KPiA+PiBsaWtlIHRvIG9yIGRlbWFuZCB0byBiZSBwYXJ0IG9mIHRoZSBlZmZvcnQgdG8gZGVm aW5lIGl0LiAgQXMgdGhlIEhUVFANCj4gPj4gZG9tYWluIGV4cGVydHMsIGFuZCB3ZSBiZWluZyB0 aGUgWUFORyBleHBlcnRzLCB0aGUgaWRlYWwgc2NlbmFyaW8gaXMNCj4gPj4gZm9yIHVzIHRvIHN0 cmlrZSBhIGNvbGxhYm9yYXRpb24uICBJbiBwYXJ0aWN1bGFyLCBnaXZlbiB0aGF0IHdlJ3JlDQo+ ID4+IHRyeWluZyB0byBwdXQgYW4gZW5kIHRvIHRoaXMgbmVhcmx5IDUteWVhciBsb25nIGVmZm9y dCwgd2UgcG9saXRlbHkNCj4gPj4gcmVxdWVzdCB0aGF0IHlvdSBnaXZlIHVzIHRoZSBibGVzc2lu ZyB0byBwcm9jZWVkIHJvdWdobHkgYXMgcGxhbm5lZA0KPiA+PiAoaS5lLiwgZGVmaW5pbmcgYSBt aW5pbWFsIHNrZWxldG9uIHdpdGggYXMgbWFueSAiZmVhdHVyZSIgc3RhdGVtZW50cw0KPiA+PiBh cyBuZWVkZWQpLiAgV2UgZW52aXNpb24gdGhpcyBhcyBhIHZlcnkgc2hvcnQgZW5nYWdlbWVudCAo TGFzdCBDYWxsDQo+ID4+IGltbWVkaWF0ZWx5IGFmdGVyIE1vbnRyZWFsKSwgYWZ0ZXIgd2hpY2gg dGhlIEhUVFAgbW9kZWwgd291bGQgbGlrZWx5DQo+ID4+IG9ubHkgYmUgdG91Y2hlZCBhZ2FpbiB3 aGVuIG5lZWRlZC4gIElmIGhpc3RvcnkgaXMgYSBndWlkZSwgSSdkIGd1ZXNzDQo+ID4+IHRoYXQg bWlnaHQgbm90IGhhcHBlbiBmb3IgMy01IHllYXJzLg0KPiA+PiANCj4gPj4gV291bGQgYSBjb2xs YWJvcmF0aW9uIGJlIG9rYXk/ICBJZiB5ZXMsIHRoZW4gaXMgdGhlcmUgc29tZW9uZSBpbg0KPiA+ PiBwYXJ0aWN1bGFyIHRoYXQgSSAoYXMgYSBjb250cmlidXRvci9hdXRob3IpIGNhbiBidWRkeSB1 cCB3aXRoIGluDQo+ID4+IEhUVFBCSVMgdG8gZ2V0IGV4cGVydC1sZXZlbCBhZHZpY2U/DQo+ID4+ IA0KPiA+IA0KPiA+IFRoaXMgcHV0cyB1cyBpbiBhIHRvdWdoIHNwb3QuIFRoZSAtMDAgZHJhZnQg ZG9lcyBub3QgZG8gYSBnb29kIGpvYiBvZg0KPiA+IGRlc2NyaWJpbmcgSFRUUCBzbyBJIGRvbid0 IGZlZWwgd2UgY2FuIGVuZG9yc2UgaXQuIFRoZSB3b3JraW5nIGdyb3VwDQo+ID4gaGFzIGFuIGV4 dGVuc2l2ZSBzZXQgb2YgYWRvcHRlZCBkcmFmdHMgcmlnaHQgbm93IGFuZCBJIGRvbid0IGJlbGll dmUNCj4gPiBpdCBpcyB0aGUgcmlnaHQgcHJpb3JpdHkgdG8gcHV0IHRoaXMgaW4gZnJvbnQgb2Yg dGhlbSB0b28gaW4gb3JkZXIgdG8NCj4gPiBwdXQgdGhlIHdvcmsgaW4gdG8gbWFrZSBpdCBhcHBy b3ByaWF0ZWx5IGV4cHJlc3NpdmUgLSBpdCB3b3VsZA0KPiA+IGRpc3RyYWN0IGZyb20gdGhlIHBy aW9yaXRpZXMgdGhlIGdyb3VwIGhhcyBkZWNpZGVkIG9uLg0KPiA+IA0KPiA+IFdoYXQgZG8geW91 IHRoaW5rIG9mIHJlY2FzdGluZyB0aGlzIGFzIGEgbW9kZWwgbGltaXRlZCB0byByZXN0Y29uZg0K PiA+IGJhc2VkIGFwcGxpY2F0aW9ucz8NCj4gPiANCj4gPiAtUGF0cmljaw0KPiANCj4gTWFoZXNo IEpldGhhbmFuZGFuaQ0KPiBtamV0aGFuYW5kYW5pQGdtYWlsLmNvbQ0KPiANCj4gPiANCg== From nobody Thu Apr 4 08:40:00 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934F91206C8 for ; Thu, 4 Apr 2019 08:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ducksong.com header.b=i1TnBFsC; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=mfjAkT6Y Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fB_pC80DD1HZ for ; Thu, 4 Apr 2019 08:39:51 -0700 (PDT) Received: from outbound1g.eu.mailhop.org (outbound1g.eu.mailhop.org [52.28.6.212]) (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 88A9C120678 for ; Thu, 4 Apr 2019 08:39:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554392324; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=c/P2z9GV3UDxjFD+c4GKVPrnGO5BnPY6wcZ4gkn/+Pa3eTjA16zmtDcTf644tV4x2Pj2tz4eV58Ou tW+JsaEBs6d22/3eyuaQ7n75ivJfrAizix13wTcfSL/X37CirCcwLaVji0vXbl8564p/yk5uhzUNLr y33v7MsFKt14bNYQa0uW0KXhWv9rkhg25YvqKvKaue2oXnmEQY4V1EIHOH3SvtDMi7tq0zSjtJJIqs qA6eY0c3l5Hl00p0E2US6SIsU36T6xIh6f/wpjhJCcuVRF8v0f/WbTUk4+jHIsoJBzK/Ye/2cjQgg2 X/YbsTCXJqGeg+FWuWgzrpuP5/ZHaKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=aKmpki/YEZEZlGYzIkEvnbc2kOL7uWkqibg976HCH3c=; b=X8e7n1akXMHlzCGdPNRuBKpgXT33rAxJdwETQnt8y9pDun0UVAVKZAFDD3GNKWyZvzfyGNeap5DPp 1sVJLmUKp60n2/CnEgScPr8z9GOlaMhrYwhRNcnxjyj86/8yz1NeEiTwGyuaWsLw5xSjIoHWqDFAHl icDEprIJOuaxVHvKXiSnkGa2zp0s7ZQC0u2gCtHxZtsyaydCV5h45YCXRo5cMoNadfD5W/mZF+bIfw 2Hxj8s8MHY3Z70nHBdcVnDgBxFBPgXuiAb+LTR/PAb5AVey+U0XmL1LuZUppiD3eip0DeAGNC8Rz7j EkS40R1ch4KqjdKZypn8IC7OQbSCUtA== ARC-Authentication-Results: i=1; outbound3.eu.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.210.44; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=aKmpki/YEZEZlGYzIkEvnbc2kOL7uWkqibg976HCH3c=; b=i1TnBFsCxLqkrC80+4udmMM2HsqOh1qXuX00ukleVZriVLOaWMiHvcymoY/Zp8DwsgszK15hEvfhF OlGA9YLBvIY4160LeHrW+gyQKoeJ2em+dA5xy894uHT7pNGyiEJXe+35EXM9bXraw+AV5lHTeJuyXd JlM1g5QiqOQSBUtk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=aKmpki/YEZEZlGYzIkEvnbc2kOL7uWkqibg976HCH3c=; b=mfjAkT6YgyWzAfOqeLxAMP4BwL/yID8S3xafisHKFXYN3ZgY/r0HZWFQxoAftt8MyItfsYIb7uMm9 SJ9rjf5XrtrqghpvWWqrXUqnRqGPVcTMbh2brDv4MfV19PV7H3fQXtcv7hV04brRlqTePuBtthPBBX 5MUNgCGxDv82d2DqO4QQtbpG9epf7Z1nwTH8IKTRwEsIOLa4Mv71kCcs/nsSIQ+oukoAQyloYRG4OC kW7GDFQQM18HtumQggojaazMCoaFnE8usQNx1NL9tc2ddi90rmLFD5BQ8yYdTOajzsQ1/OApfUStzn PFVhxB3+mWR05YVB6Y98B1NSUJGQXKQ== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: b86ef1be-56ef-11e9-908b-352056dbf2de X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.210.44 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-ot1-f44.google.com (unknown [209.85.210.44]) by outbound3.eu.mailhop.org (Halon) with ESMTPSA id b86ef1be-56ef-11e9-908b-352056dbf2de; Thu, 04 Apr 2019 15:38:41 +0000 (UTC) Received: by mail-ot1-f44.google.com with SMTP id t8so2736999otp.7; Thu, 04 Apr 2019 08:38:40 -0700 (PDT) X-Gm-Message-State: APjAAAXRTRdCsFDX36Dhx2+WkOcdlvhP7pgoEisgN+BDv58qX3K6wuxB TKL8MgjpXbNWF0swTmwdroLC9P3+OEa2pThZww8= X-Google-Smtp-Source: APXvYqyqrzOrp13WI2IlWNKlbr0tLaUCIwulD+0ic2/3zJ3HprYk6yQGz14vq2mnxHtsLCHJu7FxB6GXQ9nlWJ4aXyc= X-Received: by 2002:a9d:51d2:: with SMTP id d18mr4320401oth.61.1554392320016; Thu, 04 Apr 2019 08:38:40 -0700 (PDT) MIME-Version: 1.0 References: <01000169def07790-5f902f1b-ddce-438b-8e05-d4b7e82818bc-000000@email.amazonses.com> <56E946DC-A690-4B1E-8FB5-683473955C5D@gmail.com> <20190404.163346.857364419603319540.mbj@tail-f.com> In-Reply-To: <20190404.163346.857364419603319540.mbj@tail-f.com> From: Patrick McManus Date: Thu, 4 Apr 2019 17:38:28 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Martin Bjorklund Cc: mjethanandani@gmail.com, "Patrick R. McManus" , httpbis-chairs@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org Content-Type: multipart/alternative; boundary="0000000000001389980585b62a70" Archived-At: Subject: Re: [netconf] time to meet today after 5pm X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 15:39:59 -0000 --0000000000001389980585b62a70 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 4, 2019 at 4:33 PM Martin Bjorklund wrote: > > I don't think this is correct. In what way do you think RESTCONF > tries to use HTTP as a stateful transport? > > below > > > >> On Tue, Apr 2, 2019 at 6:44 PM Kent Watsen > > > >> Actually, "managing persistence" is exactly what we're trying to > > >> achieve here. Our show-stopping driving use-case regards RESTCONF > > >> Call Home (RFC 8071) and, in particular, point "S7" on page 8 of that > > >> document, without which a remote device may become a "brick" and > > >> require a technician to perform on-site repair. > also, in an exchange that wasn't copied to the wg,: > To give a concrete example, there may be a device, deployed behind a NAT, requiring a persistent management connection to its controller application. Because the device is behind a NAT, it MUST initiate the connection (the controller cannot) and, thus the device MUST ensure aliveness of the connection to the controller (the controller *needs* the device-initiated connection to be up in order to send commands to the device). In case the controller disappears, perhaps due to its data-center being hit by a meteor, the device must promptly detect to loss and initiate reconnection to another controller. > --0000000000001389980585b62a70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 4, 2019 at 4:33 PM Martin= Bjorklund <mbj@tail-f.com> wro= te:

I don't think this is correct.=C2=A0 In what way do you think RESTCONF<= br> tries to use HTTP as a stateful transport?


below
=C2=A0

> >> On Tue, Apr 2, 2019 at 6:44 PM Kent Watsen <kent+ietf@watsen.net><= br>
> >> Actually, "managing persistence" is exactly what we= 're trying to
> >> achieve here.=C2=A0 Our show-stopping driving use-case regard= s RESTCONF
> >> Call Home (RFC 8071) and, in particular, point "S7"= on page 8 of that
> >> document, without which a remote device may become a "br= ick" and
> >> require a technician to perform on-site repair.

also, in an exchange that wasn't copied to the w= g,:

> To give a concrete example, there may be = a device, deployed behind a NAT, requiring a persistent management connecti= on to its controller application.=C2=A0 Because the device is behind a NAT,= it MUST initiate the connection (the controller cannot) and, thus the devi= ce MUST ensure aliveness of the connection to the controller (the controlle= r *needs* the device-initiated connection to be up in order to send command= s to the device). =C2=A0 In case the controller disappears, perhaps due to = its data-center being hit by a meteor, the device must promptly detect to l= oss and initiate reconnection to another controller.



--0000000000001389980585b62a70-- From nobody Thu Apr 4 09:23:28 2019 Return-Path: <01000169e929781e-b0dcb6b3-af41-4f9c-ba52-ac4afb7164d4-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535E11201DE for ; Thu, 4 Apr 2019 09:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsJc-ep_Mnrh for ; Thu, 4 Apr 2019 09:23:24 -0700 (PDT) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9DB7120142 for ; Thu, 4 Apr 2019 09:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1554395003; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=3yc5dGWtckO4MmKToMD1v1elt/XcQy0Kztcp3PCRz8s=; b=VMRH3/NJi6P2YBsgJR8Nu9GWx3GTpIQ2INKVrOVLlXJSpkIiAVUen5gQE/u1VDr2 Mo/zs5CAc0/avYV0HteHKwrpTswiT13QgiV3twDUGfHO/HKYE+5ts3Oe/t6JR4CZbE3 2yi8skKlt5mIbCUj4WbYHJEcqBFO9EeED4NOQDyc= From: Kent Watsen Message-ID: <01000169e929781e-b0dcb6b3-af41-4f9c-ba52-ac4afb7164d4-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_66F9B161-BC13-4EDA-ABF7-1A2A87CAA7BC" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 4 Apr 2019 16:23:23 +0000 In-Reply-To: <20190403.134424.1377386644961079970.mbj@tail-f.com> Cc: Juergen Schoenwaelder , "netconf@ietf.org" To: Martin Bjorklund References: <01000169cb20ec39-94187bed-9312-4e19-a91f-466db763ee7e-000000@email.amazonses.com> <20190329205316.tcjzicuythyd4gvm@anna.jacobs.jacobs-university.de> <20190403.134424.1377386644961079970.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.04-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 16:23:27 -0000 --Apple-Mail=_66F9B161-BC13-4EDA-ABF7-1A2A87CAA7BC Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii >> and the creation of a private key that becomes (protected) >> configuration is similar to the creation of a user account, where an >> unused uid is allocated that becomes configuration. > > AFAIK there is no standard model defined that actually do this. Mostly true, though one might claim that is an example of an RPC that modifies configuration. > The closest thing we have is the "type" of an interface: > > When an interface entry is created, a server MAY > initialize the type leaf with a valid value, e.g., if it > is possible to derive the type from the name of the > interface. > > If private keys are handled like this, then I can accept it. This is not what is being asked for here. > But we > should NOT introduce special actions/rpcs that manipulate the > configuration. Why not? Not that it's a valid justification, but vendors do it already. What would it take to make it be not "special"? Would adding a standard (yang-next?) "modifies-configuration" leaf to the action/rpc definition suffice? FWIW, I do agree with Balazs, and argued as much a couple years ago, that the current approach is not best practice. That said, I'm more interested in the general-purpose use of rpcs/actions this way. We have always said no, but the reasoning is unclear. What are the specific objections and is there anyway to alleviate them? Kent // contributor --Apple-Mail=_66F9B161-BC13-4EDA-ABF7-1A2A87CAA7BC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

and the = creation of a private key that becomes (protected)
configuration is similar to the creation of a user account, = where an
unused uid is allocated that becomes = configuration.

AFAIK there is = no standard model defined that actually do this.

Mostly = true, though one might claim that <edit-config> is an = example 
of an RPC that modifies = configuration.


The closest = thing we have is the "type" of an interface:

=           When an = interface entry is created, a server MAY
=           initialize = the type leaf with a valid value, e.g., if it
=           is possible = to derive the type from the name of the
=           interface.

If private keys are handled like this, then I = can accept it.  

This is not what is being asked for = here.


But we
should NOT introduce special actions/rpcs that manipulate = the
configuration.

Why not?  Not that it's a valid = justification, but vendors do it already.
What would it take = to make it be not "special"?   Would adding a
standard = (yang-next?) "modifies-configuration" leaf to the = action/rpc
definition suffice?

FWIW, I do agree with Balazs, and argued as much a = couple years
ago, that the current approach is not best = practice.  That said, I'm
more interested in the = general-purpose use of rpcs/actions this way.

We have always said no, but the reasoning is = unclear.  What are the
specific objections and is there = anyway to alleviate them?


Kent // contributor


= --Apple-Mail=_66F9B161-BC13-4EDA-ABF7-1A2A87CAA7BC-- From nobody Thu Apr 4 09:42:20 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA89F12014E; Thu, 4 Apr 2019 09:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ew3SlH9P0n7J; Thu, 4 Apr 2019 09:42:16 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 248CC1200C7; Thu, 4 Apr 2019 09:42:15 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 7F3F0CE2; Thu, 4 Apr 2019 18:42:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 5mes5GbbG0Hh; Thu, 4 Apr 2019 18:42:13 +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 atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 4 Apr 2019 18:42:13 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 41718200BA; Thu, 4 Apr 2019 18:42:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id pcpBDYy3mBJz; Thu, 4 Apr 2019 18:42:13 +0200 (CEST) Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id B873A200B8; Thu, 4 Apr 2019 18:42:12 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Thu, 4 Apr 2019 18:42:12 +0200 Received: by anna.localdomain (Postfix, from userid 501) id E236C3007B0CF4; Thu, 4 Apr 2019 18:42:11 +0200 (CEST) Date: Thu, 4 Apr 2019 18:42:11 +0200 From: Juergen Schoenwaelder To: Patrick McManus CC: Martin Bjorklund , , , Message-ID: <20190404164211.dm7qpvt33kv3x5gj@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Patrick McManus , Martin Bjorklund , netconf-chairs@ietf.org, httpbis-chairs@ietf.org, netconf@ietf.org References: <01000169def07790-5f902f1b-ddce-438b-8e05-d4b7e82818bc-000000@email.amazonses.com> <56E946DC-A690-4B1E-8FB5-683473955C5D@gmail.com> <20190404.163346.857364419603319540.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netconf] time to meet today after 5pm X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 16:42:19 -0000 On Thu, Apr 04, 2019 at 05:38:28PM +0200, Patrick McManus wrote: > On Thu, Apr 4, 2019 at 4:33 PM Martin Bjorklund wrote: > > > > > I don't think this is correct. In what way do you think RESTCONF > > tries to use HTTP as a stateful transport? [...] > To give a concrete example, there may be a device, deployed behind a NAT, > requiring a persistent management connection to its controller > application. Because the device is behind a NAT, it MUST initiate the > connection (the controller cannot) and, thus the device MUST ensure > aliveness of the connection to the controller (the controller *needs* the > device-initiated connection to be up in order to send commands to the > device). In case the controller disappears, perhaps due to its > data-center being hit by a meteor, the device must promptly detect to loss > and initiate reconnection to another controller. The issue here seems to be a NAT requiring state, not the RESTCONF protocol itself requiring state. /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 Apr 4 09:49:35 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FE5120112 for ; Thu, 4 Apr 2019 09:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyWymsFUN6lG for ; Thu, 4 Apr 2019 09:49:33 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E55E12010D for ; Thu, 4 Apr 2019 09:49:33 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id CEE1FE10; Thu, 4 Apr 2019 18:49:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id S0s7S61gBubv; Thu, 4 Apr 2019 18:49:31 +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 atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 4 Apr 2019 18:49:31 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 90F1B200BA; Thu, 4 Apr 2019 18:49:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id ZhDgBRomPt6R; Thu, 4 Apr 2019 18:49:31 +0200 (CEST) Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 5903A200B8; Thu, 4 Apr 2019 18:49:31 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Thu, 4 Apr 2019 18:49:30 +0200 Received: by anna.localdomain (Postfix, from userid 501) id 633653007B0DF9; Thu, 4 Apr 2019 18:49:29 +0200 (CEST) Date: Thu, 4 Apr 2019 18:49:29 +0200 From: Juergen Schoenwaelder To: Kent Watsen CC: Martin Bjorklund , "netconf@ietf.org" Message-ID: <20190404164929.fsfga7s4izn7ucx5@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , Martin Bjorklund , "netconf@ietf.org" References: <01000169cb20ec39-94187bed-9312-4e19-a91f-466db763ee7e-000000@email.amazonses.com> <20190329205316.tcjzicuythyd4gvm@anna.jacobs.jacobs-university.de> <20190403.134424.1377386644961079970.mbj@tail-f.com> <01000169e929781e-b0dcb6b3-af41-4f9c-ba52-ac4afb7164d4-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <01000169e929781e-b0dcb6b3-af41-4f9c-ba52-ac4afb7164d4-000000@email.amazonses.com> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 16:49:35 -0000 On Thu, Apr 04, 2019 at 04:23:23PM +0000, Kent Watsen wrote: > > > We have always said no, but the reasoning is unclear. What are the > specific objections and is there anyway to alleviate them? > If editing of all configuration can be done with a single edit-data (or edit-config) operation, you simplify the world and you enable generic implementations. Once you build silos of data that can only be manipulated with special purpose operations, you say goodbye to the idea of generic client libraries. /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 Apr 4 09:51:40 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C00120121 for ; Thu, 4 Apr 2019 09:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODinFP50MhlZ for ; Thu, 4 Apr 2019 09:51:36 -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 0ADBB120117 for ; Thu, 4 Apr 2019 09:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13190; q=dns/txt; s=iport; t=1554396696; x=1555606296; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sn8gwfCvtpgHO+46jmJ++O+LI3iPLCvAfr1kVLIuIhk=; b=lNy6YmfxvvFhSk9YXhsOpHSwV3Wgo/XPDm5Cdu90uzPoXd+cKWOvfmZO VL4d5HAsIl4NzH7Cwh5Cs1l4q+WcfbVaFLwpeZ5vtACgCHm6oSg1Pd51X j3oTzgk03/WK9U242yJOnT/nZH+38Um3Ygc/dFYG+IP2MPPFJg5XX3/LR g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAAAoNaZc/4cNJK1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBgQ6BAmiBAycKmUiSS4YMgWcOAQGEbAK?= =?us-ascii?q?FTSI3Bg0BAQMBAQkBAwJtKIVKAQEBAQMtTBACAQgRBAEBFhkyHQgCBAENBQg?= =?us-ascii?q?TgwiBEWSvaYozgTABiW6BRBeBQD+BEYMSPoN/L1WFIgOKU4ZhHpQYCQKTcCK?= =?us-ascii?q?CBYlwiFqDVod5k3ACERWBMDUigVZwFYMnghYXjh9BMY9JgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.60,308,1549929600"; d="scan'208,217";a="253885208" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Apr 2019 16:51:34 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x34GpYBb010117 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Apr 2019 16:51:34 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 4 Apr 2019 11:51:33 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Thu, 4 Apr 2019 11:51:33 -0500 From: "Rob Wilton (rwilton)" To: Kent Watsen , Martin Bjorklund CC: "netconf@ietf.org" Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpAB55r2AAFc4f4AA2LGYAAAA+NoAAOhJxAAAPAjogAAJwD2w Date: Thu, 4 Apr 2019 16:51:33 +0000 Message-ID: References: <01000169cb20ec39-94187bed-9312-4e19-a91f-466db763ee7e-000000@email.amazonses.com> <20190329205316.tcjzicuythyd4gvm@anna.jacobs.jacobs-university.de> <20190403.134424.1377386644961079970.mbj@tail-f.com> <01000169e929781e-b0dcb6b3-af41-4f9c-ba52-ac4afb7164d4-000000@email.amazonses.com> In-Reply-To: <01000169e929781e-b0dcb6b3-af41-4f9c-ba52-ac4afb7164d4-000000@email.amazonses.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.63.23.177] Content-Type: multipart/alternative; boundary="_000_a668ce8a370049769a82eb1250f139e3XCHRCD007ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 16:51:39 -0000 --_000_a668ce8a370049769a82eb1250f139e3XCHRCD007ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, Inline with [RW] From: netconf On Behalf Of Kent Watsen Sent: 04 April 2019 17:23 To: Martin Bjorklund Cc: netconf@ietf.org Subject: Re: [netconf] ietf crypto types - permanently hidden and the creation of a private key that becomes (protected) configuration is similar to the creation of a user account, where an unused uid is allocated that becomes configuration. AFAIK there is no standard model defined that actually do this. Mostly true, though one might claim that is an example of an RPC that modifies configuration. [RW] But in this case, the updated configuration is provided by the client, not = the server. I.e. it is clear which entity owns the configuration, and is t= he "source of truth". The closest thing we have is the "type" of an interface: When an interface entry is created, a server MAY initialize the type leaf with a valid value, e.g., if it is possible to derive the type from the name of the interface. If private keys are handled like this, then I can accept it. This is not what is being asked for here. But we should NOT introduce special actions/rpcs that manipulate the configuration. Why not? Not that it's a valid justification, but vendors do it already. What would it take to make it be not "special"? Would adding a standard (yang-next?) "modifies-configuration" leaf to the action/rpc definition suffice? FWIW, I do agree with Balazs, and argued as much a couple years ago, that the current approach is not best practice. That said, I'm more interested in the general-purpose use of rpcs/actions this way. We have always said no, but the reasoning is unclear. What are the specific objections and is there anyway to alleviate them? [RW] I think that is bad practice for a server to inject configuration into . It makes it ambiguous as to which entity really owns the configurat= ion. I think that what is in should be owned by the client, not= the server. I'm not saying that nobody does this, but I don't believe tha= t it is the cleanest solution. I'm OK with a server injecting configuration between and , and using NACM to prevent that value from being read back from . I'm OK with the server just reporting the default system allocated value in= , again protected by NACM if appropriate. Thanks, Rob Kent // contributor --_000_a668ce8a370049769a82eb1250f139e3XCHRCD007ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kent,

 = ;

Inline wit= h [RW]

 = ;

From: = netconf <netconf-bounces@ietf.org> On Behalf Of Kent Watsen
Sent: 04 April 2019 17:23
To: Martin Bjorklund <mbj@tail-f.com>
Cc: netconf@ietf.org
Subject: Re: [netconf] ietf crypto types - permanently hidden

 

 



and the creation of a private key that becomes (prot= ected)
configuration is similar to the creation of a user account, where an
unused uid is allocated that becomes configuration.


AFAIK there is no standard model defined that actually do this.<= /p>

 

Mostly true, though one might claim that <edit-co= nfig> is an example 

of an RPC that modifies configuration.

 

[RW]

But in this case, the updated c= onfiguration is provided by the client, not the server.  I.e. it is cl= ear which entity owns the configuration, and is the “source of truth”.



The closest thing we have is the "type" of= an interface:

          When an interfa= ce entry is created, a server MAY
          initialize the = type leaf with a valid value, e.g., if it
          is possible to = derive the type from the name of the
          interface.

If private keys are handled like this, then I can accept it.  

 

This is not what is being asked for here.=

 



But we
should NOT introduce special actions/rpcs that manipulate the
configuration.

 

Why not?  Not that it's a valid justification, = but vendors do it already.

What would it take to make it be not "special&q= uot;?   Would adding a

standard (yang-next?) "modifies-configuration&q= uot; leaf to the action/rpc

definition suffice?

 

FWIW, I do agree with Balazs, and argued as much a c= ouple years

ago, that the current approach is not best practice.=  That said, I'm

more interested in the general-purpose use of rpcs/a= ctions this way.

 

We have always said no, but the reasoning is unclear= .  What are the

specific objections and is there anyway to alleviate= them?

 

[RW]

I think that is bad practice fo= r a server to inject configuration into <running>.  It makes it = ambiguous as to which entity really owns the configuration.   I think that what is in <running> should be owned by the clien= t, not the server.  I’m not saying that nobody does this, but I = don’t believe that it is the cleanest solution.=

 

I’m OK with a server inje= cting configuration between <running> and <intended>, and using= NACM to prevent that value from being read back from <intended>.

 

I’m OK with the server ju= st reporting the default system allocated value in <operational>, aga= in protected by NACM if appropriate.

 

Thanks,
Rob

 

 

 

Kent // contributor

 

 

--_000_a668ce8a370049769a82eb1250f139e3XCHRCD007ciscocom_-- From nobody Thu Apr 4 10:05:19 2019 Return-Path: <01000169e94f9d0d-7f85f47b-9f92-41a2-94b1-0061bb9bdb3d-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CB7120104; Thu, 4 Apr 2019 10:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArIxsRU6dvLn; Thu, 4 Apr 2019 10:05:15 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F96E120642; Thu, 4 Apr 2019 10:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1554397503; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=LyMnICVBrIBaE6hETiJBdMMUtfv2oxr7GRYsHdoDvOs=; b=TQLHmmuXd1/63lijmgmgH2ErAloRQ2aj6dk8l/FxHs8R3WmH4ZSA2qLdw1RB7lmI n01D81Of85MoleGF9B6w9gzLso+cuTgaSDpnq8r/7Kz/cB/5D/MPEzBdpIC3F0aQx3n iiKmwaeD4vXnFe5jYQkOrPhpG1uXQnwI44MvCqwo= From: Kent Watsen Message-ID: <01000169e94f9d0d-7f85f47b-9f92-41a2-94b1-0061bb9bdb3d-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B1714681-2C8F-47AC-B660-D84677E432D8" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 4 Apr 2019 17:05:02 +0000 In-Reply-To: Cc: Martin Bjorklund , "netconf-chairs@ietf.org" , httpbis-chairs@ietf.org, "netconf@ietf.org" To: Patrick McManus References: <01000169def07790-5f902f1b-ddce-438b-8e05-d4b7e82818bc-000000@email.amazonses.com> <56E946DC-A690-4B1E-8FB5-683473955C5D@gmail.com> <20190404.163346.857364419603319540.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.04-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] time to meet today after 5pm X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 17:05:18 -0000 --Apple-Mail=_B1714681-2C8F-47AC-B660-D84677E432D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > I don't think this is correct. In what way do you think RESTCONF > tries to use HTTP as a stateful transport? >=20 >=20 > below > =20 >=20 > > >> On Tue, Apr 2, 2019 at 6:44 PM Kent Watsen > >=20 > > >> Actually, "managing persistence" is exactly what we're trying to > > >> achieve here. Our show-stopping driving use-case regards = RESTCONF > > >> Call Home (RFC 8071) and, in particular, point "S7" on page 8 of = that > > >> document, without which a remote device may become a "brick" and > > >> require a technician to perform on-site repair. >=20 > also, in an exchange that wasn't copied to the wg,: >=20 > > To give a concrete example, there may be a device, deployed behind a = NAT, requiring a persistent management connection to its controller = application. Because the device is behind a NAT, it MUST initiate the = connection (the controller cannot) and, thus the device MUST ensure = aliveness of the connection to the controller (the controller *needs* = the device-initiated connection to be up in order to send commands to = the device). In case the controller disappears, perhaps due to its = data-center being hit by a meteor, the device must promptly detect to = loss and initiate reconnection to another controller. To be clear, RESTCONF is not trying to use HTTP as a stateful protocol, = but it is ideal to try to keep RESTCONF Call Home connections up, as = described above. Per the "S7" reference, devices SHOULD use RFC 6520 = (the TLS heartbeat extension). This would keep the *stateful* = transport (TLS) up but, unfortunately, OpenSSL doesn't want to implement = it (worst, they just removed the DTLS code, = https://github.com/openssl/openssl/issues/4856 = , despite Ben Kaduk and = myself stating value). The thinking behind this thread is that maybe some traffic could run on = top of TLS (i.e., at the HTTP layer), to do the same and, if not, then = maybe we could do it at the RESTCONF layer. [FWIW, you might recall = NETCONF/RESTCONF keepalives discusseded at the IETF 103 meeting.] Patrick, if HTTP keepalive is not possible, then lets strike the = "keepalive" parts from the ietf-http-client and ietf-http-server models, = leaving it to implementations to lean more heavily on their TLS = suppliers to implement RFC 6520, or fallback to unprotected TCP = keepalives (which is what the BBF/Nokia said they would be doing for = expediency). Regarding the rest, let me clean the remaining bits (i.e., = post a -01) and present them to you again then. For everyone else, this email thread is from last week when Mahesh and I = were trying to meet with the HTTPBIS chairs to discuss the = http-client-server draft under adoption poll. We wanted to proactively = engage HTTPBIS rather than have any surprises, such as the exchange with = TCPM. Our hope is that we can come to an agreement, like the one = struck with TCPM, whereby domain experts in each WG co-author a = bare-minimum grouping that enables our 5-year chartered work effort to = come to an end. With regards to Last Call, we can do it joint Last = Call, if desired. For longterm maintenance of the YANG model, we're = happy to turn it over to the domain-specific WG, though we don't have = any need or expectation for an update, the bare-minimum is sufficient. Kent // pick a hat --Apple-Mail=_B1714681-2C8F-47AC-B660-D84677E432D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


I don't think this is correct.  = In what way do you think RESTCONF
tries to use HTTP as a stateful transport?


below
 

> >> On Tue, Apr 2, 2019 at 6:44 PM Kent Watsen <kent+ietf@watsen.net>

> >> Actually, "managing persistence" is exactly what we're = trying to
> >> achieve here.  Our show-stopping driving use-case = regards RESTCONF
> >> Call Home (RFC 8071) and, in particular, point "S7" on = page 8 of that
> >> document, without which a remote device may become a = "brick" and
> >> require a technician to perform on-site repair.

also, in an exchange that wasn't copied to the wg,:

> To give a concrete = example, there may be a device, deployed behind a NAT, requiring a = persistent management connection to its controller application.  = Because the device is behind a NAT, it MUST initiate the connection (the = controller cannot) and, thus the device MUST ensure aliveness of the = connection to the controller (the controller *needs* the = device-initiated connection to be up in order to send commands to the = device).   In case the controller disappears, perhaps due to its = data-center being hit by a meteor, the device must promptly detect to = loss and initiate reconnection to another = controller.


To be clear, RESTCONF is = not trying to use HTTP as a stateful protocol, but it is ideal to try to = keep RESTCONF Call Home connections up, as described above.   Per = the "S7" reference, devices SHOULD use RFC 6520 (the TLS heartbeat = extension).   This would keep the *stateful* transport (TLS) up = but, unfortunately, OpenSSL doesn't want to implement it (worst, they = just removed the DTLS code, https://github.com/openssl/openssl/issues/4856, despite = Ben Kaduk and myself stating value).

The thinking behind this thread is that = maybe some traffic could run on top of TLS (i.e., at the HTTP layer), to = do the same and, if not, then maybe we could do it at the RESTCONF = layer.  [FWIW, you might recall NETCONF/RESTCONF keepalives = discusseded at the IETF 103 meeting.]

Patrick, if HTTP keepalive is not = possible, then lets strike the "keepalive" parts from the = ietf-http-client and ietf-http-server models, leaving it to = implementations to lean more heavily on their TLS suppliers to implement = RFC 6520, or fallback to unprotected TCP keepalives (which is what the = BBF/Nokia said they would be doing for expediency).  Regarding the = rest, let me clean the remaining bits (i.e., post a -01) and present = them to you again then.

For everyone else, this email thread is from last week when = Mahesh and I were trying to meet with the HTTPBIS chairs to discuss the = http-client-server draft under adoption poll.  We wanted to = proactively engage HTTPBIS rather than have any surprises, such as the = exchange with TCPM.   Our hope is that we can come to an agreement, = like the one struck with TCPM, whereby domain experts in each WG = co-author a bare-minimum grouping that enables our 5-year chartered work = effort to come to an end.  With regards to Last Call, we can do it = joint Last Call, if desired.   For longterm maintenance of the YANG = model, we're happy to turn it over to the domain-specific WG, though we = don't have any need or expectation for an update, the bare-minimum is = sufficient.

Kent= // pick a hat



= --Apple-Mail=_B1714681-2C8F-47AC-B660-D84677E432D8-- From nobody Thu Apr 4 10:12:47 2019 Return-Path: <01000169e95687c5-a1809710-e13d-4bc3-a5d3-5387af4112b7-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECB91201CC for ; Thu, 4 Apr 2019 10:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyqN4SdwlFsl for ; Thu, 4 Apr 2019 10:12:44 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D311204AD for ; Thu, 4 Apr 2019 10:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1554397956; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=J/XmdKKIk3BGn91BrruTHqPItYq4xXR7eTVg4fOgFN0=; b=JZSOwLtunNwXdbyXyuJlC+Hvm8etXykQYvdqbjohaP9W8jId3JpKTrqxwJ1Q3m6G oV2EL9Fx050mzIEGtxmtRYm0ei5GJg5pCxIgqCKnSyAkmDQjMP+SD0ezLL8C/ItnFgu L7uCXyJYRsNXExROEzvt35pceDFB7A3IEpHqd3S8= From: Kent Watsen Message-ID: <01000169e95687c5-a1809710-e13d-4bc3-a5d3-5387af4112b7-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7E17FF6A-AB81-4648-A743-21A547D30A48" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 4 Apr 2019 17:12:36 +0000 In-Reply-To: Cc: Martin Bjorklund , "netconf@ietf.org" To: "Rob Wilton (rwilton)" References: <01000169cb20ec39-94187bed-9312-4e19-a91f-466db763ee7e-000000@email.amazonses.com> <20190329205316.tcjzicuythyd4gvm@anna.jacobs.jacobs-university.de> <20190403.134424.1377386644961079970.mbj@tail-f.com> <01000169e929781e-b0dcb6b3-af41-4f9c-ba52-ac4afb7164d4-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.04-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 17:12:46 -0000 --Apple-Mail=_7E17FF6A-AB81-4648-A743-21A547D30A48 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > [RW] > I think that is bad practice for a server to inject configuration into = . It makes it ambiguous as to which entity really owns the = configuration. I think that what is in should be owned by = the client, not the server. I=E2=80=99m not saying that nobody does = this, but I don=E2=80=99t believe that it is the cleanest solution. >=20 We're not talking about the server doing something on its own accord = here; this would be a direct result of a client request. Abstractly, = such can be considered configuration as legitimate as configuration = provided by any other means. Kent // contributor --Apple-Mail=_7E17FF6A-AB81-4648-A743-21A547D30A48 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

[RW]

I think that is bad practice for a server to inject = configuration into <running>.  It makes it ambiguous as to = which entity really owns the configuration.   I think that what is in <running> should be owned by the = client, not the server.  I=E2=80=99m not saying that nobody does = this, but I don=E2=80=99t believe that it is the cleanest = solution.



We're not talking about the server doing something = on its own accord here; this would be a direct result of a client = request.  Abstractly, such can be considered configuration as = legitimate as configuration provided by any other means.

Kent // contributor




= --Apple-Mail=_7E17FF6A-AB81-4648-A743-21A547D30A48-- From nobody Thu Apr 4 10:24:21 2019 Return-Path: <01000169e9613a53-6b1ac2ef-810e-476b-84a5-0eb388e7af48-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F092312008D for ; Thu, 4 Apr 2019 10:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiHS1LoLvCgS for ; Thu, 4 Apr 2019 10:24:18 -0700 (PDT) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7573D12000F for ; Thu, 4 Apr 2019 10:24:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1554398657; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=q+Omh3IK9V1x6QDFE00h5R6CkrFDk9nReheq1KdBGDo=; b=cc76ehCdkvprMQcpqukQTCP3L/dLq2zlhVfqGRgGwT4elnubbJHD6hdWlGTcDWPj PdBjr1px7LXRKkchqNiZI3V0iO33UJRx5Zu8IlrMBnvaVDD505Ltm52c10D1YJG6Umc 6C/Is5CtvtsCySWc7xgtBeMRpfj+1bRytAKpxLyQ= From: Kent Watsen Message-ID: <01000169e9613a53-6b1ac2ef-810e-476b-84a5-0eb388e7af48-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_42BBDE71-24DE-4B4B-AEA9-78100B02031F" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 4 Apr 2019 17:24:17 +0000 In-Reply-To: <20190404164929.fsfga7s4izn7ucx5@anna.jacobs.jacobs-university.de> Cc: Martin Bjorklund , "netconf@ietf.org" To: Juergen Schoenwaelder References: <01000169cb20ec39-94187bed-9312-4e19-a91f-466db763ee7e-000000@email.amazonses.com> <20190329205316.tcjzicuythyd4gvm@anna.jacobs.jacobs-university.de> <20190403.134424.1377386644961079970.mbj@tail-f.com> <01000169e929781e-b0dcb6b3-af41-4f9c-ba52-ac4afb7164d4-000000@email.amazonses.com> <20190404164929.fsfga7s4izn7ucx5@anna.jacobs.jacobs-university.de> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.04-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 17:24:20 -0000 --Apple-Mail=_42BBDE71-24DE-4B4B-AEA9-78100B02031F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii >> We have always said no, but the reasoning is unclear. What are the >> specific objections and is there anyway to alleviate them? >> > > If editing of all configuration can be done with a single edit-data > (or edit-config) operation, you simplify the world and you enable > generic implementations. > > Once you build silos of data that can only be manipulated with special > purpose operations, you say goodbye to the idea of generic client > libraries. Fair, so what can we do to ensure this doesn't spiral out of control? Clearly there is some line being crossed here (a Security best practice) that is driving this. Could we add that such use MUST only be done in order to resolve a Security best practice? That said, I think your fear is unwarranted. I do not believe that folks would rush to defined 1000s of RPCs. It seems that such use would be done only in extenuating circumstances. And, besides, so what? Why do we care if people do stupid things? Do we feel that our obligation to prevent people from doing stupid things is more important than enabling people to do smart things? Kent --Apple-Mail=_42BBDE71-24DE-4B4B-AEA9-78100B02031F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

We have = always said no, but the reasoning is unclear.  What are the
specific objections and is there anyway to alleviate them?


If editing of all = configuration can be done with a single edit-data
(or = edit-config) operation, you simplify the world and you enable
generic implementations.

Once = you build silos of data that can only be manipulated with special
purpose operations, you say goodbye to the idea of generic = client
libraries.

Fair, so what can we do to ensure this doesn't spiral out of = control?

Clearly= there is some line being crossed here (a Security best = practice)
that is driving this.   Could we add = that such use MUST only be done in 
order to = resolve a Security best practice?

That said, I think your fear is = unwarranted.  I do not believe that folks
would = rush to defined 1000s of RPCs.   It seems that such use = would
be done only in extenuating = circumstances.

And, besides, so what?  Why do we care if people do = stupid things?
Do we feel that our obligation to = prevent people from doing stupid
things is more = important than enabling people to do smart things?

Kent

= --Apple-Mail=_42BBDE71-24DE-4B4B-AEA9-78100B02031F-- From nobody Thu Apr 4 10:46:30 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D191205FB for ; Thu, 4 Apr 2019 10:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kVSaB11lHPa for ; Thu, 4 Apr 2019 10:46:27 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 36AA01205F7 for ; Thu, 4 Apr 2019 10:46:26 -0700 (PDT) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 8E57C1AE0386; Thu, 4 Apr 2019 19:46:23 +0200 (CEST) Date: Thu, 04 Apr 2019 19:46:23 +0200 (CEST) Message-Id: <20190404.194623.1178346313710501110.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: kent+ietf@watsen.net, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <20190404164929.fsfga7s4izn7ucx5@anna.jacobs.jacobs-university.de> References: <20190403.134424.1377386644961079970.mbj@tail-f.com> <01000169e929781e-b0dcb6b3-af41-4f9c-ba52-ac4afb7164d4-000000@email.amazonses.com> <20190404164929.fsfga7s4izn7ucx5@anna.jacobs.jacobs-university.de> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 17:46:29 -0000 Juergen Schoenwaelder wrote: > On Thu, Apr 04, 2019 at 04:23:23PM +0000, Kent Watsen wrote: > > > > > > We have always said no, but the reasoning is unclear. What are the > > specific objections and is there anyway to alleviate them? > > > > If editing of all configuration can be done with a single edit-data > (or edit-config) operation, you simplify the world and you enable > generic implementations. > > Once you build silos of data that can only be manipulated with special > purpose operations, you say goodbye to the idea of generic client > libraries. And you can no longer create all required config in one transaction; you have to split it into sending multiple special-purpose actions. Perhaps also in a certain order, that you have to figure out somehow, since config might have refererences to other partf of the config etc. You can no longer restore a backup with just a copy-config. So I don't think the reasoning is unclear at all. /martin From nobody Thu Apr 4 11:21:41 2019 Return-Path: <01000169e994ab6b-8d0de949-b410-419e-82bc-2fec1d8fa724-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535B4120427 for ; Thu, 4 Apr 2019 11:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cx7ctQ2IiSyC for ; Thu, 4 Apr 2019 11:21:37 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74EDF1201A7 for ; Thu, 4 Apr 2019 11:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1554402028; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=KFOEdvDaCb+CBrD7yL/kHj2lGNRmwU0WkgO43rx8Bxg=; b=B2fQSIWphsXBQB5wVddOoS7z5yUNUerlDG08Mkt+KRv+4OCbw7NUgqM8ZV2gq5/C 87EPwxCMbROJ/iiAeuqxY7pJ4hhU/RHpRz19xS5CiUOCxyv0J1qUjVo2wUvKndQBmaX 0hJeyUhITGzFhbWNMScmogbKW+cq4h7NTRzDvEJY= From: Kent Watsen Message-ID: <01000169e994ab6b-8d0de949-b410-419e-82bc-2fec1d8fa724-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1265E9FB-671B-4055-972E-AFF176A56699" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 4 Apr 2019 18:20:28 +0000 In-Reply-To: <20190404.194623.1178346313710501110.mbj@tail-f.com> Cc: Juergen Schoenwaelder , "netconf@ietf.org" To: Martin Bjorklund References: <20190403.134424.1377386644961079970.mbj@tail-f.com> <01000169e929781e-b0dcb6b3-af41-4f9c-ba52-ac4afb7164d4-000000@email.amazonses.com> <20190404164929.fsfga7s4izn7ucx5@anna.jacobs.jacobs-university.de> <20190404.194623.1178346313710501110.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.04-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 18:21:39 -0000 --Apple-Mail=_1265E9FB-671B-4055-972E-AFF176A56699 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On Apr 4, 2019, at 1:46 PM, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: >> On Thu, Apr 04, 2019 at 04:23:23PM +0000, Kent Watsen wrote: >>> >>> >>> We have always said no, but the reasoning is unclear. What are the >>> specific objections and is there anyway to alleviate them? >>> >> >> If editing of all configuration can be done with a single edit-data >> (or edit-config) operation, you simplify the world and you enable >> generic implementations. >> >> Once you build silos of data that can only be manipulated with special >> purpose operations, you say goodbye to the idea of generic client >> libraries. > > And you can no longer create all required config in one transaction; > you have to split it into sending multiple special-purpose actions. > Perhaps also in a certain order, that you have to figure out somehow, > since config might have refererences to other partf of the config > etc. > > You can no longer restore a backup with just a copy-config. > > So I don't think the reasoning is unclear at all. This is a good start to a list of limitations that could be added to a description statement. Let people decide. In this case, not a big deal. Kent // contributor --Apple-Mail=_1265E9FB-671B-4055-972E-AFF176A56699 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 4, 2019, at 1:46 PM, Martin Bjorklund <mbj@tail-f.com> = wrote:

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Apr 04, 2019 at = 04:23:23PM +0000, Kent Watsen wrote:


We have always = said no, but the reasoning is unclear.  What are the
specific objections and is there anyway to alleviate them?


If editing of all = configuration can be done with a single edit-data
(or = edit-config) operation, you simplify the world and you enable
generic implementations.

Once = you build silos of data that can only be manipulated with special
purpose operations, you say goodbye to the idea of generic = client
libraries.

And you can no longer create all required config in one = transaction;
you have to split it into sending multiple = special-purpose actions.
Perhaps also in a certain order, = that you have to figure out somehow,
since config might = have refererences to other partf of the config
etc.

You can no longer restore a backup with just a = copy-config.

So I don't think the reasoning = is unclear at all.


This is = a good start to a list of limitations that could be added to
a description statement.  Let people decide.  In = this case, not a 
big deal.

Kent // = contributor


 
= --Apple-Mail=_1265E9FB-671B-4055-972E-AFF176A56699-- From nobody Fri Apr 5 02:12:56 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD06120398; Fri, 5 Apr 2019 02:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hansfords.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 ZAAH6t2UHDp2; Fri, 5 Apr 2019 02:12:43 -0700 (PDT) Received: from mail.myfast.site (mail.myfast.site [109.203.117.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC2612039A; Fri, 5 Apr 2019 02:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qeSGc3vONy7/tfLVVBJPQdV/3111AtnW5ECCZJ+T2wY=; b=bPnXcyEZbB/vUDVHsH6YBW8vhX E9SMS5vE02FGvepiq2P0jyNg4ExL7g7JEXmDcoBK78s0PzsDINn48ulmM5LlZrtkzLIiNOQffS02g 3EH3D0DMX6rnjOFL7/c32M/ccflrOyC6LzNhGtNePAmwnRGtqw22xmxxTI+CBfVxvhALl/Xt/HKlB w6+Ximm6l4xWuQjD9y2BvGVmbkJgLQCrgjyj9KoFzeiIWqgc1SPOKhCE813rjiYoovJ993jnGXl/p y4LwjAzhSBLtkt+b5Ou6tnL6hMlbHMv9CAZu3mSn/zehGTiGAgegEu5cvddUIhb3xHocOIyff5QPQ lFWgX/WA==; Received: from hansfords.plus.com ([84.92.116.209]:52588 helo=Vanguard) by mail.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hCKtp-003nE5-Cl; Fri, 05 Apr 2019 10:12:37 +0100 From: To: "'Per Hedeland'" , "'Martin Bjorklund'" Cc: , , , , , , "'Juergen Schoenwaelder'" , "'Andy Bierman'" , "'Robert Wilton'" References: <20140113155326.2E4B97FC396@rfc-editor.org> <74C3A7F7-B338-4B9F-AD61-66F39EA43FC9@amsl.com> <34e64e9f-f3a0-9c4f-9860-e69e120e926c@hedeland.org> <20190221.142233.540619960445664842.mbj@tail-f.com> In-Reply-To: Date: Fri, 5 Apr 2019 10:12:37 +0100 Message-ID: <008001d4eb8f$b71f9ce0$255ed6a0$@hansfords.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQE+wu+3N6Bb48thUdvloAZ9jidAOALjD61/Ah3GzdUCZwYXwAGaEPBnpxGJ4CA= Content-Language: en-gb X-Antivirus: Avast (VPS 190405-0, 05/04/2019), Outbound message X-Antivirus-Status: Clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mail.myfast.site X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hansfords.net X-Get-Message-Sender-Via: mail.myfast.site: authenticated_id: jonathan@hansfords.net X-Authenticated-Sender: mail.myfast.site: jonathan@hansfords.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [netconf] [Errata Held for Document Update] RFC6241 (3821) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 09:12:48 -0000 Hi, Apologies for taking so long to reply. I have been out of the loop for some= time. And apologies for not involving the mailing list. The RFC Errata page= states, "Note: To report an error in an existing erratum, please contact th= e RFC Editor", so that is what I did. Maybe the note could be a bit more informative for those not au fait with all the correct procedures to follow= within the IETF. Further, I concur only the parameter affects persistence, and not= the parameter. Apologies again. I am trying to understand the correct behaviour of clients and servers with= persistent confirmed commits, and in particular the persistence of locks an= d configuration changes following a session termination. The reason is that I= have dealt with some elements that always restart when their configuration changes, and I want to understand what is and isn't possible in that scenario with NETCONF (RFC 6241). It would be helpful if someone could confirm (or otherwise) my thoughts below. We intend to support :candidate but not :writable-running. THE PERSISTENCE OF A CONFIRMED COMMIT FOLLOWING SESSION TERMINATION Section 8.3.5.2 :candidate and states: When a client fails with outstanding changes to the candidate configuration, recovery can be difficult. To facilitate easy recovery, any outstanding changes are discarded when the lock is released, whether explicitly with the operation or implicitly from session failure. Section 8.4.1 :confirmed-commit states: If the session issuing the confirmed commit is terminated for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the confirmed commit was issued, unless the confirmed commit also included a element. If the device reboots for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the confirmed commit was issued. The first paragraph from Section 8.4.1 mentions a corner case not covered i= n Section 8.3.5.2. Assuming the description of that corner case to be correct= , it would be useful if an Erratum was raised on Section 8.3.5.2 to also mention the corner case (see below). The second paragraph from Section 8.4.1 makes it clear a device reboot will= revert the server to the configuration before the start of the confirmed commit. So, on reboot, the device needs to determine whether a confirmed commit was ongoing and, if it was, ignore both (if supported) and= , and revert . So if there is any device that reboots whe= n its configuration changes, persistent confirmed commits WILL NOT survive th= e reboot and, if :writable-running is not supported, a standard should be used instead. For all other causes of session termination, a persistent confirmed commit WILL persist. THE PERSISTENCE OF LOCKS FOLLOWING SESSION TERMINATION Section 7.5 states: A lock MUST NOT be granted if any of the following conditions is true: * A lock is already held by any NETCONF session or another entity. * The target configuration is , it has already been modified, and these changes have not been committed or rolled back. * The target configuration is , and another NETCONF session has an ongoing confirmed commit (Section 8.4). The server MUST respond with either an element or an . A lock will be released by the system if the session holding the lock is terminated for any reason. In the netconf WG email thread "[Netconf] Is there a problem with confirmed= commits?", I summarised my understanding of the above as, "it seems the persist-id can be considered a de facto lock on both and that is released on a confirming , a timeout on the confirmed or a . Unlike other locks, this "lock" could be shared between clients by sharing the persist-id." However, on further examination it appears the lock on will not persist if the session terminates after a confirmed commit but before the confirming commit, as all the changes currently in will have been committed. So is the intention for to be not lockable for the same duration as during a confirmed commit? If so, it would be useful if an Erratum was raised on Section 7.5 to clarify (see below). However, since and operations with as the target cannot include the persist-id, there is no way for any sessio= n to update during a persistent confirmed commit following sessio= n termination. SOME OTHER CLARIFICATIONS SOUGHT Section 7.5 states: If the lock is already held, the element will be "lock-denied" and the element will include the of the lock owner. If the lock is held by a non- NETCONF entity, a of 0 (zero) is included. Note that any other entity performing a lock on even a partial piece of a target will prevent a NETCONF lock (which is global) from being obtained on that target. How should the error be reported if the lock is an implicit lock due to a persistent confirmed commit that has survived session termination? I have proposed a couple of alternatives as Errata below. Section 8.4.4.1 states: Cancels an ongoing confirmed commit. If the parameter is not given, the operation MUST be issued on the same session that issued the confirmed commit. With a persistent confirmed commit, does a issues on the same session that issued the confirmed commit require the parameter? FINAL THOUGHTS In Section 7.5 it states: When the lock is acquired, the server MUST prevent any changes to the locked resource other than those requested by this session. SNMP and CLI requests to modify the resource MUST fail with an appropriate error. It seems to me this is the same behaviour the server should exhibit with an= ongoing confirmed commit (except, maybe, wrt ). If that is the case, it would be useful if an Erratum was raised on Section 8.4.1 to clarify (see below). PROPOSED ERRATA Sections 7.5, 8.3.5.2 and 8.4.1 In Section 7.5: OLD: When the lock is acquired, the server MUST prevent any changes to the locked resource other than those requested by this session. SNMP and CLI requests to modify the resource MUST fail with an appropriate error. : A lock MUST NOT be granted if any of the following conditions is true: * A lock is already held by any NETCONF session or another entity. * The target configuration is , it has already been modified, and these changes have not been committed or rolled back. : If the lock is already held, the element will be "lock-denied" and the element will include the of the lock owner. If the lock is held by a non- NETCONF entity, a of 0 (zero) is included. Note that any other entity performing a lock on even a partial piece of a target will prevent a NETCONF lock (which is global) from being obtained on that target. In Section 8.3.5.2: OLD: When a client fails with outstanding changes to the candidate configuration, recovery can be difficult. To facilitate easy recovery, any outstanding changes are discarded when the lock is released, whether explicitly with the operation or implicitly from session failure. In Section 8.4.1: OLD: If the session issuing the confirmed commit is terminated for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the confirmed commit was issued, unless the confirmed commit also included a element. It should say: In Section 7.5: NEW: When the lock is acquired, the server MUST prevent any changes to the locked resource other than those requested by this session. SNMP and CLI requests to modify the resource MUST fail with an appropriate error. : A lock MUST NOT be granted if any of the following conditions is true: * A lock is already held by any NETCONF session or another entity. * The target configuration is , it has already been modified, and these changes have not been committed or rolled back, or another NETCONF session has an ongoing confirmed commit (Section 8.4). : EITHER If the lock is already held, or another NETCONF session has an ongoing confirmed commit (Section 8.4), the element will be "lock-denied" and the element will include the of the lock owner. If the lock is held by a non- NETCONF entity, a of 0 (zero) is included. Note that any other entity performing a lock on even a partial piece of a target will prevent a NETCONF lock (which is global) from being obtained on that target. OR If the lock is already held, the element will be "lock-denied" and the element will include the of the lock owner. If the lock is held by a non- NETCONF entity, or another NETCONF session has an ongoing confirmed commit (Section 8.4), a of 0 (zero) is included. Note that any other entity performing a lock on even a partial piece of a target will prevent a NETCONF lock (which is global) from being obtained on that target. In Section 8.3.5.2: NEW: Except in the case of a persistent confirmed commit (Section 8.4.5.1), when a client fails with outstanding changes to the candidate configuration, recovery can be difficult. To facilitate easy recovery, any outstanding changes are discarded when the lock is released, whether explicitly with the operation or implicitly from session failure. In Section 8.4.1: NEW: If the session issuing the confirmed commit is terminated for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the confirmed commit was issued, unless the confirmed commit also included a element. With an ongoing persistent confirmed commit, the server MUST prevent any changes to the candidate configuration datastore following session termination, and MUST prevent any changes to the running configuration datastore other than by a session using the parameter. SNMP and CLI requests to modify either resource MUST fail with an appropriate error. Jonathan -----Original Message----- From: Per Hedeland Sent: 21 February 2019 13:48 To: Martin Bjorklund Cc: mferguson@amsl.com; jonathan@hansfords.net; bclaise@cisco.com; rob.enns@gmail.com; iesg@ietf.org; netconf@ietf.org; rfc-editor@rfc-editor.org Subject: Re: [netconf] [Errata Held for Document Update] RFC6241 (3821) On 2019-02-21 14:22, Martin Bjorklund wrote: > Hi, > > Per Hedeland wrote: >> On 2019-02-20 01:44, Megan Ferguson wrote: >>> Jonathan and Benoit, >>> We have edited the "corrected text in this errata report as >>> suggested by Jonathan. >> >> I don't know if this change - i.e. the addition of the text "or >> " in two places - should affect the status of the >> document, but it seems to me that it can then no longer be considered >> a "clarification", since it proposes a change to the semantics >> specified in RFC 6241. As far as I can see, it is clear from 6241 >> that the presence of the parameter does not affect the >> persistence, only the presence of the parameter does that. > > Hmm, I missed this detail. > > It is clearly not correct to say that the affects > persistence. So s/or // in the 4th and 5th paragraphs. Hm, right, the remainder of the change to the 5th paragraph should be kept (I originally misread it as *only* adding "or " there too). > Do you see any other issues with the proposed text? No, it seems fine - a useful clarification. > (An editorial change - the 4th para should be split into two, just as > in the original text) +1 --Per > /martin > > > > > > >> >> Furthermore, I'm afraid I fail to find any motivation for this change >> in the quoted message from Jonathan (as far as I can see, this >> message was not sent to the mailing list). >> >> --Per Hedeland >> >>> We have left the status of this report as Held for Document >>> Update. >>> Please let us know if any further action is necessary on our part. >>> The report itself is viewable at >>> https://www.rfc-editor.org/errata/eid3821. >>> Old (as in Jonathans original report): >>> If the session issuing a sequence of one or more confirmed commits >>> is terminated for any reason before the confirm timeout expires, the >>> server MUST restore the configuration to its state before the >>> sequence of confirmed commits was issued, unless the last confirmed >>> commit also included a element. >>> If the device reboots for any reason before the confirm timeout >>> expires, the server MUST restore the configuration to its state >>> before the sequence of confirmed commits was issued. >>> New (as updated by Jonathans email - see the last line of both >>> paragraphs): >>> If the session issuing a sequence of one or more confirmed commits >>> is terminated for any reason before the confirm timeout expires, the >>> server MUST restore the configuration to its state before the >>> sequence of confirmed commits was issued, unless the last confirmed >>> commit also included a or element. >>> If the device reboots for any reason before the confirm timeout >>> expires, the server MUST restore the configuration to its state >>> before the sequence of confirmed commits was issued, unless the last >>> confirmed commit also included a or element. >>> Thank you. >>> RFC Editor/mf >>> >>>> Hi, >>>> I raised erratum 3821 to clarify the meaning of the term "confirmed= >>>> commit" for those not familiar with the use of the term within >>>> JUNOS. Both the original text and the erratum include text that states >>>> If the device reboots for any reason before the confirm timeout >>>> expires, the server MUST restore the configuration to its state before >>>> the sequence of confirmed commits was issued.. I have since >>>> discovered the description of the persist leaf on page 102 that >>>> includes the statement, A persistent confirmed commit is not aborted >>>> if the NETCONF session terminates. The only way to abort a persistent >>>> confirmed commit is to let the timer expire, or to use the >>>> operation. Consequently, the replacement text should >>>> read: >>>> 8.4.1. Description >>>> The :confirmed-commit:1.1 capability indicates that the server >>>> will support the operation, the , >>>> >>> timeout>, , and parameters for the >>>> operation, and differentiate between a to be confirmed >>>> operation (a confirmed commit) and a confirming >>>> operation. See Section 8.3 for further details on the >>>> operation. >>>> A confirmed operation MUST be reverted if a confirming >>>> commit is not issued within the timeout period (by default 600 >>>> seconds =3D 10 minutes). The confirming commit is a >>>> operation without the parameter and, if successful, >>>> cannot be reverted. The timeout period can be adjusted with the >>>> >>> timeout> parameter. If a follow-up confirmed operation is >>>> issued before the timer expires, the timer is reset to the new >>>> value >>>> (600 seconds by default). Both the confirming commit and a >>>> follow-up confirmed operation MAY introduce additional >>>> changes to the configuration. >>>> If the element is not given in the confirmed commit >>>> operation, any follow-up commit and the confirming commit MUST be >>>> issued on the same session that issued the confirmed commit. If the >>>> element is given in the confirmed operation, a >>>> follow-up commit and the confirming commit can be given on any >>>> session, and they MUST include a element with a value >>>> equal to the given value of the element. >>>> If the server also advertises the :startup capability, a >>> config> from running to startup is also necessary to save the >>>> changes to startup. If the session issuing a sequence of one or >>>> more confirmed commits is terminated for any reason before the >>>> confirm timeout expires, the server MUST restore the configuration >>>> to its state before the sequence of confirmed commits was issued, >>>> unless the last confirmed commit also included a or >>>> element. >>>> If the device reboots for any reason before the confirm timeout >>>> expires, the server MUST restore the configuration to its state >>>> before the sequence of confirmed commits was issued, unless the >>>> last confirmed commit also included a or element. >>>> If a confirming commit is not issued, the device will revert its >>>> configuration to the state prior to the issuance of the first in >>>> the current sequence of confirmed commits. To cancel the current >>>> sequence of confirmed commits and revert changes without waiting >>>> for the confirm timeout to expire, the client can explicitly >>>> restore the configuration to its state before the sequence of >>>> confirmed commits was issued, by using the operation. >>>> Jonathan Hansford >>> On Jan 13, 2014, at 7:53 AM, RFC Errata System >>> wrote: >>> >>>> The following errata report has been held for document update for >>>> RFC6241, "Network Configuration Protocol (NETCONF)". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=3D6241&eid=3D3821 >>>> >>>> -------------------------------------- >>>> Status: Held for Document Update >>>> Type: Editorial >>>> >>>> Reported by: Jonathan Hansford Date >>>> Reported: 2013-12-06 Held by: Benoit Claise (IESG) >>>> >>>> Section: 8.4.1 >>>> >>>> Original Text >>>> ------------- >>>> 8.4.1. Description >>>> >>>> The :confirmed-commit:1.1 capability indicates that the server will >>>> support the operation and the , >>>> , , and parameters for the >>>> operation. See Section 8.3 for further details on the >>>> operation. >>>> >>>> A confirmed operation MUST be reverted if a confirming >>>> commit is not issued within the timeout period (by default 600 >>>> seconds =3D 10 minutes). The confirming commit is a >>>> operation without the parameter. The timeout period >>>> can be adjusted with the parameter. If a >>>> follow-up confirmed operation is issued before the timer >>>> expires, the timer is reset to the new value (600 seconds by >>>> default). Both the confirming commit and a follow-up confirmed >>>> operation MAY introduce additional changes to the configuration. >>>> >>>> If the element is not given in the confirmed commit >>>> operation, any follow-up commit and the confirming commit MUST be >>>> issued on the same session that issued the confirmed commit. If >>>> the element is given in the confirmed operation, >>>> a follow-up commit and the confirming commit can be given on any >>>> session, and they MUST include a element with a value >>>> equal to the given value of the element. >>>> >>>> If the server also advertises the :startup capability, a >>>> from running to startup is also necessary to save the >>>> changes to startup. >>>> >>>> If the session issuing the confirmed commit is terminated for any >>>> reason before the confirm timeout expires, the server MUST restore >>>> the configuration to its state before the confirmed commit was >>>> issued, unless the confirmed commit also included a >>>> element. >>>> >>>> If the device reboots for any reason before the confirm timeout >>>> expires, the server MUST restore the configuration to its state >>>> before the confirmed commit was issued. >>>> >>>> If a confirming commit is not issued, the device will revert its >>>> configuration to the state prior to the issuance of the confirmed >>>> commit. To cancel a confirmed commit and revert changes without >>>> waiting for the confirm timeout to expire, the client can >>>> explicitly restore the configuration to its state before the >>>> confirmed commit was issued, by using the operation. >>>> >>>> Corrected Text >>>> -------------- >>>> 8.4.1. Description >>>> >>>> The :confirmed-commit:1.1 capability indicates that the server will >>>> support the operation, the , >>> timeout>, , and parameters for the >>>> operation, and differentiate between a to be confirmed >>>> operation (a confirmed commit) and a confirming >>>> operation. See Section 8.3 for further details on the >>>> operation. >>>> >>>> A confirmed operation MUST be reverted if a confirming >>>> commit is not issued within the timeout period (by default 600 >>>> seconds =3D 10 minutes). The confirming commit is a >>>> operation without the parameter and, if successful, >>>> cannot be reverted. The timeout period can be adjusted with the >>>> >>> timeout> parameter. If a follow-up confirmed operation is >>>> issued before the timer expires, the timer is reset to the new >>>> value >>>> (600 seconds by default). Both the confirming commit and a >>>> follow-up confirmed operation MAY introduce additional >>>> changes to the configuration. >>>> >>>> If the element is not given in the confirmed commit >>>> operation, any follow-up commit and the confirming commit MUST be >>>> issued on the same session that issued the confirmed commit. If the >>>> element is given in the confirmed operation, a >>>> follow-up commit and the confirming commit can be given on any >>>> session, and they MUST include a element with a value >>>> equal to the given value of the element. >>>> >>>> If the server also advertises the :startup capability, a >>> config> from running to startup is also necessary to save the >>>> changes to startup. If the session issuing a sequence of one or >>>> more confirmed commits is terminated for any reason before the >>>> confirm timeout expires, the server MUST restore the configuration >>>> to its state before the sequence of confirmed commits was issued, >>>> unless the last confirmed commit also included a element. >>>> >>>> If the device reboots for any reason before the confirm timeout >>>> expires, the server MUST restore the configuration to its state >>>> before the sequence of confirmed commits was issued. >>>> >>>> If a confirming commit is not issued, the device will revert its >>>> configuration to the state prior to the issuance of the first in >>>> the current sequence of confirmed commits. To cancel the current >>>> sequence of confirmed commits and revert changes without waiting >>>> for the confirm timeout to expire, the client can explicitly >>>> restore the configuration to its state before the sequence of >>>> confirmed commits was issued, by using the operation. >>>> >>>> Notes >>>> ----- >>>> This erratum seeks to clarify the meaning of the term "confirmed >>>> commit" for those not familiar with the use of the term within >>>> JUNOS. In particular, that the use of "confirmed" is not in the >>>> sense of the adjective (meaning "firmly established") but rather >>>> that the commit needs to be confirmed. It also emphasises that a >>>> "confirming commit" cannot be reverted. Finally it identifies that >>>> it is possible to have a sequence of "confirmed commits" prior to a >>>> "confirming commit" and that, should no "confirming commit" be >>>> received, the configuration will revert to the state prior to the >>>> first "confirmed commit" in the sequence. >>>> >>>> -------------------------------------- >>>> RFC6241 (draft-ietf-netconf-4741bis-10) >>>> -------------------------------------- >>>> Title : Network Configuration Protocol (NETCONF) >>>> Publication Date : June 2011 >>>> Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., >>>> A. Bierman, Ed. >>>> Category : PROPOSED STANDARD >>>> Source : Network Configuration >>>> Area : Operations and Management >>>> Stream : IETF >>>> Verifying Party : IESG >>>> >>> _______________________________________________ >>> 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 >> --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From nobody Fri Apr 5 03:14:37 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D821200F6 for ; Fri, 5 Apr 2019 03:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9AvY7a4zOfl for ; Fri, 5 Apr 2019 03:14:33 -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 ADFDF120086 for ; Fri, 5 Apr 2019 03:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13362; q=dns/txt; s=iport; t=1554459272; x=1555668872; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2FjqCseOiG12gKWwgo7m5qIGDNAVKrT+bxEuh/FX3ZY=; b=iWTWPGKEPflA1nY8DtZP59o48VmNJm+PjRLxy1JHtdcPpTVegcZ3NUt9 2Pla9pG9uLizYAESZcysHYJoxpnIZAlZHwKdsD+EeTRcfiiX6nlMhNqBQ IRor70Emx3ykcNtzhRjfsLQIGsEg+B1lU2w2ji/K0W7rh9Cpoh5SJ3jND 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAAAtKadc/4gNJK1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAIBAQEBCwGBDoECaIEDJwqEBJVHkk6Hcw4BAYRsAheFOyI?= =?us-ascii?q?3Bg0BAQMBAQkBAwJtKIVKAQEBBCMKTBACAQgRBAEBKwICAjAdCAIEDgUIE4M?= =?us-ascii?q?IgRFkrx2BL4o0gTABiXCBRBeBQD+BEYMSPoQugyCCVwONDoQqlD0JApN3IpR?= =?us-ascii?q?Vg1abdAIRFYEwNSKBVnAVgyeQTEExj0uBIAEB?= X-IronPort-AV: E=Sophos;i="5.60,312,1549929600"; d="scan'208,217";a="257197405" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Apr 2019 10:14:31 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x35AEVha024726 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 Apr 2019 10:14:31 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 5 Apr 2019 05:14:30 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Fri, 5 Apr 2019 05:14:30 -0500 From: "Rob Wilton (rwilton)" To: Kent Watsen CC: Martin Bjorklund , "netconf@ietf.org" Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpAB55r2AAFc4f4AA2LGYAAAA+NoAAOhJxAAAPAjogAAJwD2w//+/vgD//zkDAA== Date: Fri, 5 Apr 2019 10:14:30 +0000 Message-ID: <3ee1585d967540299a96169814e90a90@XCH-RCD-007.cisco.com> References: <01000169cb20ec39-94187bed-9312-4e19-a91f-466db763ee7e-000000@email.amazonses.com> <20190329205316.tcjzicuythyd4gvm@anna.jacobs.jacobs-university.de> <20190403.134424.1377386644961079970.mbj@tail-f.com> <01000169e929781e-b0dcb6b3-af41-4f9c-ba52-ac4afb7164d4-000000@email.amazonses.com> <01000169e95687c5-a1809710-e13d-4bc3-a5d3-5387af4112b7-000000@email.amazonses.com> In-Reply-To: <01000169e95687c5-a1809710-e13d-4bc3-a5d3-5387af4112b7-000000@email.amazonses.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.63.23.177] Content-Type: multipart/alternative; boundary="_000_3ee1585d967540299a96169814e90a90XCHRCD007ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 10:14:35 -0000 --_000_3ee1585d967540299a96169814e90a90XCHRCD007ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VudCwNCg0KQnV0IGNsaWVudHMgYXJlIGFsc28gYWxsb3dlZCB0byBleHBsaWNpdGx5IGNv bmZpZ3VyZSBwdWJsaWMgYW5kIHByaXZhdGUga2V5cyBpbiB0aGUgY29uZmlndXJhdGlvbj8gIChJ LmUuIHRoZSDigJx1cGxvYWQgb2Yga2V5c+KAnSBwcmV2aW91cyBkZXNjcmliZWQpLg0KDQpJZiBh IHByaXZhdGUga2V5IGlzIHVwbG9hZGVkIGluIHRoZSBjb25maWd1cmF0aW9uLCB3b3VsZCB0aGF0 IHByaXZhdGUga2V5IHN0aWxsIGJlIHJlYWRhYmxlIGJ5IHRoZSBjbGllbnQgaW4gPHJ1bm5pbmc+ LCA8aW50ZW5kZWQ+PyAgT3Igd291bGQgdGhhdCBhbHNvIGJlIGJsb2NrZWQgdmlhIE5BQ00gYnkg ZGVmYXVsdD8NCg0KSeKAmW0gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgb25jZSB0aGUga2V5cyBhcmUg Z2VuZXJhdGVkLCBob3cgdGhlc2UgdHdvIGNhc2VzIGRpZmZlcj8NCg0KMSkgdXBsb2FkIG9mIGtl eXMNCg0KMikgZ2VuZXJhdGlvbiBvZiBrZXlzIG9uIHRoZSBib3ggdGhhdCBiZWNvbWUgKHByb3Rl Y3RlZCkgY29uZmlndXJhdGlvbg0KDQpJZiBhIGNsaWVudCBkb2VzIG5vdCB3YW50IHRvIGV4cGxp Y2l0bHkgdXBsb2FkIGtleXMgdGhlbiBhcmUgdGhleSBmb3JjZWQgdG8gZXhwbGljaXRseSBkbyAo MikgdG8gZ2VuZXJhdGUga2V5cz8gIE9yIGNvdWxkIHRoZSBzeXN0ZW0gYXV0b21hdGljYWxseSBn ZW5lcmF0ZSBwZXJzaXN0ZW50IGtleXM/DQoNClRoYW5rcywNClJvYg0KDQoNCkZyb206IEtlbnQg V2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD4NClNlbnQ6IDA0IEFwcmlsIDIwMTkgMTg6MTMN ClRvOiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+DQpDYzogTWFydGlu IEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+OyBuZXRjb25mQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW25ldGNvbmZdIGlldGYgY3J5cHRvIHR5cGVzIC0gcGVybWFuZW50bHkgaGlkZGVuDQoNCg0K DQpbUlddDQpJIHRoaW5rIHRoYXQgaXMgYmFkIHByYWN0aWNlIGZvciBhIHNlcnZlciB0byBpbmpl Y3QgY29uZmlndXJhdGlvbiBpbnRvIDxydW5uaW5nPi4gIEl0IG1ha2VzIGl0IGFtYmlndW91cyBh cyB0byB3aGljaCBlbnRpdHkgcmVhbGx5IG93bnMgdGhlIGNvbmZpZ3VyYXRpb24uICAgSSB0aGlu ayB0aGF0IHdoYXQgaXMgaW4gPHJ1bm5pbmc+IHNob3VsZCBiZSBvd25lZCBieSB0aGUgY2xpZW50 LCBub3QgdGhlIHNlcnZlci4gIEnigJltIG5vdCBzYXlpbmcgdGhhdCBub2JvZHkgZG9lcyB0aGlz LCBidXQgSSBkb27igJl0IGJlbGlldmUgdGhhdCBpdCBpcyB0aGUgY2xlYW5lc3Qgc29sdXRpb24u DQoNCg0KV2UncmUgbm90IHRhbGtpbmcgYWJvdXQgdGhlIHNlcnZlciBkb2luZyBzb21ldGhpbmcg b24gaXRzIG93biBhY2NvcmQgaGVyZTsgdGhpcyB3b3VsZCBiZSBhIGRpcmVjdCByZXN1bHQgb2Yg YSBjbGllbnQgcmVxdWVzdC4gIEFic3RyYWN0bHksIHN1Y2ggY2FuIGJlIGNvbnNpZGVyZWQgY29u ZmlndXJhdGlvbiBhcyBsZWdpdGltYXRlIGFzIGNvbmZpZ3VyYXRpb24gcHJvdmlkZWQgYnkgYW55 IG90aGVyIG1lYW5zLg0KDQpLZW50IC8vIGNvbnRyaWJ1dG9yDQoNCg0KDQoNCg== --_000_3ee1585d967540299a96169814e90a90XCHRCD007ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQs IGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFt ZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBw dCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBL ZW50LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QnV0IGNsaWVudHMg YXJlIGFsc28gYWxsb3dlZCB0byBleHBsaWNpdGx5IGNvbmZpZ3VyZSBwdWJsaWMgYW5kIHByaXZh dGUga2V5cyBpbiB0aGUgY29uZmlndXJhdGlvbj8mbmJzcDsgKEkuZS4gdGhlIOKAnHVwbG9hZCBv ZiBrZXlz4oCdIHByZXZpb3VzDQogZGVzY3JpYmVkKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPklmIGEgcHJpdmF0ZSBrZXkgaXMgdXBsb2FkZWQgaW4gdGhlIGNvbmZp Z3VyYXRpb24sIHdvdWxkIHRoYXQgcHJpdmF0ZSBrZXkgc3RpbGwgYmUgcmVhZGFibGUgYnkgdGhl IGNsaWVudCBpbiAmbHQ7cnVubmluZyZndDssICZsdDtpbnRlbmRlZCZndDs/Jm5ic3A7DQogT3Ig d291bGQgdGhhdCBhbHNvIGJlIGJsb2NrZWQgdmlhIE5BQ00gYnkgZGVmYXVsdD88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPknigJltIHRyeWluZyB0byB1bmRlcnN0YW5k IG9uY2UgdGhlIGtleXMgYXJlIGdlbmVyYXRlZCwgaG93IHRoZXNlIHR3byBjYXNlcyBkaWZmZXI/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+MSkgdXBsb2Fk IG9mIGtleXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjIpIGdlbmVy YXRpb24gb2Yga2V5cyBvbiB0aGUgYm94IHRoYXQgYmVjb21lIChwcm90ZWN0ZWQpIGNvbmZpZ3Vy YXRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SWYgYSBjbGllbnQgZG9lcyBu b3Qgd2FudCB0byBleHBsaWNpdGx5IHVwbG9hZCBrZXlzIHRoZW4gYXJlIHRoZXkgZm9yY2VkIHRv IGV4cGxpY2l0bHkgZG8gKDIpIHRvIGdlbmVyYXRlIGtleXM/Jm5ic3A7IE9yIGNvdWxkIHRoZSBz eXN0ZW0NCiBhdXRvbWF0aWNhbGx5IGdlbmVyYXRlIHBlcnNpc3RlbnQga2V5cz88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyw8YnI+DQpSb2I8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBLZW50IFdh dHNlbiAmbHQ7a2VudCYjNDM7aWV0ZkB3YXRzZW4ubmV0Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+ IDA0IEFwcmlsIDIwMTkgMTg6MTM8YnI+DQo8Yj5Ubzo8L2I+IFJvYiBXaWx0b24gKHJ3aWx0b24p ICZsdDtyd2lsdG9uQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IE1hcnRpbiBCam9ya2x1 bmQgJmx0O21iakB0YWlsLWYuY29tJmd0OzsgbmV0Y29uZkBpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW25ldGNvbmZdIGlldGYgY3J5cHRvIHR5cGVzIC0gcGVybWFuZW50bHkgaGlk ZGVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltSV108L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkkgdGhpbmsgdGhhdCBpcyBiYWQgcHJhY3RpY2UgZm9yIGEgc2VydmVyIHRvIGluamVjdCBj b25maWd1cmF0aW9uIGludG8gJmx0O3J1bm5pbmcmZ3Q7LiZuYnNwOyBJdCBtYWtlcyBpdA0KIGFt YmlndW91cyBhcyB0byB3aGljaCBlbnRpdHkgcmVhbGx5IG93bnMgdGhlIGNvbmZpZ3VyYXRpb24u Jm5ic3A7ICZuYnNwO0kgdGhpbmsgdGhhdCB3aGF0IGlzIGluICZsdDtydW5uaW5nJmd0OyBzaG91 bGQgYmUgb3duZWQgYnkgdGhlIGNsaWVudCwgbm90IHRoZSBzZXJ2ZXIuJm5ic3A7IEnigJltIG5v dCBzYXlpbmcgdGhhdCBub2JvZHkgZG9lcyB0aGlzLCBidXQgSSBkb27igJl0IGJlbGlldmUgdGhh dCBpdCBpcyB0aGUgY2xlYW5lc3Qgc29sdXRpb24uPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSdyZSBub3QgdGFsa2luZyBhYm91dCB0aGUgc2VydmVyIGRv aW5nIHNvbWV0aGluZyBvbiBpdHMgb3duIGFjY29yZCBoZXJlOyB0aGlzIHdvdWxkIGJlIGEgZGly ZWN0IHJlc3VsdCBvZiBhIGNsaWVudCByZXF1ZXN0LiAmbmJzcDtBYnN0cmFjdGx5LCBzdWNoIGNh biBiZSBjb25zaWRlcmVkIGNvbmZpZ3VyYXRpb24gYXMgbGVnaXRpbWF0ZSBhcyBjb25maWd1cmF0 aW9uIHByb3ZpZGVkIGJ5IGFueSBvdGhlciBtZWFucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2VudCAvLyBjb250cmlidXRvcjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_3ee1585d967540299a96169814e90a90XCHRCD007ciscocom_-- From nobody Fri Apr 5 03:48:44 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D77D1203BD for ; Fri, 5 Apr 2019 03:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFb3E-il3fdW for ; Fri, 5 Apr 2019 03:48:40 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130135.outbound.protection.outlook.com [40.107.13.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78021200F5 for ; Fri, 5 Apr 2019 03:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ukeQeD1/uDHWjaUmTMPnJMYE9UtF7EcPYldCIXgPSlU=; b=We0nbr8bj7C3dFL/EbHZf1gDnWVo+VOADMk2ta+bOgkZKkYdiVKECQNWmhhFn5FmatFBHSly0iI0shbTK2x6VKKzy+90c07Q7GwdkKre2a1x0zOqJHW2ABcvaFKZ2CednjPMlR8+0QaaiVyk9M9aqP3y47llqlxmEcnHauFi0VQ= Received: from DB7PR07MB5562.eurprd07.prod.outlook.com (20.178.46.212) by DB7PR07MB4666.eurprd07.prod.outlook.com (52.135.141.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.12; Fri, 5 Apr 2019 10:48:36 +0000 Received: from DB7PR07MB5562.eurprd07.prod.outlook.com ([fe80::89bf:8194:3f8c:ff65]) by DB7PR07MB5562.eurprd07.prod.outlook.com ([fe80::89bf:8194:3f8c:ff65%5]) with mapi id 15.20.1771.007; Fri, 5 Apr 2019 10:48:36 +0000 From: tom petch To: "j.schoenwaelder@jacobs-university.de" , Martin Bjorklund CC: "netconf@ietf.org" Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AQHU650f9g7iAuRhP0CzDwIXBf2MNg== Date: Fri, 5 Apr 2019 10:48:36 +0000 Message-ID: <01dd01d4eb9c$b9a04160$4001a8c0@gateway.2wire.net> References: <20190403.134424.1377386644961079970.mbj@tail-f.com> <01000169e929781e-b0dcb6b3-af41-4f9c-ba52-ac4afb7164d4-000000@email.amazonses.com> <20190404164929.fsfga7s4izn7ucx5@anna.jacobs.jacobs-university.de> <20190404.194623.1178346313710501110.mbj@tail-f.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0022.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::34) To DB7PR07MB5562.eurprd07.prod.outlook.com (2603:10a6:10:7b::20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.215.234] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 20125991-4783-4e22-c7ee-08d6b9b44188 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DB7PR07MB4666; x-ms-traffictypediagnostic: DB7PR07MB4666: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0998671D02 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(136003)(346002)(376002)(396003)(189003)(199004)(13464003)(71200400001)(6512007)(8936002)(8676002)(386003)(2501003)(1556002)(2906002)(256004)(14444005)(71190400001)(316002)(25786009)(966005)(14496001)(6306002)(4720700003)(5660300002)(68736007)(110136005)(3846002)(6116002)(478600001)(7736002)(66066001)(86152003)(14454004)(62236002)(50226002)(44716002)(4326008)(93886005)(84392002)(106356001)(105586002)(99286004)(229853002)(6486002)(52116002)(97736004)(305945005)(9686003)(81816011)(76176011)(81156014)(26005)(446003)(44736005)(476003)(81686011)(81166006)(86362001)(486006)(102836004)(61296003)(53936002)(6506007)(6436002)(6246003)(186003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB4666; H:DB7PR07MB5562.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: EFblu5gSAAbLwD+1d4WsLl+o+nUuoNqAZkfT5iQW7Irq2SNk+kBaDKlAf8izKuR2rn3OxGXS2kT3fcH71XnpCnHkUqnqKyuzEt1B/CnDrIQRovcU3tBr4KN4UxYOqZfDhZXMVhYAXzI9WlSC/Zw9pA6Y5YAoIUW+lkvZdTYnyN/m1H8L0wCh0ne93G3L84svUgBPOG8A484jsbs8g0dnfkWO0xNBRjGJyuPJ0w+C291B1QANpY2gOZV6ci5SJKir9+NuWXhbNm0lV9VM6hhTDgLMr7qPYDveCKrDHh9LGWTcAMtCekSaDE6CjKQXDAX15diHImOLXtdSZ7UIYDZuJVya7NDgaJUjT0Gh8F/gFSXsFDtpVlwkx2H0IWEBYS6t3bUAVGdyCJP7bcfihD1ksgBXaRzRRYwBTQM2umw3Bxo= Content-Type: text/plain; charset="iso-8859-1" Content-ID: <131103EDA4C3C64D920DA9E8387C0CF2@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 20125991-4783-4e22-c7ee-08d6b9b44188 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2019 10:48:36.7120 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4666 Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 10:48:42 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Thursday, April 04, 2019 6:46 PM > Juergen Schoenwaelder wrote: > > On Thu, Apr 04, 2019 at 04:23:23PM +0000, Kent Watsen wrote: > > > > > > > > > We have always said no, but the reasoning is unclear. What are the > > > specific objections and is there anyway to alleviate them? > > > > > > > If editing of all configuration can be done with a single edit-data > > (or edit-config) operation, you simplify the world and you enable > > generic implementations. > > > > Once you build silos of data that can only be manipulated with special > > purpose operations, you say goodbye to the idea of generic client > > libraries. > > And you can no longer create all required config in one transaction; > you have to split it into sending multiple special-purpose actions. > Perhaps also in a certain order, that you have to figure out somehow, > since config might have refererences to other partf of the config > etc. > > You can no longer restore a backup with just a copy-config. Which is exactly what I have seen customers - think military - do. Security-related information - userid, passwords, second factor , ...- MUST NOT be backed up like everything else - special procedures - authentication, encryption - must be used. This is security - it matters. Tom Petch > So I don't think the reasoning is unclear at all. > > /martin > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Fri Apr 5 05:22:08 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2AD6120410 for ; Fri, 5 Apr 2019 05:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWnBSVtzqMVq for ; Fri, 5 Apr 2019 05:22:04 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 16D1212040F for ; Fri, 5 Apr 2019 05:22:03 -0700 (PDT) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 6A32A1AE0312; Fri, 5 Apr 2019 14:22:01 +0200 (CEST) Date: Fri, 05 Apr 2019 14:22:01 +0200 (CEST) Message-Id: <20190405.142201.707949273328784535.mbj@tail-f.com> To: ietfc@btconnect.com Cc: j.schoenwaelder@jacobs-university.de, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <01dd01d4eb9c$b9a04160$4001a8c0@gateway.2wire.net> References: <20190404164929.fsfga7s4izn7ucx5@anna.jacobs.jacobs-university.de> <20190404.194623.1178346313710501110.mbj@tail-f.com> <01dd01d4eb9c$b9a04160$4001a8c0@gateway.2wire.net> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 12:22:06 -0000 tom petch wrote: > > ----- Original Message ----- > From: "Martin Bjorklund" > To: > Cc: > Sent: Thursday, April 04, 2019 6:46 PM > > > Juergen Schoenwaelder wrote: > > > On Thu, Apr 04, 2019 at 04:23:23PM +0000, Kent Watsen wrote: > > > > > > > > > > > > We have always said no, but the reasoning is unclear. What are > the > > > > specific objections and is there anyway to alleviate them? > > > > > > > > > > If editing of all configuration can be done with a single edit-data > > > (or edit-config) operation, you simplify the world and you enable > > > generic implementations. > > > > > > Once you build silos of data that can only be manipulated with > special > > > purpose operations, you say goodbye to the idea of generic client > > > libraries. > > > > And you can no longer create all required config in one transaction; > > you have to split it into sending multiple special-purpose actions. > > Perhaps also in a certain order, that you have to figure out somehow, > > since config might have refererences to other partf of the config > > etc. > > > > You can no longer restore a backup with just a copy-config. > > Which is exactly what I have seen customers - think military - do. > > Security-related information - userid, passwords, second factor , ...- > MUST NOT be backed up like everything else - special procedures - > authentication, encryption - must be used. Agreed! BUT, then it should not be modelled as configuration, imo. And the current model already handles this case with "hidden" keys. /martin > > This is security - it matters. > > Tom Petch > > > So I don't think the reasoning is unclear at all. > > > > /martin > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > From nobody Fri Apr 5 07:54:01 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C43120482 for ; Fri, 5 Apr 2019 07:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikl6HYOOAe4H for ; Fri, 5 Apr 2019 07:53:57 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40056.outbound.protection.outlook.com [40.107.4.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4DE12046B for ; Fri, 5 Apr 2019 07:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=poxMd+DKzEfZx0cPP2u+Cvfp4FksJLKsAhhM33gChH8=; b=P8WeQBYq6AvzfAPX4Fzhbbu04Xs013BLVgPgHNBFSQkW1n0etAIWzf32qREm0gIzt3LldymyiueRpNFHDc1Rf8JCzyssz3Q25ZICCbnGDokzC8Fg9hT1k7Nxbt6+pgTeLF7cnDQzXaZpUXsNL9gOczJpA6mpYnlwZGd9DGtdZt8= Received: from HE1PR0701MB2508.eurprd07.prod.outlook.com (10.168.129.10) by HE1PR0701MB2092.eurprd07.prod.outlook.com (10.168.30.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.8; Fri, 5 Apr 2019 14:53:48 +0000 Received: from HE1PR0701MB2508.eurprd07.prod.outlook.com ([fe80::20ca:9699:6d54:1543]) by HE1PR0701MB2508.eurprd07.prod.outlook.com ([fe80::20ca:9699:6d54:1543%7]) with mapi id 15.20.1771.006; Fri, 5 Apr 2019 14:53:48 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Martin Bjorklund , "ietfc@btconnect.com" CC: "netconf@ietf.org" Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AQHU679f1WNMIVsqeEG2PDBEdPRHrw== Date: Fri, 5 Apr 2019 14:53:47 +0000 Message-ID: <413d5725-9c27-e50b-2622-1b0e2f35cdb1@ericsson.com> References: <20190404164929.fsfga7s4izn7ucx5@anna.jacobs.jacobs-university.de> <20190404.194623.1178346313710501110.mbj@tail-f.com> <01dd01d4eb9c$b9a04160$4001a8c0@gateway.2wire.net> <20190405.142201.707949273328784535.mbj@tail-f.com> In-Reply-To: <20190405.142201.707949273328784535.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [89.135.192.225] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 x-clientproxiedby: AM6P194CA0053.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:84::30) To HE1PR0701MB2508.eurprd07.prod.outlook.com (2603:10a6:3:72::10) authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 600836b4-4a2e-4a3a-8dd0-08d6b9d68219 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:HE1PR0701MB2092; x-ms-traffictypediagnostic: HE1PR0701MB2092: x-microsoft-antispam-prvs: x-forefront-prvs: 0998671D02 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(396003)(39860400002)(376002)(346002)(13464003)(189003)(199004)(386003)(6506007)(26005)(478600001)(71200400001)(71190400001)(5660300002)(229853002)(256004)(93886005)(14444005)(52116002)(6306002)(2501003)(53936002)(54896002)(966005)(8936002)(4326008)(36756003)(68736007)(64126003)(81166006)(486006)(31696002)(86362001)(106356001)(8676002)(102836004)(85202003)(105586002)(81156014)(476003)(6486002)(25786009)(606006)(2616005)(6246003)(99286004)(97736004)(11346002)(2906002)(76176011)(7736002)(31686004)(446003)(6436002)(65806001)(65956001)(66066001)(186003)(65826007)(85182001)(3846002)(6116002)(99936001)(6512007)(110136005)(14454004)(236005)(316002)(58126008); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2092; H:HE1PR0701MB2508.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4Subje+lgNNuRSnU3U6PkVk1GJA/lQZEHyhkgJ2wm0Xvgq44Vl0KcWf4zTblXu1zUTFQWrDbDuy+8Xw5ryK5qr3XmMYt0J8bqZX6AX/TQgSELgdpFAPY8YCWdGkzBtcP+QJzAUNifILh7PEbNIeRFtB7DVFpogzOzGZq+Sc0udjwxuZ976YVEq2bfGJUk6/BauK8KTfIwVej3OMVJfmdjo+rO9O+BJ8WaBh0ncl8X1TT3FJLAbxriJk2xSe/ru9vvUrvXgiAJBdherxX2tiZf8zVIa4zT0dOQHwlNaOLL3WOMHc5gKH9TGO0gTsf89aZAE5q0CJDo7qgufTjlZNeY36H+35WyN7MJMd7Wynw8dGYO2c6gO6DBOTTiwz6rYinJso5isUkdSVOO3J7otSk61lk9LNYBeCwtJw00UXmBEs= Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030100080606040406020605" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 600836b4-4a2e-4a3a-8dd0-08d6b9d68219 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2019 14:53:48.0179 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2092 Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 14:54:00 -0000 --------------ms030100080606040406020605 Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable

Hello,

While using actions to configure data nodes instead of edit-config clearly has problems, in some cases it is needed. Ericsson does use it, but we try to be VERY(!) restrictive when it is allowed. IMHO=C2=A0 security best practice could be one case. Al= so we should not pretend this is the only case where the system itself manipulates configuration:

  • security keys
  • HW insertion/removal (interface type)
  • onboard automation may do it
  • server capabilities that need additional configuration (must be in running as it is reference from other parts of the configuration)

I also hope we will arrive at a solution that works for non-NMDA systems too. AFAIK=C2=A0 we never stated in any RFC that NMDA is a requirement for the solution. (Except for NMDA itself :-)=C2=A0 )

regards Balazs

On 2019. 04. 05. 14:22, Martin Bjorklund wrote:
tom petch <ietfc@btconnect.=
com> wrote:

----- Original Message -----
From: "Martin Bjorklund" <mbj@tail-f.com>
To: <j.schoenwaelder@jacobs-university.de>
Cc: &=
lt;netconf@ietf.org>
Sent: Thursday, April 04, 2019 6:46 PM


Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On Thu, Apr 04, 2019 a=
t 04:23:23PM +0000, Kent Watsen wrote:


We have always said no, but the reasoning is unclear.  What are

the

specific objections =
and is there anyway to alleviate them?


If editing of all configuration can be done with a single edit-data
(or edit-config) operation, you simplify the world and you enable
generic implementations.

Once you build silos of data that can only be manipulated with

special

purpose operations, yo=
u say goodbye to the idea of generic client
libraries.

And you can no longer create all required config in one transaction;
you have to split it into sending multiple special-purpose actions.
Perhaps also in a certain order, that you have to figure out somehow,
since config might have refererences to other partf of the config
etc.

You can no longer restore a backup with just a copy-config.

Which is exactly what I have seen customers - think military - do.

Security-related information - userid, passwords, second factor , ...-
MUST NOT be backed up like everything else - special procedures -
authentication, encryption -  must be used.

Agreed!  BUT, then it should not be modelled as configuration, imo.

And the current model already handles this case with "hidden" keys.




/martin


This is security - it matters.

Tom Petch


So I don't think the rea=
soning is unclear at all.

/martin

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



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


--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20
--------------ms030100080606040406020605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20 wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4 ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9 ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9 YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF 1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6 EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0 NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA 7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+ MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0 LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9 2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa 49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDQwNTE0NTM0Mlow LwYJKoZIhvcNAQkEMSIEIMOZgZRU+ms84NobPc+L7lcGay7iKx25OF1XhiSjeqxwMGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBABYwer54o7WXPUaBFM30gI7gCvl+vRzSqmVZ8RUXq3Mymgr6 oHImQ3xmVCvtjFfeME3C8w+FCTjrTScRmK6+os6ASnXnXPdzSKnqkaO8gxRQjHM9IOt3ZEl7 wanuDjHYMxz3Kbtt17hiYhACr7dC/NAYXGMU5An0lZsbLNNaopbBtwVG7AQFy4IIjySOzCc8 +P8AKLImK1t/4kH5JybPZ/VsMDyxcJ+CVaIpr67YPYPZnLgFQc7IwPO5Hs5mEcPawYfnXRxa Q0Kvl/LHuuWS6bHtGusmxWPVWVS+0d9uYbInbj10IhXRk9raspFokAK/QaS+OlYofs8r5kBk GBXihR8AAAAAAAA= --------------ms030100080606040406020605-- From nobody Fri Apr 5 12:38:29 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8FB12011B; Fri, 5 Apr 2019 12:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwlTOZ2_mFDR; Fri, 5 Apr 2019 12:38:23 -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 2F2831200E3; Fri, 5 Apr 2019 12:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=155319; q=dns/txt; s=iport; t=1554493103; x=1555702703; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Oc1u2bhTntlMPEdnWqOpbiw8pxmhcKy1SFpKOL6GCeY=; b=dqiikoA751xooYFWWdxWt9oljTg4V/gRe8JCIYe1cEQlpQ+kZ+/jnzm8 AnPMYkVR04ExH+kM8AVOq8M25xxPA0QoUlp1uEWkgMlsGSa/5+6wRlgiH AmGjl3ih2jt862eYR3wC7NAW97QFlA8S+7xPNWK5LvXEOKOnLcZ3y3AyC o=; X-Files: image002.jpg : 85944 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAAerqdc/5hdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDlgqaIEDJwqEBIgcjSyYRoF7AgkBAgEBJYQ?= =?us-ascii?q?BRgIXhTwiNAkNAQEDAQEJAQMCbRwMhUoBAQEDAQUeAggBSQIFCwIBCA4HCAE?= =?us-ascii?q?BAQUFDgoCAgIFEAEODCUCBA4EAQYCBg2DCIFtCA+wJIEviiAPgTABi0YXgUA?= =?us-ascii?q?/gRGDEj6CVgsBAQKBOYMwglcDijUgKgYFggSEKoIJjAYDRIUFYgkChwUBe4t?= =?us-ascii?q?2IoIFhhYTjCeKQocvjVkCERWBKQcfOIFWcBU7gmwJgg0XgQEBBwEGgjyEWYV?= =?us-ascii?q?6QTGOIIEtgSABAQ?= X-IronPort-AV: E=Sophos;i="5.60,313,1549929600"; d="jpg'145?scan'145,208,217,145";a="540456016" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Apr 2019 19:38:21 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x35JcKSI024961 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 Apr 2019 19:38:21 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 5 Apr 2019 15:38:19 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Fri, 5 Apr 2019 15:38:19 -0400 From: "Eric Voit (evoit)" To: Wesley Eddy CC: "draft-ietf-netconf-subscribed-notifications.all@ietf.org" , "ietf@ietf.org" , "netconf@ietf.org" , "tsv-art@ietf.org" Thread-Topic: Tsvart last call review of draft-ietf-netconf-subscribed-notifications-23 Thread-Index: AQHU6XYMzdgYeozy5EiZCq3wEitfJqYtqllg Date: Fri, 5 Apr 2019 19:38:19 +0000 Message-ID: <8bb9e0b1b7f342acb2c77146b27bf479@XCH-RTP-013.cisco.com> References: <155422462845.6404.8212061582804708160@ietfa.amsl.com> In-Reply-To: <155422462845.6404.8212061582804708160@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: multipart/related; boundary="_004_8bb9e0b1b7f342acb2c77146b27bf479XCHRTP013ciscocom_"; type="multipart/alternative" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.154, xch-rtp-014.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [netconf] Tsvart last call review of draft-ietf-netconf-subscribed-notifications-23 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 19:38:27 -0000 --_004_8bb9e0b1b7f342acb2c77146b27bf479XCHRTP013ciscocom_ Content-Type: multipart/alternative; boundary="_000_8bb9e0b1b7f342acb2c77146b27bf479XCHRTP013ciscocom_" --_000_8bb9e0b1b7f342acb2c77146b27bf479XCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIHZlcnkgbXVjaCBXZXNsZXkgZm9yIHRoZSByZXZpZXdzISAgIENvbW1lbnRzIGluLWxp bmUuLi4NCg0KDQoNCj4gRnJvbTogV2VzbGV5IEVkZHksIEFwcmlsIDIsIDIwMTkgMTowNCBQTQ0K DQo+DQoNCj4gUmV2aWV3ZXI6IFdlc2xleSBFZGR5DQoNCj4gUmV2aWV3IHJlc3VsdDogQWxtb3N0 IFJlYWR5DQoNCj4NCg0KPiBUaGlzIGRvY3VtZW50IGhhcyBiZWVuIHJldmlld2VkIGFzIHBhcnQg b2YgdGhlIHRyYW5zcG9ydCBhcmVhIHJldmlldyB0ZWFtJ3MNCg0KPiBvbmdvaW5nIGVmZm9ydCB0 byByZXZpZXcga2V5IElFVEYgZG9jdW1lbnRzLiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4N Cg0KPiBwcmltYXJpbHkgZm9yIHRoZSB0cmFuc3BvcnQgYXJlYSBkaXJlY3RvcnMsIGJ1dCBhcmUg Y29waWVkIHRvIHRoZSBkb2N1bWVudCdzDQoNCj4gYXV0aG9ycyBhbmQgV0cgdG8gYWxsb3cgdGhl bSB0byBhZGRyZXNzIGFueSBpc3N1ZXMgcmFpc2VkIGFuZCBhbHNvIHRvIHRoZSBJRVRGDQoNCj4g ZGlzY3Vzc2lvbiBsaXN0IGZvciBpbmZvcm1hdGlvbi4NCg0KPg0KDQo+IFdoZW4gZG9uZSBhdCB0 aGUgdGltZSBvZiBJRVRGIExhc3QgQ2FsbCwgdGhlIGF1dGhvcnMgc2hvdWxkIGNvbnNpZGVyIHRo aXMNCg0KPiByZXZpZXcgYXMgcGFydCBvZiB0aGUgbGFzdC1jYWxsIGNvbW1lbnRzIHRoZXkgcmVj ZWl2ZS4gUGxlYXNlIGFsd2F5cyBDQyB0c3YtDQoNCj4gYXJ0QGlldGYub3JnIGlmIHlvdSByZXBs eSB0byBvciBmb3J3YXJkIHRoaXMgcmV2aWV3Lg0KDQo+DQoNCj4gVGhlIGRvY3VtZW50IGluY2x1 ZGVzIGEgd2F5IGludGVuZGVkIHRvIGFzayBmb3IgYSBwYXJ0aWN1bGFyIERpZmZTZXJ2IENvZGUN Cg0KPiBQb2ludCAoRFNDUCkgdmFsdWUgdG8gYmUgdXNlZCBieSBhIHB1Ymxpc2hlci4gIFRoaXMg aXMgbWlzc2luZyBzb21lIGNvbnRleHQuDQoNCj4gV2h5IHdvdWxkIGEgc3Vic2NyaWJlciBkbyB0 aGlzPw0KDQoNCg0KU29tZSBvZiB0aGUgUW9TIGNvbnRleHQgaXMgcHJvdmlkZWQgZnJvbSBSRkMt NzkyMy4gIFRoaXMgUkZDIHByb3ZpZGVzIHJlcXVpcmVtZW50cy9jb250ZXh0IGZvciBhIFlBTkcg YmFzZWQgc3Vic2NyaXB0aW9uIHNlcnZpY2UuDQoNCg0KDQpBcyBhIHF1aWNrIHN1bW1hcnkgb2Yg dGhpcyBSRkMsIHRoZSBzdWJzY3JpcHRpb24gc2VydmljZSBmaXJzdCBhbmQgZm9yZW1vc3QgZXN0 YWJsaXNoZXMgYSBuZXcgbWVjaGFuaXNtIGZvciByb3V0ZXIgaW50ZWdyYXRpb24gd2l0aCBuZXR3 b3JrIENvbnRyb2xsZXJzIGFuZCBOZXR3b3JrIE1hbmFnZW1lbnQgU3lzdGVtcyAoTk1TKS4gICBC ZXR3ZWVuIHRoZXNlIGRldmljZXMsIGEgY29tbW9uIG5ldHdvcmsgb3BlcmF0aW9ucyBjb250ZXh0 IG1pZ2h0IGJlIGF2YWlsYWJsZS4gIEluIGZhY3QsIHRoZSBzYW1lIG9wZXJhdGlvbmFsIG9yZ2Fu aXphdGlvbnMgbWlnaHQgb3BlcmF0ZSBhbGwgdGhlc2UgZGV2aWNlcy4gIEJhc2VkIG9uIHRoaXMs IHRoZXJlIHNob3VsZCBiZSBzb21lIHNoYXJlZCBrbm93bGVkZ2Ugb2YgdGhlIHVuZGVybHlpbmcg UW9TIGNvbnRleHQuDQoNCg0KDQpJbiBjb21tdW5pY2F0aW5nIGJldHdlZW4gQ29udHJvbGxlcnMv Tk1TIGFuZCBhIG5ldHdvcmsgZWxlbWVudCwgc29tZSBzdWJzY3JpcHRpb25zIG1pZ2h0IGNhcnJ5 IGluZm9ybWF0aW9uIHdpdGggYSBoaWdoZXIgYnVzaW5lc3MgcHJlY2VkZW5jZSB0aGFuIG90aGVy cy4gIEZvciBleGFtcGxlLCBwcm92aWRpbmcgaW5mb3JtYXRpb24gYWJvdXQgYSBsaW5lIGNhcmQg b3V0YWdlIHNob3VsZCB0YWtlIHByZWNlZGVuY2Ugb3ZlciBhIHNldCBvZiBjb3VudGVycy4gICBU aGVzZSBwcmVjZWRlbmNlIG5lZWRzIG11c3QgYmUgcmVzcGVjdGVkIGF0IGEgdmFyaWV0eSBvZiBj b25nZXN0aW9uIHBvaW50cy4gIFRoZXNlIGluY2x1ZGUgZHVyaW5nIHRoZSBkZXF1ZXVpbmcgb2Yg aW5mb3JtYXRpb24gZnJvbSB0aGUgcHVibGlzaGVyLCBhcyB3ZWxsIGFzIGR1cmluZyBuZXR3b3Jr IHRyYW5zaXQuDQoNCg0KDQpEcml2ZW4gYnkgdGhpcywgUkZDLTc5MjMgU2VjdGlvbiA0LjIuNi44 IHByb3ZpZGVzIGd1aWRhbmNlIG9uIHNvbWUgc3Vic2NyaXB0aW9uIFFvUyBwYXJhbWV0ZXJzOg0K DQogIOKAnFRoZSBTdWJzY3JpcHRpb24gU2VydmljZSBTSE9VTEQgc3VwcG9ydCB0aGUgcmVsYXRp dmUgcHJpb3JpdGl6YXRpb24NCg0KICAgb2Ygc3Vic2NyaXB0aW9ucyBzbyB0aGF0IHRoZSBkZXF1 ZXVpbmcgYW5kIGRpc2NhcmRpbmcgb2YgcHVzaCB1cGRhdGVzDQoNCiAgIGNhbiBjb25zaWRlciB0 aGlzIGlmIHRoZXJlIGlzIGluc3VmZmljaWVudCBiYW5kd2lkdGggYmV0d2VlbiB0aGUNCg0KICAg UHVibGlzaGVyIGFuZCB0aGUgUmVjZWl2ZXIu4oCdDQoNCg0KDQpUaGUgbmVlZCBmb3IgRFNDUCBp cyB3ZWxsIGtub3duLCBhbmQgaGFzIGFsc28gYmVlbiByZWNvZ25pemVkIGJ5IHRoZSBPcGVuQ29u ZmlnIFRlbGVtZXRyeSBlZmZvcnQuICAgQW5kIGFzIGEgcmVzdWx0LCB0aGUgRFNDUCBvYmplY3Qg ZnJvbSB0aGlzIGRyYWZ0IHdhcyBhbHNvIHBpY2tlZCB1cCBieSB0aGUgT3BlbkNvbmZpZy10ZWxl bWV0cnkueWFuZyBtb2RlbC4gICBGb3IgbW9yZSBpbmZvIG9uIHRoYXQsIHNlZSBsaW5lIDU4MyBv ZjoNCg0KaHR0cHM6Ly9naXRodWIuY29tL29wZW5jb25maWcvcHVibGljL2Jsb2IvbWFzdGVyL3Jl bGVhc2UvbW9kZWxzL3RlbGVtZXRyeS9vcGVuY29uZmlnLXRlbGVtZXRyeS55YW5nDQoNCg0KDQo+ IElzIGl0IGFza2luZyBmb3IgRFNDUCB2YWx1ZXMgdGhhdCBpdCBhc3N1bWVzDQoNCj4gYXJlIGhv bm9yZWQgYW5kIG5vdCBibGVhY2hlZCBvciBhbHRlcmVkIGFsbCB0aGUgd2F5IGJldHdlZW4gaXQg YW5kIHRoZQ0KDQo+IHB1Ymxpc2hlcj8gIEFyZSB0aGVyZSBjb25kaXRpb25zIG5vcm1hbCBmb3Ig dGhlIHVzZSBvZiB0aGlzIHByb3RvY29sIHdoZXJlIHRoYXQNCg0KPiBhc3N1bXB0aW9uIHVzdWFs bHkgaG9sZHM/DQoNCg0KDQpUaGUgdGVsZW1ldHJ5IGltcGxlbWVudGF0aW9ucyBzZWVuIHNvIGZh ciBhcmUgd2l0aGluIHRoZSBkb21haW4vcHJvdmVuYW5jZSBvZiBhIHNpbmdsZSBvcGVyYXRvci4g IEFzIGEgcmVzdWx0LCB0aGVyZSBoYXZlbid0IGJlZW4gcmVxdWlyZW1lbnRzIHdoaWNoIGhhdmUg ZHJpdmVuIGEgbWFwcGluZyBvciBuZWdvdGlhdGlvbiBiZXR3ZWVuIGEgcmVxdWVzdGVkIHF1YWxp dHkgb2Ygc2VydmljZSwgYW5kIG9uZSBkZWxpdmVyZWQgYnkgdGhlIHN1YnNjcmlwdGlvbiBzZXJ2 aWNlLiAgKFdlIHRhbGtlZCBhYm91dCB0aGlzIGVhcmx5IG9uLCBidXQgcGVvcGxlIHRob3VnaHQg dGhhdCB3b3VsZCBiZSB1bm5lY2Vzc2FyeSBjb21wbGV4aXR5LiAgUGx1cyB3ZSBjb3VsZCBhbHdh eXMgbGF5ZXIgc3VjaCBhIGNhcGFiaWxpdHkgaW4gZHVyaW5nIHRoZSBmdXR1cmUgaWYgbmVjZXNz YXJ5LikNCg0KDQoNCj4gQnkgYXNraW5nIGZvciBhIHBhcnRpY3VsYXIgRFNDUCB0byBiZSBzZXQs IHRoZSBzdWJzY3JpYmVyIGlzIG1heWJlIGF0dGVtcHRpbmcgdG8NCg0KPiBvcHRpbWl6ZSB0aGUg YmVoYXZpb3IgZHVyaW5nIHNvbWUgdHlwZSBvZiBvdmVybG9hZCwgd2hlcmUgdGhleSByZWFsbHkg d2FudA0KDQo+IHNvbWUgbm90aWZpY2F0aW9ucyBxdWlja2x5LCBidXQgb3RoZXJzIGFyZW4ndCBh cyBpbXBvcnRhbnQsIGFuZCBtYXkgYmUgZmluZSB0bw0KDQo+IGRyb3AgYW5kIGhhdmUgcmV0cmFu c21pdHRlZCBieSBUQ1AsIGV0Yy4gIFRoaXMgYWxsIHNlZW1zIHRvIGJlIGltcGxpY2l0IHRob3Vn aCwNCg0KPiB3aXRoIG5vIGRlZXAgZGlzY3Vzc2lvbiBvZiB3aGF0IHRoZSBwcm90b2NvbCBpcyBh dHRlbXB0aW5nIHRvIGVuYWJsZSB3aXRoIHRoaXMNCg0KPiBvcHRpb24gb3IgaG93IGl0IHdvdWxk IGJlIHByb2R1Y3RpdmVseSB1c2VkLg0KDQoNCg0KV2UgaGFkIHNldmVyYWwgZWFybHkgZGlzY3Vz c2lvbnMgb24gd2hldGhlciB0aGlzIGRyYWZ0IHNob3VsZCB0YWxrIGFib3V0IHZhcmlvdXMgYnVz aW5lc3Mgb2JqZWN0aXZlcyBvZiBwcm90b2NvbCBzZWxlY3Rpb25zLiAgQW5kIGluIG1hbnkgY2Fz ZXMgdGhpcyBpcyBkb25lLiAgQnV0IGFzIHRoZSBkcmFmdCBkb2N1bWVudHMgd2FzIGFscmVhZHkg cXVpdGUgbGFyZ2UsIHdlIGhhdmUgYmVlbiBob3BpbmcgdGhhdCBvdGhlciBkb2N1bWVudHMgY2Fu IHByb3ZpZGUgaGVscC9jb250ZW50IG9uIFFvUyBhc3BlY3RzLCByYXRoZXIgdGhhbiBnb2luZyBp bnRvIHRoZW0gZGVlcGx5IGhlcmUuICBBbmQgdGhlcmUgYXJlIGRvY3VtZW50cyB3aGljaCBkbyBo ZWxwLiAgIEZvciBleGFtcGxlIGltcGxlbWVudGVycyBkbyBoYXZlIGRvY3VtZW50cyBsaWtlIFJG Qy03OTIzIGFuZCBodHRwOi8vd3d3Lm9wZW5jb25maWcubmV0L3Byb2plY3RzL3RlbGVtZXRyeS8u ICBUaGVyZSBhcmUgYWxzbyB2ZW5kb3IgZG9jdW1lbnRzIHdoaWNoIGNhbiBwcm92aWRlIGd1aWRh bmNlLg0KDQoNCg0KDQoNCj4gSXQgc2VlbXMgdG8gYmUgY29uc2lkZXJlZCBmYXRhbCBpZiBhIHB1 Ymxpc2hlciBjYW4ndCB3cml0ZSBhIHJlcXVlc3RlZCBEU0NQDQoNCj4gdmFsdWUuICBUaGUgcmVx dWVzdHMgZmFpbCB3aXRoICJkc2NwLXVuYXZhaWxhYmxlIi4gIFRoaXMgc2VlbXMgdG9vIGRyYXN0 aWMsIHNpbmNlDQoNCj4gdGhlIERTQ1AgaXMgYW55d2F5cyBhZHZpc29yeSB0byBub2RlcyBvbiB0 aGUgcGF0aCwgYW5kIG1heSBiZSBhbHRlcmVkDQoNCj4gYW55d2F5cy4gIEknbSBub3Qgc3VyZSB3 aHkgdGhpcyB3b3VsZCBiZSBjb25zaWRlcmVkIGEgZmF0YWwgaXNzdWUgdG8gdGhlDQoNCj4gc3Vi c2NyaXB0aW9uLg0KDQoNCg0KQSBkZXNpZ24gZ29hbCBpcyB0aGF0IGEgcHVibGlzaGVyIGV4YWN0 bHkgbWVldHMgdGhlIHRlcm1zIHJlcXVlc3RlZCBieSB0aGUgc3Vic2NyaXB0aW9uLiAgIElmIGEg cHVibGlzaGVyIGNhbm5vdCBtZWV0IHRoZSByZXF1ZXN0LCB0aGUgc3Vic2NyaXB0aW9uIGlzIG5v dCBlc3RhYmxpc2hlZC4gICBTbyBpZiBhIERTQ1AgaXMgbm90IGF2YWlsYWJsZSwgd2UgaGF2ZSB0 aGUgc3Vic2NyaWJlciBhc2sgZm9yIG9uZSB0aGF0IGlzIGF2YWlsYWJsZS4NCg0KDQoNCkRTQ1Ag bm90IGF2YWlsYWJsZSBpcyBqdXN0IG9uZSBvZiBtYW55IHJlYXNvbnMgd2h5IGEgc3Vic2NyaXB0 aW9uIG1heSBiZSByZWplY3RlZC4gIEFuZCBlYWNoIHJlamVjdGVkIHN1YnNjcmlwdGlvbiByZXF1 ZXN0IGNhbiBlZmZlY3RpdmVseSBiZSB0cmVhdGVkIGFzIGEgbmVnb3RpYXRpb24uICBTbyBsb29r IGF0IGVycm9yIG1lc3NhZ2VzIGFzIGEgd2F5IHRvIHByb3ZpZGUgZmVlZGJhY2sgZm9yIGEgYmV0 dGVyIHN1YnNlcXVlbnQgc3Vic2NyaXB0aW9uIHJlcXVlc3QuDQoNCg0KDQo+IFRoZSBmZWF0dXJl IGRlc2NyaXB0aW9uIGZvciAiZHNjcCIgbWlzY2hhcmFjdGVyaXplcyBpdCBhcyBhIHB1cmUgcHJp b3JpdHkNCg0KPiBtZWNoYW5pc20sIHJhdGhlciB0aGFuIGEgbW9yZSBnZW5lcmFsIGluZGljYXRp b24gb2YgY2xhc3Mgb2Ygc2VydmljZSB0cmVhdG1lbnQ6DQoNCj4gICJUaGlzIGZlYXR1cmUgaW5k aWNhdGVzIGEgcHVibGlzaGVyIHN1cHBvcnRzIHRoZSBwbGFjZW1lbnQgb2Ygc3VnZ2VzdGVkDQoN Cj4gcHJpb3JpdGl6YXRpb24gbGV2ZWxzIGZvciBuZXR3b3JrIHRyYW5zcG9ydCB3aXRoaW4gbm90 aWZpY2F0aW9uIG1lc3NhZ2VzLiIgIEl0DQoNCj4gY291bGQgYmUgbW9yZSBjb3JyZWN0IHRvIHNh eSBzb21ldGhpbmcgbGlrZSAiVGhpcyBmZWF0dXJlIGluZGljYXRlcyB0aGF0IGENCg0KPiBwdWJs aXNoZXIgc3VwcG9ydHMgdGhlIGFiaWxpdHkgdG8gc2V0IHRoZSBEaWZmU2VydiBDb2RlIFBvaW50 IChEU0NQKSB2YWx1ZSBpbg0KDQo+IG91dGdvaW5nIHBhY2tldHMuIg0KDQoNCg0KVGhpcyBtYWtl cyBzZW5zZS4gIEkgaGF2ZSB1cGRhdGVkIHRoZSB0ZXh0IGFjY29yZGluZ2x5Lg0KDQo+IFRoZSBz YW1lIGNvbW1lbnQgaXMgYXBwbGljYWJsZSBpbiB0aGUgZHNjcCBsZWFmIGRlc2NyaXB0aW9uIG9u IHBhZ2UgNDUuICBJdCBpcw0KDQo+IG1pc2NoYXJhY3Rlcml6ZWQgYXMgYSBwdXJlIHByaW9yaXR5 IG1lY2hhbmlzbSwgd2hpY2ggaXMgbm90IGhvdyB0aGUgSUVURiBoYXMNCg0KPiBkZWZpbmVkIERT Q1AuDQoNCg0KDQpJIGhhdmUgdHdlYWtlZCB0aGUgbGVhZiB0ZXh0IHRvOg0KDQoNCg0KICAgICAg ICAiVGhlIGRlc2lyZWQgbmV0d29yayBEaWZmU2VydiBDb2RlIFBvaW50IChEU0NQKSB2YWx1ZS4g VGhpcyBpcw0KDQogICAgICAgICB0aGUgRFNDUCB2YWx1ZSB0byBiZSBzZXQgb24gbm90aWZpY2F0 aW9uIG1lc3NhZ2VzDQoNCiAgICAgICAgIGVuY2Fwc3VsYXRpbmcgdGhlIHJlc3VsdHMgb2YgdGhl IHN1YnNjcmlwdGlvbi4gIFRoaXMgRENQIHZhbHVlDQoNCiAgICAgICAgIGlzIHNoYXJlZCBmb3Ig YWxsIHJlY2VpdmVycyBvZiBhIGdpdmVuIHN1YnNjcmlwdGlvbi4iDQoNCg0KDQpEb2VzIHRoaXMg bWVldCB5b3VyIG9iamVjdGl2ZT8NCg0KDQoNCj4gVGhlIHdlaWdodGluZyBmZWF0dXJlIHNlZW1z IHRvIG5lZWQgYSBsaXR0bGUgYml0IG1vcmUgd29yay4gIEl0IGFsbG93cyB2YWx1ZXMNCg0KPiBi ZXR3ZWVuIDAgYW5kIDI1NSwgYW5kIHRoZXJlIGlzIHNvbWUgZGVzY3JpcHRpb24gdGhhdCBiYW5k d2lkdGggaXMgc3VwcG9zZWQNCg0KPiB0byBiZSBhbGxvY2F0ZWQgc29tZWhvdyBwcm9wb3J0aW9u YWwgdG8gdGhlIHdlaWdodGluZywgYnV0IGl0J3Mgbm90IHJlYWxseSBjbGVhcg0KDQo+IGhvdyB0 aGlzIHdvdWxkIGJlIGRvbmUgb3IgdGhhdCBpdCBtYWtlcyBzZW5zZS4gICBJcyBpdCBhc3N1bWVk IHRoYXQgdGhlDQoNCj4gcHVibGlzaGVyIGhhcyBzb21lIGZpeGVkIGJhbmR3aWR0aCBsaW1pdCB0 aGF0IGl0J3MgdHJ5aW5nIHRvIHN0YXkgd2l0aGluLCBhbmQNCg0KPiB0aGF0IGl0IGNhbiBjaG9v c2UgbWVzc2FnZXMgZnJvbSBzdHJlYW1zIChiYXNlZCBvbiB0aGVpciBzaXplLCBmcmVxdWVuY3ks IGV0YykNCg0KPiBpbiBzb21lIHdheSB0byBob25vciB0aGUgd2VpZ2h0cz8gIFdoYXQgaXMgdGhl IG1ldGhvZCB0byBjb21wdXRlIHRoZQ0KDQo+IHByb3BvcnRpb25zPyAgSXMgaXQgcHVyZWx5IGxp bmVhcj8gIFdoYXQgaWYgdGhlcmUgaXMgbm8gY29udGVudGlvbj8gIFdoYXQgaWYgdGhlcmUNCg0K PiBpcyBubyBpbmhlcnJlbnQgYmFuZHdpZHRoIGxpbWl0IGtub3duIHRvIHRoZSBwdWJsaXNoZXIg KHNpbmNlIGdlbmVyYWxseSB0aGVyZQ0KDQo+IHByb2JhYmx5IHdvdWxkbid0IGJlKT8gIFRoZSBp bnRlbnRpb24gYW5kIGRldGFpbCBvZiB3aGF0IHRoaXMgaXMgdHJ5aW5nIHRvDQoNCj4gYWNoaWV2 ZSBzZWVtcyB0byBuZWVkIHRvIGJlIHdvcmtlZCB0aHJvdWdoIGEgYml0IG1vcmUgdG8gYXZvaWQg anVzdCBoYXZpbmcgYQ0KDQo+IGNvbXBsZXggZmVhdHVyZSB0aGF0IG1pZ2h0IG5vdCByZWFsbHkg YWNoaWV2ZSBtdWNoIHJlYWwgcmVzdWx0LCBkZXBlbmRpbmcgb24NCg0KPiBob3cgaXRzIGltcGxl bWVudGVkLg0KDQoNCg0KSW5pdGlhbGx5IHRoZSBkcmFmdCB0ZXh0IG1hZGUgc29tZSBleHBsaWNp dCBsaW5rYWdlcyBoZXJlIHRvIGNvcnJlc3BvbmRpbmcgSFRUUDIgY2FwYWJpbGl0aWVzLiAgVGhl IG9iamVjdGl2ZSBpcyB0byBoYXZlIHRoZSBwcmlvcml0eSBtZWNoYW5pc20gKmV4YWN0bHkqIG1h dGNoIHRvIHRoZSB3ZWlnaHQgbWVjaGFuaXNtcyB1c2VkIHdpdGggSFRUUDIuICAgQmVsb3cgKG9y IGF0dGFjaGVkKSBpcyBhIHBpY3R1cmUgZnJvbSBJRVRGICM5NiAgc2hvd2luZyB0aGUgaW50ZW5k ZWQgYmVoYXZpb3I6DQoNCltjaWQ6aW1hZ2UwMDIuanBnQDAxRDRFQkM1LjhFMDUzRTYwXQ0KDQpU aGlzIGNvbXBsZXggZmVhdHVyZSByZWFsbHkgc2hvdWxkbuKAmXQgYmUgdmVyeSBoYXJkIGluIHBy YWN0aWNlIHdoZXJlIEhUVFAyIHRyYW5zcG9ydCBhbmQgY29kZSBleGlzdHMuDQoNCg0KDQpBbHNv IHdvcnRoIG5vdGluZyBpcyB0aGF0IHRoZSBPcGVuQ29uZmlnIHRlbGVtZXRyeSBlZmZvcnQgdXNl cyBHUlBDLiAgQW5kIHVuZGVybmVhdGggR1JQQyBpcyBIVFRQMi4gIFNvIHBhcmFsbGVsIHN0YW5k YXJkaXphdGlvbiBtZWNoYW5pc21zIGFyZSBwb3NpdGlvbmVkIGhlcmUgYXMgd2VsbC4NCg0KDQoN Cj4gSXMgdGhlcmUgYW55IHRob3VnaHQgb24gcGhhc2UgZWZmZWN0cywgd2l0aCByZWdhcmQgdG8g ZXZlbnRzIHRoYXQgaGF2ZSBtYW55DQoNCj4gc3Vic2NyaWJlcnMsIGNhdXNpbmcgYSBsYXJnZSBu dW1iZXIgb2Ygc2ltdWx0YW5lb3VzIHdyaXRlcyBvbiBkaWZmZXJlbnQNCg0KPiBzdHJlYW1zPyAg T3ZlcmFsbCwgdGhlcmUgY291bGQgYmUgbG93IGJhbmR3aWR0aCB1dGlsaXphdGlvbiBmb3Igbm90 aWZpY2F0aW9ucywNCg0KPiBidXQgdGhlbiBzdWRkZW4gc3Bpa2VzIHdoZW4gdGhlcmUgaXMgYSBj b3VwbGluZyBpbiB0aGUgbm90aWZpY2F0aW9ucyBnb2luZyBvdXQNCg0KPiBvbiBtdWx0aXBsZSBz dHJlYW1zLiAgVGhpcyBjb3VsZCBsZWFkIHRvIHNvbWUgY29ubmVjdGlvbnMgc2VlaW5nIGxvc3Nl cyBhbmQNCg0KPiBvdGhlcnMgbm90LCBmb3IgaW5zdGFuY2UsIGFuZCB0aGVyZSBtaWdodCBiZSBh IHJlYXNvbiB0byB0cnkgdG8gZGl0aGVyIHRoZSB3cml0ZXMNCg0KPiBvciBoYXZlIG90aGVyIGxv Z2ljIGVuY291cmFnZWQgdG8gaGFuZGxlIHN1cmdlcyBvZiBvdXRnb2luZyBub3RpZmljYXRpb25z Lg0KDQo+IFNpbmNlIHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9ydHMgYXJlIFRDUC1iYXNlZCwgbG9z c2VzIHdpbGwgYmUgcmVjb3ZlcmVkDQoNCj4gZXZlbnR1YWxseSwgYnV0IHRoZXJlIGNvdWxkIGJl IGxhdGVuY3kgY3JlYXRlZCBpbiB0aGUgbWVhbnRpbWUuICBUaGlzIG1pZ2h0DQoNCj4gbW90aXZh dGUgc29tZSBvZiB0aGUgUW9TIGZlYXR1cmVzIHRoYXQgYXJlIGN1cnNvcmlseSBkaXNjdXNzZWQs IGJ1dCBpdHMgbm90IGNsZWFyDQoNCj4gaG93IHRoZXkgd291bGQgYmUgZWZmZWN0aXZlLg0KDQoN Cg0KWWVzLCB0aGlzIGlzIHZlcnkgbXVjaCBhIGNvbnNpZGVyYXRpb24uICBBbmQgd2hlcmUgdGhp cyBpcyBhIHdvcnJ5IGFib3V0IHRoZXNlIGlzc3Vlcywgd2Ugd2FudGVkIHRvIGFsbG93IHRoZSBh ZG9wdGlvbiBvZiB0cmFuc3BvcnRzIGNhcGFibGUgb2YgaGFuZGxpbmcgdGhlc2UgaXNzdWVzLiAg IEJ1dCB0aGlzIGlzIGEgaGFyZCB0ZWNobm9sb2d5IHByb2JsZW0gc3BhY2UuICBBbmQgd2UgZGlk buKAmXQgd2FudCB0byBkZXZlbG9wIG5ldyBjb21wbGV4IGNvZGUuICBBbmQgd2UgZGlkbuKAmXQg d2FudCB0byBkZXZlbG9wIHVudGVzdGVkIFFvUyBwYXJhZGlnbXMuICAgRXNwZWNpYWxseSB3aGVu IHJlYWxseSBnb29kIGluZHVzdHJ5IHNvbHV0aW9ucyBhbHJlYWR5IGV4aXN0Lg0KDQoNCg0KQXMg YSByZXN1bHQsIGVsZW1lbnRzIG9mIHRoZSBRb1MgbW9kZWwgdW5kZXJseWluZyBIVFRQMiBzZWVt ZWQgcmVhc29uYWJsZSB0byBhZG9wdC4NCg0KDQoNClRoYW5rcyBhZ2FpbiBmb3IgdGhlIGRlZXAg Y29uc2lkZXJhdGlvbiBvZiBRb1MgaW1wbGljYXRpb25zIGhlcmUsDQpFcmljDQoNCg0K --_000_8bb9e0b1b7f342acb2c77146b27bf479XCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu TXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhhbmtzIHZl cnkgbXVjaCBXZXNsZXkgZm9yIHRoZSByZXZpZXdzISZuYnNwOyAmbmJzcDtDb21tZW50cyBpbi1s aW5lLi4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgRnJvbTogV2VzbGV5IEVk ZHksIEFwcmlsIDIsIDIwMTkgMTowNCBQTTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgUmV2aWV3ZXI6IFdlc2xleSBFZGR5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IFJldmlldyByZXN1bHQ6IEFsbW9zdCBSZWFkeTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgVGhpcyBkb2N1bWVudCBoYXMgYmVlbiByZXZpZXdlZCBhcyBwYXJ0 IG9mIHRoZSB0cmFuc3BvcnQgYXJlYSByZXZpZXcgdGVhbSdzPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBrZXkgSUVU RiBkb2N1bWVudHMuIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBwcmltYXJpbHkgZm9yIHRoZSB0cmFuc3BvcnQg YXJlYSBkaXJlY3RvcnMsIGJ1dCBhcmUgY29waWVkIHRvIHRoZSBkb2N1bWVudCdzPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGF1dGhvcnMgYW5kIFdHIHRvIGFs bG93IHRoZW0gdG8gYWRkcmVzcyBhbnkgaXNzdWVzIHJhaXNlZCBhbmQgYWxzbyB0byB0aGUgSUVU RjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBkaXNjdXNzaW9u IGxpc3QgZm9yIGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg V2hlbiBkb25lIGF0IHRoZSB0aW1lIG9mIElFVEYgTGFzdCBDYWxsLCB0aGUgYXV0aG9ycyBzaG91 bGQgY29uc2lkZXIgdGhpczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyByZXZpZXcgYXMgcGFydCBvZiB0aGUgbGFzdC1jYWxsIGNvbW1lbnRzIHRoZXkgcmVjZWl2 ZS4gUGxlYXNlIGFsd2F5cyBDQyB0c3YtPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IGFydEBpZXRmLm9yZyBpZiB5b3UgcmVwbHkgdG8gb3IgZm9yd2FyZCB0aGlz IHJldmlldy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRoZSBkb2N1bWVudCBp bmNsdWRlcyBhIHdheSBpbnRlbmRlZCB0byBhc2sgZm9yIGEgcGFydGljdWxhciBEaWZmU2VydiBD b2RlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFBvaW50IChE U0NQKSB2YWx1ZSB0byBiZSB1c2VkIGJ5IGEgcHVibGlzaGVyLiZuYnNwOyBUaGlzIGlzIG1pc3Np bmcgc29tZSBjb250ZXh0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyBXaHkgd291bGQgYSBzdWJzY3JpYmVyIGRvIHRoaXM/Jm5ic3A7IDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5Tb21lIG9mIHRoZSBRb1MgY29udGV4dCBpcyBwcm92aWRlZCBmcm9t IFJGQy03OTIzLiZuYnNwOyBUaGlzIFJGQyBwcm92aWRlcyByZXF1aXJlbWVudHMvY29udGV4dCBm b3IgYSBZQU5HIGJhc2VkIHN1YnNjcmlwdGlvbiBzZXJ2aWNlLiZuYnNwOw0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPkFzIGEgcXVpY2sgc3VtbWFyeSBvZiB0aGlzIFJGQywgdGhlIHN1 YnNjcmlwdGlvbiBzZXJ2aWNlIGZpcnN0IGFuZCBmb3JlbW9zdCBlc3RhYmxpc2hlcyBhIG5ldyBt ZWNoYW5pc20gZm9yIHJvdXRlciBpbnRlZ3JhdGlvbiB3aXRoIG5ldHdvcmsgQ29udHJvbGxlcnMg YW5kIE5ldHdvcmsgTWFuYWdlbWVudCBTeXN0ZW1zIChOTVMpLiZuYnNwOyZuYnNwOyBCZXR3ZWVu IHRoZXNlIGRldmljZXMsIGEgY29tbW9uIG5ldHdvcmsgb3BlcmF0aW9ucw0KIGNvbnRleHQgbWln aHQgYmUgYXZhaWxhYmxlLiZuYnNwOyBJbiBmYWN0LCB0aGUgc2FtZSBvcGVyYXRpb25hbCBvcmdh bml6YXRpb25zIG1pZ2h0IG9wZXJhdGUgYWxsIHRoZXNlIGRldmljZXMuJm5ic3A7IEJhc2VkIG9u IHRoaXMsIHRoZXJlIHNob3VsZCBiZSBzb21lIHNoYXJlZCBrbm93bGVkZ2Ugb2YgdGhlIHVuZGVy bHlpbmcgUW9TIGNvbnRleHQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkluIGNvbW11 bmljYXRpbmcgYmV0d2VlbiBDb250cm9sbGVycy9OTVMgYW5kIGEgbmV0d29yayBlbGVtZW50LCBz b21lIHN1YnNjcmlwdGlvbnMgbWlnaHQgY2FycnkgaW5mb3JtYXRpb24gd2l0aCBhIGhpZ2hlciBi dXNpbmVzcyBwcmVjZWRlbmNlIHRoYW4gb3RoZXJzLiZuYnNwOyBGb3IgZXhhbXBsZSwgcHJvdmlk aW5nIGluZm9ybWF0aW9uIGFib3V0IGEgbGluZSBjYXJkIG91dGFnZSBzaG91bGQgdGFrZSBwcmVj ZWRlbmNlDQogb3ZlciBhIHNldCBvZiBjb3VudGVycy4gJm5ic3A7Jm5ic3A7VGhlc2UgcHJlY2Vk ZW5jZSBuZWVkcyBtdXN0IGJlIHJlc3BlY3RlZCBhdCBhIHZhcmlldHkgb2YgY29uZ2VzdGlvbiBw b2ludHMuJm5ic3A7IFRoZXNlIGluY2x1ZGUgZHVyaW5nIHRoZSBkZXF1ZXVpbmcgb2YgaW5mb3Jt YXRpb24gZnJvbSB0aGUgcHVibGlzaGVyLCBhcyB3ZWxsIGFzIGR1cmluZyBuZXR3b3JrIHRyYW5z aXQuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RHJpdmVuIGJ5IHRoaXMs IFJGQy03OTIzIFNlY3Rpb24gNC4yLjYuOCBwcm92aWRlcyBndWlkYW5jZSBvbiBzb21lIHN1YnNj cmlwdGlvbiBRb1MgcGFyYW1ldGVyczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyDigJxUaGUgU3Vic2NyaXB0aW9uIFNlcnZpY2UgU0hPVUxEIHN1cHBvcnQg dGhlIHJlbGF0aXZlIHByaW9yaXRpemF0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgb2Ygc3Vic2NyaXB0aW9ucyBzbyB0aGF0IHRoZSBkZXF1 ZXVpbmcgYW5kIGRpc2NhcmRpbmcgb2YgcHVzaCB1cGRhdGVzPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgY2FuIGNvbnNpZGVyIHRoaXMgaWYgdGhl cmUgaXMgaW5zdWZmaWNpZW50IGJhbmR3aWR0aCBiZXR3ZWVuIHRoZTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFB1Ymxpc2hlciBhbmQgdGhlIFJl Y2VpdmVyLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgbmVlZCBmb3IgRFND UCBpcyB3ZWxsIGtub3duLCBhbmQgaGFzIGFsc28gYmVlbiByZWNvZ25pemVkIGJ5IHRoZSBPcGVu Q29uZmlnIFRlbGVtZXRyeSBlZmZvcnQuJm5ic3A7Jm5ic3A7IEFuZCBhcyBhIHJlc3VsdCwgdGhl IERTQ1Agb2JqZWN0IGZyb20gdGhpcyBkcmFmdCB3YXMgYWxzbyBwaWNrZWQgdXAgYnkgdGhlIE9w ZW5Db25maWctdGVsZW1ldHJ5LnlhbmcgbW9kZWwuJm5ic3A7ICZuYnNwO0ZvciBtb3JlIGluZm8g b24gdGhhdCwNCiBzZWUgbGluZSA1ODMgb2Y6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5odHRwczovL2dpdGh1Yi5jb20vb3BlbmNvbmZpZy9wdWJsaWMvYmxvYi9tYXN0 ZXIvcmVsZWFzZS9tb2RlbHMvdGVsZW1ldHJ5L29wZW5jb25maWctdGVsZW1ldHJ5Lnlhbmc8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBJcyBpdCBhc2tpbmcgZm9yIERTQ1AgdmFs dWVzIHRoYXQgaXQgYXNzdW1lczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBhcmUgaG9ub3JlZCBhbmQgbm90IGJsZWFjaGVkIG9yIGFsdGVyZWQgYWxsIHRoZSB3 YXkgYmV0d2VlbiBpdCBhbmQgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IHB1Ymxpc2hlcj8mbmJzcDsgQXJlIHRoZXJlIGNvbmRpdGlvbnMgbm9ybWFsIGZv ciB0aGUgdXNlIG9mIHRoaXMgcHJvdG9jb2wgd2hlcmUgdGhhdDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBhc3N1bXB0aW9uIHVzdWFsbHkgaG9sZHM/PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSB0ZWxlbWV0cnkgaW1wbGVtZW50YXRpb25zIHNl ZW4gc28gZmFyIGFyZSB3aXRoaW4gdGhlIGRvbWFpbi9wcm92ZW5hbmNlIG9mIGEgc2luZ2xlIG9w ZXJhdG9yLiZuYnNwOyBBcyBhIHJlc3VsdCwgdGhlcmUgaGF2ZW4ndCBiZWVuIHJlcXVpcmVtZW50 cyB3aGljaCBoYXZlIGRyaXZlbiBhIG1hcHBpbmcgb3IgbmVnb3RpYXRpb24gYmV0d2VlbiBhIHJl cXVlc3RlZCBxdWFsaXR5IG9mIHNlcnZpY2UsIGFuZCBvbmUNCiBkZWxpdmVyZWQgYnkgdGhlIHN1 YnNjcmlwdGlvbiBzZXJ2aWNlLiZuYnNwOyAoV2UgdGFsa2VkIGFib3V0IHRoaXMgZWFybHkgb24s IGJ1dCBwZW9wbGUgdGhvdWdodCB0aGF0IHdvdWxkIGJlIHVubmVjZXNzYXJ5IGNvbXBsZXhpdHku Jm5ic3A7IFBsdXMgd2UgY291bGQgYWx3YXlzIGxheWVyIHN1Y2ggYSBjYXBhYmlsaXR5IGluIGR1 cmluZyB0aGUgZnV0dXJlIGlmIG5lY2Vzc2FyeS4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgQnkgYXNraW5nIGZvciBhIHBhcnRpY3VsYXIgRFNDUCB0byBiZSBzZXQsIHRoZSBz dWJzY3JpYmVyIGlzIG1heWJlIGF0dGVtcHRpbmcgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgb3B0aW1pemUgdGhlIGJlaGF2aW9yIGR1cmluZyBzb21lIHR5 cGUgb2Ygb3ZlcmxvYWQsIHdoZXJlIHRoZXkgcmVhbGx5IHdhbnQ8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgc29tZSBub3RpZmljYXRpb25zIHF1aWNrbHksIGJ1 dCBvdGhlcnMgYXJlbid0IGFzIGltcG9ydGFudCwgYW5kIG1heSBiZSBmaW5lIHRvPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGRyb3AgYW5kIGhhdmUgcmV0cmFu c21pdHRlZCBieSBUQ1AsIGV0Yy4mbmJzcDsgVGhpcyBhbGwgc2VlbXMgdG8gYmUgaW1wbGljaXQg dGhvdWdoLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB3aXRo IG5vIGRlZXAgZGlzY3Vzc2lvbiBvZiB3aGF0IHRoZSBwcm90b2NvbCBpcyBhdHRlbXB0aW5nIHRv IGVuYWJsZSB3aXRoIHRoaXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgb3B0aW9uIG9yIGhvdyBpdCB3b3VsZCBiZSBwcm9kdWN0aXZlbHkgdXNlZC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+V2UgaGFkIHNldmVyYWwgZWFybHkgZGlzY3Vzc2lvbnMg b24gd2hldGhlciB0aGlzIGRyYWZ0IHNob3VsZCB0YWxrIGFib3V0IHZhcmlvdXMgYnVzaW5lc3Mg b2JqZWN0aXZlcyBvZiBwcm90b2NvbCBzZWxlY3Rpb25zLiZuYnNwOyBBbmQgaW4gbWFueSBjYXNl cyB0aGlzIGlzIGRvbmUuJm5ic3A7IEJ1dCBhcyB0aGUgZHJhZnQgZG9jdW1lbnRzIHdhcyBhbHJl YWR5IHF1aXRlIGxhcmdlLCB3ZSBoYXZlIGJlZW4gaG9waW5nIHRoYXQNCiBvdGhlciBkb2N1bWVu dHMgY2FuIHByb3ZpZGUgaGVscC9jb250ZW50IG9uIFFvUyBhc3BlY3RzLCByYXRoZXIgdGhhbiBn b2luZyBpbnRvIHRoZW0gZGVlcGx5IGhlcmUuICZuYnNwO0FuZCB0aGVyZSBhcmUgZG9jdW1lbnRz IHdoaWNoIGRvIGhlbHAuJm5ic3A7Jm5ic3A7IEZvciBleGFtcGxlIGltcGxlbWVudGVycyBkbyBo YXZlIGRvY3VtZW50cyBsaWtlIFJGQy03OTIzIGFuZA0KPGEgaHJlZj0iaHR0cDovL3d3dy5vcGVu Y29uZmlnLm5ldC9wcm9qZWN0cy90ZWxlbWV0cnkvIj5odHRwOi8vd3d3Lm9wZW5jb25maWcubmV0 L3Byb2plY3RzL3RlbGVtZXRyeS88L2E+LiZuYnNwOyBUaGVyZSBhcmUgYWxzbyB2ZW5kb3IgZG9j dW1lbnRzIHdoaWNoIGNhbiBwcm92aWRlIGd1aWRhbmNlLiZuYnNwOw0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBJdCBzZWVtcyB0byBiZSBjb25zaWRlcmVkIGZhdGFsIGlmIGEgcHVibGlzaGVy IGNhbid0IHdyaXRlIGEgcmVxdWVzdGVkIERTQ1A8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgdmFsdWUuJm5ic3A7IFRoZSByZXF1ZXN0cyBmYWlsIHdpdGggJnF1 b3Q7ZHNjcC11bmF2YWlsYWJsZSZxdW90Oy4mbmJzcDsgVGhpcyBzZWVtcyB0b28gZHJhc3RpYywg c2luY2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdGhlIERT Q1AgaXMgYW55d2F5cyBhZHZpc29yeSB0byBub2RlcyBvbiB0aGUgcGF0aCwgYW5kIG1heSBiZSBh bHRlcmVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGFueXdh eXMuJm5ic3A7IEknbSBub3Qgc3VyZSB3aHkgdGhpcyB3b3VsZCBiZSBjb25zaWRlcmVkIGEgZmF0 YWwgaXNzdWUgdG8gdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IHN1YnNjcmlwdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QSBkZXNpZ24g Z29hbCBpcyB0aGF0IGEgcHVibGlzaGVyIGV4YWN0bHkgbWVldHMgdGhlIHRlcm1zIHJlcXVlc3Rl ZCBieSB0aGUgc3Vic2NyaXB0aW9uLiZuYnNwOyAmbmJzcDtJZiBhIHB1Ymxpc2hlciBjYW5ub3Qg bWVldCB0aGUgcmVxdWVzdCwgdGhlIHN1YnNjcmlwdGlvbiBpcyBub3QgZXN0YWJsaXNoZWQuJm5i c3A7Jm5ic3A7IFNvIGlmIGEgRFNDUCBpcyBub3QgYXZhaWxhYmxlLCB3ZSBoYXZlIHRoZSBzdWJz Y3JpYmVyIGFzayBmb3Igb25lDQogdGhhdCBpcyBhdmFpbGFibGUuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkRTQ1Agbm90IGF2YWlsYWJsZSBpcyBqdXN0IG9uZSBvZiBtYW55IHJlYXNv bnMgd2h5IGEgc3Vic2NyaXB0aW9uIG1heSBiZSByZWplY3RlZC4mbmJzcDsgQW5kIGVhY2ggcmVq ZWN0ZWQgc3Vic2NyaXB0aW9uIHJlcXVlc3QgY2FuIGVmZmVjdGl2ZWx5IGJlIHRyZWF0ZWQgYXMg YSBuZWdvdGlhdGlvbi4mbmJzcDsgU28gbG9vayBhdCBlcnJvciBtZXNzYWdlcyBhcyBhIHdheSB0 byBwcm92aWRlIGZlZWRiYWNrIGZvciBhIGJldHRlcg0KIHN1YnNlcXVlbnQgc3Vic2NyaXB0aW9u IHJlcXVlc3QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVGhlIGZlYXR1cmUg ZGVzY3JpcHRpb24gZm9yICZxdW90O2RzY3AmcXVvdDsgbWlzY2hhcmFjdGVyaXplcyBpdCBhcyBh IHB1cmUgcHJpb3JpdHk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgbWVjaGFuaXNtLCByYXRoZXIgdGhhbiBhIG1vcmUgZ2VuZXJhbCBpbmRpY2F0aW9uIG9mIGNs YXNzIG9mIHNlcnZpY2UgdHJlYXRtZW50OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyZuYnNwOyAmcXVvdDtUaGlzIGZlYXR1cmUgaW5kaWNhdGVzIGEgcHVibGlz aGVyIHN1cHBvcnRzIHRoZSBwbGFjZW1lbnQgb2Ygc3VnZ2VzdGVkPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHByaW9yaXRpemF0aW9uIGxldmVscyBmb3IgbmV0 d29yayB0cmFuc3BvcnQgd2l0aGluIG5vdGlmaWNhdGlvbiBtZXNzYWdlcy4mcXVvdDsmbmJzcDsg SXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgY291bGQgYmUg bW9yZSBjb3JyZWN0IHRvIHNheSBzb21ldGhpbmcgbGlrZSAmcXVvdDtUaGlzIGZlYXR1cmUgaW5k aWNhdGVzIHRoYXQgYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBwdWJsaXNoZXIgc3VwcG9ydHMgdGhlIGFiaWxpdHkgdG8gc2V0IHRoZSBEaWZmU2VydiBDb2Rl IFBvaW50IChEU0NQKSB2YWx1ZSBpbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBvdXRnb2luZyBwYWNrZXRzLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5UaGlzIG1ha2VzIHNlbnNlLiZuYnNwOyBJIGhhdmUgdXBkYXRlZCB0aGUgdGV4dCBh Y2NvcmRpbmdseS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGUgc2FtZSBjb21tZW50 IGlzIGFwcGxpY2FibGUgaW4gdGhlIGRzY3AgbGVhZiBkZXNjcmlwdGlvbiBvbiBwYWdlIDQ1LiZu YnNwOyBJdCBpczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBt aXNjaGFyYWN0ZXJpemVkIGFzIGEgcHVyZSBwcmlvcml0eSBtZWNoYW5pc20sIHdoaWNoIGlzIG5v dCBob3cgdGhlIElFVEYgaGFzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IGRlZmluZWQgRFNDUC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBoYXZl IHR3ZWFrZWQgdGhlIGxlYWYgdGV4dCB0bzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O1RoZSBkZXNp cmVkIG5ldHdvcmsgRGlmZlNlcnYgQ29kZSBQb2ludCAoRFNDUCkgdmFsdWUuIFRoaXMgaXMNCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhlIERTQ1AgdmFsdWUgdG8gYmUg c2V0IG9uIG5vdGlmaWNhdGlvbiBtZXNzYWdlcyZuYnNwOw0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtlbmNhcHN1bGF0aW5nIHRoZSByZXN1bHRzIG9mIHRoZSBzdWJzY3Jp cHRpb24uJm5ic3A7IFRoaXMgRENQIHZhbHVlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO2lzIHNoYXJlZCBmb3IgYWxsIHJlY2VpdmVycyBvZiBhIGdpdmVuIHN1YnNjcmlw dGlvbi4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RG9lcyB0aGlzIG1lZXQg eW91ciBvYmplY3RpdmU/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVGhlIHdl aWdodGluZyBmZWF0dXJlIHNlZW1zIHRvIG5lZWQgYSBsaXR0bGUgYml0IG1vcmUgd29yay4mbmJz cDsgSXQgYWxsb3dzIHZhbHVlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBiZXR3ZWVuIDAgYW5kIDI1NSwgYW5kIHRoZXJlIGlzIHNvbWUgZGVzY3JpcHRpb24g dGhhdCBiYW5kd2lkdGggaXMgc3VwcG9zZWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgdG8gYmUgYWxsb2NhdGVkIHNvbWVob3cgcHJvcG9ydGlvbmFsIHRvIHRo ZSB3ZWlnaHRpbmcsIGJ1dCBpdCdzIG5vdCByZWFsbHkgY2xlYXI8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgaG93IHRoaXMgd291bGQgYmUgZG9uZSBvciB0aGF0 IGl0IG1ha2VzIHNlbnNlLiZuYnNwOyZuYnNwOyBJcyBpdCBhc3N1bWVkIHRoYXQgdGhlPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHB1Ymxpc2hlciBoYXMgc29t ZSBmaXhlZCBiYW5kd2lkdGggbGltaXQgdGhhdCBpdCdzIHRyeWluZyB0byBzdGF5IHdpdGhpbiwg YW5kPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHRoYXQgaXQg Y2FuIGNob29zZSBtZXNzYWdlcyBmcm9tIHN0cmVhbXMgKGJhc2VkIG9uIHRoZWlyIHNpemUsIGZy ZXF1ZW5jeSwgZXRjKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBpbiBzb21lIHdheSB0byBob25vciB0aGUgd2VpZ2h0cz8mbmJzcDsgV2hhdCBpcyB0aGUgbWV0 aG9kIHRvIGNvbXB1dGUgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IHByb3BvcnRpb25zPyZuYnNwOyBJcyBpdCBwdXJlbHkgbGluZWFyPyZuYnNwOyBXaGF0 IGlmIHRoZXJlIGlzIG5vIGNvbnRlbnRpb24/Jm5ic3A7IFdoYXQgaWYgdGhlcmU8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgaXMgbm8gaW5oZXJyZW50IGJhbmR3 aWR0aCBsaW1pdCBrbm93biB0byB0aGUgcHVibGlzaGVyIChzaW5jZSBnZW5lcmFsbHkgdGhlcmU8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcHJvYmFibHkgd291 bGRuJ3QgYmUpPyZuYnNwOyBUaGUgaW50ZW50aW9uIGFuZCBkZXRhaWwgb2Ygd2hhdCB0aGlzIGlz IHRyeWluZyB0bzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBh Y2hpZXZlIHNlZW1zIHRvIG5lZWQgdG8gYmUgd29ya2VkIHRocm91Z2ggYSBiaXQgbW9yZSB0byBh dm9pZCBqdXN0IGhhdmluZyBhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IGNvbXBsZXggZmVhdHVyZSB0aGF0IG1pZ2h0IG5vdCByZWFsbHkgYWNoaWV2ZSBtdWNo IHJlYWwgcmVzdWx0LCBkZXBlbmRpbmcgb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgaG93IGl0cyBpbXBsZW1lbnRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+SW5pdGlhbGx5IHRoZSBkcmFmdCB0ZXh0IG1hZGUgc29tZSBleHBsaWNpdCBsaW5r YWdlcyBoZXJlIHRvIGNvcnJlc3BvbmRpbmcgSFRUUDIgY2FwYWJpbGl0aWVzLiZuYnNwOyBUaGUg b2JqZWN0aXZlIGlzIHRvIGhhdmUgdGhlIHByaW9yaXR5IG1lY2hhbmlzbSAqZXhhY3RseSogbWF0 Y2ggdG8gdGhlIHdlaWdodCBtZWNoYW5pc21zIHVzZWQgd2l0aCBIVFRQMi4mbmJzcDsmbmJzcDsg QmVsb3cgKG9yIGF0dGFjaGVkKSBpcyBhIHBpY3R1cmUNCiBmcm9tIElFVEYgIzk2ICZuYnNwO3No b3dpbmcgdGhlIGludGVuZGVkIGJlaGF2aW9yOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSI3NTIiIGhlaWdodD0iMzMxIiBzdHls ZT0id2lkdGg6Ny44MzMzaW47aGVpZ2h0OjMuNDQ3OWluIiBpZD0iUGljdHVyZV94MDAyMF8xIiBz cmM9ImNpZDppbWFnZTAwMi5qcGdAMDFENEVCQzUuOEUwNTNFNjAiPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhpcyBjb21wbGV4IGZlYXR1cmUgcmVhbGx5IHNob3Vs ZG7igJl0IGJlIHZlcnkgaGFyZCBpbiBwcmFjdGljZSB3aGVyZSBIVFRQMiB0cmFuc3BvcnQgYW5k IGNvZGUgZXhpc3RzLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFsc28gd29ydGgg bm90aW5nIGlzIHRoYXQgdGhlIE9wZW5Db25maWcgdGVsZW1ldHJ5IGVmZm9ydCB1c2VzIEdSUEMu Jm5ic3A7IEFuZCB1bmRlcm5lYXRoIEdSUEMgaXMgSFRUUDIuJm5ic3A7IFNvIHBhcmFsbGVsIHN0 YW5kYXJkaXphdGlvbiBtZWNoYW5pc21zIGFyZSBwb3NpdGlvbmVkIGhlcmUgYXMgd2VsbC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBJcyB0aGVyZSBhbnkgdGhvdWdodCBvbiBw aGFzZSBlZmZlY3RzLCB3aXRoIHJlZ2FyZCB0byBldmVudHMgdGhhdCBoYXZlIG1hbnk8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgc3Vic2NyaWJlcnMsIGNhdXNp bmcgYSBsYXJnZSBudW1iZXIgb2Ygc2ltdWx0YW5lb3VzIHdyaXRlcyBvbiBkaWZmZXJlbnQ8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgc3RyZWFtcz8mbmJzcDsg T3ZlcmFsbCwgdGhlcmUgY291bGQgYmUgbG93IGJhbmR3aWR0aCB1dGlsaXphdGlvbiBmb3Igbm90 aWZpY2F0aW9ucyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg YnV0IHRoZW4gc3VkZGVuIHNwaWtlcyB3aGVuIHRoZXJlIGlzIGEgY291cGxpbmcgaW4gdGhlIG5v dGlmaWNhdGlvbnMgZ29pbmcgb3V0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IG9uIG11bHRpcGxlIHN0cmVhbXMuJm5ic3A7IFRoaXMgY291bGQgbGVhZCB0byBz b21lIGNvbm5lY3Rpb25zIHNlZWluZyBsb3NzZXMgYW5kPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IG90aGVycyBub3QsIGZvciBpbnN0YW5jZSwgYW5kIHRoZXJl IG1pZ2h0IGJlIGEgcmVhc29uIHRvIHRyeSB0byBkaXRoZXIgdGhlIHdyaXRlczxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBvciBoYXZlIG90aGVyIGxvZ2ljIGVu Y291cmFnZWQgdG8gaGFuZGxlIHN1cmdlcyBvZiBvdXRnb2luZyBub3RpZmljYXRpb25zLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBTaW5jZSB0aGUgdW5kZXJs eWluZyB0cmFuc3BvcnRzIGFyZSBUQ1AtYmFzZWQsIGxvc3NlcyB3aWxsIGJlIHJlY292ZXJlZDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBldmVudHVhbGx5LCBi dXQgdGhlcmUgY291bGQgYmUgbGF0ZW5jeSBjcmVhdGVkIGluIHRoZSBtZWFudGltZS4mbmJzcDsg VGhpcyBtaWdodDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBt b3RpdmF0ZSBzb21lIG9mIHRoZSBRb1MgZmVhdHVyZXMgdGhhdCBhcmUgY3Vyc29yaWx5IGRpc2N1 c3NlZCwgYnV0IGl0cyBub3QgY2xlYXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgaG93IHRoZXkgd291bGQgYmUgZWZmZWN0aXZlLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5ZZXMsIHRoaXMgaXMgdmVyeSBtdWNoIGEgY29uc2lkZXJhdGlvbi4mbmJz cDsgQW5kIHdoZXJlIHRoaXMgaXMgYSB3b3JyeSBhYm91dCB0aGVzZSBpc3N1ZXMsIHdlIHdhbnRl ZCB0byBhbGxvdyB0aGUgYWRvcHRpb24gb2YgdHJhbnNwb3J0cyBjYXBhYmxlIG9mIGhhbmRsaW5n IHRoZXNlIGlzc3Vlcy4mbmJzcDsgJm5ic3A7QnV0IHRoaXMgaXMgYSBoYXJkIHRlY2hub2xvZ3kg cHJvYmxlbSBzcGFjZS4mbmJzcDsgQW5kIHdlIGRpZG7igJl0IHdhbnQNCiB0byBkZXZlbG9wIG5l dyBjb21wbGV4IGNvZGUuJm5ic3A7IEFuZCB3ZSBkaWRu4oCZdCB3YW50IHRvIGRldmVsb3AgdW50 ZXN0ZWQgUW9TIHBhcmFkaWdtcy4mbmJzcDsgJm5ic3A7RXNwZWNpYWxseSB3aGVuIHJlYWxseSBn b29kIGluZHVzdHJ5IHNvbHV0aW9ucyBhbHJlYWR5IGV4aXN0LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5BcyBhIHJlc3VsdCwgZWxlbWVudHMgb2YgdGhlIFFvUyBtb2RlbCB1bmRlcmx5 aW5nIEhUVFAyIHNlZW1lZCByZWFzb25hYmxlIHRvIGFkb3B0Lg0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlRoYW5rcyBhZ2FpbiBmb3IgdGhlIGRlZXAgY29uc2lkZXJhdGlvbiBvZiBR b1MgaW1wbGljYXRpb25zIGhlcmUsPGJyPg0KRXJpYzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_8bb9e0b1b7f342acb2c77146b27bf479XCHRTP013ciscocom_-- --_004_8bb9e0b1b7f342acb2c77146b27bf479XCHRTP013ciscocom_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=85944; creation-date="Fri, 05 Apr 2019 19:38:19 GMT"; modification-date="Fri, 05 Apr 2019 19:38:19 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAwADAAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAKWBeADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2RDlF OQeOo706mp9xenTt0p1ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFUdZmeDR7uSJikiREqw6g0MmUuWLl2L1FeQ/wDCT6x/0EZ/++qP+En1j/oIT/8AfVZe2R5P9s0v 5WevUV5D/wAJPrH/AEEJ/wDvqj/hJ9Y/6CE//fVHtkH9s0v5X+B69RXkP/CT6x/0EJ/++qP+En1j /oIT/wDfVHtkH9s0v5X+B69RXkP/AAk+sf8AQQn/AO+qP+En1j/oIT/99Ue2Qf2zS/lf4Hr1FeQ/ 8JPrH/QQn/76o/4SfWP+ghP/AN9Ue2Qf2zS/lf4Hr1FeQ/8ACT6x/wBBCf8A76o/4SfWP+ghP/31 R7ZB/bNL+V/gevUV5D/wk+sf9BCf/vqj/hJ9Y/6CE/8A31R7ZB/bNL+V/gevUV5D/wAJPrH/AEEJ /wDvqj/hJ9Y/6CE//fVHtkH9s0v5X+B69RXkP/CT6x/0EJ/++qP+En1j/oIT/wDfVHtkH9s0v5X+ B69RXkP/AAk+sf8AQQn/AO+qP+En1j/oIT/99Ue2Qf2zS/lf4Hr1FeQ/8JPrH/QQn/76o/4SfWP+ ghP/AN9Ue2Qf2zS/lf4Hr1FeQ/8ACT6x/wBBCf8A76o/4SfWP+ghP/31R7ZB/bNL+V/gevUV5D/w k+sf9BCf/vqj/hJ9Y/6CE/8A31R7ZB/bNL+V/gevUV5D/wAJPrH/AEEJ/wDvqj/hJ9Y/6CE//fVH tkH9s0v5X+B69RXkP/CT6x/0EJ/++qP+En1j/oIT/wDfVHtkH9s0v5X+B69RXkP/AAk+sf8AQQn/ AO+qP+En1j/oIT/99Ue2Qf2zS/lf4Hr1FeQ/8JPrH/QQn/76o/4SfWP+ghP/AN9Ue2Qf2zS/lf4H r1FYXhC9nvdAimupWllLsCzHnrW7Wid1c9WlUVSCmuoUUUUywooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKAGxjEajG3joO1OpsYxGoxjjoe1OoAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigBDWT4gfGi3o/wCmRrWNY3iL/kD3n/XI0nsZ1f4cvRnk1S2qh7uFWGVLgEHvzUVT2X/H 7B/10X+dcZ8VHdHZ+L/C9vFpy3mnQLGYh+8RO49azde061t/C2l3EECJNLje6jluK6LUtYXT/E0N tcc2tzCEcHoD61H4oggsrbR4jj7PHcjr6VvKK1se9XoUn7SULLo/J3WpyUPhPV57dZktTtYbgCwB I+laHhTwyuoPcS3sZ2xZVUJxlveuj1eYQa3DNHpl1cyBQY5InIX6Y6VW0G7N7r2rP5DQSNEMxE8g 0lBJmUMJRp1ox31t+Hp+ByV/4cv7KCa5liUQxvglWBxUNxod9a6dHfTRYt5MbWz69OK6Twwj3P8A aWi3odDMN6h+o5rekW31R7jQjgC1WMg/SkoJq5nDA06seaLtfRLz10PP5fD+oxPbo1uS9wN0aqck j+lTXXhXVbO3aaW2yi/e2sCR+Fdna6hFdeKb+CNlEsMHlQZ9R1xWX4UttTtdXu5dREqW4RvOMp+U n8aORB9Spcyiru7av2t3/rY5yx8OajqNqtzawB4mYrncByK2tP0SGLw7qv2y3ja6gOFbqV+hq004 j8A3T2pKI1y4XBxxup/g24it/DmoT3KmSNH3MOueKFFXHRw9KNSMe8W7vbZnKXOiXtnYR3lxGI4p Pu7mGT+FZ9db40ia9jtNVt5GezlQAL2Q1yVRJWdjgxNJUqnLHb8/MKKKKk5wooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigD0vwO+PD8Q/22/nXTiuU8Ef8AICj/AN5v511S9K64fCj7 LCfwIeiHUUUVR0BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAMjx5a4zjHfrT6bGcxqck8dTTqACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAQ1jeIv+QPef9cjWyaxvEX/ACB7 z/rkaT2M6v8ADl6M8mp8W/zU8vO/I249aZU9l/x+wf8AXRf51xnxUdWjXu9F8RahIsl1a3ErgYDN jpUd/b69M9vZXyTszf6mN8c49K7PXbLWLi8RtO1CO3i2AbGfHNYlrFqNv4w02PUrtbluSpVs4GK1 cbHrVcKoy5fe1aV9LMwm1bWdM3WbXU8Jj+UxlulU4NQu7W5NxBcSJM3VweTXUzaCNa8V6m8zslvA 2XKjJPHQVXvvDFpJpE17pv2pDAfnjuFwSPUVLjI554avq09Fe2uunYwRq18L77YLmT7TjHmZ5oi1 a+hu3uo7mRZ5PvODya6W48O6LY2tjPeTXI+0gDamCcnv9KfP4W0ax1WKzurq4L3P+qVQPl+po5ZD +qYhfa/Hq/8AM5AXMwuDOJGEpO7eDzmrVzreo3kPlXF5NJH/AHS3FbFv4RMviK5sWlP2e3G9nA5I 7D61PceFrO50+5n037Wklvklbhcbx7UcsiI4XEcrt59d7bnNDULoWP2MTN9mzny+2aIdQuoLaS2h mdYZfvoOjV0f/CP6RbaDaajezXCiQfMqYJJ9qkm0DTdPvtMvI5JpLO5cYU43Z7fhRysf1WsrPm7d dk/0OdludQtrIWUrypbuNwiboR61RrsPiB9jF8gUS/awo/3Nv+NcfSkrOxjiqbpVHC97BRRRUnOF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAej+CP+QHH/vN/OuqXpXK+CP8AkBx/ 7zfzrql6V1w+FH2WE/gQ9EOoooqjoCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAbGcxqchuOo706mp9 xenTt0p1ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAIaxvEX/IHvP+ uRrZNY3iL/kD3n/XI0nsZ1f4cvRnk1S2rBLuFmOFVwSfxqKiuM+JTs7ne60mh6zdrcPraxEIF2qe KzLaLStI8QafPBqYuIgzeY7H7nHFcrRVud3ex2zxnNLn5Fe976/5ncWfiOzt9f1RHuNtvdNlJ06K cdapardiPTpAPEb3btwI1Xgj3rlKKOdieNnKLi1379fmdV4h1K0urfRVgnRzAB5gB+7061Prmq2V x4s0y5huY3giC73B4XmuOopczCWMm76b2/A7mPxLZWviy8fzg1rcoFEqc7TjrVbUbxYrKZl8SvcM chIkXqPQ1x9FPnY3jpyTTXfv1+Z02taha3HhPTLaKdHnibLoOq8VY1PV7NtG0RYp0eS3dWkQdVAr kaKXMyHi566bpL7jqfGM9hqMsd9aX0cjlQphA5HvXLUUUm7u5lWq+1m5tWuFFFFIyCiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKAPR/BH/IDj/3m/nXVL0rlfBH/IDj/wB5v511S9K6 4fCj7LCfwIeiHUUUVR0BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUANQYRQQBx0HanU2MYjUYxx0PanU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAhrG8Rf8AIHvP+uRrZNY3 iL/kD3n/AFyNJ7GdX+HL0Z5NRRTJZPKTdjNckYuTUVuz4lK+g+iqv24f3DR9uH9w10/Uq/8AKX7O XYtUVV+3D+4aPtw/uGj6lX/lD2cuxaoqr9uH9w0fbh/cNH1Kv/KHs5di1RVX7cP7ho+3D+4aPqVf +UPZy7Fqiqv24f3DR9uH9w0fUq/8oezl2LVFVftw/uGj7cP7ho+pV/5Q9nLsWqKq/bh/cNH24f3D R9Sr/wAoezl2LVFVftw/uGj7cP7ho+pV/wCUPZy7Fqiqv24f3DR9uH9w0fUq/wDKHs5di1RVX7cP 7ho+3D+4aPqVf+UPZy7Fqiqv24f3DR9uH9w0fUq/8oezl2LVFVftw/uGj7cP7ho+pV/5Q9nLsWqK q/bh/cNH24f3DR9Sr/yh7OXYtUVV+3D+4aPtw/uGj6lX/lD2cuxaoqr9uH9w0fbh/cNH1Kv/ACh7 OXYtUVDDciZ9oUjjNTVhUpypvlkrMlprRno/gj/kBx/7zfzrql6Vyvgj/kBx/wC83866peldEPhR 9jhP4EPRDqKKKo6AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAGRkeWuM9O/WnZqND+7U5J46nvS7qAH 5ozTN1G6gB+aM0zdRuoAfmjNM3UbqAH5ozTN1G6gB+aM0zdRuoAfmjNM3UbqAH5ozTN1G6gB+aM0 zdRuoAfmjNM3UbqAH5ozTN1G6gB+aM0zdRuoAfmjNM3UbqAH5ozTN1G6gB+aM0zdRuoAfmjNM3Ub qAH5ozTN1G6gB+aM0zdRuoAfmjNM3UbqAH5ozTN1G6gB+aM0zdRuoAfmjNM3UbqAH5ozTN1G6gB+ aM0zdRuoAfmjNM3UbqAH5ozTN1G6gB+aM0zdTgaAHUmaKaTQA7NGaZuo3UAPzRmmbqN1AD80Zpm6 jdQA/NGaZuo3UAPzRmmbqN1AD80Zpm6jdQA/NGaZuo3UAPzRmmbqN1AD80Zpm6jdQA/NGaZuo3UA PzRmmbqN1AD80Zpm6jdQA/NGaZuo3UAPzRmmbqN1AD80Zpm6jdQA/NGaZuo3UAPzRmmbqN1AD80Z pm6jdQA/NGaZuo3UAPzRmmbqN1AD80Zpm6jdQA/NGaZuo3UAPzRmmbqN1AD80Zpm6jdQA/NGaZuo 3UAPzRmmbqM0APrG8Rf8ge8/65GtjNY/iL/kD3n/AFyNJ7GdX+HL0Z5NUF5/qD9anqC8/wBQfrWW F/jR9T4uHxIo0UUV9KdgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRSGgCSKIzEhS OPWpfsUn95aSwP71/pXawQi00WzmttHS9MwJkkdC2DnpiqbSSb6kpSlJpPY4iW3aJdzEY9qjjQyO FHU10niK4mfTMSaNFZjeP3ixFT9MmudtG/0laS1Y2mluS/YpP7y017R0UsSuBXYaNbquizXcenLf TiUIVcEhVx1xUOpXM7abcBtAhhBQ5kEJBX3zQ5K7SX4goSsm3v5M46rAs5COq1VDdK6zw3aw3mqJ HPEZQELLH2YgcA0Kyi5PoJqTkox6nPfYpP7y1XYbWIPUV3bXNwrkf8IzAMHp5LVxeoOz6jOWgEDF uYgMBfbFK9+n4l8rXW/yaCz/ANf+FXqo2X+v/Cr1eDmP8b5HLW+I9H8Ef8gOP/eb+ddUvSuV8Ef8 gOP/AHm/nXVL0qIfCj63CfwIeiHUUUVR0BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAQqcxqc546+tF C/6tc4zjt0pKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigBRTxTB TxQApphp5phoASkoooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKUUlK KAHisjxF/wAga7/65GtcVkeIv+QNd/8AXI0nsZ1f4cvRnk1QXn+oP1qeoLz/AFB+tZYX+NH1Pi4f EijRRRX0p2BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFIaWkNAE+n/AOuf6V21ndJp WlWz3l5eHz1LRQwPtCrnua43R4DPPPh0XZGW+Y4z7D3rt9KiM+lQR3psJ4BkxrLJtdB6Uptciv3K pp+0dt7GV4nmGoeHzdWt5dPCkyrJDO2cE9CDXJWZ/wBKSuw8Yo8ehrHC1lHarKP3UD7iT6muT0uE 3GpQxBlUucbmOAKim1fyNKqbVup2WiyfYtMlvLi7uYrfzNixQHBdsetSX96mq6NeiyvL5JIoi7xz PuV170mgJIbSeKR7KS1L4aKd8c+oqbWofI0O8Sw/s+CNoyZPLk3O49KKjXO+46Kl7NdvxPOgflFd d4fgln1BBDO0AVCzyL1Cgc1yA+6K7PSLe4ttRt2t7m3V2j35dvlx3BrSL92RjJe/F+ZsRa5ZXE6w JeaohdtqymQEZ7HFcJq8U1vrV3FcyGSVJCGc9/evRVtoI5BNBDpKXOch/OJAPqBXm+piVdXuhPIs svmEs6nIJrGNr+6dE1Ll97UdZf678KvVRsv9d+FXq8fMf43yPNrfEej+CP8AkBx/7zfzrql6Vyvg j/kBx/7zfzrql6VEPhR9bhP4EPRDqKKKo6AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAIVGI14A46Ck pVGI1GNvHT0pKACiiigAooooAKKKht7u3uw5tpklCNtYoc4PoaAJqKKKACiignAJPQUAFFRW11Be QiW1mSaMkjehyMjrUtABRUVxdQWkDTXMyRRL952OAKkVgyhlOQRkEd6AFooooAKKKKACiionu7eO 5jt3mRZ5ASkZPzMB1wKAJaKKKACiohd25uzaiZDcBd5iz8wX1xUoIPQg/SgAooooAKKg+3Wv2Zrj 7RF5CEhpC3yjHXmktNRs7+AzWd1DPEOrxsCBQBYoqK2uoL2ES2syTRkkbkORmiS7t4rmO3kmRZ5Q THGT8zY64FAEtFGQe44qKS7t4biKCSZEmlz5aE8tjrigCWiigkDqQPrQAUUUUAFFFFABRRRQAUUU UAFFFFABRUNxeW1oiPcTxxK7BFLNgFj0A96moAKKKKACiiop7uC2aNZ5kjMrbUDHG4+goAmFPFQQ zxXCloZFkVWKkqc4I6ipxQApphp5phoAbRRRQAUU2SWOIAyyIgPTcwFBkRQCzoA3Qlhg0AOopC6q wVmUFugJ5P0rm/CXiOfWRqf294Y/s140EWDtyo+vegDpaKRmVFLOyqo6ljgUJIkq7o3V19VIIoAW imiaJpDGssZcdVDDP5U1p4hkedEG6AFx19KAJKKoaTLdiyB1Se2ecyMAYW+UjPA+uKupLHICUkRg vUqwOKAHUVzdn4kl12y1YaWbeC5s5jDG0zgqSP4j7VvRSGO0ja6kjV9o3tuAUn2oAmopvmJs3702 f3twx+dAljZ9gljL4ztDDP5UAOooqK4nSGN8yIJNhKqWGTgelAEtFYPgzWrjXvDMOoXuxZWeRW28 AAMQP5VuRyxygmKRHA6lWBoAdRTDcQjGZohk4GXHJ9KexCqWYgKOpJwKACimpLHKu6ORHX1VgRSf aIfl/fRfN935xz9KAH0UjusalpGVFHdjgVgWeu3Fx46vNJ/dm0htUmRl6kknvQB0FFM86LzPL82P zP7m4Z/KlaWNCQ0iKQMkFgOPWgB1FIjrIoaNldT0KnIpomiaQxiWMyDqoYZ/KgB9FIrq4yjKwHGV OaFdXGUZWHqpyKAForHudWmbxPbaTZhSFjM90x/hXoAPc/0rVM0Qk8vzYxJ/c3DP5UAPorGm8Rwx eLIND2rvkhMxkLgYx0GPWtSSdNjCOaHzCCEBcdcUAS0VR0mW6/syD+1J7Z7ts7mhb5G+lXEkjlBM ciOB3VgaAHUUwzxKxUyxhlGSC4yKeCCAQQQe4oAKKKZ50Rk8sSx+Z/c3DP5UAPoprSxoSHkRSBkh mAwKrajqMWnaTcX7FXjhjMnDDDYHTNAFuisGz1a81nTdIv8AT5LWKK4Ia4jkbJ2kfdX3rbeaKNgs ksaE9AzAE0APopGdUxuZVzwMnGaRJY5M+XIj467WBxQA6imPPFGwWSWNGPQM4BNYWua3dad4m0Gw gCeTfyOspI5wFyMUAdBSisbQNXmvpL6zvgq3tlMUcL0ZTyrD8K2RQA8VkeIv+QNd/wDXI1risjxF /wAga7/65Gk9jOr/AA5ejPJqgvP9QfrU9QXn+oP1rLC/xo+p8XD4kUaKKK+lOwKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigApDS0hoGXdCmhg1AvcQCeID5kJxn8a7yEWWrW8L2+ggxxrs3 vLsAOeme9eead/r3+ldoVstQ0OxjfVEt5YVIMRBx16/WplH3U/8AP9Cqc7SktNvL82UfF/8AoWlf ZY9KS0jlkVjIH37sdga5XTmVL+JmQOoOSp6Gu2vbTS28ONYSa7CC0yyb2UkLjsK43yI7fVvKgnW4 jU/LIowGqYP3rf5/qaVU+Tm/y0+476xn0/U7P7Pa6CX2Pvb95hV4xnd/Sq2uxDTNJuWg0WOESRlD MJfMCg/yqLS2tLjw/PZ3F+to5lDrwfm47+1TW1tptrpt9FLrcR+0RFMbTtHuaU1yt7+mo6cudR21 W/uq3ytc88H3RXe+H9R0+JUhk0nz7h0KblOS2fauO1Oyt7KZY7W+jvEIyXQEAe1dP4ZuIrXU0e4l EMZjKlz2yOo96tJSg2ZtuFWK0/Bm8dMihUSp4ejLp82wXGSMe1edajcvearczyII2eQkoBgL7V2t rYWFvqSTnXk2I+7IVtx5rC8RWenyXd3f22q28skkm4QIhBrO9pLr9/6mtnKDasvK8fv0sZVl/rvw q9VGy/134Verx8x/jfI82t8R6P4I/wCQHH/vN/OuqXpXK+CP+QHH/vN/OuqXpUQ+FH1uE/gQ9EOo ooqjoCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAhX/Vr16d+tJSrzEvJPHU96SgAooooA5XW/Gk1hrE mmaVo1zqlxAgefyiAIwenWnN45gOm6XeR2c2L+5Fs0b/ACtE3fNYHiRdLm8XXZj1q48P6rFGuZmY CK5XtweuKzrrWrrUPCekanqsiyJZasqvcom1ZEHG/HpQB6HqGuCx1/TtLMJc3yyESZ4TaM9K878L eLJ9Di1mK00a71BY7+SSd4uBEuf1Nbt9rthrHxI0BNOuEuVhjmLyRnK8r0z61Q8G+KdH0fT9fh1C 6iglS8mfY/BkHPT19KAOi1Dx1bQ6Zp1xplpNqFxqIzb28fDHHXPpipdI8ZR3lnfyapY3GmT2C754 ph0XGcg964iC205fDGhxazLd6XLPLLNaX0Z2iDJyA3pkU9r3U9S0XxJow1JNbgtrdJI7qNeTzkoS OpxQB0dj8RXuLy2N5od7Z6deOI7e8k+6xPTI7Zp1t4+m1DV7mwtdDuZ47adobiZWGxAOh/GgeOdF k0jSobMR6hczmOJLRcbkPAJI7YpvgIAJ4m4AP2+TP5UAV4PHlhpGgafcW+kvFBd3MkKwxEEhgTyB 3ya0tH8bS397PYX2j3Wn6isJmhglI/fKPQ+tcLZ39tpuheFbu8/1EepzFzjOOTzXXXGqWfiL4jaL /ZEyXS2UUkk80ZyqhgABn1oA57w94mnHhTW59b0aW4tkuix81wQzFsbPwrrdX8af2bc2+naVpVxq V88IlaCAgCJMcZNcW11B/wAK88R2nnIbmPUGZ4s/MBvHOK39K1Sz8P8Aji+/taZLVb20heCaU4Vg ByM0AasXj22m8L6hqotJo59P4uLSTh0PpVW2+I3mX1kLnRby20++YRwXj42sx6celc5qVzFq1h42 1Wy5sJY44kkAwJGXGSK3/FIA8H+HuBgXNtj8xQB3W0+lcJJ8SZnuLyGw0C8vWspmScxEYVR3z/St WTwjeSa6NQXxJqaReYJPsgI8vH936Vz3hDxRo2jzeI4NQuoraVb6SQhzjzB7ev0oA2tT+IFnZaFp uq21tLdQ38nlqicMremPXPFRWfiRb3xDpcepaE9nfTJKUeZhuiVcZ/OuUt4XTw94akljMaXOstPG jDBCMTjiun8Uo03xD0eNPvvZ3Cr9SKAI7j4lMJJ57PQr670q3cpLepjaMdSB3Aq7rfjyHTG0wWVl LqH9pxl7cRHljjIFYvh3xXo2k/D6Sxv7iOG8tY5YZbVuHZyT0HfOaqaLay2mp+BoblNkghmfaeqg 8j9DQBry+Jmku78poEkWrrpvmtlh5mMkbc+3WqPgvxfd2fhfSRqOnTiK4ufs4uXkBzu6N+fFX7kF /iZqyjqdI/qaz9Hhh1r4QfZrWVJLuzBk2qcsjq2QD6UAdpc64IfE1po0cBkeaJpnkDcRqOn51D4w 1R9J8M3U0JxPJiGL/eY4H86w/ANyfEOo6j4ikUgSKlrDnsFHzfrVz4jAjw/bS4+SK9hZz6DcKAMj xppkOmeFtEguVc6Tbzob4KeWBHJPqMmoPC/9lzeLdUm8KjbpAsis4ThDLjjA+laXjyS2TWPDsurA nRhITMT9zdj5S3tVNLjS7j4gRnw0YmhFjL9ua2/1R4+XOOM9aAMjwb41l0PwyI49FvLu0t55Dc3U Y+WPLH867K/1+xbXNGMFgLya7t5JbacEZUAZwPrXK+FfFmi6f8OLy1ubiNLlPOTyD96QsSBgd+tT aTay2WteBoLhSkq2kuVPUZAOKAL3wu1jUdSXVUv7KeNRcu4mkfI3Z/1f4Vv6vqNpbeK9GtZrETXF wshinJGYsDn86yfhtdQeVrFl5yG6j1CVmiz8wG4849Kk8S/8lD8Mf7k//oNAFM/E6V7eee10C8uY bSV0upEI2xAHGff1qp468S3bt4ZudJtJ7i2uJ1mXY+3zT2Q1Z8IAf8IBrpwOZ7rPvyazLuWO28Ke BrmeRY4IrlC7scBR70AdPqvjae1vxYaZot1qN8kayXEURAEGexPrUyeOtP8A+Eam1eaKaFoH8qS1 YfvFk/uY9a4me1g/4TnXPtnie70QXLrPA0ThY50I65PpUH2W3g0CXVbS6v8AUbSLVY5bi4uVH7wL wXGOo5oA6y0+Ikz6tYadqGg3djcX0m2MSkYK4zuz/SrWreN5rbVZ7DRtFu9Wktf+Pl4cBYz6Z7ms nxF4k0nWPF/haHTrmK6dbrzC8ZyEGOhPr7VhQWUNv4i12HUPFd7oUwumlESMFWRD0YE9TQB2d/8A ECztPDNtrMVtLKktwLd4ejxseCCPUEVseH9WutYsXnvdMm05w+0RSkEsOxrzKS0tofBllJaz3dzD c65HIJrsANJzjIx2OK9cubu3tWjFxPHEZW2Rh2xub0HvQBI7rGjO5AVRkk9hXDSfE0gyXcGhX02j Rvsa/XG3g4JA64rr9Wge50e9hi/1kkDqv1xXBaZ4u0W0+GbWVxPHHdw27Wz2bf6wydMbaAN3XPHk Gk3thbW1lNfNfwGa38k8uewxUVv42m1LSdVi/sq5tdXs4izWbkbsEcMDXN2l3B4b17wgdYIhC6c6 F36RknjPpWvDeQa9461W90t1ntYNNMDzJyrOeQAe9AGV4d8RlfA2lPrWjyTqb5IoJJXB3sxP7wfT pXS6z46ktNXn0/R9HutWltebloSAsftnua41Lu3m+HXhqGKZHlt9VjWVFOSh3NwR2ro/Dmuad4c1 3xFZ6xcR2dw14bhWlO0SRkDGD36UAX7v4hWMHheDW4oJZInnEEkR4eJjwQR6il0jxw99r0Wmaho9 1pzXKl7V5sYlA/ka4i6IufC09/HGUtL3X45IAwxuXOM498V2/ijA8ceFv+ukuP8AvkUAM1Px1cw6 hc22j6DeamlodtxNGQqqe4GetZviDWYPEFt4T1G2Vljl1AfK/VSOoNYpu4tXuNWm1XxLLpQhuJIx ptrhGcDgEjqxNVtEP/FJeEx83GsSAB+v3u9AHe2Mn9k/EC908cQahCLqNewcHDY+tdWK47U1M3xV 0YRn/U2UrSAehPFdiKAFNMNPNMNADaKKKAPNPHdiD4qF3rmm32o6L5AWMWrn9y+eSQKrXklg/gvS RpN/cXlquqxhTPw8XzfcP0rpNe03Vo9efUvD+tWkEksYjntrs7k46EDsao/8Icj+FbmyfWbb+057 kXhuFICLKDkYHpQBpeKjjxd4V5/5byf+gGuX8NeCbDxK+vXGoSzkrfSrCqSFREw/i471r2uh6tda 7peqa5rlhNJZMw8qIhVCkYz9ap2/hvXtMl1E6T4h06GPULh3kV/m2KehX3oAoXH9qaz4H0vzornU bWzunivIoXxJOi8A+9T6JqWkaVo2vXHhye9tpYrbcdOugf3LdNwzz3rauPDH2LQ9Ng0HW4be+sGL iSRwUmJ+9uHvSab4cku7u/vvE+qWNxc3lt9l2W+FVU/qaAK+m/D22XTdO1W21CeDWDsnkvJJCRJn kqRnGOcVU8P+GrTW/FPiK7v2ldrS7zAquVVG28nAqaHwzq88dtpWpeI7KXRLZ1ZQmBLIqn5VJrf8 PabHo97rU0t9aMl9N5kQWQfKNuMGgDgUtpL7wnoltHO8LS61InmKeQNx6V0Unh218HeLtITSnmW0 1Mvb3MDyFg5253c96x9d0Z9L0DRdN/tKAXDaq0izQsDs3EkGum0nR76XX4NV8Ta1ZXT2albaKAhV GerH3oA4600GwsPCfjC5toSk0c7wK28nCA9K3YtKj8YeIodM1SSVtOsNOikFujlQ7sOpxUtx4YvT H4gs4dV042GpsZYwzfMjk9/arWoaBdQ3Vnqfh/WLK31GK2W3nWUgxyqOlAGJfwP4esfFmgwTySWM VotxbrIxYxZ6rn0pt94Yg0PQdC161uLn+1GlgEszSE+YrYypHTFbCeFZJNB1r7frFpc6zqqbHl3A IgHRQPStPWNJXUfDGnabFf2iy2rwszFxg7MZx+VAE954zNprh07+xNSlHmBPPjjzHz3z6VzemeGr fxm+s6vqk9x9qjuJIbYpIVEAUcYAr0L7faD/AJeoP+/griLnw/qVnqV7/wAI/r9lbafqDF545cM0 bHqU+tAHLC+nsfhxoWmr9pkju72WOcW3+tkVWOQv1q94bdNP8W6eNA0TWLC1nJju0ucmMgjhue4r Zt/ByxeDrHTl1i3i1PT52nt7pXBAYsTyPcHmrmkafq02sw6h4k16zlW1UiG3tmCqSR95vWgDA8O+ CbLxJb6xdalNcMyXky2wSQqISCeRjvms6+1+7vfD+g6bei9uoWllS5W1P72dYzgD/GrHhy11u4TW Do2uWdpBcX0qSpPglRn7yV0l34StodF0yLRdXgttR0wlorh2BDk/e3D3oAw/CcgsfFUcOjaRq1hp lxC4uI7vJQMBkMM1S0rwlaan4A1DV7qe4N7btO9s6yECHaSRgV1+i6dqTaq2p+I9ctJ5liMUMFuw WNc9WI7mnaToosPBF7o0l/aNPOJgrhxtG/OP50AY0kT+L7/w5pOpTSGzbT/tU6IxUzNwACRUdhp6 +EPF/iAWUkjxw6WJYVkbcYxzhc+grTvPDky6fo8+lavZ2+r6ZCId7MDHIuOQRRonh2eLXNQv9d1e zuzf2ohlCMAFPOQB6YoA4KDyLrRxff2P4gl1yRfNW/Unbv6jHbbXUXNg/ifxnocGqmaFZtL3XMSs VLkdjj3qwnh3X7e0/sa38T2KaNnar8eesefug1uppEMPi6x1KO/tja2tkbba0gLsfWgDnrDf4Q/4 S+y02WT7NZwrLbJIxbyyw7Zqzp3w9tv7KsNWt9Qng1htk8l5JISHzyVIzjFa66Lazazrs93e2rWm pwpEEWQbhgYOaw4vC+rzw2+k6l4jspNDtnDBUwJZFB4Un0oAlTUT4TuPFdqx42i8th6lxggf8Crq fCOmnSfC9jbPzKY/MkJ7s3Jrk/GllZap4x8Pww3cQJ4uFDjBiU7hk/UV6Gjo6gxMrJ0BU5FAHJ+G C1z4t8U3DH96syQqT2AU4rgns9PsLqb/AISu31ay1Q3BZNWiZmTG75cdgMV3+mw/2b491e1kBEWp xLcRn1I4YfXkVlT+DfFD2s+jprNs+jTMctNHumVCclQaAIJ/D+mX3xYsJ5EM5kshcebvI3uMYb8q r+FfDVnqLa5qt2ZXuLW7n8gCQhU4PaujvvC+oQa9pGoaLcwItnALWVJlzvj46e9WvDvh240jT9Wt 5pI3a9nklQr0AYYGaAPPbS0Oo6B4GtDNJEs88qOyNhtvcZregsYfBHi/UINJaVbR9La5MDuWAdT1 Gavab4IvrO28MRvPCTpMzyTYz8wPpWvqGhtJ4ok1idlNkLBreSMDLHJyf0oA4W78GW9x8OZvEMl3 cHV57c3Elx5pwwPJTHTGK9L8PnPh3Tj/ANO6fyryfUUvP+EDuYrPxHbSaDyLeIpi4PPEZH1r0NLq +06Hw3awGMJMoSeNly2AuePSgDT8SX0umeG9RvIP9bDAzIfQ44rgZ/BFtbeCh4giu7ka4kAuzd+a fmb72COmO1elX1nFqFjPaTjMU6GNh7HiuE/4QnxNJYroc2twHQ1O3IjPnNHn7maAKT6anjHxtYC/ kkW3l0lJZ4kYr5h9DjtmmzaPDp8finw2Xlm02K0F3bxu5JiPPGfTirGr6bf/APCybeHQLpLS4ttN AjEi5RlHG1hW9o/hG5hs9Vl1i8W51PVIyksqLhEXGAoHoKAOSs9NtdL0bwQ1pGU+0XKzS/MTubbz WhpHhS08bnU9W1uW4knNzJFbhJSotwpwMAd6uWHg7W1tNEt9QurSRdKut6FFI3RAYA+tPufCfiLT b6+/4RnVbeCyvnMkkU8e4xMepU0Ac1ezXepeEtFs57uQzQ6ybP7QD8xUHAP1xW9baDbeEviJpkWl PMkF9BJ9ojeQsHYfxc96uSeBHh0jRLG0uVY2N8t3PJJ1kOcsfrWvqehzX3irTdSV0EFrHIkin7x3 DtQB5lqkel6jNqcr2Wq67qHmOVvICyRQ46Be2BWxp13LfP8AD2ed2eUmQMzHJOARzWpaeDfEdlb3 GkQaxbx6NIzkFYv3wDfw5qxpvgq9sx4YV54SNIeQyYz84bOMfnQBYR/s/wAWJY04W508M49Sp4P6 11wrlNJQ6l4+1bU15gtYls4z6t1b+ldWKAHisjxF/wAga7/65GtcVkeIv+QNd/8AXI0nsZ1f4cvR nk1QXn+oP1qeoLz/AFB+tZYX+NH1Pi4fEijRRRX0p2BSHgUtIehoA6n/AIROwhtreS91yC2eeMSB GQ5ANZuu6A+jeRKs8dzazjMc0fQ10mseH11W10uY6lZ2uLRF2zNgn3qOZrAXGg6FFOl6sM+ZnHKH PYVyxqPR3v3O+dGOqtbazucRWlNpBh8PW+q+aCJpmi8vHTHfNbGlWNrL45u7aSBGgVpcRkcDHSr9 ve2WneBrWW7s1uyLuQRRP93Pv+FXKq7q3kZU6Cabk+/4WOV0XTDrGqw2SyCMy5+cjOMDNJPYwQ2L S/bEa4WUxmDHOB/FXYWFrZnxNoepafD9nivFctCOisBziqK6dZTaDBLcIiNJqbRyTY5256Zpe11/ rzK9h7vnr+n+Zx+a0tQ0g2Gl6feGUMLxCwXGNuDiut12zt7SC5hm8OhLRV/cXdsdzexY1FNqVjpn hTQpLqwS9laNgqyH5VGefxo9s3ZxQfV1HmUn08+5wtFd4vhmxufFRaK3JtPswuRbKepP8NLqei/b tEvZbjQ49Lltk8yOSNuHA7H3p+3jdE/VZ2b/AK0OCzS12WszaXpOjWES6XDJc3doGaQ8FT6j3rja 0hPnV7GNSnyO17hRRRVmYUhpaQ0DLekTtbzzFAp3xlTuGeK7i3j1OLRbF9Otop0dDuLRKSDmuC0/ /XP9K624DWfh+zMHntJON5lVztTB+6BQ43jH1CMrSk+y6fIq+K31dtHxf2ccMPmL8yxhTn6iuY0u ZrfUYZUClkOQGGRXT+IALzwml0ySwyRSrGQzErL7gHvXK2X/AB9JUR+K1jSpdRvfod9oqXraJNPp 8Mc0vn/MjRqcDHXmodXfXTpN0LiwiSLyzvYQqCB9ai09BB4eubpVmklL+WoRiBHx94gUiFr/AMN3 8c6zrJBEZBOXOG/2SKJqzlKy3/rqFN3UY3adu+n5HDD7oruvDskt9qkS4jDpAVQeWCDgcZzXCj7o rsfDlst1qSK7uAsZfahwXwM7RVJLkkQ2/aRS7m1v8RBsf2bD1/54rXA6kZzq1ybpAk2871AwAfpX X2N9JLrDJJbXDQzNsEYdsx+4NcnrFuLXW7yESmUJKRvJyTUW5ZWaXyNL80XJNv1/4YSy/wBd+FX6 oWX+u/Cr9eLmP8b5HBW+I9H8Ef8AIDj/AN5v511S9K5XwR/yA4/95v511S9KiHwo+twn8CHoh1FF FUdAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAEKnManOeOvrSUq58tc4zjt0pKAClpKKAOA8QX19f37 xXXgUajHCxEUzsp3D1FI3iHW3sPsTeBGNrt2+SXXbj0xXoOT60ZPqaAPN7TU9SsPK+x/D3yfJJMe x1G0nriopLm8lYNJ8OEZlcyAll+8epr03J9TRk+poA8+vfEGt6la/Zr3wG88H/PN5FIpNP13WdKt zBp/gJreI8lI3UA16Fk+poyfU0AebWmpajY3rXlr8PBDct96VGUMfxqzbeI9ds/O+zeBZIvPYvJt kUb2PUmvQMn1NGT6mgDyXU2128m0v7N4La3trGdpWgDrtfI5GPxrW07W9X0hXXTvAJtlc5YROq5N eiZPqaMn1NAHmr31/LNcSv8ADsNJccTMWXL/AF9alv8AWNW1WBIb/wAAG4ij+6sjqQv0r0XJ9TRk +poA88GuawNNOnjwEwsyMGEOu3H0p83iHXLmCKCbwLI8URDRo0ikKR0I+legZPqaMn1NAHD/APCZ eJ/+hNuP+/wrmNMg1e3a8bUfA325p7prmMyMpMee1ev5PqaMn1NAHn9x4h1y6EAuPAjyCBg0W6Rf kI6EelLJ4k16a8iu5PA0jXMIIjlMq7lB64Nd/k+poyfU0Aea3GoX91fC+uPh2sl0vIlZlLVJF4t1 nUZYb3/hCWllgJWKUSDKeoFeisflbOcYNZ2gyQPp7G1Ro4/MbhjnnPNAHJDxHrovmvP+EGk+0snl tL5q7ivpn0qtFrGt2EF2NL8CG1luQd7I6gFj3PrXpGT6muc8QeN7Lw7qUdjcwXM08sXmRrCu4vzj aB60Ac/4Mv8AXtIs7HSJfC80UO/97cGQYBJ5bFdnrunwapot3Z3LqkcqFd5ONp7H86zNM8cWGq6T fXiRXEUlipae1mXbIvGelYd9490XXNBuTdaXqD6eqo5crtV/mAAB9jigDqNKtm1Dw5Bba1aI7qnl yxyAMrY4B/EVa0/RtO0mF4dPsoLaN/vLGmAfrWNrfjaw0F7e0S1u726kiDi2tU3OqY4JpU8d6XL4 Yn1uMSmG2bbNERiSM5xgg0AXm8N6DFJDI2mWSPEf3TFANpJzxV+WxtpruG6lgja4hBEUhHzJnriu NuvGOj63FateaXqAiW8jWB3XYGY52sPUVR07xxcp408QJcWGoy28CZRNvEYXr9M9qAO7g0jT7W/l vbezhiuphiSVFwz/AFNSzWNrcXUNzNBG88GfKkYcpnris268UWdr4Zi1srI9vMqFEXG4lug+ta6u DEJG+Qbdx3dvrQBBBptna20lvBbRRwSkl41XAYnrn61DdaVpT6YtleWtsbFOFikA2L9K5uT4o6TH dsv2S+ayV/La/WLMIOcdawPiFrEF/wCLNF0y4sL+70/BlZbccXGRxtI6470Aeg3egaRqVvDFd6fa 3EMQxEHQEKPaqfiPT71PDTW3h2OCOWIgrAyDZIg6pj3Fa8ZhtLFT/qoIowfm/gUDv9K5D/haOmee pOn6kLFn2C+MP7o84zn0oAztD0K/1LxBYXMnh220KxsXMrKhBaaQjHbtXb6joOlau6vqOn21y6fd aVASKvK4dA4bKkZB9q464+J2l295In2K/ks4pPLkvUizCpzjrQB1E2l2NxbxW81pC8MLBo0K8IR0 IqrrmlDVDZFzEqWtws7O45Xb6elJH4itZfEUekRq7SyWv2pZRjYUzj86x/FOuQ3uieJtNjSRZrK1 +dz0O4ZGKAOtVg6hlIKnoR0NZ0nhzR5tQF9Jplq12DnzjGN2a43wt8Q9NttJ0iwngvEiMSQ/bGjP kl8dN1buu+OrPRdRNjHZXt/cIoeVbSPd5SnoTQBFrOhyal490y4mtFn09LSSOYuAVyTwCK6Kw02z 0u2+z2FrFbw/3I1wKy38Z6QnhldcMzfZHO1V2/OX/u49apaX8QLDUvtSSWd7ZXFvA1wILmPa0iAZ ytAGt/wjuiW4d/7OtI1aUTMdgALjo315qXUND0rWGR9RsLa6ZfutIgJFcjdeP9G13Rbrz9M1CSwE QkaTbtVuR8ob1BNaOoePNN0S4j0/7JdzT/ZklhihXczqRwAPUYoA6KfS7G5to7aa0heCJg0cZXhS OhAp1xbWk11bzXEcTTxEmFn+8pPXFcfrPjuG98B6nqGlR3S3MSmJ49mJLdj3YdgKj0bXrHUrbws+ pWF6t8+Y4Hl4+YKMufUGgDrJNA0mXURfyadbNeD/AJbGMbvzpw0TTVWNRYwBY5TMgC/dc9WHvXPa n8SdM0/UJ7aOzvryO2bbcXFvFujiPuavap420vSrDT71y8ttfnEUkQz2z0oAfo+mzv4i1PWL2PY8 pEFup6iNe/4muiFcz4e8bWXiDUZrAWt3Z3ca7xFdJtLr/eFdMKAFNMNPNMNADaKKKAOY1D4c+HNU v5by7sneeZtzsJmGT9KrN8K/CgUn+z5OBn/Xt/jXYUjfcbPTBoA4TSfhz4V1PT1uTpkiZZl2+ex6 Grn/AAqrwp/z4Sf9/wBv8a39AeCTSUa1jaOLe2FY5Oc81o0Acf8A8Kq8Kf8APhJ/3/b/ABo/4VV4 U/58JP8Av+3+NdhRQBx//CqvCn/PhJ/3/b/Gj/hVXhT/AJ8JP+/7f412FFAHH/8ACqfCZ66e/wCM zUv/AAqnwp/z4Sf9/wBv8ab8S2u/7I09LGdoJ5L2NFdT0zWdJpU/gbxDpU9tqV5dW9/KYbqK4fcG bGQw9KANP/hVPhT/AJ8JP+/7f41Sv/hfokU1qLDRxNG0mLgvdMpRPUc8mqWm+Hbrxta3muXur3tv OZpFs0gk2pCFOBx36VGutXupad4UkupW+0LqLW8zKcCTbxk/WgDe/wCFU+FP+fB/+/7f41l694H8 G6Bb28txpsz/AGidIECzt95jj1rP03w7P4lHiGW51a9hjtbyX7NHDIVCsOcn1+lVPEEDeIfAnhi8 1GeZrg3aW7ur43Atgn68daAOvPwp8KD/AJcH/wC/7f40n/CqvCn/AD4Sf9/2/wAa5rxXBDY+Ils9 futXg0WG3VbSW2ZtobuXI6mu58GsG8OQbNVGqRgkJc9yvYH3FAHMzeBvBsPiK30Y6bMbieJpg3nt gKPxrT/4VT4U/wCfCT/v+3+NZGteH7W6+L1pNJLcgtatcELIQMr0A9uOlR6b4duvG1nd67e6ve29 w00gs0gk2pCEJA479KANr/hVPhMdNPcfSZqX/hVXhT/nwk/7/t/jWh4H1W51fwvbz3zBrmN2hkYf xFTjP41xXi54v+Evu18T3eq2dgFX7DLakiJeOS2O+aANjUPhfokUlqNP0cTI0uJzJdMuxPUc8mrv /CqfCn/Pg/8A3/b/ABrK1C4lXS/CXl6qb9Wvwv2lDjzVxwD71UsvD03ijWfFK3OqXsEFresIY4ZC uGxnJ9h6UAb/APwqrwp/z4Sf9/2/xpf+FU+FP+fB/wDv+3+Nc/Dquqax4X8PaOb6SOfUJ3hmulOH MaE5wfU1Zs9Dn8NfEfSLKHUbq40+WGRkjnkLFW4zz3oAi8J+CPDPiLTri5m0kwtDdSQBUuHIIU4B rc/4VT4U/wCfCT/v+3+NcUmuS6T4Me3iuJbYXusTRyTQrudE3HO0etW/Der2em+KtPg0C81e5trt zHdRXiMQPRwT0oA6n/hVXhT/AJ8JP+/7f40v/CqfCn/PhJ/3/b/GtPxtI8XgzVXiYq6wEqwOCDXE 3Gg3+heGLTxRHrF5JqMaxyTI7/unQ9V2/SgDov8AhVPhPr/Z759fPaul0rSrTRdPjsbCMx28f3VL Z/U1wHjS+srrWYU1nVruOza3V4rHT93mlj1LkfpWNaavdP8AD/xJbwXN6Es7iNbU3WRKik9DQB63 cafb3Vzb3EyZltmLRsDgjPX8KsV5Zr8Ung/w/ZLHql+ZNYkQXU5JdkG3LbB2zUXhnV7PTvFmn2/h +81e5tbtzHcxXqMQvHDgnpQB6x+VZmta7Bohs1nRma8nEEYX1Pc155pXh248R2WvXFzq97ELS7mN skUhAVgM5PrVfXLU+JPDng+81GeczzTrA7I+3I9fr70AevUYzwcc9qhit/slisEBZjFHtQuck4HG TXj1pLbm/La1req6V4iFwcPNnyCN3AA6YxQB6MngLw4mqnUV0yL7QW38n5Q3rt6VP4u1hvDvhq71 aGCOaa2UFVfpycVk6fNK3xWv4mmLxjTomAB+XPqBXOeI5JJdF8eRs7MFmiCAngfSgD02ynN1YW9w wCtLGrlQemRmpq8wudCvfCmk6b4hh1e7mug0S3Mcj5jdGwMBe2M1X8UywyeK7z/hKL3VbKz2qbCW 2JESgjqcd80Aemf2Taf2v/aflf6Z5fleZn+H0xVuvPNQnvb/AE3w5odrrbTLqJbzdQh4Z417D35p 2o+Gb7wroetNY6nPNpj2hKxzyFpI5PUH0oA7TVpdQhst2k28Nxc71GyV9q7c8nP0q6Og6V5LqWiy 6T8PoNV/tO9mu7xrbzd8p2jLdh2rUn0OfxL8QdYs5tRurewigiZo4HKlmxxz2oA7fXNXh0HSJ9Qu VZooQMhepzSG6v5buxa1tomsZo908jPhkOOMDvXmOt208vgzX9H1G7nuDo9yhglLYZkboG9cVsi3 Gga54Wtread4FtZZGWSQsWO3PNAHo1JXmWneGb3xVos3iK61m+h1GVnktlikxHCAeBt79Kgur/Uf E0ng5ftslrLeLNHcSRHBO3gke5x+tAHpljYW+m2/kWkeyMsWPOSSepJqyK4bwxZTeHPHV7okV7cX Ng9qLhFuH3sjZwea7kUAPFZHiL/kDXf/AFyNa4rI8Rf8ga7/AOuRpPYzq/w5ejPJqgvP9QfrU9QX n+oP1rLC/wAaPqfFw+JFGiiivpTsCkPQ0tFAG34lvbe9/s77PIH8q1VHx2b0rO0q7FhqtrdMCVhk DkD0qpS1KilHlLlNuXMd7bXHh6x1+XVE1JpWuQ5WPZjyyw5yao2sujah4Vg06+vvs063MkisFyBk 9/rXH0Vn7HzZt9Zf8qt/mdtDremW3iDSLe3mP2GwVlM7D7zEcnFU/wC1NP8A+Ecit5283F+0rxDg lCetcrRT9ihfWJdv60/yO9h1LSdIiuprbWZri2liZY7FgTgkd/pXP61fW9z4f0WCGQNLBGwkUfwk msKiiNJJ3uE8Q5LltodufEdhDrMO6VmtZrJbeWSP70Z9R9KqajJpVjpVykerXGpXEw2xLkhUHqfW uTooVFLZg8RJp3Ru+Jr63vY9KFvIHMNoscmP4W9Kw6SlrSMeVWMpzc3dhRRRTICkNLSGgCbT/wDX P9K7vRILqC3s4YL5kkvDvERTcqoOrc9+K4TT/wDXP9K7zS557bRYzdXltapIpWB2TdIFPXHoKVS/ s1Yqjb2zb7f12M3xkUv9Ka5gvJpktphEySKAMnuMVx9n/wAfSV1XieOSLw1ClpPBNYrKN7xrhi/+ 1XK2f/H0lTT0aRdZ3i29ztNDSa2spLuK7eFpHEMUaruEj+49Kv8AiRDc6deWP2+V7i1i8yVAgWNv UcelVvDctxbWks7TW8VorjDTLuw/qo9aTUg/9h6i+n3sF00gL3LhcSbfb2qanxt/1+RVFpUku/8A W1/0PPx90V1mhWkl3fxiOYweWvmNIOqgDnFcmPuiut0AXTalD9iKiTbyX+7txzn2rWPwyMJ2dSN+ 51K3jCyjmudRnC3chjgZIlD46bjXm2p2j2Or3VvK2545CC3r716G00NzqELx6jZSTQrsggMREan2 /GvO9RFwNWuvtmftHmHfn1rGCszqqO6/p/qx9l/rvwq9VGy/134Verx8x/jfI8yt8R6P4I/5Acf+ 83866pelcr4I/wCQHH/vN/OuqXpUQ+FH1uE/gQ9EOoooqjoCiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAhXiNeAOOgpKVRiNRjbx09KSgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooARvutnpg1naCLYaefshcx+Y33+uc81ot91s9MGs7QY4ItPZbaUyp5jHcRjnNAGlXD6xd2Vn8W tKe+eOPdZOsTPwA2fWu4ridd0GPWviNZLfWRnsDYursR8obPHPY0AZupzQX3ifxRcWDLJDHpPlzy IcqZOoGe5xRrCqnwNtQoAHlQ8D/fFdrZeG9K07SZdNs7OOK0lBEiL/Hnrk06bQNOuNEXSJbcNYoF AizxgHI/WgDlvD91a2Hj/V1v5I4Z57aBrd5SBlAvIBPvXOa1JBeWXji6sNrWTvCm9Puu4PzYr0fW PCuj6/HEmpWUc3kjEbdGUemRTv8AhGtJGiHSFso0sG6xLwDzmgDmfGihdB8MKoAAvLfAH+7U+hiN /iH4ot5nUeckYCE8sCMdK6W90ax1CC2huoBJHaurxAn7pXoarXuiaZHqZ19rIvfwRkh487mA7Y70 AcFpQkvNX0/wlICV0y+knlB7xr8yfzr0bXY5JdA1COEEyNA4UDrnFc94PtJtQ1zVPEt3YyWT3gWK GKUYcIvc/WuvoA8+0/WNFj+ERjkmt1VLVopISRu8zpjHXOar2McsOteAY5wwkW2lyG6j5a6qTwL4 dl1T+0H0uE3O7eT/AAlvXHStO40mzutRtL6aENc2gIhf+5kYNAEPiS8Ww8OahcvAJ1jhYmI9G46H 2ryjX1vm8CrdXniW3EEqIYdNs0AXr9314r2eSNJo2jkUOjgqykcEVz8HgHw3bLcLDpcIE4IfOTx7 elAGvpzf8Sa1ZhkfZ0yPX5RXmJkm0jSb7UvDWvWsumJI7y6ZfKMg5+ZR3zmvVoYkt4Y4ohhI1CqP QDpWHceBPDt3qZv5tMha4LbiecE+pHSgDn7XUYT8RtKvrpo7VbvRgVVztAOc4/Ws67vYL+Xx7Nay CSP7Mq7l5BIXnFd5rPhnSfEEUUep2Ucyw/6vsV+hFNi8LaPBBdQw2UccV3GIplXgMoGAKAOJ1LU9 Kn+DtpbW8sDzSQxRRRKRu83jt1zmpLq0dvENzLouvrpmsR28S3cFyo8uXC8HmuqtPA/h6y1CK9t9 MhW4iUKjdQuO+Omal1rwjoviGdJtTsUmlQYD5IOPQkUAcJLrZ1PRtA1DU4beKC21Ro7h4VxExHAf 6E103iXWtHnupbSKOO61BrCd0niw3kptPU9s1vnQ9NOkf2WbKH7Bt2+Rt+XFVdM8IaJo9tcQWFhH EtyhSU8kspGMZPagDjpUVPgNbhQAPsyHj/fqxp95Y2nxNt/tkkUcj6REIXkIAz3GTXYtoGnNoS6O bcfYFUIIs8YBzXK3nhe21b4hTxX9gZdOGnoiMwO0EE8A+tAGXfyRX83jq508q9qbVYy6fdaQDnFT yyLPL4BMTq+IiuVOcHyxxXc2Whabp2ltp1paRRWbAhowOGz1z61TsfB2i6abb7JZiP7LIZYfmJ2M RgkUAc94G1PS7DwnfwX08EM8E8/2tJSAxJJ5IPWudsYc6J4NEkZ8qTVpHjVh/ATlf0r0HUvBPh/V 9Q+232mxSXHVm5G76gdav3Oi2F21kZrdT9hcPbgcCM+1AGDfqB8WNNIABNhJk/8AAq7AVRfTLWXV Y9ReIG7ijMaSeinkirwoAU0w080w0ANooooAKRvuNnpg5paRvuNnpg0AZ+gC3Gkp9jLmHe2N/XOe a0aztAjgi0lFtpTLHvbDEY5zzWjQAUUUUAFFFFAHE/FNZX0TT1t5PLmN/GEf+6c8U600TxFrWu2V 14m+yxWunEtFHAc+c+Mbj6fSuk1nRLTXYYIrzzNsEyzJsbHzDpWhQBwI0Txd4fa8sPD5s59OuZGk ikmOGt93XjvU58FXVlY+HbW1YTGxujcXMjHG4nqR+NdvRQBzPhrQ7zTLbXEuVUNeXUksWDnKsOKy Ljwjqp+H+n6fCkJ1GxuBcKjN8rEMTjNd7RQBxN9a+MYrv7ZaRWl3HdRL51jcvlYHHUqfStbwX4fn 8O6LJBdtGbi4naeRYhhELdl9q6CigDlNf0jVj4u03WNKhhnSOJredJGwQp6kVlroni7w/wDa9O0A 2c2nXMjPFJMcNb7uox36139FAGV4Z0QeHtBt9P8AM810y0kn95yck/nWFrFh4qtdWupNKW01Kwu8 HyLw/wCobGOPb2rsqKAOBh8EX9npWg2yNFJJa35urjbwqg9QtbfhvRLvTL7xFLcqoW/uzLDg5ypG Oa6OigDza50G50nw5o8T3cFprVteO9oJOUlLEnYT2yKSyOt3PxS0uXXDbJOtrIRbQNuES8ck+9dz rugWHiOwNnqURePO5SpwyH1B7Gqfh7wdpfhmSWWyWaSeUYaaeQu+PTJ7UAc1B4G1MeHWRHig1S31 GS8tWb5lIJ4B+orS0ix8U3+tW11rn2WxtLXJ8i15M7erHHT2rsKKAMHxz/yJOrf9e7Vydho3irXt B03Sr6W0XR9kbvcqf3kiDkLjsa9A1PT4dW02exut3kzpsfacHFSWdrHY2UNrDny4UCLuOTgUAcbf aDr+l+KrnUdAt7G5hvI0RvtPBhKjGR7VQbwVrn9k+IreeSO4udRmjlSQfKCR1GO2K9HooA5rxJ4c utV0fTzYypDqWnsskLOMqWAwVPsaq6PY+Kb7W7e71z7LY2tqCRBa8+c3qx9PauvooA5jwzoN5pel 6zBcqoku7iaSLBzkMMCsi48J6wngjRbW1jhbUtNnE3lu3ytgnjNd9RQBBB58+np9qUQ3Dx4cIc7G I7GvP77w54vv7GTQ7tdPu7NmwNRm5lCZz09a9HooA4rVNA13S9etdU8OC3uWFotpNFcHGQOjZrPf wZrk3h/xNb3TxS3uqSRyIynC5HUfQV6LRQB5+vh7xXqy2Gla09oml2jI8k0R+efb0GO1XNW0/wAV WmqXR0pLTUtPusFYbw/8e5xjj2rtKKAOBXwLqOn+HtLOm3EP9sadM867hiNt5+ZPpSzeHfEmuW+p 3msmGK5ltDb21pC52LnqSfWu9ooA5DXvDd/qHgCx0m3RDdwmAuCePlIzzWLKdei+JOtTeHxBLIlv EJIJzgOMcEH2r0ms+20S1tdau9Vi8z7TdIqSZb5cDpgUAcuvgvUJvCWsQ3k8Umsao3myMPuKw+6o 9hT7fQ9avtV0C81S2hiNnFJDcLG+RgjAI+tdrRQB56mheMdFtLjRdHezl06Zm8q5lJDwK3UY74rQ i8HXGn6l4WFqRJbaWsgncnBJYdcfWuyooAwE0i6Xx9JqxVfsjWQhBzzuznpXQCkpRQA8VkeIv+QN d/8AXI1risjxF/yBrv8A65Gk9jOr/Dl6M8mqC8/1B+tT1Bef6g/WssL/ABo+p8XD4kUaKKK+lOwK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigApDS0hoGaHh9rNL9zqEcskOzpG2Dmu6MNjq WnWypo+oSQxgiKQMM4z0zXnenf65/pXWWWnTTWcci6xDArDiNpWBX8KUorlUr2+/9Bwm1Jx5b/d+ oeK4orPwube3027tladWaSU5DH0rkdKMI1OA3Ks0IPzhTgke1dT4mlEHhj7JPqK3s5nVkCMWCDvz XI2X/H2lRTWprVa5dO3l+h6RZf2ZeaZJb2uk381v5m7IcHa2O1QX1rBp2h6h9n0m+ieSEqZZDkKK ytKspbm3do9TitQGxsaQqT78Veuj/Z2hahHd6vHcrLCVSJHLHd60qkbNpO/lqFKfMlJq3np/w55+ PuivQ/D9zpkckX2ewvZrvy8Oqv8AKwxzx6V52Puiuo0uBri5VEultjt/1jMVH5itFFSi7syc3Ccb K51UOl2UN2s66HqJKtuClhjNcBrkjS6/eu6SRs0pJWT7w+tdpZ2c9ndRzN4ggCIwLYlY5HcYriNX nhudcvJrfd5TykruPNZL4t7/AH/qbNrk2t936BZf678KvVRsv9d+FXq8fMf43yPOrfEej+CP+QHH /vN/OuqXpXK+CP8AkBx/7zfzrql6VEPhR9bhP4EPRDqKKKo6AooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKAIV/1a9enfrSUqnMa4JPHU0lABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAjcq30NZ2g26W2nlI5lmXzGO5enXpWi3KsPUGs7QbVrPTzGzo5MjNlDkcmgDSpc0lFABRRRQ AUUUUAFFFFAB1ooooAKKKKACiiigAooooAKKKKACiiigAooooAKXNJRQAUUUUAFFFFACinimCnig BTTDTzTDQA2iiigApG5Rh7GlpGGUYeoNAGfoECW2kpHHMsyh2O9enWtGs3QLVrPSUhZ0ch2OUORy a0qACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigApRSUooAeKyPEX/ACBrv/rka1xWR4i/ 5A13/wBcjSexnV/hy9GeTVBef6g/Wp6gvP8AUH61lhf40fU+Lh8SKNFFFfSnYFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUhpaaaBm14QtobjVJmuI/NSGFpfL/vEdq6LSUgkS/wBcubaM RwjEUWPk3npXIaHeTWN+Z7d9sijg1uX+vXeowpDKI0hVt3lxrtBPqaShKW2z/r8RurCG+6/Pp9wu vTDVfC7301vFHPFcKgeNdocHtj2rA8P2yXmvWdvIcJI4U/StHxDq81/p0UGyOKCJhtjjGBn1PvWL p8jRX8TxsVdTkEdjU8jTtt+hXtIyjffv5nd2Vrbar4gcPaLBZWSsXUDqB6/Wobm9TXdO1RJLSCOO CEyQvGm0pjoCe9VrnxLfXVo9uxjRZOJGRAGf6mqd3rE39hPYxJHFEV/eMo+aT6mqdKbV3+exMa9N Oy+em/ZfI5YfdFd3dW8Vvp1hY29sjzXaK7TkZOT2FcKPuiux0/xHe2FpHDH5TBB+7LoCU+hoipPW ITlBaS6m1eXMGk6lb6Pa2kEsY2pOWTLMx681wutWsdjrt5bxHMccpC1vWWtT2c804SOS4lOfNkGS p9RXLTO0t1K7kszOSSe5pOm4NX/4dlKtGonb/hl2LNl/rvwq9VGy/wBd+FXq8PMf43yOKt8R6P4I /wCQHH/vN/OuqXpXK+CP+QHH/vN/OuqXpUQ+FH1uE/gQ9EOoooqjoCiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAhU5jU5zx19aSlX/VryDx1HSkoAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKAEYZVh6g1m6Bay2enNHMAGMjNwc8E1pNyjfQ1meHoJrfTmS4VlfzGOG9M0AalFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAop4pgp4 oAU0w080w0ANooooAKRxlGHqDS0j8o2OuDQBneH7WWy0hIZgA4djwc9TWlWZ4dhmt9HSO4VlkDsS G64zWnQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFKKSlFADxWR4i/5A13/ANcjWuKy PEX/ACBrv/rkaT2M6v8ADl6M8mqC8/1B+tT0yWMSptJIHtWFCahUjJ7JnxUXZpmbRVz7Cn99qPsK f32r2v7Qod/wOn2sSnRVz7Cn99qPsKf32o/tCh3/AAD2sSnRVz7Cn99qPsKf32o/tCh3/APaxKdF XPsKf32o+wp/faj+0KHf8A9rEp0Vc+wp/faj7Cn99qP7Qod/wD2sSnRVz7Cn99qPsKf32o/tCh3/ AAD2sSnRVz7Cn99qPsKf32o/tCh3/APaxKdFXPsKf32o+wp/faj+0KHf8A9rEp0Vc+wp/faj7Cn9 9qP7Qod/wD2sSnSGrv2FP77UGxT+81H9oUO/4B7WJBp3+uf6VoVTSP7KxZTkkd6sxszxhuBmuvDY unV92G5lV958yINR/wCPb/gQqnZ/8faVblJuV2NwM9RTEtxC4dSSR2Nc88woc97/AIGkGowcWXqi uf8Aj2k/3aWGRpQTgDBqKWRn3xEDB4yK6p4ulGmqj2ZjGL5jL/hFbi/dX6CqH2JAv3mqyk7GRUwM etc9DHUXLlT1fkbVmp7E461jt/rn/wB41qSyNHg4BzVZbRXYsWOSc1eJxlKnLkk9SaTUbtiWX+u/ Cr1QxWywtuDEnHepq8LGVY1anNHYzqSUndHo/gj/AJAcf+83866pelcr4I/5Acf+83866pelOHwo +vwn8CHoh1FFFUdAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAEK/wCrXgDjoOlJSqMRqMY46elJQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAI33G+hrM8Omb+zW+0b9/mt9/r jNabfcb6Gszw9PNcacz3DMz+YwyfTNAGpRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAKKeKYKeKAFNMNPNMNADaKKKACkf7jY64NLSOcIxHUA0AZ nhzzjo6fad/mb2zv64zxWpWZ4dnmudHSS4ZmkLsCW64zWnQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFKKSlFADxWR4i/5A13/ANcjWuKyPEX/ACBrv/rkaT2M6v8ADl6M8mooorjPiQoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAjaMP1p6rtUL6UtFe9lPs3F2Xv L8h3I/JC85oMeeDUlFediZUo4j3F7q/HuHMxsaeWCB3ppiBYtmpKK9nEqhHDXavFbBdjNvFIsIVw 2akoryct9m6yjNenqF2NdA+M9qFXbTqK6c29mpJJe8wuFFFFeMI9H8Ef8gOP/eb+ddUvSuV8Ef8A IDj/AN5v511S9K64fCj7LCfwIeiHUUUVR0BRRRQBy3jjVJrGHTraO7NlDe3Ihmuh1jXHY9ifWksd J1DS9UtZtM1Oa/02TIuUuJvMK8cMp/pVvxNe6WrWema1aiW11BzGHcDYrDpk9ie1cxc+Hrbwh4m0 WXw9dzxi7uRFNZGUujxnqwHbFAGjpPj1JJtel1KK5htdPl+VjAQFQDv75rVTxrpTabJfObiKFWCJ 5kJUyk9Ng/izXH6lg+HPHI/6ehx+C1oeMIrldQ8Ji1uIrSNXKrJIm5EfZ8uR0+lAHU6R4msNYM6Q mWGaAbpIbiMxuo9cHtVBfH2jtcIn+lCCSTy0ujAwhZs4wH6VjPBNYeILi/1bVoL+6ttPk32sMATd H1+YisPxHNft4Dtru61Gzt7SZ4jb2FtEMfeBAz14oA7nUPHGlade3NpILmWe2wZUhhLlVIzu47U2 Lx7os9xbxxSzNFcMES4ER8rcf4d3TNZmioreIfFjlQWMMIz7eWaw5kWL4P6OY1C/6TG3A7+aeaAP TridLW2lnlzsiQu2B2AzXNJ8RtCfyXMlwkEw/dzvCRGx/uhvX2rb1s/8SC/P/Ts//oJrhLq3hPgD wpGY12faoDjH1NAHW6f4v07UftYQXEUlpH5skc0RRtn94A9RU83iWwg0S31Z2k+yzlAhCHPzHA4r mtaz/wAJ5eqo+9or8Dvyaz9SvLf/AIVXoq+cm6SW3VRnkkNyKALl94lu9Hm8XXKtNN9laEW6BS4j JT07CtjTtftLy502aeS9iu5bJpRC6lVKjG5ivr6Vz2of6vx5/uQ/+i6tTHPijRiDn/iSS9PwoA1r X4haJdvD5b3AhmbYs7QkRBs42lugNFrqTw+NdZW5uWWzgtYpMM3yp1ya5uGfTz8FkSFoyWTYqg/N 52/+eaq+I47or4gRSRMun2vmHGcAdc0Adtp3jTS9SvY7aP7RE03+peaEok3+6T1qQ+L9LSz1G4lk eNdPk8udXTDA9sDvnPFctdafe3dpo39oeI7M27TRParDbAMxHQKR7VmeLmtZfH8d8sLyabYvGuqM p+Qtk7MjvjIzQB3J1vT49TkmeW7WVbEXLRMDtEfrj+9UVl480e/urWGJrhVu8CGZ4Ssbn+6G6ZrF 191fxPqzIQVbQyQR0IyajvY0j8B+FgqqAJ7YjA6UAdHqvjPS9HvXtbgzu8S7pjDEXWEdixHStHR9 Xtdd0yK/sWZreUZQsME/hXLeH5be3k8VrqDIsguHeXzD/wAsyvy/hirvw0KnwLYGP7hDbfpuNAHV UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAEK/wCrXAIGOh60lKv+rXknjqetJQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAI3CsfQGs3QLuW805pJiCwkZeBjgG tJuFY+gNZ2g3RvNPaRo0Q+Yy4QYHBoA0qKr392thZSXLqWWMZIFQadrVlqaA28w390bgigC/RRRQ AUUUjusaM7kKqgliewoAWioYLu3urRbqCZJLdl3CRTlSPXNJZ31rqFv59nPHPDkjejZHFAE9FQ2t 5b3sRktZkmQMVLIcjI6ipWYIpZiAoGST2oAWiorW6gvbdZ7WVJYm6OhyDUpIUEk4A5JoAKKitbuC 9gE9rKk0TEgOhyDUpIGMkDPrQAUUVGtzC08kKyoZYwGdc8qPegCSiqVrrWm3109taX9vNOn3o0kB I/Cpo722lu5bWOdGuIgDJGD8yg9MigCeiobq8t7GHzruZIYshdznAyegqXcDjkZIyKAFoqG6u7ex t2nu5khhUgF3OAM8CpgQQCDkEZBoAKKOlAIIyDkHuKACiiigAooooAUU8VXnuIbWPzLiRY0yF3Mc DJ6VYFACmmGnmmGgBtFFFABSOcIx9AaWkY4Rj6A0AZ3h+6kvdISaYguXYcDHQ1pVnaBcm80lJiiI S7DagwODVm/vBYWUlyylljGSBQBYoqhp2tWWqIDbzDf3RuGFX6ACiiigAoqjf63pmluqX9/b27t0 WSQAmrcM8VxCssEiSRsMq6HIP40APooBDDIII9RRQAUUUUAFFFFABRRWff6/pWlTCLUNQt7aQjIW RwCRQBoUVUsNWsNVVm0+8guQvXy3DYq3QAUUUUAFFFFABRRTZZUhiaSVgiINzMegFADqKjgniuoE mt5FkicZV1OQRUlABRRRQAUUUUAFFFQi9tikziePZCcSNuGEPuaAJqKqWGr2GqBzp95Bc7PveW4b FTXF1BZxebcypFHkDc5wMnpQBLRUFxfW1o0K3E6RGZtkYY43n0FT0AFFQWt9bXsJmtZ45Y1YqXVs gEdRU/WgAoqG1vbe+jd7WZJkRyjFDkBh1FTUAFFGQSQCMjqPSigAooooAKKKKAClFRQXEN1EJbeR ZIySAynI461KKAHisjxF/wAga7/65GtcVkeIv+QNd/8AXI0nsZ1f4cvRnk1NkkEa7m6U6oLz/UH6 1z0YKdSMX1Pioq7SD7ZF7/lR9si9/wAqo0V7P9nUfM6PYxL32yL3/Kj7ZF7/AJVRoo/s6j5h7GJe +2Re/wCVH2yL3/KqNFH9nUfMPYxL32yL3/Kj7ZF7/lVGij+zqPmHsYl77ZF7/lR9si9/yqjRR/Z1 HzD2MS99si9/yo+2Re/5VRoo/s6j5h7GJe+2Re/5UfbIvf8AKqNFH9nUfMPYxL32yL3/ACo+2Re/ 5VRoo/s6j5h7GJe+2Re/5UfbIvf8qo0Uf2dR8w9jEvfbIvf8qPtkXv8AlVGko/s6j5h7GJoC7jPT J/Cl+0IQThuPaq9jzI30q7XTh8DCk+aDfYymoxdiE3SDqG/KkF3GemfypL3iD8RVa1P+kLWEssoq VrsqMIuPMXBcIezflSfak9G/KpqZP/qH+ldM8BCVNU23ZGa5W9iP7ZF7/lS/aU9G/Ks4HpWsPuj6 VhTy2le6b0NJwjAjNwgOMN+VN+1xe/5VPisuQ/vW+tXiMBTqT55N3YqcYyNCO4SVtq5zUlUbP/X/ AIVerxMXRjRqcsSakVF2R6P4I/5Acf8AvN/OurXpXKeCP+QHH/vN/Ord14SS6upLhdX1aFpDu2x3 GFX6DFVD4UfX4T+BD0R0NFcVq1tqvhW3ivoNauLuETxxvBcqGyGYLwe3Wu0ByAao6BaKKKAKmpaf ZalZPBqMMctueSJOg9/as3Q/D+hafM1xpcUTy/d8wSbyo9Ac8Vl/EWUw2OnyXKTPpa3QN8IQc7O2 cc4z1qHRLfw5qGr2moeFNRghaIMJ7eE/65SOAVPTB70Ab9z4U0i7ubqea1Bku12T4JAce4q7faXZ 6lYmzvIElgwBsYdMdMVwum+KtV04eKb/AFG0Dw2c+VUS5I4Hyj2rabxfeQadDNd6Q6XV44SytlkB aXIzk+mO9AGvpfhvS9GilSytETzhiQt8xcehJ7VSXwH4eVZFGnRlZDnBJIXvx6UaZ4mlkvZ7HWLE 2N5DF54UNvWRO5U98VnP421CCCLULjQ5ItJlkVBK0g8xQTgMU9KAOlg0iztprqWKEK90FWY/3gBg fpULeHdNfSYdMa2U2cLBkjzwCDkfrWJeeMr5dW1Gx03SDdNYKskjmXaCpGfz9qgg+IMs1tZ6j/ZM qaTcyLD9oZxuVicfd9M8UAdjNClxA8Mq7o5FKsPUHiqbaFYPZWto0AMFoyvCv90r0qzfXP2OxuLj bu8qNnx64Ga5Cy8fXM1nZ6lc6PJBpNyyp9oMgJQnjJX+7nvQB1TaVaNqf9otEDdeV5W8/wBz0rKh 8GeHXZ5obKFg77sq2QrA9uw5qu3iu8n8SXmlWWl+elmVM0xkAG1hngdzVe18XQW3h+2lstNP2i7u ZIbe0jb77Bjk57DuaAOi/sSw3XrG3Um+AFxn+MAYGfwqj/wjml6Xah7aFY3hheGFnf7oftk+pqpB 4vmjW/t9T082t/aW5uRFv3LKg7q1Z8ni2a+8OJqWoaGBZSyQ+SHlyWLOBkjtjrQBL4T8Fadp+jaf c6lp8ceoQR7pNzZCtknce2feumTTbF7qe8WJHkuowkj9Q6joK45dZ1NfFHiRbyzSSwtrQOUMvAXY TwP9rvWsmsar/ZNjcaPpFu9pJbrId9xs8vjp06CgC9p/hDRdMvvtdpYokwztJJIT/dB6VYi8PabD Y3Vmtspgu2Zp1bnzCepNYGm+OLq78PS6lNpMgYz+RbRQtv8APPTIOOB71LF4p1MXsum3+lC2vntn mttsu5JNvUE9jQBrf2DpVuBviRd8AtAWbrH2Wp5NEsZbG2s3gBgtSrRJ/dK9K4rw/rt2fC2mTazY pO81+I43aTJyWPzfhWzdeL7x7y8XSNJe+trFttxN5gXJHJCjuRQBl69pF7c63dPd+Ho9TD8WtxG4 jCjH3ZBnnBrqPC2kNoXhyzsJCpkiT5yvTJ5OKy77xwqLo502ze8OqhvKAbaVIGcH+tXvD3iGXVp7 2zvbM2d9ZsBLFu3AgjIINAG7RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAQqcxqc7uOv rSUq8xryDx26UlABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAdRisifQ 3MhNneyWsZ58uMcZ9a16KAOf8R2E/wDZDP8AbJdsUW1kx/rD6muY0nw5qF86yxhreP8A56Nx+Vej Mquu1gGHoRS9BjtQBBY28lrapFLO87L1dutT0UUAFNliWeF4mGVkUqfoRinUUAecaVftpfw01SzB 2y2lxJZoPTc3H6NT/ChHhLTPEekucCxj89M+jJ/jmq1/Aw+JD6GFPk3t1HfkDphQQf1ApfiMklp4 khEKnGtQCzbHchgf60AX9I1j/hEvBmj20NlJe6nfgyx2sXBYt8xJPYc1raP4tk1Frux1bSpdO1CG Eym3kbcJE9Qe9c34806G18S6HLd31zp2npbtb/a4Djy27AnsDUegWemP4kupdP1jUNXe2spA1xI2 6JAR93PrQBsW/jW2svCumzafpJNzfOyW1hCepB5OewqXSvG0+r6tcaNe6RJYXcds0kqyPnb6Y9RX KaBdxaNF4U1e+bbYBJ4HlIysbEnBPpWzb63Y638T7iTTpFmii01kMy9HPse+KAMrwn40u9D8IxeR oVxdWFrI/wBpulYAJ83Yd8VpeLdf1FvFnhmTS7B7q2lHmxgS7RKSOQR7CpPDu0fBe7xjBinJ/M1X ubqCwfwHd3cqQ26IQ0jHABK8UAejyTiC0eeUbQkZkYemBkiuHs7e71D4d6vqUBxf6mJJQ2cHaDgA HtwK6/V1M+hXwi+YvbSbcd8qcVw8vn3HwSt/sgdikCiVY/vbVbDD9KAMLTZvDt7e+GoPCsQi1iGZ TcsMqQgHz7j/ABVqPrV1o/xP8QDTdLl1G7mhi2xIdoAA5JNM1vU/DmoaXotv4a8ltTFxEYFt0xIg H3t39c1es/EGm6H8UdfGqXCWwlhi2yv0yByM0AXrzxpY6h4QfULjTPMaK6SCeznODG+7H6VQstY1 dvi3cw/2Y7WxtkT/AFvEceeJMe9YmozLf+HNe1aBStnearD5DEY3gEAsK6e3u7ey+LEy3MyRNc6d EkIY43njgUAbnjPULfSvDc11d2aXsKyIDC5wDlgAfw61l6l44ubTXJdH07RZL67SBJY0jfAII7nt in/FDjwNdZ4/fRf+hioNDx/wtDU+mf7Og/lQBR17xhcaz8NdUu7KxmhuomNvcxF8NAe5z3q1ZeML rTfCmkrcaRM+qXKCO3s0fcZAAPnJ7CsuRDL4Y8eonJ+1P0+i1na09nfv4W1BtVmtdOFr9ne8tm/1 UmBwT2oA7fQ/GD3tzcWes6dLpV9BEZjFI24Mg6kHvWJdfFC4t7GXUh4euTpWSsF0WwJDnAyOwPrW PZ6TY6hqmoR6RrGoavcx2Ei+e7bo03D7ufU0/VPF+jt8Jv7NWVftwt1t2tcfOjjAJI7dKAOw1jxg 2nxWENjp0t/qV7EJY7WM42rjkk9hUdh41eew1L7dpstjqOnwmaS0kb7y9iD3Fcj4htIk8SaLc6jq d1pdnNpqxJdQnADjnaT2osLTTj/wkVxp+qX2qGHT2je6mbMZz/CD3oA6TTdcuPHek3ME+iy2thcW 5aC5Z8hn9h7GtvwXqj6t4XtJ5jmdAYZf95Tg0zwYQvgjSzwFFqDVH4aIR4aml/glvJnT6bqAOvNM NPNMNADaKKKACgjII7GiigDIm0KTzD9jvpbWHtEg4B71V8R2E50uSX7ZJtjjAZMcOfU10NIyq67W UMD2IoA840nw7qF+6yxq0Cf89G4/KvQLG3ktbVIpZ3nZf4261YHAwOlFABSjqKSigDypZ/D2n+Ld XXxvbZupps281whaPyscBT2rXsrdtD8I69NoE8eoafJmSziil5hBHzDPbHWpLTxXp8l3qGk+NPss N1BM3lGePCSRH7pBPtWd4ctrOWfxZL4fQro0lvtiABCNLj5ivtQAmg+Nr3QvAmjy32kyOZnEEJ8z LTAjhh9TW5P44vbWyto5tBn/ALYumYRWCuCdo/iLdhXKwX1rd+E/BccE0cjwXqRyqDyjehrR8f2k S+ONNutQ1G50yyktmiF3AcbXznaT2zQB02g+LTqMl1a6rYS6Xf2sfmyQSHIKf3ge4rGl+I98kJ1F PDdy2iBv+PwuAducbtvpWVokdjbavqt9pGo32tz2dg486Y7oieoQevSud1V7C/8ABct5c+JLu91G SLcLGE7UibuCoHAFAHo+seOW0/WLfTrLTJL6a6tRPAEbBYnoD6D3rPT4kXlzazJZ+HLmbUbUn7Xb bwBCB33d6j0ghviBohyCf7EU5/AVe8N4/wCEg8YEYz5vP/fFAHRaDrEOv6LbajbqyRzrna3VT3Fc xe6TYat8Unj1G0huUXTwQsi5AO6r/wAOOfBNpj+/J/6GaoXurWGkfFJ5dRu4rZG08ANI2ATuoAq+ I9GsvCGu6LrOjQrZ+bci2uIo+FkRvUeta2seM7qDV5dO0LRZtWmtwDcFGCrHnoM9z7Vla/rFl4x1 7RtI0WZbtYLkXVzLHykar0BPvWDNY2dt4x16LV/EN5oryXHnxCN9qSoR1zjqKAOwu/iDbW3hZdZW 0k+W4FvPbvw8TZwR+FJpnjm4n1m3sdW0WfTY7zP2SaRsiT2Poa4u5SxsfAU9/bPe3NrJqschluRl ptrDLAehrpNe1/TvFGpeHrDRp1uZ1u1uH2D/AFKKOd3p6UAX7/xzef2jcwaHoNxqkFm2y4nRgoDD qF9SKk1Lx/a2Wgadq0Fs88N5OISmcOjc8Y9cjFcJp9nYWVzq0GseJr/R7qG6kcwI+1XUnIZeOc1d a0trbwp4bNt9pME2sLIpuvvtnPP49aAOv0TxncX2vf2Tq2jzaZcSRmWDzGDCRB1+hrH17x5Neabq yWei3M+kxo8D3ykYDYwcL3Ge9aviBS/xG0RB95rW4Uf98iue0rxRpejfD/UNIv5BFqNuJomtWHzu STggdwaANfSfEkfh74f6AsdtJd3l1CqW9tF95zj9BWjovi+4vbyWw1fSZdL1BYjNHE7bllUdcGuE 1C1U6H4LvLq7uLGxW3Mcl1B1iYjjPoK0tDstKk8Wq1hreoazLbWsjNM77oogRjBPqaALyfFG6l04 ajF4euJNPiYrc3CvxGQccDvW/rvjCPS7ax+w2kmoXl+N1tbx8FhjOSewrmtDI/4UlfEYx5dx/M05 r2DRNa8K6rqDeXYtpxtzMfuo5wRn0oA0R8Qpo9Pu3vdHktb2ydBc2zv91GON4PcVuar4gFhdaTb2 8IuJNSkCqN2Nq4yWrMj1ey8aS6xplhAk1oLfyzfL0dyPujjnFYngOebXteSe5VsaLa/Y/m/56ZIJ /ICgDt9f1IaPoN7fd4Iiy/XoP1rDs/CkWp+C7OxvJZEE5W6uthwZSfmIJ9Oas/EGNpPAuqBBkiMH 8AwNLqniQaB4b03UfszT2jiJZnU/6pCPvY70Acxo50Wb4l20fhNI4YrWCRL7y/lVuwGD1IPeo/ib p2sTtHfXN4iaXBdwrBbIOXJPLNVq91DSNY8b6C3hpoprmORnuZbZcKIschiK0/igQPCkX/X9B/6H QBR+KF0tifDV08bSCK+VtiDJb5egrW0LxlPqGt/2Xq2kzaXdSIZIBIwYSr9fX2rM+JV5Dp83hq6u R+5ivgz8ZwNvWnXGs2Xifx/oi6NMt0tksks8sf3UBGACfWgDnvEPiO4n8I2kui6OIIW1NkkWKTaC 6v0P+9XqWnTT3On28t1bm2ndAXhJzsPpmvJVdY/hsk7sFii1xmdj0UeZ1r161uYby2iuLaRZYZFD I6nIYUAcPF45tNJ8OyahBpKxRHUntXiibq2fv/U1oaT42urrXk0zU9Fn0+WeNpLQu4IlA7exriIi D4Tizgj/AISRv/Qq7fxGR/wsDwt65n/9BFAGD4M8R38Gq+Jp9Wsnhsop2klmaXd5RAGEA9604PiF eB4bnUPDt1aaROwWO8ZgcZ6Fl7CuenAuLDx1pUUgN/JceckAPzsgAyQKzpINCudGtFHijVb2Scog 09Hy270K44AoA7/W/Gc9lq503RtJm1W4iQS3HlttEanpz3PtTdI+IFpqOhalqtxbSWsFjL5ZRuXY +mPXPGKzNJ1Wx8JeL9Zt9ZnFr9pSKWCWXo6hcYz6iubz/bngnxTcWMcgibVBNhB82wHJIHrjmgDs LLx5e/bLYax4fudOsrtwkFyzBhk9Nw7Zp0/jq8/4SW70fT9DlvHtJVWWRJMBUP8AEf8ACuOktdDv Bp0UPijVdUluJYylor5KkEHLDHAFdf4TAHjzxYB1EsQz/wABoAtaC/8AZnjDVdHHywSqt7Av93d9 4D8a6oVyIBl+LTMh4h07D/ieK64UAPFZHiL/AJA13/1yNa4rI8Rf8ga7/wCuRpPYzq/w5ejPJqgv P9QfrU9QXn+oP1rLC/xo+p8XD4kUaKKK+lOwKKKKACiitSLS4pPDE+pl282OdYgvbBFJtLcqMXLY y6K1/D+jxaub3znZfs8BlXb3IrQ0LSfD2qtb2sl1ereyjBUKNoP1qZVFG/kaQoylbzOYoro7q08L RTLHHd352uVkyg4HtV1dE8LtpTagLy/+zrJ5Z+QZz9Kl1Uuj+4aoN9V95x9FdNp+jaHef2jdNc3Y sLQKVYKN5z7VImgaJq1tcDRL64N1Chk8udcbgOuKPaxQLDya0t95ytFdHYaFpcOlwXuuXskIuSfK jiGTgdzVDxBo40a+SOKYTW8yCSGQfxKapVIt2JlSlGPMzLoooqzIKKKKACkNLSGgZPp5/ev9K0ki kkGUjdgP7qk1maf/AK5/pXoVsmpHRLFtLmgtE2EOshVS5z97nrVe05IohUfaTfkuhw+pQyx2uXjd RuHJUiqNof8ASkrqvFg1caQP7QvIJofMHyo6k5/CuTs/+PtKlT5pJlOmoQa1+ZsJG8hwiMx9FGab dW8yWsjNFIAF6lTXU6Cl4+gSnTnit5lm+aWTA3jHQE1FrK66NIuvtOoWzw7DvVZFJI/KqlW1cdPv FDDLlUte+2n5nA54FbS8hcegrDH3RXZ+FRu1iJREHYodpIyFOOGP0ohLli5CqQ55Rj3M0W0//PGX /vg1iygrO4YEENyCK9IZPEYcj+07Tg/89F/wrz7VPP8A7WuftUiyTbzvZTkE1Dq8/b5Fqiqd3r81 /wAELL/X/hV6qNl/rvwq9XhZj/G+Ry1viPR/BH/IDj/3m/nXVL0rlfBH/IDj/wB5v511S9KiHwo+ twn8CHojm/H/APyLS/8AX3b/APoxa6Vfuj6VzXj/AP5Fpf8Ar7t//Ri10q/dH0qjoFooooAwPE2t y6HJZSy23m6bK5jupApYxA9Dj0rmb6LQ9T8V6LP4YSE30dyJLiW2XCiHHzBscfhXY654g0zQo4hq swjW4JVF2F95HUYANUdI8TeH7q6NvphCSMpYhbZowQOTztAoA47VbiKPSfG9o7bbhpxIsZ6lfl5H tWr43slaTw7f3MlzFY27FZ5Lc4aIMuA2fTNdfZS6drFsL61SGeOUFfM2DLAduautGjoUZVZCMFSM igDz2wTS11K8vNBm1HU7yzsnKXE0u+IE9EHAya5rXbnT7vwlFcyalfahq8rxtJGWO2E7hnKgYAHv XssNvDbJsgijiX+6ihR+lMFjarv220I3/fxGPm+vrQByOh/8h3xWfWKHn/tkaw7kH/hT+j8HP2iL /wBGmvTlhjUsVjQFvvEKOfrTTbwmIRGGPyx0TaMD8KAKutc6Bff9ez/+gmvPBr9lrPw3sdGsstqN wscItwp3LgjLH24zmvSdQtmvNNubdCA0sTICe2RiqegaMmkaTZwSJE1zBEI2lVBk49+tAGJ4cQx+ KvEqHkr5Qz6/uxXNaY39nWvh7WJ1f7Ha3l1HOwGfLDkgMfavT4jA0kpi8suDiQrjOfenCCIRGIRJ 5Z6ptGD+FAHn2sXkPiHW7++01vOtLLSZYnnUHaztyFB71JrA/wCLV6Vx/Ha/+hrXby/ZNOsJXeOK G2jUs4VAFA78CltntL+whlgWOS2kUPH8vy47HFAHD6jcRQa/4rglcJLcaaDEp/jAjbOKo6hrsP8A wj+heG2u1tBd2qSXU7HGyHHIHuelelPbQSyB5IY3cDAZkBOPTNRy6dZzbfNtLd9owN0SnA9OlAHG 6/rlnB4fsbfQL5YrBLhLe5uLb5jbx4PPt061jWQ00fESwXSbi6u0NpMHuZnLB2x0BPB/CvTI7C0i jeOO1gSN/vKsYAb6jvTktLeIII4IkCfd2oBt+npQB5lZ3MUvhPQ7dHBmt9WVZU7od7dRWnomt2fh aHWdP1eRoblbmWaNWUkzK/I2+vpXdCztlYsLeIEtuJCDk+v1pZbWCd1eWCKR0+6zICR9KAPOdDsp rLUvB6XMZjkf7VKUI5QMuQK6HRf+SgeIP+ucH/oNdLL5KYmmEY8sE72x8v49qciR7jKirucDLAct +NAD6KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigCFciNcgA46DpSUqjEajGOOnpSUAFFF YfiPxXa+HfJiaCe7vLjPlW1uu52x39hQBuUVzem+NrTUNMvrk2txbXFihee0mXbIorNh+KWnSyWr tp98ljcFUF4yfu1c9s/1oA7akeRIkLyMqKOrMcAVz/iDxjb6HeR2UNndajfSJ5gt7ZckL6n0rE13 xPbeJfh3rjwwz201uhSaCdcNGetAHdqwZQykEHoQeDSLLGzsiupdfvKDyPqK4Tw78Q7FLTSrKayv IreSNIY7148RO+Omf61Ppd1DY+P/ABRdXMgSGKCJ3Y9AAKAO2orjrP4k2dzeQpNpmoWtncPshvJo 8RuT0+mata744g0jU20+20691K5jQPMtquRGp6EmgDp6Ko6LrFtr2lxX9nv8qTs64ZSOoIrF1vx5 baLrMml/Ybq6vBGJI44BkyZ9PpQB1FFczb+O7C58NXmsLDMv2Li4tnG2SM+hqC2+IthJp1zf3Nle WtpCqmOSRP8AX56BPWgDraK5bRPHtrq2qJp91YXmm3Ey7oBcpgSj2P8ASqdx8TrSG4uoIdLv7qS0 maOfyV3CMKcbj/hQB2tFYN54z0q08Owaz5jS29xgQpGuXkY/wgetV9A8cW2t6g2nz2V1p16F3pDc rguvqDQB01NkljhAMsiICcAswGT6Vw0vxNju7a5XTtH1Gd4xJG0ka5WNhnqf1rL0LxHb3nw/06Tx Bpt1cBLxI0kkbHmSFjhwfQUAen0Vyut+PrXSdTksLXT7zUriAbpxbJkRD3NS3PjvS4PDEWux75bS SVYiBwyEnHI9qAOlorltJ8fWmqa3HpsljeWbzgtbSXCbVnA9Kj1X4gwWOoT2ljpd/qbWpxcPbJlY j6E+tAHVvLHHt8x1TccLuOMn0FKzBFLMQqjkk9BXBeKdXttd03wxqFkWMMuooRuGCD3BrrfEn/It 6n/17Sf+gmgDQR0lQPG6uh6MpyDUGoTz22nzzWlubmdFykION59M15x4O+INlpXhjSbSeyvTbRoI pL0R/ukcnpmuu1/xja6JPBaw2tzqN7OnmJb2q7m2/wB4+goAwzr/AIna9W8bwGTcqmwSmddwX0zi kuNf8TXckMlx4DMrwNuiZp1JQ+o4rXsvHdnd6FqOoNa3MEunD/SLWUbXWqdt8TdPuLy0R7G9htLo hI7x0xGXPbP9aAK114h8T30DQ3fgQzRN1SSdSP5VBYa7r9nbvb6f4DSKLJDpFOgGfQ4rf13xvbaJ qi6fHZXd/dBfMlS2Td5SeprmPB3ia207TdZ1Py5JLa51fYCOCm7oSKAIr288XXBtIbbwcIdOiz51 mzoyTA/yNVrSXxLpniN9U/4Q9IYWgFtDbJMqKoznr3Jrv7vxTaWnimy0J1Y3F3GZFcH5Vx2P1rI1 zxLpNzM9tfafJcR2l/HArBsDzT0I+lAFGPXPEkNkbOPwEVtiCDEJ12kHrxion1nXNRtYrabwFHPb RkBVM6MqY9PpW3rPj200rVZNOisby9khUG5e3TcsAPrXCx69cad8K7u405Z2NxqL4li42KWB5+vT 8aAPXopIwkUT7Ecxj9zuGQMcjH6Vj+HNMn0eTULB482XnGW2fttbqv4HNcZeeJVtPF+hapd2N2kk mnMq2u3dKzZGBj3rsvDPi228S/aY1tp7O7tSBNbzjDLnoaANC00TTLG5a4tLC2hnfrIkYBP40XOi aZeNK11YW8zS43l0BLY6VFqeuRaXqem2c0Tn7fIY0kB4VgM4NQWvim0uvFV5oKKwntYhI0hPytns PpQBfms7BreOymht/JyDHCQAOPQe1LcaXY3VzDcXFpDJPD/q5GUbk+hrzvxB4stZ9f8AD2rmGZbe G4niUAbmkIGPlHua6vw740ttfvbmzks7nT7yBfMaG5XBKf3qAN66tIL6Aw3USTREglHGQSOlIlnb xXTXMcKLO6hGkA5IHQZrkpfibYpcuY9N1CbT432PfpHmJT3+o96va345sNFvLS3aGa5a8hM0HkDc X6YAHqc0Ab0djaxCYJBGonJaUBfvk9c+tQx6LpsVi1kljbi1Y7mi2DaT64rP8M+LLbxL9pjW2ns7 u1YLNbzjDLnpWN8Udbu9H0S1FlDcM01wgaSLjAB+6frQB00Wn2dhaTWWlJb2UroSoiABB7NivPJt C8TapC+lXWg2UU0rBLjVxtBkTPJAA6mpr3xMth8Q7bUJrC786fSgEs1XMpbceK63Q/GVhrWm3d26 S2TWRIuYpxhovrQBqy6XaXNhHZ3VvFPAihQsigjilg0uytbJrS3tIYrZhhokQBT9RXL2nxKsri7i WbTb+2sp32Q3sseI3J6fSp9Y8fW+la5NpSadd3l1GivtgGcqe/4UAa+sQTw+HprTSIAJWTyYlXgI Dxn8Kt6NpsekaRa2MP3IIwufU9z+dc3qXxCtrG+e1tNMv9QeEA3Bt0yIc84J9faul0jVbXWtNhvr F98MoyMjBB7gjsaALpphp5phoAbRRRQAUUUUAFFFFABRRRQAUjkqjFRuYAkD1NYXiXxfZ+F57SO8 hlkN1uCeWMnI7Y7k1Bofje11l7qCSzurG8tozK1tcLhmTHUUAYOo6lrupv8A6d8Pkudh+VpJUJ/l U8HiPxRawCC38CGKEDARJ1A/LFXdH+I1lq5aRbG7hs0jZ3u3X92pXqufWm2XxJs7m8hSfTb+0s7h tkN5NHiNyen0zQBlRX2twf6n4domJPN+WVR8/wDe6das3fiDxPfwGC88BmeI9UknUj+VbXiDxpb6 HfJYwWV1qN8yeYYLVclV9Se1M/4TvTz4YuNaWObZbMEngcbZI2zjBFAGNZa54k06DyLLwCIIv7kc ygH9KgivtahaZovh1EjTgiUiVAXB654rTT4n6aLoR3NlfW8MibreaSPic+ij1q7ofji21mS9gexu rK6tIzK0FwuGZMZyKAMaPXPEkM8c0fgIrLGnlo4nXKr6D2p0fiDxPDJM8fgRlec5lIuFy/1p8fxW 0+SOK4GnX5syds10qZjhOcYJqDxD4qu7f4haLBaWl3cWbRFgIj8s27GGHsKAJbbxH4ps4BDbeBWi iXOEW4UAVVv77W9UmEt/8O0uJAMBpJlJA/KtbUfiPa2V9cQwaXqF5BattuLmGPKRHv8AXFdVZ3cV 9ZxXVu2+GVA6HpkGgDg7LWvEGkxMLLwAtqnVvLmRfz4pt5rGu6wsb3ngCO7Ucozzo35HFU4PEt9q GveLLOeyvBD5DKhf7sAVe/8Avdqk8LfEOz0rwxpFtNYXzWscawy3qp+6R+mPegCLxDceK9c0mCwi 8HNaxwzJKAsy4wpzjFX7PVvEGnyPLZ/D5YZJPvukqAt+ldH4g8YWugvbwJb3F/eXC74ra2XLFfU+ gqfw54mtvEcEpiimtriBts1tOu14zQByd7qWu6jMk178PEnkT7rySoSP0qabXvE1ysSzeAy6wsGj BnXCEdCOK6TxL4otfC8VrLexyOlzL5QKdQcZ6d6xY/ibZMZoZdL1GG+TBitGj/eTA9CooArv4i8U SXUdy/gVmnjBCSG4XKg9cVXm1PXrm7+1TfDxJLjG3zGlQtj64rotK8b6dqOhXeqSrLZpZErcRTDD RkdqoWXxHt7nULaC60jUbKC6YJBczx4Ryen0zQBROueJGsRZt4BzagbREZlK4+mKbZav4h02ForH 4frbxv8AeWOZRn68Vq6j8QLex1640iPTby6ubdl3+SuQFYZ3H0AqC6+JdnBdSiLTNQuLKB/LmvY4 8xoe/wBcUAUE1/xBFanT08CqsLg5gFwuCD14p8+ueJLmzFpP4B8y3AwInmUqB9MVFr+v2+l/EbTd QEc1ysunN5McK5aQk8ACuj0HxpY61Z3s0kU1jJY83MNwMNGMZzQBhWev+JtOtxBY+A/IjHRI51Az +ArP8M6l4n0L7RDN4WLzXNwbi4k+0Ku0MeuPQCtmP4nWjTxNLpOpQ6fM4SO+ePEbEnAP0qjrRB8c +ICDkHQv8aAO6n+zX1q1tK8bLcxldu4HcCOcetZ3huwuLXQzpmpQh1t2MSFhkSx/wn8uK5zwzd6d DbeE4bi0aS+ezdoJw3EYHUY96kb4q2IgaePS7+WGKRkuJY0ysGDjJNAHXWGk2Gl7/sFnBb7/AL3l oFzUt1Z297EIrqFJowwYK4yMjoaxda8ZWGj2NnOkc15LfDNtBAuXkGM5qLw743tPEWqS6fDaXFvc QRCSVJhgoc42kUAb1zY2t55f2qCObyjlN652mmWOl2OmBxY2kNvvOW8tAuT71HrWs2mg6ZLf37lY Y/QZLHsAPWsHR/iDa6lqSWN1p17p80ylrcXKYEw9j60AbrWOlJbnTmhtBFMSxt22/OT1O3vVu2to bO3SC2jWKKMYVFGAorzDwvdR658TtSur/Rrz7RFJiCWQ8WoAIwR7132va/DoK2ZnieT7XcLbrtPQ nuaALI0fTxEIhZw+WJPOC7Rjf/e+tTyWkE1xFPJEjTQ58tyOVz1xVK/1uLT9b07TXjZpL7fsYHhd vXP51zL/ABSsgZvJ0q/uFt5GS4aJNwhAOMk0AdcNMsl1A3y2sIu2XaZgo3Eemagh0fSLbUTPDZWc d4w3blRQ/wBfWqOqeM9N03RLXUk8y6W8IFtFCMvKT2ArmdH16PXfijDP9mntJItOZZYZ12shzn+V AFzxNa69HrzTRaNb69p8ijyYpdoa2cdTkjpWv4L0K60fSbg6kIvtd7O1xMifdXP8P4Vm3XxNtIZZ Wt9J1G6sIHKS3sUf7tcdfqKoeLvFtxb+JPDh0+2u7i0mzLiHpOCOB+HWgDtbXRNMsblri0sLaGdu siRgH86sRWdvbzzTxQoksxzI6jl8etc5rHj2303UGsrXTb7UbmNQ86WyZ8kHsT6+1Tz+OdLi8ORa wnmyxyv5aQov7wyf3MetAEvh3TLiG81LVL+PZdXsvCHqka8KP61vCuc8PeMYddvpbGawvNOvY08z yblMFl9Qa6MUAPFZHiL/AJA13/1yNa4rI8Rf8ga7/wCuRpPYzq/w5ejPJqgvP9QfrU9QXn+oP1rL C/xo+p8XD4kUaKKK+lOwKKKKACuu0KSwj8E3japFLLB9rX5Yzg5xxXI1rQ6lAnhO405t32iS5WRe OMAetZ1Y8yS8zajJRbb7M6fQJ9Dlh1QaVa3EUv2RtxlbIxXO+Df+Rqsv94/ypPDeq2+lm/8AtJf9 /bmNNozyar+Hb+HTNdtru43eVGSW2jJrPkaU0be0TdNvo/1Kd5/x/T/9dG/nW3F/yT+f/r8H8qwr hxLcyuv3WckZ+taUepQL4Ul087vtDXAkHHGMetaSTaXyMabScvRmp4TggudB1uK7uRbQsqbpSM7e fSpbOTQvDUVzc2upG/u5ImijRU2gZHU1jaZqUFroWq2ku7zbpUEeBxwcnNZFT7Nybu9DT2yjGNkr 2+7Vmno+lXWu3Swq5EMYzJI5+WJe9TeJ9Sgv7+OOz5tbSMQxserAd62bTVPDv/CNQ6bNc3sDE7pz DH/rD6E+lc9q8elRyx/2PNcSxkfOZlwQfaiLcp6oU4qNOyad99fwM+iiitjmCiiigApDS0hoAm0/ /XP9K723trLWNJtPOg1B5IE2b4k4x6VwWn/65/pXeWeqpHFpcsd4I4Yh5M0AOCCc/NjuKU78i5dy qTj7SSltZGN4q0e1sdIE0EV8jeYozOoC1y1n/wAfaV2Pi0ND4b8m6vUuJftO6DbJuwnvXHWX/H2l TTbb1dy60VGLsraHd6Klrf6K9lcxXkhSXeDAuQtR6toFlBpF1LHDqSskZIMiAL+NN02/8vQTHBdC 3nhn81lzgyr6Cr+tTBtK1WeS/SSzuYg0MXmZYP6Y7VNRyjJ22KpKEoK6u7f5nmg+6K7Hw1cx22po ZRKyOhQrEMs2R0rjh90V2Phq7is9SR5nEYaMoJD/AAEjg1qtYSMZO1SGvU2j4c05n4ttWAJ6eWK4 LU7dLXVrmGMSBEfAEn3vxr0GynuZ4YI49UQT2c58x2lwsiHuPWuA1l4ZNevXtmLRGUlSe9ZRcua0 nc3lGHJeKsJZf678KvVRsv8AXfhV6vGzH+N8jzq3xHo/gj/kBx/7zfzrql6Vyvgj/kBx/wC83866 pelRD4UfW4T+BD0Rzfj/AP5Fpf8Ar7t//Ri10q/dH0rmviAQvhkEnAF3b5J/66LXSIQyAqQRjqDV HQOooooA4vxxf2+ma/4aurtisKXEm4hS38I7Ctiz8TaZrkV1Fp8zu8cRZg0bLxj3FVvEdncXHibw 7NDC7xwzyGRlHCAqOtdBcqWtZgoyShAA+lAHnnh3V76Lw9omj6R5S3l55rmWUZWJFY5OO5q7eeIt c0uDVdPuWgl1CygW6hnRMLNHnDAr2NUNK0vUtFstC1gafPK9ossNzbqP3gRicMB3ra0yzutf1/UN Wu7KW0s5LT7JBFOMO4JyWI7UARXPjKdfGejWEOw2F1bh5nx0dh8vNbfhzU7jVjqE8pX7Ol00Vvgf wrxk/jXn1n4c1uPwjqlxJaSHVLa4jFqpHLJFwMfUV6N4Y09tM8OWVtKCJVjDSZ67jyf50AYs+qa5 rWralBoU1tbwaa3lkypvM0mMlevAps2va3f3VhpFrFDY6jLbme7eQbxCAcYA75NQpJfeE9a1gJpd 1ew6hL9ot3t13AORgq3pzjmozDrOkavY+IL6ze8kltTBeR2q5aM5ypA746GgBbvxXq2m6NrkF2IW 1TTFR0kRcJMrEAHHbvU8Gr6/YatpS6pLbS2+qgqEiTaYH25HPcc1l6jpupavpfiHVWsZonvUiitr Zh+8KKwOSOxrd1myuZtS8LPHBIy28uZSB9wbB1oA5jTL7V9B0TxZqIvIp5ILttimPHz8c/TBHFbs +r+ILKKwsnmtJtS1V8wkRkLboFy2eecVkX1jfjR/Fmmf2fdNNcXHnwsqZSRSV6H146Vv+I7C8hud E1mztXuZNOyJYE++yMuDj3FAFG/1TU7SLVdE1qSGeR9Pknt7iJNu8AYII9RXReEv+RT0v/r3X+Vc zdwX3iS+v9VGn3Ntbw6dJbW8cy7ZJXbk/L6Vu6HejStH0PT7yGZJ7iIRgbOFYLkhj2oAn8X6pcaN 4Zu76zCmeIAoGHBORWLFrWu6Rd6ZNrclrLZ6iwjKxIVNu5XI57ir/wAQ2ZPBOoNHy6qpXPruFZDS X/i2TRrOTS7qzhtXWe6lmXCkheFQ985oAY3irVdRivNSsL/Tba1tndYrSZhvnC9STnjPOKmn8T6r rGp6Nb6HJBBFqFm07vKm/wAsj09eeKyLbR4tDiu9Pu/Cf9o3hmdra4WAMkoY5G5u2M810Frpl1B4 v0WRrNIYodPkSTyFxFG5x8ooA6mCTZBGtxNG0wUByDgE9+K5vxr4lm0UafFbXENtHdylJLyRd6Qg DPIHrVqbwNoVxPJNJayF5GLMftEgyT+NU9R02Pw3bxR2GjG/0yZz9siy0sg44ZQx5oAxdevtW1L4 f6yJbu2dYceXeQDKXEZ68A8GrsuoeIYdU0XRLO7tt9xYmWW4eLpgjGBn04rMh8OXEmheKH0zTJrK 0vkX7LZuNrFgPmbb2z6Vs2C3N94t0W/FlcwwJprxP5qbSjZHBoAik8QarqOpXlpZanp1kNOIid58 ZnlxzgZ4WrEHifU9Z8O2lxpqW0Nw8rQ3U8jAxQberdefasq40a20TxBqsmo+HH1WG+m8+3migEhU nqjZ6c96XU9Lu007RZbvRB9gjld7vTrFc4z90le+O9AFm08Vahb3Gs6fPfWd/LaWTXUNxAuBkA8E ZNVT4j8VW2naLqMjWco1VkhFvsI8tmGQ27PPTOKqppt5Pr2r3FroUljYzaRJDboIwpZsdwOhPpWx dabeNoPhCJbaUyW1xA0ygcxgIQSaANDQdV1OPxNe6Jq80FxJHAlxFNEmzIYkEEe2K6iuWhsrkfE2 6vDA4tm09EEuPlLbjxn1rqaACiiigAooooAKKKKACiiigAooooAhX/VrwRx0NJSr/q15J46nrSUA Fea+LoLr/hZNq0erjSPNs9sNwyBgxB5Xnoa9Kqjq2iadrtsLfU7SO4jByAw5B9j2oA84itcXHiKa XXm1a6i05o5XWIKijsNw4Jq/qqIvwXsAFUAJARx33CuzsvDeladpkun2dlHFazArIi/xg+pqWXRL CbSU0yS3DWaABYs8DHSgDiNWu7vUPGNxY2mqWuiC3tkMlwyDzZwfQnsK52yZR4e8cqt9JfxgL/pE nWTgZP0r1HVfCui63PFNqVhFPLEMIzdceh9acfDWkmO6jFmix3SBJlXgMo6DFAHF69q+l3vw102z s5opLiYwRwQpywcEZ47YrO8Q288s/jKKLcZVtbYtt5OBjNegWfg/QrDURf2umwx3SjAcDp7j3q9F pVnDfXN4kC/aLpQszHneB0BoA8rvbWS48O2gu/GwuLOcxrHbRQKzE5GAAOeK2dTtYn8T3TaNr7aR q8MMa3CXK/u5wBw3PWuqtPBfh+x1I39tpcCXOdwbHQ+oHaptZ8K6N4glSXVLCOeROA54OPTNAFDw FrE+teHjNdJCJY53iZ4BhJcfxD61l/2hYWHxfuReyxxSSWKiJ3OB1ORmuztLO3sLWO2tIUhgjGFR BgCuOu/DUWs/EO+bVNPM+nyWSKruvy7gT0PrQBg6rNDfw+Ob2xIeyeOOPzF+67gjOPWtbxSY7bw1 4Vurhf8AQra4hafjhVwME+1dcnh/TI9HbSo7ONLFhholGAasTWdmdNa1uIozZhNrJJ93aPWgDkPF mo2Oq6/4ZttOniubsXom/dHcUjA5Jx2qv4K1nSbC48UR3dxDBMuoSvJ5hALL2+tdRofhfQtFkNzp FlDE0o/1q8kj2PpXLeGfCenarc622s6cksianI8ZkHOD0/CgDB01o7Gw8M6leqU03+053UuPlRWz sJ9BXUa7fWmqeP8Aw7Fp00dxcQGSSV4jnZGVPU+5rrbnTLK7082NxaxSWhXb5RX5QPpVHQ/D2h6G 0y6PawRSE7ZShyw9iaAOe+H6g+BdV2gbmubr8etc750bfCjw4iyIzx6jErqDyp8xuteoafpdnpVq 1tZQiKF3Z2Xrlm6ms+LwboUKSJHYIqSTLOygnG8dDQBheEdSsdK1vxJbajPFbXf2wzN5rYLxkDBB PUVyl2Y7jwZqV1Cv+hXOvRvBxwy5wSPbNemax4U0XX5km1PT4p5U6OeD9D61YuNC02506KwktI/s kLK0cS8BSOlAGD4sVV8V+FcADFw4GPTbXMR3Nzq76vcnxBBodnFcyI9rAgErEcbmPXJr0u5061vL q2uLiIPLasWhbP3SeKz5fCGhT6t/acumwNeZyXI6n1x60Aea6U2fA/hf5iwGsEBm6n5q9S8Sf8i3 qf8A17Sf+gmmL4a0pYIYVtFEUM5uI1zwsh71o3EEd1BJBMu6ORSrr6g9aAPMrbW9H/4UulsJoTK1 v5IgH3zITwMeuadLNfz63baVFqVtosttp0RluZEBllBH3QT2FdjD4J8PW95DdRaXAJoQAjEZxjp+ NWNY8L6Pr8sUuqWMVxJF91m6/T6UAeXWW0aX48RNQk1BRAmbmTrIfX6V0viREX4ZaKAqhVktSBjp 0rrf+Ea0nZcotlGqXUYimVeAyjoMVPcaNY3enxWM8Ae2hKlEz029KAOX0i/s9K8f+Io9RmS3lmEc sbSnAeMDnBrF0K2t9e8KeL1sgDHJevJCQO4AIIrvNX8N6TrzxPqljFcPEcozDkVPp+j2OlRzR2Nu kKTNudV6E4xQB5V/aB1CxPjFt3+g3ECZx0VRtf8AWrVzEx8GaVfyjEmo6wl0c+jNx+leiJ4b0qPR 5dKSzQWMpJeLsSTk1JPoen3FlbWctspt7VlaFOyFelAHK+GNSsdJ1vxPb6nPHb3BujMfNON8ZHBH qK5qN4p/g/qklvgQnUCy9sL5i16TqnhfR9auornUbCKeaL7rsOfx9akj8P6ZFpk2nJaJ9jnJaSLs SetAHLFobn4maDIjJKo01mVgcjPHSr2lgD4na3gAE2sWf1rYsPDWlaZLbyWdoI3tozHEck7VPUVb j061i1Ga+jiAuZlCSPnqB0oAwPiDEU8PJqKD95ps6XQI7BTz+lcLc3x0q1tvFqg51GW4Qkf3WGI6 9durWG9tZba5QSQyqVdD0IqjceHdKuNLg0+e0RrO3IaOM9FK9KAOJOmDTtV8C2kigsokdgf7xXJP 51o65E8vj67SAfvpNHkVcdSc8V0NxJoVzeW11PdWjT2mfJbzR8meDViCHTbzUf7Rt2imukTyjKj5 wvXFAHk2kwzjwRuk8Zpa2iRtHNZmFSyHnKY6k10Ol2sdv4v8IwhnlWPTZNjyLtY++O1dJceF/Cs+ tC5ntLI35O7BYZJ9dvrWpd2mmw38GpXflRTwqY4pXbaFB7CgDB0kAfE3XMAAm2iz+tM+Jxx4XhYk BVvISxPYbq3rQaS+qTXdpNbveTqFdkkBLAdOKs6hp1rq1lJZ30CzW8gwyN3oA5NGiuPjBFKhSQf2 TlHByPvHpWH4ggkmfx2lupLmOIkL1xgZrtLOy8OaPdRyW8trDPBF9nXM3KpnO3860bWwsVuLi9tk jZ7sDzZFOQ4HAoA8qvbZ7jwzbC68bC4sp/LRLaKBS5PGFAHORXWaDGE+KWsA/MyadAAxHPatm18F +H7LUv7Qt9LgS5zuDAcA+oHatKLTLSHU59QjhAu50CSSZ5ZR0FAHlmjWt+uoa5GnipdHkjvHeWCS NSSOzZPXiu1+G1vFB4adre8kvIpbh3Ezx7NxJ5IHpWhqvhHQ9culuNS06KaZf4yME/X1rYtreK1g SC3jWKKMbVRRgAUASmmGnmmGgBtFFFABRRRQAUUUUAFFFFAHD+Nru0sfGXhae/ZVhWWT5m6KcDBN R6reW2p/ECNtOkSY22mzfaJIzkAEcAmrvi3SH1XxT4e8yza4s0aQT/LlVBHet3S/DmlaLbS2+m2U cEcoIk2jlh7mgDgo7eSX4EOlsp3bGYhR238ms+/tXuPD9oLvxsLmznMax20UCl2ORgADnivVrHTb XTrBbK1hVLZQQI+owetZtn4L8P2GpG/tdLgjuc5DgfdPqB2oA4We0vl+IWqxR+IRo8rwxNG0iA+c gXsT6elU7m2jXwl4nnXVX1R5J4lmn8rYjMD2PQ16drPhvSfECoNVso7gp91jwR+NL/wjul/2P/ZS 2ca2PH7pRgGgDm/E0UZu/BylF2i4XAx/sUuogf8ACxtR9TozV1VxpdpdPavPCGa0bdCc/cOMfyqH UNLt3N3fJDm9e2aEOOpXHAoA4TQ9c0WL4QzQSTwhxDJG8J+80hJwMd+1Ps1ew8Q+ChfMImFi6Hec c4GBWj4N8F6adC0661XSUGowg5Mq4I+Y4yK6fVtA03XPI/tK1SYwNviJ4Kn2NAHn1xtt7jWL/wAM +IksvLldrqwvkG1nHXAPY13vhbUX1bw3YXskKwvNGGKKMAfT2qHUPBmgapfLeXumwy3Ax85HXHr6 1soiQxKiKqRoMADgAUAeerKkWv8AjmF5FWV7dWVCeSNnamvGi/AqABVANqjdO+etda+g6FquovqX kQz3RQwvLG3UEYIOParZ0SwbRl0o24+wqoQRZ4wO1AHnGpW92fHkBi1oaO02mxCGZ0DCTAGVBPSt nwRaqPFWqztrbatcrEkc0qxbUB7DI4JrqtU8PaXrVnHa6jZxzwxjCBhyv0NTaXo9holoLbTbWO3h znag6n1PrQBzPxBRXvfDSuAVOorwfoaluURvi7aMVBYae+Dj3ro73TLTUXt3u4RI1tJ5kRJ+63rS tp1q2prqJiH2tUMYkz0U9qAPOL/UP7Lt/GMywQylr6OPEy5RSQPmYegrM8QxXFvLoz3vij+0p3vI ilvCAI1GevFeqf2HpxW9VrVGW+ObhW5Eh6c1RtvBPh+ztjBb6ZEiFxIcddwORzQBk+HQv/CyfFTk ZYRwj3xtrmpJP7PtNT1Lwz4hihto5XafTL5B9/PIAPPNenW+l2lrf3N7DCFubnaJXz97HSsq68Ie G9Q1c3Vxp9tJejDN6n3IoA57T7n+0viFoN5LAsTyaSZPLA+4Se1Q6pejTNf8Y3Qt0n2WcRMbjKtn jkeld3/ZVn/aUd/5Ci6ij8pHHZPTFJ/ZFj9qubk26tLdII5i3IdR2IoA8h8SpcjwxbXF74pS6MjR NFY2qgRgZHGB2FdFqBz4v1onr/wj6/yNdVb+BvDtrDPFBpcKLP8Af9eueD2q82g6c9zLcNbgyzQC 2ds9Yx/DQB5/o3/IQ8E/9g+X+VXfC0af8Ku1j5V+Z7ktx1+Y12UXh/TYHs3jtgrWaGOA5+4p6in2 2i2Fpp0thBbhLWUsXjB67utAHBaRcwafr/hS5v3WO3k0oxQyPwqyemfUitHRb6yv/izqsli6SBbJ FkdOhbPrS+N7ZrC1023TSI9S0RB5clouPNDfwlCaPAmjTR6ve6u2k/2TayRLBb2rffAHJLUAWfiQ Vi07S7qdSbS31CN5+MgLnqfaqvjLUrDVdQ8O2um3EVzdtepMnlHJWMdScdBiu2uLeG7t3guI1lik GGRhkEVl6R4S0TQrh59N0+KCZ+rgZI+npQBkeFD/AMVr4r/6+E/lUfxLZYrHSLiVgsUOoxM7Hoo9 TXU22mWlnd3N1bxBJrpg0zZ+8RTr6wtdTs5LW+hSeCQYZHGQaAOQ1nVbO/8AiR4chtLiOZollZzG cgZAxzVHwPrmj2Oga7HdXMMMkd3O0yucFgc4+tdbp3hLRdKaF7GwjheAlkZeoJ6/WuY8JeC7G8s7 qXXdJBuEv5XjMq4JUng+4oAxNFZNL/4Q691EeTZGS42NJ92Mucpn04rcn1WxuPim8tk0dwbfSn83 y+QxyTjPfiuzv9JsdTsDY3trHLakAeWRwMdMelVNN8LaPpE0cun2McEkcZjDL/dPXPrQB5fcS3Go eCbnULjxJDZWskbmPTLNAMH+4e+fWtiCZYofh7PPIqR7CC7HAzsrsovBfh+C9mu49LgE8wIdsevX A7VNd+FtHvtLt9OurJJLW3/1SE/c+hoA87sba/8A+Eo8RJF4nXR5PtZkMTop3oRwwJ7UtvaaR/wi h+2axdMtxqZaHUUh2Kk39702+9egap4Q0PWmibUNPimeJQqseDgdAT3q3LounTaV/ZslnCbILtEO 35QKAOQ8Oanqdp4xj0fUNSs9YSS3aRLqJR5kYHZiPWu+FZWjeGdI8P7/AOyrGO3Z/vMOSfxrVFAD xWR4i/5A13/1yNa4rI8Rf8ga7/65Gk9jOr/Dl6M8mqC8/wBQfrU9QXn+oP1rLC/xo+p8XD4kUaKK K+lOwKKKKACiikPSgDc0fw39vs2vr27jsrJTtEj9XPoBTtV8NpaaeNQ069S+s9212UYKH3FW/FH7 rw/oMMfERgL4HQsetc/BdXUVpNBC7iCTBlUdD6ZrGLlL3rnTNQh7jXTfzNW98P22nXNvHdX2xJrb zg+3v2WsI16JcW8NzrVmlxEkijSSwDDIBx1qPS9DksNDtJrPR7fUZ7kF5GnYYQdgBURr2WprLDc0 vd2/4Y8+or0NNAsrXxUhntES3ntHle3JDCNgOQKzTPp+u6Bqfl6bBayWIDwvH1YZ/iq1XT2Rm8M1 u9dfwOautMmtLC0u5dvl3QJjAPOBVSuy8S6msvhDRk+x26edGSGUcpg44+tcbV05OSuzOtCMJWj2 QUUUVZiFFFFABSGlpDQBNp/+uf6V6BpEKWyaakNnHMl0pMs7LuIPPyj0rz/T/wDXP9K760t7yHTL STSL6GDemZUklH3s9cGpqfw0rl0f4rdtrGL4kt0fwwLiW2WCaO58tGAx5q/T2rlbL/j7Sum8XWuo mxW4v7uGcBwoCSBsfgK5my/4+0pQ+LcdT4XpY7jR41t9J+2Q2qXNw04jbcu4RL64qfW7WOa21tJb VI0gXzIpgu3Df3feo9Dt5jo5m0+7jt7vzcNvkwGXHpUPiC21e40ud72/gljjUsUWUc/gKU9ZvX/M unpTXu3+6xwY+6K7Dw5aw3mpxpOu9QhYR5++QOBXHj7orsfDcEVxqaJM4QeWSrltu1scHNaJ2hIx kr1ILzN7e89tp7vpcW552ieER4AX/PevP9Yt4bTXLyC3bdEkpCmu+kj8QOhiOq2xXpkTLmvO7yB7 bUJ4pGVnVzkqcg/jWUVrubzemz+ZNZf678KvVRsv9d+FXq8bMf43yPOrfEej+CP+QHH/ALzfzrql 6Vyvgj/kBx/7zfzrql6VEPhR9bhP4EPRGB44uPs/hef9xFMZZI4QsoyoLMBn8M5rCsfhlcW6gt4n 1VCf4IZNqD6A1seP/wDkWl/6+7f/ANGLXSr90fSqOgxtA8PPobSl9Uvr7zAOLl9236VtUUUAYfiL xGdClsYYrGa9nvHZI44mAOQM96bYa/qN1cFLrQbqziCMxlkkUgYGccVk+Obma01/w1Nb2r3cq3Em IUYKW+UdzWxZatf6hFdJeaNPYKsRIeSRWDHHTigC3oWsR67pMV/DG0aS5wrdRg4rRry/QZ7m/wBN 0DQLe6ltYrhJZp5IjhyqscKD2zVvUhqmlvrGiW+oXMqx2YvbSV3JkQg8qW7igD0WivN5/E91P400 S4guHGmrAiXCBvlLyDjIrqPCM899Bf380rvHcXbmFWOQsYOBigDoKK4eK3uvF2tayTqd3aQ2E32a 3S3coNwGSzevPakmXVdS1yx8OXupPGYLTz7ua1JRpjnCgHqPegDuaK831TUNS0fSfEeki/mkezjj ltblm/eKrMBgnvira217oetaDINUu7kanmO6jmkypO0HKj+Hr2oA7Ky1K21B7hLaTebaTypPZsZx +tW68mgtpNG8MeMLqxvLtbhLsxozSk7enP1561t3dveWUuj6JBqt4ZdWYyXFw77mVVUEhPTNAHa6 heLp+nXF26llgjaQqOpAGaq2Qttcg0/VjG4ITzIlZvu7h6etcjqP2nQbnUdFa8nu7K60yWeLz33v Gy8Ebu4NdT4S/wCRT0v/AK91/lQBZ1vSYtc0mawnd0jlABZOowc1chjEMKRgkhFCgn2rC8c3Fza+ Eb2WylaK4ULsdTgg7hWFLFfeFJtH1BtTu7tLuRYbyOZ9yksudyjtgigDvaK8mHiJNVivdRuNY1K3 vlkcWsNujeUgU4UEDhs45rTa51DxNrXh+KS8u7GO6sHkuI4mKEsD+nNAHo1ZetareaYIzaaVPfhs 7vKcLs+uaqL4u8PWKi1l1q28yH923mS/NkcHPvWhZaxYaxaTSaddxXKICrNG2QDigDD0Dxnc+IGi eDQbuO1eQxtO0i4Ug4OR9as3vi0R301ppmnXWpS25xMYMBYz6ZPf2qj8OCV8FsR1FxcY/wC+zU/w 6Vf+EVSbrLNNI8p7ltxzmgCU+NrE+G7rV4opW+ytsmtiNsiPnG0g1Xfxrc2kC3Wo+H761s+C8+5X CA9yB2qLx3Z2lp4R1ma0hjWeYo82zq7ZGM1Be3uva7oDaXB4fltvtMIiM88ylVUjk4HPSgDtYpUn iSWNgyOoZSO4NPqvp9qLHTra1DbhDEsefXAxVigAooooAKKKKACiiigAooooAKKKKACiiigCFTmN TnPHX1pKVeY1yQTjqOlJQAUUUUAFFFFABVHWtZtdB0yS+vWIiTAAUZZmPQAepq9XJ/ETUHsdGtEj W3V7i6SNZ7hdyQH++RQAaT4+h1DVoNPvNJ1DTZLnPkNcphZMelInxBt5tcl0y30u+mkguPImkQAp H/tE+lcjcxSW3jXw4tx4mk1m4NwSyjGyMY7YrofCUTSSeNViH71711XHXO04oAnuPiXZRXUoh0zU LmxhcpLfRR5iUjr9a6+2uIru2ingcPFKoZGHcGvG9Et5h4PkaTxq1jBEHSeyMa7kOTlcHk5r0/wd bLaeE9NhjlklRYhteRdrEe47UAZGofEe1sr++sodLvru4spNsqQKGwuM7vYVFN8UtMRIZ4LK+nsn 2iW6RP3cJPZj60nhRF/4SXxk20bjPgnHbbWRaxovwSvNqqATITgdT5lAHb/8JDbnxLBoyxu0k9r9 qWUEbdvpWV4k1yK703xJpSxOstnZlmcnhtw7Vl/aYNP+IOgz3kyQxS6P5avIcAt1xmqFxf2+paj4 4mtJBLELFVDr0JA7UAVrbxNe6fqvhCzisr2a3WxUlYukpK9f+A966VfFOkaLBrt/FYzR/ZrtY7o7 h+8Y/wAQrG0+aO31jwLJNIscZ04qGZsDO3pWZq7ImheMWlGYxqkRYeozQB2Om/ESyvtVgs5rC9s4 7o4tridMRzH2ql4f1K30jV/GN7eybIIbsFj+HQVF4r1bTdW0zQLTTJ4Z7mW6haFIiCUAxk8dK53X 4ZZbPxd5bMoj1OJpHUZKqMZOO+OtAHaaX8Q7a/v4La60u/09Lk4t57lMJKe2D2zXVTSpbwySyttj jUsxPYDrXlN9Ym4Glpd+N5dRjmnjaG3iiViSOR06CvUNUMS6Vdm5Rnh8lvMVepXHOKAOVtfiZZXF 1CJNL1CCwnkEcV88f7piTgVQsvFV5/ws/VLaWwvmto4Qqr/DGBk7/oaxY76fw5pNpeaH4ht9R0pp EVNNulDSKCei98iuiinSP4ja+JZFjefTUKKzYLcHgUAW9I+I1nq7F10+8htEjZ5LuQDy0K9Rn1pl p8SrO4uolm0vULWynfZFeyx4icnp9M1h21vJN8DJ0t1O4h2IUc4381l3lmbnw3bfaPHUlxaz7ES1 jiUtnsAOvFAHoGv+MoNEvo7GCxu9SvXTzDBarkqvqagi8f2Evhu81c2tzH9icR3FtIAsiEnFYGo3 Fze+Lruwt9Yt9CFpbRCS4ZQJrgY9T2Fc1EV/4RHxsqXkl7GLiPFxIOZOetAHcp8T9NFyqXNjfW0E y7reeSP5Zz6L71f0Hxva61dXdtNZXWnXFtH5rR3K4Jj/ALwrN8Twxn/hD1Ma7VuI8DHT5KfqRiX4 lXRnQvF/ZDeYqjkrk5/SgAg+JtlNcRF9L1GKwmk8uO/aP90xzgfhXXXtw1rYzzpG8rRxlgidW47V 5RHezeHdGt77QPEMF9pRkULpl2oaRQW+6o65FetKxktt2NpaPOPTIoA898C+NCnhe/vNaiu4o7eZ 38+bkPljhF9x0rY0n4hWuo6nBZXem32mvc/8e73KYWX6GuMWWMfDxN7CRLPWfMuYwclU8w5JHpXS +NdW07Vhodpp1xDc3ct7HJCImBKKOp46DFAHb3NxHZ20txO2yKJS7sewFcjY/Em0u7y3jl0rUba0 uX2QXksf7uQnp+ddLrZt10S9N4jyW/kt5qoMsVxzivM4L+68OWmnXGk+IbfVdKllSNLC5UGVATjC +hFAHZa345h0rU5NPs9MvtTuYVDTLapkRg9Mmkk8f6anhZddEU5t/OEMkZGHjbODn6VzUt3c6t4h 1rZr0Hh63tpQsiRqBNNx94k9awrXa/w1ul8154/7aUB5By43Dk/WgDt1+JtgLmSC507ULdypa2Dx 83Q/2BWjoHjSz1uK+M1tcafNYjdPDcjDKvrVHxFEh8ceEwUX5TJjjp8tYviaCWfV/GMdspMjadHw vU880Aa9v8TLKa5jMmmahDp8r7I7948RMegP0rsiFkQg8qwx9Qa8cmtfP8IQG58cySWUyJGLOOJS 2eMKF68V67YxmHT7eMszFI1XLdTx3oA868W+BvD9lqGhC3sAgur9Y5sMfmU9RWx4htLTwL4WuV8O 24tri9mSFCCThmOM/hVjxv8A8hLwz/2El/lUnxHs57nwu09shklsp0udg6sFOT+lAFBPhXozaXtl Nw+pMm43hlO/zOufzqj4n0y6fw34c07xBIlzL9uWOZlJAdcHGfwrpovG2hPoS6mdRtxF5e4qXG8H HTHXNcp4kuJPFnhfQJNTtmtlvNQA2IxDbOcHPYmgA8beENB8N6E2paSn2G/hlQwNHIcu24fLjvXo 1k7y2lu8oxI0asw9yOa5ix+GXh3Tr2O5WG5nkibcguJ2kUH1wa6xfvCgDzXwt4P0PXn1i61S0Wac ahKoZnI4qz4PktNA8QeJbK3uidFslSVSz7liYj5gDVDw34F0nxHLrF5fteCUahIn7m4ZBjPoK2vE /hm00X4carZaLbmMMm9yDud+eST3oAfafEqzuLuJZtM1C1sp32RXsseInJ6fTNX9f8aW+i362NvY 3epXpTzGhtVyUX1NcBeWn2jw1bfafHMlzaT7FS0jiUuT2UDrxVuSxu18e6rCviR9FleKJkZlX98g X1Pp6UAdn/wnWnnwvc62sU2y1O2e3YbZI2z0INXPDXidfEfntHp93axR4KSTrgSg91rzma1iTwZ4 qnj1aXVGkmjWWdowqswP8OOtes6YAul2gUAAQpgD6CgC0aYaeaYaAG0UUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAVyXxM1SfTPBd59nt55GmUxmSL/AJZD1PtXW1zfxEP/ABQWrf8A XL+tAGDoXiPS/CnhOwWHR72K6vDlLIDdLMQOX+hrd0nxxZ6rZX8htbm1urCMyTWk42yAYzWIt3b6 b430C51F1jgm0oRQyyHCq/cZ7HFQ6rd22qeMdYn010ljt9HkjuJYzlSx6DPc0AdD4a8bQ+J7kJa6 beRQNHvW5kX92T3UH1q94i8SWvhy2iknjlnmmbZDbwrl5D7CqvgBQvgLRgoABtgePWsrx1fTrrmk afa3Ntp8s+9hfzKCYsdlJ4BNAF/RfHEGrXNzaT6de6feQQmbyLlcFkHcVmL8VtPaCK5XS9QazJ2z XKplITnHJrB0pPI+Ic0Z1yXWJBpkoknbGAcdBir+mRoPgZcgKuDBISMdTuNAHaDxDbtr9vpYjfNz b/aIZsja49PrTrPXIr7XL/TYYnzZBfMlyNpJ/hHvXLa8f7N8PeGfEAB/4lqRGUjvGyAH+langC3Z tFm1OYfvtTne4Oeu3OF/TFAFzxJ4qtvDa26Pbz3d1ctiG2txl3x1Ncz4X1yHVviHq995ctsqWSCW OcbWjIPORV/WbqDTfifpd1qDrFbyWbxRSucKr5zjPY4rFvbmDV/FPiz+yGWVjpQQtF/E3se9AGyv xOsWuN39magNNL7BqHl/us5xn6Ve13xzZ6FqUVi1rcXU08HnQiAZMnPQCvPobYv4Hjefxw6WTRCN 7JYlLA9Nm3rmuhW5sdG8f6At/MFUaV5cUs3HzZHX0OKAOm0PxlYazZ3c0kc1jJZDNzBcDDxjrk1m 2vxLsp7mLzdM1C3sZn2RX0keImJ6fQGuc8TMNa1PxXPo7edEmnRxSSRchnDZOPXAzVG6tPP8LW32 nxzJPZzLGi2kcSls8YUL14NAHd6147ttH1mTShYXd3drEssaW4DGQHPT8qn0zxtpuo+H7rVnEtrH aErcRTDDxsOxFZOlQiP4ryq3zNHpMShmHPWuf1eJm0vxgUjLJHqUUkiqP4AATQBJ4h8ZR+IJ9Ch/ s6+sWOoxyRG4TAlX1Brrte8bwaPqX2C20+81O8VQ8kVquTGvqaw/GWuaRqA8NR2dzBPK9/E8YjIJ Re/0rKazuz481+NfEzaHK7rIqsq4lTHUE+lAHYS+PNNj8MHWxHKYUlEUsRGHiYnBBB9Ki0v4gWmo 61Dp8un3tn9pBNtNOmEmx6Vw91awx+CNZmj1OXUxNqUPmTvGFV2BwduOors/FqqNV8JYAGLvA46D ZQBQ8L+Jr2++IetWc9leiEsqoX+5AAD1+tdV4i8Q2vhvT1ubpJJWkcRxQxDLyMegFYXhyVIviJ4n ikkRZJGiZELcsMHoKn8fx6bNp9lFqV1NZM1wPs93H/yxk7E+1ADbXx4l9aahH/ZV/aajbQGUWsqY dx6rWH4U8etp/gBNQ1e0vWWOfyzM+P3u5jyPp0qfRNU1SDxDPot9qdprEb2UkiXUSjzE46MR61ht LFL8HdMg3o7x6kiyIDkr+9bqKAOy/wCFg2sekte3OnX1u7S+VBbun7y4JGQVHpVrw/4yt9bu5LOe yu9NvUTzPIulwWX1HrXP/EeCU+IPDsq6g2mQqzoLsKCImIGM545qpY2vkeMIZbnxLLrl3a2ssgjS NdoXHRmHr6UAbN18TLWCWZoNI1K6sIWKyXsUf7tcdav6v460/SG08GGe4XUIjJAYhkt6DHqa89nl n1DwVc6hceJorO3kjcppVmoGD/dI6/WtnSgJdS8AmQBiLFjz67aANlPibaSQSKmk6kdRjbDWAj/e gf3vpV7/AIT7TD4Xj1pY52SSTyVtwv7wyf3MetQ6Qi/8LR159o3fZYRnHPSuVt49Nk8JTxalcTWY bW5fIuoh/qZMjBPtQB2vh7xjDrt9JYzafeadeonmeTdLgsvqK6MVwPhrVNTtfGEejX2qWmsxSW7S JdRKPMjx2Yj1rvhQA8VkeIv+QNd/9cjWuKyPEX/IGu/+uRpPYzq/w5ejPJqgvP8AUH61PUF5/qD9 aywv8aPqfFw+JFGiiivpTsCiiigAooooA6bTtR0vU9Dj0vWpXt3t2JguFXdgHsRS3t9pOkaLNp+j yvdTXRHnXDrtAUdgK5ikrP2Svvp2N/bu1rK+1+p3H9v6b/a1vN9o/dppxgJ2nh8dKq2+o6XrGk2s Go389hcWgKB4wSJFz/OuRoqfYroyvrMnujsLTWdJtvEMj27yJaJaPCskmSZGI6/jWXouoW1rpGrw zSbZLiILGMfeOaw6Wq9kv68iPbyvt3/E6K+utPv/AAjYR/ail7ZAr5JThsn1rnaSlqox5dCJz53d hRRRVEBRRRQAUhpaaaBml4caIapia1a6Rhjy1OCfpXaTXGl3d1DZx6JO9wibTGH2lfrXM+CHC6rc qjqlw8DLAzHGGroo47jQdEvJ7wkajeHy4wWy+O5rJtN269NWbRTSv066J7fqzJ8XsLPSxZppZs1e QPvZ9xbHoa5fTGVNRhLx+YoPKf3vauo16Kaz8GJDfkiaS4DxI5yyrjk1heGHhj8SWTXGPLD8k9BQ nbz/AFCSvZbX/A7Wa70qO1gtJNEuFlZtyxliCc981W11V0zSLny9Ea386PYZXk3bf8DV+0trrTr6 81jVmDCJW8gswO9j0xWUguU8Patd6gzCC4ixGHP33J4IFLS107r1er8itbpNWfotEu+nU4QfdFeg 6Fd2Frp/n3WlSuFQo04J2kmvPR90V6R9gudXsNLjsWH2FY1EyhgAjfxFqptWtLYiKle8dWvK5Jb2 9rNbC7tfD0zop3KWmPOPbvXAajdG81W5naNYy7k7B0X2rvrqS41TxNEmmFhaWZVAynCqo6k1w+uy wzeIL6S3x5TSnbjpSW6v+uhUrcrtsnbZK/mrDLL/AF34VeqjZf678KvV42Y/xvkedW+I9H8Ef8gO P/eb+ddUvSuV8Ef8gOP/AHm/nXVL0qIfCj63CfwIeiOb8f8A/ItL/wBfdv8A+jFrpV+6PpXNeP8A /kWl/wCvu3/9GLXSr90fSqOgWiiigDC1vSLm/wBd0S7h2+VZSu8uTzggAYrZnQyW8iL1ZSB+VSUU AcLaeEtV0zTdIubNoP7T0/zFaNz8kqMeVz2rU0bRL+XVr3V9c8lbi4hFvHBEcrHH357kmumooA83 tfh7qNv4Q1Ww89Pt01wJLaTP3VQ/Jz9K7nQ9O/snRLSy4zDEFYjue/61fooA5GfR9c0jVtRn0FbW aDUm8xxOxUwyYwWHqKjbwzq+lzWGpafcpe6hBAYLkXDECcE5yD2weldlRQBw9x4T1S/0jWp7xoDq mpBFWND8kSKQQue/etfU9Furu+8Pyx7NthJumye20DiuhooA4O88K6u9h4i0+JIGg1CXz4Jd+Dkk ZUj8K2df0K8uxpl7prxrqGnHciyfdkBGGUmujooA4xvD2satPf6jqwt4rmSye1tbeJshM9ST7mtC xnudBttB0mSKN2lTypGDcqVXOQO9dHUbQxtKsrIpkQYViORQBzvxE3f8IRqO1trbVwfQ7hVG00fX Nal0r+2xapZWO2UeUxLTvtwCR2HNdZfWFvqVo9reRCWGT7yHoamRFjRUUYVRgD2oA4uHRfEeiR3W naOLKW0mkZ4biY4eDcckY747VpR6Fep4o0y/klE0dtZvDLIeGZzjnFdJRQBWOn2bMWa1gJJySYxz T1tooYnSCJI9wPCqBmpqKAMDwZo1zoWgCzvNnm+dK/ynIwzEj+dUI9K13w7dXSaHHa3dhcSGVYpn KGFj1we4rrqKAOIm8H6lN4b1Vbi4jn1bUpFkkIOI0weFX2Ars7dDFbRI33lQA/lUlFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQBCv+rXp07dKSlUYjUY28dPSkoAKKKKACiiigAqtqGnWmq2b2 l/Ak9u/3kcZBqzRQBjWvhDQrGKCO102GNbeXzoyo5V/XNX7LTLTTpbmS0gWJ7qTzZiP429TVqigD EuvBnh+91L7fcaVbvdZ3FyvU+pFbYAUAKAAOAB2oooAqW2lWdnPdTW8CpJdtunYfxnGOaiXQdNXS G0tbVBYtnMPY5OT+taFFAGbqfhzStZtIrXUbGK4hhwI1Yfdx6GmxeGtIginihsYo47iIQyqowGQd q1KKAMq78L6Pf2lpbXVhFJDZ4+zqf+WeOmKxPGvh6MeFr6PSbLNxdXEckqoMlyCOfyrsKOlAGNpP hXRtKuBe2enQQ3boN8irznHP0q7Bo9hbyXbx20Ya9bdcZGfMPTmrlFAGNpvg/QdHvmvNP0yCG4P8 ajkfT0rZIyCCMg+tFFAGHB4L8PW+p/2hDpVut1u3bwvQ+uOlWrzw7peoalFqF1ZxyXcQ2pKeoFaV FAFax02002xWzs4FitlziMdOetZtr4M8P2Wpf2hbaVbx3WchwvQ+oFbdFAGTqvhbRtbuo7nUtPhu Jo/uuw5pZPDGjyxXUTWEXl3YUToBgPt6Vq0UAVLjS7O7+y+fAr/ZGDQ5/gIGBj8KcdNtDqZ1Awqb sx+V5nfb6VZooAw4/BXh6HU/7Qj0q3F1u3b9vf1x0rcoooAy7bwzpFncXk1vYQo96MXHHEn1FR6V 4S0PRLprnTdNggnbq6jn8PStiigAIDAhgCDwQe9Ylp4L8P2Opfb7bSreO6zuDgdD6gVt0UAZF74T 0PUtTXULzTYJbtcYkYcn6+tPbwzpD28sDWMXkyzCd0HQuOh/StSigCrPptpc3ltdzQq89rnyXPVM 9cUqabaR6hNfJCouZ1CSP3ZR0FWaKAMSDwX4fttT/tCHSrdbrO7eF6H1x0rboooArXmm2t/JbvdQ rI1tJ5sRP8DetWT8wIIyD1BoooAwD4E8NNf/AGw6Pbefu3Z28Z9cdK1bzTLO/FuLqBJBbuJIgf4G HQirVFABRRRQBWsdNtNNWVbOFYhNIZZNv8THqaskBgQwBB4IPeiigDEtfBnh+y1L+0LbSreO6zkO F6H1AqxrPhvSfECoNVsYrnZ90sOR+NadFAGf/wAI/pf9j/2ULKJbAjBhUYU1pRIsUaxoMKoCgegF IKeKAFNMNPNMNADaKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKgvrG21OyltL2 JZbeUYdG6EVPRQBQv9C03VNOSxvrOKe2QAKjj7uPSmWHh3StL06WwsbGKG2lBEiKPvA9cmtKigCG ys4NOsobS0jEVvCu2NF6KKravoWm69bLBqlpHcxKcqHHQ+1X6KAMu38M6RZtC1tYQxNDG0SFBjCt 1H41LHoenRaO2lJaoLFlKmHsQeTV+igDkPGaXdxp0XhrTNMklivI1iM4/wBXAgI6++BXU2drHY2M FrEMRwxhF+gGKnzSUAUtV0ew1uzNrqdrHcwk52uOh9qi03w7pWjzGXT7KK3cxiIlB1Udq0qKAMQe C/Dw1T+0f7KtvtW7dv29/XHSsjWNAXV/iHbG+sRcacbBkcsvyhsjA+tdlS5oAo6Zo9ho1l9k060i t4O6KOv19ao23gzw/Z6l/aFvpVul1ncHC9D6gVt0UAVV0y0TVX1JYFF48YjaXuVHakg0qytnu2it 0U3bbp+M+YcY5/CrdFAGFb+CPDto++30q3jbzRKCByGHQ1Z1nwxo/iAodVsIblk+6zDkfjWpRQBn SeH9Ll0pNMayi+xIQywgYUEcg1PdaZaXsttJcQrI9q2+En+A4xkfhVqigDPfQNMk1pNXa0j/ALQQ bRP/ABYqxqGn2mq2b2t/Ak8D/eRxkGrFFAGZo/hrSNAWRdKsYrfzPvlRyfxqung3QY0nVNNiVZ5V mkUZwzqcg/nW3RQBW1DTrTVbRrW/t454H6o4yKq6P4b0nQEddKsYrYSffKjlvxrTooAxIvBnh+C8 mu49KthPMCHbb1z14q1DoGm28lk8VoitYqUtyP8AlmD1ArRooArRadaw6jNfRwqt1OoWSTuwHQVX /wCEe0v+zp7A2UTWs7mSSIjIZj1NaNFAGXo3hnSPD+/+yrGK2L/eZRyfxrVFJSigB4rI8Rf8ga7/ AOuRrXFZHiL/AJA13/1yNJ7GdX+HL0Z5NUF5/qD9anqC8/1B+tZYX+NH1Pi4fEijRSUV9KdgtFJR QAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtNNLQaBjI7p7Ry8YGTWrDcz3MCTSSEtj Iyc4rIdM1qWgxZoPY1dK97Gde3Kn1KN3qdxfkrcMWIPUnJqBJWgkEigEj1pfLw7fWhkyKy1N/d2N O0vZ72EmRzhTgAnIqve6rcyFraRi0afKoJ6CpdNXbC3+9VO6T/S3PvWkr8iMIW9o10IcfLV601S4 adYVOxW4OCaq7eKfZJi8Q1Ebpo1nZxbZfudQubGLEUhCyHDAHGay1Jdix6k5q9qS7o0+tU0XFVUv zEUrchbsv9d+FXqo2X+v/Cr1eBmP8b5HPW+I9H8Ef8gOP/eb+ddWvSuU8Ef8gOP/AHm/nV6/8OXN 9ePMmu6lbxv/AMsYnAVfpxUQ+FH1uE/gQ9EV/H//ACLS/wDX3b/+jFrpV+6PpXO2/gjT0uI57ye8 vpI2DL9pmLKCOhx0ro6o6AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAIV4jUYI46GkpyAGNcZIx360u 2gBlFP20baAGUU/bRtoAZRT9tG2gBlFP20baAGUU/bRtoAZRT9tG2gBlFP20baAGUU/bRtoAZRT9 tG2gBlFP20baAGUU/bRtoAZRT9tG2gBlFP20baAGUU/bRtoAZRT9tG2gBlFP20baAGUU/bRtoAZR T9tG2gBlFP20baAGUU/bRtoAZRT9tG2gBlFP20baAGUU/bRtoAZRT9tG2gBlFP20baAGinrSbacB igANMapKaRQBHRT9tG2gBlFP20baAGUU/bRtoAZRT9tG2gBlFP20baAGUU/bRtoAZRT9tG2gBlFP 20baAGUU/bRtoAZRT9tG2gBlFP20baAGUU/bRtoAZRT9tG2gBlFP20baAGUU/bRtoAZRT9tG2gBl FP20baAGUU/bRtoAZRT9tG2gBlFP20baAGUU/bRtoAZRT9tG2gBlFP20baAGUU/bRtoAZRT9tG2g BlKKdtpQtAAOlZHiL/kDXf8A1yNbGKx/EX/IHvP+uRpPYzq/w5ejPJqQgMMEZFLRXGnY+JG+Un9w flR5Sf3B+VOoqueXcd2N8pP7g/Kjyk/uD8qdRRzy7hdjfKT+4Pyo8pP7g/KnUUc8u4XY3yk/uD8q PKT+4Pyp1FHPLuF2N8pP7g/Kjyk/uD8qdRRzy7hdjfKT+4Pyo8pP7g/KnUUc8u4XY3yk/uD8qPKT +4Pyp1FHPLuF2N8pP7g/Kjyk/uD8qdRRzy7hdjfKT+4Pyo8pP7g/KnUUc8u4XY3yk/uD8qPKT+4P yp1FHPLuF2M8pP7g/KngADAGBRRXq5TJurK76CuxnlJ/cH5UeUn9wflT6K8uU5Xeo7sRVCjCgAUh jQnJUE06ivVxMn9Spu/9aiuxnlJ/cH5UojRTkKAadRXBhpy9tDXqh3YjKrfeAP1pPKT+4Pyp1FdG ZSksQ7PsK7ECKpyqgGloorz229wPR/BH/IDj/wB5v511S9K5XwR/yA4/95v511S9K6ofCj7LCfwI eiHUUUVR0BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUANj5jU5zx19aWkTlFyQeOop1ACUUtFACUUtFA CUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUt FACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUtFFABSUtFACU UtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFA CUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUUt FACGsbxF/wAge8/65Gtk1jeIv+QPef8AXI0nsZ1f4cvRnk1FFQ3ZxAfrXNSh7Saj3PikruxN+Io/ EVlZPqaMn1Nen/Zb/m/A29j5mr+Io/EVlZPqaMn1NH9lv+b8A9j5mr+Io/EVlZPqaMn1NH9lv+b8 A9j5mr+Io/EVlZPqaNx9TS/st/zfgHsPM1fxFH4isrcfU0ZPqaP7Lf8AN+Aex8zV/EUfiKytx9TR uPqaP7Lf834B7DzNX8RR+IrKyfU0ZPqaf9lv+b8A9j5mr+Io/EVlZPqaMn1NH9lv+b8A9j5mr+Io /EVlZPqaMn1NH9lv+b8A9j5mr+Io/EVlZPqaMn1NH9lv+b8A9j5mrxRWbFKY5A2TjvWkDkZHevSw WEhRV1uZzhyhR+NUruXdJtU8LUAdlIIJ4rkqZdTdROO3YqNJtXNSimxuJEDDvUF5LgBAeT1rvqYW lKkqbWi2IjFt2LPHqKKysn1NXLOXcpQnkdK4sLl8Kc7zd+xcqTirlmjj1psjiOMse1ZpZiSSTzWu NwUKz5lpIUKfMalFUbMkzck9KvV4WIo+xnyXuTOPK7Ho/gj/AJAcf+83866pelcr4I/5Acf+8386 6pelaQ+FH2GE/gQ9EOoooqjoCms6p95gPqadXnnxelki0ywMbshMrZ2nHaonLkjzHRhaH1irGne1 z0Dzo/8Anon/AH0KPOj/AOeif99Cvmn7Zc/8/Ev/AH2aPtlz/wA/Ev8A32a5/rXke1/YD/5+fh/w T6W86P8A56J/30KPOj/56J/30K+aftlz/wA/Ev8A32aPtlz/AM/Ev/fZo+teQf2A/wDn5+H/AAT6 W86P/non/fQo86P/AJ6J/wB9Cvmn7Zc/8/Ev/fZo+2XP/PxL/wB9mj615B/YD/5+fh/wT6W86P8A 56J/30KPOj/56J/30K+aftlz/wA/Ev8A32aPtlz/AM/Ev/fZo+teQf2A/wDn5+H/AAT6W86P/non /fQo86P/AJ6J/wB9Cvmn7Zc/8/Ev/fZo+2XP/PxL/wB9mj615B/YD/5+fh/wT6W86P8A56J/30KP Oj/56J/30K+aftlz/wA/Ev8A32aPtlz/AM/Ev/fZo+teQf2A/wDn5+H/AAT6W86P/non/fQo86P/ AJ6J/wB9Cvmn7Zc/8/Ev/fZo+2XP/PxL/wB9mj615B/YD/5+fh/wT6W86P8A56J/30KPOj/56J/3 0K+aftlz/wA/Ev8A32aPtlz/AM/Ev/fZo+teQf2A/wDn5+H/AAT6W86P/non/fQpVZXGVYEexr5o +2XP/PxL/wB9mvYfhPI8vheZpHZj9pbljnsKunX55WscmNyr6rS9pzX+R3FIWCjLEAeppa5T4lO0 fgy5ZGKtvTkHHetpPlTZ5tCn7WpGnfd2Oo86P/non/fQo86P/non/fQr5p+2XP8Az8S/99mj7Zc/ 8/Ev/fZrm+teR7v9gP8A5+fh/wAE+lvOj/56J/30KPOj/wCeif8AfQr5p+2XP/PxL/32aPtlz/z8 S/8AfZo+teQf2A/+fn4f8E+lvOj/AOeif99Cjzo/+eif99Cvmn7Zc/8APxL/AN9mj7Zc/wDPxL/3 2aPrXkH9gP8A5+fh/wAE+lvOj/56J/30KPOj/wCeif8AfQr5p+2XP/PxL/32aPtlz/z8S/8AfZo+ teQf2A/+fn4f8E+lvOj/AOeif99Cjzo/+eif99Cvmn7Zc/8APxL/AN9mj7Zc/wDPxL/32aPrXkH9 gP8A5+fh/wAE+lvOj/56J/30KPOj/wCeif8AfQr5p+2XP/PxL/32aPtlz/z8S/8AfZo+teQf2A/+ fn4f8E+lvOj/AOeif99Cjzo/+eif99Cvmn7Zc/8APxL/AN9mj7Zc/wDPxL/32aPrXkH9gP8A5+fh /wAE+lvOj/56J/30KPOj/wCeif8AfQr5p+2XP/PxL/32aPtlz/z8S/8AfZo+teQf2A/+fn4f8E+l vOj/AOeif99ClV1f7rA/Q180fbLn/n4l/wC+zXq/wglkl0nUDI7OROuNxz/DV06/PLlsc2Myn6tS dXnvbyPQI/uL06dulOpsYxGoxt46elOroPGCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAQ1jeIv+QPef9cjWyaxvEX/ACB7z/rkaT2M6v8ADl6M8mqC8/1B+tT1Bef6g/Ws sL/Gj6nxcPiRRooor6U7AooooAKKKKAAcEGu58O65DqX2mObR9O/0e2MikR8kj1rhq6Pwb/r9S/6 83rKtFONzow0mppIsaTqcWv+J7CObTrOGNdwKxJgNx3rmLkBbqYAYAdgAPrWx4L/AORrs/q38jWR d/8AH5P/ANdG/nRFWm0u3+YptypqT3u/0OrtjBoPheyvYdLivprvJkklXcseO1Zmvy6bf2Vrf2Uc dtcuSs9snQEdwPSrkF9q/hTTbSa3njnsrtd4Rk3Kp7jnoafrslvrHhiHVzZR2l2JvKbyxgSD1rOO kr+e/wDwDeVnBx7La34pnJ0UUV0nCFFFFABRRRQAUUUUAJW7Y6ZPJFBv4WTkEdhWFW3aXs9vEgjc gY6HpVxT6ETcVbmNJfDVmOXaRz9cU/8A4Ryw/uP/AN9Gqy63OB8yoad/bkv/ADzSo9nM0VakFzoq W0a/ZdxBbBB5xWVq2kS2OJmdXRjj3FaT6zcN90Kv4VmalcSzxZlctz3q+WdtTPnp83u9TNrZs/D9 ywWXzY1yM4zmsatZHZVG1iOOxpRi5bBOajuiW40e5mt/MDIoXPyscE1iEYJHpWuzsw5Yn8ayG+8f rTmmndipyTVkiez/ANf+FXqo2f8Ar/wq9Xz2Y/xvkZVviPR/BH/IDj/3m/nXVL0rlfBH/IDj/wB5 v511S9KiHwo+twn8CHoh1FFFUdAV5z8Yf+QZYf8AXVv5V6NXnPxh/wCQZYf9dW/lWVf+Gzvyv/e4 f10PJqKKK80+3CiiigAooooAKKKKACiiigAooooAKKKKACiiigAr2X4Sf8itN/18t/IV41Xsvwk/ 5Fab/r5b+QrfDfGeTnX+6/NHdVyXxN/5Eq5/30/nXW1yXxN/5Eq5/wB9P5121PgZ8zgv95p+qPDa KKK8s+8CiiigAooooAKKKKACiiigAooooAKKKKACiiigAr1r4O/8gjUf+u6/+g15LXrXwd/5BGo/ 9d1/9BrbD/xEeXnH+6S+X5nocfEa8EcdDTqbH/q1xnp3606vRPjQooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKAENY3iL/kD3n/XI1smsbxF/yB7z/rkaT2M6v8OXozyaoLz/ AFB+tT0hAYYIyK56U/ZzUux8VF2dzKorU8tP7o/Kjy0/uj8q9T+1I/ym/tl2MuitTy0/uj8qPLT+ 6Pyo/tSP8oe2XYy6K1PLT+6Pyo8tP7o/Kj+1I/yh7ZdjLq9pmqy6U07QqrGaIxNu7A1N5af3R+VH lp/dH5UPMoNWcRrEcruivpWpSaTqMV5CqtJGSQG6VsyeM2kVgdJ07LA5Pl81neWn90flR5af3R+V RLMKcndwLji5RVkT6X4rvNMtmtfLhuLZmLCKZdwU+1Qaz4gu9bMYn2RwxfcijXCrR5af3R+VHlp/ dH5U1mFNPm5NQeLk48vQy6K1PLT+6Pyo8tP7o/Kq/tSP8pn7ZdjLorU8tP7o/Kjy0/uj8qP7Uj/K Htl2MuitTy0/uj8qPLT+6Pyo/tSP8oe2XYy6K1PLT+6Pyo8tP7o/Kj+1I/yh7ZdjLrUi/wBUv0o8 pP7o/KndAK7sFi1Xk0laxnUqcwUUUV6BmFQXn+o/Gp6QgMMEZFZV5+zpyn2HF2dzKrWHQfSm+Wn9 0flTq5cFilX5rK1i6k+YKym+8frWrTfLT+6KeNxSoct1e4U58pTs/wDX/hV6kCKpyFANLXz+JrKt PnSsTOXM7no/gj/kBx/7zfzrql6Vyvgj/kBx/wC83866pelXD4UfYYT+BD0Q6iiiqOgK85+MP/IM sP8Arq38q9Grzn4w/wDIMsP+urfyrKv/AA2d+V/73D+uh5NRRRXmn24UUUUAFaWjaBqGvyyR6bD5 rxruYbgMD8aza9D+ET+XqWoueiwZ/WrpxUpJM5sZWlRoSqR3RxVpo97e6qNNhhJu9xXyyccjr1q3 a+E9XvNUudOgtg11bf61N4G38a9MGkwX3i3S/EumDME5ZZwOzYIzUHh5zH8SPErjqq5/lWqoq6v3 POlmc3GTglpG/wA72aPL73R73T9U/s+5hKXWQuzIPJ6c1c1fwlq+h26T6ha+XG7bQQ4OT+FejXem R614t0bXFXNuYWklPbKUzx5qcdz4Z0rUMb4/tYfHqAT/AIUOikmxxzGpKdOKS139ddPwOFtvAPiG 7tlni09tjDI3MASPoaw72yuNPuXt7uJopk6qwwa9gunt/FpgvdE8RPaXCKNsBbAz7rXn3juLWYtY Qa75TTbMJLGuA61NSmoq6NcHjalWpyVLJ9tU19+5zNFFFYnqBRRRQAV7L8JP+RWm/wCvlv5CvGq9 l+En/IrTf9fLfyFb4b4zyc6/3X5o7quS+Jv/ACJVz/vp/Outrkvib/yJVz/vp/Ou2p8DPmcF/vNP 1R4bRRRXln3hqaR4b1TXdx060eVV6t0X8zRq/hvVNCK/2jaPErdG6qfxFdz4r1C48OeDtHs9Kc2y zpukdOC3HrXON4w1O98KTaZd2zXcZbi5cElPbNayhCOj3POpYjEVbVIpcl7edtr9vkcrRXeSeH9B 8M6NZ3GvpcXV3drvEUTbQgp134M04alot5YtLJpOoyBSjH5l9s0vZSNPr9Ls7a2fR27HA1YsbC51 K5W3s4XllP8ACor0SXw94Rt/Fg0JoLt55iAGEnyxkjIFX/BGm2eh+J9Z04I7zQrkSk/8sz2+tUqL vZsxqZlFU3KMXe11ft3PJpEaORkcYZTgj3ptej6LoPh7Xpdau5LeeG3tmyB5nIx1NUNI8P6J4k1C 4ubaKez0qyi3TF33M5/pxU+yfQ1+vwV+ZNWtf59Dh60m0DUF0ZdVMP8AobNtEm4dfp1rrbHQvDXi uG7t9EjurW9gUunmtuEgqa5Ro/hFEjjDLdbSPfdTVLdsmeO1jGKs7pNPszitW0K/0Qwfb4fK89N8 fzA5H4Vn16n4v0Ztf17w7YK+wSW2Wb0Axmnf8IDpN5cXGnw6dqFs8any7yRso7D2pui7vlM4ZnBU 4uru9dO17HlVFegaF4V0ceGNQv8AWo5mksp2R/LbGQMDGK4vVZrGe+d9Nt3gtuNqO24/nWcoOKTZ 2UsTGrOUYp6dehTr1r4O/wDII1H/AK7r/wCg15LXrXwd/wCQRqP/AF3X/wBBrTD/AMRHHnH+6S+X 5nocZzGpzu46+tOpsZzGpyDx1FOr0T40KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoqvfXkWn2M91O dsUKF2PsKzdA1KabRYL3VZo4numLxqxC7VP3V+uKANqiq41C0a3a4W6gMKnBkEg2j8aa0631hK2n XMTuykRyIwZQ2OOlAFqiuXs9Q1TxF4UJ0+5is9VjcwzM6bgrqcHj361zUB8cz+JLrRxr1mJLeFZj J9n4IbPGPwoA9NorOtLn7BYQxatfW5u1jzK5YIG98HtVibUbO3iSWe6gjjf7rvIAG+hoAs0VCby2 EAn+0ReSeBJvG0/jSRX1rPO0MVzC8qfeRXBYfUUAT0VWn1CztZVjuLqCKRuivIFJ/A1JJdQQsqyT RozglQzAZA64oAloqqNSsjbG4F3bmAHBk8wbQfrVXV5ZptPik07ULa2LSr++kIKsueQPc0AalFc7 ZeK4bvxle6JuhUW0SMreYMuxzkAe1T+L9d/4Rzw1eX6NH58afulc4DN2+tAG3RXN+FdRuBoiT65q 9lcTTDzVaNgqquOnXtW3LqFnDAs0t1AkT/ddpAFb6GgCzRUAvLY232gXERg/56Bxt/OhL61kmaFL mFpVGSgcEgeuKAJ6Kgt7y2u932a4im2nDeW4bB98U1tQs1ufs7XUAnP/ACzMg3fl1oAs0VDc3dvZ x77qeKFP70jhR+tPimjnjEkMiSI3RkOQfxoAfRUc08VtEZJ5UijHVnYAD8TUH9p2jWUt1FcwyQxq WZ1kBUY96ALdFYXhDxIninQ0vwI0dmYGJWyUAPGa1p761tmKz3MMRA3EO4GB680AT0VWm1Gzto0k nu4I0f7rPIAG+hrN8S+I4NB8OT6ojRTBQPLG8Yck9jQBt0VStNUtp9KhvnuIVidAxfeNoJHIzVi3 uYbqISW80csZ/ijYMPzFAEtFIzBVLMQAOST2qG2vrW83fZbmGbb97y3DY/KgCeiqx1CzFz9mN1B5 /wDzz8wbvy60+W7t4GKzTxRsF3EM4Bx6/SgCaiooLmG6iEtvNHLGf4kYMPzFRw6hZ3EzQwXUEkq9 USQEj8KALNFRx3EUzukUqO0Zw4VgSp9D6Uz7dalA/wBph2FtgbeMFvT60AT0VXTULORZGjuoGWL/ AFhEgIT6+lPt7mG6iElvNHLGejIwYfmKAJaKqpqdlJcG3jvLdph/yzEgLflXOxeIp4/iFf6bdXEU enwWaSrvIXDE+poA6yiud8Za1NpnhK51HTJozIu3Y4wy8kCtZL+GHT4J7yeKEOiktIwUEke9AFyi mRSxzRiSJ1dG6MpyD+NZ+o/av7S0/wAi+gt4vMPmxOBumGOi0AadFVX1OxjAL3luoLbBmVR83p16 1keKPFUXh1tOQ+UWvLhYsu4ART1agDoaKrz39pbRJJPdQRRv91nkADfQ1MjrKgeNlZW5DKcg0AOo qOe4htYjJcSpFGOrOwUD8TXN2OvXF38QrzTUmjksI7KOaPbg5Ynk5oA6iiq39oWf2n7N9qg8/wD5 5+YN35dafc3lvZoHup4oVPAMjhR+tAE1FYXijxNB4f8ADkuqIYpgMCMbxhyTjg96fBdzXupWFzBq Nr9iktyzwAgtI394H0FAG1RVX+1LHMY+2W+ZOEHmr83055qaaeK3iMk8iRxjqzsAB+JoAkoqmdUs zYzXcVzBLFEpZmSQEDHvXO6X4jn8T+HLa+s721sZWuAJFdg3yhvu/UigDrqKr3F9a2e37Vcww7un mOFz+dPe5hjjWR5Y1jbADFgAc9OaAJaKgivbWeZ4obmGSRPvIjgkfUVPQAhrG8Rf8ge8/wCuRrZN Y3iL/kD3n/XI0nsZ1f4cvRnk1RXLskOVODmpagvP9QfrWOGSdWKfc+Lh8SKv2iX++aPtEv8AfNR0 V9F7Gn/KvuOvlXYk+0S/3zR9ol/vmo6KPY0/5V9wcq7En2iX++aPtEv981HRR7Gn/KvuDlXYk+0S /wB80faJf75p1m8Ed3G93G0kAPzopwSK66JPDEuhz6kNLuAkMqxlPN5Oe9ZzhTj9j8Ea06Cn1SOP +0S/3zR9ol/vmt6x0uw13Vp5bdHstLt4/MlLNkgfX3q5b23hfWZ2sbNLi1nYEQzyN8rH39KTVJfY /BFLDX7eXmcr9ol/vmj7RL/fNdHo+m6bBpOo3erW73BtZhGFR8VKmn6Hr2nXh0uCe0u7aPzQrtuD gdaGqSfwfggWGultfscv9ol/vmj7RL/fNRUta+xp/wAq+4w5V2JPtEv980faJf75qOij2NP+VfcH KuxJ9ol/vmj7RL/fNR0Uexp/yr7g5V2JPtEv980faJf75qOij2NP+VfcHKuxJ9ol/vmr8ZJjUnri sutSP/Vr9K2owjFvlVjGskkrDqKKK6DAKhunZIsqcHNTVDdgmA4BOD2qZpOLTKh8SKn2iX++a0R0 H0rKHJrVHQfSsqEIxvyqxpWSVrBWcbiXJ+c9a0ay2BDEEYOaK8IytzK4UUne5ZtZXeXDMSMVbqjZ /wCv/Cr1fO4+KjWtFW0Jqq0j0fwR/wAgOP8A3m/nXVL0rlfBH/IDj/3m/nXVL0qYfCj67CfwIeiH UUUVR0BXnPxh/wCQZYf9dW/lXo1ec/GH/kGWH/XVv5VlX/hs78r/AN7h/XQ8mooorzT7cKKKKACu w+Huu2Gh3V++oTeUssGxOCcnNcfRTjJxd0ZV6Ma1N05bM7zwD40g0S6ubTUJCtlKxdGxnY2fT3qz pPirSrbxlrt/Lcbbe6UiFtp+bivOqKtVZJJdjmnl9KcpS25lZno2jeNrOx8EXtnJMftoMiwLg8hv ft1qneeKLD/hDdEto2Wa6s5Q8sLqcEAnrXC0Ue1lawLL6Slzed/wsejzXXgXVp47+WW4sJ8AvFEC oyPoKwfHfia28RX9uLFHFtax+WjP1b3rlqKJVG1axVLBQpzU+Zu213sFFFFZnYFFFFABXsvwk/5F ab/r5b+QrxqvZfhJ/wAitN/18t/IVvhvjPJzr/dfmjuq5L4m/wDIlXP++n8662uS+Jv/ACJVz/vp /Ou2p8DPmcF/vNP1R4bRRRXln3h3+neJ9D1zw9BpXicSRPbDEVxGO1M1vxLoum+Gn0Tw2ryLMcyz uOf/ANdcHRWntXY4VgKale7te9r6XO+n1vQPFejWUOtXMtjeWahPMVNwcf5FOu/GGmDUtEsLEuul 6dIGaVxyx9cV5/RR7Vh9Qp7XdtbLornaXWv6fJ8T4tWWfNksqsZNp6BcdK07Hxhpdt4/1K+eY/Yr uMIJQp449K84ooVVr77hLAU5Kzb+Hl+R6Fp2s6FpFlr1tBftKt2pMTNGRuJHSsbwV4mttEe7tNRR nsbxNkm3qvbNctRR7R3TXQr6lDllGTb5rX+R6Bp+r+G/CEV5daRdTX15OhSJWTaIx71TuPENjN8O 005p83xuPMZMHpnPWuLoo9q9hLAwvzSbbunf02PRdX8bWEXiDQ7+yczpaweXMoGCM4zjNLqOraDd T3F6niPVEEg3LbR5G1vT6V5zRT9q+pKy6nG3K2radO9+x2tj4hsY/h/qenS3DG8nlZkVgSWHHJP4 VxVFFRKTlY6aVGNJyceruFetfB3/AJBGo/8AXdf/AEGvJa9a+Dv/ACCNR/67r/6DWmH/AIiOHOP9 0l8vzPQ0+4ucZx26U6mxjEajGOOg7U6vRPjQooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAOV+JMjJ4Lu lU4Erxxt9CwBrK+JFlHc6RoFmSVie9ijO3g4xiul8YaU2teF76zj/wBaybo/94cj+VZUtg3jPQdD uoZ0iNtMk0gYZ5Xgr7GgDlPF2m2ula7pehafotxe6Z5b3MljbPjzGzjJz1FX/BEV3Z+L5FtPD15o 2lzW5MkMzhl8wHgqO1dR4o8Ly61Pa3+m3zWGp2mRFOF3AqeqsO4qLw94bvdLvrjVtf1X7detHs3K uyONBzwtAFfwk5j8YeKrZQfLFwkoHYFl5/lS6d/yVPVv+vGH+ZqTwNA841TWZBj+0rpnjB/55r8q /wBa0bbQpIPF15rBmUx3FukIjxyCpPOfxoA5bxLotpr3xS0y01BDJb/YZGePJAfB6H2rM1+z0n/h J5LKPRbzXzawpFHZxkrDajHc55JruZ/D8kvjS11wTqI4bZoDFjkknrmsq/8AB+rp4hutQ0HWhYxX uDcxPFvJI4yp7GgDgF84fDfX7N4XtBDqcapAX3eQCw4Brp9R8Maf4Z1zwve6Ujw3M1yIbiTeSZlI 53Vc/wCFbzR6HqmnRaiG+23UdyssqksNpBOfXNdDrfh+TVZ9HkSdUGn3CzMCM7wBjAoA8/8AEGlR WfiLVrvxFoFzqtncyboL22cs1suOm0dCKsajZafrd/4Ltra6uLiwkSQCR2xI6gdGP6Vv6h4N1xNT vZtB14WdrfMXmhli34J6lT2qxbeBhYXXh9rW5Hk6SH3BxlpSw5PtzQBz1h4K0h/Hup6S0Lf2VHBH OLPefL3njOM1lPH9m8AvaKzGG110RRBjnaoYYFelWugyW/i691gzKY7mBIhHjlSvfNYc3gOeXRJ7 EXsYaXUvtwbYcAZzt+tAFLRdC00fFzWphaJ5kMMUsbc/K7ZyfxrT+KWn2t74GvpLmFZHt1DxE/wt kDNWpfDV/H44XXLG/jit5o1iurdo8mQLnGD2rQ8UaM/iDw7d6bHKsL3C7Q7DIHOaAPPrrwtpc/in wrpf2YJYvYvJJCpIDnGTn6mn+IrLSIvEi6dHo93rotbdUj0+EkRWwPcnPU12J8LynxHo+p/aE2af atbsm05ckYyDVHVfCGrHxHPqugaytgbxVW5R4t+7bwCvoaAOFsjJH4E8ZWT2rWSW9woS1Z93k5Gc A1paz4QsNOt/DU1mZYbq8lSG5uFc75VZeQTW9H8OpoNJ16yTUfM/tVkkEsqksGA5J9c1tar4al1C HRUW4RDp0ySMSud+FxgUAct/Z1r4P8a366LH9nhbR5LhogxKl16Nz3rkrO0a+8PC5Pg7VbnVJ1My 6os3O88hh7V6zceHDdeLP7VllRoGsmtXhI5O45zmud/4QDXIYG0u08RtFobEjyPL/eqhOSobsKAM vX9P1G/TQ9S1bRpNXt4rPbdWKyYZZP7+M810Xw6m0drG8j0X7ZCiy5ks7rg27Y6AelS6z4PvXns7 vw7qh0+7tYRb5kXejp7j1q74W8NTaH9rub+8N7qF44eeYLtBxwABQBg/ER7GbVNMtbyC71M4Z10u 3H+t/wBpj6CsHwpaRjxTrOmzaI+l2Vzp+82Lybh16+1dn4m8LX+o6ta6tompLYX8CGIs8e9XQ9iK h0bwXdad4ik1a71Nrya4tvJnLrglvVewHtQBV+Eem2ln4LhuLeBY5rh2Mrjq2GIH6VU8Q6HZ6/8A FWztdRj822GnszR5ID/Nxmt/wd4cv/DNvcWdxfx3NnvLWyCPa0YJyQT3qxJ4fkfxrFrnnqI47UwG LbySTnOaAOF1200p/FFxZx6JeeIWtokiS2QlYbQemfWsmC0juvhd4gtr20Mf2G+Jhgdy3kEkDAPs Ca7q98HaxFr95faFrYsYL9g1zE0Qc7hxlT2ptn8Pja+Htc0k3xePUZPMSVhlkPXn15FAHK+IIIrf UdC0W20W41DTYrL7S1hbPt3scct6itbwJFd2fiyeO20C80bSpoNxgncMokB6r6ZrSm8E6tPYafP/ AGysWuWCmNLuOLCOn91l71peGvDN9pt/PqWtamdQ1CZRHuVdiIo7KtAFX4ivLLpun6ekrRRX96kE zIcHYeoz71S1DwnpnhDfq2hyCwlitpFMAbIuDjgkE9RXS+JvD8XiTSGs5JWhkVhJDMnWNx0NYeme CdQm1NL3xRqq6m0MTRQRrHsVQwwSR3OKAMCLwNpc3w+/tiQudXa3N39u8w7w+N3X0qMWcfi3xZ4b /tXc8c2kmSZASBIc9DjtmtQ/DvWRbnSIvETLoBbm38v96Eznbu9K6BPC3keKbDU7eVEtrOzNqsO3 nrwc0AcxpejNp9/4v0PRZDbQmFWt0L4WJ2U9CelYuiW+j6Rqelwatol/omqRyqovY2LR3DdMM3oa 76TwkLjU9bnuLj9xqkKx7UGGjwMZzWRb+BNbnms7fWtfF5pdnIskcKxbXYr93c3egCz4JGPFHi3I x/py/wDoNcVcQC58B2cO4oJNfZSynkAueldrqHgzVf8AhIbu+0XWvsVvf4+1xGPcSRxlT2OKhi+H s0Hh2y0xL5D9l1AXe9lPzDOcfWgDKvfBWlWvj7TtOtY3hsbu2d7qBXOJyvTdzS6bBaeHX8Z2Fvcv YadbhGQrlvJ3KM7R+Ndnd6FJceLLHWBMoS2heIxkctu75rNu/BP2+fxD9ouR5WrBAoQfNGVAGffk UAeZanDBZ6TaX+m+Fr2xaGaJv7UnkKvJk9ce9dfc+HbHxH8WL1NTUy28VhExh3EK5PrjrU958Ptd 1jSvseseIRcLCym3VIdqjaeC/rV3VvBWq3HieXXNL1hLK5a3SFR5e5eOu4dxQBy2p2q6NovizRLZ 2NjbSQyQIzZ8rcRlR7U3WZm1Pxe0F5oF5rlpZWkQjt4XwiEryzDua6v/AIQCU+FtQsZdQ87UtRkE txdyLwzA9APSptW8G6g+oQ6noGqjT9QECwTFo98cqgcZHrQBS+G6X1tc6pbSaXdabp25Xtre4fcU J+8B7VZ8Yj/is/CH/X3J/wCgVreF/Ds2hxXEt9fPfX90++aZuB7BR2FLrfh+TVtc0W/SdY106ZpG QrkvlcYHpQBwmgeENL13T/El1qUTTSJdziLLECIgZyPeqt7YW2seFPBUuoxC4ke5WBncnLJk8GvQ NB8My6Pp+q2z3CSG+nklVguNoYYwazLnwLdv4O0zS7bUI4b7T5RLFceXldwJPT8aAM+08N6d4n8Y 6xDq0IntNMEdta2pY7IxtznHrWj4DjOl6pr2iRyvJaWM6m33tkorLnbn2pNQ8G6x/aA1TRtZSy1K aJY7xjFujmIH3tvY1seFfDQ8OWUwluXu7y5k824uHHLt/hQBieKbGLxD470nRdQy+ni2kuXh3ECR gcAGsaLTofCPi/xI2l5SOPSPOijLZ8sjsPauu8U+F5tamtb/AE29NjqlpkQz7dw2nqpHcVQ0PwPd Wes32oaxqQ1B7+18icFNv5egxQB51bWT3Ph5LiPwdqsmqyp5y6qJuS55Df7tdJ4j0++vLjSdU1bR JNZtEsgs9kkmGik7vjPNaY8Aa4kH9lR+JHXQs48jy/3oTP3Q/pWnrXhG/e9tr7w7qv8AZ91DCLdh InmI6DpketAHFalb6BffDDUhpqXWy2uVYW13kNauWAIA9MGtv7Bbab458P21nCsMCaRPtRegyMmt SPwFI/hjVbG81AzahqjCSa62YAYEEYHpxT7Hwjqa6rpmoalqMNxNZ2cls5SMrv3dD+FAHFaX4S02 8+GN7q1xGz30Zmkhl3HMO1jgL6VreI7m1vNL8NxajFeanLJbiX+zrfrcHb95j6Cum0/wjNZ+BrjQ WukaSVZAJQpwNxJ6fjVTUfBWoMuk3Wkaotnqen232YytHuR078UAcp4Zs4x4q1fTpdDbSrK500ub F5NwOD94+lVbLTLSz+G2jzW8CxyT6nGZWHViHwP0rudI8FXVj4jbV73UzeTT2pguC64JOeNvYD2q hB8PtTj0ldMk1WGS1gvFubcGIgoobJU+tAEOm+HbDxl4k16616P7WLaf7NBEzHbEoHUAd6wNSjkg 8Eavo32iSSGx1aOCCRmyyoWGBn2rstV8G6qms3GpeGtYGnPeAfaY3j3qxHG4DsabJ8PtvhIaTDe7 riS6W6nuZVyZHDAn+VAGXfeGdP8ADPinwxc6UjQTXE5huGDk+cCuct616RWJrOgSapqOj3KTqg0+ fzWUjO8YxgVt0AIaxvEX/IHvP+uRrZNY3iL/AJA95/1yNJ7GdX+HL0Z5NUF5/qD9anqC8/1B+tZY X+NH1Pi4fEijRRRX0p2BRRRQAUUUUAFdDa/8iBqH/X1HXPVpQ6qkXhy50wxMXmmWQPngY7VE03a3 c1pSSbv2Zp6AGk8Ja9HHzJhGIHXaDzXP2lvLd3MUFspaaQ4QDqTVzQ9Zm0S+8+JVkRl2SRt0dfSt pfFOk2JkuNJ0byL1wcSO+4Jn0FQ+aLdle5ouScY8ztb+tCbQoLSDwxq8Os+ckSTqsgi5YNVdtZ0T SdNuodDiunuLlfLaW4wNq+1ZcOtBNDvrKVGeW6lEnmZ6YrKoVK7bkOVblilHt8xKWiitjlCiiigA ooooAKKKKAFjOJFPoRW68lvOdzho3PXbyPyrCT76/WtStaauY1ZWsT+RGfuzp+IxR9mH/PeL86go rSz7mN12LAghH3rgf8BGac1xDBBIsCFmZSCz/wCFVaR/uN9KTjfcalZ6Iz7ditxGw6hq2Tco5y8C E+o4rFh/1yfWtKoppNGlWTTLAuY0OVt0z781l6hK012ztjJ9BVyqF3/rz9KdRJIVKTbsLZ/6/wDC r1UbP/X/AIVer5vMf43yFW+I9H8Ef8gOP/eb+ddUvSuV8Ef8gOP/AHm/nXVL0qIfCj63CfwIeiHU UUVR0BXnPxh/5Blh/wBdW/lXo1ec/GH/AJBlh/11b+VZV/4bO/K/97h/XQ8mooorzT7cKKKKACii igAooooAKKKKACiiigAooooAKKKKACvZfhJ/yK03/Xy38hXjVey/CT/kVpv+vlv5Ct8N8Z5Odf7r 80d1XJfE3/kSrn/fT+ddbXJfE3/kSrn/AH0/nXbU+BnzOC/3mn6o8Noooryz7wKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACvWvg7/yCNR/67r/6DXktetfB3/kEaj/13X/0GtsP/ER5ecf7pL5f mehxjEa8EcdD2p1Nj/1a9enfrTq9E+NCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKgtbKCyR0toljV 3LkL03HqanooAKjmhS4geGVd0bqVYeoNSUUARwQx20CQwoEjQbVUdAKkoooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAQ1jeIv8A kD3n/XI1smsbxF/yB7z/AK5Gk9jOr/Dl6M8mprosi7WGRTqZLJ5SbiM1y01JySjufFK99Bn2SL+6 fzo+yRf3T+dR/bl/uH86Pty/3D+dd3s8b5/eactQk+yRf3T+dH2SL+6fzqP7cv8AcP50fbl/uH86 PZ43z+8OWoSfZIv7p/Oj7JF/dP51H9uX+4fzo+3L/cP50ezxvn94ctQk+yRf3T+dH2SL+6fzqP7c v9w/nR9uX+4fzo9njfP7w5ahJ9ki/un86PskX90/nUf25f7h/Oj7cv8AcP50ezxvn94ctQk+yRf3 T+dH2SL+6fzqP7cv9w/nR9uX+4fzo9njfP7w5ahJ9ki/un86PskX90/nUf25f7h/Oj7cv9w/nR7P G+f3hy1CT7JF/dP50fZIv7p/Oo/ty/3D+dH25f7h/Oj2eN8/vDlqEn2SL+6fzo+yRf3T+dR/bl/u H86Pty/3D+dHs8b5/eHLUJPskX90/nR9ki/un86j+3L/AHD+dH25f7h/Oj2eN8/vDlqEotYgc7T+ dS1WF6CQNh596s16mXRrRUva+RElJfEFFFFekSFBGQQehooJwCfSlLZ2AiW2iVgQOR71LVdLwO4X YRmrFcGXRqxhL2u9ypKS+IKje3jkbcw5+tSVBLdCJ9pUmrx8ajpfut7hFNv3R6QRxtuUYNSVDDci Z9oUjjNTV83WVRStU3CSaep6P4I/5Acf+83866pelcr4I/5Acf8AvN/OuqXpW0PhR9hhP4EPRDqK KKo6Arzn4w/8gyw/66t/KvRq85+MP/IMsP8Arq38qyr/AMNnflf+9w/roeTUUUV5p9uFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABXsvwk/5Fab/AK+W/kK8ar2X4Sf8itN/18t/IVvhvjPJzr/d fmjuq5L4m/8AIlXP++n8662uS+Jv/IlXP++n867anwM+ZwX+80/VHhtFFFeWfeBRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAV618Hf8AkEaj/wBd1/8AQa8lr1r4O/8AII1H/ruv/oNbYf8AiI8v OP8AdJfL8z0OM5jU53cdT3p1NjOUU5B46inV6J8aFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQBQ1vV4NC0i41G5V2igXcwQZJ+lcovxW05QslxpWrW8BwTNJbHao9SfStP4jMF8 Camx6BAT/wB9CufuPiX4fufDbWNstxeXT23lLAtu3zMVx6UAeg2t1De2sVzbSLJDKoZHXoQarHVF Gtrpv2efc0Xm+bs/d/TPrXn32rxB4b0XwlounGKK7vFeORZVyE7j8ga1YNf1nR/ES2GtXcNxHBpr 3MzRR7d7A9RQB3dFeaf2z43k0Y+JkkshY484aeY/nMXru9cVa1XxJruqeIdLsfDk8EEWoWP2jfMm 7y/egDr11uH+0L21lilhWzjEjzyLiMg+h9qbLr1uq6e8EU1xFfNtjkiTKqMdT6CuF1jU9du7fxTp E95Bus7CN9wi4OR8/wCdLoOpa1o2heEoJbyKWO+lCYWPGItuQv196APTaK828Wz+MNBjkuk8QWhE 0uy1tVtsu5J4UVLqXiTXbX+zNCN/YWmrSW3n3l5c4CR89AO5oA9EorjfB/iS8utWutF1S8s765gj E0d1aEFZEPHIHQitfxXqOo6dpIbSYY3uZHCB5ThIgert7CgDborznRPE+rWnjCz0nUda03V4rxW5 tQAYmH0qC21nxnrUOrTabd2cEWn3MiqZIsmULzt9uO9AHptZj67bR+I4tFKv9pkgM4OPl2g4rlbj xjqmpaFoMekRwxapq4PzSDKRBR8zYqno8etQ/FW3h16SCaZNPYJPCu0SLn07UAek0Vz3jrVrvQ/C d3fWBUXEe3buGRyaxmvvF+n6Ebm4ks7i5vGTycJtS1Ujkue4FAHdVWtNRtb551tZlkMD+XJt/hb0 rgNI8TazbeK7fR73XNN1Vb2N9r2ygGFwOM46is3wjf6l4Z07xPqt/dxT21vcSAwqmC82Rhs9hzQB 61RXly+Lte0qODVdQ1rRry1lZfOsYGXzIlY9j3IzXpctwEs3uEG8CMuAO/GaAJqzLfXba51+60hF f7RbRrI5I4welcJoviPxXripqdjqGlzq0uG0rhZETODknvinXi65cfE/VYNBkgtpZLOIyTzLuEY9 AO5oA9MoriNE8T60/h/WEvLaO61bS5jB+6+VZTjIPsKxD4r1/RtU05tQ1zSb9LudIpbOADfEGPqP SgD1KivPZtU8Wax4r1nStGubW2gs2UieaPdjI+6B3zS/8J/e2fhG5lvoYV1m2uvsTKTiMydmJ7DH NAHoNFecWPijWNH1axXV9a0nVLW9kETLaMA8DHp06ivR6AENY3iL/kD3n/XI1smsbxF/yB7z/rka T2M6v8OXozyaoLz/AFB+tT1Bef6g/WssL/Gj6nxcPiRRooor6U7AooooAKKKKACiiigC4umTNpD6 iCvkpKIiO+TWyPA12EjMt/YRM6hgjy4OD04qOH/kn9x/1+r/ACrY8SeFtU1a/t7mziRoTbRruaQL yB6VzyqO9r23OyFFON1G+i/U5XV9Fu9EuRDdqPmG5HU5Vh6g1Qrp/FxW2sNJ01rhZ7m0iYSspyAS ema5itacnKN2YVoqE2kFFFFWZBRRRQAUUUUAFFFFACp99frWpVGyiSa7jSVtqE8n0rYk06ZOUAkT synNa02luY1Yt2sVaKe0Ui/eRh9RTdreh/KtTnsJSP8Acb6VIsMrfdjY/QVYj02RhmciKPuWPNJy SKjFt6Iwof8AXJ9a0qhsba3kvpEklKomdjY6/WtE6e55SSNx7NWdNpLU1qxbehUqhd/68/StoadL /E0aj1Liqeq2lvDCrpNvmzhgOlOck1oFKLTuylZ/6/8ACr1UbP8A1/4Ver5vMf43yJrfEej+CP8A kBx/7zfzrql6Vyvgj/kBx/7zfzrql6VEPhR9bhP4EPRDqKKKo6Arzn4w/wDIMsP+urfyr0avOfjD /wAgyw/66t/Ksq/8Nnflf+9w/roeTUUUV5p9uFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABX svwk/wCRWm/6+W/kK8ar2X4Sf8itN/18t/IVvhvjPJzr/dfmjuq5L4m/8iVc/wC+n8662uS+Jv8A yJVz/vp/Ou2p8DPmcF/vNP1R4bRRRXln3gUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFetfB 3/kEaj/13X/0GvJa9a+Dv/II1H/ruv8A6DW2H/iI8vOP90l8vzPQ0+4ucZx26U6mxjEajAHHQdqd XonxoUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHOePoJbnwXqEUMbySMgwi DJPzDtWtptrFHp9qfIjVxEmfkAIOBV2igDj/ABTbTy+NvC0scMjxxTSF3VSQvy9z2qprWlT6l8QZ o1jcRT6TJCJdp2hieBmu7ooA8sXxDrMHhgeFv7AvTqoj+yrKE/clem/d9K1tN0e40vx1okJjdorb SjE8oU7d3pmu9ooA89n0y6uvFPjJFgk23NgiRMVOHO08A96y7Ka41DT/AAhGNOvYX0668qdZIiMY Xr9PevVqKAPI4vFm/wAY3Oq65omsStasYrGKK2LJGvd/941P4hit9U1Wz8UXfh251HTJrcwy20kR 86BgeG216rRQBwngKxt31O71Gw8Ox6PYlBHCXjKzSdyTzwKm+Jdrc3Gm2Lra3F5YRXIa9trcnfJH j9ea7WigDyWwsopvF3h290fw3LpempK6lni2uxK9WHYfWuj8G2txBo/iJZoJEaS7nKBlILAjgiu3 ooA8stLLUtK8NeF9agsZp300OtxbBcSbG4JA9RWho+pXuv8AxJtdSfS7qzshYPHE06YJ+bnPpzXo dFAHL/Ea3mufBd5HbxPLISmFRck/MO1Zfj60uptA0hvslxd2EMiNe20BId02+nfntXeUUAeTadZR S+MfD19pHhuXS9MR3Us8W12JXqw7D61Kul3V9beK/DRs7hLi4uGuoJnT91IMggbvfFeqUUAeOW1l p161rYWHgPyNUDqs8tzCfJjA+8wOefavXZEdLNkt9okWPCAjjOOPwqaigDxfU4BqziD/AIRa8s/F AlA+1WqFISc/eLA4xiu20S1uoviNqctxG+1rGFfNKnazDrg12VFAHmF/puqTaZ4ySygnEkt8jhVy pljAG4KfpWLdWVre2enyaB4TuLGO3u4muZ5oiJOozjufc17TRQB5hD4ln8PeO/Ej/wBmXV7aO8eT bJuZH28ZHpUV14V1PV/CN7qFzYhry6vxffYX/ijH8B9yK7jSPD76Z4h1jUmmDrqDoyoB9zAxW5QB 5Ro9npmq63Yx6N4KFg0Uge5uLuEqIwOyc8nNer0UUAIaxvEX/IHvP+uRrZNY3iL/AJA95/1yNJ7G dX+HL0Z5NUF5/qD9anqOeMyxbVxnPescPJRqxb2ufFxdpIzqKn+xSeq0fYpPVa9763R/mR1e0j3I KKn+xSeq0fYpPVaPrdH+ZB7SPcgoqf7FJ6rR9ik9Vo+t0f5kHtI9yCip/sUnqtH2KT1Wj63R/mQe 0j3NeGaMeBZ4vMXzDeKdmecY64p3jC68zV4TbzlkFrEPkfjOOelY32KT1Wj7FJ6rWar0FK/OjV4l OPL6fgQEknJJJ9TRU/2KT1Wj7FJ6rWn1uj/MjL2ke5BRU/2KT1Wj7FJ6rR9bo/zIPaR7kFFT/YpP VaPsUnqtH1uj/Mg9pHuQUVP9ik9Vo+xSeq0fW6P8yD2ke5BRU/2KT1Wj7FJ6rR9bo/zIPaR7jbX/ AI+FrTSWSP7jsv0NUobV45VYkYFWq66FSFSN4u6MKkryuiyNQuR/y1J+tL/aVz/fH5CqtFbcsexH tJdyyb+5b/lqwHtUDSO5yzE/U02imklsJyb3ZVtv+PiWrVQwwtHK7HGGqas6UlON4sc3d6BmoLz/ AFH41PUdxGZY9q4znvTqSUYNvYIO0kVbP/X/AIVeqtb27xSbmIxjtVmvmMdUjOreLurFVGnLQ9H8 Ef8AIDj/AN5v511S9K5XwR/yA4/95v511S9KUPhR9dhP4EPRDqKKKo6Arzn4w/8AIM0//rq38q9G rzj4xH/iWaf/ANdW/lWVf+Gzvyz/AHuH9dDiLCGJrGItGpJHUip/s8P/ADyT8qi07/kHw/SrNfTY enD2MNOi/I+HzCvVWLq2k/il1fdm1pejaamjSane2rXAWTy1ij4x7mor210K605riyh+zXEbAGBz u3j1FW9Ki1Oz0n7fpkvmKz7ZYAu7HoSKt3K/2noF1dahYJaTwEeXKqbPMPpisXGKnfz/AKVjVVar p8qbTtfW/wB9zl5tLa3eNJbYK0gDICOoPStXS/D0Uv8AaENzZ/6RDDuRAOQc1o6zaT3V9pDQxO6m CMBlGR+daZ+0DX9d+y588W42460TnFx0S/podONRTd5SavbfybOKu9EnsFVrqyMav0JXg1J/wjl3 9m+0f2e3lY3btvb1rdsftP8AwjV//aAkIMieT539/PbNayu13qiJKl7ZX5QLuX5oTx+WKJVFH7K0 FCEpWfPLXz9f8vI4a00eW/Yra2fmleu1elPOhXAuzbGxPngbtm3nFdDKlzF4WZLEszrdMLgxdT6d O1W9GGox31rJfyZb7LIYlP31GO9VKaSbSRMYzbUXOWttb6anOw6IbYXAvNLZm8kunbZ/tGrFz4YE 2n6fLp9iZHliLSkDjOas6BPLOmrtLI7n7K3LHNS6mdQ/sLRxaed5Ww/6vP3s98VMl79rL9NhxqSd Ny5pWt313OZ/s1hc/Z/sv77ONm3nNTXeg3FjGJLqxMaHjcV4ruoTF/bmZVLXwsBuUHDFu/44rOF0 p0rUFXT7wRlPna4kyFPYjPehVU2rRXQbpzSd6j69X0OYPh66FuZzYkRBd2/bxiqP2eH/AJ5J+VdN 4muZlTT4VlcR/ZFO0HAOa52t6UVKPM0jlr1Zwlyxm/vKl9DEtjMVjUEL1Ar0T4Sf8itN/wBfLfyF efah/wAg+f8A3a7/AOEZ/wCKWm/6+W/kK8fMopYmNl0/U+ryWpKeV1eZ399fkjvK5L4m/wDIlXP+ +n8662uR+J3/ACJVz/vp/OuKp8DO3Bf7xD1R5RpEUb2jFkVju6kVe+zw/wDPJPyqnon/AB5N/v1o V7+AhF4aF10Pls8r1VmNZKT+Lua2g6JY3cF3d3cJkitlB8qMfMx/wqSS38PX1pOIbY2NzGu5A53B /b60uhW1/wDZ7m80ucieHAMIGS6n271q2zya1a3S6vp6RLFEXFyI9hDDp9aVSMVJvt+Hy6mVKrVl BRu7u+99fn0ORl0ww28U8lsFil+4xHBrT0XQIptVS3vrTCyQtIoxyeODV/UoZbrwtpP2eN5du5Tt GcHNa6pLF4qsEAImXTwAPQ4NE5RcXor6/gFJVFNNydvd69zjbvQLizi86exKRE8MV4pYPDt3cwed Dp7NGRkMF610GkG98rVf7S837OYW3+bnG/tjNXYZTKNPS8hvba4EaiGW3OUI7EinKfLpyoUIylrz yV/PzOLttKe7nMNvaeZIOqhelSy6FcQXMcEtiVlk+4pX730rqGhubex1yO3k8y8E67niHzFO/Sod JTU/M0t71z5H2j92kn38+vPanzxs2krf8C5KjUuouUrvz03sZFroD290hvdKeRHDYQcEnFTReHYr zw9HPaWfmXTXDIcDoorR0q5nuPGU/myu+PNwCeBwaYv2z/hDB9j8zH2t9/l5zj8KmS1Wivp+pcJy 5W+aTWvXXSxzdxpT2tx5E9psl7KV5NT3Hh67tYPOnsGSMdWK9K7Kxx52h/2iM3ex8B/vY/hzUdvd bbu8C6dfM2xxL50vyY/Hik6q6RX9Mapy61Ja+b7X1OQg8P3N1AJoLEvGQSGA44qmbeIEgxJke1dL f3M0PhLS1hkeNWeTIU4zzXO10U4qV20vuOStVnCyU3suvdEbQRbW/dJ0Pauy+Dx/4lWo/wDXdf8A 0GuQb7jfQ11vwdP/ABK9R/67r/6DXl5pFKpTsu/6H0eQ1JzwmI5m3rD82eixjEa8EcdD2p1Nj/1a 4z079adXCdYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRWbrHiLStASNtWvorVZThDIfvVBpfi7Qtbn8jTdUtr iX+4jc/kaANmiiigAooooAKKKKACiiigAooooAQ1jeIv+QPef9cjWyaxvEX/ACB7z/rkaT2M6v8A Dl6M8mpGZUGWOBS1Bef6g/WuejBTmovqfFRV3Yf9oi/vij7RF/fFZtFet/ZlP+Zm/sV3NL7RF/fF H2iL++KzaKP7Mp/zMPYruaX2iL++KPtEX98Vm0Uf2ZT/AJmHsV3NL7RF/fFH2iL++KrWOn3WpXHk WUDTS4J2r1xV2fwtrVtC0s2mzrGoyWx0qXl1FOzl+RawraukyP7RF/fFH2iL++KqCyuGs2uxCxt1 bYZOwb0qCq/s2n/MyXQSNL7RF/fFH2iL++KzaKP7Mp/zMXsV3NL7RF/fFH2iL++KzaKP7Mp/zMPY ruaX2iL++KPtEX98Vm0Uf2ZT/mYexXc0vtEX98UfaIv74rNoo/syn/Mw9iu5pfaIv74o+0Rf3xWb RR/ZlP8AmYexXc01mjYgK4JNPrPtf+Pha0K9LB0FQg4xfUyqR5XYKKKK6iAooopgNV1YkKwJHUU6 qtt/x8S1arDD01ThyruypKzsFIzqi5Y4FLUF5/qPxqq8FUpuD6iiruxKsqOcKwJp1UbP/X/hV6vl cVRVGpyoqceV2PR/BH/IDj/3m/nXVL0rlfBH/IDj/wB5v511S9KuHwo+vwn8CHoh1FFFUdAV5v8A GL/kG6f/ANdW/lXpFeb/ABi/5Blh/wBdG/lWVb4Gd+Wf71D+uhxemg/2dD9KtYPpXHmaVRhZHAHY Mab9on/57Sf99GvQpZxCEIx5Nl3OHFcI1atadRVV7zb27u/c7q0vruwcvaTyRMeu09adeane6gAL u4klA6BjxXBefP8A89pP++jSefP/AM9pP++jVf2xTvfk1Mf9UcRbl9tp6P8AzPQYtX1CC2+zxXUq w/3QaauqXyzyTLcyCWQAOwPJxXAefP8A89pP++jR58//AD2k/wC+jR/a9L/n2H+qWI/5/fg/8zvr zUr2/Ci6uJJQvQMeBUo1zU1t/IF5N5eNuM9vrXnnnz/89pP++jR58/8Az2k/76NL+16VrezD/VLE 3v7b8H/md7aaheWDM1rPJEW67T1pTqd6bprk3EhmZdpcnnHpXCRyXEkioJZMk/3jT7kXFtKUM0hH Y7jWn9qRcXU9npsYvhmpGoqHt1zNXSs/8zs4bqe3EghkZBKu18fxD0qzBrWpWyKkN3KiqNoAPAFe fefP/wA9pP8Avo0nnz/89pP++jUPOKT3pmy4RxEdq34P/M7n7TcfaftHmv52c7885qe71a/voxHd XUkiD+EnivP/AD5/+e0n/fRo8+f/AJ7Sf99Gj+2Ke/IJcI4hJr22/k/8zuZ7me6KGd2fYoVc9h6V Fg+lcZ58/wDz2k/76NL9on/57Sf99Gms6gtofiJ8HVnq6q+5/wCZ1Oog/wBnz/7td98I/wDkVpv+ vlv5CvGhNKww0jkHsWNezfCP/kVpv+vlv5CuGvi1iqyklayPWo5VLLMBOnKXNeSfY7yuR+J3/IlX P/XRP5111cj8Tv8AkSrn/ron86ip8DMcF/vEPVHlWif8eTf79aOD6Vx/myIMI7KPQHFNNxP/AM9p P++jXXhs2jSpRpuO3mRmPCtTFYqddVEuZ3tb/gnb21zPZyiW3keJx/EpxVi71jUb6Ly7q7lkT+6T xXn/AJ8//PaT/vo0nnz/APPaT/vo1q84pt3cNTkXCOIS5VW09H/md/a6pfWUTRW1zJGjdVU8Un9p 3puFn+0Secq7A+eQPSuB8+f/AJ7Sf99Gjz5/+e0n/fRo/telv7MP9UsRa3tvwf8Amd/c6rf3kIhu LmSSMdFJ4p8GtalbQCGG7lSMdFB6V5758/8Az2k/76NHnz/89pP++jS/tela3sw/1TxN7+219H/m d3b3t1a3BngmkSU9WB5NSS6pfTXSXElxI00f3WJ+79K4Dz5/+e0n/fRq3NDcxWqS+bJk9RuPFawz ONROSp7I56vDU6DhTnXS5nZaPf7zr4ry4guTcRSsszZy4689alttVv7NAlvcyRqCWwvTJrghNcMQ BLJk/wC0amukubYrmaQhh13Gks0jKLl7PRFS4ZqU6kaTrpSle2j6b9Tsp7u5ubjz5pXeX++TzVif WtSuYDDNdyvGeqk9a898+f8A57Sf99Gjz5/+e0n/AH0aj+2KWn7s2/1RxCv++38n/mdy9zPJbxwO 7GKPOxT0XNRYPpXGefP/AM9pP++jS/aJ/wDntJ/30af9tQX2PxJfB1Z71V9z/wAzsWB2N9DXVfB3 /kF6j/13H/oNeTLPN3lk/wC+jXrPwcH/ABKtQ/67r/6DXHiMasVUjZWtc9PDZNPLMJV5p83Ny9Lb P/gno8ZzGpyTx1NOpsZyinIPHUd6dUnGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBxni+3huvGHhiK4ijliaWT KSKGB+X0NVviF4c0+x8OSazp1rDaX2nMs8UkCBCcEZBx2NSeONRtdK8U+Gru+mWG3jlk3SN0Hy1R 8X+LtO8UaUfD/h6f7dd6g6xsYgSsaZyzE/QUAauo+M71XsbHQ9OGoalcWy3Dqz7EiUjqxqbTfG6t pupSazaNYXumLuuYM7uD0KnuDXHeJtHsNN8aodav77TrGWyjigubZyilk4IYimWWjWep6B4lfw+d RvQYkRbq6fcJyp3EL34oA2pfiLrdnaw3eoeHjb2l46rbSGTP3jxvHYkV1Nnr8lz4vvtGMKhLaBJR IDyxbtXC+JvHGkax4U06xsy0l200Aki2EGAgjO70rVutZsfDHxNvbjVpTbwXllGIpWB2sVPIz60A a6+No4ItfnvYQkWlTiFdhyZSRkD6k1RtfG2s291aya9oP2LTrtwkU6y7ihP3d47Zrkpkl8ReGfF8 9rDMFbUY5woGHaMAHIHrjmoo7XwzfzafBYatreqXU0qf6IZj+7weS4PTFAHpukeIJNS8Q6xprQqi 2DIquDy+4ZrOTx0kWhalqN1bc2t41pFFGctKwwAPqc1k2+vaf4U8fa+urzNbi7WKSBmUkSADGB6m uamt5dW8A392IrhI4taaeVYwRIseRkj3xzQB22neMdYh1O1t/EmiDT4b1tlvMku8BuoVvQ12deO2 Nn4bvtc0uHS9U1jV52mEnltOSkIHO589PpXsVACGsbxF/wAge8/65Gtk1jeIv+QPef8AXI0nsZ1f 4cvRnk1QXn+oP1qeoLz/AFB+tZYX+NH1Pi4fEijRRRX0p2BRRRQAUUUUAdH4G3/21P5ed/2SXbt6 5xWh4TTxANeia4+2C1GfOM5O3b75rP8AAztFrU7odrLaSkH0OKz7jxJq91E0U2oTtG3BG7rXPOLl KSR2U5xhCMnfd/odPaWllfeHNWWW5W2s1v8Ad5mM8egFZk/ha0TUNOEN8ZbC/JVJtuCrehFR2/8A yTy7/wCvxf5U/UJWg8HaHKhwyTOw+oNSlJPR9bfgU3GUVdbK/wCJSsdA8/Ub+C5kaKOyR2dgPTp+ dX4PC+mx2tqdS1Q29zdpvjUJlQD0ya0/EssNtoM19ARv1goTj0A+b9as6bFqv2GwgNpa6xpsiDEj DBiHcE9sUnUk1zXsVGjBS5bX/wCH/wAjgLu3NpdywF1fy2K7lOQfcVFWhr8Fta67dw2JBt0kwmDm s+uqLukzhmrSaCiiimSFFFFABRRSUAaNnps7QfayAIh09TUtOsLuWC1VUb5SOVPIp7SI+SYwp/2T W8E0jmqNSehFRT/k7bh9aULF3kI/4DV3M7EdFWFS2/ilf8FqzDLp0JB2SOR/eqXO3QtU77tDb2zh gs4ZYo9rv94+tUK3G1e1ddrRsV9CKpyXNgx4tW/A4qISaVmjSpGLd1JGfQbKa+UxwAFh82DVpri3 H3LUf8CYmk+3S42x7Y1P90YqndqyRnHli7tmRaApcsrDDLkEVerItZSdRlGe5rXHIr5rMHet8iq8 bSPR/BH/ACA4/wDeb+ddUvSuV8Ef8gOP/eb+ddUvSoh8KPrMJ/Ah6IdRRRVHQFecfGEf8Syw/wCu rfyr0evOfjD/AMgyw/66t/Ksq/8ADZ35X/vcP66HkhWk2U+ivNufauCGbKNlPop3FyIZso2U+ii4 ciGbKNlPoHJouHIjQ0iz3O0zDheB9at6hYie3JUfOvIqWymto4o4UlUuew7mrE08dum6UkL04Ga+ sw9CisJySat1fn/wD8ozDG4uWbe2pwad/dVnql5eepymyjZVu8MLXDNASVbnkYxVevlai5JON72P 1KhJVacaji1dbPdeQzZRsp9FTc15EM2UbKfRRcORDQtezfCQf8UtN/18t/IV43Xsvwk/5Fab/r5b +QrbD/GeXnKthfmjuq5L4m/8iVc/76fzrra5L4m/8iVc/wC+n867anwM+awX+80/VHhZXNJsp9Fe Xc+6cUxmyjZT6KdxciGbKNlPoouHIhmyjZT6KVw5EWdNsvtFxkj5E5NbUlqssbIRwRiqWn3tvbwr Hht7Hk4rTmlWCIyP90V9VlsKMcO9U+5+XcR1cXUzBe44paQ87dV6v9DG0/Tz9qcyDiM4/Gr17ZCe 2YAfMORU0d9bSOFR/mbtipZpo7dQ0rbQTitaGHw8MPKCknHW7OTHY7H1cfCtKDjNW5VZ9PLzdzkz Hg4o2VcvvKNyzQNlG5+lVq+UqR5JuN72P1bDyValGpa11ez3XkM2UbKfRUXNuRDQtet/Bwf8SnUf +u6/+g15NXrXwd/5BGo/9d1/9BrbD/xEebm6thJfL8z0OP7i9OnbpTqbGMRqMAcdB2p1egfHBRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAVrvTrPUAovLaGcL0EiBsfnSWmmWVgSbO0ggJ6mOMLn8qtUUAQ3Npb3sXl XUEc0f8AdkUMP1p0MEVtEIoI0jjXoqDAH4VJRQBy/jHw2dS0cx6VaQC5e5ikcgBCwVsnJroLixtr wILq3im2HK+YgbB9s1YooAiitoYS5iiRDIcttUDd9aig02ytZ3mt7SCKV/vOkYBP41aooAr3Fja3 Ukb3FtFK8ZyjOgJX6U+O3hhDiOJEDkswVQNxPc1LRQBWttOs7J3e1tYYWf7xjQKT+VWaKKAENY3i L/kD3n/XI1smsbxCM6PdgdfKNJ7GdX+HL0Z5NUVypeEhRk5qfy3/ALjflRsf+635VzU5uElJdD4t XTuZfkS/3DR5Ev8AcNamx/7rflRsf+635V3/ANp1OyNPay7GX5Ev9w0eRL/cNamx/wC635UbH/ut +VH9p1OyD2suxl+RL/cNHkS/3DWpsf8Aut+VGx/7rflR/adTsg9rLsZ0S3MLFoi6EjBKnHFM8iX+ 4a1Nj/3W/KjY/wDdb8qP7SqfyoftZdjOC3IhMQL+WTkpnjPrip7SIzzQwX00sdoG5Kjds9wKtbH/ ALrflRsf+635UnmVTshqtNdCbxHdx3b21rp6yGys4/LjLjBY9zisyKa+gjMcMsyRnqqsQKu7H/ut +VGx/wC635UlmE0rcqHLETlLmsZnkS/3DSeRL/cNamx/7rflRsf+635VX9p1OyI9rLsZfkS/3DR5 Ev8AcNamx/7rflRsf+635Uf2nU7IPay7GX5Ev9w0eRL/AHDWpsf+635UbH/ut+VH9p1OyD2suxl+ RL/cNHkS/wBw1qbH/ut+VGx/7rflR/adTsg9rLsQwKVgQMMECpKUgjg9aSvoaUuanGT6pGTd2FFF FWIKKKKACiiigApR1FJQOtMDFtUYajKSONxrZXoKzoVY3L/KfvHtWmsb4Hyt+VfIYmbnUbZ0V7to 9G8Ef8gOP/eb+ddUvSuW8EgrocYIIO5uv1rqV6VcPhR9VhP4EPRDqKKKo6ArA8V+FIfFVvBFNcyQ CFiwKAHOfrW/RSaUlZl06kqUlODs0ec/8Kcsv+gncf8AfC0f8Kcsv+gncf8AfC16NRWfsKfY7P7U xf8AP+R5z/wpyy/6Cdx/3wtH/CnLL/oJ3H/fC16NRR7Cn2D+1MX/AD/kec/8Kcsv+gncf98LR/wp yy/6Cdx/3wtejUUewp9g/tTF/wA/5HnP/CnLL/oJ3H/fC0f8Kdsv+gncf98LXo1FHsKfYP7Uxf8A P+R5pc/Cq1062ku49Rnd4VLhSgwcViaToMXiS+WxmneFSCwZACeK9fvU8yxnT+9Gw/SvLvCb+R4o tV9XKV6eDpx+r1IJHg5ljK7xtCvKWq2fz/4Jpf8ACnbL/oJ3H/fC0f8ACnLL/oJ3H/fC16NRXmew p9j3v7Uxf8/5HnP/AApyy/6Cdx/3wtH/AApyy/6Cdx/3wtejUUewp9g/tTF/z/kec/8ACnLL/oJ3 H/fC0f8ACnLL/oJ3H/fC16NRR7Cn2D+1MX/P+R5z/wAKcsv+gncf98LXWeF/DcXhfTXs4Z3mVpDJ ucAHkD/CtqinGlGLukZ1sdXrR5KkroKy/EWhx+ItHk0+WVolcg71GSMGtSiraTVmc0JyhJSjujzn /hTll/0E7j/vhaP+FOWX/QTuP++Fr0ais/YU+x2/2pi/5/yPOf8AhTll/wBBO4/74Wj/AIU5Zf8A QTuP++Fr0aij2FPsH9qYv+f8jzn/AIU5Zf8AQTuP++Fo/wCFOWX/AEE7j/vha9Goo9hT7B/amL/n /I85/wCFOWX/AEE7j/vhaP8AhTll/wBBO4/74WvRqKPYU+wf2pi/5/yPNZ/hJZ2sEk66lcExqWAK LzisLTNGTXr9NPklaJJM5dRkjFeu6odul3R9Im/lXmvgsbvFFv7Bj+lengqcY0KiS6foeDmmMrVc XQlOV2np96JdQ+GFpo9jLfR6hPI0I3BWQAGszRfDUXim7a0mneBUXzNyAEnt3r0vxT/yLd5/uVx/ w7/5Dc//AFxP8xRh6cVhKkUtB43GV55jRqSl7y2/EX/hTtl/0E7j/vhaP+FOWX/QTuP++Fr0aivM 9hT7Hu/2pi/5/wAjzn/hTll/0E7j/vhaP+FOWX/QTuP++Fr0aij2FPsH9qYv+f8AI85/4U5Zf9BO 4/74Wun8J+FIfClrcQQ3Ek4mcOS4AxgY7Vv0U40oRd0jOrjsRWjyVJXQ2MYjUYxx0PanUyPHlrjO Md+tPrQ5AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAENU7tNynirtRu m6gDm57XLH5B+VQ/ZP8AZH5V0bWoJ6U37GvpQBz32M/3R+VH2M/3R+VdD9jX0o+xr6UAc99jP90f lR9jP90flXQ/Y19KPsa+lAHPfYz/AHR+VH2M/wB0flXQ/Y19KPsa+lAHPfYz/dH5UfYz/dH5V0P2 NfSj7GvpQBz32M/3R+VH2M/3R+VdD9jX0o+xr6UAc99jP90flR9jP90flXQ/Y19KPsa+lAHPfYz/ AHR+VH2M/wB0flXQ/Y19KPsa+lAHPfYz/dH5UfYz/dH5V0P2NfSj7GvpQBz32M/3R+VH2M/3R+Vd D9jX0o+xr6UAc99jP90flR9jP90flXQ/Y19KPsa+lAHk+tLs1e4Xphv6VRrrPE/hm8/tGa7gUSRy HOB1Fcw9vNEcPG6n3FfRYepCVOKT6HyGLo1I1ZNxe7IqKUgjrSVucgUUUUAFFFFABRTlRm+6pP0F TxWE8p4QgepqZVIw+J2NIUp1HaKbNLR7fcynaOfaustrTAHyD8qztCsSpQEdK66K0AUcV81J3k2f ZwVopMbZx7AOAPpWgOlRpGFqSpLFooooAKKKKACiiigAooooAKKKKACiiigBGG5SPUYryO1b7J4q Q9NlyR+teu15HrC/ZvFM/bbOD+ua9HL9XOPkePm2ipy7M9copsZ3RqfUA06vOPYCiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAz9efy9CvW9IjXAeA03eI1b+7Gxrs/GM3k+GrrnG8BPzrmP h1Du1O5l/uRgfma9HD+7hZs8fF+9jaUex1Xi1tvhq791A/WuT+HS51a4b0i/rXS+N5PL8NTDuzKP 1rB+HEebm8k9FAoo6YSb/roGI1x9NeX+Z31FFFecewFFFFABRRRQA2M5jXknjqadTYzmNTndx19a dQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAmKMUtFACYoxS0 UAJijFLRQAmKMUtFACYoxS0UAJijFLRQAmKMUtFACYoxS0UAJijFLRQAmKMUtFACYoxS0UAQTwCV SDWPc6EkhJxmt+kxQB5b4s03+z7qEhcK6/rVvRdGj1DS45vLVjkg8VsfEO136XbzqP8AVyYJ+tM+ Hlwslhc27dUfcPoa9OUnLCJp7HixjGGYSjJaSRTn8ML5L7YRu2nHFcvpsKy6lHDIAQzbcH1r2Pyl PavJtXgbSPEsoHHly71+mc0YGcpqcG+gZnTjTlTqpaJ6nQDw0g/5Yr+VUtc0M2umNMqAbCM4HavQ rby7i2ilXBV1DA1Dqtit3pVzBjl4zj69q46dWUaicnsz0a1CE6UlFLVHnfhS1F7LND/EAGFdZFoA GMiuP8I3X2DxJCJOA5MTZr1XArbHw5at+5zZVU5qHL2Zn2emrBjitADApaK4j0gooooAKKKKACii igAooooAKKKKACiiigAooooAK8p8Xr5fii5I7lW/SvVq8s8b/wDIzT/7q/yrvy7+K/Q8rOP4K9T0 uwbfp9u3rGp/SrFVNJ/5BFn/ANcU/kKt1xS+Jnpw1igoooqSgooooAKKKKACiiigAooooAKKKKAC iiigAooooA474iXQTT7e2B5kfcR7Cl+Hdr5em3FwRzI+AfYVz3jW/wDt+vtHGcpAPLH1713/AIes v7P0O1gxhgm5vqa9Kr+6wsY9WeNQ/fY6VTpHT9P8zC+Idxs0qCHPMkmT+Apvw6gK6dczH+OQAfgK yviFeebqsNsp4hTJ+prq/CFobTw5bAjDSAyH8aU/cwiXcdP97mEpfyo26KKK849gKKKKACiiigBq fcXp07dKdTUGEXIA46CnUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAZfiOyN /oN1CBltm5fqK4XwLffZNeELHCzrs/HtXppAYEHoa8l1m2k0PxHJs42SeZGfbrXo4JqcJ0X1PHzJ OlUhiF03PW64D4h6fsuYL5Rw42OfcdK7bTrxNQ0+G5jPEig/Q1X13TRqukT22BvK5Q+jDpXNh6ns aqb+Z24uksRQaj6oyvAupC80UW7NmS3O3H+z2rpq8n8N6o+ha4POysbHy5R6e9erqwZQynIIyDV4 2lyVLrZmWW1/a0VF7x0PKPE9k2k+I5TGNqswljP+fevS9Hv11PS4LlTkuo3ex71i+ONHN/pguYVz Nb88dSvesHwLros7lrC4bEUxyhPZv/r10TX1jDqS3ictJ/VMW4P4ZbHotFFFeYe0FFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABXlPjBvN8UXIHOCq/pXqrMFUseABk15FMzar4oYryZbjA+ma9DL 1aUpdkeRm7vCMOrZ6rp6eXp1sv8AdiUfpVmmqu1Qo6AYp1cDd3c9aKskgooopDCiiigAooooAKKK KACiiigAooooAKKKKACs3X9VTSNKluGI342oPVqvTTR28LSzOERBkse1eW+I9bl8QamEhDGBTtiQ d/eurC0HVnrstzhx2KVCnp8T2Dwvpz6xr6PICyI3myE16nLIkELyOQqIpJPoKyPC+iDRdLVXA+0S fNIf6VleO9cFtaf2dC372Xl8fwr/APXrWtJ4muox2McPFYLDOc93r/kjkJDJ4g8SHHJuJuPZf/1V 63DEsEKRKMKihRXDfD/SNzyalKvC/JFn17mu8pY6onJU47IMrpNQdWW8gooorhPUCiiigAooooAb GMRqMY46elOpsf8Aq169O/WnUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFc j490c3Vil/EuZIOHx3WuupkkazRtHIoZGGCD3FaUajpTUkY4iiq1N031OG8A60EZ9NnfAb5os+vc V3leT6/pM3h3Vw0W4RFt8Lj+Vd74a8QR63ZDcQtzGMSJ/UV2YykpfvobM8/LsQ43w1X4lscz460E wT/2lbr+7kOJQP4T61f8E+JBcQrp12/71P8AVMf4h6V108Ed1A8MyB43GGBry3xDoNx4fvxLCW8g tmKQfw+xq6E44in7Ge62M8TTnhK31imtHuj1UgMCGGQeCDXmfi3w2+k3Zu7UH7LI2Rj/AJZn0rov DHi+LUI0tb9wl0OAx4D/AP166a4t4rqB4Z0DxuMFT3rnpzqYSpaSOqrTpY+jeL9PI5Lwp4vSeNLL UZAsy8JIx4b2PvXYg55FeceIfBU9gzXGnhprfrtH3k/xqto/jG/0nEM2Z4V42P8AeX6Gt6mFjWXt KD+Ry0cdPDP2WJXzPUaKwtO8YaXqAAM3kSH+GTj9a20kSRQ0bKwPcHNcE6coO0lY9anVhUV4O46i iioNAooooAKKp3Wq2dmcTTKG/ujk/lVM+IFb/UWdzIPUrt/nQBsUVjf27N306bH+8KcviGEf8fFv cQ+5TI/MUAa9FVYtSs5oWlS4jKKMsc9Kz5NdknJGn2xkX/nrIdq/h3NAG1RXPvdamwLSXcEQ9FTO PzrG1HxXPp2RFfpcy/3RGMfnVwpyqO0Vczq1oUlzTdja8X6yul6Q6K37+cbEHoO5rlPAemm61c3b A+XbjIP+0ax7i4vvEOoGSTdLIeyjhRXdaNf2Ol6XFa6fHJcy9XCrj5u+T2r0KlsLR9n9pnkUubG4 lVbe5HY6iisFtQ1SboLe3HocsaZ5uonrfqD7RivMPbOhorAW81WM8TW8w9GUr/Kp4tf8tgt/btBn +MfMn59qANiimo6yIGRgynkEHrTqACiiigAooooAKKKKACikzis++1/TtOB+0XSBh/Cpyfyqoxcn aKJlOMFeTsaNVb/UrXTLczXcqxqPXqfoK47U/iGSGTTYMf8ATST/AArnYrfVvEt5u/eTuert91a7 aeBl8VV2R5lbM4J8lFczLfiLxRca7L5EAZLbPyoOr/Wuh8IeFDZbb+/T98RmND/D7n3q74f8H22k bZ7jE1z6kfKv0p2v+L7XSUaKArPddlB4X6mrnV517HDrQzpUPZv6zi3r2LniDXodDsi7ENOwxHH6 n/CvObCzu/E+tEuSzO26V+yikhg1HxTqhOWkkY/Mx+6gr0vRNFg0SyEEIy55d+7Gqbjg4WWs2QlP Mal3pTX4ly0tYrK1jt4FCxxjAFTUUV5jd3dntpJKyCiiikMKKKKACiiigBsZzGvJPHU96dTYzmNT nPHX1p1ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBR1fSYNYsXtpx15 Vu6n1rzC5ttQ8LasOSkiHKOOjivXapanpVrq9sYbuMMP4W7qfauvDYn2Xuy1izgxuCVf34aSXUzv D3im21qMRuRFdAfMhPX3Fa93aQ31s8FzGHjcYINeY614YvtCmM0W6SAHKyp1X6+laWiePJrYLDqS maMceYPvD6+tbVMJzfvKDujmo49xfscUrPuVPEHhC50mQz2YaW265H3k+tTaF44ubHbDqAaeEcBv 4l/xrvLHVLLU4g1rOkgI+7nn8qxtZ8FWWpFpbf8A0ec85UfKfqKccTGa9niF8xTwU6b9rhJfI19O 1iy1WLfaTq/qvQj8Kqar4W03VctJEI5T/wAtI+D+Nef3vh7VtFkMnlybV6SxHIpy+LtVFt9nmnLx 9yeGx6Zp/VJL36Ehf2hBr2eKhYfqnhZ7S58qyuFuznlUHK/XtVILq+lN8puYcd1JxW9Y+K7GOMRm 3aD1K85rTi1vT7kcXKc9n4/nVfWMRDSpC5H1TCVHejUs/X+mcsPF2sqgQ3jceo5qWLxhqSn95PIf cNXTPb6ddD5kt5M/Sq7+G9Nl6Q7f91qh18PL46djRYXGQ/h1b/18zNi8c3kf/LRm9nUGppfHct2q xSoYEJ+d4vvEe3pT38IWTfceVfxzUD+DIv4Ll/xWl/sT7of/AApR7P7ixB4k0eD/AFauGPVmXJP4 1N/wlunf89X/AO+DWafBnpdfmtJ/whjf8/Q/75o9ng/5n/XyH7XMf5F/XzNE+LNPHR5D/wABpjeM rNeiSt+FUh4MPe6/8dqRPBkP8d0/4LRy4NdWLnzF/ZS+7/MqXniO2nuo5Vs+E6gnG4+9Mn8YXsgx EkcQ7YGa1o/CNgv32lf8cVdh0HToMbbZWI7tzR7XCQ2jcPYZhU+KaX9eRxr3Wpam20vNLn+FelaF j4TuZyGumEKenVq7BI0jGI0VR7CnVM8fK1qasXTyqF+atJyZRt9Kt7O0aCBSoYYZgfmP41bhRYIw kShFHYU800yIvV1H1NcTbk7vU9OMYwXKtEOpKia8t0+9PEPqwqF9WsY/vXUX4NmhQk9kJ1ILdot0 ucghgCp6g1mP4i01P+XgH6A1Xk8Waen3RI/0FaLD1XtFmUsXQjvNfealtevo92I445JbWYEhF58t vb2rXt9csp3CGQxOf4ZRtP61xT+MoVOYrdz/ALxqrceMJZ1KmzhIP97mtVgqz6GEsyw0ftHp4OeR S15PB4t1W2jMcM4VCeARnb9KjfW9bvuBc3Lg9kzj9K1WXVPtNIwlm9H7KbPWJJ4oRmSREA/vHFZ9 x4k0q1/1l7ET6Kc/yrzePRNbvjn7Pctnu5I/nWhb+AdUm5lMUI/2mz/Kn9Uow+OZP1/EVP4dI6G5 +IOmxZEEcsx9cYH61jXfxDvZMi1t44h2LfMau2/w7hQbry9bHcKMD86uLpHhbShmZ4XYf89H3H8q pfVY/DFyZMvr0/jkoI46XWNa1dyvnXEmf4IwcfpVqx8F6tfENIggU/xSnn8q6WXxro1guyygL46e WgUVj3vxCvZci1hjhHqfmNbqddq1OHKvM5ZU8NF3rVHJ+Rtaf4E0+yHm30hnI67uFFWrzxRo2ixe TAVcr0jhHH51wT3Ws64+C9xPnsucVrad4Bv7nDXjrboeo6tWc6K3xE/ka08RJ+7hKVvMr6v4z1DU 8xW/+jwnjan3j+NO0XwZe6mwmu828BOSW+830FdrpXhbTdKw0cXmSj/lpJyfwrZrKeMjBctBW8zo p5dOpLnxMrvsVNO0y10q2EFpGEUdT3P1q3RRXntuTuz1oxUVaK0CiiikMKKKKACiiigAooooAamd i5xnHbpTqbHxGvAHHQU6gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKAEZQ6lWAKnqDXL6z4Gs74tLZn7NMew+6fwrqaK0p1Z03eLsZVaFOsuWaueS3ugatoku/y5AF6 SxHI/Srmn+OtTs8LPtuEH9/hvzr0PUb2Ows3lkXd2C/3j2FcvPodvfu099GomcfdiG0J/wDXrtWN hUVq0bnmPLalJ82HnbyZNb+P9PuIis8ckLkdxkVl2lvpOp2xMnleYzsSc4brVe58HKcm1uCPZx/W sybwzqUGSsYfHdDVRp4eTvTnysidXFxXLWpqSNebwdC/NvcMoPQEZrOm8I3yZ8to5B7GqIbU7I4B uI8fWpo/Eepw8GcnHZhXSoYhfDNM5JVMHL46bi/Ia+hapD/ywk+qmo/J1SE/duV/OtCPxhfL99Im /DFTr4zm/jtkP0NPmxPWCZKhg/s1JL5GSL3VYv8Alrcj8DThrOqL/wAvEv4itgeMkP37If8AfVL/ AMJbaH71l/KpvU60l+BajS+ziH9zMj/hINTH/Lw34ij/AISTU/8An4P5Vs/8JVp562R/75FH/CUa b/z5H/vgVN3/AM+fyKsv+gj8zH/4STU/+fg/lR/wkmp/8/B/Ktj/AISjTf8AnyP/AHwKP+Eo03/n yP8A3wKL/wDTn8gsv+gn8zG/4SDU2/5eG/AU3+2tUb/l4l/AVtf8JVp46WR/75FJ/wAJbZjpZfoK d5dKP5CtHriPzMX+0tVf/lvcH6A0hn1ST+O5P51tHxhCPu2I/MUw+Mj/AA2ij/gVO9XpSX4EuNDr Xf3Mx/I1SX+C5P504aTqkn/LCY/U1pt4zuP4bdB+NRN4wvj91Ih+FVzYjpBL5kOOE61JP5FVfDmp v1gI+rVMnhPUG6iNfqaRvFepN0dF+i1C3iDU5P8Al4f8BT/2p9kL/YV/M/uLyeDbo/fniH0zVhfB qLzLd4+grFN9qk3/AC1uG+gNAtNUnP8Aq7hs+pNS41/tVEi1PDfZot/M3h4a0qL/AF12T/wMCl+y eHbb78iMfds1ip4e1SXrAw/3jU6+Er8qSfLU+mazaj9usbRlP/l3h180aE2paFDC6wQKzFSAQlWr TxzaWVlFFHYlnRQCeBms6Hwe5AM1wFPcKM1e0vwjYyX7215LKWxujKnAYVk3hFvJv7zdLHv4YqP3 DJ/iLeNkQWsSe5JNZs/jLWbk4W42Z7Rriu4g8G6NBj/Rd59XbNaUGl2NsMQ2sKfRBU/WMND4YFfU 8ZU+Orb0/pHlmzW9TbpeTZ9c4q5beCNYuTmSJYs95Gr1EAKMKAB7UtJ5hPaEUio5TC96kmzhrT4c jg3l5n1WNf61u2fg/SLPBFv5rDvIc1uUVzzxVWe8jrp4HD09o/qRxQxQKFijVFHZRipKKK5zrSsF FFFABRRRQAUUUUAFFFFABRRRQAUUUUANjGI1G3bx09KdTY/9WvXp3606gAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDE8SK5tY3QbvJkDlfUVVhmS4jEkbBlb vW9cw+ahFclqNs1ldhbIstxJzsH3cepoA06KoB9QjAyIZfp8tSwT3TyATW6on94PmgCycEfNgj3q m50yU4d7Nj6b1zVi5/49Jv8Arm38q4Lwp4G0LVvDcF3d2ha5lLbpRIwOc9etNNrYTinujs30TTpe Tax8+lVX0DRzJ5fyLJ/cEoz+VYWhXF9plvr+iJK9xNp6l7R2OWKsMgfhWNomjeGdb0cO2oMNdZSX lknKyJJ6YPbNaKtUW0mZPDUXvBfcdo3hLTz080f8CqD/AIRfTGk8tbr5/wC6JAT+VZ+s32r2HhXT bCWVU1W9dbZpUOcDuwPrii5+G+nxWLNp8txHqiDcl2ZTuZx6+2apYqsvtMzeBw7+wi9L4UsIQDLd mMHpvYDP502Pwtp8xxFfCQ+iOp/lWb4m086jL4XstbRZHkkZbhVbAY7R3qp4n8OaV4Wt7TUNEzaX i3KKqpKT5gJ5BGeaf1ut/MT9Qw38h0P/AAhtt/z3ko/4Q62/57yV0G7EW9h0XcR+FZVj4jt7/wAO yaxHG6wIHJQ/e+XrT+t1v5g/s/DfyFUeDrTvNJTh4Qsu8kp/GmX3jSzsrOylW2ubie9j8yK3hXc+ 31NT2Hi3Tr3SLjUGMlulqcTpKuGjPpil9brfzD+oYb+RCDwlp46mU/8AAqkXwtpo/gc/Vqoab47s tQvoraW0u7QTnEEs8e1ZPoal1bxpZaVqZsfs9zcyxjdMYE3CIeppPE1n9plLB4dfYRcj8PaUwykS yAcZD5qVdG0xHCCCLeRkKTzj6Vh/DiZbjQLmWNtyPeSMp9iaqeIdXh0b4g2dxOssgNk6rHGuWdie ABUutUe8n95aw1FbQX3HXLplkn3baIf8BqX7PBGpIhjAHogrJ0PxVZa3b3MgSW1ktP8AXxTjayD1 rOh+IenTXKqbW8jtHfYl48WIyfr6VDnJ7s0VOK2R0kF1bT8QuhPpjBqxk1yeveJ9O0/VGsJbK4uL ryxIn2dcsQfT6VHd+N4dGuRatDdXzbA7CJMtCD0De9SUdhSEZqnpOrWut6el5ZOWjbghhgqe4I9a u0AJtqBWzrlmqfeUMW+lMuNQSNvLhHnTHoi9vqat6NYOkjTzndNJ949gPQUAdAvIFLSAYFLQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAyPmNcEkY6mn02M5jU5zx19adQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAjcA1y8jAa5diT77gF M919q6gjIrD1bTBcEOMrIvKuvUUAQ7aULiqPn3tt8s0InUfxIcH8qcNVhH345kPuhoAsXP8Ax6Tf 9c2/lXN+B761g8H2pmuYY9u7ducDHNbDavbyMYUjlkZhyoXHFZKfDvwyxEp0vDH5iDI3X6UAZekX k0194m8RadEJkwI7cHOJQg5IqV7Twj4o0T+0rtLSGRo90rq2x437++c12NtawWdslvbRJFCgwqKM ACsafwP4eubw3UumRGUnJwSFJ9x0oA48G6TwRo2qTGWaPT7zfuYZYw5wGrtr/wAVaVaaM+pLeQyR 7N0YVgS57AD1rU+zw/Z/I8pPJ27fLx8uPTFYsHgfw9bXouotMiEoO4ZJKg/TpQBgeIo28RjwqL+O S0a6lZnSNsMnHrWxp/gLSLC9juibm5liOY/tEpcKfUCty5062u7i2nni3SWzFoTnG01ZoAbIMxSD uUP8q8+0bUrOz+F99DNcRrLGZo2jz824k4GK9DrFk8H6FLfyXr6dEbiUEM3Y56nHr70Acr9nguYd AFtqr6Xq6WQMMrL+7kTupJ71Q1fUNQv/AA5q1pdvbNNZXUXm3lsuVcE/ePriu+vvDOkalYQ2d5Zp JBAMRAk5Qex61PY6Jp2m2DWVpaRx2zZ3JjO76+tAHB39ndSrpi3/AIvivIZZ42hhhtwWYg5HToK2 vDl7aWGveI4dQljinNz5jeYcb48dR6jrWvp3hDQ9JvTd2Onxxzno2ScfT0qXU/DWk6xdRXOoWUc0 0X3XPB/H1oAxvhy8Uug3TwY8pryUpj0zxTrxFb4o2BZQStk5GexzW3Z2llooS0soPKWZy+1Txnua mbTbV9TTUGizdIhjWTPRT2xQBxOuRSSap4xS3U+a1hHgL1NZUtvdS+EIWuPGEDafIip9nS2Bb/dA HOa9Mj061ivp7xIgLidQkjZ+8B0GKzYvBmgw6j9uj02IXG7cD2B9cdKAMjSYRH8Q2VjvaPTIwGYY Nc/9kvn8QeIki16LTXE5kaGWMEyLjggntXoklrYWuoPqUgVLp0EZct1UdsVl3/hvT/Fl7FNe2IMc fRz8rv7fSgDI+H6Xn9m3klvdx3KzXBZpWjKgt3wK6xdNuLg/6RcSMP7qfKK29M0e10+zjt7aFIok GFRRgCr6wovQUAZFlpCQgBECiteKJY1wBTwAKWgAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAan3FyQeOo6U6mx8RrwBx0HSnUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFNZAw5p1FAFOWxR+1V20ytSigDnL7RhLgnIZfusvBFUg1 9Z8OouIx3HDV1xUN1FV5bJH7UAc4uq25OJC0Tejrip0uYXGUlQj2NX5dLDfwgj3FU5NChY5MCE+u KADzE/vr+dNe4hj+/Kg+ppv9gQ/88RT49BhU5ECZ9SKAM+81RV2G0fzWU/MijO4fWrltdxXaZjPz Dqp6ir6aSAOFC/QVTvNFV23gMsg6OnBoAkoqj5eoW/CyJMo7OMGj7bcp/rLJj/uMKAL1FUf7Sf8A 585/0o+23L/6uyYf77CgC9UFzdxWq5kb5j0UdTUHlahccNIkKntGMmrlloqI+8gvIervyaAM5LGe +l+0Tl436IqHG0VL9kvouEuiR/tpmunhtVjXGKebdD2oA5XytR/57xj32Uv2G8l/1l24HoigV0/2 VPSnCBB2oA5620OMOHZS7/3nOTW1bWSxYJHNWgoHQU6gBAMUtFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAMiIMSEDAI6U+iigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigApMD0oooANo9KMD0oooAWm sobqKKKAIXtY27VC1ghoooAZ/Z6etPWwjFFFAEyWqL2qYKF6CiigB1FFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/Z --_004_8bb9e0b1b7f342acb2c77146b27bf479XCHRTP013ciscocom_-- From nobody Fri Apr 5 19:58:09 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E76012066A; Fri, 5 Apr 2019 19:57:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Carlos Pignataro via Datatracker To: Cc: draft-ietf-netconf-subscribed-notifications.all@ietf.org, ietf@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Carlos Pignataro Message-ID: <155451947938.10151.12663725914439778891@ietfa.amsl.com> Date: Fri, 05 Apr 2019 19:57:59 -0700 Archived-At: Subject: [netconf] Opsdir last call review of draft-ietf-netconf-subscribed-notifications-23 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 02:58:00 -0000 Reviewer: Carlos Pignataro Review result: Has Nits Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Almost Ready This is a comprehensive very well written document. >From an operational point of view, as per the ops-dir review, I have no concerns or comments. Might be nice to collect some of the operational points in an Operations Consideration section, particularly given the document structure of Section 5.x, "ZZZ Considerations". I do have one important question for consideration, which is: what is *really* the relationship of this (+ draft-ietf-netconf-netconf-event-notifications potentially) with RFC 5277? A Normative reference, this doc has no metadata regarding Updating, Obsoleting, etc. Yet lots of it is indeed a superset of it. I recommend the authors+ADs consider whether there is any more formal relationship with RFC 5277 that would require meta-tagging the RFC. Thanks, Carlos Pignataro. From nobody Sat Apr 6 05:03:16 2019 Return-Path: <01000169f287fa3f-076e9a88-770f-41b1-9ffe-034061e6eedb-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DF5120005 for ; Sat, 6 Apr 2019 05:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhMotusOX_72 for ; Sat, 6 Apr 2019 05:03:13 -0700 (PDT) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2733312001A for ; Sat, 6 Apr 2019 05:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1554552191; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=Of4cDemh/ZrkIYvvPaI2WUJdrqj6j7uSX6h3fLW4Xbw=; b=gaV/liO//35PWZJDC3r36O4/xUpWXFKYK7xG49dWYvnrkF7pwzIlfya1o7K4vJj+ Ikt7Cz/U3FEmtCMsURnXNDHZZjA02I0hMnbbMSqolvashgWNhMYyp8rDoqvCCdiWkTy fP2jD22M8lgjkr7gEMxs6TEhjc4inWgPMxg8qcPM= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_16F78DF1-2757-47A5-9788-0FEEFA6B918D" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-ID: <01000169f287fa3f-076e9a88-770f-41b1-9ffe-034061e6eedb-000000@email.amazonses.com> Date: Sat, 6 Apr 2019 12:03:11 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.06-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] reporting-level enum value X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 12:03:15 -0000 --Apple-Mail=_16F78DF1-2757-47A5-9788-0FEEFA6B918D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The zerotouch draft is in AUTH48 and one thing came up... In Section 7.3, in the RPC-reply for the `get-boostrapping-data` RPC, = there is a leaf called `reporting-level`: "Specifies the reporting level for progress reports the bootstrap server would like to receive when processing onboarding information. With current values "standard" and "verbose". The question to the WG is, would it be in anyway better to NOT use the = word "standard"? Perhaps it should be "minimal", =E2=80=9Cdefault=E2=80=9D, = =E2=80=9Cmandatory=E2=80=9D, or =E2=80=9Crequired=E2=80=9D instead? Thoughts? Kent --Apple-Mail=_16F78DF1-2757-47A5-9788-0FEEFA6B918D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

The zerotouch draft is = in AUTH48 and one thing came up...

In Section 7.3, in the RPC-reply for the = `get-boostrapping-data` RPC, there is a leaf called = `reporting-level`:

      =    "Specifies the reporting level for progress reports the
           bootstrap server = would like to receive when processing
      =      onboarding information.

With current values "standard" and = "verbose".

The = question to the WG is, would it be in anyway better to NOT use the word = "standard"?
Perhaps it should be "minimal", = =E2=80=9Cdefault=E2=80=9D, =E2=80=9Cmandatory=E2=80=9D, or = =E2=80=9Crequired=E2=80=9D instead?
Thoughts?

Kent

= --Apple-Mail=_16F78DF1-2757-47A5-9788-0FEEFA6B918D-- From nobody Sun Apr 7 14:17:33 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D60F6120607; Sun, 7 Apr 2019 14:17:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155467184578.18241.18179379395858589165@ietfa.amsl.com> Date: Sun, 07 Apr 2019 14:17:25 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-ssh-client-server-12.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 21:17:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG Groupings for SSH Clients and SSH Servers Authors : Kent Watsen Gary Wu Liang Xia Filename : draft-ietf-netconf-ssh-client-server-12.txt Pages : 43 Date : 2019-04-07 Abstract: This document defines three YANG modules: the first defines groupings for a generic SSH client, the second defines groupings for a generic SSH server, and the third defines common identities and groupings used by both the client and the server. It is intended that these groupings will be used by applications using the SSH protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-ssh-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-12 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-ssh-client-server-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-ssh-client-server-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Apr 7 14:31:11 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C94BA12017D; Sun, 7 Apr 2019 14:31:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155467266375.18250.12590160498951557593@ietfa.amsl.com> Date: Sun, 07 Apr 2019 14:31:03 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-tls-client-server-11.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 21:31:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG Groupings for TLS Clients and TLS Servers Authors : Kent Watsen Gary Wu Liang Xia Filename : draft-ietf-netconf-tls-client-server-11.txt Pages : 43 Date : 2019-04-07 Abstract: This document defines three YANG modules: the first defines groupings for a generic TLS client, the second defines groupings for a generic TLS server, and the third defines common identities and groupings used by both the client and the server. It is intended that these groupings will be used by applications using the TLS protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-tls-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-11 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tls-client-server-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-tls-client-server-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Apr 7 15:37:10 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F47812013B; Sun, 7 Apr 2019 15:37:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155467662331.18332.13666980022394835168@ietfa.amsl.com> Date: Sun, 07 Apr 2019 15:37:03 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-netconf-client-server-11.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 22:37:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : NETCONF Client and Server Models Author : Kent Watsen Filename : draft-ietf-netconf-netconf-client-server-11.txt Pages : 64 Date : 2019-04-07 Abstract: This document defines two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server. Both modules support both the SSH and TLS transport protocols, and support both standard NETCONF and NETCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. This document contains references to other drafts in progress, both in the Normative References section, as well as in body text throughout. Please update the following references to reflect their final RFC assignments: o I-D.ietf-netconf-keystore o I-D.ietf-netconf-tcp-client-server o I-D.ietf-netconf-ssh-client-server o I-D.ietf-netconf-tls-client-server Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "XXXX" --> the assigned RFC value for this draft o "AAAA" --> the assigned RFC value for I-D.ietf-netconf-tcp-client- server o "YYYY" --> the assigned RFC value for I-D.ietf-netconf-ssh-client- server o "ZZZZ" --> the assigned RFC value for I-D.ietf-netconf-tls-client- server Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2019-04-07" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix B. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-11 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-client-server-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-netconf-client-server-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Apr 7 16:06:40 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15082120148; Sun, 7 Apr 2019 16:06:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155467839201.18289.16325426076961394063@ietfa.amsl.com> Date: Sun, 07 Apr 2019 16:06:32 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-restconf-client-server-11.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 23:06:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : RESTCONF Client and Server Models Author : Kent Watsen Filename : draft-ietf-netconf-restconf-client-server-11.txt Pages : 51 Date : 2019-04-07 Abstract: This document defines two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. Both modules support the TLS transport protocol with both standard RESTCONF and RESTCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. This document contains references to other drafts in progress, both in the Normative References section, as well as in body text throughout. Please update the following references to reflect their final RFC assignments: o I-D.ietf-netconf-keystore o I-D.ietf-netconf-tcp-client-server o I-D.ietf-netconf-tls-client-server o I-D.ietf-netconf-http-client-server Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "XXXX" --> the assigned RFC value for this draft o "AAAA" --> the assigned RFC value for I-D.ietf-netconf-tcp-client- server o "BBBB" --> the assigned RFC value for I-D.ietf-netconf-tls-client- server o "CCCC" --> the assigned RFC value for I-D.ietf-netconf-http- client-server Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2019-04-07" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix B. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-11 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-client-server-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-client-server-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Apr 7 17:08:05 2019 Return-Path: <01000169fa45ea88-505cd325-94b7-4d48-a529-448a9905f534-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F2F120267 for ; Sun, 7 Apr 2019 17:08: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OxnvvhxgTtT for ; Sun, 7 Apr 2019 17:08:02 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96C9120248 for ; Sun, 7 Apr 2019 17:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1554682080; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=23vlV1lkmEAaWl1ox/nfqnyvv/wekIZfO9j1WRTbt/4=; b=VfY8h6AQBI6rRXNrG6pwJc7MDtVRMNWIKk2nyGs8B7vuda634+xZGp5FadXZPHYn xZfHlN+SIEy2ptb8kGKwnWTFatmLnn2QPQFjUEafVp6HGyD07XfAFNUlXBYSY+xCTQb bI+UeeC6kHLsijB9RD/O8LMBk6m6k5E99ygDf9FI= From: Kent Watsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-ID: <01000169fa45ea88-505cd325-94b7-4d48-a529-448a9905f534-000000@email.amazonses.com> Date: Mon, 8 Apr 2019 00:07:59 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.08-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] overview of updates and current issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 00:08:04 -0000 For all drafts: - Collapsed all the inner groupings into the top-level grouping. - Added a top-level "demux container" inside the top-level grouping. By "demux", I'm referring to the namespace problem discussed @104. - Added NACM statements and updated the Security Considerations = section. - Added "presence" statements on the "keepalive" containers, as was needed to address a validation error that appeared after adding the "must" statements into the NETCONF/RESTCONF client/server modules. - Updated the boilerplate text in module-level "description" statement to match copyeditor convention. For the http draft: - removed "keepalive" node - added "proxy-server" node - added "protocol-version" node - added "server-name" node For the netconf/restconf drafts: - Adjusted for the top-level "demux container" added by groupings imported from other modules. - Added "must" expressions to ensure that keepalives are not configured for "periodic" connections. - Moved "groupings-expanded" tree diagrams to the Appendix. Current Issues: 1. Regarding the "demux containers": Pros: - now NC/RC models look better - a convenient place to have a nacm:default-deny-write Cons: - seems overbearing for general use Question: Would it be better to revert and instead wrap each "uses" statement in the NC/RC models with a container? Pros: maximum flexibility Cons: less consistency? =20 2. Only in the RESTCONF draft, http proxy-server weirdness a) in the "ietf-restconf-client", there's an unwanted "proxy-server" definition (middle of page 43): = /restconf-client/listen/endpoint/https/http-client-parameters/proxy-server= An HTTP client that receives a call-home connection does NOT need to initiate a connection and therefore there never is a desire to configure a proxy server, but here it is! It's here because the "ieft-http-client" grouping defines it, but when that grouping is used, neither "refine" nor "augment" can remove the definition. Sure, a "must" could disable it, but it still shows in the tree diagram, which is undesirable... b)in the "ietf-restconf-server", there's a missing "proxy-server" definition (bottom of page 48 ): /restconf-server/call-home/restconf-client/endpoints/endpoint/\ https/http-client-parameters/ An HTTP server that establishes a call-home connection needs to initiate a connection and therefore there is a desire to configure a proxy server, but the config node is missing! This is because the "ieft-http-server" grouping doesn't defines a proxy-server node (because servers typically never need to go through a proxy so, when that grouping is used, the definition is missing. Sure, we could augment it in, but coupled with the above, maybe there's a better answer? What to do? 3. In either the NETCONF and RESTCONF drafts, does it matter at all where a 'must' statement is located, especially if they refer to nodes that are conditional by "if-feature" statements? i.e., search for "case periodic-connection" Should the "must" statements be located somewhere else? 4) Only in the NETCONF draft, Section 5 contains the old "Design Considerations" text from ~5 years ago. The idea of removing is was discussed a while back, and someone said it was worth keeping... I'm thinking again to remove it, but rather to deleting it, I'm now thinking maybe we could *move* it to an Informational draft: "Architecture for the Collection of Client and Server Models" that could also contain a picture like this: crypto-types ^ ^ / \ / \ trust-anchors keystore ^ ^------+ ^ | \ | | +-----------+ | / \ tcp-client-server ssh-client-server tls-client-server = http-client-server ^ ^ ^ ^ ^ = ^ | | | | | = | | | | +----------+ | = | | | | | | = | | | | | | = | | +--------------|-------|------------+ | = | | | | | | = | | | | | | = | +--------------+ | | | | = +--------+ | | | | | | | | | | | | netconf-client-server restconf-client-server If there is desire, it would be best to do it now so that all of the client/server drafts could reference it. Thus, whichever draft a reader begins with, their attention is drawn to the collection and thus they can see how the part fits into the whole. Someone else can write it. Thoughts? Kent // contributor From nobody Mon Apr 8 08:46:58 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2531120310 for ; Mon, 8 Apr 2019 08:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QF1beoggiqBj for ; Mon, 8 Apr 2019 08:46:33 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CABCA120307 for ; Mon, 8 Apr 2019 08:46:25 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 08A10E03; Mon, 8 Apr 2019 17:46:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id UgD85MhsNiCP; Mon, 8 Apr 2019 17:46:23 +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 atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 8 Apr 2019 17:46:23 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id E5231200C2; Mon, 8 Apr 2019 17:46:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id TVkksb88lw6p; Mon, 8 Apr 2019 17:46:23 +0200 (CEST) Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 10871200C1; Mon, 8 Apr 2019 17:46:22 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Mon, 8 Apr 2019 17:46:14 +0200 Received: by anna.localdomain (Postfix, from userid 501) id 42D793007BA85C; Mon, 8 Apr 2019 17:46:13 +0200 (CEST) Date: Mon, 8 Apr 2019 17:46:13 +0200 From: Juergen Schoenwaelder To: Kent Watsen CC: "netconf@ietf.org" Message-ID: <20190408154613.ytibxwvjurfcwinp@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: <01000169fa45ea88-505cd325-94b7-4d48-a529-448a9905f534-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <01000169fa45ea88-505cd325-94b7-4d48-a529-448a9905f534-000000@email.amazonses.com> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netconf] overview of updates and current issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 15:46:44 -0000 On Mon, Apr 08, 2019 at 12:07:59AM +0000, Kent Watsen wrote: > > Current Issues: > > 1. Regarding the "demux containers": > > Pros: > - now NC/RC models look better > - a convenient place to have a nacm:default-deny-write > > Cons: > - seems overbearing for general use > > Question: > > Would it be better to revert and instead wrap each "uses" > statement in the NC/RC models with a container? > > Pros: maximum flexibility > Cons: less consistency? What exactly are the demux containers? You mean the and containers? I have no strong opinion, they may be ok although things get a bit more verbose. > 2. Only in the RESTCONF draft, http proxy-server weirdness > > a) in the "ietf-restconf-client", there's an unwanted "proxy-server" > definition (middle of page 43): > > /restconf-client/listen/endpoint/https/http-client-parameters/proxy-server > > An HTTP client that receives a call-home connection does NOT need > to initiate a connection and therefore there never is a desire to > configure a proxy server, but here it is! > > It's here because the "ieft-http-client" grouping defines it, but > when that grouping is used, neither "refine" nor "augment" can > remove the definition. > > Sure, a "must" could disable it, but it still shows in the tree > diagram, which is undesirable... > > > b)in the "ietf-restconf-server", there's a missing "proxy-server" > definition (bottom of page 48 ): > > /restconf-server/call-home/restconf-client/endpoints/endpoint/\ > https/http-client-parameters/ > > An HTTP server that establishes a call-home connection needs > to initiate a connection and therefore there is a desire to > configure a proxy server, but the config node is missing! > > This is because the "ieft-http-server" grouping doesn't > defines a proxy-server node (because servers typically > never need to go through a proxy so, when that grouping > is used, the definition is missing. > > Sure, we could augment it in, but coupled with the above, > maybe there's a better answer? > > What to do? No idea. > 3. In either the NETCONF and RESTCONF drafts, does it matter at all > where a 'must' statement is located, especially if they refer to > nodes that are conditional by "if-feature" statements? > > i.e., search for "case periodic-connection" > > Should the "must" statements be located somewhere else? I actually wonder whether this must is really desirable. What breaks if I have TCP keep-alives turned on for a periodic call-home connection? Perhaps I want to enable keep-alives to work around a broken firewall. > 4) Only in the NETCONF draft, Section 5 contains the old "Design > Considerations" text from ~5 years ago. > > The idea of removing is was discussed a while back, and someone > said it was worth keeping... > > I'm thinking again to remove it, but rather to deleting it, I'm > now thinking maybe we could *move* it to an Informational draft: > > "Architecture for the Collection of Client and Server Models" > > that could also contain a picture like this: > > crypto-types > ^ ^ > / \ > / \ > trust-anchors keystore > ^ ^------+ ^ > | \ | > | +-----------+ > | / \ > tcp-client-server ssh-client-server tls-client-server http-client-server > ^ ^ ^ ^ ^ ^ > | | | | | | > | | | +----------+ | | > | | | | | | > | | | | | | > | +--------------|-------|------------+ | | > | | | | | | > | | | | | | > +--------------+ | | | | +--------+ > | | | | | | > | | | | | | > netconf-client-server restconf-client-server > > > > > If there is desire, it would be best to do it now so that all of > the client/server drafts could reference it. Thus, whichever draft > a reader begins with, their attention is drawn to the collection and > thus they can see how the part fits into the whole. I like the modularization you are doing but perhaps the problem is that the packaging of this stuff into documents makes things hard to follow. For example, why not define crypto-types, trust-anchors, and keystore into one document? Then this document could explain the top part of your figure. One could perhaps also put tcp-client-server, tls-client-server, and http-client-server together, perhaps even adding ssh-client-server to it. Note that you always revise the modules are different speeds later on since you can have future RFCs take over control over a specific module. That said, I believe we need to document the design of this somewhere so that others use it instead of rolling their own solutions. So my preference likely is to do both, merge some closely related modules into single documents and have a document that explains the overall design and how it is to be used by others. /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 Mon Apr 8 12:11:05 2019 Return-Path: <01000169fe5c5e14-63eba328-51f5-4ba3-ac17-311909f5bd86-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8292712032F for ; Mon, 8 Apr 2019 12:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14nvbK4W1Mwh for ; Mon, 8 Apr 2019 12:11:01 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8156312032C for ; Mon, 8 Apr 2019 12:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1554750660; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=m6U5haUNyymaJvrWgAMw6QXvxqA8PbELUkqPcx595z8=; b=gOmJYNyavCRsk7njlP7sdMa12oNx3Wmd/aMnCCw3lOKh2RehCJFvkTdHZhdaWYAB cu85sYTGBvq0Vf+ShCWMj1KI8jPmlsU463PxzJ8NPgu9glWlOs6QRPgXFwczxj8ewFC tJ5nh+yyOsv4bTqPF4XLSpXNePPEuRwBpH5yKs8g= From: Kent Watsen Message-ID: <01000169fe5c5e14-63eba328-51f5-4ba3-ac17-311909f5bd86-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7198D22E-2350-47E2-AC24-CEC3CCC7768A" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 8 Apr 2019 19:11:00 +0000 In-Reply-To: Cc: Mahesh Jethanandani , "netconf@ietf.org" To: NICK HANCOCK References: X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.08-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 19:11:04 -0000 --Apple-Mail=_7198D22E-2350-47E2-AC24-CEC3CCC7768A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Nick, You will notice in the latest tcp-client-server update [1] that there is = now a "presence" statement on the "keepalives" containers. Do you think = any more "mandatory true" statements are needed? I don't understand your last comment or, rather, I think it is the case = already that the TCP keepalives configuration is outside the SSH/TLS = configuration. Note the "keepalives" configuration inside the SSH/TLS = configuration is actually to separately configure keepalives at the = SSH/TLS levels - makes sense? [1] = https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-01 = Kent // contributor > On Mar 26, 2019, at 10:30 AM, NICK HANCOCK = wrote: >=20 > I support this work to provide the ability to configure TCP keepalives = for NETCONF connections as we need this support in our implementations = and support the adoption of these drafts. > =20 > I also have the following comments on the actual YANG implementation = and usage within the client/server model. > =20 > The leafs within the =E2=80=9Ctcp-keepalives=E2=80=9D container are = optional. Given that a server supports the feature = =E2=80=9Ctcp-client-keepalives=E2=80=9D, TCP keepalives would be = disabled per default through missing configuration, which I believe is = desirable behavior. However, there is currently nothing to prevent a = client configuring, say, just =E2=80=98max-probes=E2=80=99 only = resulting in an incomplete but valid configuration. Would not adding a = =E2=80=98presence=E2=80=99 statement to the container = =E2=80=9Ctcp-keepalives=E2=80=9D and making its child nodes mandatory or = adding default values be a more practical solution that defines a = predictable behavior? > =20 > Since TCP is a layer below the security layer and independent of the = choice of security protocol, I was wondering what the motivation was for = locating the TCP keepalives configuration within the SSH/TLS = configuration. Wouldn=E2=80=99t this be better located as a sibling nod = to the choice =E2=80=9Ctransport=E2=80=9D? > =20 > Nick > =20 > <>From: netconf > On Behalf Of Mahesh Jethanandani > Sent: 26 March 2019 12:17 > To: Netconf > > Subject: [netconf] Adoption poll for tcp-client-server and = http-client-server draft > =20 > This is the start of a two week poll for WG adoption of the two = drafts: >=20 > https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00 = > = https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-00 = >=20 > Please indicate your support for or any objections you might have for = adopting the two drafts as WG items by April 9. >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = ___________________________= ____________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = --Apple-Mail=_7198D22E-2350-47E2-AC24-CEC3CCC7768A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Nick,

You will = notice in the latest tcp-client-server update [1] that there is now = a "presence" statement on the "keepalives" containers.  Do you = think any more "mandatory true" statements are needed?

I don't understand your = last comment or, rather, I think it is the case already that = the TCP keepalives configuration is outside the SSH/TLS = configuration.  Note the "keepalives" configuration inside = the SSH/TLS configuration is actually to separately configure = keepalives at the SSH/TLS levels - makes sense?

[1] https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-se= rver-01

Kent= // contributor


On Mar = 26, 2019, at 10:30 AM, NICK HANCOCK <nick.hancock@adtran.com> wrote:

I support this work to = provide the ability to configure TCP keepalives for NETCONF connections = as we need this support in our implementations and support the adoption = of these drafts.
 
I = also have the following comments on the actual YANG implementation and = usage within the client/server model.
 
The leafs within the = =E2=80=9Ctcp-keepalives=E2=80=9D container are optional. Given that a = server supports the feature =E2=80=9Ctcp-client-keepalives=E2=80=9D, TCP = keepalives would be disabled per default through missing configuration, = which I believe is desirable behavior. However, there is currently = nothing to prevent a client configuring, say, just =E2=80=98max-probes=E2=80= =99 only resulting in an incomplete but valid configuration. Would not = adding a =E2=80=98presence=E2=80=99 statement to the container = =E2=80=9Ctcp-keepalives=E2=80=9D and making its child nodes mandatory or = adding default values be a more practical solution that defines a = predictable behavior?
 
Since TCP is a layer below the security layer and independent = of the choice of security protocol, I was wondering what the motivation = was for locating the TCP keepalives configuration within the SSH/TLS = configuration. Wouldn=E2=80=99t this be better located as a sibling nod = to the choice =E2=80=9Ctransport=E2=80=9D?
 
Nick
 
From: netconf <netconf-bounces@ietf.org> On Behalf = Of Mahesh = Jethanandani
Sent: 26 March 2019 12:17
To: Netconf <netconf@ietf.org>
Subject: [netconf] Adoption poll for = tcp-client-server and http-client-server draft
 
This is the start of a two week poll for = WG adoption of the two drafts:

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

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

Mahesh Jethanandani
mjethanandani@gmail.com



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

= --Apple-Mail=_7198D22E-2350-47E2-AC24-CEC3CCC7768A-- From nobody Tue Apr 9 12:06:55 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE49120196; Tue, 9 Apr 2019 12:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Jx6JEjHN; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=EQuOjfHf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6V3NudJw66r6; Tue, 9 Apr 2019 12:06:49 -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 77AAD120316; Tue, 9 Apr 2019 12:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20207; q=dns/txt; s=iport; t=1554836809; x=1556046409; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eFolRpL05dRL7j0GEox2HBVQF2kJHE0oRYLGqT5BGoI=; b=Jx6JEjHNPDA70uevcLT9HGOjWvW7svnQcs5AjRTZh+LDS307Jl68rDiD L0uCrVP4W9vqR4PE6NNTSjXoAOSXS84Px/YpRvV5zU0F8D0J8RbWsObpQ 7rwifiGDs1jhVsVgjwLX0eKt1FM4eaRpyyEVnxfxoDgsqaeE0EkVhhaGR c=; IronPort-PHdr: =?us-ascii?q?9a23=3A68lyPRc61LnGf2r7xeibjdeXlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/Yic5EcBJSXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BGAAAw7Kxc/5BdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwMBAQEBCwGBDi9QA2hUIAQLJ4QOg0cDjyiCV5JOhEqBLhS?= =?us-ascii?q?BEANUDgEBIwmDekYCF4VJIjYHDQEBAwEBCQECAQJtHAyFSgEBAQMBIx0BASk?= =?us-ascii?q?OAQQLAgEIEQMBAigDAgICMBQJCAIEAQ0FgyIBgRFMAw0IAQ6jOQKKFHGBL4J?= =?us-ascii?q?5AQEFgTEBg1QYggwDBYEwAYtGF4F/gREnH4JMPoJhAgKBLAESAQcCNg0JglQ?= =?us-ascii?q?xgiaLDoIIhC6HX4xmCQKIAoQeh2IaggaGFoxDi1OBGoNvgRmNWwIEAgQFAg4?= =?us-ascii?q?BAQWBVgEwZXFwFWUBgkGCCgwXg0yKU3KBKI0Ggj8BAQ?= X-IronPort-AV: E=Sophos;i="5.60,330,1549929600"; d="scan'208,217";a="259332529" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Apr 2019 19:06:48 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x39J6maB029948 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Apr 2019 19:06:48 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 9 Apr 2019 14:06:47 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 9 Apr 2019 15:06:46 -0400 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 9 Apr 2019 15:06:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eFolRpL05dRL7j0GEox2HBVQF2kJHE0oRYLGqT5BGoI=; b=EQuOjfHf3dfINpgRU1jb+xLnBHPKoXtgHzfblGid66oLOvEWsVRNsu9GmiwAZhLRhZrufpTt1iqkXQGjNWHOLOHY4rgTfhmLhv/V5GD+XpCPu7/+fJRr+eYhRZSb/EdfRCxhf43CGUz9gFIR4Fo9FhLOFqFzl4dIrdDfv2mVKeQ= Received: from MWHPR11MB0031.namprd11.prod.outlook.com (10.164.204.27) by MWHPR11MB1581.namprd11.prod.outlook.com (10.172.54.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.16; Tue, 9 Apr 2019 19:06:44 +0000 Received: from MWHPR11MB0031.namprd11.prod.outlook.com ([fe80::584f:10a3:3b55:67b]) by MWHPR11MB0031.namprd11.prod.outlook.com ([fe80::584f:10a3:3b55:67b%6]) with mapi id 15.20.1771.016; Tue, 9 Apr 2019 19:06:44 +0000 From: "Charles Eckel (eckelcu)" To: Kent Watsen , Patrick McManus CC: "httpbis-chairs@ietf.org" , "netconf-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] time to meet today after 5pm Thread-Index: AQHU6vCNgvMqKxW42UOukw8bvA9ZS6YsEPAAgAASFACAABgwAIAIHy0A Date: Tue, 9 Apr 2019 19:06:43 +0000 Message-ID: References: <01000169def07790-5f902f1b-ddce-438b-8e05-d4b7e82818bc-000000@email.amazonses.com> <56E946DC-A690-4B1E-8FB5-683473955C5D@gmail.com> <20190404.163346.857364419603319540.mbj@tail-f.com> <01000169e94f9d0d-7f85f47b-9f92-41a2-94b1-0061bb9bdb3d-000000@email.amazonses.com> In-Reply-To: <01000169e94f9d0d-7f85f47b-9f92-41a2-94b1-0061bb9bdb3d-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=eckelcu@cisco.com; x-originating-ip: [2001:420:c0c0:1005::1d6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 18a07bd8-638a-4bce-3704-08d6bd1e81b8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:MWHPR11MB1581; x-ms-traffictypediagnostic: MWHPR11MB1581: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(376002)(366004)(396003)(346002)(199004)(189003)(83716004)(6306002)(6116002)(54896002)(236005)(6512007)(4326008)(11346002)(6246003)(446003)(93886005)(71200400001)(106356001)(6436002)(256004)(105586002)(81166006)(14444005)(33656002)(58126008)(81156014)(82746002)(86362001)(54906003)(6486002)(229853002)(7736002)(606006)(8676002)(71190400001)(68736007)(36756003)(53936002)(8936002)(2616005)(478600001)(110136005)(46003)(316002)(476003)(966005)(5660300002)(97736004)(186003)(14454004)(25786009)(99286004)(486006)(76176011)(2906002)(6506007)(53546011)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1581; H:MWHPR11MB0031.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: cFZyNFPgpIGjoNbmXG4Z/DxfMiPDZD2WMPlU2wJO/ggGgFvnHLyMkEgqM6b469WcGve16HW7p3GNPC0DSeJV2AuY3Cgm75J/o15CqsCoZVUcOhzUFkKzNnhHIu42CIBQdduQ58Y7bDcFtPrKmC5+WxgxHtScZxtImcNM/egu8U+wqMfHUsvP/kpzvDA4dvQJpPC/dTy01ces91FstohZHtwMHbnVAUyWIVGedrvt65bnV8rR1pU7t7XOkwFDRMr7bxV1N5S2LixlD4ijSN0wria3wgoBOWlnAX+IR31iW9zTZPwpuwnE5Bz0GjZrRDmgxp0MQim3gDbDzLSyoxu3bMNuu7jFhEkU5dE+EwjNkptDxiTzEU0PFsmh4KmGwU5pCiG0JhGCra4giI6WYRUFk53d+AVN0Bxn0MKKZ1HuPQQ= Content-Type: multipart/alternative; boundary="_000_B21C3F25221B4EE3A981D4EE49864C06ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 18a07bd8-638a-4bce-3704-08d6bd1e81b8 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2019 19:06:44.0894 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1581 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.26, xch-aln-016.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [netconf] time to meet today after 5pm X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 19:06:53 -0000 --_000_B21C3F25221B4EE3A981D4EE49864C06ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIHNlZSBpbmxpbmUuDQoNCkZyb206IG5ldGNvbmYgPG5ldGNvbmYtYm91bmNlc0BpZXRm Lm9yZz4gb24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD4NCkRh dGU6IFRodXJzZGF5LCBBcHJpbCA0LCAyMDE5IGF0IDc6MDYgUE0NClRvOiBQYXRyaWNrIE1jTWFu dXMgPG1jbWFudXNAZHVja3NvbmcuY29tPg0KQ2M6ICJodHRwYmlzLWNoYWlyc0BpZXRmLm9yZyIg PGh0dHBiaXMtY2hhaXJzQGlldGYub3JnPiwgIm5ldGNvbmYtY2hhaXJzQGlldGYub3JnIiA8bmV0 Y29uZi1jaGFpcnNAaWV0Zi5vcmc+LCAibmV0Y29uZkBpZXRmLm9yZyIgPG5ldGNvbmZAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW25ldGNvbmZdIHRpbWUgdG8gbWVldCB0b2RheSBhZnRlciA1cG0N Cg0KDQoNCkkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBjb3JyZWN0LiAgSW4gd2hhdCB3YXkgZG8geW91 IHRoaW5rIFJFU1RDT05GDQp0cmllcyB0byB1c2UgSFRUUCBhcyBhIHN0YXRlZnVsIHRyYW5zcG9y dD8NCg0KYmVsb3cNCg0KDQo+ID4+IE9uIFR1ZSwgQXByIDIsIDIwMTkgYXQgNjo0NCBQTSBLZW50 IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ8bWFpbHRvOmtlbnQlMkJpZXRmQHdhdHNlbi5u ZXQ+Pg0KDQo+ID4+IEFjdHVhbGx5LCAibWFuYWdpbmcgcGVyc2lzdGVuY2UiIGlzIGV4YWN0bHkg d2hhdCB3ZSdyZSB0cnlpbmcgdG8NCj4gPj4gYWNoaWV2ZSBoZXJlLiAgT3VyIHNob3ctc3RvcHBp bmcgZHJpdmluZyB1c2UtY2FzZSByZWdhcmRzIFJFU1RDT05GDQo+ID4+IENhbGwgSG9tZSAoUkZD IDgwNzEpIGFuZCwgaW4gcGFydGljdWxhciwgcG9pbnQgIlM3IiBvbiBwYWdlIDggb2YgdGhhdA0K PiA+PiBkb2N1bWVudCwgd2l0aG91dCB3aGljaCBhIHJlbW90ZSBkZXZpY2UgbWF5IGJlY29tZSBh ICJicmljayIgYW5kDQo+ID4+IHJlcXVpcmUgYSB0ZWNobmljaWFuIHRvIHBlcmZvcm0gb24tc2l0 ZSByZXBhaXIuDQoNCmFsc28sIGluIGFuIGV4Y2hhbmdlIHRoYXQgd2Fzbid0IGNvcGllZCB0byB0 aGUgd2csOg0KDQo+IFRvIGdpdmUgYSBjb25jcmV0ZSBleGFtcGxlLCB0aGVyZSBtYXkgYmUgYSBk ZXZpY2UsIGRlcGxveWVkIGJlaGluZCBhIE5BVCwgcmVxdWlyaW5nIGEgcGVyc2lzdGVudCBtYW5h Z2VtZW50IGNvbm5lY3Rpb24gdG8gaXRzIGNvbnRyb2xsZXIgYXBwbGljYXRpb24uICBCZWNhdXNl IHRoZSBkZXZpY2UgaXMgYmVoaW5kIGEgTkFULCBpdCBNVVNUIGluaXRpYXRlIHRoZSBjb25uZWN0 aW9uICh0aGUgY29udHJvbGxlciBjYW5ub3QpIGFuZCwgdGh1cyB0aGUgZGV2aWNlIE1VU1QgZW5z dXJlIGFsaXZlbmVzcyBvZiB0aGUgY29ubmVjdGlvbiB0byB0aGUgY29udHJvbGxlciAodGhlIGNv bnRyb2xsZXIgKm5lZWRzKiB0aGUgZGV2aWNlLWluaXRpYXRlZCBjb25uZWN0aW9uIHRvIGJlIHVw IGluIG9yZGVyIHRvIHNlbmQgY29tbWFuZHMgdG8gdGhlIGRldmljZSkuICAgSW4gY2FzZSB0aGUg Y29udHJvbGxlciBkaXNhcHBlYXJzLCBwZXJoYXBzIGR1ZSB0byBpdHMgZGF0YS1jZW50ZXIgYmVp bmcgaGl0IGJ5IGEgbWV0ZW9yLCB0aGUgZGV2aWNlIG11c3QgcHJvbXB0bHkgZGV0ZWN0IHRvIGxv c3MgYW5kIGluaXRpYXRlIHJlY29ubmVjdGlvbiB0byBhbm90aGVyIGNvbnRyb2xsZXIuDQoNCg0K VG8gYmUgY2xlYXIsIFJFU1RDT05GIGlzIG5vdCB0cnlpbmcgdG8gdXNlIEhUVFAgYXMgYSBzdGF0 ZWZ1bCBwcm90b2NvbCwgYnV0IGl0IGlzIGlkZWFsIHRvIHRyeSB0byBrZWVwIFJFU1RDT05GIENh bGwgSG9tZSBjb25uZWN0aW9ucyB1cCwgYXMgZGVzY3JpYmVkIGFib3ZlLiAgIFBlciB0aGUgIlM3 IiByZWZlcmVuY2UsIGRldmljZXMgU0hPVUxEIHVzZSBSRkMgNjUyMCAodGhlIFRMUyBoZWFydGJl YXQgZXh0ZW5zaW9uKS4gICBUaGlzIHdvdWxkIGtlZXAgdGhlICpzdGF0ZWZ1bCogdHJhbnNwb3J0 IChUTFMpIHVwIGJ1dCwgdW5mb3J0dW5hdGVseSwgT3BlblNTTCBkb2Vzbid0IHdhbnQgdG8gaW1w bGVtZW50IGl0ICh3b3JzdCwgdGhleSBqdXN0IHJlbW92ZWQgdGhlIERUTFMgY29kZSwgaHR0cHM6 Ly9naXRodWIuY29tL29wZW5zc2wvb3BlbnNzbC9pc3N1ZXMvNDg1NiwgZGVzcGl0ZSBCZW4gS2Fk dWsgYW5kIG15c2VsZiBzdGF0aW5nIHZhbHVlKS4NCg0KVGhlIHRoaW5raW5nIGJlaGluZCB0aGlz IHRocmVhZCBpcyB0aGF0IG1heWJlIHNvbWUgdHJhZmZpYyBjb3VsZCBydW4gb24gdG9wIG9mIFRM UyAoaS5lLiwgYXQgdGhlIEhUVFAgbGF5ZXIpLCB0byBkbyB0aGUgc2FtZSBhbmQsIGlmIG5vdCwg dGhlbiBtYXliZSB3ZSBjb3VsZCBkbyBpdCBhdCB0aGUgUkVTVENPTkYgbGF5ZXIuICBbRldJVywg eW91IG1pZ2h0IHJlY2FsbCBORVRDT05GL1JFU1RDT05GIGtlZXBhbGl2ZXMgZGlzY3Vzc2VkZWQg YXQgdGhlIElFVEYgMTAzIG1lZXRpbmcuXQ0KDQpQYXRyaWNrLCBpZiBIVFRQIGtlZXBhbGl2ZSBp cyBub3QgcG9zc2libGUsIHRoZW4gbGV0cyBzdHJpa2UgdGhlICJrZWVwYWxpdmUiIHBhcnRzIGZy b20gdGhlIGlldGYtaHR0cC1jbGllbnQgYW5kIGlldGYtaHR0cC1zZXJ2ZXIgbW9kZWxzLCBsZWF2 aW5nIGl0IHRvIGltcGxlbWVudGF0aW9ucyB0byBsZWFuIG1vcmUgaGVhdmlseSBvbiB0aGVpciBU TFMgc3VwcGxpZXJzIHRvIGltcGxlbWVudCBSRkMgNjUyMCwgb3IgZmFsbGJhY2sgdG8gdW5wcm90 ZWN0ZWQgVENQIGtlZXBhbGl2ZXMgKHdoaWNoIGlzIHdoYXQgdGhlIEJCRi9Ob2tpYSBzYWlkIHRo ZXkgd291bGQgYmUgZG9pbmcgZm9yIGV4cGVkaWVuY3kpLiAgUmVnYXJkaW5nIHRoZSByZXN0LCBs ZXQgbWUgY2xlYW4gdGhlIHJlbWFpbmluZyBiaXRzIChpLmUuLCBwb3N0IGEgLTAxKSBhbmQgcHJl c2VudCB0aGVtIHRvIHlvdSBhZ2FpbiB0aGVuLg0KDQpJIHdvdWxkIHJlY29tbWVuZCBhZ2FpbnN0 IGFkZGluZyBhbnkga2VlcGFsaXZlIG1lY2hhbmlzbSB0byBSRVNUQ09ORi4gU3Ryb25nbHkgcmVj b21tZW5kaW5nIHRoZSB1c2Ugb2YgSFRUUFMgd2hlbiB1c2luZyBSRVNUQ09ORiBpcyBmaW5lLCBi dXQga2VlcCBpbiBtaW5kIHRoYXQgUkVTVENPTkYgd2FzIGNyZWF0ZWQsIGFuZCBpcyB2aWV3ZWQg aW4gdGhlIGluZHVzdHJ5LCBhcyBhIOKAnFJFU1QtbGlrZeKAnSBhbHRlcm5hdGl2ZSB0byBORVRD T05GLiBUaGUgdHJhZGVvZmYgaXMgZnVuY3Rpb25hbGl0eSBidWlsdCBpbnRvIHRoZSBwcm90b2Nv bCB2cy4gY29tcGxleGl0eSBvZiB3cml0aW5nIGFuIGFwcGxpY2F0aW9uIHRoYXQgdXNlcyB0aGUg cHJvdG9jb2wuIEl0IGlzIHRyaXZpYWwgdG8gbWFrZSBpbmRpdmlkdWFsIFJFU1RDT05GIHJlcXVl c3RzIGJ1dCBtb3JlIGRpZmZpY3VsdCBmb3IgYW4gYXBwbGljYXRpb24gdG8gaW1wbGVtZW50IG5l dHdvcmsgdHJhbnNhY3Rpb25zIHVzaW5nIFJFU1RDT05GIHRoYW4gaWYgdXNpbmcgTkVUQ09ORi4g QW4gYXBwbGljYXRpb24gZGV2ZWxvcGVyIGlzIGZyZWUgdG8gY2hvb3NlIHRoZSByaWdodCBwcm90 b2NvbCBmb3IgdGhlIGpvYi4gQWRkaW5nIGNvbXBsZXhpdHkgdG8gUkVTVENPTkYgdGhhdCBtYWtl IGl0IGxlc3MgUkVTVC1saWtlIHdvdWxkIGJlIGEgbWlzdGFrZSwgaW4gbXkgb3Bpbmlvbi4NCg0K Q2hlZXJzLA0KQ2hhcmxlcw0KDQpGb3IgZXZlcnlvbmUgZWxzZSwgdGhpcyBlbWFpbCB0aHJlYWQg aXMgZnJvbSBsYXN0IHdlZWsgd2hlbiBNYWhlc2ggYW5kIEkgd2VyZSB0cnlpbmcgdG8gbWVldCB3 aXRoIHRoZSBIVFRQQklTIGNoYWlycyB0byBkaXNjdXNzIHRoZSBodHRwLWNsaWVudC1zZXJ2ZXIg ZHJhZnQgdW5kZXIgYWRvcHRpb24gcG9sbC4gIFdlIHdhbnRlZCB0byBwcm9hY3RpdmVseSBlbmdh Z2UgSFRUUEJJUyByYXRoZXIgdGhhbiBoYXZlIGFueSBzdXJwcmlzZXMsIHN1Y2ggYXMgdGhlIGV4 Y2hhbmdlIHdpdGggVENQTS4gICBPdXIgaG9wZSBpcyB0aGF0IHdlIGNhbiBjb21lIHRvIGFuIGFn cmVlbWVudCwgbGlrZSB0aGUgb25lIHN0cnVjayB3aXRoIFRDUE0sIHdoZXJlYnkgZG9tYWluIGV4 cGVydHMgaW4gZWFjaCBXRyBjby1hdXRob3IgYSBiYXJlLW1pbmltdW0gZ3JvdXBpbmcgdGhhdCBl bmFibGVzIG91ciA1LXllYXIgY2hhcnRlcmVkIHdvcmsgZWZmb3J0IHRvIGNvbWUgdG8gYW4gZW5k LiAgV2l0aCByZWdhcmRzIHRvIExhc3QgQ2FsbCwgd2UgY2FuIGRvIGl0IGpvaW50IExhc3QgQ2Fs bCwgaWYgZGVzaXJlZC4gICBGb3IgbG9uZ3Rlcm0gbWFpbnRlbmFuY2Ugb2YgdGhlIFlBTkcgbW9k ZWwsIHdlJ3JlIGhhcHB5IHRvIHR1cm4gaXQgb3ZlciB0byB0aGUgZG9tYWluLXNwZWNpZmljIFdH LCB0aG91Z2ggd2UgZG9uJ3QgaGF2ZSBhbnkgbmVlZCBvciBleHBlY3RhdGlvbiBmb3IgYW4gdXBk YXRlLCB0aGUgYmFyZS1taW5pbXVtIGlzIHN1ZmZpY2llbnQuDQoNCktlbnQgLy8gcGljayBhIGhh dA0KDQoNCg0K --_000_B21C3F25221B4EE3A981D4EE49864C06ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <2C10F8D7F4268F45BDF2F6284C1B3F4C@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWww LCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj5QbGVhc2Ugc2VlIGlubGluZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPm5ldGNvbmYgJmx0O25ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyZn dDsgb24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuICZsdDtrZW50JiM0MztpZXRmQHdhdHNlbi5uZXQm Z3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCBBcHJpbCA0LCAyMDE5IGF0IDc6MDYgUE08 YnI+DQo8Yj5UbzogPC9iPlBhdHJpY2sgTWNNYW51cyAmbHQ7bWNtYW51c0BkdWNrc29uZy5jb20m Z3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtodHRwYmlzLWNoYWlyc0BpZXRmLm9yZyZxdW90OyAm bHQ7aHR0cGJpcy1jaGFpcnNAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtuZXRjb25mLWNoYWlyc0BpZXRm Lm9yZyZxdW90OyAmbHQ7bmV0Y29uZi1jaGFpcnNAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtuZXRjb25m QGlldGYub3JnJnF1b3Q7ICZsdDtuZXRjb25mQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6 IDwvYj5SZTogW25ldGNvbmZdIHRpbWUgdG8gbWVldCB0b2RheSBhZnRlciA1cG08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1s ZWZ0Oi41aW4iPg0KSSBkb24ndCB0aGluayB0aGlzIGlzIGNvcnJlY3QuJm5ic3A7IEluIHdoYXQg d2F5IGRvIHlvdSB0aGluayBSRVNUQ09ORjxicj4NCnRyaWVzIHRvIHVzZSBIVFRQIGFzIGEgc3Rh dGVmdWwgdHJhbnNwb3J0PzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj5iZWxvdzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxicj4NCiZndDsgJmd0OyZndDsgT24gVHVlLCBBcHIgMiwgMjAxOSBh dCA2OjQ0IFBNIEtlbnQgV2F0c2VuICZsdDs8YSBocmVmPSJtYWlsdG86a2VudCUyQmlldGZAd2F0 c2VuLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmtlbnQmIzQzO2lldGZAd2F0c2VuLm5ldDwvYT4mZ3Q7 PGJyPg0KPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBBY3R1YWxseSwgJnF1b3Q7bWFuYWdpbmcgcGVyc2lz dGVuY2UmcXVvdDsgaXMgZXhhY3RseSB3aGF0IHdlJ3JlIHRyeWluZyB0bzxicj4NCiZndDsgJmd0 OyZndDsgYWNoaWV2ZSBoZXJlLiZuYnNwOyBPdXIgc2hvdy1zdG9wcGluZyBkcml2aW5nIHVzZS1j YXNlIHJlZ2FyZHMgUkVTVENPTkY8YnI+DQomZ3Q7ICZndDsmZ3Q7IENhbGwgSG9tZSAoUkZDIDgw NzEpIGFuZCwgaW4gcGFydGljdWxhciwgcG9pbnQgJnF1b3Q7UzcmcXVvdDsgb24gcGFnZSA4IG9m IHRoYXQ8YnI+DQomZ3Q7ICZndDsmZ3Q7IGRvY3VtZW50LCB3aXRob3V0IHdoaWNoIGEgcmVtb3Rl IGRldmljZSBtYXkgYmVjb21lIGEgJnF1b3Q7YnJpY2smcXVvdDsgYW5kPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyByZXF1aXJlIGEgdGVjaG5pY2lhbiB0byBwZXJmb3JtIG9uLXNpdGUgcmVwYWlyLjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5hbHNvLCBp biBhbiBleGNoYW5nZSB0aGF0IHdhc24ndCBjb3BpZWQgdG8gdGhlIHdnLDo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mZ3Q7IFRvIGdpdmUgYSBjb25jcmV0 ZSBleGFtcGxlLCB0aGVyZSBtYXkgYmUgYSBkZXZpY2UsIGRlcGxveWVkIGJlaGluZCBhIE5BVCwg cmVxdWlyaW5nIGEgcGVyc2lzdGVudCBtYW5hZ2VtZW50IGNvbm5lY3Rpb24gdG8gaXRzIGNvbnRy b2xsZXIgYXBwbGljYXRpb24uJm5ic3A7IEJlY2F1c2UgdGhlIGRldmljZSBpcyBiZWhpbmQgYSBO QVQsIGl0IE1VU1QgaW5pdGlhdGUgdGhlIGNvbm5lY3Rpb24NCiAodGhlIGNvbnRyb2xsZXIgY2Fu bm90KSBhbmQsIHRodXMgdGhlIGRldmljZSBNVVNUIGVuc3VyZSBhbGl2ZW5lc3Mgb2YgdGhlIGNv bm5lY3Rpb24gdG8gdGhlIGNvbnRyb2xsZXIgKHRoZSBjb250cm9sbGVyICpuZWVkcyogdGhlIGRl dmljZS1pbml0aWF0ZWQgY29ubmVjdGlvbiB0byBiZSB1cCBpbiBvcmRlciB0byBzZW5kIGNvbW1h bmRzIHRvIHRoZSBkZXZpY2UpLiAmbmJzcDsgSW4gY2FzZSB0aGUgY29udHJvbGxlciBkaXNhcHBl YXJzLCBwZXJoYXBzIGR1ZQ0KIHRvIGl0cyBkYXRhLWNlbnRlciBiZWluZyBoaXQgYnkgYSBtZXRl b3IsIHRoZSBkZXZpY2UgbXVzdCBwcm9tcHRseSBkZXRlY3QgdG8gbG9zcyBhbmQgaW5pdGlhdGUg cmVjb25uZWN0aW9uIHRvIGFub3RoZXIgY29udHJvbGxlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRvIGJlIGNsZWFyLCBSRVNUQ09ORiBpcyBub3Qg dHJ5aW5nIHRvIHVzZSBIVFRQIGFzIGEgc3RhdGVmdWwgcHJvdG9jb2wsIGJ1dCBpdCBpcyBpZGVh bCB0byB0cnkgdG8ga2VlcCBSRVNUQ09ORiBDYWxsIEhvbWUgY29ubmVjdGlvbnMgdXAsIGFzIGRl c2NyaWJlZCBhYm92ZS4gJm5ic3A7IFBlciB0aGUgJnF1b3Q7UzcmcXVvdDsgcmVmZXJlbmNlLCBk ZXZpY2VzIFNIT1VMRCB1c2UgUkZDIDY1MjANCiAodGhlIFRMUyZuYnNwO2hlYXJ0YmVhdCBleHRl bnNpb24pLiAmbmJzcDsgVGhpcyB3b3VsZCBrZWVwIHRoZSAqc3RhdGVmdWwqIHRyYW5zcG9ydCAo VExTKSB1cCBidXQsIHVuZm9ydHVuYXRlbHksIE9wZW5TU0wgZG9lc24ndCB3YW50IHRvIGltcGxl bWVudCBpdCAod29yc3QsIHRoZXkganVzdCByZW1vdmVkIHRoZSBEVExTIGNvZGUsJm5ic3A7PGEg aHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL29wZW5zc2wvb3BlbnNzbC9pc3N1ZXMvNDg1NiI+aHR0 cHM6Ly9naXRodWIuY29tL29wZW5zc2wvb3BlbnNzbC9pc3N1ZXMvNDg1NjwvYT4sDQogZGVzcGl0 ZSBCZW4gS2FkdWsgYW5kIG15c2VsZiBzdGF0aW5nIHZhbHVlKS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGUgdGhpbmtpbmcgYmVoaW5kIHRoaXMgdGhy ZWFkIGlzIHRoYXQgbWF5YmUgc29tZSB0cmFmZmljIGNvdWxkIHJ1biBvbiB0b3Agb2YgVExTIChp LmUuLCBhdCB0aGUgSFRUUCBsYXllciksIHRvIGRvIHRoZSBzYW1lIGFuZCwgaWYgbm90LCB0aGVu IG1heWJlIHdlIGNvdWxkIGRvIGl0IGF0IHRoZSBSRVNUQ09ORiBsYXllci4gJm5ic3A7W0ZXSVcs IHlvdSBtaWdodCByZWNhbGwNCiBORVRDT05GL1JFU1RDT05GIGtlZXBhbGl2ZXMgZGlzY3Vzc2Vk ZWQgYXQgdGhlIElFVEYgMTAzIG1lZXRpbmcuXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+UGF0cmlj aywgaWYgSFRUUCBrZWVwYWxpdmUgaXMgbm90IHBvc3NpYmxlLCB0aGVuIGxldHMgc3RyaWtlIHRo ZSAmcXVvdDtrZWVwYWxpdmUmcXVvdDsgcGFydHMgZnJvbSB0aGUgaWV0Zi1odHRwLWNsaWVudCBh bmQgaWV0Zi1odHRwLXNlcnZlciBtb2RlbHMsIGxlYXZpbmcgaXQgdG8gaW1wbGVtZW50YXRpb25z IHRvIGxlYW4gbW9yZSBoZWF2aWx5IG9uIHRoZWlyIFRMUyBzdXBwbGllcnMNCiB0byBpbXBsZW1l bnQgUkZDIDY1MjAsIG9yIGZhbGxiYWNrIHRvIHVucHJvdGVjdGVkIFRDUCBrZWVwYWxpdmVzICh3 aGljaCBpcyB3aGF0IHRoZSBCQkYvTm9raWEgc2FpZCB0aGV5IHdvdWxkIGJlIGRvaW5nIGZvciBl eHBlZGllbmN5KS4gJm5ic3A7UmVnYXJkaW5nIHRoZSByZXN0LCBsZXQgbWUgY2xlYW4gdGhlIHJl bWFpbmluZyBiaXRzIChpLmUuLCBwb3N0IGEgLTAxKSBhbmQgcHJlc2VudCB0aGVtIHRvIHlvdSBh Z2FpbiB0aGVuLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkkgd291bGQgcmVjb21tZW5kIGFnYWluc3QgYWRkaW5n IGFueSBrZWVwYWxpdmUgbWVjaGFuaXNtIHRvIFJFU1RDT05GLiBTdHJvbmdseSByZWNvbW1lbmRp bmcgdGhlIHVzZSBvZiBIVFRQUyB3aGVuIHVzaW5nIFJFU1RDT05GIGlzIGZpbmUsIGJ1dCBrZWVw IGluIG1pbmQgdGhhdCBSRVNUQ09ORg0KIHdhcyBjcmVhdGVkLCBhbmQgaXMgdmlld2VkIGluIHRo ZSBpbmR1c3RyeSwgYXMgYSDigJxSRVNULWxpa2XigJ0gYWx0ZXJuYXRpdmUgdG8gTkVUQ09ORi4g VGhlIHRyYWRlb2ZmIGlzIGZ1bmN0aW9uYWxpdHkgYnVpbHQgaW50byB0aGUgcHJvdG9jb2wgdnMu IGNvbXBsZXhpdHkgb2Ygd3JpdGluZyBhbiBhcHBsaWNhdGlvbiB0aGF0IHVzZXMgdGhlIHByb3Rv Y29sLiBJdCBpcyB0cml2aWFsIHRvIG1ha2UgaW5kaXZpZHVhbCBSRVNUQ09ORiByZXF1ZXN0cyBi dXQNCiBtb3JlIGRpZmZpY3VsdCBmb3IgYW4gYXBwbGljYXRpb24gdG8gaW1wbGVtZW50IG5ldHdv cmsgdHJhbnNhY3Rpb25zIHVzaW5nIFJFU1RDT05GIHRoYW4gaWYgdXNpbmcgTkVUQ09ORi4gQW4g YXBwbGljYXRpb24gZGV2ZWxvcGVyIGlzIGZyZWUgdG8gY2hvb3NlIHRoZSByaWdodCBwcm90b2Nv bCBmb3IgdGhlIGpvYi4gQWRkaW5nIGNvbXBsZXhpdHkgdG8gUkVTVENPTkYgdGhhdCBtYWtlIGl0 IGxlc3MgUkVTVC1saWtlIHdvdWxkIGJlIGEgbWlzdGFrZSwNCiBpbiBteSBvcGluaW9uLiA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZiI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Q2hhcmxlczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Gb3IgZXZlcnlvbmUgZWxzZSwg dGhpcyBlbWFpbCB0aHJlYWQgaXMgZnJvbSBsYXN0IHdlZWsgd2hlbiBNYWhlc2ggYW5kIEkgd2Vy ZSB0cnlpbmcgdG8gbWVldCB3aXRoIHRoZSBIVFRQQklTIGNoYWlycyB0byBkaXNjdXNzIHRoZSBo dHRwLWNsaWVudC1zZXJ2ZXIgZHJhZnQgdW5kZXIgYWRvcHRpb24gcG9sbC4gJm5ic3A7V2Ugd2Fu dGVkIHRvIHByb2FjdGl2ZWx5IGVuZ2FnZQ0KIEhUVFBCSVMgcmF0aGVyIHRoYW4gaGF2ZSBhbnkg c3VycHJpc2VzLCBzdWNoIGFzIHRoZSBleGNoYW5nZSB3aXRoIFRDUE0uICZuYnNwOyBPdXIgaG9w ZSBpcyB0aGF0IHdlIGNhbiBjb21lIHRvIGFuIGFncmVlbWVudCwgbGlrZSB0aGUgb25lIHN0cnVj ayB3aXRoIFRDUE0sIHdoZXJlYnkgZG9tYWluIGV4cGVydHMgaW4gZWFjaCBXRyBjby1hdXRob3Ig YSBiYXJlLW1pbmltdW0gZ3JvdXBpbmcgdGhhdCBlbmFibGVzIG91ciA1LXllYXIgY2hhcnRlcmVk IHdvcmsNCiBlZmZvcnQgdG8gY29tZSB0byBhbiBlbmQuICZuYnNwO1dpdGggcmVnYXJkcyB0byBM YXN0IENhbGwsIHdlIGNhbiBkbyBpdCBqb2ludCBMYXN0IENhbGwsIGlmIGRlc2lyZWQuICZuYnNw OyBGb3IgbG9uZ3Rlcm0gbWFpbnRlbmFuY2Ugb2YgdGhlIFlBTkcgbW9kZWwsIHdlJ3JlIGhhcHB5 IHRvIHR1cm4gaXQgb3ZlciB0byB0aGUgZG9tYWluLXNwZWNpZmljIFdHLCB0aG91Z2ggd2UgZG9u J3QgaGF2ZSBhbnkgbmVlZCBvciBleHBlY3RhdGlvbiBmb3IgYW4gdXBkYXRlLA0KIHRoZSBiYXJl LW1pbmltdW0gaXMgc3VmZmljaWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj5LZW50IC8vIHBpY2sgYSBoYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B21C3F25221B4EE3A981D4EE49864C06ciscocom_-- From nobody Tue Apr 9 12:19:05 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9D81203D5 for ; Tue, 9 Apr 2019 12:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=iy4m4yJY; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=YI8gB212 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5k3AoxpTPDM for ; Tue, 9 Apr 2019 12:19:02 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11F8C1203D6 for ; Tue, 9 Apr 2019 12:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8085; q=dns/txt; s=iport; t=1554837542; x=1556047142; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Fsf8JI4ffQTlSkHn3quPMy53AMenCvu3q2grAcEWru4=; b=iy4m4yJYQXs/Rfz71BcogBzajGiKWTUWaIfEVvVyzgs2O4ISpcKqA7qv Sbber/1WZnJWgCg26ZRJZKHzKp4hDV5oAwDQrnyWfc/aJw7D2CApBxJ1r 54wVZkh2zdOvWhbgaCtGlrlaQQ+Ikci+13enunWMVU4JnV5oDSv3gvQUz Y=; IronPort-PHdr: =?us-ascii?q?9a23=3AHFXHUhWe4udnQN62FDLEmFIuXavV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA92J8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank3F8dPUFR413q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVAAD+7qxc/4gNJK1lGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYEOL1ADaFQgBAsnhA6DRwOEUopWSoINkk6ESoEugSQ?= =?us-ascii?q?DVA4BASyEQAIXhUkiNAkNAQEDAQEJAQIBAm0cDIVKAQEBBCMdAQE4DwIBCBE?= =?us-ascii?q?DAQIrAgICMB0IAgQBEoMiAYERTAMVAaM8AooUcYEvgnkBAQWCRoJAGIIMCIE?= =?us-ascii?q?wAYtGF4F/gTgfgkw+hC42gmoxgiaNFoQulEUJApQCGpRfi1OTfQIEAgQFAg4?= =?us-ascii?q?BAQWBTziBVnAVZQGCQYIKg2+KU3KBKI9FAQE?= X-IronPort-AV: E=Sophos;i="5.60,330,1549929600"; d="scan'208,217";a="543595977" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Apr 2019 19:19:00 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x39JJ04e011730 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Apr 2019 19:19:00 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 9 Apr 2019 14:19:00 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 9 Apr 2019 15:18:59 -0400 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 9 Apr 2019 14:18:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Fsf8JI4ffQTlSkHn3quPMy53AMenCvu3q2grAcEWru4=; b=YI8gB212Pmtq94fFiE19cbaObCdp+8ceOM8ps+NgpEP6B46XtkS5fpEJXN2LaP4zLfw10NW8WZaahrc/d1tlb3xJVpz3bDfsKhlYpNOTLbF7qVwzqspUKpQZDXX8obBtF+UgqUGruxPMn5DumBGg8DzoZaRKyMppRWYCdCzL8v4= Received: from MWHPR11MB0031.namprd11.prod.outlook.com (10.164.204.27) by MWHPR11MB1693.namprd11.prod.outlook.com (10.169.231.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.15; Tue, 9 Apr 2019 19:18:57 +0000 Received: from MWHPR11MB0031.namprd11.prod.outlook.com ([fe80::584f:10a3:3b55:67b]) by MWHPR11MB0031.namprd11.prod.outlook.com ([fe80::584f:10a3:3b55:67b%6]) with mapi id 15.20.1771.016; Tue, 9 Apr 2019 19:18:57 +0000 From: "Charles Eckel (eckelcu)" To: Kent Watsen , "netconf@ietf.org" Thread-Topic: [netconf] reporting-level enum value Thread-Index: AQHU7HDLrQGEr+AuLkahf0NWQxi4j6Y0Ws2A Date: Tue, 9 Apr 2019 19:18:57 +0000 Message-ID: <025910F1-FD33-499C-A6E2-F6816FAB5467@cisco.com> References: <01000169f287fa3f-076e9a88-770f-41b1-9ffe-034061e6eedb-000000@email.amazonses.com> In-Reply-To: <01000169f287fa3f-076e9a88-770f-41b1-9ffe-034061e6eedb-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=eckelcu@cisco.com; x-originating-ip: [2001:420:c0c0:1005::1d6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cbc5e121-6d08-44fb-c137-08d6bd20370b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:MWHPR11MB1693; x-ms-traffictypediagnostic: MWHPR11MB1693: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(39860400002)(396003)(376002)(366004)(199004)(189003)(82746002)(14454004)(2501003)(5660300002)(478600001)(446003)(476003)(11346002)(106356001)(2616005)(99286004)(486006)(53936002)(105586002)(97736004)(6512007)(6306002)(186003)(54896002)(8936002)(6116002)(6246003)(36756003)(316002)(71200400001)(256004)(81156014)(6436002)(25786009)(102836004)(8676002)(7736002)(53546011)(33656002)(6506007)(71190400001)(83716004)(6486002)(58126008)(81166006)(4744005)(86362001)(68736007)(110136005)(229853002)(2906002)(76176011)(46003); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1693; H:MWHPR11MB0031.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: kPW9O9rtW6erti1+R9mgvDe4RtWIHHDy7ZbfaurB+O0mHLkwaO5Uu5EtO6vYk4F2/XKBnrD1e2Ne4nvM/jag8guMQ4S56esd+ni0hl7puI/I/TttgWW2ls7F5FKVj7ebFiU8e+7YJ4fHAlXYrAmDGburThfN8KVcgZ9XmCa6Cd5AX0NAqIYtZy3cEm0fs/9sr/KWty1VgHQCiOQyzzmh9iAvXO9cgMUkJ34hYncXUZb9NMkd9SovQGM1wLK7/RoEgvUR7DiniZM8jv+npEQPFZMqQmVcesI1giqoIGh9oBBqg95z2NkubLtdY9jrPH8ZiwOVrJVsG8b8xiJDjdg+1FlmLP637UogLfAroCHCIeCN0Tf6CBQqWrQLfulbgfgdXUV0ycyLlZh/g76iFmq91eNTUnsKqXnl9bhdg0BnOfQ= Content-Type: multipart/alternative; boundary="_000_025910F1FD33499CA6E2F6816FAB5467ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cbc5e121-6d08-44fb-c137-08d6bd20370b X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2019 19:18:57.8043 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1693 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [netconf] reporting-level enum value X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 19:19:05 -0000 --_000_025910F1FD33499CA6E2F6816FAB5467ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCcbWluaW1hbOKAnSBzZWVtcyBhcHByb3ByaWF0ZSB0byBtZS4NCg0KQ2hlZXJzLA0KQ2hhcmxl cw0KDQpGcm9tOiBuZXRjb25mIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBv ZiBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ+DQpEYXRlOiBTYXR1cmRheSwgQXBy aWwgNiwgMjAxOSBhdCAyOjAzIFBNDQpUbzogIm5ldGNvbmZAaWV0Zi5vcmciIDxuZXRjb25mQGll dGYub3JnPg0KU3ViamVjdDogW25ldGNvbmZdIHJlcG9ydGluZy1sZXZlbCBlbnVtIHZhbHVlDQoN Cg0KVGhlIHplcm90b3VjaCBkcmFmdCBpcyBpbiBBVVRINDggYW5kIG9uZSB0aGluZyBjYW1lIHVw Li4uDQoNCkluIFNlY3Rpb24gNy4zLCBpbiB0aGUgUlBDLXJlcGx5IGZvciB0aGUgYGdldC1ib29z dHJhcHBpbmctZGF0YWAgUlBDLCB0aGVyZSBpcyBhIGxlYWYgY2FsbGVkIGByZXBvcnRpbmctbGV2 ZWxgOg0KDQogICAgICAgICAiU3BlY2lmaWVzIHRoZSByZXBvcnRpbmcgbGV2ZWwgZm9yIHByb2dy ZXNzIHJlcG9ydHMgdGhlDQogICAgICAgICAgIGJvb3RzdHJhcCBzZXJ2ZXIgd291bGQgbGlrZSB0 byByZWNlaXZlIHdoZW4gcHJvY2Vzc2luZw0KICAgICAgICAgICBvbmJvYXJkaW5nIGluZm9ybWF0 aW9uLg0KDQpXaXRoIGN1cnJlbnQgdmFsdWVzICJzdGFuZGFyZCIgYW5kICJ2ZXJib3NlIi4NCg0K VGhlIHF1ZXN0aW9uIHRvIHRoZSBXRyBpcywgd291bGQgaXQgYmUgaW4gYW55d2F5IGJldHRlciB0 byBOT1QgdXNlIHRoZSB3b3JkICJzdGFuZGFyZCI/DQpQZXJoYXBzIGl0IHNob3VsZCBiZSAibWlu aW1hbCIsIOKAnGRlZmF1bHTigJ0sIOKAnG1hbmRhdG9yeeKAnSwgb3Ig4oCccmVxdWlyZWTigJ0g aW5zdGVhZD8NClRob3VnaHRzPw0KDQpLZW50DQoNCg== --_000_025910F1FD33499CA6E2F6816FAB5467ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <2870B750CEEFBF4EB46E2601B2AE5754@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1 NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3 MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9y bWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0 RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssc2VyaWYiPuKAnG1pbmltYWzigJ0gc2VlbXMgYXBwcm9wcmlhdGUgdG8gbWUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWYiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkNoYXJsZXM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPm5ldGNvbmYgJmx0O25ldGNvbmYtYm91 bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuICZsdDtrZW50JiM0Mztp ZXRmQHdhdHNlbi5uZXQmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlNhdHVyZGF5LCBBcHJpbCA2LCAy MDE5IGF0IDI6MDMgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90O25ldGNvbmZAaWV0Zi5vcmcmcXVv dDsgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltuZXRjb25m XSByZXBvcnRpbmctbGV2ZWwgZW51bSB2YWx1ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGUg emVyb3RvdWNoIGRyYWZ0IGlzIGluIEFVVEg0OCBhbmQgb25lIHRoaW5nIGNhbWUgdXAuLi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkluIFNlY3Rpb24gNy4zLCBpbiB0 aGUgUlBDLXJlcGx5IGZvciB0aGUgYGdldC1ib29zdHJhcHBpbmctZGF0YWAgUlBDLCB0aGVyZSBp cyBhIGxlYWYgY2FsbGVkIGByZXBvcnRpbmctbGV2ZWxgOjxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtTcGVjaWZpZXMgdGhlIHJlcG9ydGluZyBsZXZl bCBmb3IgcHJvZ3Jlc3MgcmVwb3J0cyB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2Jvb3RzdHJhcCBzZXJ2ZXIgd291bGQgbGlrZSB0byByZWNlaXZlIHdo ZW4gcHJvY2Vzc2luZzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7b25ib2FyZGluZyBpbmZvcm1hdGlvbi4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPldpdGggY3VycmVudCB2YWx1ZXMgJnF1b3Q7c3RhbmRhcmQmcXVvdDsgYW5kICZx dW90O3ZlcmJvc2UmcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+VGhlIHF1ZXN0aW9uIHRvIHRoZSBXRyBpcywgd291bGQgaXQgYmUgaW4gYW55d2F5 IGJldHRlciB0byBOT1QgdXNlIHRoZSB3b3JkICZxdW90O3N0YW5kYXJkJnF1b3Q7PzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPlBlcmhhcHMgaXQgc2hvdWxkIGJlICZxdW90O21pbmltYWwmcXVvdDssIOKA nGRlZmF1bHTigJ0sIOKAnG1hbmRhdG9yeeKAnSwgb3Ig4oCccmVxdWlyZWTigJ0gaW5zdGVhZD88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhvdWdodHM/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5LZW50PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_025910F1FD33499CA6E2F6816FAB5467ciscocom_-- From nobody Tue Apr 9 14:03:38 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C2512045D; Tue, 9 Apr 2019 14:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a_91tx3k-qe1; Tue, 9 Apr 2019 14:03:28 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5634A120456; Tue, 9 Apr 2019 14:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3974; q=dns/txt; s=iport; t=1554843807; x=1556053407; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ESCKMOUe3OzMZkgl3K1fbJgG1WZyD/Bzn9D7MOCJlqU=; b=LNhGWyI2hZCVr9mssIazh+jDpIp+wM+nJwEWfZXxx3VH+B1YzRcMY7pY H5ichP/339Zvj4C3YUYjwxRUNQ9yI3yL99L0b/4M2+Uf6CRZAZef083uD 0yuZJuwSydfSIeC6T9COczSLKBR08jwcLiGw/gMeZEN64YMAR8ASN+LQn A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAABzB61c/51dJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUgQBAQEBCwGBZiqBazGEBJVJmEaBew4BAYRsAheFSSI1CA0?= =?us-ascii?q?BAQMBAQkBAgECbSiFSgEBAQMBIxE+BQIFCwIBCBUFAiYCAgIwFRACBAENDRK?= =?us-ascii?q?CPYI5CK47gS+KMoELJQGLRheBQD+BEYMSPodOglcDjROYEWIJApN6IpRfi1O?= =?us-ascii?q?TfQIRFYEwIQI0gVZwFYMokEtBj36BIAEB?= X-IronPort-AV: E=Sophos;i="5.60,330,1549929600"; d="scan'208";a="256668388" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Apr 2019 21:03:26 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x39L3P1E008716 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Apr 2019 21:03:26 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 9 Apr 2019 17:03:25 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Tue, 9 Apr 2019 17:03:25 -0400 From: "Eric Voit (evoit)" To: "Carlos Pignataro (cpignata)" , "ops-dir@ietf.org" CC: "draft-ietf-netconf-subscribed-notifications.all@ietf.org" , "ietf@ietf.org" , "netconf@ietf.org" Thread-Topic: Opsdir last call review of draft-ietf-netconf-subscribed-notifications-23 Thread-Index: AQHU7CSNB07lUgUCgUG2NvnSY7Nf0aY0TpQg Date: Tue, 9 Apr 2019 21:03:24 +0000 Message-ID: <3e994b49f5c2405cb72d1f0345c5e496@XCH-RTP-013.cisco.com> References: <155451947938.10151.12663725914439778891@ietfa.amsl.com> In-Reply-To: <155451947938.10151.12663725914439778891@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.157, xch-rtp-017.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [netconf] Opsdir last call review of draft-ietf-netconf-subscribed-notifications-23 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 21:03:30 -0000 SGkgQ2FybG9zLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcuICBTb21lIHRob3VnaHRzIGluLWxp bmUuLi4NCg0KPiBGcm9tOiBDYXJsb3MgUGlnbmF0YXJvLCBBcHJpbCA1LCAyMDE5IDEwOjU4IFBN DQo+IA0KPiBSZXZpZXdlcjogQ2FybG9zIFBpZ25hdGFybw0KPiBSZXZpZXcgcmVzdWx0OiBIYXMg Tml0cw0KPiANCj4gSGksDQo+IA0KPiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBw YXJ0IG9mIHRoZSBPcGVyYXRpb25hbCBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcNCj4gZWZmb3J0IHRv IHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiAg VGhlc2UNCj4gY29tbWVudHMgd2VyZSB3cml0dGVuIHdpdGggdGhlIGludGVudCBvZiBpbXByb3Zp bmcgdGhlIG9wZXJhdGlvbmFsIGFzcGVjdHMgb2YNCj4gdGhlIElFVEYgZHJhZnRzLiBDb21tZW50 cyB0aGF0IGFyZSBub3QgYWRkcmVzc2VkIGluIGxhc3QgY2FsbCBtYXkgYmUgaW5jbHVkZWQgaW4N Cj4gQUQgcmV2aWV3cyBkdXJpbmcgdGhlIElFU0cgcmV2aWV3LiAgRG9jdW1lbnQgZWRpdG9ycyBh bmQgV0cgY2hhaXJzIHNob3VsZA0KPiB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55 IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCj4gDQo+IFN1bW1hcnk6IEFsbW9zdCBSZWFkeQ0K PiANCj4gVGhpcyBpcyBhIGNvbXByZWhlbnNpdmUgdmVyeSB3ZWxsIHdyaXR0ZW4gZG9jdW1lbnQu DQo+IA0KPiA+RnJvbSBhbiBvcGVyYXRpb25hbCBwb2ludCBvZiB2aWV3LCBhcyBwZXIgdGhlIG9w cy1kaXIgcmV2aWV3LCBJIGhhdmUgbm8NCj4gY29uY2VybnMgb3IgY29tbWVudHMuIE1pZ2h0IGJl IG5pY2UgdG8gY29sbGVjdCBzb21lIG9mIHRoZSBvcGVyYXRpb25hbCBwb2ludHMNCj4gaW4gYW4g T3BlcmF0aW9ucyBDb25zaWRlcmF0aW9uIHNlY3Rpb24sIHBhcnRpY3VsYXJseSBnaXZlbiB0aGUg ZG9jdW1lbnQNCj4gc3RydWN0dXJlIG9mIFNlY3Rpb24gNS54LCAiWlpaIENvbnNpZGVyYXRpb25z Ii4NCg0KSW4gImltcGxlbWVudGF0aW9uIGNvbnNpZGVyYXRpb25zIiB0aGVyZSBhcmUgYSBjb3Vw bGUgd2hpY2ggYXJlIHJlYWxseSBvcGVyYXRpb25hbCBjb25zaWRlcmF0aW9ucy4gIEZvciBleGFt cGxlIHRoZSBmaXJzdCBhbmQgdGhpcmQgYnVsbGV0cyBtaWdodCBxdWFsaWZ5IGFzIG9wZXJhdGlv bmFsLiAgVGhlIGhhcmQgcGFydCBpcyB0aGF0IHRoZSBvcGVyYXRpb25hbCBjb25zaWRlcmF0aW9u cyB0byBleHBvc2Ugd2lsbCB2YXJ5IGJ5IHRoZSBzdWJzZXQgb2YgZmVhdHVyZSB3aGljaCBhcmUg c2VsZWN0ZWQuICBTbyBJIGNhbiBpbWFnaW5lIHRoYXQgbXVjaCB0ZXh0IGNvdWxkIGJlIHdyaXR0 ZW4gb24gYmVzdCBvcGVyYXRpb25hbCBwcmFjdGljZXMuICBJIGFtIGhvcGluZyB0aGF0IHN1Y2gg ZG9jdW1lbnRzIGNvdWxkIGZvbGxvdyB0aGlzIG9uZSBiYXNlZCBvbiBzcGVjaWZpYyBkZXBsb3lt ZW50IGNvbnRleHRzLg0KIA0KPiBJIGRvIGhhdmUgb25lIGltcG9ydGFudCBxdWVzdGlvbiBmb3Ig Y29uc2lkZXJhdGlvbiwgd2hpY2ggaXM6IHdoYXQgaXMgKnJlYWxseSoNCj4gdGhlIHJlbGF0aW9u c2hpcCBvZiB0aGlzICgrIGRyYWZ0LWlldGYtbmV0Y29uZi1uZXRjb25mLWV2ZW50LW5vdGlmaWNh dGlvbnMNCj4gcG90ZW50aWFsbHkpIHdpdGggUkZDIDUyNzc/IEEgTm9ybWF0aXZlIHJlZmVyZW5j ZSwgdGhpcyBkb2MgaGFzIG5vIG1ldGFkYXRhDQo+IHJlZ2FyZGluZyBVcGRhdGluZywgT2Jzb2xl dGluZywgZXRjLiBZZXQgbG90cyBvZiBpdCBpcyBpbmRlZWQgYSBzdXBlcnNldCBvZiBpdC4NCg0K V2Ugd2VudCBhcm91bmQgYW5kIGFyb3VuZCBpbiB0aGUgV0cgb24gdGhpcyBmb3IgYSBiaXQuICBU aGUgaW5pdGlhbCBkZWNpc2lvbiB3YXMgdGhhdCB3ZSB3ZXJlIGdvaW5nIHRvIG9ic29sZXRlIFJG Qy01Mjc3LiAgSG93ZXZlciB0aGUgcHJvYmxlbSB3YXMgdGhhdCBSRkMtNTI3NyBTZWN0aW9uIDQg aGFzIGEgPG5vdGlmaWNhdGlvbj4gZWxlbWVudCBkZWZpbmVkIHdoaWNoIHdlIGFyZSBub3QgcmVw bGFjaW5nIHlldC4gIFRoaXMgPG5vdGlmaWNhdGlvbj4gaXMgdXNlZCBpbiBzZXZlcmFsIGltcG9y dGFudCBwbGFjZXMuICBFeGFtcGxlcyBpbmNsdWRlIFJGQy04MDQwIHNlY3Rpb24gNi40IGFuZCBS RkMtNzk1MCBTZWN0aW9uIDcuMTYuMi4NCg0KU28gd2UgZGlkbid0IHdhbnQgdG8gcmVjb21tZW5k IGFuIG9ic29sZXRlIHdpdGhvdXQgYSByZXBsYWNlbWVudCBvZiB0aGF0IDxub3RpZmljYXRpb24+ LiAgVGhlIGdvb2QgbmV3cyBpcyB0aGF0IHdlIGFyZSB3b3JraW5nIG9uIGEgcmVwbGFjZW1lbnQg Zm9yIHRoaXMgbm90aWZpY2F0aW9uLiAgU2VlOiBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0 aW9uLW1lc3NhZ2VzICAgICBCdXQgdGhpcyBzdGlsbCBoYXMgYSB3aGlsZSB0byBnbyBiZWZvcmUg aXQgaXMgcmVhZHkuICBBcyBhIHJlc3VsdCB3ZSBhcmUgbGVmdCB3aXRoIFNlY3Rpb24gMS40IG9m IGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMgd2hpY2ggZGVzY3Jp YmVzIHRoZSByZWxhdGlvbnNoaXAgd2l0aCBSRkMtNTI3Ny4NCg0KPiBJIHJlY29tbWVuZCB0aGUg YXV0aG9ycytBRHMgY29uc2lkZXIgd2hldGhlciB0aGVyZSBpcyBhbnkgbW9yZSBmb3JtYWwNCj4g cmVsYXRpb25zaGlwIHdpdGggUkZDIDUyNzcgdGhhdCB3b3VsZCByZXF1aXJlIG1ldGEtdGFnZ2lu ZyB0aGUgUkZDLg0KDQpJIHRoaW5rIHRoYXQgdGhpcyBpcyBmdWxseSBhcHByb3ByaWF0ZSBhcyB3 ZSBmaW5pc2ggZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcw0KDQpUaGFu a3MhDQpFcmljDQogDQo+IFRoYW5rcywNCj4gDQo+IENhcmxvcyBQaWduYXRhcm8uDQoNCg== From nobody Tue Apr 9 16:42:23 2019 Return-Path: <0100016a047b19fc-e465e8b2-4858-4971-8350-d548c649dd12-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25007120491 for ; Tue, 9 Apr 2019 16:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VXlKHtyhdeO for ; Tue, 9 Apr 2019 16:42:19 -0700 (PDT) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15BF7120483 for ; Tue, 9 Apr 2019 16:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1554853337; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=FnGG1al/max9heUckhhYnanh7cAfWOwNhiIOI4Jp42Q=; b=cUtKt3M1XFsaKnpTCBOIooYnuZy2ClL6hu520GSk9F4KF/vjp+hfx65n8Pf53UvL pbYJDNUKqu5Kk/GE58gJaLOdvJXRPtKPiaZkfmminRo1m4yVkTHuZLBIYBtLGNN4Kp2 z/m6S+ROGEHm2VjWULpO1msIqIz6WRoz8d0Hz4EA= From: Kent Watsen Message-ID: <0100016a047b19fc-e465e8b2-4858-4971-8350-d548c649dd12-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B084A063-D274-4326-ABDA-1CF24244FE21" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 9 Apr 2019 23:42:17 +0000 In-Reply-To: <025910F1-FD33-499C-A6E2-F6816FAB5467@cisco.com> Cc: "netconf@ietf.org" To: "Charles Eckel (eckelcu)" References: <01000169f287fa3f-076e9a88-770f-41b1-9ffe-034061e6eedb-000000@email.amazonses.com> <025910F1-FD33-499C-A6E2-F6816FAB5467@cisco.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.09-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] reporting-level enum value X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 23:42:21 -0000 --Apple-Mail=_B084A063-D274-4326-ABDA-1CF24244FE21 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Charles. Any objections? Kent // contributor=20 > On Apr 9, 2019, at 3:18 PM, Charles Eckel (eckelcu) = wrote: >=20 > =E2=80=9Cminimal=E2=80=9D seems appropriate to me. > =20 > Cheers, > Charles > =20 > From: netconf > on behalf of Kent Watsen = > > Date: Saturday, April 6, 2019 at 2:03 PM > To: "netconf@ietf.org " > > Subject: [netconf] reporting-level enum value > =20 > =20 > The zerotouch draft is in AUTH48 and one thing came up... > =20 > In Section 7.3, in the RPC-reply for the `get-boostrapping-data` RPC, = there is a leaf called `reporting-level`: >=20 > "Specifies the reporting level for progress reports the > bootstrap server would like to receive when processing > onboarding information.=20 > =20 > With current values "standard" and "verbose". > =20 > The question to the WG is, would it be in anyway better to NOT use the = word "standard"? > Perhaps it should be "minimal", =E2=80=9Cdefault=E2=80=9D, = =E2=80=9Cmandatory=E2=80=9D, or =E2=80=9Crequired=E2=80=9D instead? > Thoughts? > =20 > Kent --Apple-Mail=_B084A063-D274-4326-ABDA-1CF24244FE21 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Charles.  Any objections?

Kent // contributor 


On Apr 9, 2019, at 3:18 PM, = Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:

=E2=80=9Cminimal=E2=80=9D seems appropriate to = me.
 
Cheers,
Charles
 
From: netconf <netconf-bounces@ietf.org> on behalf of Kent Watsen = <kent+ietf@watsen.net>
Date: Saturday, April 6, 2019 = at 2:03 PM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: [netconf] = reporting-level enum value
 
 
The zerotouch draft = is in AUTH48 and one thing came up...
 
In Section 7.3, in the RPC-reply for the = `get-boostrapping-data` RPC, there is a leaf called = `reporting-level`:

      =    "Specifies the reporting level for progress reports the
           bootstrap server = would like to receive when processing
      =      onboarding information. 
 
With current values "standard" and = "verbose".
 
The question to the WG is, would it be in anyway = better to NOT use the word "standard"?
Perhaps it should be "minimal", =E2=80=9Cdefault=E2=80=9D, = =E2=80=9Cmandatory=E2=80=9D, or =E2=80=9Crequired=E2=80=9D instead?
Thoughts?
 
Kent

= --Apple-Mail=_B084A063-D274-4326-ABDA-1CF24244FE21-- From nobody Tue Apr 9 17:47:49 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB87120142; Tue, 9 Apr 2019 17:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=g9vW9n3j; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BrB7//CX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY88eM92o5gy; Tue, 9 Apr 2019 17:47:46 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84BED120134; Tue, 9 Apr 2019 17:47:46 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id A3F632F3; Tue, 9 Apr 2019 20:47:45 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 09 Apr 2019 20:47:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=V ch622raV+E9j2emo+l8u7Int9mxMdgvF670pB8nJqM=; b=g9vW9n3j8TDBg6+9H QBinQW3tWDF0YYawwyRMUjQXqA/we4sG3P95i4w3VmyQMxdHeHQrFNjgLgoKlnt+ inXjktiflBF7mC1FNXx235fNenXoE6x5oVat+tfyUI6fRP505UCepZV9NzEqv0CY ja4lbMnONc1QAg/BjGU0WO4Zb5n9Ig3ZDfAslf71daCGlXaU6hscDlouNG6bvX1U BJBF299O9XRQeaE++euLz6KVKVZKvYG1w6zu+sd8RwXRLREOhwDcxGiz1QxZ1oa3 hPIPhhhNNU9iSBJ8XGPujr4sxfumDJB7KpEQ3RWrmVFYm6WmxdKms8/gP2MasxGD ysHBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=Vch622raV+E9j2emo+l8u7Int9mxMdgvF670pB8nJ qM=; b=BrB7//CX/FDGdvvVyfRVBMVVnvFGsS2uYXzSNEYLZ8aQM92gCF1hEe/dc vJ+TFc8krWYMf9UL+jeTXRcLRlrtTOYnLAyTKU3YuuP1lWyN9rH4WvCHv+UBhyDb G/bVWm0+b2QykggbAo7kvcCb89MA/TuoRXsACb6OIbhrwJk3ORpjnOqOrQZ1lCfs OEIz6TG7eu11w19MYkvomkw8iCBrGxwC2QuG9S8+4BCSLnmy4epVIa+MyM52CLdi jCnlebaAZnQ50e6QrbdFLtV8Ea7fyiESaFtcjV4ebcsheHB+Q+YFwgaXdDSiBzUj 9wl0Q5dtqWLxSR9ZxGGZdMwZTriCg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeigdeflecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hmnhhothdrnhgvthenucfkphepudeggedrudefiedrudejhedrvdeknecurfgrrhgrmhep mhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivg eptd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id ADB7B10392; Tue, 9 Apr 2019 20:47:42 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Mark Nottingham In-Reply-To: Date: Wed, 10 Apr 2019 10:47:42 +1000 Cc: Kent Watsen , Patrick McManus , "httpbis-chairs@ietf.org" , "netconf-chairs@ietf.org" , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1783839F-4A70-46BA-8DC4-C386CE8A07C0@mnot.net> References: <01000169def07790-5f902f1b-ddce-438b-8e05-d4b7e82818bc-000000@email.amazonses.com> <56E946DC-A690-4B1E-8FB5-683473955C5D@gmail.com> <20190404.163346.857364419603319540.mbj@tail-f.com> <01000169e94f9d0d-7f85f47b-9f92-41a2-94b1-0061bb9bdb3d-000000@email.amazonses.com> To: "Charles Eckel (eckelcu)" X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [netconf] time to meet today after 5pm X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 00:47:48 -0000 Charles, > On 10 Apr 2019, at 5:06 am, Charles Eckel (eckelcu) = wrote: >=20 > I would recommend against adding any keepalive mechanism to RESTCONF. = Strongly recommending the use of HTTPS when using RESTCONF is fine, but = keep in mind that RESTCONF was created, and is viewed in the industry, = as a =E2=80=9CREST-like=E2=80=9D alternative to NETCONF. The tradeoff is = functionality built into the protocol vs. complexity of writing an = application that uses the protocol. It is trivial to make individual = RESTCONF requests but more difficult for an application to implement = network transactions using RESTCONF than if using NETCONF. An = application developer is free to choose the right protocol for the job. = Adding complexity to RESTCONF that make it less REST-like would be a = mistake, in my opinion. What do you mean by "REST-like"? Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Wed Apr 10 00:13:36 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE0E1202BC; Wed, 10 Apr 2019 00:13:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Takeshi Takahashi via Datatracker To: Cc: draft-ietf-netconf-yang-push.all@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Takeshi Takahashi Message-ID: <155488041402.1083.9565126428194093115@ietfa.amsl.com> Date: Wed, 10 Apr 2019 00:13:34 -0700 Archived-At: Subject: [netconf] Secdir last call review of draft-ietf-netconf-yang-push-22 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 07:13:34 -0000 Reviewer: Takeshi Takahashi Review result: Has Nits This draft talks about push-type update notifications of YANG datastore. It provides two types of subscriptions: periodic and on-change. I have one comments (item 4) and four clarification questions (items 1-3) below. 1. on the on-change subscription (in sections 3.3 and 3.10) The draft says "it will be important for client applications to have a way to identify for which objects on-change notifications are supported and for which ones they are not supported," but this issue is currently left to the implementation. It would be nice if you could provide some example solutions to this problem so that the implementers of this draft will not be confused. When a publisher accept on-change subscription even when the scope of the subscription contains objects for which on-change is not supported, I wonder sending some notification message on the situation could be helpful for the subscriber. By reading other part of the draft, I feel that the draft is indeed recommending to implement such comprehensive notifications. If so, it had better be clearly mentioned in this section. I also think it is not a bad idea to define such a comprehensive notification in this draft, though it is up to the authors. 2. on the differing dampening periods for multiple objects(in section 3) The draft says "In case whether a subscriber wants to have separate dampening periods for different objects, the subscriber has the option to create multiple subscriptions with different selection filters." That is a good solution. Then are the any other options for allowing to have separate dampening periods for different objects? The sentence gave me the impression that there are multiple options; so I am asking this question only for clarification. 3. imcomplete-update flag (in sections 3.11.1 and 4.3.2) I am not sure what would be the expected actions of the subscribers when they receive a message with incomplete-update flag on. Some navigations would be appreciated. Meanwhile, according to section 4.3.2, a publisher MAY subsequently send a push-update containing a full selection snapshot of subscribed data. If such a push-update is subsequently sent, does the publisher need to send anoter message with incomplete-update flag on prior to the push-update with a full selection snapshot of subscribed data? 4. security considerations (in section 7) This section enumerates four threats that are newly introduced by this draft. Some countermeasures, or directions to address these threats, had better be provided here. From nobody Wed Apr 10 01:30:03 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E661202CF; Wed, 10 Apr 2019 01:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=WfB/gxHv; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BP+XH1yQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wf1DuI1MrJty; Wed, 10 Apr 2019 01:29:59 -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 48A181202CE; Wed, 10 Apr 2019 01:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1930; q=dns/txt; s=iport; t=1554884999; x=1556094599; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=J1uhRaEaro8CRsgivwFnhJD6tiGRiWbkELxqNDecn0M=; b=WfB/gxHv55VccPV/ncVshMCtbNEAi7r6/Hv+JZ+ppWD/FCdiBKAteTJy YqNJmPACvJwmIliZpHAsDS6IbrY3TLn9odYdYGXxYL5ELLHpaCgJBX1aF rnipuEoqiQLNF320IKJzhDwNwCQYxYp5eAFYgTEVV8A+JUA9wuJxKcktu c=; IronPort-PHdr: =?us-ascii?q?9a23=3AEtsWsRIsgQwacFi6CNmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvad2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXEDwL/PuZDESF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVAAA/qK1c/5tdJa1lGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYE9UANoVCAECyeEDoNHA4RSilaCMiWXGIEugSQDVA4?= =?us-ascii?q?BARsRhEACF4VPIjQJDQEBAwEBCQECAQJtHAyFSgEBAQMBIxEMAQE3AQ8CAQg?= =?us-ascii?q?OCgICJgICAjAVEAIEDgWDIgGBXQMNCAGhXQKKFHGBL4J5AQEFhQQYggwDBYE?= =?us-ascii?q?LJQGLRheBf4E4DBOCTD6ELhaDCjGCJosOggiYcwkClAITB5Rfn1ACBAIEBQI?= =?us-ascii?q?OAQEFgU84gVZwFWUBgkGCCoNvhFmFenKBKI9FAQE?= X-IronPort-AV: E=Sophos;i="5.60,332,1549929600"; d="scan'208";a="260520570" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Apr 2019 08:29:58 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x3A8TwhQ004105 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 Apr 2019 08:29:58 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 10 Apr 2019 03:29:57 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 10 Apr 2019 03:29:56 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 10 Apr 2019 04:29:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J1uhRaEaro8CRsgivwFnhJD6tiGRiWbkELxqNDecn0M=; b=BP+XH1yQMROgxqTI4xhvHLDPXqfKHPD7mwV9stbUduBEYb6X79YnmaUP/Rtj3dPFm+wmcdUIIata7W5mH9PNPLOJicLp28AOoXrTciwNliC8RyPQU6ipqRbAygDf2OvOqruS8nnzmvGclz02LH1G3IoNM1EQva8t0htK8CjptZI= Received: from MWHPR11MB0031.namprd11.prod.outlook.com (10.164.204.27) by MWHPR11MB1760.namprd11.prod.outlook.com (10.175.53.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.15; Wed, 10 Apr 2019 08:29:54 +0000 Received: from MWHPR11MB0031.namprd11.prod.outlook.com ([fe80::584f:10a3:3b55:67b]) by MWHPR11MB0031.namprd11.prod.outlook.com ([fe80::584f:10a3:3b55:67b%6]) with mapi id 15.20.1771.016; Wed, 10 Apr 2019 08:29:54 +0000 From: "Charles Eckel (eckelcu)" To: Mark Nottingham CC: Kent Watsen , Patrick McManus , "httpbis-chairs@ietf.org" , "netconf-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] time to meet today after 5pm Thread-Index: AQHU6vCNgvMqKxW42UOukw8bvA9ZS6YsEPAAgAASFACAABgwAIAIHy0AgAA9vwCAAKKpgA== Date: Wed, 10 Apr 2019 08:29:54 +0000 Message-ID: References: <01000169def07790-5f902f1b-ddce-438b-8e05-d4b7e82818bc-000000@email.amazonses.com> <56E946DC-A690-4B1E-8FB5-683473955C5D@gmail.com> <20190404.163346.857364419603319540.mbj@tail-f.com> <01000169e94f9d0d-7f85f47b-9f92-41a2-94b1-0061bb9bdb3d-000000@email.amazonses.com> <1783839F-4A70-46BA-8DC4-C386CE8A07C0@mnot.net> In-Reply-To: <1783839F-4A70-46BA-8DC4-C386CE8A07C0@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=eckelcu@cisco.com; x-originating-ip: [2001:420:c0c0:1006::88] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a2d62522-8bf4-444c-bf83-08d6bd8eb588 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:MWHPR11MB1760; x-ms-traffictypediagnostic: MWHPR11MB1760: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 00032065B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(136003)(39860400002)(376002)(346002)(199004)(189003)(4326008)(2616005)(71200400001)(476003)(966005)(478600001)(14454004)(68736007)(6246003)(11346002)(71190400001)(446003)(83716004)(486006)(25786009)(186003)(81156014)(6306002)(6512007)(86362001)(81166006)(97736004)(53936002)(46003)(36756003)(5660300002)(8676002)(229853002)(99286004)(58126008)(316002)(7736002)(6436002)(54906003)(305945005)(8936002)(82746002)(6116002)(106356001)(102836004)(53546011)(256004)(93886005)(6506007)(6916009)(76176011)(105586002)(2906002)(33656002)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1760; H:MWHPR11MB0031.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5lyFZwli0dGON7iKqoEPVxBy4JO4zXptsCwiGFxjo2XvRHKzacjrDu958Zf04MKB9On63HZoH0JwVJXTJ5UyhsKFXzO6mPjgknPMvlYiRHb5erD+QxDFmQ1brup3osI8fuFhuK1I8uM1kDhoTrqtJSX49CpbvnmKcdD4Cbu8JvpmVAZTwHBf5tgXbWm9KWsnNDX1I01WeROdWqI81CLuAr0dNYOwGZOQho4JpbT+sKzqVWtGXrGUnV89el+WdK3o88QVzXV9S4UJZR0EweqMMvlYuOCIIblTxZAMI41UFbHFgAsiP46z2x4VC1dVXMefrqFZT/3Jm/CymRg8ZcwWmhl8BTh+2OkXtjik0tjukaBEi2LtcSuxnJMj/bImxA4Swt3EGmZVTDcfjC6kGtjqCbHynTBCrXzJpj4j6quJ7Xs= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a2d62522-8bf4-444c-bf83-08d6bd8eb588 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2019 08:29:54.5795 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1760 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [netconf] time to meet today after 5pm X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 08:30:02 -0000 T24gNC8xMC8xOSwgMjo0OCBBTSwgIk1hcmsgTm90dGluZ2hhbSIgPG1ub3RAbW5vdC5uZXQ+IHdy b3RlOg0KDQogICAgQ2hhcmxlcywNCiAgICANCiAgICA+IE9uIDEwIEFwciAyMDE5LCBhdCA1OjA2 IGFtLCBDaGFybGVzIEVja2VsIChlY2tlbGN1KSA8ZWNrZWxjdUBjaXNjby5jb20+IHdyb3RlOg0K ICAgID4gDQogICAgPiBJIHdvdWxkIHJlY29tbWVuZCBhZ2FpbnN0IGFkZGluZyBhbnkga2VlcGFs aXZlIG1lY2hhbmlzbSB0byBSRVNUQ09ORi4gU3Ryb25nbHkgcmVjb21tZW5kaW5nIHRoZSB1c2Ug b2YgSFRUUFMgd2hlbiB1c2luZyBSRVNUQ09ORiBpcyBmaW5lLCBidXQga2VlcCBpbiBtaW5kIHRo YXQgUkVTVENPTkYgd2FzIGNyZWF0ZWQsIGFuZCBpcyB2aWV3ZWQgaW4gdGhlIGluZHVzdHJ5LCBh cyBhIOKAnFJFU1QtbGlrZeKAnSBhbHRlcm5hdGl2ZSB0byBORVRDT05GLiBUaGUgdHJhZGVvZmYg aXMgZnVuY3Rpb25hbGl0eSBidWlsdCBpbnRvIHRoZSBwcm90b2NvbCB2cy4gY29tcGxleGl0eSBv ZiB3cml0aW5nIGFuIGFwcGxpY2F0aW9uIHRoYXQgdXNlcyB0aGUgcHJvdG9jb2wuIEl0IGlzIHRy aXZpYWwgdG8gbWFrZSBpbmRpdmlkdWFsIFJFU1RDT05GIHJlcXVlc3RzIGJ1dCBtb3JlIGRpZmZp Y3VsdCBmb3IgYW4gYXBwbGljYXRpb24gdG8gaW1wbGVtZW50IG5ldHdvcmsgdHJhbnNhY3Rpb25z IHVzaW5nIFJFU1RDT05GIHRoYW4gaWYgdXNpbmcgTkVUQ09ORi4gQW4gYXBwbGljYXRpb24gZGV2 ZWxvcGVyIGlzIGZyZWUgdG8gY2hvb3NlIHRoZSByaWdodCBwcm90b2NvbCBmb3IgdGhlIGpvYi4g QWRkaW5nIGNvbXBsZXhpdHkgdG8gUkVTVENPTkYgdGhhdCBtYWtlIGl0IGxlc3MgUkVTVC1saWtl IHdvdWxkIGJlIGEgbWlzdGFrZSwgaW4gbXkgb3Bpbmlvbi4NCiAgICANCiAgICBXaGF0IGRvIHlv dSBtZWFuIGJ5ICJSRVNULWxpa2UiPw0KDQpXaXRoIFJFU1RDT05GLCB0aGUgWUFORyBtb2RlbHMg c3VwcG9ydGVkIGJ5IHRoZSBSRVNUQ09ORiBzZXJ2ZXIgcmVzdWx0IGluIGl0IGV4cG9zaW5nIFJF U1RmdWwgb3IgUkVTVC1saWtlIEFQSXMgdG8gdGhlIFJFU1RDT05GIGNsaWVudC4gWW91IGNhbiB2 aWV3IHRoZSBSRVNUQ09ORiBzZXJ2ZXIgYXMgc3VwcG9ydGluZyBhIHNldCBvZiBSRVNUIEFQSXMg d2l0aCBzb21lIGFkZGl0aW9uYWwgY29udmVudGlvbnMvcmVxdWlyZW1lbnRzIG9uIHRoZSBzdHJ1 Y3R1cmUgb24gdGhlIFVSSXMsIHN1Y2ggYXMgdGhlIHJvb3Qgb2YgdGhlIFJFU1RDT05GIEFQSSwg dXNlIG9mIHNwZWNpZmljIEhUVFAgcmVzcG9uc2UgY29kZXMsIGV0Yy4NCg0KQ2hlZXJzLA0KQ2hh cmxlcw0KICAgIA0KICAgIENoZWVycywNCiAgICANCiAgICAtLQ0KICAgIE1hcmsgTm90dGluZ2hh bSAgIGh0dHBzOi8vd3d3Lm1ub3QubmV0Lw0KICAgIA0KICAgIA0KDQo= From nobody Wed Apr 10 06:30:42 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EB91200FE; Wed, 10 Apr 2019 06:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGo9jGDa5g9u; Wed, 10 Apr 2019 06:30:33 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8AC8120072; Wed, 10 Apr 2019 06:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3884; q=dns/txt; s=iport; t=1554903033; x=1556112633; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ywz0Y2vYoSvjjCToBflLF19Q6/b8iY0CEJiFAoOBuuE=; b=MUJR350KsVDfX0DK/XG2shmnplY9BPtL+QHzrpRYERmVm6N5oX48njvk oI9nycSmnqesRFbaUV2r4pQLyx/GqcBM9uSLBRWbdBpbo+WrDztZXj8BB s/8AziT+yLwVtks5ZBhtLkVEed3nmdXUzJPWrmTgBQMNXeFZH3hJ2yvVk U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAADk7q1c/5RdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBZiqBaycKhASIHI0jmEaBew4BAYRsAheFVCI?= =?us-ascii?q?0CQ0BAQMBAQkBAgECbSiFSgEBAQECASMRQwIFCwIBCA4EAwUCJgICAjAVAg4?= =?us-ascii?q?CBAENBQiCT0uBbgisZIEvii6BCyUBi0YXgUA/gRGDEj6HToJXA4sLggqYdQk?= =?us-ascii?q?Ck30iggaGFoxIgwaIUJN+AhEVgTAfOIFWcBU7gmyCQY4LQTGPTYEgAQE?= X-IronPort-AV: E=Sophos;i="5.60,332,1549929600"; d="scan'208";a="257744056" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Apr 2019 13:30:32 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x3ADUVqJ010597 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 Apr 2019 13:30:31 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 10 Apr 2019 09:30:30 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Wed, 10 Apr 2019 09:30:30 -0400 From: "Eric Voit (evoit)" To: Wesley Eddy , "tsv-art@ietf.org" CC: "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "ietf@ietf.org" , "netconf@ietf.org" Thread-Topic: Tsvart last call review of draft-ietf-netconf-netconf-event-notifications-17 Thread-Index: AQHU6XGhrLf+tGZ5QUSv4zZKpgLDaqY1arKA Date: Wed, 10 Apr 2019 13:30:30 +0000 Message-ID: References: <155422272574.6262.7757640015847252701@ietfa.amsl.com> In-Reply-To: <155422272574.6262.7757640015847252701@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.151, xch-rtp-011.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [netconf] Tsvart last call review of draft-ietf-netconf-netconf-event-notifications-17 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 13:30:35 -0000 PiBGcm9tOiBXZXNsZXkgRWRkeSwgQXByaWwgMiwgMjAxOSAxMjozMiBQTQ0KPiANCj4gUmV2aWV3 ZXI6IFdlc2xleSBFZGR5DQo+IFJldmlldyByZXN1bHQ6IFJlYWR5IHdpdGggSXNzdWVzDQo+IA0K PiBUaGlzIGRvY3VtZW50IGhhcyBiZWVuIHJldmlld2VkIGFzIHBhcnQgb2YgdGhlIHRyYW5zcG9y dCBhcmVhIHJldmlldyB0ZWFtJ3MNCj4gb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGtleSBJRVRG IGRvY3VtZW50cy4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuDQo+IHByaW1hcmlseSBmb3Ig dGhlIHRyYW5zcG9ydCBhcmVhIGRpcmVjdG9ycywgYnV0IGFyZSBjb3BpZWQgdG8gdGhlIGRvY3Vt ZW50J3MNCj4gYXV0aG9ycyBhbmQgV0cgdG8gYWxsb3cgdGhlbSB0byBhZGRyZXNzIGFueSBpc3N1 ZXMgcmFpc2VkIGFuZCBhbHNvIHRvIHRoZSBJRVRGDQo+IGRpc2N1c3Npb24gbGlzdCBmb3IgaW5m b3JtYXRpb24uDQo+IA0KPiBXaGVuIGRvbmUgYXQgdGhlIHRpbWUgb2YgSUVURiBMYXN0IENhbGws IHRoZSBhdXRob3JzIHNob3VsZCBjb25zaWRlciB0aGlzDQo+IHJldmlldyBhcyBwYXJ0IG9mIHRo ZSBsYXN0LWNhbGwgY29tbWVudHMgdGhleSByZWNlaXZlLiBQbGVhc2UgYWx3YXlzIENDIHRzdi0N Cj4gYXJ0QGlldGYub3JnIGlmIHlvdSByZXBseSB0byBvciBmb3J3YXJkIHRoaXMgcmV2aWV3Lg0K PiANCj4gSSByZXZpZXdlZCB0aGlzIGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIHNldCBvZiByZWxh dGVkIFdHIGRvY3VtZW50cyBvbg0KPiBORVRDT05GL1JFU1RDT05GIHN1YnNjcmlwdGlvbnMgYW5k IGV2ZW50IG5vdGlmaWNhdGlvbnMuICBJIGFsc28gaGF2ZSBzb21lDQo+IGNvbW1lbnRzIG9uIG90 aGVyIGRvY3VtZW50cyBpbiB0aGUgc2V0LCBzb21lIG9mIHdoaWNoIG1heSBpbmZsdWVuY2UgdGhp cw0KPiBvbmNlLCBzaW5jZSB0aGV5IGFyZSBjbG9zZWx5IHJlbGF0ZWQuDQo+IA0KPiBJbiBmaWd1 cmUgMywgYW5kIHRleHQgb24gcGFnZSAxMSwgdGhlcmUgaXMgYW4gZXhhbXBsZSB3aXRoIGEgRGlm ZlNlcnYgY29kZXBvaW50DQo+IHZhbHVlIG9mICIxMCIuICBUaGlzIGNvdWxkIGJlIGludGVycHJl dGVkIGFzIGJpbmFyeSwgZGVjaW1hbCwgaGV4YWRlY2ltYWwsIGV0Yy4NCj4gIEl0IHNob3VsZCBi ZSBjbGVhciB3aGF0IHRoZSBiYXNlIGlzIHN1cHBvc2VkIHRvIGJlLiAgSXQgc2VlbWVkIHByZXR0 eQ0KPiBhbWJpZ3VvdXMgaW4gdGhpcyBhbmQgdGhlIHJlbGF0ZWQgZG9jdW1lbnRzLCBzbyBpdCdz IG5vdCBhcHBhcmVudCB0aGF0IGFuDQo+IGltcGxlbWVudGVyIHdvdWxkIGJlIHN1cmUgdG8gZ2V0 IGl0IHJpZ2h0IG9yIGZvciBpdCB0byBiZSBjb21wYXRpYmxlLg0KDQpIaSBXZXNsZXksDQoNCkZp Z3VyZSAzIGluY2x1ZGVzIHRoZSBYTUwgZGVmaW5pdGlvbiA8ZHNjcD4xMDwvZHNjcD4NClRoaXMg aXMgYmVsb3cgdGhlIFhNTCBuYW1lc3BhY2UgInVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzpp ZXRmLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyINCiANCkluIHRoZSAiaWV0Zi1zdWJzY3JpYmVk LW5vdGlmaWNhdGlvbnMiIFlBTkcgbW9kZWwgd2hlcmUgdGhpcyAiZHNjcCIgdGFnIGlzIGRlZmlu ZWQsIGl0IGlzIHNob3duIHRvIGJlIG9mOg0KICAgICAgdHlwZSBpbmV0OmRzY3A7DQoNCmhpZ2hl ciBpbiB0aGF0IFlBTkcgbW9kZWwsICJpbmV0IiBwb2ludHMgdG8gUkZDIDY5OTE6IENvbW1vbiBZ QU5HIERhdGEgVHlwZXMuICBUaGlzIGlzIGEgY29yZSBkb2N1bWVudCBmb3IgWUFORyB3aGljaCBh bnkgWUFORyBpbXBsZW1lbnRlciBzaG91bGQgYmUgZmFtaWxpYXIuDQoNCldpdGhpbiBSRkMgNjk5 MSwgdGhlIGRlZmluaXRpb24gb2YgImRzY3AiIGlzDQoNCiAgICAgdHlwZWRlZiBkc2NwIHsNCiAg ICAgICB0eXBlIHVpbnQ4IHsNCiAgICAgICAgIHJhbmdlICIwLi42MyI7DQogICAgICAgfQ0KICAg ICAgIGRlc2NyaXB0aW9uDQogICAgICAgICJUaGUgZHNjcCB0eXBlIHJlcHJlc2VudHMgYSBEaWZm ZXJlbnRpYXRlZCBTZXJ2aWNlcyBDb2RlIFBvaW50DQogICAgICAgICB0aGF0IG1heSBiZSB1c2Vk IGZvciBtYXJraW5nIHBhY2tldHMgaW4gYSB0cmFmZmljIHN0cmVhbS4NCiAgICAgICAgIEluIHRo ZSB2YWx1ZSBzZXQgYW5kIGl0cyBzZW1hbnRpY3MsIHRoaXMgdHlwZSBpcyBlcXVpdmFsZW50DQog ICAgICAgICB0byB0aGUgRHNjcCB0ZXh0dWFsIGNvbnZlbnRpb24gb2YgdGhlIFNNSXYyLiI7DQog ICAgICAgcmVmZXJlbmNlDQogICAgICAgICJSRkMgMzI4OTogTWFuYWdlbWVudCBJbmZvcm1hdGlv biBCYXNlIGZvciB0aGUgRGlmZmVyZW50aWF0ZWQNCiAgICAgICAgICAgICAgICAgICBTZXJ2aWNl cyBBcmNoaXRlY3R1cmUNCiAgICAgICAgIFJGQyAyNDc0OiBEZWZpbml0aW9uIG9mIHRoZSBEaWZm ZXJlbnRpYXRlZCBTZXJ2aWNlcyBGaWVsZA0KICAgICAgICAgICAgICAgICAgIChEUyBGaWVsZCkg aW4gdGhlIElQdjQgYW5kIElQdjYgSGVhZGVycw0KICAgICAgICAgUkZDIDI3ODA6IElBTkEgQWxs b2NhdGlvbiBHdWlkZWxpbmVzIEZvciBWYWx1ZXMgSW4NCiAgICAgICAgICAgICAgICAgICB0aGUg SW50ZXJuZXQgUHJvdG9jb2wgYW5kIFJlbGF0ZWQgSGVhZGVycyI7DQogICAgIH0NCg0KSG9wZWZ1 bGx5IHRoaXMgd2lsbCBhZGRyZXNzIHRoZSBhbWJpZ3VpdHkuICANCg0KVGhhbmtzLA0KRXJpYw0K DQoNCj4gSSBoYXZlIG90aGVyIGJyb2FkIGNvbW1lbnRzIG9uIHRoZSBEU0NQIHVzYWdlIHRoYXQg d2lsbCBiZSBpbiByZXZpZXcNCj4gY29tbWVudHMgZm9yIHRoZSBzdWJzY3JpYmVkLW5vdGlmaWNh dGlvbnMgZHJhZnQgd2hlcmUgaXQgaXMgbW9yZSBhcHByb3ByaWF0ZS4NCg0K From nobody Wed Apr 10 06:51:05 2019 Return-Path: <0100016a07840591-b6aa476d-1837-447f-907d-93c137a36ed7-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301FB12039B; Wed, 10 Apr 2019 06:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PY4PM1zsjk4H; Wed, 10 Apr 2019 06:50:56 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65101203A7; Wed, 10 Apr 2019 06:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1554904254; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=WHt7v6dYPHsTe/G3XRJDaFDEMyU+ec6wxyVJidf8HBQ=; b=P/cwRVn1hGjnIdeXrZQvv4d2X7l1YuE8W2jhwS71EUuJypWIa/mItaS6pTKQg47V O+L8gUHBiVgSX1QZJOMOp5Hnr/150bxf/jjpQObv2riS5oTRFYwAQUhYVcb4JAltQj2 3EmMfK0EI28dHkTmDoTO3XvyDEfhQmuRQOxxpdZc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Kent Watsen In-Reply-To: Date: Wed, 10 Apr 2019 13:50:53 +0000 Cc: Mark Nottingham , Patrick McManus , "httpbis-chairs@ietf.org" , "netconf-chairs@ietf.org" , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <0100016a07840591-b6aa476d-1837-447f-907d-93c137a36ed7-000000@email.amazonses.com> References: <01000169def07790-5f902f1b-ddce-438b-8e05-d4b7e82818bc-000000@email.amazonses.com> <56E946DC-A690-4B1E-8FB5-683473955C5D@gmail.com> <20190404.163346.857364419603319540.mbj@tail-f.com> <01000169e94f9d0d-7f85f47b-9f92-41a2-94b1-0061bb9bdb3d-000000@email.amazonses.com> <1783839F-4A70-46BA-8DC4-C386CE8A07C0@mnot.net> To: "Charles Eckel (eckelcu)" X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.10-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] time to meet today after 5pm X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 13:50:58 -0000 > What do you mean by "REST-like"? >=20 > With RESTCONF, the YANG models supported by the RESTCONF server result = in it exposing RESTful or REST-like APIs to the RESTCONF client. You can = view the RESTCONF server as supporting a set of REST APIs with some = additional conventions/requirements on the structure on the URIs, such = as the root of the RESTCONF API, use of specific HTTP response codes, = etc. The root of the API is discovered via /.well-known/host-meta, per = https://tools.ietf.org/html/rfc8040#section-3.1. As for what is RESTCONF, from Sections 1.2: RESTCONF is not intended to replace NETCONF, but rather to provide an HTTP interface that follows Representational State Transfer (REST) principles [REST-Dissertation] and is compatible with the NETCONF datastore model. And Section 1.3: RESTCONF combines the simplicity of HTTP with the predictability and automation potential of a schema-driven API. Knowing the YANG modules used by the server, a client can derive all management resource URLs and the proper structure of all RESTCONF requests and responses. This strategy obviates the need for responses provided by the server to contain Hypermedia as the Engine of Application State (HATEOAS) links, originally described in Roy Fielding's doctoral dissertation [REST-Dissertation], because the client can determine the links it needs from the YANG modules. Kent From nobody Wed Apr 10 08:11:45 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00161203C4; Wed, 10 Apr 2019 08:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJwmtkikcoX6; Wed, 10 Apr 2019 08:11:30 -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 457311203BD; Wed, 10 Apr 2019 08:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29408; q=dns/txt; s=iport; t=1554909090; x=1556118690; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=D93N1h51gmURt9MoFHVTc8Sz52hZeGMxJW3ejVszI7Y=; b=ljnEAdEDmGsJ02q1L1ul1QfrtWgI4Bij3bf5tSllz1d1x/mO+3Li3KXZ XqhbW5JRHrSjiINQuk9d5NdE9hLWvLNRczfrprg/oXTSkSzC3Ed1Zi0Y4 Qn72bDKaW5smSQTDyGSvoV0K0tPIYb756mh8twGNyLz81CMeRxgPmt9PC w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BfAABbB65c/4ENJK1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZYEPWCqBaxQTCoQElRolmkEOAQGEbAIXhVQiOBIBAQMBAQk?= =?us-ascii?q?BAgECbSiFSwMDI08FAhACAQgVEBMHAwICAjAUEQIEDgUagj1LgRJkrHOBL4o?= =?us-ascii?q?rgTCLRxeBQD+BEScME4JMPoRDgwsxgiYDjRWEL4dfjAViCQKLYkGHYhqCBpJ?= =?us-ascii?q?ejHCPcYJzAhEVgTA2ISiBLnAVZQGCQT6QDkExj02BIAEB?= X-IronPort-AV: E=Sophos;i="5.60,332,1549929600"; d="scan'208,217";a="260709870" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Apr 2019 15:11:13 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x3AFBDiQ006893 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 Apr 2019 15:11:13 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 10 Apr 2019 11:11:12 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1473.003; Wed, 10 Apr 2019 11:11:12 -0400 From: "Carlos Pignataro (cpignata)" To: "Eric Voit (evoit)" CC: "ops-dir@ietf.org" , "draft-ietf-netconf-subscribed-notifications.all@ietf.org" , "ietf@ietf.org" , "netconf@ietf.org" Thread-Topic: Opsdir last call review of draft-ietf-netconf-subscribed-notifications-23 Thread-Index: AQHU7xeskVwDPMWz+0mc9NXGW1eimKY1xCMA Date: Wed, 10 Apr 2019 15:11:12 +0000 Message-ID: References: <155451947938.10151.12663725914439778891@ietfa.amsl.com> <3e994b49f5c2405cb72d1f0345c5e496@XCH-RTP-013.cisco.com> In-Reply-To: <3e994b49f5c2405cb72d1f0345c5e496@XCH-RTP-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.104.8) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.6.129] Content-Type: multipart/alternative; boundary="_000_C156DC6548644D1FB5EAEE574A35EA2Fciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.152, xch-rtp-012.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [netconf] Opsdir last call review of draft-ietf-netconf-subscribed-notifications-23 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 15:11:33 -0000 --_000_C156DC6548644D1FB5EAEE574A35EA2Fciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEVyaWMsDQoNCk9uIEFwciA5LCAyMDE5LCBhdCA1OjAzIFBNLCBFcmljIFZvaXQgKGV2b2l0 KSA8ZXZvaXRAY2lzY28uY29tPG1haWx0bzpldm9pdEBjaXNjby5jb20+PiB3cm90ZToNCg0KSGkg Q2FybG9zLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcuICBTb21lIHRob3VnaHRzIGluLWxpbmXi gKYNCg0KDQpUaGFua3MgZm9yIHRoZSBmb2xsb3ctdXAuDQoNCkZyb206IENhcmxvcyBQaWduYXRh cm8sIEFwcmlsIDUsIDIwMTkgMTA6NTggUE0NCg0KUmV2aWV3ZXI6IENhcmxvcyBQaWduYXRhcm8N ClJldmlldyByZXN1bHQ6IEhhcyBOaXRzDQoNCkhpLA0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBk b2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBPcGVyYXRpb25hbCBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcN CmVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0 aGUgSUVTRy4gIFRoZXNlDQpjb21tZW50cyB3ZXJlIHdyaXR0ZW4gd2l0aCB0aGUgaW50ZW50IG9m IGltcHJvdmluZyB0aGUgb3BlcmF0aW9uYWwgYXNwZWN0cyBvZg0KdGhlIElFVEYgZHJhZnRzLiBD b21tZW50cyB0aGF0IGFyZSBub3QgYWRkcmVzc2VkIGluIGxhc3QgY2FsbCBtYXkgYmUgaW5jbHVk ZWQgaW4NCkFEIHJldmlld3MgZHVyaW5nIHRoZSBJRVNHIHJldmlldy4gIERvY3VtZW50IGVkaXRv cnMgYW5kIFdHIGNoYWlycyBzaG91bGQNCnRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBh bnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpTdW1tYXJ5OiBBbG1vc3QgUmVhZHkNCg0K VGhpcyBpcyBhIGNvbXByZWhlbnNpdmUgdmVyeSB3ZWxsIHdyaXR0ZW4gZG9jdW1lbnQuDQoNCkZy b20gYW4gb3BlcmF0aW9uYWwgcG9pbnQgb2YgdmlldywgYXMgcGVyIHRoZSBvcHMtZGlyIHJldmll dywgSSBoYXZlIG5vDQpjb25jZXJucyBvciBjb21tZW50cy4gTWlnaHQgYmUgbmljZSB0byBjb2xs ZWN0IHNvbWUgb2YgdGhlIG9wZXJhdGlvbmFsIHBvaW50cw0KaW4gYW4gT3BlcmF0aW9ucyBDb25z aWRlcmF0aW9uIHNlY3Rpb24sIHBhcnRpY3VsYXJseSBnaXZlbiB0aGUgZG9jdW1lbnQNCnN0cnVj dHVyZSBvZiBTZWN0aW9uIDUueCwgIlpaWiBDb25zaWRlcmF0aW9ucyIuDQoNCkluICJpbXBsZW1l bnRhdGlvbiBjb25zaWRlcmF0aW9ucyIgdGhlcmUgYXJlIGEgY291cGxlIHdoaWNoIGFyZSByZWFs bHkgb3BlcmF0aW9uYWwgY29uc2lkZXJhdGlvbnMuICBGb3IgZXhhbXBsZSB0aGUgZmlyc3QgYW5k IHRoaXJkIGJ1bGxldHMgbWlnaHQgcXVhbGlmeSBhcyBvcGVyYXRpb25hbC4gIFRoZSBoYXJkIHBh cnQgaXMgdGhhdCB0aGUgb3BlcmF0aW9uYWwgY29uc2lkZXJhdGlvbnMgdG8gZXhwb3NlIHdpbGwg dmFyeSBieSB0aGUgc3Vic2V0IG9mIGZlYXR1cmUgd2hpY2ggYXJlIHNlbGVjdGVkLiAgU28gSSBj YW4gaW1hZ2luZSB0aGF0IG11Y2ggdGV4dCBjb3VsZCBiZSB3cml0dGVuIG9uIGJlc3Qgb3BlcmF0 aW9uYWwgcHJhY3RpY2VzLiAgSSBhbSBob3BpbmcgdGhhdCBzdWNoIGRvY3VtZW50cyBjb3VsZCBm b2xsb3cgdGhpcyBvbmUgYmFzZWQgb24gc3BlY2lmaWMgZGVwbG95bWVudCBjb250ZXh0cy4NCg0K U29ycnkgSSB3YXMgbm90IGV4cGxpY2l0LiBXaGlsZSBtYW55IG9mIHRoZXNlIGNvbnNpZGVyYXRp b25zIGhhdmUgb3BlcmF0aW9uYWwgaW1wbGljYXRpb25zLCBJIG1lYW50IHRoaW5ncyBsaWtlIEFw cGVuZGl4IEEgb2YgUkZDIDU3MDYsIG1vcmUgZGVwbG95bWVudCB0aGFuIGltcGxlbWVudGF0aW9u Lg0KDQoNCkkgZG8gaGF2ZSBvbmUgaW1wb3J0YW50IHF1ZXN0aW9uIGZvciBjb25zaWRlcmF0aW9u LCB3aGljaCBpczogd2hhdCBpcyAqcmVhbGx5Kg0KdGhlIHJlbGF0aW9uc2hpcCBvZiB0aGlzICgr IGRyYWZ0LWlldGYtbmV0Y29uZi1uZXRjb25mLWV2ZW50LW5vdGlmaWNhdGlvbnMNCnBvdGVudGlh bGx5KSB3aXRoIFJGQyA1Mjc3PyBBIE5vcm1hdGl2ZSByZWZlcmVuY2UsIHRoaXMgZG9jIGhhcyBu byBtZXRhZGF0YQ0KcmVnYXJkaW5nIFVwZGF0aW5nLCBPYnNvbGV0aW5nLCBldGMuIFlldCBsb3Rz IG9mIGl0IGlzIGluZGVlZCBhIHN1cGVyc2V0IG9mIGl0Lg0KDQpXZSB3ZW50IGFyb3VuZCBhbmQg YXJvdW5kIGluIHRoZSBXRyBvbiB0aGlzIGZvciBhIGJpdC4gIFRoZSBpbml0aWFsIGRlY2lzaW9u IHdhcyB0aGF0IHdlIHdlcmUgZ29pbmcgdG8gb2Jzb2xldGUgUkZDLTUyNzcuIEhvd2V2ZXIgdGhl IHByb2JsZW0gd2FzIHRoYXQgUkZDLTUyNzcgU2VjdGlvbiA0IGhhcyBhIDxub3RpZmljYXRpb24+ IGVsZW1lbnQgZGVmaW5lZCB3aGljaCB3ZSBhcmUgbm90IHJlcGxhY2luZyB5ZXQuIFRoaXMgPG5v dGlmaWNhdGlvbj4gaXMgdXNlZCBpbiBzZXZlcmFsIGltcG9ydGFudCBwbGFjZXMuICBFeGFtcGxl cyBpbmNsdWRlIFJGQy04MDQwIHNlY3Rpb24gNi40IGFuZCBSRkMtNzk1MCBTZWN0aW9uIDcuMTYu Mi4NCg0KRG9lcyB0aGlzIGRlc2NyaWJlIGFuIFVwZGF0ZSBvZiBzcGVjaWZpYyBzZWN0aW9ucyB0 aGVuPyBPciB3b3VsZCB3YW50IHRvIGJyaW5nIGluIHRoZSBub3RpZmljYXRpb24gYW5kIGRvIGEg ZnVsbCBiaXM/DQoNCkF0IHRoaXMgcG9pbnQsIG15IGNvbW1lbnQgaXMgdGhhdCB0aGUgcmVsYXRp b25zaGlwIGlzIG5vdCBleHBsaWNpdC4NCg0KDQpTbyB3ZSBkaWRuJ3Qgd2FudCB0byByZWNvbW1l bmQgYW4gb2Jzb2xldGUgd2l0aG91dCBhIHJlcGxhY2VtZW50IG9mIHRoYXQgPG5vdGlmaWNhdGlv bj4uICBUaGUgZ29vZCBuZXdzIGlzIHRoYXQgd2UgYXJlIHdvcmtpbmcgb24gYSByZXBsYWNlbWVu dCBmb3IgdGhpcyBub3RpZmljYXRpb24uICBTZWU6IGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmlj YXRpb24tbWVzc2FnZXMgICAgIEJ1dCB0aGlzIHN0aWxsIGhhcyBhIHdoaWxlIHRvIGdvIGJlZm9y ZSBpdCBpcyByZWFkeS4gIEFzIGEgcmVzdWx0IHdlIGFyZSBsZWZ0IHdpdGggU2VjdGlvbiAxLjQg b2YgZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyB3aGljaCBkZXNj cmliZXMgdGhlIHJlbGF0aW9uc2hpcCB3aXRoIFJGQy01Mjc3Lg0KDQpUaGlzIGlzIHN0aWxsIHNv bWV3aGF0IGNvbmZ1c2luZy4gU2VjdGlvbiAxLjQgc2F5czoNCg0KICAgVGhpcyBkb2N1bWVudCBp cyBpbnRlbmRlZCB0byBwcm92aWRlIGEgc3VwZXJzZXQgb2YgdGhlIHN1YnNjcmlwdGlvbg0KICAg Y2FwYWJpbGl0aWVzIGluaXRpYWxseSBkZWZpbmVkIHdpdGhpbiBbUkZDNTI3N10uDQoNCkJ1dCBp ZiBpdCBpcyByZWFsbHkgYSBzdXBlcnNldCwgaXMgaXQgb2Jzb2xldGluZyBpdD8gUzEuNCBmdXJ0 aGVyIGdvZXM6DQoNCiAgIEVzcGVjaWFsbHkgd2hlbg0KICAgZXh0ZW5kaW5nIGFuIGV4aXN0aW5n IFtSRkM1Mjc3XSBpbXBsZW1lbnRhdGlvbiwgaXQgaXMgaW1wb3J0YW50IHRvDQogICB1bmRlcnN0 YW5kIHdoYXQgaGFzIGJlZW4gcmV1c2VkIGFuZCB3aGF0IGhhcyBiZWVuIHJlcGxhY2VkLg0KDQpT aW1pbGFybHksIHJldXNlK3JlcGxhY2UgbWVhbnMgb2Jzb2xldGU/IE9yIHVwZGF0ZT8gOi0pDQoN Cg0KSSByZWNvbW1lbmQgdGhlIGF1dGhvcnMrQURzIGNvbnNpZGVyIHdoZXRoZXIgdGhlcmUgaXMg YW55IG1vcmUgZm9ybWFsDQpyZWxhdGlvbnNoaXAgd2l0aCBSRkMgNTI3NyB0aGF0IHdvdWxkIHJl cXVpcmUgbWV0YS10YWdnaW5nIHRoZSBSRkMuDQoNCkkgdGhpbmsgdGhhdCB0aGlzIGlzIGZ1bGx5 IGFwcHJvcHJpYXRlIGFzIHdlIGZpbmlzaCBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9u LW1lc3NhZ2VzDQoNCkkgZG8gbm90IHRoaW5rIHlvdSBuZWVkIHRvIHdhaXQgZm9yIGRyYWZ0LWll dGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMgKGFuZCBkZWxheSBkcmFmdC1pZXRmLW5l dGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zKSBpbiBvcmRlciB0byBoYXZlIGFuIGFwcHJv cHJpYXRlIG1ldGEtcmVmZXJlbmNlLiBQZXJoYXBzIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmlj YXRpb24tbWVzc2FnZXMgd2lsbCB1cGRhdGUgc29tZXRoaW5nIChkcmFmdC1pZXRmLW5ldGNvbmYt c3Vic2NyaWJlZC1ub3RpZmljYXRpb25zPykNCg0KVGhhbmtzLA0KDQpDYXJsb3MuDQoNCg0KVGhh bmtzIQ0KRXJpYw0KDQpUaGFua3MsDQoNCkNhcmxvcyBQaWduYXRhcm8uDQoNCg== --_000_C156DC6548644D1FB5EAEE574A35EA2Fciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <06D1BAFEFBA3944AA0124935401F0BC8@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpLCBFcmljLA0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPk9uIEFwciA5LCAyMDE5LCBhdCA1OjAzIFBNLCBFcmljIFZvaXQgKGV2b2l0KSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmV2b2l0QGNpc2NvLmNvbSIgY2xhc3M9IiI+ZXZvaXRAY2lzY28u Y29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5l d2xpbmUiPg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IE1lbmxvLVJlZ3VsYXI7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3Jh dGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xh c3M9IiI+SGkNCiBDYXJsb3MsPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IE1lbmxvLVJlZ3VsYXI7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3Jh dGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAs IDApOyBmb250LWZhbWlseTogTWVubG8tUmVndWxhcjsgZm9udC1zaXplOiAxMXB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0 aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IE1lbmxvLVJlZ3VsYXI7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3Jh dGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xh c3M9IiI+VGhhbmtzDQogZm9yIHRoZSByZXZpZXcuICZuYnNwO1NvbWUgdGhvdWdodHMgaW4tbGlu ZeKApjwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBNZW5sby1SZWd1bGFyOyBmb250LXNpemU6IDExcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBj bGFzcz0iIj4NCjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IE1lbmxvLVJlZ3VsYXI7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KVGhhbmtzIGZvciB0aGUgZm9sbG93LXVwLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogTWVubG8tUmVndWxhcjsgZm9u dC1zaXplOiAxMXB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6 IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KRnJvbTogQ2Fy bG9zIFBpZ25hdGFybywgQXByaWwgNSwgMjAxOSAxMDo1OCBQTTxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NClJldmlld2VyOiBDYXJsb3MgUGlnbmF0YXJvPGJyIGNsYXNzPSIiPg0KUmV2aWV3 IHJlc3VsdDogSGFzIE5pdHM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpIaSw8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBw YXJ0IG9mIHRoZSBPcGVyYXRpb25hbCBkaXJlY3RvcmF0ZSdzIG9uZ29pbmc8YnIgY2xhc3M9IiI+ DQplZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkg dGhlIElFU0cuICZuYnNwO1RoZXNlPGJyIGNsYXNzPSIiPg0KY29tbWVudHMgd2VyZSB3cml0dGVu IHdpdGggdGhlIGludGVudCBvZiBpbXByb3ZpbmcgdGhlIG9wZXJhdGlvbmFsIGFzcGVjdHMgb2Y8 YnIgY2xhc3M9IiI+DQp0aGUgSUVURiBkcmFmdHMuIENvbW1lbnRzIHRoYXQgYXJlIG5vdCBhZGRy ZXNzZWQgaW4gbGFzdCBjYWxsIG1heSBiZSBpbmNsdWRlZCBpbjxiciBjbGFzcz0iIj4NCkFEIHJl dmlld3MgZHVyaW5nIHRoZSBJRVNHIHJldmlldy4gJm5ic3A7RG9jdW1lbnQgZWRpdG9ycyBhbmQg V0cgY2hhaXJzIHNob3VsZDxiciBjbGFzcz0iIj4NCnRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3Qg bGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NClN1bW1hcnk6IEFsbW9zdCBSZWFkeTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N ClRoaXMgaXMgYSBjb21wcmVoZW5zaXZlIHZlcnkgd2VsbCB3cml0dGVuIGRvY3VtZW50LjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi PkZyb20gYW4gb3BlcmF0aW9uYWwgcG9pbnQgb2YgdmlldywgYXMgcGVyIHRoZSBvcHMtZGlyIHJl dmlldywgSSBoYXZlIG5vPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KY29uY2VybnMgb3Ig Y29tbWVudHMuIE1pZ2h0IGJlIG5pY2UgdG8gY29sbGVjdCBzb21lIG9mIHRoZSBvcGVyYXRpb25h bCBwb2ludHM8YnIgY2xhc3M9IiI+DQppbiBhbiBPcGVyYXRpb25zIENvbnNpZGVyYXRpb24gc2Vj dGlvbiwgcGFydGljdWxhcmx5IGdpdmVuIHRoZSBkb2N1bWVudDxiciBjbGFzcz0iIj4NCnN0cnVj dHVyZSBvZiBTZWN0aW9uIDUueCwgJnF1b3Q7WlpaIENvbnNpZGVyYXRpb25zJnF1b3Q7LjxiciBj bGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IE1lbmxvLVJlZ3VsYXI7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3Jh dGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBNZW5sby1SZWd1bGFyOyBmb250LXNpemU6IDExcHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNs YXNzPSIiPkluDQogJnF1b3Q7aW1wbGVtZW50YXRpb24gY29uc2lkZXJhdGlvbnMmcXVvdDsgdGhl cmUgYXJlIGEgY291cGxlIHdoaWNoIGFyZSByZWFsbHkgb3BlcmF0aW9uYWwgY29uc2lkZXJhdGlv bnMuICZuYnNwO0ZvciBleGFtcGxlIHRoZSBmaXJzdCBhbmQgdGhpcmQgYnVsbGV0cyBtaWdodCBx dWFsaWZ5IGFzIG9wZXJhdGlvbmFsLiAmbmJzcDtUaGUgaGFyZCBwYXJ0IGlzIHRoYXQgdGhlIG9w ZXJhdGlvbmFsIGNvbnNpZGVyYXRpb25zIHRvIGV4cG9zZSB3aWxsIHZhcnkgYnkgdGhlIHN1YnNl dCBvZg0KIGZlYXR1cmUgd2hpY2ggYXJlIHNlbGVjdGVkLiAmbmJzcDtTbyBJIGNhbiBpbWFnaW5l IHRoYXQgbXVjaCB0ZXh0IGNvdWxkIGJlIHdyaXR0ZW4gb24gYmVzdCBvcGVyYXRpb25hbCBwcmFj dGljZXMuICZuYnNwO0kgYW0gaG9waW5nIHRoYXQgc3VjaCBkb2N1bWVudHMgY291bGQgZm9sbG93 IHRoaXMgb25lIGJhc2VkIG9uIHNwZWNpZmljIGRlcGxveW1lbnQgY29udGV4dHMuPC9zcGFuPjxi ciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IE1lbmxvLVJl Z3VsYXI7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5Tb3Jy eSBJIHdhcyBub3QgZXhwbGljaXQuIFdoaWxlIG1hbnkgb2YgdGhlc2UgY29uc2lkZXJhdGlvbnMg aGF2ZSBvcGVyYXRpb25hbCBpbXBsaWNhdGlvbnMsIEkgbWVhbnQgdGhpbmdzIGxpa2UgQXBwZW5k aXggQSBvZiBSRkMgNTcwNiwgbW9yZSBkZXBsb3ltZW50IHRoYW4gaW1wbGVtZW50YXRpb24uPC9k aXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IE1lbmxvLVJlZ3VsYXI7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3Jh dGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZv bnQtZmFtaWx5OiBNZW5sby1SZWd1bGFyOyBmb250LXNpemU6IDExcHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1 c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9u OiBub25lOyIgY2xhc3M9IiI+DQpJIGRvIGhhdmUgb25lIGltcG9ydGFudCBxdWVzdGlvbiBmb3Ig Y29uc2lkZXJhdGlvbiwgd2hpY2ggaXM6IHdoYXQgaXMgKnJlYWxseSo8YnIgY2xhc3M9IiI+DQp0 aGUgcmVsYXRpb25zaGlwIG9mIHRoaXMgKCYjNDM7IGRyYWZ0LWlldGYtbmV0Y29uZi1uZXRjb25m LWV2ZW50LW5vdGlmaWNhdGlvbnM8YnIgY2xhc3M9IiI+DQpwb3RlbnRpYWxseSkgd2l0aCBSRkMg NTI3Nz8gQSBOb3JtYXRpdmUgcmVmZXJlbmNlLCB0aGlzIGRvYyBoYXMgbm8gbWV0YWRhdGE8YnIg Y2xhc3M9IiI+DQpyZWdhcmRpbmcgVXBkYXRpbmcsIE9ic29sZXRpbmcsIGV0Yy4gWWV0IGxvdHMg b2YgaXQgaXMgaW5kZWVkIGEgc3VwZXJzZXQgb2YgaXQuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1 b3RlPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog TWVubG8tUmVndWxhcjsgZm9udC1zaXplOiAxMXB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9 IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IE1lbmxvLVJlZ3VsYXI7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6 IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+V2UNCiB3ZW50IGFy b3VuZCBhbmQgYXJvdW5kIGluIHRoZSBXRyBvbiB0aGlzIGZvciBhIGJpdC4gJm5ic3A7VGhlIGlu aXRpYWwgZGVjaXNpb24gd2FzIHRoYXQgd2Ugd2VyZSBnb2luZyB0byBvYnNvbGV0ZSBSRkMtNTI3 Ny4gSG93ZXZlciB0aGUgcHJvYmxlbSB3YXMgdGhhdCBSRkMtNTI3NyBTZWN0aW9uIDQgaGFzIGEg Jmx0O25vdGlmaWNhdGlvbiZndDsgZWxlbWVudCBkZWZpbmVkIHdoaWNoIHdlIGFyZSBub3QgcmVw bGFjaW5nIHlldC4gVGhpcyAmbHQ7bm90aWZpY2F0aW9uJmd0Ow0KIGlzIHVzZWQgaW4gc2V2ZXJh bCBpbXBvcnRhbnQgcGxhY2VzLiAmbmJzcDtFeGFtcGxlcyBpbmNsdWRlIFJGQy04MDQwIHNlY3Rp b24gNi40IGFuZCBSRkMtNzk1MCBTZWN0aW9uIDcuMTYuMi48L3NwYW4+PGJyIHN0eWxlPSJjYXJl dC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogTWVubG8tUmVndWxhcjsgZm9udC1z aXplOiAxMXB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpEb2VzIHRoaXMgZGVzY3JpYmUgYW4g VXBkYXRlIG9mIHNwZWNpZmljIHNlY3Rpb25zIHRoZW4/IE9yIHdvdWxkIHdhbnQgdG8gYnJpbmcg aW4gdGhlIG5vdGlmaWNhdGlvbiBhbmQgZG8gYSBmdWxsIGJpcz88L2Rpdj4NCjxkaXY+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkF0IHRoaXMgcG9pbnQsIG15IGNvbW1lbnQgaXMgdGhhdCB0 aGUgcmVsYXRpb25zaGlwIGlzIG5vdCBleHBsaWNpdC48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBz dHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IE1lbmxvLVJlZ3Vs YXI7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBNZW5sby1SZWd1 bGFyOyBmb250LXNpemU6IDExcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNw bGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPlNvDQogd2UgZGlkbid0IHdhbnQgdG8g cmVjb21tZW5kIGFuIG9ic29sZXRlIHdpdGhvdXQgYSByZXBsYWNlbWVudCBvZiB0aGF0ICZsdDtu b3RpZmljYXRpb24mZ3Q7LiAmbmJzcDtUaGUgZ29vZCBuZXdzIGlzIHRoYXQgd2UgYXJlIHdvcmtp bmcgb24gYSByZXBsYWNlbWVudCBmb3IgdGhpcyBub3RpZmljYXRpb24uICZuYnNwO1NlZTogZHJh ZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcyAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtCdXQgdGhpcyBzdGlsbCBoYXMgYSB3aGlsZSB0byBnbyBiZWZvcmUgaXQNCiBpcyByZWFk eS4gJm5ic3A7QXMgYSByZXN1bHQgd2UgYXJlIGxlZnQgd2l0aCBTZWN0aW9uIDEuNCBvZiBkcmFm dC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIHdoaWNoIGRlc2NyaWJlcyB0 aGUgcmVsYXRpb25zaGlwIHdpdGggUkZDLTUyNzcuPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IE1lbmxvLVJlZ3VsYXI7IGZvbnQtc2l6ZTog MTFweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5UaGlzIGlzIHN0aWxsIHNvbWV3aGF0 IGNvbmZ1c2luZy4gU2VjdGlvbiAxLjQgc2F5czo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBp cyBpbnRlbmRlZCB0byBwcm92aWRlIGEgc3VwZXJzZXQgb2YgdGhlIHN1YnNjcmlwdGlvbjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7Y2FwYWJpbGl0aWVzIGluaXRpYWxseSBkZWZp bmVkIHdpdGhpbiBbUkZDNTI3N10uICZuYnNwOzwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRl cmNoYW5nZS1uZXdsaW5lIj4NCkJ1dCBpZiBpdCBpcyByZWFsbHkgYSBzdXBlcnNldCwgaXMgaXQg b2Jzb2xldGluZyBpdD8gUzEuNCBmdXJ0aGVyIGdvZXM6PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7RXNwZWNpYWxseSB3aGVuPC9kaXY+DQo8ZGl2 PiZuYnNwOyAmbmJzcDtleHRlbmRpbmcgYW4gZXhpc3RpbmcgW1JGQzUyNzddIGltcGxlbWVudGF0 aW9uLCBpdCBpcyBpbXBvcnRhbnQgdG8NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO3VuZGVy c3RhbmQgd2hhdCBoYXMgYmVlbiByZXVzZWQgYW5kIHdoYXQgaGFzIGJlZW4gcmVwbGFjZWQuJm5i c3A7PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KU2ltaWxh cmx5LCByZXVzZSYjNDM7cmVwbGFjZSBtZWFucyBvYnNvbGV0ZT8gT3IgdXBkYXRlPyA6LSk8L2Rp dj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBNZW5sby1SZWd1bGFyOyBmb250LXNpemU6IDExcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBj bGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogTWVu bG8tUmVndWxhcjsgZm9udC1zaXplOiAxMXB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNz PSIiPg0KSSByZWNvbW1lbmQgdGhlIGF1dGhvcnMmIzQzO0FEcyBjb25zaWRlciB3aGV0aGVyIHRo ZXJlIGlzIGFueSBtb3JlIGZvcm1hbDxiciBjbGFzcz0iIj4NCnJlbGF0aW9uc2hpcCB3aXRoIFJG QyA1Mjc3IHRoYXQgd291bGQgcmVxdWlyZSBtZXRhLXRhZ2dpbmcgdGhlIFJGQy48YnIgY2xhc3M9 IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBNZW5sby1SZWd1bGFyOyBmb250LXNpemU6IDExcHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246 IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogTWVubG8tUmVndWxhcjsgZm9udC1zaXplOiAxMXB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9u OiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0i Ij5JDQogdGhpbmsgdGhhdCB0aGlzIGlzIGZ1bGx5IGFwcHJvcHJpYXRlIGFzIHdlIGZpbmlzaCBk cmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzPC9zcGFuPjxiciBzdHlsZT0i Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IE1lbmxvLVJlZ3VsYXI7IGZv bnQtc2l6ZTogMTFweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KSSBkbyBub3QgdGhpbmsgeW91 IG5lZWQgdG8gd2FpdCBmb3IgZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdl cyZuYnNwOyhhbmQgZGVsYXkgZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0 aW9ucykgaW4gb3JkZXIgdG8gaGF2ZSBhbiBhcHByb3ByaWF0ZSBtZXRhLXJlZmVyZW5jZS4gUGVy aGFwcyZuYnNwO2RyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMgd2lsbCB1 cGRhdGUgc29tZXRoaW5nIChkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRp b25zPyk8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rp dj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkNhcmxvcy48L2Rpdj4NCjxkaXY+ PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IE1lbmxvLVJlZ3VsYXI7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNz PSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBNZW5sby1SZWd1bGFyOyBmb250LXNpemU6IDExcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0 OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPlRoYW5rcyE8L3Nw YW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogTWVu bG8tUmVndWxhcjsgZm9udC1zaXplOiAxMXB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+ DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IE1l bmxvLVJlZ3VsYXI7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5v bmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+RXJpYzwvc3Bhbj48YnIg c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBNZW5sby1SZWd1 bGFyOyBmb250LXNpemU6IDExcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBz dHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IE1lbmxvLVJlZ3Vs YXI7IGZvbnQtc2l6ZTogMTFweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBNZW5sby1SZWd1bGFyOyBmb250 LXNpemU6IDExcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQpUaGFua3MsPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQ2FybG9zIFBpZ25hdGFyby48L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_C156DC6548644D1FB5EAEE574A35EA2Fciscocom_-- From nobody Wed Apr 10 09:17:35 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A34171203D7; Wed, 10 Apr 2019 09:17:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: netconf@ietf.org, ietf@ietf.org, draft-ietf-netconf-restconf-notif.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Sparks Message-ID: <155491304260.9197.1007765785277967184@ietfa.amsl.com> Date: Wed, 10 Apr 2019 09:17:22 -0700 Archived-At: Subject: [netconf] Genart last call review of draft-ietf-netconf-restconf-notif-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 16:17:23 -0000 Reviewer: Robert Sparks Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-netconf-restconf-notif-13 Reviewer: Robert Sparks Review Date: 2019-04-10 IETF LC End Date: 2019-04-12 IESG Telechat date: Not scheduled for a telechat Summary: Ready for publication as a proposed standard Nits/editorial comments: The abstract is quite terse. Please consider expanding it to something that stands better by itself. The sentence that starts "Driving these requirements" in the introduction does not follow where it sits in the paragraph. There is no antecedent for "these requirements". I suggest replacing the sentence with "Requirements for these mechanisms are captured in [RFC7923]. The second sentence in the first paragraph of section 3 is a run-on. I suggest s/2.4, the/2.4. The/ From nobody Wed Apr 10 09:37:08 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D18912038B for ; Wed, 10 Apr 2019 09:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3qpJKgOiah7 for ; Wed, 10 Apr 2019 09:37:02 -0700 (PDT) Received: from us-smtp-delivery-128.mimecast.com (us-smtp-delivery-128.mimecast.com [63.128.21.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46FE712037D for ; Wed, 10 Apr 2019 09:37:01 -0700 (PDT) Received: from ex-hc1.corp.adtran.com (ex-hc1.adtran.com [76.164.174.81]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-340-kjh9CFiFMduIJCd_41VUkw-1; Wed, 10 Apr 2019 12:36:55 -0400 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0382.000; Wed, 10 Apr 2019 11:36:54 -0500 From: NICK HANCOCK To: Kent Watsen CC: Mahesh Jethanandani , "netconf@ietf.org" Thread-Topic: [netconf] Adoption poll for tcp-client-server and http-client-server draft Thread-Index: AQHU48WK88pkUu3tWEqeuFS0y837C6Yd+NxQgBURBQCAAjWfgA== Date: Wed, 10 Apr 2019 16:36:52 +0000 Message-ID: References: <01000169fe5c5e14-63eba328-51f5-4ba3-ac17-311909f5bd86-000000@email.amazonses.com> In-Reply-To: <01000169fe5c5e14-63eba328-51f5-4ba3-ac17-311909f5bd86-000000@email.amazonses.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0FEVFJBTiIsImlkIjoiMjQ3ZTZlMzEtMzE2Mi00YmM2LWJiZDMtOWU0OWRlMzFiMzJlIiwicHJvcHMiOlt7Im4iOiJDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiR0IifV19LHsibiI6IlF1ZXN0aW9uMSIsInZhbHMiOltdfSx7Im4iOiJRdWVzdGlvbjIiLCJ2YWxzIjpbXX0seyJuIjoiUXVlc3Rpb24zIiwidmFscyI6W119XX0sIlN1YmplY3RMYWJlbHMiOltdLCJUTUNWZXJzaW9uIjoiMTcuMi4xMS4wIiwiVHJ1c3RlZExhYmVsSGFzaCI6ImhJaE5xR3oyOWQwaktBZkxzXC9LQVZaZkp2NkU3eENGeFQ2NHBjVkdPN3hmWVpMSXhQVEc1NnFQd2h0UnRydmJ1In0= x-originating-ip: [172.20.48.41] MIME-Version: 1.0 X-MC-Unique: kjh9CFiFMduIJCd_41VUkw-1 X-Mimecast-Spam-Score: 0 Content-Type: multipart/alternative; boundary="_000_BD6D193629F47C479266C0985F16AAC7011EA6891Aexmb1corpadtr_" Archived-At: Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 16:37:06 -0000 --_000_BD6D193629F47C479266C0985F16AAC7011EA6891Aexmb1corpadtr_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGkgS2VudCwNCg0KU29tZSBjb21tZW50cyBpbi1saW5l4oCmDQoNCk5pY2sNCg0KRnJvbTogS2Vu dCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0Pg0KU2VudDogMDggQXByaWwgMjAxOSAyMTox MQ0KVG86IE5JQ0sgSEFOQ09DSyA8bmljay5oYW5jb2NrQGFkdHJhbi5jb20+DQpDYzogTWFoZXNo IEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+OyBuZXRjb25mQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW25ldGNvbmZdIEFkb3B0aW9uIHBvbGwgZm9yIHRjcC1jbGllbnQtc2Vy dmVyIGFuZCBodHRwLWNsaWVudC1zZXJ2ZXIgZHJhZnQNCg0KSGkgTmljaywNCg0KWW91IHdpbGwg bm90aWNlIGluIHRoZSBsYXRlc3QgdGNwLWNsaWVudC1zZXJ2ZXIgdXBkYXRlIFsxXSB0aGF0IHRo ZXJlIGlzIG5vdyBhICJwcmVzZW5jZSIgc3RhdGVtZW50IG9uIHRoZSAia2VlcGFsaXZlcyIgY29u dGFpbmVycy4gIERvIHlvdSB0aGluayBhbnkgbW9yZSAibWFuZGF0b3J5IHRydWUiIHN0YXRlbWVu dHMgYXJlIG5lZWRlZD8NCltOaWNrXSBHaXZlbiB0aGF0IOKAmG1heC1wcm9iZXPigJkgYW5kIOKA mHByb2JlLWludGVydmFs4oCZIGFyZSBvcHRpb25hbCBpbiB0aGUgY3VycmVudCByZXZpc2lvbiwg YSBjbGllbnQgb3Igb3BlcmF0b3IgaGFzIHRoZSBvcHRpb24gbm90IHRvIGNvbmZpZ3VyZSB0aGVt LiBTaW5jZSB0aGV5IGFyZSBhbHNvIHdpdGhvdXQgZGVmYXVsdCB2YWx1ZXMsIHRoZSBhY3R1YWwg YmVoYXZpb3IgYWZ0ZXIgdGhlIOKAmGlkbGXigJN0aW1l4oCZIGV4cGlyZXMgd291bGQgYmUgZGVm aW5lZCBieSB0aGUgc3BlY2lmaWMgaW1wbGVtZW50YXRpb24gYW5kIG5vdCBieSB0aGUgb3BlcmF0 b3IuIE9uIHRoZSBvdGhlciBoYW5kLCBmb3IgdGhlIFlBTkcgbW9kZWwgdG8gc3BlY2lmeSBhcmJp dHJhcnkgZGVmYXVsdCB2YWx1ZXMgbWF5IG5vdCByZWFsbHkgYmUgaGVscGZ1bCB0byBhbiBvcGVy YXRvciBhcyBtZWFuaW5nZnVsIHZhbHVlcyB3b3VsZCBzdXJlbHkgZGVwZW5kIG9uIHRoZSBvcGVy YXRvcnMgc3BlY2lmaWMgcmVxdWlyZW1lbnRzLg0KQ29uc2VxdWVudGx5LCBJIGJlbGlldmUgdGhh dCBhbGwgMyBsZWFmcyB3aXRoaW4gdGhlIGNvbnRhaW5lciDigJhrZWVwYWxpdmVz4oCZIHNob3Vs ZCBiZSBtYW5kYXRvcnkuDQoNCkkgZG9uJ3QgdW5kZXJzdGFuZCB5b3VyIGxhc3QgY29tbWVudCBv ciwgcmF0aGVyLCBJIHRoaW5rIGl0IGlzIHRoZSBjYXNlIGFscmVhZHkgdGhhdCB0aGUgVENQIGtl ZXBhbGl2ZXMgY29uZmlndXJhdGlvbiBpcyBvdXRzaWRlIHRoZSBTU0gvVExTIGNvbmZpZ3VyYXRp b24uICBOb3RlIHRoZSAia2VlcGFsaXZlcyIgY29uZmlndXJhdGlvbiBpbnNpZGUgdGhlIFNTSC9U TFMgY29uZmlndXJhdGlvbiBpcyBhY3R1YWxseSB0byBzZXBhcmF0ZWx5IGNvbmZpZ3VyZSBrZWVw YWxpdmVzIGF0IHRoZSBTU0gvVExTIGxldmVscyAtIG1ha2VzIHNlbnNlPw0KW05pY2tdIE15IGlu aXRpYWwgZXhwZWN0YXRpb24gd2FzIHRoYXQgc2luY2UgdGhlIHNlY3VyaXR5IGxheWVyIHJ1bnMg b3ZlciB0aGUgVENQIGNvbm5lY3Rpb25zLCB0aGUgdGNwLWNsaWVudC1wYXJhbWV0ZXJzIHdvdWxk IGJlIGNvbmZpZ3VyZWQgaW5kZXBlbmRlbnRseSBvZiB0aGUgc2VjdXJpdHkgcHJvdG9jb2wsIGku ZS4sIHRvIGJlIGZvdW5kIGRpcmVjdGx5IHVuZGVyIOKAmGVuZHBvaW504oCZIGFuZCBub3QgdW5k ZXIgc3NoIG9yIHRscy4NCg0KWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1r d2F0c2VuLW5ldGNvbmYtdGNwLWNsaWVudC1zZXJ2ZXItMDE8aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWt3YXRzZW4tbmV0Y29uZi10Y3AtY2xpZW50LXNlcnZlci0wMT4NCg0KS2Vu dCAvLyBjb250cmlidXRvcg0KDQoNCg0KT24gTWFyIDI2LCAyMDE5LCBhdCAxMDozMCBBTSwgTklD SyBIQU5DT0NLIDxuaWNrLmhhbmNvY2tAYWR0cmFuLmNvbTxtYWlsdG86bmljay5oYW5jb2NrQGFk dHJhbi5jb20+PiB3cm90ZToNCg0KSSBzdXBwb3J0IHRoaXMgd29yayB0byBwcm92aWRlIHRoZSBh YmlsaXR5IHRvIGNvbmZpZ3VyZSBUQ1Aga2VlcGFsaXZlcyBmb3IgTkVUQ09ORiBjb25uZWN0aW9u cyBhcyB3ZSBuZWVkIHRoaXMgc3VwcG9ydCBpbiBvdXIgaW1wbGVtZW50YXRpb25zIGFuZCBzdXBw b3J0IHRoZSBhZG9wdGlvbiBvZiB0aGVzZSBkcmFmdHMuDQoNCkkgYWxzbyBoYXZlIHRoZSBmb2xs b3dpbmcgY29tbWVudHMgb24gdGhlIGFjdHVhbCBZQU5HIGltcGxlbWVudGF0aW9uIGFuZCB1c2Fn ZSB3aXRoaW4gdGhlIGNsaWVudC9zZXJ2ZXIgbW9kZWwuDQoNClRoZSBsZWFmcyB3aXRoaW4gdGhl IOKAnHRjcC1rZWVwYWxpdmVz4oCdIGNvbnRhaW5lciBhcmUgb3B0aW9uYWwuIEdpdmVuIHRoYXQg YSBzZXJ2ZXIgc3VwcG9ydHMgdGhlIGZlYXR1cmUg4oCcdGNwLWNsaWVudC1rZWVwYWxpdmVz4oCd LCBUQ1Aga2VlcGFsaXZlcyB3b3VsZCBiZSBkaXNhYmxlZCBwZXIgZGVmYXVsdCB0aHJvdWdoIG1p c3NpbmcgY29uZmlndXJhdGlvbiwgd2hpY2ggSSBiZWxpZXZlIGlzIGRlc2lyYWJsZSBiZWhhdmlv ci4gSG93ZXZlciwgdGhlcmUgaXMgY3VycmVudGx5IG5vdGhpbmcgdG8gcHJldmVudCBhIGNsaWVu dCBjb25maWd1cmluZywgc2F5LCBqdXN0IOKAmG1heC1wcm9iZXPigJkgb25seSByZXN1bHRpbmcg aW4gYW4gaW5jb21wbGV0ZSBidXQgdmFsaWQgY29uZmlndXJhdGlvbi4gV291bGQgbm90IGFkZGlu ZyBhIOKAmHByZXNlbmNl4oCZIHN0YXRlbWVudCB0byB0aGUgY29udGFpbmVyIOKAnHRjcC1rZWVw YWxpdmVz4oCdIGFuZCBtYWtpbmcgaXRzIGNoaWxkIG5vZGVzIG1hbmRhdG9yeSBvciBhZGRpbmcg ZGVmYXVsdCB2YWx1ZXMgYmUgYSBtb3JlIHByYWN0aWNhbCBzb2x1dGlvbiB0aGF0IGRlZmluZXMg YSBwcmVkaWN0YWJsZSBiZWhhdmlvcj8NCg0KU2luY2UgVENQIGlzIGEgbGF5ZXIgYmVsb3cgdGhl IHNlY3VyaXR5IGxheWVyIGFuZCBpbmRlcGVuZGVudCBvZiB0aGUgY2hvaWNlIG9mIHNlY3VyaXR5 IHByb3RvY29sLCBJIHdhcyB3b25kZXJpbmcgd2hhdCB0aGUgbW90aXZhdGlvbiB3YXMgZm9yIGxv Y2F0aW5nIHRoZSBUQ1Aga2VlcGFsaXZlcyBjb25maWd1cmF0aW9uIHdpdGhpbiB0aGUgU1NIL1RM UyBjb25maWd1cmF0aW9uLiBXb3VsZG7igJl0IHRoaXMgYmUgYmV0dGVyIGxvY2F0ZWQgYXMgYSBz aWJsaW5nIG5vZCB0byB0aGUgY2hvaWNlIOKAnHRyYW5zcG9ydOKAnT8NCg0KTmljaw0KDQpGcm9t OiBuZXRjb25mIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmYtYm91bmNl c0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBNYWhlc2ggSmV0aGFuYW5kYW5pDQpTZW50OiAyNiBN YXJjaCAyMDE5IDEyOjE3DQpUbzogTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0 Y29uZkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbbmV0Y29uZl0gQWRvcHRpb24gcG9sbCBmb3IgdGNw LWNsaWVudC1zZXJ2ZXIgYW5kIGh0dHAtY2xpZW50LXNlcnZlciBkcmFmdA0KDQpUaGlzIGlzIHRo ZSBzdGFydCBvZiBhIHR3byB3ZWVrIHBvbGwgZm9yIFdHIGFkb3B0aW9uIG9mIHRoZSB0d28gZHJh ZnRzOg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQta3dhdHNlbi1uZXRjb25m LXRjcC1jbGllbnQtc2VydmVyLTAwPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1r d2F0c2VuLW5ldGNvbmYtdGNwLWNsaWVudC1zZXJ2ZXItMDA+DQpodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQta3dhdHNlbi1uZXRjb25mLWh0dHAtY2xpZW50LXNlcnZlci0wMDxodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQta3dhdHNlbi1uZXRjb25mLWh0dHAtY2xpZW50 LXNlcnZlci0wMD4NCg0KUGxlYXNlIGluZGljYXRlIHlvdXIgc3VwcG9ydCBmb3Igb3IgYW55IG9i amVjdGlvbnMgeW91IG1pZ2h0IGhhdmUgZm9yIGFkb3B0aW5nIHRoZSB0d28gZHJhZnRzIGFzIFdH IGl0ZW1zIGJ5IEFwcmlsIDkuDQoNCk1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlA Z21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRjb25mIG1haWxpbmcg bGlzdA0KbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjxodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KbmV0Y29uZiBtYWlsaW5nIGxpc3QNCm5ldGNvbmZAaWV0Zi5v cmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldGNvbmY8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRjb25mPg0KDQo= --_000_BD6D193629F47C479266C0985F16AAC7011EA6891Aexmb1corpadtr_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2EtTGlnaHQ7DQoJcGFub3Nl LTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29u dmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCAyLjBjbSA3MC44NXB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5IaSBLZW50LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U29t ZSBjb21tZW50cyBpbi1saW5l4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5OaWNrPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX19fX19yZXBseXNlcGFyYXRvciI+ PC9hPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IEtlbnQgV2F0c2VuICZsdDtrZW50K2lldGZAd2F0c2VuLm5ldCZndDsNCjxicj4NCjxiPlNlbnQ6 PC9iPiAwOCBBcHJpbCAyMDE5IDIxOjExPGJyPg0KPGI+VG86PC9iPiBOSUNLIEhBTkNPQ0sgJmx0 O25pY2suaGFuY29ja0BhZHRyYW4uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTWFoZXNoIEpldGhh bmFuZGFuaSAmbHQ7bWpldGhhbmFuZGFuaUBnbWFpbC5jb20mZ3Q7OyBuZXRjb25mQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0Y29uZl0gQWRvcHRpb24gcG9sbCBmb3IgdGNw LWNsaWVudC1zZXJ2ZXIgYW5kIGh0dHAtY2xpZW50LXNlcnZlciBkcmFmdDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIE5pY2ssPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3Ugd2lsbCBub3RpY2UgaW4gdGhlIGxh dGVzdCZuYnNwO3RjcC1jbGllbnQtc2VydmVyIHVwZGF0ZSBbMV0gdGhhdCB0aGVyZSBpcyBub3cg YSAmcXVvdDtwcmVzZW5jZSZxdW90OyBzdGF0ZW1lbnQgb24gdGhlICZxdW90O2tlZXBhbGl2ZXMm cXVvdDsgY29udGFpbmVycy4gJm5ic3A7RG8geW91IHRoaW5rIGFueSBtb3JlICZxdW90O21hbmRh dG9yeSB0cnVlJnF1b3Q7IHN0YXRlbWVudHMgYXJlIG5lZWRlZD88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5b Tmlja10gR2l2ZW4gdGhhdCDigJhtYXgtcHJvYmVz4oCZIGFuZCDigJhwcm9iZS1pbnRlcnZhbOKA mSBhcmUgb3B0aW9uYWwgaW4gdGhlIGN1cnJlbnQgcmV2aXNpb24sIGEgY2xpZW50IG9yIG9wZXJh dG9yIGhhcyB0aGUgb3B0aW9uIG5vdCB0byBjb25maWd1cmUgdGhlbS4gU2luY2UNCiB0aGV5IGFy ZSBhbHNvIHdpdGhvdXQgZGVmYXVsdCB2YWx1ZXMsIHRoZSBhY3R1YWwgYmVoYXZpb3IgYWZ0ZXIg dGhlIOKAmGlkbGXigJN0aW1l4oCZIGV4cGlyZXMgd291bGQgYmUgZGVmaW5lZCBieSB0aGUgc3Bl Y2lmaWMgaW1wbGVtZW50YXRpb24gYW5kIG5vdCBieSB0aGUgb3BlcmF0b3IuIE9uIHRoZSBvdGhl ciBoYW5kLCBmb3IgdGhlIFlBTkcgbW9kZWwgdG8gc3BlY2lmeSBhcmJpdHJhcnkgZGVmYXVsdCB2 YWx1ZXMgbWF5IG5vdCByZWFsbHkgYmUgaGVscGZ1bA0KIHRvIGFuIG9wZXJhdG9yIGFzIG1lYW5p bmdmdWwgdmFsdWVzIHdvdWxkIHN1cmVseSBkZXBlbmQgb24gdGhlIG9wZXJhdG9ycyBzcGVjaWZp YyByZXF1aXJlbWVudHMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Db25zZXF1 ZW50bHksIEkgYmVsaWV2ZSB0aGF0IGFsbCAzIGxlYWZzIHdpdGhpbiB0aGUgY29udGFpbmVyIOKA mGtlZXBhbGl2ZXPigJkgc2hvdWxkIGJlIG1hbmRhdG9yeS48L3NwYW4+PC9pPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbid0IHVuZGVyc3RhbmQgeW91ciBsYXN0 IGNvbW1lbnQgb3IsIHJhdGhlciwgSSB0aGluayBpdCBpcyB0aGUgY2FzZSBhbHJlYWR5IHRoYXQg dGhlJm5ic3A7VENQIGtlZXBhbGl2ZXMgY29uZmlndXJhdGlvbiBpcyBvdXRzaWRlIHRoZSBTU0gv VExTIGNvbmZpZ3VyYXRpb24uICZuYnNwO05vdGUgdGhlICZxdW90O2tlZXBhbGl2ZXMmcXVvdDsg Y29uZmlndXJhdGlvbiBpbnNpZGUgdGhlJm5ic3A7U1NIL1RMUyBjb25maWd1cmF0aW9uIGlzIGFj dHVhbGx5DQogdG8gc2VwYXJhdGVseSBjb25maWd1cmUga2VlcGFsaXZlcyBhdCB0aGUgU1NIL1RM UyBsZXZlbHMgLSBtYWtlcyBzZW5zZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bTmlja10gTXkgaW5pdGlh bCBleHBlY3RhdGlvbiB3YXMgdGhhdCBzaW5jZSB0aGUgc2VjdXJpdHkgbGF5ZXIgcnVucyBvdmVy IHRoZSBUQ1AgY29ubmVjdGlvbnMsIHRoZSB0Y3AtY2xpZW50LXBhcmFtZXRlcnMgd291bGQgYmUg Y29uZmlndXJlZCBpbmRlcGVuZGVudGx5DQogb2YgdGhlIHNlY3VyaXR5IHByb3RvY29sLCBpLmUu LCB0byBiZSBmb3VuZCBkaXJlY3RseSB1bmRlciDigJhlbmRwb2ludOKAmSBhbmQgbm90IHVuZGVy IHNzaCBvciB0bHMuICZuYnNwOzwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlsxXSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1rd2F0c2VuLW5ldGNvbmYtdGNwLWNsaWVudC1zZXJ2ZXItMDEiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rd2F0c2VuLW5ldGNvbmYtdGNwLWNsaWVudC1zZXJ2ZXIt MDE8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPktlbnQgLy8gY29udHJpYnV0b3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gTWFyIDI2LCAyMDE5LCBhdCAxMDozMCBBTSwgTklDSyBIQU5DT0NL ICZsdDs8YSBocmVmPSJtYWlsdG86bmljay5oYW5jb2NrQGFkdHJhbi5jb20iPm5pY2suaGFuY29j a0BhZHRyYW4uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBzdXBwb3J0 IHRoaXMgd29yayB0byBwcm92aWRlIHRoZSBhYmlsaXR5IHRvIGNvbmZpZ3VyZSBUQ1Aga2VlcGFs aXZlcyBmb3IgTkVUQ09ORiBjb25uZWN0aW9ucyBhcyB3ZSBuZWVkIHRoaXMgc3VwcG9ydCBpbiBv dXIgaW1wbGVtZW50YXRpb25zIGFuZCBzdXBwb3J0IHRoZQ0KIGFkb3B0aW9uIG9mIHRoZXNlIGRy YWZ0cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYWxzbyBoYXZlIHRoZSBmb2xsb3dpbmcgY29tbWVudHMg b24gdGhlIGFjdHVhbCBZQU5HIGltcGxlbWVudGF0aW9uIGFuZCB1c2FnZSB3aXRoaW4gdGhlIGNs aWVudC9zZXJ2ZXIgbW9kZWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgbGVhZnMgd2l0aGluIHRoZSDi gJx0Y3Ata2VlcGFsaXZlc+KAnSBjb250YWluZXIgYXJlIG9wdGlvbmFsLiBHaXZlbiB0aGF0IGEg c2VydmVyIHN1cHBvcnRzIHRoZSBmZWF0dXJlIOKAnHRjcC1jbGllbnQta2VlcGFsaXZlc+KAnSwg VENQIGtlZXBhbGl2ZXMgd291bGQgYmUgZGlzYWJsZWQNCiBwZXIgZGVmYXVsdCB0aHJvdWdoIG1p c3NpbmcgY29uZmlndXJhdGlvbiwgd2hpY2ggSSBiZWxpZXZlIGlzIGRlc2lyYWJsZSBiZWhhdmlv ci4gSG93ZXZlciwgdGhlcmUgaXMgY3VycmVudGx5IG5vdGhpbmcgdG8gcHJldmVudCBhIGNsaWVu dCBjb25maWd1cmluZywgc2F5LCBqdXN0IOKAmG1heC1wcm9iZXPigJkgb25seSByZXN1bHRpbmcg aW4gYW4gaW5jb21wbGV0ZSBidXQgdmFsaWQgY29uZmlndXJhdGlvbi4gV291bGQgbm90IGFkZGlu ZyBhIOKAmHByZXNlbmNl4oCZDQogc3RhdGVtZW50IHRvIHRoZSBjb250YWluZXIg4oCcdGNwLWtl ZXBhbGl2ZXPigJ0gYW5kIG1ha2luZyBpdHMgY2hpbGQgbm9kZXMgbWFuZGF0b3J5IG9yIGFkZGlu ZyBkZWZhdWx0IHZhbHVlcyBiZSBhIG1vcmUgcHJhY3RpY2FsIHNvbHV0aW9uIHRoYXQgZGVmaW5l cyBhIHByZWRpY3RhYmxlIGJlaGF2aW9yPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U2luY2UgVENQIGlzIGEg bGF5ZXIgYmVsb3cgdGhlIHNlY3VyaXR5IGxheWVyIGFuZCBpbmRlcGVuZGVudCBvZiB0aGUgY2hv aWNlIG9mIHNlY3VyaXR5IHByb3RvY29sLCBJIHdhcyB3b25kZXJpbmcgd2hhdCB0aGUgbW90aXZh dGlvbiB3YXMgZm9yIGxvY2F0aW5nIHRoZSBUQ1ANCiBrZWVwYWxpdmVzIGNvbmZpZ3VyYXRpb24g d2l0aGluIHRoZSBTU0gvVExTIGNvbmZpZ3VyYXRpb24uIFdvdWxkbuKAmXQgdGhpcyBiZSBiZXR0 ZXIgbG9jYXRlZCBhcyBhIHNpYmxpbmcgbm9kIHRvIHRoZSBjaG9pY2Ug4oCcdHJhbnNwb3J04oCd Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Tmljazwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPm5ldGNvbmYNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldGNv bmYtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bmV0Y29uZi1i b3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+TWFoZXNoIEpldGhhbmFuZGFuaTxicj4N CjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj4yNiBNYXJjaCAyMDE5IDEyOjE3PGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5OZXRjb25mICZsdDs8YSBocmVmPSJtYWls dG86bmV0Y29uZkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bmV0Y29uZkBp ZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5bbmV0Y29uZl0gQWRvcHRpb24gcG9s bCBmb3IgdGNwLWNsaWVudC1zZXJ2ZXIgYW5kIGh0dHAtY2xpZW50LXNlcnZlciBkcmFmdDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgdGhlIHN0YXJ0IG9mIGEgdHdvIHdlZWsgcG9sbCBmb3Ig V0cgYWRvcHRpb24gb2YgdGhlIHR3byBkcmFmdHM6PGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWt3YXRzZW4tbmV0Y29uZi10Y3AtY2xpZW50LXNl cnZlci0wMCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWt3YXRzZW4tbmV0Y29uZi10Y3AtY2xpZW50LXNlcnZlci0wMDwvc3Bhbj48 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWt3YXRz ZW4tbmV0Y29uZi1odHRwLWNsaWVudC1zZXJ2ZXItMDAiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rd2F0c2VuLW5ldGNvbmYtaHR0 cC1jbGllbnQtc2VydmVyLTAwPC9zcGFuPjwvYT48YnI+DQo8YnI+DQpQbGVhc2UgaW5kaWNhdGUg eW91ciBzdXBwb3J0IGZvciBvciBhbnkgb2JqZWN0aW9ucyB5b3UgbWlnaHQgaGF2ZSBmb3IgYWRv cHRpbmcgdGhlIHR3byBkcmFmdHMgYXMgV0cgaXRlbXMgYnkgQXByaWwgOS48YnI+DQo8YnI+DQpN YWhlc2ggSmV0aGFuYW5kYW5pPGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21h aWwuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNv bTwvc3Bhbj48L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpuZXRjb25mIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5uZXRjb25mQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvc3Bh bj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhLUxpZ2h0JnF1b3Q7LHNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCm5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhy ZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EtTGlnaHQmcXVvdDssc2VyaWY7Y29sb3I6cHVy cGxlIj5uZXRjb25mQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EtTGlnaHQmcXVvdDssc2VyaWYiPjxicj4N Cjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dGNvbmYiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYS1MaWdodCZxdW90OyxzZXJpZjtjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_BD6D193629F47C479266C0985F16AAC7011EA6891Aexmb1corpadtr_-- From nobody Wed Apr 10 10:35:18 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC611203B0 for ; Wed, 10 Apr 2019 10:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P00Y8KCIBKTV for ; Wed, 10 Apr 2019 10:35:13 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 725FA1200EB for ; Wed, 10 Apr 2019 10:35:13 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 1FDBD6CB for ; Wed, 10 Apr 2019 19:35:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id vt83PGOhGZ9v for ; Wed, 10 Apr 2019 19:35:12 +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 atlas5.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 10 Apr 2019 19:35:12 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 09F6C200C5 for ; Wed, 10 Apr 2019 19:35:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id fiZAxqm33ltA for ; Wed, 10 Apr 2019 19:35:11 +0200 (CEST) Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 94B2F200C2 for ; Wed, 10 Apr 2019 19:35:11 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Wed, 10 Apr 2019 19:20:08 +0200 Received: by anna.localdomain (Postfix, from userid 501) id A69A130080C277; Wed, 10 Apr 2019 19:20:08 +0200 (CEST) Date: Wed, 10 Apr 2019 19:20:08 +0200 From: Juergen Schoenwaelder To: NICK HANCOCK CC: Kent Watsen , "netconf@ietf.org" Message-ID: <20190410172008.osgrdgvkvpd35q7c@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: NICK HANCOCK , Kent Watsen , "netconf@ietf.org" References: <01000169fe5c5e14-63eba328-51f5-4ba3-ac17-311909f5bd86-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 17:35:17 -0000 Sorry, this is impossible to read without an HTML rendering engine. /js On Wed, Apr 10, 2019 at 04:36:52PM +0000, NICK HANCOCK wrote: > Hi Kent, >=20 > Some comments in-line=E2=80=A6 >=20 > Nick >=20 > From: Kent Watsen > Sent: 08 April 2019 21:11 > To: NICK HANCOCK > Cc: Mahesh Jethanandani ; netconf@ietf.org > Subject: Re: [netconf] Adoption poll for tcp-client-server and http-cli= ent-server draft >=20 > Hi Nick, >=20 > You will notice in the latest tcp-client-server update [1] that there i= s now a "presence" statement on the "keepalives" containers. Do you thin= k any more "mandatory true" statements are needed? > [Nick] Given that =E2=80=98max-probes=E2=80=99 and =E2=80=98probe-inter= val=E2=80=99 are optional in the current revision, a client or operator h= as the option not to configure them. Since they are also without default = values, the actual behavior after the =E2=80=98idle=E2=80=93time=E2=80=99= expires would be defined by the specific implementation and not by the o= perator. On the other hand, for the YANG model to specify arbitrary defau= lt values may not really be helpful to an operator as meaningful values w= ould surely depend on the operators specific requirements. > Consequently, I believe that all 3 leafs within the container =E2=80=98= keepalives=E2=80=99 should be mandatory. >=20 > I don't understand your last comment or, rather, I think it is the case= already that the TCP keepalives configuration is outside the SSH/TLS con= figuration. Note the "keepalives" configuration inside the SSH/TLS confi= guration is actually to separately configure keepalives at the SSH/TLS le= vels - makes sense? > [Nick] My initial expectation was that since the security layer runs ov= er the TCP connections, the tcp-client-parameters would be configured ind= ependently of the security protocol, i.e., to be found directly under =E2= =80=98endpoint=E2=80=99 and not under ssh or tls. >=20 > [1] https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server= -01 >=20 > Kent // contributor >=20 >=20 >=20 > On Mar 26, 2019, at 10:30 AM, NICK HANCOCK > wrote: >=20 > I support this work to provide the ability to configure TCP keepalives = for NETCONF connections as we need this support in our implementations an= d support the adoption of these drafts. >=20 > I also have the following comments on the actual YANG implementation an= d usage within the client/server model. >=20 > The leafs within the =E2=80=9Ctcp-keepalives=E2=80=9D container are opt= ional. Given that a server supports the feature =E2=80=9Ctcp-client-keepa= lives=E2=80=9D, TCP keepalives would be disabled per default through miss= ing configuration, which I believe is desirable behavior. However, there = is currently nothing to prevent a client configuring, say, just =E2=80=98= max-probes=E2=80=99 only resulting in an incomplete but valid configurati= on. Would not adding a =E2=80=98presence=E2=80=99 statement to the contai= ner =E2=80=9Ctcp-keepalives=E2=80=9D and making its child nodes mandatory= or adding default values be a more practical solution that defines a pre= dictable behavior? >=20 > Since TCP is a layer below the security layer and independent of the ch= oice of security protocol, I was wondering what the motivation was for lo= cating the TCP keepalives configuration within the SSH/TLS configuration.= Wouldn=E2=80=99t this be better located as a sibling nod to the choice =E2= =80=9Ctransport=E2=80=9D? >=20 > Nick >=20 > From: netconf > On Behalf Of Mahesh Jethanandani > Sent: 26 March 2019 12:17 > To: Netconf > > Subject: [netconf] Adoption poll for tcp-client-server and http-client-= server draft >=20 > This is the start of a two week poll for WG adoption of the two drafts: >=20 > https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00<= https://tools.ietf.org/html/draft-kwatsen-netconf-tcp-client-server-00> > https://tools.ietf.org/html/draft-kwatsen-netconf-http-client-server-00= >=20 > Please indicate your support for or any objections you might have for a= dopting the two drafts as WG items by April 9. >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > 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 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 Apr 10 11:29:47 2019 Return-Path: <0100016a08834944-944143b3-7387-460c-a30e-167524705d55-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E5C120129 for ; Wed, 10 Apr 2019 11:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKvJOQBLdDnu for ; Wed, 10 Apr 2019 11:29:44 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77FC812006D for ; Wed, 10 Apr 2019 11:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1554920983; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=xc9eHRPpLWO8suL9D9qpbx/YIEDYRYyh7/6OO14ui/A=; b=DgTXXvDBcOXpryyFejdF9T1r4S2038BuGlts+30Ms10JKX+3kYFwDcpmm4UChHV6 1Vua7FsI/8NoYYP2jQFosls2G9xILYAsy9RoSNBF3DFPzQv5Y8BjMRyXq4DdtCOeNwx cJ9VsL7LteeO6oYTMuDts0qOO/8kj7+sUhDaNDi4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Kent Watsen In-Reply-To: Date: Wed, 10 Apr 2019 18:29:43 +0000 Cc: Mahesh Jethanandani , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <0100016a08834944-944143b3-7387-460c-a30e-167524705d55-000000@email.amazonses.com> References: <01000169fe5c5e14-63eba328-51f5-4ba3-ac17-311909f5bd86-000000@email.amazonses.com> To: NICK HANCOCK X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.10-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 18:29:46 -0000 [Even though I do have an HTML-rendering SMTP client, I also found this = message difficult to read, mostly due to the inline-level not changing. = It took me awhile to realize that I have to search for "[Nick]". I've = converted this message to plain-text...] > You will notice in the latest tcp-client-server update [1] that there = is now a "presence" statement on the "keepalives" containers. Do you = think any more "mandatory true" statements are needed? >=20 > [Nick] Given that =E2=80=98max-probes=E2=80=99 and = =E2=80=98probe-interval=E2=80=99 are optional in the current revision, a = client or operator has the option not to configure them. Since they are = also without default values, the actual behavior after the = =E2=80=98idle=E2=80=93time=E2=80=99 expires would be defined by the = specific implementation and not by the operator. On the other hand, for = the YANG model to specify arbitrary default values may not really be = helpful to an operator as meaningful values would surely depend on the = operators specific requirements. >=20 > Consequently, I believe that all 3 leafs within the container = =E2=80=98keepalives=E2=80=99 should be mandatory. Fair enough. > I don't understand your last comment or, rather, I think it is the = case already that the TCP keepalives configuration is outside the = SSH/TLS configuration. Note the "keepalives" configuration inside the = SSH/TLS configuration is actually to separately configure keepalives at = the SSH/TLS levels - makes sense? >=20 > [Nick] My initial expectation was that since the security layer runs = over the TCP connections, the tcp-client-parameters would be configured = independently of the security protocol, i.e., to be found directly under = =E2=80=98endpoint=E2=80=99 and not under ssh or tls. =20 Still, I think that this is the case already. Can you please provide a = concrete example illustrating the concern? Thanks, Kent // contributor From nobody Wed Apr 10 13:40:56 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADD01205F6; Wed, 10 Apr 2019 13:40:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stewart Bryant via Datatracker To: Cc: draft-ietf-netconf-yang-push.all@ietf.org, ietf@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Stewart Bryant Message-ID: <155492884208.22557.5359832641233656648@ietfa.amsl.com> Date: Wed, 10 Apr 2019 13:40:42 -0700 Archived-At: Subject: [netconf] Genart last call review of draft-ietf-netconf-yang-push-22 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 20:40:42 -0000 Reviewer: Stewart Bryant Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-netconf-yang-push-22 Reviewer: Stewart Bryant Review Date: 2019-04-10 IETF LC End Date: 2019-04-12 IESG Telechat date: Not scheduled for a telechat Summary: A well written document with just a small nuber of minor matter in the nits section that need to be considered. Major issues: None Minor issues: None Nits/editorial comments: ** Obsolete normative reference: RFC 7895 (Obsoleted by RFC 8525) ============ SB> I assume that the ADs are happy with seven front page authors. =========== Abstract Via the mechanism described in this document, subscriber applications SB> I am not sure if starting a sentence with "via" is good English SB> but I have not seen it done before. =========== Traditional approaches to providing visibility into managed entities from remote have been built on polling. SB> from remote what? =========== 3.10. On-Change Notifiable Datastore Nodes In some cases, a publisher supporting on-change notifications may not be able to push on-change updates for some object types. Reasons for this might be that the value of the datastore node changes frequently (e.g., [RFC8343]'s in-octets counter), that small object changes are frequent and meaningless (e.g., a temperature gauge changing 0.1 degrees), or that the implementation is not capable of on-change notification for a particular object. SB> I could not see the parameter range specifiy what is regarded as trivial SB> specified in the model. It seems that it perhaps ought to be. =================== The next figure depicts augmentations of module ietf-yang-push to the notifications that are specified in module ietf-subscribed- notifications. The augmentations allow to include subscription SB> s/allow to include/allow the inclusion of/ =============== From nobody Wed Apr 10 13:41:18 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C5C1205E5; Wed, 10 Apr 2019 13:40:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stewart Bryant via Datatracker To: Cc: draft-ietf-netconf-yang-push.all@ietf.org, ietf@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Stewart Bryant Message-ID: <155492884207.22609.13843454346388048546@ietfa.amsl.com> Date: Wed, 10 Apr 2019 13:40:42 -0700 Archived-At: Subject: [netconf] Genart last call review of draft-ietf-netconf-yang-push-22 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 20:40:43 -0000 Reviewer: Stewart Bryant Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-netconf-yang-push-22 Reviewer: Stewart Bryant Review Date: 2019-04-10 IETF LC End Date: 2019-04-12 IESG Telechat date: Not scheduled for a telechat Summary: A well written document with just a small nuber of minor matter in the nits section that need to be considered. Major issues: None Minor issues: None Nits/editorial comments: ** Obsolete normative reference: RFC 7895 (Obsoleted by RFC 8525) ============ SB> I assume that the ADs are happy with seven front page authors. =========== Abstract Via the mechanism described in this document, subscriber applications SB> I am not sure if starting a sentence with "via" is good English SB> but I have not seen it done before. =========== Traditional approaches to providing visibility into managed entities from remote have been built on polling. SB> from remote what? =========== 3.10. On-Change Notifiable Datastore Nodes In some cases, a publisher supporting on-change notifications may not be able to push on-change updates for some object types. Reasons for this might be that the value of the datastore node changes frequently (e.g., [RFC8343]'s in-octets counter), that small object changes are frequent and meaningless (e.g., a temperature gauge changing 0.1 degrees), or that the implementation is not capable of on-change notification for a particular object. SB> I could not see the parameter range specifiy what is regarded as trivial SB> specified in the model. It seems that it perhaps ought to be. =================== The next figure depicts augmentations of module ietf-yang-push to the notifications that are specified in module ietf-subscribed- notifications. The augmentations allow to include subscription SB> s/allow to include/allow the inclusion of/ =============== From nobody Thu Apr 11 01:26:24 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B0412011D for ; Thu, 11 Apr 2019 01:26: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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJTrqH89MZ2Z for ; Thu, 11 Apr 2019 01:26:21 -0700 (PDT) Received: from us-smtp-delivery-128.mimecast.com (us-smtp-delivery-128.mimecast.com [216.205.24.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05FFD12017D for ; Thu, 11 Apr 2019 01:26:20 -0700 (PDT) Received: from ex-hc3.corp.adtran.com (ex-hc2.adtran.com [76.164.174.82]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-335-QONegf9EMreI1k0u1Ge4vQ-1; Thu, 11 Apr 2019 04:26:12 -0400 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc3.corp.adtran.com ([fe80::3892:20fa:600f:75c6%15]) with mapi id 14.03.0382.000; Thu, 11 Apr 2019 03:26:11 -0500 From: NICK HANCOCK To: Kent Watsen CC: Mahesh Jethanandani , "netconf@ietf.org" Thread-Topic: [netconf] Adoption poll for tcp-client-server and http-client-server draft Thread-Index: AQHU48WK88pkUu3tWEqeuFS0y837C6Yd+NxQgBURBQCAAjWfgIAA44GAgACFiOA= Date: Thu, 11 Apr 2019 08:26:10 +0000 Message-ID: References: <01000169fe5c5e14-63eba328-51f5-4ba3-ac17-311909f5bd86-000000@email.amazonses.com> <0100016a08834944-944143b3-7387-460c-a30e-167524705d55-000000@email.amazonses.com> In-Reply-To: <0100016a08834944-944143b3-7387-460c-a30e-167524705d55-000000@email.amazonses.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0FEVFJBTiIsImlkIjoiM2ZhNWJkMTktYmQzNy00YjhhLWI1MjYtOTg2NGE5YmUzMWY2IiwicHJvcHMiOlt7Im4iOiJDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiR0IifV19LHsibiI6IlF1ZXN0aW9uMSIsInZhbHMiOltdfSx7Im4iOiJRdWVzdGlvbjIiLCJ2YWxzIjpbXX0seyJuIjoiUXVlc3Rpb24zIiwidmFscyI6W119XX0sIlN1YmplY3RMYWJlbHMiOltdLCJUTUNWZXJzaW9uIjoiMTcuMi4xMS4wIiwiVHJ1c3RlZExhYmVsSGFzaCI6Ilp0dzZvblhyRjhiaThXdjllR0pFRytTQTFCWEd3eEVnWVEzSGVEdzB4aVUwRnZpUUdta0trNTZVVk5rTW81SDIifQ== x-originating-ip: [172.20.62.167] MIME-Version: 1.0 X-MC-Unique: QONegf9EMreI1k0u1Ge4vQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] Adoption poll for tcp-client-server and http-client-server draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 08:26:24 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogS2VudCBXYXRzZW4gPGtl bnQraWV0ZkB3YXRzZW4ubmV0Pg0KPiBTZW50OiAxMCBBcHJpbCAyMDE5IDIwOjMwDQo+IFRvOiBO SUNLIEhBTkNPQ0sgPG5pY2suaGFuY29ja0BhZHRyYW4uY29tPg0KPiBDYzogTWFoZXNoIEpldGhh bmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+OyBuZXRjb25mQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJlOiBbbmV0Y29uZl0gQWRvcHRpb24gcG9sbCBmb3IgdGNwLWNsaWVudC1zZXJ2ZXIg YW5kIGh0dHAtY2xpZW50LQ0KPiBzZXJ2ZXIgZHJhZnQNCj4gDQo+IFtFdmVuIHRob3VnaCBJIGRv IGhhdmUgYW4gSFRNTC1yZW5kZXJpbmcgU01UUCBjbGllbnQsIEkgYWxzbyBmb3VuZCB0aGlzDQo+ IG1lc3NhZ2UgZGlmZmljdWx0IHRvIHJlYWQsIG1vc3RseSBkdWUgdG8gdGhlIGlubGluZS1sZXZl bCBub3QgY2hhbmdpbmcuICBJdCB0b29rDQo+IG1lIGF3aGlsZSB0byByZWFsaXplIHRoYXQgSSBo YXZlIHRvIHNlYXJjaCBmb3IgIltOaWNrXSIuICBJJ3ZlIGNvbnZlcnRlZCB0aGlzDQo+IG1lc3Nh Z2UgdG8gcGxhaW4tdGV4dC4uLl0NCg0KVGhhbmtzIGZvciB0aGUgZmVlZGJhY2ssIEknbGwgYXZv aWQgSFRNTCBpbiB0aGUgZnV0dXJlLg0KDQo+IA0KPiANCj4gDQo+ID4gWW91IHdpbGwgbm90aWNl IGluIHRoZSBsYXRlc3QgdGNwLWNsaWVudC1zZXJ2ZXIgdXBkYXRlIFsxXSB0aGF0IHRoZXJlIGlz IG5vdyBhDQo+ICJwcmVzZW5jZSIgc3RhdGVtZW50IG9uIHRoZSAia2VlcGFsaXZlcyIgY29udGFp bmVycy4gIERvIHlvdSB0aGluayBhbnkNCj4gbW9yZSAibWFuZGF0b3J5IHRydWUiIHN0YXRlbWVu dHMgYXJlIG5lZWRlZD8NCj4gPg0KPiA+IFtOaWNrXSBHaXZlbiB0aGF0IOKAmG1heC1wcm9iZXPi gJkgYW5kIOKAmHByb2JlLWludGVydmFs4oCZIGFyZSBvcHRpb25hbCBpbiB0aGUNCj4gY3VycmVu dCByZXZpc2lvbiwgYSBjbGllbnQgb3Igb3BlcmF0b3IgaGFzIHRoZSBvcHRpb24gbm90IHRvIGNv bmZpZ3VyZSB0aGVtLg0KPiBTaW5jZSB0aGV5IGFyZSBhbHNvIHdpdGhvdXQgZGVmYXVsdCB2YWx1 ZXMsIHRoZSBhY3R1YWwgYmVoYXZpb3IgYWZ0ZXIgdGhlDQo+IOKAmGlkbGXigJN0aW1l4oCZIGV4 cGlyZXMgd291bGQgYmUgZGVmaW5lZCBieSB0aGUgc3BlY2lmaWMgaW1wbGVtZW50YXRpb24gYW5k IG5vdA0KPiBieSB0aGUgb3BlcmF0b3IuIE9uIHRoZSBvdGhlciBoYW5kLCBmb3IgdGhlIFlBTkcg bW9kZWwgdG8gc3BlY2lmeSBhcmJpdHJhcnkNCj4gZGVmYXVsdCB2YWx1ZXMgbWF5IG5vdCByZWFs bHkgYmUgaGVscGZ1bCB0byBhbiBvcGVyYXRvciBhcyBtZWFuaW5nZnVsIHZhbHVlcw0KPiB3b3Vs ZCBzdXJlbHkgZGVwZW5kIG9uIHRoZSBvcGVyYXRvcnMgc3BlY2lmaWMgcmVxdWlyZW1lbnRzLg0K PiA+DQo+ID4gQ29uc2VxdWVudGx5LCBJIGJlbGlldmUgdGhhdCBhbGwgMyBsZWFmcyB3aXRoaW4g dGhlIGNvbnRhaW5lciDigJhrZWVwYWxpdmVz4oCZDQo+IHNob3VsZCBiZSBtYW5kYXRvcnkuDQo+ IA0KPiBGYWlyIGVub3VnaC4NCj4gDQo+IA0KPiA+IEkgZG9uJ3QgdW5kZXJzdGFuZCB5b3VyIGxh c3QgY29tbWVudCBvciwgcmF0aGVyLCBJIHRoaW5rIGl0IGlzIHRoZSBjYXNlDQo+IGFscmVhZHkg dGhhdCB0aGUgVENQIGtlZXBhbGl2ZXMgY29uZmlndXJhdGlvbiBpcyBvdXRzaWRlIHRoZSBTU0gv VExTDQo+IGNvbmZpZ3VyYXRpb24uICBOb3RlIHRoZSAia2VlcGFsaXZlcyIgY29uZmlndXJhdGlv biBpbnNpZGUgdGhlIFNTSC9UTFMNCj4gY29uZmlndXJhdGlvbiBpcyBhY3R1YWxseSB0byBzZXBh cmF0ZWx5IGNvbmZpZ3VyZSBrZWVwYWxpdmVzIGF0IHRoZSBTU0gvVExTDQo+IGxldmVscyAtIG1h a2VzIHNlbnNlPw0KPiA+DQo+ID4gW05pY2tdIE15IGluaXRpYWwgZXhwZWN0YXRpb24gd2FzIHRo YXQgc2luY2UgdGhlIHNlY3VyaXR5IGxheWVyIHJ1bnMgb3ZlciB0aGUNCj4gVENQIGNvbm5lY3Rp b25zLCB0aGUgdGNwLWNsaWVudC1wYXJhbWV0ZXJzIHdvdWxkIGJlIGNvbmZpZ3VyZWQNCj4gaW5k ZXBlbmRlbnRseSBvZiB0aGUgc2VjdXJpdHkgcHJvdG9jb2wsIGkuZS4sIHRvIGJlIGZvdW5kIGRp cmVjdGx5IHVuZGVyDQo+IOKAmGVuZHBvaW504oCZIGFuZCBub3QgdW5kZXIgc3NoIG9yIHRscy4N Cj4gDQo+IFN0aWxsLCBJIHRoaW5rIHRoYXQgdGhpcyBpcyB0aGUgY2FzZSBhbHJlYWR5LiAgQ2Fu IHlvdSBwbGVhc2UgcHJvdmlkZSBhIGNvbmNyZXRlDQo+IGV4YW1wbGUgaWxsdXN0cmF0aW5nIHRo ZSBjb25jZXJuPw0KDQpObyByZWFsIGNvbmNlcm4uIElmIEkgcmVhZCB0aGUgY2FzZXMgJ3NzaCcg YW5kICd0bHMnIGFzICdzc2ggb3ZlciB0Y3AnIA0KYW5kICd0bHMgb3ZlciB0Y3AnLCBpdCBtYWtl cyBzZW5zZS4gSW5pdGlhbGx5IHRoZSBkdXBsaWNhdGlvbiBvZiB0aGUgDQpUQ1AgY29uZmlndXJh dGlvbiBidWdnZWQgbWUuDQoNCj4gDQo+IA0KPiANCj4gVGhhbmtzLA0KPiBLZW50IC8vIGNvbnRy aWJ1dG9yDQo+IA0KDQpOaWNrDQo= From nobody Thu Apr 11 13:35:38 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C30120620; Thu, 11 Apr 2019 13:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8cOI0uS-aBI; Thu, 11 Apr 2019 13:35:33 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E5C120617; Thu, 11 Apr 2019 13:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27122; q=dns/txt; s=iport; t=1555014933; x=1556224533; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TAQGUo2/QKqKfNtyoNlMA+RIC82riMUMF7eaEY69wK0=; b=iX6hflnhYUfmebcY/GQlVh8WtgDbQ7YWkWqi/4JZ4ZC6Vn8lCC+lJv8g cWx/Q8yLbfTmQWIc72AcPya68Gg38nD33Ua4N6HmHDEiqD3YxyM9Z714v X67T9nYXDg4Uq69IxwzPnHkzrWRO11ylDpLdUcfCh+lriBtTyHwwrFVNV M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAADQo69c/5xdJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBgQ5YKmiBAxQUCoQElTWaQw4BAYRtAhe?= =?us-ascii?q?FXCM3Bg0BAQMBAQoBAgECbSiFSgEBAQQjCkUFAhACAQgVEBoDAgICMBQRAgQ?= =?us-ascii?q?OBQgSgj1MgR1rrFCBL4orgTABi0YXgUA/gRGDEj6EWx+CVIJXA4plgjqEMYd?= =?us-ascii?q?gjAtiCQKCBYloQYdgIoIGkmiMeZJyAhEVgTA1IiiBLnAVgyeQTEExj1GBIAE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.60,338,1549929600"; d="scan'208,217";a="546643560" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Apr 2019 20:35:32 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x3BKZVHk030809 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Apr 2019 20:35:32 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 11 Apr 2019 16:35:30 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Thu, 11 Apr 2019 16:35:31 -0400 From: "Eric Voit (evoit)" To: "Carlos Pignataro (cpignata)" CC: "ops-dir@ietf.org" , "draft-ietf-netconf-subscribed-notifications.all@ietf.org" , "ietf@ietf.org" , "netconf@ietf.org" Thread-Topic: Opsdir last call review of draft-ietf-netconf-subscribed-notifications-23 Thread-Index: AQHU7CSNB07lUgUCgUG2NvnSY7Nf0aY0TpQggAF7dQD//8e2QA== Date: Thu, 11 Apr 2019 20:35:31 +0000 Message-ID: <87c35eec471440358c8ca99feee35ca5@XCH-RTP-013.cisco.com> References: <155451947938.10151.12663725914439778891@ietfa.amsl.com> <3e994b49f5c2405cb72d1f0345c5e496@XCH-RTP-013.cisco.com> 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.226] Content-Type: multipart/alternative; boundary="_000_87c35eec471440358c8ca99feee35ca5XCHRTP013ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.156, xch-rtp-016.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [netconf] Opsdir last call review of draft-ietf-netconf-subscribed-notifications-23 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 20:35:37 -0000 --_000_87c35eec471440358c8ca99feee35ca5XCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2FybG9zLA0KDQpGcm9tOiBDYXJsb3MgUGlnbmF0YXJvLCBBcHJpbCAxMCwgMjAxOSAxMTox MSBBTQ0KDQoNCkhpLCBFcmljLA0KDQpPbiBBcHIgOSwgMjAxOSwgYXQgNTowMyBQTSwgRXJpYyBW b2l0IChldm9pdCkgPGV2b2l0QGNpc2NvLmNvbTxtYWlsdG86ZXZvaXRAY2lzY28uY29tPj4gd3Jv dGU6DQoNCkhpIENhcmxvcywNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiAgU29tZSB0aG91Z2h0 cyBpbi1saW5l4oCmDQoNCg0KVGhhbmtzIGZvciB0aGUgZm9sbG93LXVwLg0KDQoNCkZyb206IENh cmxvcyBQaWduYXRhcm8sIEFwcmlsIDUsIDIwMTkgMTA6NTggUE0NCg0KUmV2aWV3ZXI6IENhcmxv cyBQaWduYXRhcm8NClJldmlldyByZXN1bHQ6IEhhcyBOaXRzDQoNCkhpLA0KDQpJIGhhdmUgcmV2 aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBPcGVyYXRpb25hbCBkaXJlY3RvcmF0 ZSdzIG9uZ29pbmcNCmVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHBy b2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlDQpjb21tZW50cyB3ZXJlIHdyaXR0ZW4gd2l0aCB0 aGUgaW50ZW50IG9mIGltcHJvdmluZyB0aGUgb3BlcmF0aW9uYWwgYXNwZWN0cyBvZg0KdGhlIElF VEYgZHJhZnRzLiBDb21tZW50cyB0aGF0IGFyZSBub3QgYWRkcmVzc2VkIGluIGxhc3QgY2FsbCBt YXkgYmUgaW5jbHVkZWQgaW4NCkFEIHJldmlld3MgZHVyaW5nIHRoZSBJRVNHIHJldmlldy4gIERv Y3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQNCnRyZWF0IHRoZXNlIGNvbW1lbnRz IGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpTdW1tYXJ5OiBBbG1v c3QgUmVhZHkNCg0KVGhpcyBpcyBhIGNvbXByZWhlbnNpdmUgdmVyeSB3ZWxsIHdyaXR0ZW4gZG9j dW1lbnQuDQoNCg0KRnJvbSBhbiBvcGVyYXRpb25hbCBwb2ludCBvZiB2aWV3LCBhcyBwZXIgdGhl IG9wcy1kaXIgcmV2aWV3LCBJIGhhdmUgbm8NCmNvbmNlcm5zIG9yIGNvbW1lbnRzLiBNaWdodCBi ZSBuaWNlIHRvIGNvbGxlY3Qgc29tZSBvZiB0aGUgb3BlcmF0aW9uYWwgcG9pbnRzDQppbiBhbiBP cGVyYXRpb25zIENvbnNpZGVyYXRpb24gc2VjdGlvbiwgcGFydGljdWxhcmx5IGdpdmVuIHRoZSBk b2N1bWVudA0Kc3RydWN0dXJlIG9mIFNlY3Rpb24gNS54LCAiWlpaIENvbnNpZGVyYXRpb25zIi4N Cg0KSW4gImltcGxlbWVudGF0aW9uIGNvbnNpZGVyYXRpb25zIiB0aGVyZSBhcmUgYSBjb3VwbGUg d2hpY2ggYXJlIHJlYWxseSBvcGVyYXRpb25hbCBjb25zaWRlcmF0aW9ucy4gIEZvciBleGFtcGxl IHRoZSBmaXJzdCBhbmQgdGhpcmQgYnVsbGV0cyBtaWdodCBxdWFsaWZ5IGFzIG9wZXJhdGlvbmFs LiAgVGhlIGhhcmQgcGFydCBpcyB0aGF0IHRoZSBvcGVyYXRpb25hbCBjb25zaWRlcmF0aW9ucyB0 byBleHBvc2Ugd2lsbCB2YXJ5IGJ5IHRoZSBzdWJzZXQgb2YgZmVhdHVyZSB3aGljaCBhcmUgc2Vs ZWN0ZWQuICBTbyBJIGNhbiBpbWFnaW5lIHRoYXQgbXVjaCB0ZXh0IGNvdWxkIGJlIHdyaXR0ZW4g b24gYmVzdCBvcGVyYXRpb25hbCBwcmFjdGljZXMuICBJIGFtIGhvcGluZyB0aGF0IHN1Y2ggZG9j dW1lbnRzIGNvdWxkIGZvbGxvdyB0aGlzIG9uZSBiYXNlZCBvbiBzcGVjaWZpYyBkZXBsb3ltZW50 IGNvbnRleHRzLg0KDQpTb3JyeSBJIHdhcyBub3QgZXhwbGljaXQuIFdoaWxlIG1hbnkgb2YgdGhl c2UgY29uc2lkZXJhdGlvbnMgaGF2ZSBvcGVyYXRpb25hbCBpbXBsaWNhdGlvbnMsIEkgbWVhbnQg dGhpbmdzIGxpa2UgQXBwZW5kaXggQSBvZiBSRkMgNTcwNiwgbW9yZSBkZXBsb3ltZW50IHRoYW4g aW1wbGVtZW50YXRpb24uDQoNCjxlcmljPiBIaSBDYXJsb3MsDQpQZXIgb3VyIGNhbGwsIEkgcmVm aW5lZCB0aGUgc2VjdGlvbiBkZWZpbml0aW9uIHRvIOKAnEltcGxlbWVudGF0aW9uIGFuZCBEZXBs b3ltZW50IENvbnNpZGVyYXRpb25z4oCdLiAgIEkgZG8gYWdyZWUgdGhhdCBhIG51bWJlciBvZiB0 aGUgZWxlbWVudHMgZnJvbSBSRkMtNTcwNiBBcHBlbmRpeCBBIGFyZSBjb3ZlcmVkIGVsc2V3aGVy ZSBhY3Jvc3Mgc3BlY2lmaWMgc2VjdGlvbnMgb2YgdGhlIGRvY3VtZW50Lg0KDQoNCkkgZG8gaGF2 ZSBvbmUgaW1wb3J0YW50IHF1ZXN0aW9uIGZvciBjb25zaWRlcmF0aW9uLCB3aGljaCBpczogd2hh dCBpcyAqcmVhbGx5Kg0KdGhlIHJlbGF0aW9uc2hpcCBvZiB0aGlzICgrIGRyYWZ0LWlldGYtbmV0 Y29uZi1uZXRjb25mLWV2ZW50LW5vdGlmaWNhdGlvbnMNCnBvdGVudGlhbGx5KSB3aXRoIFJGQyA1 Mjc3PyBBIE5vcm1hdGl2ZSByZWZlcmVuY2UsIHRoaXMgZG9jIGhhcyBubyBtZXRhZGF0YQ0KcmVn YXJkaW5nIFVwZGF0aW5nLCBPYnNvbGV0aW5nLCBldGMuIFlldCBsb3RzIG9mIGl0IGlzIGluZGVl ZCBhIHN1cGVyc2V0IG9mIGl0Lg0KDQpXZSB3ZW50IGFyb3VuZCBhbmQgYXJvdW5kIGluIHRoZSBX RyBvbiB0aGlzIGZvciBhIGJpdC4gIFRoZSBpbml0aWFsIGRlY2lzaW9uIHdhcyB0aGF0IHdlIHdl cmUgZ29pbmcgdG8gb2Jzb2xldGUgUkZDLTUyNzcuIEhvd2V2ZXIgdGhlIHByb2JsZW0gd2FzIHRo YXQgUkZDLTUyNzcgU2VjdGlvbiA0IGhhcyBhIDxub3RpZmljYXRpb24+IGVsZW1lbnQgZGVmaW5l ZCB3aGljaCB3ZSBhcmUgbm90IHJlcGxhY2luZyB5ZXQuIFRoaXMgPG5vdGlmaWNhdGlvbj4gaXMg dXNlZCBpbiBzZXZlcmFsIGltcG9ydGFudCBwbGFjZXMuICBFeGFtcGxlcyBpbmNsdWRlIFJGQy04 MDQwIHNlY3Rpb24gNi40IGFuZCBSRkMtNzk1MCBTZWN0aW9uIDcuMTYuMi4NCg0KRG9lcyB0aGlz IGRlc2NyaWJlIGFuIFVwZGF0ZSBvZiBzcGVjaWZpYyBzZWN0aW9ucyB0aGVuPyBPciB3b3VsZCB3 YW50IHRvIGJyaW5nIGluIHRoZSBub3RpZmljYXRpb24gYW5kIGRvIGEgZnVsbCBiaXM/DQoNCjxl cmljPiBUaGUgV0cgdGFsa2VkIGFib3V0IHRoaXMgc2V2ZXJhbCB0aW1lcy4gIChJbiBmYWN0IHRo ZSBhZG9wdGVkIGRyYWZ0IHdhcyBvcmlnaW5hbGx5IGRyYWZ0LWlldGYtbmV0Y29uZi1yZmM1Mjc3 YmlzLikgICAgQnV0IHdoZXJlIHdlIGVuZGVkIHVwIHdhcyB0aGF0IHdlIHdlcmUgbm90IHJlYWR5 IHRvIGFzc2VydCBvYnNvbGVzY2VuY2UgdW50aWwgd2UgaGFkIHRoZSBuZXcgPG5vdGlmaWNhdGlv bj4gZWxlbWVudCBuYWlsZWQgZG93bi4gICBTbyBwcm9ncmVzc2luZyB0aGUgY3VycmVudCBzZXQg b2YgZHJhZnRzIGluIElFU0cgcmV2aWV3IGdhdmUgdXMgYSBnb29kIHN0ZXAgaW4gdGhhdCBkaXJl Y3Rpb24uICBBbmQgd2hlbiB3ZSBoYXZlIHN0cnVjdHVyZWQgdGhpcyBkb2N1bWVudCBzbyB0aGF0 IHdoZW4gd2UgZG8gY29tcGxldGUgZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNz YWdlcywgdGhpbmdzIHNob3VsZCBpbnRlZ3JhdGUgY2xlYW5seS4gIFRoZSBoYXJkIHF1ZXN0aW9u IHdpbGwgYmUgaG93IHRvIGhhbmRsZSB0aGUgbWV0YS1yZWZlcmVuY2VzIHByb3Blcmx5LiAgSSBi ZWxpZXZlIHRoaXMgaXMgYmVzdCBhdHRlbXB0ZWQgd2hlbiBhbiBmdWxsIHNldCBvZiBkb2N1bWVu dHMgd2hpY2ggaXMgYWJsZSB0byBvYnNvbGV0ZSBSRkMtNTI3NyBpcyBhdmFpbGFibGUuDQoNClNv IHdlIGRpZG4ndCB3YW50IHRvIHJlY29tbWVuZCBhbiBvYnNvbGV0ZSB3aXRob3V0IGEgcmVwbGFj ZW1lbnQgb2YgdGhhdCA8bm90aWZpY2F0aW9uPi4gIFRoZSBnb29kIG5ld3MgaXMgdGhhdCB3ZSBh cmUgd29ya2luZyBvbiBhIHJlcGxhY2VtZW50IGZvciB0aGlzIG5vdGlmaWNhdGlvbi4gIFNlZTog ZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcyAgICAgQnV0IHRoaXMgc3Rp bGwgaGFzIGEgd2hpbGUgdG8gZ28gYmVmb3JlIGl0IGlzIHJlYWR5LiAgQXMgYSByZXN1bHQgd2Ug YXJlIGxlZnQgd2l0aCBTZWN0aW9uIDEuNCBvZiBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJl ZC1ub3RpZmljYXRpb25zIHdoaWNoIGRlc2NyaWJlcyB0aGUgcmVsYXRpb25zaGlwIHdpdGggUkZD LTUyNzcuDQoNClRoaXMgaXMgc3RpbGwgc29tZXdoYXQgY29uZnVzaW5nLiBTZWN0aW9uIDEuNCBz YXlzOg0KDQogICBUaGlzIGRvY3VtZW50IGlzIGludGVuZGVkIHRvIHByb3ZpZGUgYSBzdXBlcnNl dCBvZiB0aGUgc3Vic2NyaXB0aW9uDQogICBjYXBhYmlsaXRpZXMgaW5pdGlhbGx5IGRlZmluZWQg d2l0aGluIFtSRkM1Mjc3XS4NCg0KQnV0IGlmIGl0IGlzIHJlYWxseSBhIHN1cGVyc2V0LCBpcyBp dCBvYnNvbGV0aW5nIGl0Pw0KDQoNCjxlcmljPiBUaGUgc3Vic2NyaXB0aW9uIGNhcGFiaWxpdGll cyBhcmUgYSBzdXBlcnNldC4gIEkuZS4sIHRoZSBjb250cm9sIHBsYW5lIGNhbiBkbyBldmVyeXRo aW5nIGluIFJGQy01Mjc3LiAgSG93ZXZlciB0aGUgPG5vdGlmaWNhdGlvbj4gZWxlbWVudCB3b3Jr IHdhcyBkZWZlcnJlZC4NCg0KUzEuNCBmdXJ0aGVyIGdvZXM6DQoNCiAgIEVzcGVjaWFsbHkgd2hl bg0KICAgZXh0ZW5kaW5nIGFuIGV4aXN0aW5nIFtSRkM1Mjc3XSBpbXBsZW1lbnRhdGlvbiwgaXQg aXMgaW1wb3J0YW50IHRvDQogICB1bmRlcnN0YW5kIHdoYXQgaGFzIGJlZW4gcmV1c2VkIGFuZCB3 aGF0IGhhcyBiZWVuIHJlcGxhY2VkLg0KDQpTaW1pbGFybHksIHJldXNlK3JlcGxhY2UgbWVhbnMg b2Jzb2xldGU/IE9yIHVwZGF0ZT8gOi0pDQoNCjxlcmljPiBGb3IgdGhlIHJlYXNvbnMgYWJvdmUs IG5vdCBvYnNvbGV0ZS4gIFBlcmhhcHMg4oCYdXBkYXRl4oCZIG1pZ2h0IGFwcGx5LiAgQnV0IGhv bmVzdGx5IEkgZG9u4oCZdCBrbm93IHRoZSBtZXRhLXJlZmVyZW5jZSBjb252ZW50aW9uIHdoZW4g dHdvIGRvY3VtZW50cyAoZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9u cyAmIGRyYWZ0LWlldGYtbmV0Y29uZi1uZXRjb25mLWV2ZW50LW5vdGlmaWNhdGlvbnMpIGltcHJv dmUgdXBvbiB0aGUgbWFqb3JpdHkgb2Ygd2hhdCBpcyBpbiBhbm90aGVyIGRvY3VtZW50IChSRkMt NTI3NykuICBGb3IgdGhhdCByZWFzb24sIGRvaW5nIG5vdGhpbmcgaW4gbWV0YS1yZWZlcmVuY2lu ZyB1bnRpbCBhIGZ1bGwgZnVuY3Rpb25hbCByZXBsYWNlbWVudCB3YXMgYXZhaWxhYmxlIHNlZW1l ZCBsaWtlIHRoZSBiZXN0IHBhdGguDQoNClRoYW5rcywNCkVyaWMNCg0KDQpJIHJlY29tbWVuZCB0 aGUgYXV0aG9ycytBRHMgY29uc2lkZXIgd2hldGhlciB0aGVyZSBpcyBhbnkgbW9yZSBmb3JtYWwN CnJlbGF0aW9uc2hpcCB3aXRoIFJGQyA1Mjc3IHRoYXQgd291bGQgcmVxdWlyZSBtZXRhLXRhZ2dp bmcgdGhlIFJGQy4NCg0KSSB0aGluayB0aGF0IHRoaXMgaXMgZnVsbHkgYXBwcm9wcmlhdGUgYXMg d2UgZmluaXNoIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMNCg0KSSBk byBub3QgdGhpbmsgeW91IG5lZWQgdG8gd2FpdCBmb3IgZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlm aWNhdGlvbi1tZXNzYWdlcyAoYW5kIGRlbGF5IGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVk LW5vdGlmaWNhdGlvbnMpIGluIG9yZGVyIHRvIGhhdmUgYW4gYXBwcm9wcmlhdGUgbWV0YS1yZWZl cmVuY2UuIFBlcmhhcHMgZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcyB3 aWxsIHVwZGF0ZSBzb21ldGhpbmcgKGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlm aWNhdGlvbnM/KQ0KDQpUaGFua3MsDQoNCkNhcmxvcy4NCg0KDQoNClRoYW5rcyENCkVyaWMNCg0K DQpUaGFua3MsDQoNCkNhcmxvcyBQaWduYXRhcm8uDQoNCg== --_000_87c35eec471440358c8ca99feee35ca5XCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6TWVubG8tUmVndWxhcjsNCglwYW5vc2UtMTowIDAgMCAw IDAgMCAwIDAgMCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWww LCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3Jt YWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQ2FybG9zLDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBDYXJsb3MgUGlnbmF0YXJvLCBBcHJp bCAxMCwgMjAxOSAxMToxMSBBTTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SGksIEVyaWMsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gQXByIDksIDIwMTksIGF0IDU6MDMgUE0sIEVyaWMgVm9pdCAoZXZv aXQpICZsdDs8YSBocmVmPSJtYWlsdG86ZXZvaXRAY2lzY28uY29tIj5ldm9pdEBjaXNjby5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sby1SZWd1bGFy JnF1b3Q7LHNlcmlmIj5IaSBDYXJsb3MsPGJyPg0KPGJyPg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3 LiAmbmJzcDtTb21lIHRob3VnaHRzIGluLWxpbmXigKY8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiBy Z2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGFua3MgZm9yIHRoZSBmb2xsb3ctdXAuPGJyPg0KPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0 LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87 LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250 LWZhbWlseTomcXVvdDtNZW5sby1SZWd1bGFyJnF1b3Q7LHNlcmlmIj5Gcm9tOiBDYXJsb3MgUGln bmF0YXJvLCBBcHJpbCA1LCAyMDE5IDEwOjU4IFBNPGJyPg0KPGJyPg0KUmV2aWV3ZXI6IENhcmxv cyBQaWduYXRhcm88YnI+DQpSZXZpZXcgcmVzdWx0OiBIYXMgTml0czxicj4NCjxicj4NCkhpLDxi cj4NCjxicj4NCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIE9w ZXJhdGlvbmFsIGRpcmVjdG9yYXRlJ3Mgb25nb2luZzxicj4NCmVmZm9ydCB0byByZXZpZXcgYWxs IElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gJm5ic3A7VGhlc2U8 YnI+DQpjb21tZW50cyB3ZXJlIHdyaXR0ZW4gd2l0aCB0aGUgaW50ZW50IG9mIGltcHJvdmluZyB0 aGUgb3BlcmF0aW9uYWwgYXNwZWN0cyBvZjxicj4NCnRoZSBJRVRGIGRyYWZ0cy4gQ29tbWVudHMg dGhhdCBhcmUgbm90IGFkZHJlc3NlZCBpbiBsYXN0IGNhbGwgbWF5IGJlIGluY2x1ZGVkIGluPGJy Pg0KQUQgcmV2aWV3cyBkdXJpbmcgdGhlIElFU0cgcmV2aWV3LiAmbmJzcDtEb2N1bWVudCBlZGl0 b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkPGJyPg0KdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBs aWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPGJyPg0KPGJyPg0KU3VtbWFyeTogQWxt b3N0IFJlYWR5PGJyPg0KPGJyPg0KVGhpcyBpcyBhIGNvbXByZWhlbnNpdmUgdmVyeSB3ZWxsIHdy aXR0ZW4gZG9jdW1lbnQuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O01lbmxvLVJlZ3VsYXImcXVvdDssc2VyaWYiPkZyb20gYW4gb3BlcmF0aW9u YWwgcG9pbnQgb2YgdmlldywgYXMgcGVyIHRoZSBvcHMtZGlyIHJldmlldywgSSBoYXZlIG5vPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sby1SZWd1 bGFyJnF1b3Q7LHNlcmlmIj5jb25jZXJucyBvciBjb21tZW50cy4gTWlnaHQgYmUgbmljZSB0byBj b2xsZWN0IHNvbWUgb2YgdGhlIG9wZXJhdGlvbmFsIHBvaW50czxicj4NCmluIGFuIE9wZXJhdGlv bnMgQ29uc2lkZXJhdGlvbiBzZWN0aW9uLCBwYXJ0aWN1bGFybHkgZ2l2ZW4gdGhlIGRvY3VtZW50 PGJyPg0Kc3RydWN0dXJlIG9mIFNlY3Rpb24gNS54LCAmcXVvdDtaWlogQ29uc2lkZXJhdGlvbnMm cXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtN ZW5sby1SZWd1bGFyJnF1b3Q7LHNlcmlmIj48YnI+DQpJbiAmcXVvdDtpbXBsZW1lbnRhdGlvbiBj b25zaWRlcmF0aW9ucyZxdW90OyB0aGVyZSBhcmUgYSBjb3VwbGUgd2hpY2ggYXJlIHJlYWxseSBv cGVyYXRpb25hbCBjb25zaWRlcmF0aW9ucy4gJm5ic3A7Rm9yIGV4YW1wbGUgdGhlIGZpcnN0IGFu ZCB0aGlyZCBidWxsZXRzIG1pZ2h0IHF1YWxpZnkgYXMgb3BlcmF0aW9uYWwuICZuYnNwO1RoZSBo YXJkIHBhcnQgaXMgdGhhdCB0aGUgb3BlcmF0aW9uYWwgY29uc2lkZXJhdGlvbnMgdG8gZXhwb3Nl IHdpbGwgdmFyeSBieSB0aGUgc3Vic2V0DQogb2YgZmVhdHVyZSB3aGljaCBhcmUgc2VsZWN0ZWQu ICZuYnNwO1NvIEkgY2FuIGltYWdpbmUgdGhhdCBtdWNoIHRleHQgY291bGQgYmUgd3JpdHRlbiBv biBiZXN0IG9wZXJhdGlvbmFsIHByYWN0aWNlcy4gJm5ic3A7SSBhbSBob3BpbmcgdGhhdCBzdWNo IGRvY3VtZW50cyBjb3VsZCBmb2xsb3cgdGhpcyBvbmUgYmFzZWQgb24gc3BlY2lmaWMgZGVwbG95 bWVudCBjb250ZXh0cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvcnJ5IEkgd2FzIG5vdCBleHBsaWNp dC4gV2hpbGUgbWFueSBvZiB0aGVzZSBjb25zaWRlcmF0aW9ucyBoYXZlIG9wZXJhdGlvbmFsIGlt cGxpY2F0aW9ucywgSSBtZWFudCB0aGluZ3MgbGlrZSBBcHBlbmRpeCBBIG9mIFJGQyA1NzA2LCBt b3JlIGRlcGxveW1lbnQgdGhhbiBpbXBsZW1lbnRhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXJpZ2h0Oi41aW4iPiZsdDtlcmljJmd0 OyBIaSBDYXJsb3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLXJpZ2h0Oi41aW4iPlBlciBvdXIgY2FsbCwgSSByZWZpbmVkIHRoZSBzZWN0aW9uIGRl ZmluaXRpb24gdG8g4oCcSW1wbGVtZW50YXRpb24gYW5kIERlcGxveW1lbnQgQ29uc2lkZXJhdGlv bnPigJ0uJm5ic3A7Jm5ic3A7IEkgZG8gYWdyZWUgdGhhdCBhIG51bWJlciBvZiB0aGUgZWxlbWVu dHMgZnJvbSBSRkMtNTcwNiBBcHBlbmRpeCBBIGFyZSBjb3ZlcmVkIGVsc2V3aGVyZSBhY3Jvc3Mg c3BlY2lmaWMgc2VjdGlvbnMNCiBvZiB0aGUgZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O01lbmxvLVJlZ3VsYXImcXVvdDssc2VyaWYiPjxicj4NCjxicj4NCjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sby1SZWd1bGFyJnF1b3Q7LHNlcmlmIj5JIGRv IGhhdmUgb25lIGltcG9ydGFudCBxdWVzdGlvbiBmb3IgY29uc2lkZXJhdGlvbiwgd2hpY2ggaXM6 IHdoYXQgaXMgKnJlYWxseSo8YnI+DQp0aGUgcmVsYXRpb25zaGlwIG9mIHRoaXMgKCYjNDM7IGRy YWZ0LWlldGYtbmV0Y29uZi1uZXRjb25mLWV2ZW50LW5vdGlmaWNhdGlvbnM8YnI+DQpwb3RlbnRp YWxseSkgd2l0aCBSRkMgNTI3Nz8gQSBOb3JtYXRpdmUgcmVmZXJlbmNlLCB0aGlzIGRvYyBoYXMg bm8gbWV0YWRhdGE8YnI+DQpyZWdhcmRpbmcgVXBkYXRpbmcsIE9ic29sZXRpbmcsIGV0Yy4gWWV0 IGxvdHMgb2YgaXQgaXMgaW5kZWVkIGEgc3VwZXJzZXQgb2YgaXQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sby1SZWd1bGFyJnF1b3Q7LHNlcmlm Ij48YnI+DQpXZSB3ZW50IGFyb3VuZCBhbmQgYXJvdW5kIGluIHRoZSBXRyBvbiB0aGlzIGZvciBh IGJpdC4gJm5ic3A7VGhlIGluaXRpYWwgZGVjaXNpb24gd2FzIHRoYXQgd2Ugd2VyZSBnb2luZyB0 byBvYnNvbGV0ZSBSRkMtNTI3Ny4gSG93ZXZlciB0aGUgcHJvYmxlbSB3YXMgdGhhdCBSRkMtNTI3 NyBTZWN0aW9uIDQgaGFzIGEgJmx0O25vdGlmaWNhdGlvbiZndDsgZWxlbWVudCBkZWZpbmVkIHdo aWNoIHdlIGFyZSBub3QgcmVwbGFjaW5nIHlldC4gVGhpcyAmbHQ7bm90aWZpY2F0aW9uJmd0Ow0K IGlzIHVzZWQgaW4gc2V2ZXJhbCBpbXBvcnRhbnQgcGxhY2VzLiAmbmJzcDtFeGFtcGxlcyBpbmNs dWRlIFJGQy04MDQwIHNlY3Rpb24gNi40IGFuZCBSRkMtNzk1MCBTZWN0aW9uIDcuMTYuMi48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+RG9lcyB0aGlzIGRlc2NyaWJlIGFuIFVwZGF0ZSBvZiBzcGVjaWZpYyBzZWN0aW9u cyB0aGVuPyBPciB3b3VsZCB3YW50IHRvIGJyaW5nIGluIHRoZSBub3RpZmljYXRpb24gYW5kIGRv IGEgZnVsbCBiaXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZsdDtlcmljJmd0OyBUaGUgV0cgdGFsa2VkIGFib3V0IHRoaXMgc2V2ZXJhbCB0 aW1lcy4mbmJzcDsgKEluIGZhY3QgdGhlIGFkb3B0ZWQgZHJhZnQgd2FzIG9yaWdpbmFsbHkgZHJh ZnQtaWV0Zi1uZXRjb25mLXJmYzUyNzdiaXMuKSAmbmJzcDsmbmJzcDsmbmJzcDtCdXQgd2hlcmUg d2UgZW5kZWQgdXAgd2FzIHRoYXQgd2Ugd2VyZSBub3QgcmVhZHkgdG8gYXNzZXJ0IG9ic29sZXNj ZW5jZSB1bnRpbCB3ZSBoYWQgdGhlIG5ldyAmbHQ7bm90aWZpY2F0aW9uJmd0OyBlbGVtZW50DQog bmFpbGVkIGRvd24uJm5ic3A7Jm5ic3A7IFNvIHByb2dyZXNzaW5nIHRoZSBjdXJyZW50IHNldCBv ZiBkcmFmdHMgaW4gSUVTRyByZXZpZXcgZ2F2ZSB1cyBhIGdvb2Qgc3RlcCBpbiB0aGF0IGRpcmVj dGlvbi4mbmJzcDsgQW5kIHdoZW4gd2UgaGF2ZSBzdHJ1Y3R1cmVkIHRoaXMgZG9jdW1lbnQgc28g dGhhdCB3aGVuIHdlIGRvIGNvbXBsZXRlIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24t bWVzc2FnZXMsIHRoaW5ncyBzaG91bGQgaW50ZWdyYXRlIGNsZWFubHkuJm5ic3A7DQogVGhlIGhh cmQgcXVlc3Rpb24gd2lsbCBiZSBob3cgdG8gaGFuZGxlIHRoZSBtZXRhLXJlZmVyZW5jZXMgcHJv cGVybHkuJm5ic3A7IEkgYmVsaWV2ZSB0aGlzIGlzIGJlc3QgYXR0ZW1wdGVkIHdoZW4gYW4gZnVs bCBzZXQgb2YgZG9jdW1lbnRzIHdoaWNoIGlzIGFibGUgdG8gb2Jzb2xldGUgUkZDLTUyNzcgaXMg YXZhaWxhYmxlLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O01lbmxvLVJlZ3VsYXImcXVvdDssc2VyaWYiPjxicj4NClNvIHdlIGRpZG4ndCB3YW50 IHRvIHJlY29tbWVuZCBhbiBvYnNvbGV0ZSB3aXRob3V0IGEgcmVwbGFjZW1lbnQgb2YgdGhhdCAm bHQ7bm90aWZpY2F0aW9uJmd0Oy4gJm5ic3A7VGhlIGdvb2QgbmV3cyBpcyB0aGF0IHdlIGFyZSB3 b3JraW5nIG9uIGEgcmVwbGFjZW1lbnQgZm9yIHRoaXMgbm90aWZpY2F0aW9uLiAmbmJzcDtTZWU6 IGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7QnV0IHRoaXMgc3RpbGwgaGFzIGEgd2hpbGUgdG8gZ28gYmVmb3JlDQogaXQgaXMg cmVhZHkuICZuYnNwO0FzIGEgcmVzdWx0IHdlIGFyZSBsZWZ0IHdpdGggU2VjdGlvbiAxLjQgb2Yg ZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyB3aGljaCBkZXNjcmli ZXMgdGhlIHJlbGF0aW9uc2hpcCB3aXRoIFJGQy01Mjc3Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhp cyBpcyBzdGlsbCBzb21ld2hhdCBjb25mdXNpbmcuIFNlY3Rpb24gMS40IHNheXM6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgJm5ic3A7VGhpcyBkb2N1bWVudCBpcyBpbnRlbmRlZCB0byBwcm92aWRlIGEgc3VwZXJzZXQg b2YgdGhlIHN1YnNjcmlwdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2NhcGFiaWxpdGllcyBpbml0aWFsbHkgZGVmaW5l ZCB3aXRoaW4gW1JGQzUyNzddLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KQnV0IGlmIGl0IGlzIHJlYWxseSBhIHN1cGVyc2V0LCBpcyBp dCBvYnNvbGV0aW5nIGl0PyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7ZXJpYyZndDsgVGhlIHN1YnNjcmlwdGlv biBjYXBhYmlsaXRpZXMgYXJlIGEgc3VwZXJzZXQuJm5ic3A7IEkuZS4sIHRoZSBjb250cm9sIHBs YW5lIGNhbiBkbyBldmVyeXRoaW5nIGluIFJGQy01Mjc3LiZuYnNwOyBIb3dldmVyIHRoZSAmbHQ7 bm90aWZpY2F0aW9uJmd0OyBlbGVtZW50IHdvcmsgd2FzIGRlZmVycmVkLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5TMS40IGZ1cnRoZXIgZ29lczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO0VzcGVjaWFsbHkgd2hlbjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwO2V4dGVuZGluZyBhbiBleGlzdGluZyBbUkZDNTI3N10gaW1wbGVtZW50YXRpb24sIGl0 IGlzIGltcG9ydGFudCB0bzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmbmJzcDt1bmRlcnN0YW5kIHdoYXQgaGFzIGJlZW4gcmV1c2VkIGFuZCB3aGF0 IGhhcyBiZWVuIHJlcGxhY2VkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQpTaW1pbGFybHksIHJldXNlJiM0MztyZXBsYWNlIG1lYW5zIG9i c29sZXRlPyBPciB1cGRhdGU/IDotKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7ZXJpYyZn dDsgRm9yIHRoZSByZWFzb25zIGFib3ZlLCBub3Qgb2Jzb2xldGUuJm5ic3A7IFBlcmhhcHMg4oCY dXBkYXRl4oCZIG1pZ2h0IGFwcGx5LiZuYnNwOyBCdXQgaG9uZXN0bHkgSSBkb27igJl0IGtub3cg dGhlIG1ldGEtcmVmZXJlbmNlIGNvbnZlbnRpb24gd2hlbiB0d28gZG9jdW1lbnRzIChkcmFmdC1p ZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zICZhbXA7IGRyYWZ0LWlldGYtbmV0 Y29uZi1uZXRjb25mLWV2ZW50LW5vdGlmaWNhdGlvbnMpDQogaW1wcm92ZSB1cG9uIHRoZSBtYWpv cml0eSBvZiB3aGF0IGlzIGluIGFub3RoZXIgZG9jdW1lbnQgKFJGQy01Mjc3KS4mbmJzcDsgRm9y IHRoYXQgcmVhc29uLCBkb2luZyBub3RoaW5nIGluIG1ldGEtcmVmZXJlbmNpbmcgdW50aWwgYSBm dWxsIGZ1bmN0aW9uYWwgcmVwbGFjZW1lbnQgd2FzIGF2YWlsYWJsZSBzZWVtZWQgbGlrZSB0aGUg YmVzdCBwYXRoLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FcmljPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjI1cHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVndWxhciZxdW90OyxzZXJp ZiI+PGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZx dW90O01lbmxvLVJlZ3VsYXImcXVvdDssc2VyaWYiPkkgcmVjb21tZW5kIHRoZSBhdXRob3JzJiM0 MztBRHMgY29uc2lkZXIgd2hldGhlciB0aGVyZSBpcyBhbnkgbW9yZSBmb3JtYWw8YnI+DQpyZWxh dGlvbnNoaXAgd2l0aCBSRkMgNTI3NyB0aGF0IHdvdWxkIHJlcXVpcmUgbWV0YS10YWdnaW5nIHRo ZSBSRkMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtN ZW5sby1SZWd1bGFyJnF1b3Q7LHNlcmlmIj48YnI+DQpJIHRoaW5rIHRoYXQgdGhpcyBpcyBmdWxs eSBhcHByb3ByaWF0ZSBhcyB3ZSBmaW5pc2ggZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlv bi1tZXNzYWdlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIG5vdCB0aGluayB5b3UgbmVlZCB0byB3YWl0IGZv ciBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzJm5ic3A7KGFuZCBkZWxh eSBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zKSBpbiBvcmRlciB0 byBoYXZlIGFuIGFwcHJvcHJpYXRlIG1ldGEtcmVmZXJlbmNlLiBQZXJoYXBzJm5ic3A7ZHJhZnQt aWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcyB3aWxsIHVwZGF0ZQ0KIHNvbWV0aGlu ZyAoZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucz8pPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2FybG9z LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvLVJlZ3Vs YXImcXVvdDssc2VyaWYiPjxicj4NClRoYW5rcyE8YnI+DQpFcmljPGJyPg0KPGJyIHN0eWxlPSJj YXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1h bGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBw eCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVn dWxhciZxdW90OyxzZXJpZiI+VGhhbmtzLDxicj4NCjxicj4NCkNhcmxvcyBQaWduYXRhcm8uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_87c35eec471440358c8ca99feee35ca5XCHRTP013ciscocom_-- From nobody Thu Apr 11 14:54:12 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0C01205FD; Thu, 11 Apr 2019 14:54:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Aanchal Malhotra via Datatracker To: Cc: netconf@ietf.org, ietf@ietf.org, draft-ietf-netconf-restconf-notif.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Aanchal Malhotra Message-ID: <155501965074.14152.2835369201856309773@ietfa.amsl.com> Date: Thu, 11 Apr 2019 14:54:10 -0700 Archived-At: Subject: [netconf] Secdir last call review of draft-ietf-netconf-restconf-notif-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 21:54:11 -0000 Reviewer: Aanchal Malhotra Review result: Ready The document is very clear and concise. I just have one minor clarification question. Section 3.4 Page 9 that says the following: "In addition to any required ........SHOULD only be allowed......". Is there a reason for using SHOULD instead of MUST? From nobody Thu Apr 11 23:54:20 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8BB012015B; Thu, 11 Apr 2019 23:54:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu via Datatracker To: Cc: netconf@ietf.org, ietf@ietf.org, draft-ietf-netconf-restconf-notif.all@ietf.org, dromasca@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Dan Romascanu Message-ID: <155505204479.14152.7199403462087388546@ietfa.amsl.com> Date: Thu, 11 Apr 2019 23:54:04 -0700 Archived-At: Subject: [netconf] Opsdir last call review of draft-ietf-netconf-restconf-notif-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 06:54:05 -0000 Reviewer: Dan Romascanu Review result: Ready This document describes the RESTCONF binding to the dynamic subscription capability of both subscribed notifications and YANG-Push. It's a useful and important addition to the RESTCONF protocol mechanisms, and operators should pay attention. The document is not easy reading, as it relies on several other documents, but the references in the text help. It would have helped if some notes were added concerning the possible actions that the operators need to take in order to ensure optimal behavior (initial configuration for example) or indications about when to use one or the other of the notifications mechanisms. This is not blocking, however, and the document is READY for publication. From nobody Fri Apr 12 05:22:13 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2ED12019B; Fri, 12 Apr 2019 05:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hansfords.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 sMIdq444tWgU; Fri, 12 Apr 2019 05:22:01 -0700 (PDT) Received: from mail.myfast.site (mail.myfast.site [109.203.117.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF1B12011D; Fri, 12 Apr 2019 05:22:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Type:MIME-Version:Subject:References: In-Reply-To:Message-ID:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5iIlsS695vITqJSVlJsLEP2lu8qH8e81l6q4WJO/MF0=; b=Aqdd6WbRzoKlxod5MAVcfTxH4 0Hw6kchvQL1Tw49zdScuUsfnNDjw7do5C9+4vl6XQYyg/V4FslFEa9Gsk5A7RUUejtfzowx9MOSIY ndfrVNGc5rHPOy+uyXrv5SPGKNH108VXtw5ggq+NZtFsI+1vapMZauz/kKfxPwwt4FTE6lyCbkDyo liujJVJw1mJ5xtTKr5vScoX8wv5/Zh9YtUgF5JnWpmbrPV3E1bpWGemHY741aU00FaNBSjVa0zpxW Gn3jJn8dAF+rnXve1/GyuDUYL1MP9oYe4U3NkDxFI2ph3xcS8MzPvDPRkshS4I+pN//d3n0y5C8pF yzYZbZX0g==; Received: from hansfords.plus.com ([84.92.116.209]:32987 helo=[192.168.54.23]) by mail.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hEvBt-0001cn-HD; Fri, 12 Apr 2019 13:21:58 +0100 Date: Fri, 12 Apr 2019 13:15:22 +0100 From: Jonathan To: Martin Bjorklund , Per Hedeland Cc: mferguson@amsl.com, bclaise@cisco.com, rob.enns@gmail.com, iesg@ietf.org, netconf@ietf.org, rfc-editor@rfc-editor.org Message-ID: <92cbd858-e49f-4d28-a81f-af55813c7e3c@Spark> In-Reply-To: References: <20140113155326.2E4B97FC396@rfc-editor.org> <74C3A7F7-B338-4B9F-AD61-66F39EA43FC9@amsl.com> <34e64e9f-f3a0-9c4f-9860-e69e120e926c@hedeland.org> <20190221.142233.540619960445664842.mbj@tail-f.com> X-Readdle-Message-ID: 92cbd858-e49f-4d28-a81f-af55813c7e3c@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5cb082e1_327b23c6_16b2" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mail.myfast.site X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hansfords.net X-Get-Message-Sender-Via: mail.myfast.site: authenticated_id: jonathan@hansfords.net X-Authenticated-Sender: mail.myfast.site: jonathan@hansfords.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [netconf] [Errata Held for Document Update] RFC6241 (3821) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 12:22:05 -0000 --5cb082e1_327b23c6_16b2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Re and , the point I was trying to get across is, since there can be a sequence of commits after a confirmed commit and before the final confirming commit, it would not necessarily be the last commit before session termination that makes the confirmed commit persistent. Perhaps "unless the last confirmed commit also included a or element" would be better worded as "unless the confirmed commit was persistent". Jonathan =O) On 21 Feb 2019, 13:48 +0000, Per Hedeland , wrote: > On 2019-02-21 14:22, Martin Bjorklund wrote: > > Hi, > > > > Per Hedeland wrote: > > > On 2019-02-20 01:44, Megan Ferguson wrote: > > > > Jonathan and Benoit, > > > > We have edited the "corrected text in this errata report as > > > > suggested by Jonathan. > > > > > > I don't know if this change - i.e. the addition of the text "or > > > " in two places - should affect the status of the > > > document, but it seems to me that it can then no longer be considered > > > a "clarification", since it proposes a change to the semantics > > > specified in RFC 6241. As far as I can see, it is clear from 6241 that > > > the presence of the parameter does not affect the > > > persistence, only the presence of the parameter does that. > > > > Hmm, I missed this detail. > > > > It is clearly not correct to say that the affects > > persistence. So s/or // in the 4th and 5th paragraphs. > > Hm, right, the remainder of the change to the 5th paragraph should be > kept (I originally misread it as *only* adding "or " there > too). > > > Do you see any other issues with the proposed text? > > No, it seems fine - a useful clarification. > > > (An editorial change - the 4th para should be split into two, just as > > in the original text) > > +1 > > --Per > > > /martin > > > > > > > > > > > > > > > > > > Furthermore, I'm afraid I fail to find any motivation for this change > > > in the quoted message from Jonathan (as far as I can see, this message > > > was not sent to the mailing list). > > > > > > --Per Hedeland > > > > > > > We have left the status of this report as Held for Document > > > > Update. > > > > Please let us know if any further action is necessary on our part. > > > > The report itself is viewable at > > > > https://www.rfc-editor.org/errata/eid3821. > > > > Old (as in Jonathans original report): > > > > If the session issuing a sequence of one or more > > > > confirmed commits is terminated for any reason before the confirm > > > > timeout expires, the server MUST restore the configuration to its > > > > state before the sequence of confirmed commits was issued, unless > > > > the last confirmed commit also included a > > > > element. > > > > If the device reboots for any reason before the confirm timeout > > > > expires, the server MUST restore the configuration to its state > > > > before the sequence of confirmed commits was issued. > > > > New (as updated by Jonathans email - see the last line of both > > > > paragraphs): > > > > If the session issuing a sequence of one or more > > > > confirmed commits is terminated for any reason before the confirm > > > > timeout expires, the server MUST restore the configuration to its > > > > state before the sequence of confirmed commits was issued, unless > > > > the last confirmed commit also included a or > > > > element. > > > > If the device reboots for any reason before the confirm timeout > > > > expires, the server MUST restore the configuration to its state > > > > before the sequence of confirmed commits was issued, unless the last > > > > confirmed commit also included a or element. > > > > Thank you. > > > > RFC Editor/mf > > > > > > > > > Hi, > > > > > I raised erratum 3821 to clarify the meaning of the term "confirmed > > > > > commit" for those not familiar with the use of the term within > > > > > JUNOS. Both the original text and the erratum include text that states > > > > > If the device reboots for any reason before the confirm timeout > > > > > expires, the server MUST restore the configuration to its state before > > > > > the sequence of confirmed commits was issued.. I have since > > > > > discovered the description of the persist leaf on page 102 that > > > > > includes the statement, A persistent confirmed commit is not aborted > > > > > if the NETCONF session terminates. The only way to abort a persistent > > > > > confirmed commit is to let the timer expire, or to use the > > > > > operation. Consequently, the replacement text should > > > > > read: > > > > > 8.4.1. Description > > > > > The :confirmed-commit:1.1 capability indicates that the server will > > > > > support the operation, the , > > > > timeout>, , and parameters for the > > > > > operation, and differentiate between a to be confirmed > > > > > operation (a confirmed commit) and a confirming > > > > > operation. See Section 8.3 for further details on the > > > > > operation. > > > > > A confirmed operation MUST be reverted if a confirming > > > > > commit is not issued within the timeout period (by default 600 > > > > > seconds = 10 minutes). The confirming commit is a operation > > > > > without the parameter and, if successful, cannot be > > > > > reverted. The timeout period can be adjusted with the > > > > timeout> parameter. If a follow-up confirmed operation is > > > > > issued before the timer expires, the timer is reset to the new value > > > > > (600 seconds by default). Both the confirming commit and a follow-up > > > > > confirmed operation MAY introduce additional changes to the > > > > > configuration. > > > > > If the element is not given in the confirmed commit > > > > > operation, any follow-up commit and the confirming commit MUST be > > > > > issued on the same session that issued the confirmed commit. If the > > > > > element is given in the confirmed operation, a > > > > > follow-up commit and the confirming commit can be given on any > > > > > session, and they MUST include a element with a value > > > > > equal to the given value of the element. > > > > > If the server also advertises the :startup capability, a > > > > config> from running to startup is also necessary to save the > > > > > changes to startup. If the session issuing a sequence of one or more > > > > > confirmed commits is terminated for any reason before the confirm > > > > > timeout expires, the server MUST restore the configuration to its > > > > > state before the sequence of confirmed commits was issued, unless > > > > > the last confirmed commit also included a or > > > > > element. > > > > > If the device reboots for any reason before the confirm timeout > > > > > expires, the server MUST restore the configuration to its state > > > > > before the sequence of confirmed commits was issued, unless the last > > > > > confirmed commit also included a or element. > > > > > If a confirming commit is not issued, the device will revert its > > > > > configuration to the state prior to the issuance of the first in the > > > > > current sequence of confirmed commits. To cancel the current > > > > > sequence of confirmed commits and revert changes without waiting for > > > > > the confirm timeout to expire, the client can explicitly restore the > > > > > configuration to its state before the sequence of confirmed commits > > > > > was issued, by using the operation. > > > > > Jonathan Hansford > > > > On Jan 13, 2014, at 7:53 AM, RFC Errata System > > > > wrote: > > > > > > > > > The following errata report has been held for document update > > > > > for RFC6241, "Network Configuration Protocol (NETCONF)". > > > > > > > > > > -------------------------------------- > > > > > You may review the report below and at: > > > > > http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=3821 > > > > > > > > > > -------------------------------------- > > > > > Status: Held for Document Update > > > > > Type: Editorial > > > > > > > > > > Reported by: Jonathan Hansford > > > > > Date Reported: 2013-12-06 > > > > > Held by: Benoit Claise (IESG) > > > > > > > > > > Section: 8.4.1 > > > > > > > > > > Original Text > > > > > ------------- > > > > > 8.4.1. Description > > > > > > > > > > The :confirmed-commit:1.1 capability indicates that the server will > > > > > support the operation and the , > > > > > , , and parameters for the > > > > > operation. See Section 8.3 for further details on the > > > > > operation. > > > > > > > > > > A confirmed operation MUST be reverted if a confirming > > > > > commit is not issued within the timeout period (by default 600 > > > > > seconds = 10 minutes). The confirming commit is a operation > > > > > without the parameter. The timeout period can be > > > > > adjusted with the parameter. If a follow-up > > > > > confirmed operation is issued before the timer expires, the > > > > > timer is reset to the new value (600 seconds by default). Both the > > > > > confirming commit and a follow-up confirmed operation MAY > > > > > introduce additional changes to the configuration. > > > > > > > > > > If the element is not given in the confirmed commit > > > > > operation, any follow-up commit and the confirming commit MUST be > > > > > issued on the same session that issued the confirmed commit. If the > > > > > element is given in the confirmed operation, a > > > > > follow-up commit and the confirming commit can be given on any > > > > > session, and they MUST include a element with a value > > > > > equal to the given value of the element. > > > > > > > > > > If the server also advertises the :startup capability, a > > > > > from running to startup is also necessary to save the > > > > > changes to startup. > > > > > > > > > > If the session issuing the confirmed commit is terminated for any > > > > > reason before the confirm timeout expires, the server MUST restore > > > > > the configuration to its state before the confirmed commit was > > > > > issued, unless the confirmed commit also included a > > > > > element. > > > > > > > > > > If the device reboots for any reason before the confirm timeout > > > > > expires, the server MUST restore the configuration to its state > > > > > before the confirmed commit was issued. > > > > > > > > > > If a confirming commit is not issued, the device will revert its > > > > > configuration to the state prior to the issuance of the confirmed > > > > > commit. To cancel a confirmed commit and revert changes without > > > > > waiting for the confirm timeout to expire, the client can explicitly > > > > > restore the configuration to its state before the confirmed commit > > > > > was issued, by using the operation. > > > > > > > > > > Corrected Text > > > > > -------------- > > > > > 8.4.1. Description > > > > > > > > > > The :confirmed-commit:1.1 capability indicates that the server will > > > > > support the operation, the , > > > > timeout>, , and parameters for the > > > > > operation, and differentiate between a to be confirmed > > > > > operation (a confirmed commit) and a confirming > > > > > operation. See Section 8.3 for further details on the > > > > > operation. > > > > > > > > > > A confirmed operation MUST be reverted if a confirming > > > > > commit is not issued within the timeout period (by default 600 > > > > > seconds = 10 minutes). The confirming commit is a operation > > > > > without the parameter and, if successful, cannot be > > > > > reverted. The timeout period can be adjusted with the > > > > timeout> parameter. If a follow-up confirmed operation is > > > > > issued before the timer expires, the timer is reset to the new value > > > > > (600 seconds by default). Both the confirming commit and a follow-up > > > > > confirmed operation MAY introduce additional changes to the > > > > > configuration. > > > > > > > > > > If the element is not given in the confirmed commit > > > > > operation, any follow-up commit and the confirming commit MUST be > > > > > issued on the same session that issued the confirmed commit. If the > > > > > element is given in the confirmed operation, a > > > > > follow-up commit and the confirming commit can be given on any > > > > > session, and they MUST include a element with a value > > > > > equal to the given value of the element. > > > > > > > > > > If the server also advertises the :startup capability, a > > > > config> from running to startup is also necessary to save the > > > > > changes to startup. If the session issuing a sequence of one or more > > > > > confirmed commits is terminated for any reason before the confirm > > > > > timeout expires, the server MUST restore the configuration to its > > > > > state before the sequence of confirmed commits was issued, unless > > > > > the last confirmed commit also included a element. > > > > > > > > > > If the device reboots for any reason before the confirm timeout > > > > > expires, the server MUST restore the configuration to its state > > > > > before the sequence of confirmed commits was issued. > > > > > > > > > > If a confirming commit is not issued, the device will revert its > > > > > configuration to the state prior to the issuance of the first in the > > > > > current sequence of confirmed commits. To cancel the current > > > > > sequence of confirmed commits and revert changes without waiting for > > > > > the confirm timeout to expire, the client can explicitly restore the > > > > > configuration to its state before the sequence of confirmed commits > > > > > was issued, by using the operation. > > > > > > > > > > Notes > > > > > ----- > > > > > This erratum seeks to clarify the meaning of the term "confirmed > > > > > commit" for those not familiar with the use of the term within > > > > > JUNOS. In particular, that the use of "confirmed" is not in the sense > > > > > of the adjective (meaning "firmly established") but rather that the > > > > > commit needs to be confirmed. It also emphasises that a "confirming > > > > > commit" cannot be reverted. Finally it identifies that it is possible > > > > > to have a sequence of "confirmed commits" prior to a "confirming > > > > > commit" and that, should no "confirming commit" be received, the > > > > > configuration will revert to the state prior to the first "confirmed > > > > > commit" in the sequence. > > > > > > > > > > -------------------------------------- > > > > > RFC6241 (draft-ietf-netconf-4741bis-10) > > > > > -------------------------------------- > > > > > Title : Network Configuration Protocol (NETCONF) > > > > > Publication Date : June 2011 > > > > > Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., > > > > > A. Bierman, Ed. > > > > > Category : PROPOSED STANDARD > > > > > Source : Network Configuration > > > > > Area : Operations and Management > > > > > Stream : IETF > > > > > Verifying Party : IESG > > > > > > > > > _______________________________________________ > > > > 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 > > > > --5cb082e1_327b23c6_16b2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Re <persist> and <persist-i= d>, the point I was trying to get across is, since there can be a sequ= ence of commits after a confirmed commit and before the final confirming = commit, it would not necessarily be the last commit before session termin= ation that makes the confirmed commit persistent. Perhaps =22unless the l= ast confirmed commit also included a <persist> or <persist-id>= ; element=22 would be better worded as =22unless the confirmed commit was= persistent=22.

Jonathan

=3DO)
On 21 =46eb 2019, 13:48 +0000, Per = Hedeland <per=40hedeland.org>, wrote:
On 2019-02-21 14:22, Martin Bj= orklund wrote:
Hi,

Per Hedeland <per=40hedeland.org> wrote:
On 2019-02-20 01:44, Megan =46= erguson wrote:
Jonathan and Benoit,
We have edited the =22corrected text in this errata report as
suggested by Jonathan.

I don't know if this change - i.e. the addition of the text =22or
<persist-id>=22 in two places - should affect the status of the
document, but it seems to me that it can then no longer be considered
a =22clarification=22, since it proposes a change to the semantics
specified in R=46C 6241. As far as I can see, it is clear from 6241 that<= br /> the presence of the <persist-id> parameter does not affect the
persistence, only the presence of the <persist> parameter does that= .

Hmm, I missed this detail.

It is clearly not correct to say that the <persist-id> affects
persistence. So s/or <persist-id>// in the 4th and 5th paragraphs.<= br />

Hm, right, the remainder of the change to the 5th paragraph should be
kept (I originally misread it as *only* adding =22or <persist-id>=22= there
too).

Do you see any other issues wi= th the proposed text=3F

No, it seems fine - a useful clarification.

(An editorial change - the 4th= para should be split into two, just as
in the original text)

+1

--Per

/martin







=46urthermore, I'm afraid I fail to find any motivation for this change in the quoted message from Jonathan (as far as I can see, this message was not sent to the mailing list).

--Per Hedeland

We have left the status of thi= s report as Held for Document
Update.
Please let us know if any further action is necessary on our part.
The report itself is viewable at
https://www.rfc-editor.org/errata/eid3821.
Old (as in Jonathans original report):
If the session issuing a sequence of one or more
confirmed commits is terminated for any reason before the confirm
timeout expires, the server MUST restore the configuration to its
state before the sequence of confirmed commits was issued, unless
the last confirmed commit also included a <persist>
element.
If the device reboots for any reason before the confirm timeout
expires, the server MUST restore the configuration to its state
before the sequence of confirmed commits was issued.
New (as updated by Jonathans email - see the last line of both
paragraphs):
If the session issuing a sequence of one or more
confirmed commits is terminated for any reason before the confirm
timeout expires, the server MUST restore the configuration to its
state before the sequence of confirmed commits was issued, unless
the last confirmed commit also included a <persist> or <persist-= id>
element.
If the device reboots for any reason before the confirm timeout
expires, the server MUST restore the configuration to its state
before the sequence of confirmed commits was issued, unless the last
confirmed commit also included a <persist> or <persist-id> el= ement.
Thank you.
R=46C Editor/mf

Hi,
I raised erratum 3821 to clarify the meaning of the term =22confirmed
commit=22 for those not familiar with the use of the term within
JUNOS. Both the original text and the erratum include text that states If the device reboots for any reason before the confirm timeout
expires, the server MUST restore the configuration to its state before the sequence of confirmed commits was issued.. I have since
discovered the description of the persist leaf on page 102 that
includes the statement, A persistent confirmed commit is not aborted
if the NETCON=46 session terminates. The only way to abort a persistent confirmed commit is to let the timer expire, or to use the
<cancel-commit> operation. Consequently, the replacement text shoul= d
read:
8.4.1. Description
The :confirmed-commit:1.1 capability indicates that the server will
= support the <cancel-commit> operation, the <confirmed>, <c= onfirm-
timeout>, <persist>, and <persist-id> parameters for the &= lt;commit>
operation, and differentiate between a to be confirmed <commit>
operation (a confirmed commit) and a confirming <commit>
operation. See Section 8.3 for further details on the <commit>
operation.
A confirmed <commit> operation MUST be reverted if a confirming
commit is not issued within the timeout period (by default 600
seconds =3D 10 minutes). The confirming commit is a <commit> operat= ion
without the <confirmed> parameter and, if successful, cannot be
reverted. The timeout period can be adjusted with the <confirm-
timeout> parameter. If a follow-up confirmed <commit> operation = is
issued before the timer expires, the timer is reset to the new value
(600 seconds by default). Both the confirming commit and a follow-up
confirmed <commit> operation MAY introduce additional changes to th= e
configuration.
If the <persist> element is not given in the confirmed commit
= operation, any follow-up commit and the confirming commit MUST be
issued on the same session that issued the confirmed commit. If the
= <persist> element is given in the confirmed <commit> operatio= n, a
follow-up commit and the confirming commit can be given on any
session, and they MUST include a <persist-id> element with a value<= br /> equal to the given value of the <persist> element.
If the server also advertises the :startup capability, a <copy-
config> from running to startup is also necessary to save the
changes to startup. If the session issuing a sequence of one or more
confirmed commits is terminated for any reason before the confirm
timeout expires, the server MUST restore the configuration to its
state before the sequence of confirmed commits was issued, unless
the last confirmed commit also included a <persist> or <persist-= id>
element.
If the device reboots for any reason before the confirm timeout
expires, the server MUST restore the configuration to its state
before the sequence of confirmed commits was issued, unless the last
confirmed commit also included a <persist> or <persist-id> el= ement.
If a confirming commit is not issued, the device will revert its
configuration to the state prior to the issuance of the first in the
current sequence of confirmed commits. To cancel the current
sequence of confirmed commits and revert changes without waiting for
the confirm timeout to expire, the client can explicitly restore the
configuration to its state before the sequence of confirmed commits
= was issued, by using the <cancel-commit> operation.
Jonathan Hansford
On Jan 13, 2014, at 7:53 AM, R=46C Errata System
<rfc-editor=40rfc-editor.org> wrote:

The following errata report ha= s been held for document update
for R=46C6241, =22Network Configuration Protocol (NETCON=46)=22.

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata=5Fsearch.php=3Frfc=3D6241&eid=3D3821=

--------------------------------------
Status: Held for Document Update
Type: Editorial

Reported by: Jonathan Hansford <jonathan=40hansfords.net>
Date Reported: 2013-12-06
Held by: Benoit Claise (IESG)

Section: 8.4.1

Original Text
-------------
8.4.1. Description

The :confirmed-commit:1.1 capability indicates that the server will
= support the <cancel-commit> operation and the <confirmed>, <confirm-timeout>, <persist>, and <persist-id> paramete= rs for the
<commit> operation. See Section 8.3 for further details on the
<commit> operation.

A confirmed <commit> operation MUST be reverted if a confirming
commit is not issued within the timeout period (by default 600
seconds =3D 10 minutes). The confirming commit is a <commit> operat= ion
without the <confirmed> parameter. The timeout period can be
adjusted with the <confirm-timeout> parameter. If a follow-up
= confirmed <commit> operation is issued before the timer expires, th= e
timer is reset to the new value (600 seconds by default). Both the
confirming commit and a follow-up confirmed <commit> operation MAY<= br /> introduce additional changes to the configuration.

If the <persist> element is not given in the confirmed commit
= operation, any follow-up commit and the confirming commit MUST be
issued on the same session that issued the confirmed commit. If the
= <persist> element is given in the confirmed <commit> operatio= n, a
follow-up commit and the confirming commit can be given on any
session, and they MUST include a <persist-id> element with a value<= br /> equal to the given value of the <persist> element.

If the server also advertises the :startup capability, a
<copy-config> from running to startup is also necessary to save the=
changes to startup.

If the session issuing the confirmed commit is terminated for any
reason before the confirm timeout expires, the server MUST restore
the configuration to its state before the confirmed commit was
issued, unless the confirmed commit also included a <persist>
= element.

If the device reboots for any reason before the confirm timeout
expires, the server MUST restore the configuration to its state
before the confirmed commit was issued.

If a confirming commit is not issued, the device will revert its
configuration to the state prior to the issuance of the confirmed
commit. To cancel a confirmed commit and revert changes without
waiting for the confirm timeout to expire, the client can explicitly
restore the configuration to its state before the confirmed commit
was issued, by using the <cancel-commit> operation.

Corrected Text
--------------
8.4.1. Description

The :confirmed-commit:1.1 capability indicates that the server will
= support the <cancel-commit> operation, the <confirmed>, <c= onfirm-
timeout>, <persist>, and <persist-id> parameters for the &= lt;commit>
operation, and differentiate between a to be confirmed <commit>
operation (a confirmed commit) and a confirming <commit>
operation. See Section 8.3 for further details on the <commit>
operation.

A confirmed <commit> operation MUST be reverted if a confirming
commit is not issued within the timeout period (by default 600
seconds =3D 10 minutes). The confirming commit is a <commit> operat= ion
without the <confirmed> parameter and, if successful, cannot be
reverted. The timeout period can be adjusted with the <confirm-
timeout> parameter. If a follow-up confirmed <commit> operation = is
issued before the timer expires, the timer is reset to the new value
(600 seconds by default). Both the confirming commit and a follow-up
confirmed <commit> operation MAY introduce additional changes to th= e
configuration.

If the <persist> element is not given in the confirmed commit
= operation, any follow-up commit and the confirming commit MUST be
issued on the same session that issued the confirmed commit. If the
= <persist> element is given in the confirmed <commit> operatio= n, a
follow-up commit and the confirming commit can be given on any
session, and they MUST include a <persist-id> element with a value<= br /> equal to the given value of the <persist> element.

If the server also advertises the :startup capability, a <copy-
config> from running to startup is also necessary to save the
changes to startup. If the session issuing a sequence of one or more
confirmed commits is terminated for any reason before the confirm
timeout expires, the server MUST restore the configuration to its
state before the sequence of confirmed commits was issued, unless
the last confirmed commit also included a <persist> element.

If the device reboots for any reason before the confirm timeout
expires, the server MUST restore the configuration to its state
before the sequence of confirmed commits was issued.

If a confirming commit is not issued, the device will revert its
configuration to the state prior to the issuance of the first in the
current sequence of confirmed commits. To cancel the current
sequence of confirmed commits and revert changes without waiting for
the confirm timeout to expire, the client can explicitly restore the
configuration to its state before the sequence of confirmed commits
= was issued, by using the <cancel-commit> operation.

Notes
-----
This erratum seeks to clarify the meaning of the term =22confirmed
commit=22 for those not familiar with the use of the term within
JUNOS. In particular, that the use of =22confirmed=22 is not in the sense=
of the adjective (meaning =22firmly established=22) but rather that the commit needs to be confirmed. It also emphasises that a =22confirming
commit=22 cannot be reverted. =46inally it identifies that it is possible=
to have a sequence of =22confirmed commits=22 prior to a =22confirming commit=22 and that, should no =22confirming commit=22 be received, the configuration will revert to the state prior to the first =22confirmed commit=22 in the sequence.

--------------------------------------
R=46C6241 (draft-ietf-netconf-4741bis-10)
--------------------------------------
Title : Network Configuration Protocol (NETCON=46)
Publication Date : June 2011
Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed.,
= A. Bierman, Ed.
Category : PROPOSED STANDARD
Source : Network Configuration
Area : Operations and Management
Stream : IET=46
Verifying Party : IESG

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
netconf mailing list
netconf=40ietf.org
https://www.ietf.org/mailman/listinfo/netconf


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
netconf mailing list
netconf=40ietf.org
https://www.ietf.org/mailman/listinfo/netconf


--5cb082e1_327b23c6_16b2-- From nobody Fri Apr 12 08:02:01 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5990D1207F1; Fri, 12 Apr 2019 08:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdktLjOpeLov; Fri, 12 Apr 2019 08:01:56 -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 16C75120845; Fri, 12 Apr 2019 08:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37154; q=dns/txt; s=iport; t=1555081316; x=1556290916; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wJDNxwPDp+0W8DpDOLJMWiGe0Ofg7CKTBIg6fHcKT7g=; b=cj0feKyysI31JPtj3wUW+S2en9l5mP0uCHmzzClw+APQ9EnGkaBtss56 vyIq5tNJ+Eovb/G36aos6+8xxFPDo4FYmeXY9s/huzpGIeQVyOJjarpY1 0HFKuayFne1VbG9UlOb4plT9TUJp3Js2XPBuW38jTLyC52UgJZt8uLdxg E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BcAACTp7Bc/5hdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZYEPWCqBaxQUCoQElRElmkMOAQGEbQIXhV8jOBMBAwEBCgE?= =?us-ascii?q?CAQJtKIVLBiNPBQIQAgEIFRATBwMCAgIwFBECBA4FGoI9S4Eea60FgS+KLoE?= =?us-ascii?q?yi0cXgUA/gREnDBOBTn4+hEMYH4JUMYImA4pmgjqEM4dgjAtiCQKCBYloQYd?= =?us-ascii?q?oGoIHkmiMfI9/gnQCERWBMDYhKIEucBVlAYJBPoJwAQiNFUExj1GBIAEB?= X-IronPort-AV: E=Sophos;i="5.60,341,1549929600"; d="scan'208,217";a="257992074" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Apr 2019 15:01:55 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x3CF1sKl005262 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Apr 2019 15:01:54 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 12 Apr 2019 11:01:53 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1473.003; Fri, 12 Apr 2019 11:01:53 -0400 From: "Carlos Pignataro (cpignata)" To: "Eric Voit (evoit)" CC: "ops-dir@ietf.org" , "draft-ietf-netconf-subscribed-notifications.all@ietf.org" , "ietf@ietf.org" , "netconf@ietf.org" Thread-Topic: Opsdir last call review of draft-ietf-netconf-subscribed-notifications-23 Thread-Index: AQHU7xeskVwDPMWz+0mc9NXGW1eimKY1xCMAgAHs8YCAATUegA== Date: Fri, 12 Apr 2019 15:01:53 +0000 Message-ID: References: <155451947938.10151.12663725914439778891@ietfa.amsl.com> <3e994b49f5c2405cb72d1f0345c5e496@XCH-RTP-013.cisco.com> <87c35eec471440358c8ca99feee35ca5@XCH-RTP-013.cisco.com> In-Reply-To: <87c35eec471440358c8ca99feee35ca5@XCH-RTP-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.104.8) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.116.132] Content-Type: multipart/alternative; boundary="_000_B39C08ED173542AB8E5643210B271FD2ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.152, xch-rtp-012.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [netconf] Opsdir last call review of draft-ietf-netconf-subscribed-notifications-23 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 15:01:59 -0000 --_000_B39C08ED173542AB8E5643210B271FD2ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEVyaWMsDQoNClRoYW5rcyBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlLCBhbmQgZm9yIGNvbnNp ZGVyaW5nIHRoZXNlIGNvbW1lbnRzIQ0KDQpBIHRvcC1wb3N0IHJlc3BvbnNlIHRvIGFja25vd2xl ZGdlIHRoYXQgeW91ciBhcHByb2FjaCBvbiBib3RoIGlzc3VlcyBiZWxvdyBzZWVtcyBncmVhdCB0 byBtZS4gVGhhbmsgeW91IQ0KDQrigJQNCkNhcmxvcyBQaWduYXRhcm8sIGNhcmxvc0BjaXNjby5j b208bWFpbHRvOmNhcmxvc0BjaXNjby5jb20+DQoNCuKAnFNvbWV0aW1lcyBJIHVzZSBiaWcgd29y ZHMgdGhhdCBJIGRvIG5vdCBmdWxseSB1bmRlcnN0YW5kLCB0byBtYWtlIG15c2VsZiBzb3VuZCBt b3JlIHBob3Rvc3ludGhlc2lzLiINCg0KT24gQXByIDExLCAyMDE5LCBhdCA0OjM1IFBNLCBFcmlj IFZvaXQgKGV2b2l0KSA8ZXZvaXRAY2lzY28uY29tPG1haWx0bzpldm9pdEBjaXNjby5jb20+PiB3 cm90ZToNCg0KSGkgQ2FybG9zLA0KDQpGcm9tOiBDYXJsb3MgUGlnbmF0YXJvLCBBcHJpbCAxMCwg MjAxOSAxMToxMSBBTQ0KDQoNCkhpLCBFcmljLA0KDQpPbiBBcHIgOSwgMjAxOSwgYXQgNTowMyBQ TSwgRXJpYyBWb2l0IChldm9pdCkgPGV2b2l0QGNpc2NvLmNvbTxtYWlsdG86ZXZvaXRAY2lzY28u Y29tPj4gd3JvdGU6DQoNCkhpIENhcmxvcywNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiAgU29t ZSB0aG91Z2h0cyBpbi1saW5l4oCmDQoNCg0KVGhhbmtzIGZvciB0aGUgZm9sbG93LXVwLg0KDQoN CkZyb206IENhcmxvcyBQaWduYXRhcm8sIEFwcmlsIDUsIDIwMTkgMTA6NTggUE0NCg0KUmV2aWV3 ZXI6IENhcmxvcyBQaWduYXRhcm8NClJldmlldyByZXN1bHQ6IEhhcyBOaXRzDQoNCkhpLA0KDQpJ IGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBPcGVyYXRpb25hbCBk aXJlY3RvcmF0ZSdzIG9uZ29pbmcNCmVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRz IGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlDQpjb21tZW50cyB3ZXJlIHdyaXR0 ZW4gd2l0aCB0aGUgaW50ZW50IG9mIGltcHJvdmluZyB0aGUgb3BlcmF0aW9uYWwgYXNwZWN0cyBv Zg0KdGhlIElFVEYgZHJhZnRzLiBDb21tZW50cyB0aGF0IGFyZSBub3QgYWRkcmVzc2VkIGluIGxh c3QgY2FsbCBtYXkgYmUgaW5jbHVkZWQgaW4NCkFEIHJldmlld3MgZHVyaW5nIHRoZSBJRVNHIHJl dmlldy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQNCnRyZWF0IHRoZXNl IGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpTdW1t YXJ5OiBBbG1vc3QgUmVhZHkNCg0KVGhpcyBpcyBhIGNvbXByZWhlbnNpdmUgdmVyeSB3ZWxsIHdy aXR0ZW4gZG9jdW1lbnQuDQoNCg0KRnJvbSBhbiBvcGVyYXRpb25hbCBwb2ludCBvZiB2aWV3LCBh cyBwZXIgdGhlIG9wcy1kaXIgcmV2aWV3LCBJIGhhdmUgbm8NCmNvbmNlcm5zIG9yIGNvbW1lbnRz LiBNaWdodCBiZSBuaWNlIHRvIGNvbGxlY3Qgc29tZSBvZiB0aGUgb3BlcmF0aW9uYWwgcG9pbnRz DQppbiBhbiBPcGVyYXRpb25zIENvbnNpZGVyYXRpb24gc2VjdGlvbiwgcGFydGljdWxhcmx5IGdp dmVuIHRoZSBkb2N1bWVudA0Kc3RydWN0dXJlIG9mIFNlY3Rpb24gNS54LCAiWlpaIENvbnNpZGVy YXRpb25zIi4NCg0KSW4gImltcGxlbWVudGF0aW9uIGNvbnNpZGVyYXRpb25zIiB0aGVyZSBhcmUg YSBjb3VwbGUgd2hpY2ggYXJlIHJlYWxseSBvcGVyYXRpb25hbCBjb25zaWRlcmF0aW9ucy4gIEZv ciBleGFtcGxlIHRoZSBmaXJzdCBhbmQgdGhpcmQgYnVsbGV0cyBtaWdodCBxdWFsaWZ5IGFzIG9w ZXJhdGlvbmFsLiAgVGhlIGhhcmQgcGFydCBpcyB0aGF0IHRoZSBvcGVyYXRpb25hbCBjb25zaWRl cmF0aW9ucyB0byBleHBvc2Ugd2lsbCB2YXJ5IGJ5IHRoZSBzdWJzZXQgb2YgZmVhdHVyZSB3aGlj aCBhcmUgc2VsZWN0ZWQuICBTbyBJIGNhbiBpbWFnaW5lIHRoYXQgbXVjaCB0ZXh0IGNvdWxkIGJl IHdyaXR0ZW4gb24gYmVzdCBvcGVyYXRpb25hbCBwcmFjdGljZXMuICBJIGFtIGhvcGluZyB0aGF0 IHN1Y2ggZG9jdW1lbnRzIGNvdWxkIGZvbGxvdyB0aGlzIG9uZSBiYXNlZCBvbiBzcGVjaWZpYyBk ZXBsb3ltZW50IGNvbnRleHRzLg0KDQpTb3JyeSBJIHdhcyBub3QgZXhwbGljaXQuIFdoaWxlIG1h bnkgb2YgdGhlc2UgY29uc2lkZXJhdGlvbnMgaGF2ZSBvcGVyYXRpb25hbCBpbXBsaWNhdGlvbnMs IEkgbWVhbnQgdGhpbmdzIGxpa2UgQXBwZW5kaXggQSBvZiBSRkMgNTcwNiwgbW9yZSBkZXBsb3lt ZW50IHRoYW4gaW1wbGVtZW50YXRpb24uDQoNCjxlcmljPiBIaSBDYXJsb3MsDQpQZXIgb3VyIGNh bGwsIEkgcmVmaW5lZCB0aGUgc2VjdGlvbiBkZWZpbml0aW9uIHRvIOKAnEltcGxlbWVudGF0aW9u IGFuZCBEZXBsb3ltZW50IENvbnNpZGVyYXRpb25z4oCdLiAgIEkgZG8gYWdyZWUgdGhhdCBhIG51 bWJlciBvZiB0aGUgZWxlbWVudHMgZnJvbSBSRkMtNTcwNiBBcHBlbmRpeCBBIGFyZSBjb3ZlcmVk IGVsc2V3aGVyZSBhY3Jvc3Mgc3BlY2lmaWMgc2VjdGlvbnMgb2YgdGhlIGRvY3VtZW50Lg0KDQoN CkkgZG8gaGF2ZSBvbmUgaW1wb3J0YW50IHF1ZXN0aW9uIGZvciBjb25zaWRlcmF0aW9uLCB3aGlj aCBpczogd2hhdCBpcyAqcmVhbGx5Kg0KdGhlIHJlbGF0aW9uc2hpcCBvZiB0aGlzICgrIGRyYWZ0 LWlldGYtbmV0Y29uZi1uZXRjb25mLWV2ZW50LW5vdGlmaWNhdGlvbnMNCnBvdGVudGlhbGx5KSB3 aXRoIFJGQyA1Mjc3PyBBIE5vcm1hdGl2ZSByZWZlcmVuY2UsIHRoaXMgZG9jIGhhcyBubyBtZXRh ZGF0YQ0KcmVnYXJkaW5nIFVwZGF0aW5nLCBPYnNvbGV0aW5nLCBldGMuIFlldCBsb3RzIG9mIGl0 IGlzIGluZGVlZCBhIHN1cGVyc2V0IG9mIGl0Lg0KDQpXZSB3ZW50IGFyb3VuZCBhbmQgYXJvdW5k IGluIHRoZSBXRyBvbiB0aGlzIGZvciBhIGJpdC4gIFRoZSBpbml0aWFsIGRlY2lzaW9uIHdhcyB0 aGF0IHdlIHdlcmUgZ29pbmcgdG8gb2Jzb2xldGUgUkZDLTUyNzcuIEhvd2V2ZXIgdGhlIHByb2Js ZW0gd2FzIHRoYXQgUkZDLTUyNzcgU2VjdGlvbiA0IGhhcyBhIDxub3RpZmljYXRpb24+IGVsZW1l bnQgZGVmaW5lZCB3aGljaCB3ZSBhcmUgbm90IHJlcGxhY2luZyB5ZXQuIFRoaXMgPG5vdGlmaWNh dGlvbj4gaXMgdXNlZCBpbiBzZXZlcmFsIGltcG9ydGFudCBwbGFjZXMuICBFeGFtcGxlcyBpbmNs dWRlIFJGQy04MDQwIHNlY3Rpb24gNi40IGFuZCBSRkMtNzk1MCBTZWN0aW9uIDcuMTYuMi4NCg0K RG9lcyB0aGlzIGRlc2NyaWJlIGFuIFVwZGF0ZSBvZiBzcGVjaWZpYyBzZWN0aW9ucyB0aGVuPyBP ciB3b3VsZCB3YW50IHRvIGJyaW5nIGluIHRoZSBub3RpZmljYXRpb24gYW5kIGRvIGEgZnVsbCBi aXM/DQoNCjxlcmljPiBUaGUgV0cgdGFsa2VkIGFib3V0IHRoaXMgc2V2ZXJhbCB0aW1lcy4gIChJ biBmYWN0IHRoZSBhZG9wdGVkIGRyYWZ0IHdhcyBvcmlnaW5hbGx5IGRyYWZ0LWlldGYtbmV0Y29u Zi1yZmM1Mjc3YmlzLikgICAgQnV0IHdoZXJlIHdlIGVuZGVkIHVwIHdhcyB0aGF0IHdlIHdlcmUg bm90IHJlYWR5IHRvIGFzc2VydCBvYnNvbGVzY2VuY2UgdW50aWwgd2UgaGFkIHRoZSBuZXcgPG5v dGlmaWNhdGlvbj4gZWxlbWVudCBuYWlsZWQgZG93bi4gICBTbyBwcm9ncmVzc2luZyB0aGUgY3Vy cmVudCBzZXQgb2YgZHJhZnRzIGluIElFU0cgcmV2aWV3IGdhdmUgdXMgYSBnb29kIHN0ZXAgaW4g dGhhdCBkaXJlY3Rpb24uICBBbmQgd2hlbiB3ZSBoYXZlIHN0cnVjdHVyZWQgdGhpcyBkb2N1bWVu dCBzbyB0aGF0IHdoZW4gd2UgZG8gY29tcGxldGUgZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNh dGlvbi1tZXNzYWdlcywgdGhpbmdzIHNob3VsZCBpbnRlZ3JhdGUgY2xlYW5seS4gIFRoZSBoYXJk IHF1ZXN0aW9uIHdpbGwgYmUgaG93IHRvIGhhbmRsZSB0aGUgbWV0YS1yZWZlcmVuY2VzIHByb3Bl cmx5LiAgSSBiZWxpZXZlIHRoaXMgaXMgYmVzdCBhdHRlbXB0ZWQgd2hlbiBhbiBmdWxsIHNldCBv ZiBkb2N1bWVudHMgd2hpY2ggaXMgYWJsZSB0byBvYnNvbGV0ZSBSRkMtNTI3NyBpcyBhdmFpbGFi bGUuDQoNClNvIHdlIGRpZG4ndCB3YW50IHRvIHJlY29tbWVuZCBhbiBvYnNvbGV0ZSB3aXRob3V0 IGEgcmVwbGFjZW1lbnQgb2YgdGhhdCA8bm90aWZpY2F0aW9uPi4gIFRoZSBnb29kIG5ld3MgaXMg dGhhdCB3ZSBhcmUgd29ya2luZyBvbiBhIHJlcGxhY2VtZW50IGZvciB0aGlzIG5vdGlmaWNhdGlv bi4gIFNlZTogZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcyAgICAgQnV0 IHRoaXMgc3RpbGwgaGFzIGEgd2hpbGUgdG8gZ28gYmVmb3JlIGl0IGlzIHJlYWR5LiAgQXMgYSBy ZXN1bHQgd2UgYXJlIGxlZnQgd2l0aCBTZWN0aW9uIDEuNCBvZiBkcmFmdC1pZXRmLW5ldGNvbmYt c3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIHdoaWNoIGRlc2NyaWJlcyB0aGUgcmVsYXRpb25zaGlw IHdpdGggUkZDLTUyNzcuDQoNClRoaXMgaXMgc3RpbGwgc29tZXdoYXQgY29uZnVzaW5nLiBTZWN0 aW9uIDEuNCBzYXlzOg0KDQogICBUaGlzIGRvY3VtZW50IGlzIGludGVuZGVkIHRvIHByb3ZpZGUg YSBzdXBlcnNldCBvZiB0aGUgc3Vic2NyaXB0aW9uDQogICBjYXBhYmlsaXRpZXMgaW5pdGlhbGx5 IGRlZmluZWQgd2l0aGluIFtSRkM1Mjc3XS4NCg0KQnV0IGlmIGl0IGlzIHJlYWxseSBhIHN1cGVy c2V0LCBpcyBpdCBvYnNvbGV0aW5nIGl0Pw0KDQoNCjxlcmljPiBUaGUgc3Vic2NyaXB0aW9uIGNh cGFiaWxpdGllcyBhcmUgYSBzdXBlcnNldC4gIEkuZS4sIHRoZSBjb250cm9sIHBsYW5lIGNhbiBk byBldmVyeXRoaW5nIGluIFJGQy01Mjc3LiAgSG93ZXZlciB0aGUgPG5vdGlmaWNhdGlvbj4gZWxl bWVudCB3b3JrIHdhcyBkZWZlcnJlZC4NCg0KUzEuNCBmdXJ0aGVyIGdvZXM6DQoNCiAgIEVzcGVj aWFsbHkgd2hlbg0KICAgZXh0ZW5kaW5nIGFuIGV4aXN0aW5nIFtSRkM1Mjc3XSBpbXBsZW1lbnRh dGlvbiwgaXQgaXMgaW1wb3J0YW50IHRvDQogICB1bmRlcnN0YW5kIHdoYXQgaGFzIGJlZW4gcmV1 c2VkIGFuZCB3aGF0IGhhcyBiZWVuIHJlcGxhY2VkLg0KDQpTaW1pbGFybHksIHJldXNlK3JlcGxh Y2UgbWVhbnMgb2Jzb2xldGU/IE9yIHVwZGF0ZT8gOi0pDQoNCjxlcmljPiBGb3IgdGhlIHJlYXNv bnMgYWJvdmUsIG5vdCBvYnNvbGV0ZS4gIFBlcmhhcHMg4oCYdXBkYXRl4oCZIG1pZ2h0IGFwcGx5 LiAgQnV0IGhvbmVzdGx5IEkgZG9u4oCZdCBrbm93IHRoZSBtZXRhLXJlZmVyZW5jZSBjb252ZW50 aW9uIHdoZW4gdHdvIGRvY3VtZW50cyAoZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90 aWZpY2F0aW9ucyAmIGRyYWZ0LWlldGYtbmV0Y29uZi1uZXRjb25mLWV2ZW50LW5vdGlmaWNhdGlv bnMpIGltcHJvdmUgdXBvbiB0aGUgbWFqb3JpdHkgb2Ygd2hhdCBpcyBpbiBhbm90aGVyIGRvY3Vt ZW50IChSRkMtNTI3NykuICBGb3IgdGhhdCByZWFzb24sIGRvaW5nIG5vdGhpbmcgaW4gbWV0YS1y ZWZlcmVuY2luZyB1bnRpbCBhIGZ1bGwgZnVuY3Rpb25hbCByZXBsYWNlbWVudCB3YXMgYXZhaWxh YmxlIHNlZW1lZCBsaWtlIHRoZSBiZXN0IHBhdGguDQoNClRoYW5rcywNCkVyaWMNCg0KDQpJIHJl Y29tbWVuZCB0aGUgYXV0aG9ycytBRHMgY29uc2lkZXIgd2hldGhlciB0aGVyZSBpcyBhbnkgbW9y ZSBmb3JtYWwNCnJlbGF0aW9uc2hpcCB3aXRoIFJGQyA1Mjc3IHRoYXQgd291bGQgcmVxdWlyZSBt ZXRhLXRhZ2dpbmcgdGhlIFJGQy4NCg0KSSB0aGluayB0aGF0IHRoaXMgaXMgZnVsbHkgYXBwcm9w cmlhdGUgYXMgd2UgZmluaXNoIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2Fn ZXMNCg0KSSBkbyBub3QgdGhpbmsgeW91IG5lZWQgdG8gd2FpdCBmb3IgZHJhZnQtaWV0Zi1uZXRj b25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcyAoYW5kIGRlbGF5IGRyYWZ0LWlldGYtbmV0Y29uZi1z dWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMpIGluIG9yZGVyIHRvIGhhdmUgYW4gYXBwcm9wcmlhdGUg bWV0YS1yZWZlcmVuY2UuIFBlcmhhcHMgZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1t ZXNzYWdlcyB3aWxsIHVwZGF0ZSBzb21ldGhpbmcgKGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3Jp YmVkLW5vdGlmaWNhdGlvbnM/KQ0KDQpUaGFua3MsDQoNCkNhcmxvcy4NCg0KDQoNClRoYW5rcyEN CkVyaWMNCg0KDQpUaGFua3MsDQoNCkNhcmxvcyBQaWduYXRhcm8uDQoNCg0K --_000_B39C08ED173542AB8E5643210B271FD2ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <64B3FBEBD46B24438B1390B40D03A643@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpLCBFcmljLA0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzIGZvciB0aGUgcXVpY2sgcmVz cG9uc2UsIGFuZCBmb3IgY29uc2lkZXJpbmcgdGhlc2UgY29tbWVudHMhPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BIHRvcC1wb3N0IHJl c3BvbnNlIHRvIGFja25vd2xlZGdlIHRoYXQgeW91ciBhcHByb2FjaCBvbiBib3RoIGlzc3VlcyBi ZWxvdyBzZWVtcyBncmVhdCB0byBtZS4gVGhhbmsgeW91ITwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29y ZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGlu ZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCuKAlDxiciBjbGFzcz0iIj4N CkNhcmxvcyBQaWduYXRhcm8sJm5ic3A7PGEgaHJlZj0ibWFpbHRvOmNhcmxvc0BjaXNjby5jb20i IGNsYXNzPSIiPmNhcmxvc0BjaXNjby5jb208L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPGkgY2xhc3M9IiI+4oCcU29tZXRpbWVzIEkgdXNlIGJpZyB3b3JkcyB0aGF0IEkgZG8gbm90 IGZ1bGx5IHVuZGVyc3RhbmQsIHRvIG1ha2UgbXlzZWxmIHNvdW5kIG1vcmUgcGhvdG9zeW50aGVz aXMuJnF1b3Q7PC9pPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEFwciAx MSwgMjAxOSwgYXQgNDozNSBQTSwgRXJpYyBWb2l0IChldm9pdCkgJmx0OzxhIGhyZWY9Im1haWx0 bzpldm9pdEBjaXNjby5jb20iIGNsYXNzPSIiPmV2b2l0QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3Rl OjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7IGNhcmV0LWNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3Jh dGlvbjogbm9uZTsiIGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpIaSBDYXJsb3MsPG86cCBjbGFzcz0iIj48L286cD48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFz cz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTogbm9uZSBu b25lIG5vbmUgc29saWQ7IGJvcmRlci1sZWZ0LXdpZHRoOiAxLjVwdDsgYm9yZGVyLWxlZnQtY29s b3I6IGJsdWU7IHBhZGRpbmc6IDBpbiAwaW4gMGluIDRwdDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTogc29saWQgbm9uZSBub25lOyBib3JkZXIt dG9wLXdpZHRoOiAxcHQ7IGJvcmRlci10b3AtY29sb3I6IHJnYigyMjUsIDIyNSwgMjI1KTsgcGFk ZGluZzogM3B0IDBpbiAwaW47IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+RnJvbTo8L2I+PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkNhcmxvcyBQaWduYXRhcm8sIEFwcmlsIDEw LCAyMDE5IDExOjExIEFNPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0i Ij48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkhpLCBFcmljLDxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdp bi1ib3R0b206IDVwdDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KT24gQXByIDksIDIwMTksIGF0IDU6MDMgUE0s IEVyaWMgVm9pdCAoZXZvaXQpICZsdDs8YSBocmVmPSJtYWlsdG86ZXZvaXRAY2lzY28uY29tIiBz dHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0i Ij5ldm9pdEBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxv OnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OiA4LjVwdDsgZm9udC1mYW1pbHk6IE1lbmxvLVJlZ3VsYXIsIHNlcmlmOyIgY2xhc3M9IiI+SGkg Q2FybG9zLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoYW5rcyBmb3IgdGhlIHJldmll dy4gJm5ic3A7U29tZSB0aG91Z2h0cyBpbi1saW5l4oCmPGJyIHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDAsIDApOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFy dDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXNwYWNpbmc6IDBweDsiIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9k aXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0K VGhhbmtzIGZvciB0aGUgZm9sbG93LXVwLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IHdvcmQtc3BhY2luZzogMHB4OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyIgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDguNXB0OyBmb250LWZhbWlseTogTWVubG8tUmVndWxhciwgc2VyaWY7 IiBjbGFzcz0iIj5Gcm9tOiBDYXJsb3MgUGlnbmF0YXJvLCBBcHJpbCA1LCAyMDE5IDEwOjU4IFBN PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUmV2aWV3ZXI6IENhcmxvcyBQaWduYXRhcm88 YnIgY2xhc3M9IiI+DQpSZXZpZXcgcmVzdWx0OiBIYXMgTml0czxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCkhpLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgaGF2ZSByZXZpZXdl ZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIE9wZXJhdGlvbmFsIGRpcmVjdG9yYXRlJ3Mg b25nb2luZzxiciBjbGFzcz0iIj4NCmVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRz IGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gJm5ic3A7VGhlc2U8YnIgY2xhc3M9IiI+DQpj b21tZW50cyB3ZXJlIHdyaXR0ZW4gd2l0aCB0aGUgaW50ZW50IG9mIGltcHJvdmluZyB0aGUgb3Bl cmF0aW9uYWwgYXNwZWN0cyBvZjxiciBjbGFzcz0iIj4NCnRoZSBJRVRGIGRyYWZ0cy4gQ29tbWVu dHMgdGhhdCBhcmUgbm90IGFkZHJlc3NlZCBpbiBsYXN0IGNhbGwgbWF5IGJlIGluY2x1ZGVkIGlu PGJyIGNsYXNzPSIiPg0KQUQgcmV2aWV3cyBkdXJpbmcgdGhlIElFU0cgcmV2aWV3LiAmbmJzcDtE b2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkPGJyIGNsYXNzPSIiPg0KdHJlYXQg dGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU3VtbWFyeTogQWxtb3N0IFJlYWR5PGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhpcyBpcyBhIGNvbXByZWhlbnNpdmUgdmVyeSB3ZWxsIHdy aXR0ZW4gZG9jdW1lbnQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7IiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogOC41cHQ7IGZvbnQtZmFtaWx5OiBNZW5sby1SZWd1bGFyLCBzZXJpZjsiIGNsYXNzPSIiPkZy b20gYW4gb3BlcmF0aW9uYWwgcG9pbnQgb2YgdmlldywgYXMgcGVyIHRoZSBvcHMtZGlyIHJldmll dywgSSBoYXZlIG5vPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDguNXB0OyBmb250LWZhbWlseTogTWVubG8tUmVndWxhciwgc2VyaWY7 IiBjbGFzcz0iIj5jb25jZXJucyBvciBjb21tZW50cy4gTWlnaHQgYmUgbmljZSB0byBjb2xsZWN0 IHNvbWUgb2YgdGhlIG9wZXJhdGlvbmFsIHBvaW50czxiciBjbGFzcz0iIj4NCmluIGFuIE9wZXJh dGlvbnMgQ29uc2lkZXJhdGlvbiBzZWN0aW9uLCBwYXJ0aWN1bGFybHkgZ2l2ZW4gdGhlIGRvY3Vt ZW50PGJyIGNsYXNzPSIiPg0Kc3RydWN0dXJlIG9mIFNlY3Rpb24gNS54LCAmcXVvdDtaWlogQ29u c2lkZXJhdGlvbnMmcXVvdDsuPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDguNXB0OyBmb250LWZhbWlseTogTWVubG8tUmVndWxhciwg c2VyaWY7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpJbiAmcXVvdDtpbXBsZW1lbnRhdGlvbiBj b25zaWRlcmF0aW9ucyZxdW90OyB0aGVyZSBhcmUgYSBjb3VwbGUgd2hpY2ggYXJlIHJlYWxseSBv cGVyYXRpb25hbCBjb25zaWRlcmF0aW9ucy4gJm5ic3A7Rm9yIGV4YW1wbGUgdGhlIGZpcnN0IGFu ZCB0aGlyZCBidWxsZXRzIG1pZ2h0IHF1YWxpZnkgYXMgb3BlcmF0aW9uYWwuICZuYnNwO1RoZSBo YXJkIHBhcnQgaXMgdGhhdCB0aGUgb3BlcmF0aW9uYWwgY29uc2lkZXJhdGlvbnMgdG8gZXhwb3Nl IHdpbGwgdmFyeSBieSB0aGUgc3Vic2V0DQogb2YgZmVhdHVyZSB3aGljaCBhcmUgc2VsZWN0ZWQu ICZuYnNwO1NvIEkgY2FuIGltYWdpbmUgdGhhdCBtdWNoIHRleHQgY291bGQgYmUgd3JpdHRlbiBv biBiZXN0IG9wZXJhdGlvbmFsIHByYWN0aWNlcy4gJm5ic3A7SSBhbSBob3BpbmcgdGhhdCBzdWNo IGRvY3VtZW50cyBjb3VsZCBmb2xsb3cgdGhpcyBvbmUgYmFzZWQgb24gc3BlY2lmaWMgZGVwbG95 bWVudCBjb250ZXh0cy48L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNz PSIiPg0KU29ycnkgSSB3YXMgbm90IGV4cGxpY2l0LiBXaGlsZSBtYW55IG9mIHRoZXNlIGNvbnNp ZGVyYXRpb25zIGhhdmUgb3BlcmF0aW9uYWwgaW1wbGljYXRpb25zLCBJIG1lYW50IHRoaW5ncyBs aWtlIEFwcGVuZGl4IEEgb2YgUkZDIDU3MDYsIG1vcmUgZGVwbG95bWVudCB0aGFuIGltcGxlbWVu dGF0aW9uLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0K PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDAuNWluIDAuMDAwMXB0IDBpbjsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJmx0O2VyaWMmZ3Q7IEhpIENhcmxvcyw8bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMC41aW4gMC4wMDAx cHQgMGluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+DQpQZXIgb3VyIGNhbGwsIEkgcmVmaW5lZCB0aGUgc2VjdGlvbiBkZWZpbml0 aW9uIHRvIOKAnEltcGxlbWVudGF0aW9uIGFuZCBEZXBsb3ltZW50IENvbnNpZGVyYXRpb25z4oCd LiZuYnNwOyZuYnNwOyBJIGRvIGFncmVlIHRoYXQgYSBudW1iZXIgb2YgdGhlIGVsZW1lbnRzIGZy b20gUkZDLTU3MDYgQXBwZW5kaXggQSBhcmUgY292ZXJlZCBlbHNld2hlcmUgYWNyb3NzIHNwZWNp ZmljIHNlY3Rpb25zIG9mIHRoZSBkb2N1bWVudC48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOiA4LjVwdDsgZm9udC1mYW1pbHk6IE1lbmxvLVJlZ3VsYXIsIHNlcmlmOyIgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9zcGFuPjxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4t Ym90dG9tOiA1cHQ7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOC41cHQ7IGZvbnQtZmFtaWx5OiBN ZW5sby1SZWd1bGFyLCBzZXJpZjsiIGNsYXNzPSIiPkkgZG8gaGF2ZSBvbmUgaW1wb3J0YW50IHF1 ZXN0aW9uIGZvciBjb25zaWRlcmF0aW9uLCB3aGljaCBpczogd2hhdCBpcyAqcmVhbGx5KjxiciBj bGFzcz0iIj4NCnRoZSByZWxhdGlvbnNoaXAgb2YgdGhpcyAoJiM0MzsgZHJhZnQtaWV0Zi1uZXRj b25mLW5ldGNvbmYtZXZlbnQtbm90aWZpY2F0aW9uczxiciBjbGFzcz0iIj4NCnBvdGVudGlhbGx5 KSB3aXRoIFJGQyA1Mjc3PyBBIE5vcm1hdGl2ZSByZWZlcmVuY2UsIHRoaXMgZG9jIGhhcyBubyBt ZXRhZGF0YTxiciBjbGFzcz0iIj4NCnJlZ2FyZGluZyBVcGRhdGluZywgT2Jzb2xldGluZywgZXRj LiBZZXQgbG90cyBvZiBpdCBpcyBpbmRlZWQgYSBzdXBlcnNldCBvZiBpdC48bzpwIGNsYXNzPSIi PjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOC41cHQ7IGZv bnQtZmFtaWx5OiBNZW5sby1SZWd1bGFyLCBzZXJpZjsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CldlIHdlbnQgYXJvdW5kIGFuZCBhcm91bmQgaW4gdGhlIFdHIG9uIHRoaXMgZm9yIGEgYml0LiAm bmJzcDtUaGUgaW5pdGlhbCBkZWNpc2lvbiB3YXMgdGhhdCB3ZSB3ZXJlIGdvaW5nIHRvIG9ic29s ZXRlIFJGQy01Mjc3LiBIb3dldmVyIHRoZSBwcm9ibGVtIHdhcyB0aGF0IFJGQy01Mjc3IFNlY3Rp b24gNCBoYXMgYSAmbHQ7bm90aWZpY2F0aW9uJmd0OyBlbGVtZW50IGRlZmluZWQgd2hpY2ggd2Ug YXJlIG5vdCByZXBsYWNpbmcgeWV0LiBUaGlzICZsdDtub3RpZmljYXRpb24mZ3Q7DQogaXMgdXNl ZCBpbiBzZXZlcmFsIGltcG9ydGFudCBwbGFjZXMuICZuYnNwO0V4YW1wbGVzIGluY2x1ZGUgUkZD LTgwNDAgc2VjdGlvbiA2LjQgYW5kIFJGQy03OTUwIFNlY3Rpb24gNy4xNi4yLjwvc3Bhbj48bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj4NCkRvZXMgdGhpcyBkZXNjcmliZSBhbiBVcGRhdGUgb2Ygc3Bl Y2lmaWMgc2VjdGlvbnMgdGhlbj8gT3Igd291bGQgd2FudCB0byBicmluZyBpbiB0aGUgbm90aWZp Y2F0aW9uIGFuZCBkbyBhIGZ1bGwgYmlzPzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZsdDtl cmljJmd0OyBUaGUgV0cgdGFsa2VkIGFib3V0IHRoaXMgc2V2ZXJhbCB0aW1lcy4mbmJzcDsgKElu IGZhY3QgdGhlIGFkb3B0ZWQgZHJhZnQgd2FzIG9yaWdpbmFsbHkgZHJhZnQtaWV0Zi1uZXRjb25m LXJmYzUyNzdiaXMuKSAmbmJzcDsmbmJzcDsmbmJzcDtCdXQgd2hlcmUgd2UgZW5kZWQgdXAgd2Fz IHRoYXQgd2Ugd2VyZSBub3QgcmVhZHkgdG8gYXNzZXJ0IG9ic29sZXNjZW5jZSB1bnRpbCB3ZSBo YWQgdGhlIG5ldyAmbHQ7bm90aWZpY2F0aW9uJmd0OyBlbGVtZW50IG5haWxlZCBkb3duLiZuYnNw OyZuYnNwOyBTbw0KIHByb2dyZXNzaW5nIHRoZSBjdXJyZW50IHNldCBvZiBkcmFmdHMgaW4gSUVT RyByZXZpZXcgZ2F2ZSB1cyBhIGdvb2Qgc3RlcCBpbiB0aGF0IGRpcmVjdGlvbi4mbmJzcDsgQW5k IHdoZW4gd2UgaGF2ZSBzdHJ1Y3R1cmVkIHRoaXMgZG9jdW1lbnQgc28gdGhhdCB3aGVuIHdlIGRv IGNvbXBsZXRlIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMsIHRoaW5n cyBzaG91bGQgaW50ZWdyYXRlIGNsZWFubHkuJm5ic3A7IFRoZSBoYXJkIHF1ZXN0aW9uDQogd2ls bCBiZSBob3cgdG8gaGFuZGxlIHRoZSBtZXRhLXJlZmVyZW5jZXMgcHJvcGVybHkuJm5ic3A7IEkg YmVsaWV2ZSB0aGlzIGlzIGJlc3QgYXR0ZW1wdGVkIHdoZW4gYW4gZnVsbCBzZXQgb2YgZG9jdW1l bnRzIHdoaWNoIGlzIGFibGUgdG8gb2Jzb2xldGUgUkZDLTUyNzcgaXMgYXZhaWxhYmxlLjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7IiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDguNXB0OyBmb250LWZhbWlseTogTWVubG8tUmVn dWxhciwgc2VyaWY7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpTbyB3ZSBkaWRuJ3Qgd2FudCB0 byByZWNvbW1lbmQgYW4gb2Jzb2xldGUgd2l0aG91dCBhIHJlcGxhY2VtZW50IG9mIHRoYXQgJmx0 O25vdGlmaWNhdGlvbiZndDsuICZuYnNwO1RoZSBnb29kIG5ld3MgaXMgdGhhdCB3ZSBhcmUgd29y a2luZyBvbiBhIHJlcGxhY2VtZW50IGZvciB0aGlzIG5vdGlmaWNhdGlvbi4gJm5ic3A7U2VlOiBk cmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO0J1dCB0aGlzIHN0aWxsIGhhcyBhIHdoaWxlIHRvIGdvIGJlZm9yZQ0KIGl0IGlzIHJl YWR5LiAmbmJzcDtBcyBhIHJlc3VsdCB3ZSBhcmUgbGVmdCB3aXRoIFNlY3Rpb24gMS40IG9mIGRy YWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMgd2hpY2ggZGVzY3JpYmVz IHRoZSByZWxhdGlvbnNoaXAgd2l0aCBSRkMtNTI3Ny48L3NwYW4+PG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8 L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KVGhpcyBpcyBzdGlsbCBzb21ld2hhdCBjb25mdXNpbmcu IFNlY3Rpb24gMS40IHNheXM6PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0K PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij4NCiZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IGlzIGludGVuZGVkIHRvIHByb3ZpZGUgYSBz dXBlcnNldCBvZiB0aGUgc3Vic2NyaXB0aW9uPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs YXNzPSIiPg0KJm5ic3A7ICZuYnNwO2NhcGFiaWxpdGllcyBpbml0aWFsbHkgZGVmaW5lZCB3aXRo aW4gW1JGQzUyNzddLiAmbmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CkJ1dCBpZiBpdCBpcyByZWFsbHkgYSBzdXBlcnNldCwgaXMgaXQgb2Jzb2xldGluZyBpdD88c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0i Ij48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi Pg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJmx0O2VyaWMmZ3Q7 IFRoZSBzdWJzY3JpcHRpb24gY2FwYWJpbGl0aWVzIGFyZSBhIHN1cGVyc2V0LiZuYnNwOyBJLmUu LCB0aGUgY29udHJvbCBwbGFuZSBjYW4gZG8gZXZlcnl0aGluZyBpbiBSRkMtNTI3Ny4mbmJzcDsg SG93ZXZlciB0aGUgJmx0O25vdGlmaWNhdGlvbiZndDsgZWxlbWVudCB3b3JrIHdhcyBkZWZlcnJl ZC48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpTMS40IGZ1cnRoZXIgZ29lczo8 bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNw OzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7RXNwZWNpYWxseSB3aGVuPG86 cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO2V4dGVuZGlu ZyBhbiBleGlzdGluZyBbUkZDNTI3N10gaW1wbGVtZW50YXRpb24sIGl0IGlzIGltcG9ydGFudCB0 bzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7dW5kZXJzdGFuZCB3 aGF0IGhhcyBiZWVuIHJldXNlZCBhbmQgd2hhdCBoYXMgYmVlbiByZXBsYWNlZC4mbmJzcDs8bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNpbWlsYXJseSwgcmV1c2UmIzQzO3Jl cGxhY2UgbWVhbnMgb2Jzb2xldGU/IE9yIHVwZGF0ZT8gOi0pPG86cCBjbGFzcz0iIj48L286cD48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBj bGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw LjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiIGNsYXNzPSIiPg0KJmx0O2VyaWMmZ3Q7IEZvciB0aGUgcmVhc29ucyBhYm92ZSwgbm90IG9i c29sZXRlLiZuYnNwOyBQZXJoYXBzIOKAmHVwZGF0ZeKAmSBtaWdodCBhcHBseS4mbmJzcDsgQnV0 IGhvbmVzdGx5IEkgZG9u4oCZdCBrbm93IHRoZSBtZXRhLXJlZmVyZW5jZSBjb252ZW50aW9uIHdo ZW4gdHdvIGRvY3VtZW50cyAoZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0 aW9ucyAmYW1wOyBkcmFmdC1pZXRmLW5ldGNvbmYtbmV0Y29uZi1ldmVudC1ub3RpZmljYXRpb25z KSBpbXByb3ZlIHVwb24NCiB0aGUgbWFqb3JpdHkgb2Ygd2hhdCBpcyBpbiBhbm90aGVyIGRvY3Vt ZW50IChSRkMtNTI3NykuJm5ic3A7IEZvciB0aGF0IHJlYXNvbiwgZG9pbmcgbm90aGluZyBpbiBt ZXRhLXJlZmVyZW5jaW5nIHVudGlsIGEgZnVsbCBmdW5jdGlvbmFsIHJlcGxhY2VtZW50IHdhcyBh dmFpbGFibGUgc2VlbWVkIGxpa2UgdGhlIGJlc3QgcGF0aC48bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+DQpUaGFua3MsPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KRXJpYzxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdCA1 LjI1cHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDguNXB0OyBmb250LWZhbWlseTog TWVubG8tUmVndWxhciwgc2VyaWY7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQo8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsiIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0 b206IDVwdDsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0 OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA4LjVwdDsgZm9udC1mYW1pbHk6IE1lbmxv LVJlZ3VsYXIsIHNlcmlmOyIgY2xhc3M9IiI+SSByZWNvbW1lbmQgdGhlIGF1dGhvcnMmIzQzO0FE cyBjb25zaWRlciB3aGV0aGVyIHRoZXJlIGlzIGFueSBtb3JlIGZvcm1hbDxiciBjbGFzcz0iIj4N CnJlbGF0aW9uc2hpcCB3aXRoIFJGQyA1Mjc3IHRoYXQgd291bGQgcmVxdWlyZSBtZXRhLXRhZ2dp bmcgdGhlIFJGQy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogOC41cHQ7IGZvbnQtZmFtaWx5OiBNZW5sby1SZWd1bGFyLCBzZXJpZjsi IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCkkgdGhpbmsgdGhhdCB0aGlzIGlzIGZ1bGx5IGFwcHJv cHJpYXRlIGFzIHdlIGZpbmlzaCBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3Nh Z2VzPC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KSSBkbyBub3QgdGhpbmsgeW91IG5l ZWQgdG8gd2FpdCBmb3IgZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcyZu YnNwOyhhbmQgZGVsYXkgZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9u cykgaW4gb3JkZXIgdG8gaGF2ZSBhbiBhcHByb3ByaWF0ZSBtZXRhLXJlZmVyZW5jZS4gUGVyaGFw cyZuYnNwO2RyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMgd2lsbCB1cGRh dGUgc29tZXRoaW5nIChkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25z Pyk8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZu YnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpUaGFua3MsPG86cCBjbGFzcz0iIj48L286cD48 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNz PSIiPg0KQ2FybG9zLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7IiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDguNXB0OyBmb250LWZhbWlseTogTWVu bG8tUmVndWxhciwgc2VyaWY7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpUaGFua3MhPGJyIGNs YXNzPSIiPg0KRXJpYzxiciBjbGFzcz0iIj4NCjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC1zcGFjaW5nOiAwcHg7IiBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyIgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDguNXB0OyBmb250LWZhbWlseTogTWVubG8tUmVndWxhciwgc2Vy aWY7IiBjbGFzcz0iIj5UaGFua3MsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQ2FybG9z IFBpZ25hdGFyby48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B39C08ED173542AB8E5643210B271FD2ciscocom_-- From nobody Fri Apr 12 12:24:35 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B291012079D; Fri, 12 Apr 2019 12:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Q2Cz3cvC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=b1XFeJCH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IaVjx_P3PPa; Fri, 12 Apr 2019 12:24:26 -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 27AB51201B6; Fri, 12 Apr 2019 12:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3610; q=dns/txt; s=iport; t=1555097066; x=1556306666; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=i+VBpf1fY8FTxn+MfRaTJxuG6ivPBqJRRZ9gcz0SSfw=; b=Q2Cz3cvC99ayDsa5GCmHgTcaks5lzLc18iFW4ZUAACY4GmtISzyHyg0O q4pLTQ8FLVKX17N/p4uwdealHB+Ip8EsJRejlE5yAPvxvDmXO31eIeUyI 9o4ZRcHHJ6fq6AHU8KMkVe/Ihey2yAdHqf7mTMT0WjwWmThfYJwhf4469 c=; IronPort-PHdr: =?us-ascii?q?9a23=3AfWin8hR9fCeaXdx3cSt5prEXyNpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBdfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjYgFcRHXVlN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BJAAC85bBc/4sNJK1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgT0kBScDaFQgBAsohA6DRwOEUopEgjKXP4EugSQDVA4BASU?= =?us-ascii?q?IhEACF4VfIzQJDgEDAQEKAQIBAm0cDIVLBiMRDAEBNwEPAgEIDgwCJgICAjA?= =?us-ascii?q?VEAIEAQ0FgldLAYFpAxwBAgyhbAKKFHGBL4J5AQEFgTUCg00Ygg0DBoELJwG?= =?us-ascii?q?LSBeBQD+BOAwTgkw+gmEBAQIBgXWCczGCJosbggqZBAkCggWGCIhIg0Qaggi?= =?us-ascii?q?GGoxQi2KGKo1qAgQCBAUCDgEBBYFPOIFWcBU7KgGCQYIKgSQBB4JDhRSFP3K?= =?us-ascii?q?BKY9IAQE?= X-IronPort-AV: E=Sophos;i="5.60,342,1549929600"; d="scan'208";a="259157396" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Apr 2019 19:24:10 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x3CJOA9g001387 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Apr 2019 19:24:10 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 12 Apr 2019 14:24:09 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 12 Apr 2019 14:24:09 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 12 Apr 2019 14:24:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i+VBpf1fY8FTxn+MfRaTJxuG6ivPBqJRRZ9gcz0SSfw=; b=b1XFeJCHwHsYONJ4gRYXLBinVl28bVyezz9tinE3hagqMpUgliCL4Q78VYD9RzR4i/ZRsUqN+/jsbkt8IU3d/tXMybRYFrH7Da3iXGyItGjkMz0t04OlzaXPcqRDRoQX4vnGQ8i/VhormrkBD9D0KxmqJgaoQeSE5gBclWLfYjw= Received: from MN2PR11MB3695.namprd11.prod.outlook.com (20.178.252.156) by MN2PR11MB3997.namprd11.prod.outlook.com (10.255.181.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.19; Fri, 12 Apr 2019 19:24:07 +0000 Received: from MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::8467:9ef7:d982:e972]) by MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::8467:9ef7:d982:e972%3]) with mapi id 15.20.1771.021; Fri, 12 Apr 2019 19:24:07 +0000 From: "Reshad Rahman (rrahman)" To: Wesley Eddy , "tsv-art@ietf.org" CC: "netconf@ietf.org" , "ietf@ietf.org" , "draft-ietf-netconf-restconf-notif.all@ietf.org" Thread-Topic: Tsvart last call review of draft-ietf-netconf-restconf-notif-13 Thread-Index: AQHU6XMl1tCspDTGH06mi47K3kgElqY4tKGA Date: Fri, 12 Apr 2019 19:24:06 +0000 Message-ID: <5C1FC2C9-6502-4BE1-A874-705A6BBA571B@cisco.com> References: <155422336508.6258.5897033458248231423@ietfa.amsl.com> In-Reply-To: <155422336508.6258.5897033458248231423@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.6.190114 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [2001:420:2840:1250:2421:2f0a:1dbc:638e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1f4a6403-6944-4fcb-0343-08d6bf7c6e93 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR11MB3997; x-ms-traffictypediagnostic: MN2PR11MB3997: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0005B05917 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(366004)(136003)(396003)(189003)(199004)(106356001)(99286004)(229853002)(105586002)(2616005)(2501003)(83716004)(36756003)(7736002)(6506007)(71200400001)(14454004)(102836004)(305945005)(25786009)(81156014)(97736004)(68736007)(76176011)(81166006)(8936002)(71190400001)(82746002)(86362001)(6436002)(6246003)(33656002)(6512007)(11346002)(6486002)(46003)(8676002)(478600001)(2906002)(6306002)(486006)(186003)(256004)(4326008)(316002)(5660300002)(476003)(54906003)(446003)(58126008)(110136005)(6116002)(53936002)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3997; H:MN2PR11MB3695.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 2ScvSBJ22vbRDEe6LAkSOWgk+kry95L9Xm8svKdde71uwH6v7ursmOzih2zNl17kqwQeGLdmSOuo9Wd5HdBlFEy7xlk2sLfv6Scu0+wbPc/HXW2CwJ69VKH92sVWZx3Lyh86zZ2bVpAYKwessCag282DC2kfh6xdR8ytRJe+l3gNPnVpH0kr99k2OElyprRHni7bxhl+doCftMGHJsBtWf7+7EIUKroWTVTY7fQg114DryX4/dcC9hZkhLntSLsj9JgMSCE4j+vtjMWjVHP/UxJHXs37SoHUsy2omIP/SEb42vUu5EwJw0wmjHIFngRz94LFyF26YYqDqhCeFsr5ge5xuOALPKQ0oD4GsfeWhXMlhztNZFQTtOBw/8LKkL0mH8QInK8b3kdjfRgiGKjDrM5+KB7sr2duB+YUV0gD0mY= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1f4a6403-6944-4fcb-0343-08d6bf7c6e93 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 19:24:06.9430 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3997 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.26, xch-rcd-016.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [netconf] Tsvart last call review of draft-ietf-netconf-restconf-notif-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 19:24:29 -0000 SGkgV2VzbGV5LA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcsIHBsZWFzZSBzZWUgaW5saW5l Lg0KDQoNCu+7v09uIDIwMTktMDQtMDIsIDEyOjQzIFBNLCAiV2VzbGV5IEVkZHkgdmlhIERhdGF0 cmFja2VyIiA8bm9yZXBseUBpZXRmLm9yZz4gd3JvdGU6DQoNCiAgICBSZXZpZXdlcjogV2VzbGV5 IEVkZHkNCiAgICBSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIElzc3Vlcw0KICAgIA0KICAgIFRo aXMgZG9jdW1lbnQgaGFzIGJlZW4gcmV2aWV3ZWQgYXMgcGFydCBvZiB0aGUgdHJhbnNwb3J0IGFy ZWEgcmV2aWV3IHRlYW0ncw0KICAgIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBrZXkgSUVURiBk b2N1bWVudHMuIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbg0KICAgIHByaW1hcmlseSBmb3Ig dGhlIHRyYW5zcG9ydCBhcmVhIGRpcmVjdG9ycywgYnV0IGFyZSBjb3BpZWQgdG8gdGhlIGRvY3Vt ZW50J3MNCiAgICBhdXRob3JzIGFuZCBXRyB0byBhbGxvdyB0aGVtIHRvIGFkZHJlc3MgYW55IGlz c3VlcyByYWlzZWQgYW5kIGFsc28gdG8gdGhlIElFVEYNCiAgICBkaXNjdXNzaW9uIGxpc3QgZm9y IGluZm9ybWF0aW9uLg0KICAgIA0KICAgIFdoZW4gZG9uZSBhdCB0aGUgdGltZSBvZiBJRVRGIExh c3QgQ2FsbCwgdGhlIGF1dGhvcnMgc2hvdWxkIGNvbnNpZGVyIHRoaXMNCiAgICByZXZpZXcgYXMg cGFydCBvZiB0aGUgbGFzdC1jYWxsIGNvbW1lbnRzIHRoZXkgcmVjZWl2ZS4gUGxlYXNlIGFsd2F5 cyBDQw0KICAgIHRzdi1hcnRAaWV0Zi5vcmcgaWYgeW91IHJlcGx5IHRvIG9yIGZvcndhcmQgdGhp cyByZXZpZXcuDQogICAgDQogICAgSSByZXZpZXdlZCB0aGlzIGluIGNvbmp1bmN0aW9uIHdpdGgg dGhlIHNldCBvZiByZWxhdGVkIFdHIGRvY3VtZW50cyBvbg0KICAgIE5FVENPTkYvUkVTVENPTkYg c3Vic2NyaXB0aW9ucyBhbmQgZXZlbnQgbm90aWZpY2F0aW9ucy4gICBJIGhhdmUgY29tbWVudHMg dGhhdA0KICAgIHdpbGwgYmUgc2VudCBvbiBvdGhlciBkb2N1bWVudHMgaW4gdGhlIHNldCwgc29t ZSBvZiB3aGljaCBtYXkgaW5mbHVlbmNlIHRoaXMNCiAgICBvbmNlLCBzaW5jZSB0aGV5IGFyZSBj bG9zZWx5IHJlbGF0ZWQuDQogICAgDQogICAgRmlndXJlIDMgc2hvd3MgYSBEU0NQIHZhbHVlIG9m IDEwLCBidXQgaXQgaXNuJ3QgY2xlYXIgd2hhdCB0aGUgbnVtYmVyIGJhc2UgaXMNCiAgICBzdXBw b3NlZCB0byBiZSwgYW5kIHRoaXMgc2hvdWxkIGJlIHNwZWNpZmllZCBmb3IgdGhpcyBwcm90b2Nv bCwgc2luY2UgbWFueQ0KICAgIGV4YW1wbGVzIGNhbiBiZSBmb3VuZCBpbiBvdGhlciBtYXRlcmlh bCBvZiBEU0NQIHZhbHVlcyBpbmRpY2F0ZWQgaW4gYmluYXJ5LA0KICAgIGRlY2ltYWwsIG9yIGhl eGFkZWNpbWFsLg0KVGhlIGxlYWYgImRzY3AiIGlzIGZyb20gaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMtMjMjcGFn ZS00NSwgYW5kIGluZXQ6ZHNjcCBpcyBhIHVpbnQ4IHJhbmdlICIwLi42MyIuIFRoZSBleGFtcGxl IGluIEZpZ3VyZSAzIHVzZXMgSlNPTiBlbmNvZGluZywgd2UncmUgZm9sbG93aW5nIHJ1bGVzIGZy b20gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc5NTEjcGFnZS0xMSBzbyB0aGlzIG1l YW5zIHRoYXQgMTAgaXMgZGVjaW1hbC4NCiAgICANCiAgICBJbiBzZWN0aW9uIDQsIHRoZSBmaXJz dCBidWxsZXQgZGlzY3Vzc2VzIHRha2luZyBhICJwcmlvcml0eSIgYW5kIGNvcHlpbmcgaXQNCiAg ICBpbnRvIGEgIndlaWdodGluZyIgZmllbGQuICBTaW5jZSBwcmlvcml0eSBhbmQgd2VpZ2h0IGNh biBiZSBkaWZmZXJlbnQsIHRob3VnaA0KICAgIGFyZSBjbG9zZWx5IHJlbGF0ZWQsIHRoaXMgc2Vl bXMgYSBiaXQgY29uZnVzaW5nLiAgSSB0aGluayB0aGUgaW50ZW50aW9uIGhlcmUNCiAgICBmb3Ig SFRUUDIgZWZmZWN0cyB0aGF0IGFyZSB0cnlpbmcgdG8gYmUgYWNoaWV2ZWQgc2hvdWxkIGJlIGRp c2N1c3NlZCBtb3JlIHNvDQogICAgdGhhdCBpdCBpcyBjbGVhciB0byBpbXBsZW1lbnRlcnMgYW5k IHVzZXJzIHdoYXQgbW9yZSBzcGVjaWZpYyBlZmZlY3RzIHRoaXMNCiAgICBzaG91bGQgaGF2ZS4N CkFzIG1lbnRpb25lZCBpbiB0aGUgMm5kIHBhcmFncmFwaCwgdGhhdCB0ZXh0IGlzIHNwZWNpZmlj IHRvIGh0dHAyLiBTbyB0aGUgaW50ZW50aW9uIGhlcmUgaXMgdG8gZXhwbGFpbiBob3cgdGhlIHdl aWdodGluZy9kZXBlbmRlbmN5IG5vZGVzIChmcm9tIHN1YnNjcmliZWQtbm90aWZpY2F0aW9ucykg YXJlIHVzZWQgZm9yIGh0dHAyLiBJZiBJIHVuZGVyc3Rvb2QgeW91ciBjb21tZW50IHByb3Blcmx5 LCB5b3UgZmluZCBidWxsZXQgMSBjb25mdXNpbmcgc2luY2UgaXQgbWVudGlvbnMgcHJpb3JpdHkg YW5kIHdlaWdodCBpbiB0aGUgc2FtZSB2ZWluPyBXb3VsZCB0aGlzIGJlIGJldHRlcjoNCnRha2Ug dGhlICJ3ZWlnaHRpbmciIGxlYWYgbm9kZSBpbiAgW0ktRC5kcmFmdC1pZXRmLW5ldGNvbmYtc3Vi c2NyaWJlZC1ub3RpZmljYXRpb25zXSwgYW5kIGNvcHkgaXQgaW50byB0aGUgSFRUUDIgc3RyZWFt IHdlaWdodCwgW1JGQzc1NDBdIHNlY3Rpb24gNS4zLC4uLg0KDQpSZWdhcmRzLA0KUmVzaGFkLiAN CiAgICANCiAgICANCg0K From nobody Fri Apr 12 14:12:36 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D832812009A; Fri, 12 Apr 2019 14:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=O8in0iEK; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DD1qbkkF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLFZHIvhMQvi; Fri, 12 Apr 2019 14:12:21 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C165D1200EC; Fri, 12 Apr 2019 14:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2152; q=dns/txt; s=iport; t=1555103540; x=1556313140; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zDgNcuQ8zuW+biDhUjyB041n9gDVycrbFMvgpN1lHKQ=; b=O8in0iEKtVSvNt8QT9kqCeytN68VRO0iwcQIZ+Hf5/bhJnYawnnzw3cW X5IQtpE1nZvEKEfkeuIZKXXyqxK05alkPORLVV6W63vuSAjJAbRBIarFl Ui8IyiCKWedWNN1zbZdEy33knFMY69vC1G5kjEp4SIwv3AN/vN97gD7G/ E=; IronPort-PHdr: =?us-ascii?q?9a23=3ABrg/hx1k2yoho8gesmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKHt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQE1fyLPvjaQQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAAC2/rBc/5NdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUgQBAQEBCwGBPVADaFQgBAsoCoQEg0cDjxaCV5cagS6BJAN?= =?us-ascii?q?UDgEBIwqEQAIXhV8jNQgOAQMBAQoBAgECbRwMhUsGIxEMAQE3AQ8CAQgOBgY?= =?us-ascii?q?CJgICAjAVEAIEAQ0FgyIBgWkDHAECDKFVAooUcYEvgnkBAQWFAxiCDQMGgQs?= =?us-ascii?q?nAYtIF4FAP4ERJx+CTD6CYQKBeIJzMYImixuCCpkECQKCBYYIiEiDRBqCCIY?= =?us-ascii?q?ajFCLYoYqjWoCBAIEBQIOAQEFgVEBNYFWcBVlAYJBggqDb4UUhT9ygSmOKAG?= =?us-ascii?q?BHwEB?= X-IronPort-AV: E=Sophos;i="5.60,342,1549929600"; d="scan'208";a="258194235" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Apr 2019 21:12:19 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x3CLCJcL030923 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Apr 2019 21:12:19 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 12 Apr 2019 16:12:18 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 12 Apr 2019 16:12:18 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 12 Apr 2019 17:12:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zDgNcuQ8zuW+biDhUjyB041n9gDVycrbFMvgpN1lHKQ=; b=DD1qbkkFIlc0raxnnlD1yVPs+3vNfTxu6AxbKv4b53vir0FzIMpqFGgCnRVxfCS2ftlsNt8WAqiN2e3CPaGE2rGaa55Fh9q0V8o8ccZBizUQ76U0RtB/EzX9UHLwuhOQQTFxIlo4L0HWV7WEtBiKnOhd2ADCxM+lS8eNkXf3s8Y= Received: from MN2PR11MB3695.namprd11.prod.outlook.com (20.178.252.156) by MN2PR11MB3965.namprd11.prod.outlook.com (10.255.180.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.14; Fri, 12 Apr 2019 21:12:17 +0000 Received: from MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::8467:9ef7:d982:e972]) by MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::8467:9ef7:d982:e972%3]) with mapi id 15.20.1771.021; Fri, 12 Apr 2019 21:12:17 +0000 From: "Reshad Rahman (rrahman)" To: Robert Sparks , "gen-art@ietf.org" CC: "netconf@ietf.org" , "ietf@ietf.org" , "draft-ietf-netconf-restconf-notif.all@ietf.org" Thread-Topic: Genart last call review of draft-ietf-netconf-restconf-notif-13 Thread-Index: AQHU77jw5XA/EKaad06iroZhP0yA3KY4xk6A Date: Fri, 12 Apr 2019 21:12:17 +0000 Message-ID: <08861E62-97B9-499F-9B69-6E685FA6258A@cisco.com> References: <155491304260.9197.1007765785277967184@ietfa.amsl.com> In-Reply-To: <155491304260.9197.1007765785277967184@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.6.190114 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [173.38.117.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 06123b98-00ab-4cea-d725-08d6bf8b8b09 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR11MB3965; x-ms-traffictypediagnostic: MN2PR11MB3965: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0005B05917 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(376002)(346002)(136003)(39860400002)(189003)(199004)(6486002)(305945005)(68736007)(6512007)(106356001)(54906003)(97736004)(5660300002)(71200400001)(71190400001)(105586002)(478600001)(86362001)(33656002)(6306002)(6246003)(25786009)(53936002)(58126008)(3846002)(2906002)(14454004)(99286004)(6116002)(110136005)(256004)(7736002)(82746002)(8676002)(81166006)(8936002)(486006)(316002)(229853002)(2501003)(83716004)(6436002)(81156014)(6506007)(186003)(446003)(11346002)(4326008)(66066001)(476003)(2616005)(26005)(36756003)(102836004)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3965; H:MN2PR11MB3695.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: iEZ+CwOck3khMnfV3oGtNM9zGHZw5QCjFzmcTslIt9t4RREYkQviooykCzA39U87MZDbfdcaUPZaVSO9srN83UWiIp914+eN0f1w1Modha9AN/lLyI+selJqsqlb2Z0seQyARwGQSA75nzxilYrOg6TPTMwmXIPnQcmzICb8myXFao3SmvEjU7d7GtBE+8iD7QErfQd/Dho5uEKaQRfGEztN0V1oCKqBPWcTdhczPzOX/qy9raHXjJ/hEI6z2sGIW0HV68wdRYZyNNIBzSYXWOGIzAemJPGerKp4BTLEkNGW+ci4wBAvAJFjpdVI+nxDgJ73vYCuTdLdlxd5hU6Q5pSWwHxNsHVkNXLhh8wyk8PkKOzEer5jvIRKcrkyrXIcw57TBa9/MojxnfCSu9Oei6uaHZwdqMxEQEnbvIImbHQ= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 06123b98-00ab-4cea-d725-08d6bf8b8b09 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 21:12:17.2500 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3965 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [netconf] Genart last call review of draft-ietf-netconf-restconf-notif-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 21:12:24 -0000 SGkgUm9iZXJ0LA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcsIHBsZWFzZSBzZWUgaW5saW5l Lg0KDQrvu79PbiAyMDE5LTA0LTEwLCAxMjoxNyBQTSwgIlJvYmVydCBTcGFya3MgdmlhIERhdGF0 cmFja2VyIiA8bm9yZXBseUBpZXRmLm9yZz4gd3JvdGU6DQoNCiAgICBSZXZpZXdlcjogUm9iZXJ0 IFNwYXJrcw0KICAgIFJldmlldyByZXN1bHQ6IFJlYWR5DQogICAgDQogICAgSSBhbSB0aGUgYXNz aWduZWQgR2VuLUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIEdlbmVyYWwgQXJlYQ0K ICAgIFJldmlldyBUZWFtIChHZW4tQVJUKSByZXZpZXdzIGFsbCBJRVRGIGRvY3VtZW50cyBiZWlu ZyBwcm9jZXNzZWQNCiAgICBieSB0aGUgSUVTRyBmb3IgdGhlIElFVEYgQ2hhaXIuICBQbGVhc2Ug dHJlYXQgdGhlc2UgY29tbWVudHMganVzdA0KICAgIGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBj b21tZW50cy4NCiAgICANCiAgICBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUg RkFRIGF0DQogICAgDQogICAgPGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2dlbi93aWtpL0dl bkFydGZhcT4uDQogICAgDQogICAgRG9jdW1lbnQ6IGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29u Zi1ub3RpZi0xMw0KICAgIFJldmlld2VyOiBSb2JlcnQgU3BhcmtzDQogICAgUmV2aWV3IERhdGU6 IDIwMTktMDQtMTANCiAgICBJRVRGIExDIEVuZCBEYXRlOiAyMDE5LTA0LTEyDQogICAgSUVTRyBU ZWxlY2hhdCBkYXRlOiBOb3Qgc2NoZWR1bGVkIGZvciBhIHRlbGVjaGF0DQogICAgDQogICAgU3Vt bWFyeTogUmVhZHkgZm9yIHB1YmxpY2F0aW9uIGFzIGEgcHJvcG9zZWQgc3RhbmRhcmQNCiAgICAN CiAgICBOaXRzL2VkaXRvcmlhbCBjb21tZW50czoNCiAgICANCiAgICBUaGUgYWJzdHJhY3QgaXMg cXVpdGUgdGVyc2UuIFBsZWFzZSBjb25zaWRlciBleHBhbmRpbmcgaXQgdG8gc29tZXRoaW5nIHRo YXQNCiAgICBzdGFuZHMgYmV0dGVyIGJ5IGl0c2VsZi4NClRCSCBJJ20gbm90IHN1cmUgd2hhdCBl bHNlIHRvIGFkZC4gSSdsbCBkaXNjdXNzIHdpdGggdGhlIG90aGVyIGF1dGhvcnMuIA0KICAgIA0K ICAgIFRoZSBzZW50ZW5jZSB0aGF0IHN0YXJ0cyAiRHJpdmluZyB0aGVzZSByZXF1aXJlbWVudHMi IGluIHRoZSBpbnRyb2R1Y3Rpb24gZG9lcw0KICAgIG5vdCBmb2xsb3cgd2hlcmUgaXQgc2l0cyBp biB0aGUgcGFyYWdyYXBoLiBUaGVyZSBpcyBubyBhbnRlY2VkZW50IGZvciAidGhlc2UNCiAgICBy ZXF1aXJlbWVudHMiLiBJIHN1Z2dlc3QgcmVwbGFjaW5nIHRoZSBzZW50ZW5jZSB3aXRoICJSZXF1 aXJlbWVudHMgZm9yIHRoZXNlDQogICAgbWVjaGFuaXNtcyBhcmUgY2FwdHVyZWQgaW4gW1JGQzc5 MjNdLg0KTWFrZXMgc2Vuc2UsIEknbGwgbWFrZSB0aGUgY2hhbmdlLg0KICAgIA0KICAgIFRoZSBz ZWNvbmQgc2VudGVuY2UgaW4gdGhlIGZpcnN0IHBhcmFncmFwaCBvZiBzZWN0aW9uIDMgaXMgYSBy dW4tb24uIEkgc3VnZ2VzdA0KICAgIHMvMi40LCB0aGUvMi40LiBUaGUvDQpTdXJlLg0KDQpSZWdh cmRzLA0KUmVzaGFkLiAgICANCiAgICANCiAgICANCg0K From nobody Fri Apr 12 14:30:02 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE56120174; Fri, 12 Apr 2019 14:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=iEP9YD9Y; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=T3JlgMFR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiRwbpmpDaSB; Fri, 12 Apr 2019 14:29:51 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE831200B4; Fri, 12 Apr 2019 14:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1602; q=dns/txt; s=iport; t=1555104590; x=1556314190; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hrcwsI6QKR0c7Srm7UgO0VjXxVA6tjB/d65lxmWne2A=; b=iEP9YD9YLvqTQdC2njLW6jMXtO/aa4BpAlByJZBFNDhYhwprK9drXd0j 3FJvTwEs4jAAEsYTDm0I4jCI8sJmg8PTH/vxUmByMtWTQ/uXLsLYvOEoO vn09r6UoZJziR2eH7jYY/+ga9VKaWaSk19gTvpRz9tJrci5X/FGwWy+Se E=; IronPort-PHdr: =?us-ascii?q?9a23=3AR/OwfxIal0zwunzaodmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvad2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFfhJf7vZioSF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAAD1ArFc/40NJK1lDg0BAQEBAwE?= =?us-ascii?q?BAQcDAQEBgVEGAQEBCwGBPVADaFQgBAsoCoQEg0cDhFKKRJlxgS6BJANUDgE?= =?us-ascii?q?BGAsKg3pGAheFXyM0CQ4BAwEBCgECAQJtHAyFSwIEAQEhEQwBASwLAQ8CAQg?= =?us-ascii?q?aAiYCAgIlCxUQAgQBDQWDIgGBaQMcAQIMoUoCihRxgS+CeQEBBYUDGIINAwa?= =?us-ascii?q?BCycBi0gXgUA/gREnH4JMPoJhAQGBYReCczGCJo0lmQQJAoIFjlCDRBqCCIY?= =?us-ascii?q?ajFCLYpQUAgQCBAUCDgEBBYFPOIFWcBU7KgGCQYIKg2+FFIUEO3KBKY4oAYE?= =?us-ascii?q?fAQE?= X-IronPort-AV: E=Sophos;i="5.60,342,1549929600"; d="scan'208";a="546262128" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Apr 2019 21:29:38 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x3CLTcLu022670 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Apr 2019 21:29:38 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 12 Apr 2019 16:29:38 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 12 Apr 2019 17:29:37 -0400 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 12 Apr 2019 16:29:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hrcwsI6QKR0c7Srm7UgO0VjXxVA6tjB/d65lxmWne2A=; b=T3JlgMFR+2qBDDDHu6/FHDbC2j07n7Y0z57yNcdMvCJ5ceR2A/wLa1gojAd0TPoa09CddjubjYKGo3V+zSwedjBCX9LVADMJA3lhuZyNZVzFgIITmMQHYV2dfxkawF6j/5xxd4IDi5hUDW1I+OMi4RU620jxv1qerhyd+VyTyKE= Received: from MN2PR11MB3695.namprd11.prod.outlook.com (20.178.252.156) by MN2PR11MB4015.namprd11.prod.outlook.com (10.255.181.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.17; Fri, 12 Apr 2019 21:29:35 +0000 Received: from MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::8467:9ef7:d982:e972]) by MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::8467:9ef7:d982:e972%3]) with mapi id 15.20.1771.021; Fri, 12 Apr 2019 21:29:35 +0000 From: "Reshad Rahman (rrahman)" To: Aanchal Malhotra , "secdir@ietf.org" CC: "draft-ietf-netconf-restconf-notif.all@ietf.org" , "netconf@ietf.org" , "ietf@ietf.org" Thread-Topic: [netconf] Secdir last call review of draft-ietf-netconf-restconf-notif-13 Thread-Index: AQHU8LEm3/ufrU/2dEa8pjPJiNurYqY4yTOA Date: Fri, 12 Apr 2019 21:29:35 +0000 Message-ID: References: <155501965074.14152.2835369201856309773@ietfa.amsl.com> In-Reply-To: <155501965074.14152.2835369201856309773@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.6.190114 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [173.38.117.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 13697ad4-1be5-43d3-5f4b-08d6bf8df5e9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR11MB4015; x-ms-traffictypediagnostic: MN2PR11MB4015: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0005B05917 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(366004)(39860400002)(396003)(346002)(199004)(189003)(51914003)(14454004)(99286004)(83716004)(71190400001)(478600001)(4326008)(71200400001)(86362001)(53936002)(6246003)(2171002)(82746002)(6306002)(33656002)(256004)(105586002)(2501003)(106356001)(36756003)(966005)(8936002)(8676002)(66066001)(81156014)(81166006)(6512007)(54906003)(2906002)(25786009)(26005)(6436002)(305945005)(58126008)(7736002)(316002)(110136005)(76176011)(186003)(6116002)(11346002)(3846002)(102836004)(4744005)(5660300002)(6506007)(476003)(486006)(6486002)(97736004)(446003)(2616005)(68736007)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4015; H:MN2PR11MB3695.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: K9zo16CHGWjsbj6obb6XHx1rIvrNxQvSzcyW23T664xDAGn8/wvNIfBPVfE4bZoeucOJBZKEqWAox1BJqyAT7jjQJqI/YmtlZgv/b4z2DRV5gwibB+LqEzhor7sNKMoR/dWctw5QLp9Lwne87a20533pLKsIE7GE/901c1g37XhB0FvRXkh10HCmbNKinxxrk/w7GeeNpAnKjC8mkDCZnXAct9vgHwdIjbWvTq3D3cLFzqipz2r3HTCQ0sOu/Nz97hCAJlJdmoVC+/6VdWV61785Qo1BqjsWMusmaX5D9V8R4FZ7KjIvC7mZwoO1KzcrnhfUo5dYM4Gz29A2FnV0XKRuQJEkAeOuv5RQKHMjtjQgZrE2Tf2nrcoI36vYWnSJranDt/rVjKTidZB/A48cVIhOhhTEM6XtAl/mzBivses= Content-Type: text/plain; charset="utf-8" Content-ID: <2B51749631259B4796C32C5CEB11ECA9@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 13697ad4-1be5-43d3-5f4b-08d6bf8df5e9 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 21:29:35.5599 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4015 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [netconf] Secdir last call review of draft-ietf-netconf-restconf-notif-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 21:29:53 -0000 SGkgQWFuY2hhbCwNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBQbGVhc2Ugc2VlIGlubGluZS4N Cg0K77u/T24gMjAxOS0wNC0xMSwgNTo1NCBQTSwgIm5ldGNvbmYgb24gYmVoYWxmIG9mIEFhbmNo YWwgTWFsaG90cmEgdmlhIERhdGF0cmFja2VyIiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIG9u IGJlaGFsZiBvZiBub3JlcGx5QGlldGYub3JnPiB3cm90ZToNCg0KICAgIFJldmlld2VyOiBBYW5j aGFsIE1hbGhvdHJhDQogICAgUmV2aWV3IHJlc3VsdDogUmVhZHkNCiAgICANCiAgICBUaGUgZG9j dW1lbnQgaXMgdmVyeSBjbGVhciBhbmQgY29uY2lzZS4gIEkganVzdCBoYXZlIG9uZSBtaW5vciBj bGFyaWZpY2F0aW9uIHF1ZXN0aW9uLg0KICAgIFNlY3Rpb24gMy40IFBhZ2UgOSB0aGF0IHNheXMg dGhlIGZvbGxvd2luZzoNCiAgICAiSW4gYWRkaXRpb24gdG8gYW55IHJlcXVpcmVkIC4uLi4uLi4u U0hPVUxEIG9ubHkgYmUgYWxsb3dlZC4uLi4uLiIuICANCiAgICANCiAgICBJcyB0aGVyZSBhIHJl YXNvbiBmb3IgdXNpbmcgU0hPVUxEIGluc3RlYWQgb2YgTVVTVD8gDQoNClRoZXJlIG1heSBiZSBy ZWFzb25zIHdoeSBhbiBpbXBsZW1lbnRhdGlvbiBkZWNpZGVzIG5vdCB0byBlbmZvcmNlIHRoaXMg cmVzdHJpY3Rpb24uIEdvaW5nIGJ5IFJGQzIxMTkgZGVmaW5pdGlvbnMsIHRoaXMgaXMgd2h5IHdl IGNob3NlIFNIT1VMRCBpbnN0ZWFkIG9mIE1VU1QuDQozLiBTSE9VTEQgICBUaGlzIHdvcmQsIG9y IHRoZSBhZGplY3RpdmUgIlJFQ09NTUVOREVEIiwgbWVhbiB0aGF0IHRoZXJlDQogICBtYXkgZXhp c3QgdmFsaWQgcmVhc29ucyBpbiBwYXJ0aWN1bGFyIGNpcmN1bXN0YW5jZXMgdG8gaWdub3JlIGEN CiAgIHBhcnRpY3VsYXIgaXRlbSwgYnV0IHRoZSBmdWxsIGltcGxpY2F0aW9ucyBtdXN0IGJlIHVu ZGVyc3Rvb2QgYW5kDQogICBjYXJlZnVsbHkgd2VpZ2hlZCBiZWZvcmUgY2hvb3NpbmcgYSBkaWZm ZXJlbnQgY291cnNlLg0KDQpSZWdhcmRzLA0KUmVzaGFkLiAgICANCiAgICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIG5ldGNvbmYgbWFpbGluZyBs aXN0DQogICAgbmV0Y29uZkBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0Y29uZg0KICAgIA0KDQo= From nobody Fri Apr 12 14:31:53 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66691200EA; Fri, 12 Apr 2019 14:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ZCQTgJ97; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=B733mum6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VADBWJABhxSO; Fri, 12 Apr 2019 14:31:38 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 358F21200B4; Fri, 12 Apr 2019 14:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1298; q=dns/txt; s=iport; t=1555104698; x=1556314298; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NtmK3JD30GTavmj2jtA0aQCc2eG034In0/vqWe6f/Dg=; b=ZCQTgJ97U6niEufgMHNj6w7MJ37ClCfTMU0NGw4BcUGqGGJJWDEoZSGJ VO/sJy2d2rAHfQlZg1XEuV56XAXunEa4OsCG8OqCouB2XyCTCsvjyCaRI JB8AxVirb+7aGbMV25ECywNvHP3u3ZbKFM3W6Ed993be5vWVtHFzGEeJ5 U=; IronPort-PHdr: =?us-ascii?q?9a23=3As7O3rh1+OO2bAsd2smDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKHt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQE1fyLPvjaQQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAACyArFc/4wNJK1lGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYE9UAOBPCAECygKhASDRwOEUopEgjKXP4EugSQDVA4?= =?us-ascii?q?BAS2EQAIXhV8jNAkOAQMBAQoBAgECbRwMhUsGIxEMAQE3AQ8CAQgODAIJHQI?= =?us-ascii?q?CAjAVEAIEAQ0FgyKBagMcAQKhVgKKFHGBL4J5AQEFhQMYgg0JgQsnAYtIF4F?= =?us-ascii?q?AP4E4DBOCTD6ERBeCczGCJod1hTCMFowMYgkCggWKK4NaS4NEGpRyi2KUFAI?= =?us-ascii?q?EAgQFAg4BAQWBTziBVnAVZQGCQYIKg2+KU3KBKY4oAYEfAQE?= X-IronPort-AV: E=Sophos;i="5.60,342,1549929600"; d="scan'208";a="535917386" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Apr 2019 21:31:36 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x3CLVamN012449 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Apr 2019 21:31:37 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 12 Apr 2019 16:31:36 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 12 Apr 2019 16:31:36 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 12 Apr 2019 17:31:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NtmK3JD30GTavmj2jtA0aQCc2eG034In0/vqWe6f/Dg=; b=B733mum6NxuEHKe/jWN81hQ4ijJkx1jY3QkznCCxiTA8Or7ujrbTGB/cN9egDnShKjY5HuYz102oIB5t97MY+L/Fq9rSXeLKU2Hp0xi+fFruJkdTkM9DjOFSuUrtBAuwims0mCpNgN6gQf7UStz/+gi1QCjKShkNfid8QhK8l8U= Received: from MN2PR11MB3695.namprd11.prod.outlook.com (20.178.252.156) by MN2PR11MB3776.namprd11.prod.outlook.com (20.178.251.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.16; Fri, 12 Apr 2019 21:31:35 +0000 Received: from MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::8467:9ef7:d982:e972]) by MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::8467:9ef7:d982:e972%3]) with mapi id 15.20.1771.021; Fri, 12 Apr 2019 21:31:35 +0000 From: "Reshad Rahman (rrahman)" To: Dan Romascanu , "ops-dir@ietf.org" CC: "netconf@ietf.org" , "ietf@ietf.org" , "draft-ietf-netconf-restconf-notif.all@ietf.org" Thread-Topic: Opsdir last call review of draft-ietf-netconf-restconf-notif-13 Thread-Index: AQHU8PyPM2+Cb1TvTUqfAp1qiRo4aKY4ySuA Date: Fri, 12 Apr 2019 21:31:35 +0000 Message-ID: <979EE6C4-8A85-479E-9957-6C704853FE94@cisco.com> References: <155505204479.14152.7199403462087388546@ietfa.amsl.com> In-Reply-To: <155505204479.14152.7199403462087388546@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.6.190114 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [173.38.117.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9999f43e-9043-4c30-e9e7-08d6bf8e3d3d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR11MB3776; x-ms-traffictypediagnostic: MN2PR11MB3776: x-microsoft-antispam-prvs: x-forefront-prvs: 0005B05917 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(366004)(396003)(346002)(39860400002)(189003)(199004)(2616005)(4326008)(83716004)(33656002)(71200400001)(105586002)(6486002)(25786009)(97736004)(58126008)(4744005)(316002)(68736007)(81156014)(8936002)(110136005)(54906003)(86362001)(478600001)(6436002)(53936002)(8676002)(6246003)(6116002)(3846002)(6512007)(2906002)(81166006)(14454004)(229853002)(106356001)(256004)(7736002)(305945005)(14444005)(102836004)(36756003)(5660300002)(71190400001)(476003)(6506007)(11346002)(26005)(2501003)(66066001)(76176011)(99286004)(82746002)(486006)(186003)(446003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3776; H:MN2PR11MB3695.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: B5MXjD5ekzTIMvesVWkhsPdX2k2kjqJqMoPVnaz7DJluiD367vp0GwiUZPhhDBaXo2iB1ZSM8ShUvgI3uSpn1PEam0n9r/hDAVysvFFf1ktArbVRNCFiY+3XYjZ3AoSsw4ZqFxSmUTJet378kwwzy4S2iLARqJktRgCPvlZYc1QryGj500A7F857VRCsZe7BWYkAA4eCsab65lzJ3xGmjYjpa76oY4wFVx5g3FX/jarLM8z7YyVTMGLoVQBmOwm/wQyfWE1qNbJ1jeMh5l0xvxu0UbA4C+0sK2sew47QkKS/h+GbhLwN1hXWpHZ5lKFFpH3I8avAAwtEL/QXwgRcqu79JzgiLUHsYozuPGXNzO0kAQurgdV8AJZZHP8I/GzW8Ia6OqmRRLX+2B1yjyv6MlKzduzVvCMYdFJIXGFZdZQ= Content-Type: text/plain; charset="utf-8" Content-ID: <71EEFD11BD721A4599D6E70C82A0E38B@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9999f43e-9043-4c30-e9e7-08d6bf8e3d3d X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 21:31:35.1341 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3776 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.28, xch-aln-018.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [netconf] Opsdir last call review of draft-ietf-netconf-restconf-notif-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 21:31:40 -0000 VGhhbmsgeW91IERhbi4NCg0KUmVnYXJkcywNClJlc2hhZC4NCg0K77u/T24gMjAxOS0wNC0xMiwg Mjo1NCBBTSwgIkRhbiBSb21hc2NhbnUgdmlhIERhdGF0cmFja2VyIiA8bm9yZXBseUBpZXRmLm9y Zz4gd3JvdGU6DQoNCiAgICBSZXZpZXdlcjogRGFuIFJvbWFzY2FudQ0KICAgIFJldmlldyByZXN1 bHQ6IFJlYWR5DQogICAgDQogICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIFJFU1RDT05G IGJpbmRpbmcgdG8gdGhlIGR5bmFtaWMgc3Vic2NyaXB0aW9uDQogICAgY2FwYWJpbGl0eSBvZiBi b3RoIHN1YnNjcmliZWQgbm90aWZpY2F0aW9ucyBhbmQgWUFORy1QdXNoLiBJdCdzIGEgdXNlZnVs IGFuZA0KICAgIGltcG9ydGFudCBhZGRpdGlvbiB0byB0aGUgUkVTVENPTkYgcHJvdG9jb2wgbWVj aGFuaXNtcywgYW5kIG9wZXJhdG9ycyBzaG91bGQNCiAgICBwYXkgYXR0ZW50aW9uLiBUaGUgZG9j dW1lbnQgaXMgbm90IGVhc3kgcmVhZGluZywgYXMgaXQgcmVsaWVzIG9uIHNldmVyYWwgb3RoZXIN CiAgICBkb2N1bWVudHMsIGJ1dCB0aGUgcmVmZXJlbmNlcyBpbiB0aGUgdGV4dCBoZWxwLiBJdCB3 b3VsZCBoYXZlIGhlbHBlZCBpZiBzb21lDQogICAgbm90ZXMgd2VyZSBhZGRlZCBjb25jZXJuaW5n IHRoZSBwb3NzaWJsZSBhY3Rpb25zIHRoYXQgdGhlIG9wZXJhdG9ycyBuZWVkIHRvDQogICAgdGFr ZSBpbiBvcmRlciB0byBlbnN1cmUgb3B0aW1hbCBiZWhhdmlvciAoaW5pdGlhbCBjb25maWd1cmF0 aW9uIGZvciBleGFtcGxlKSBvcg0KICAgIGluZGljYXRpb25zIGFib3V0IHdoZW4gdG8gdXNlIG9u ZSBvciB0aGUgb3RoZXIgb2YgdGhlIG5vdGlmaWNhdGlvbnMgbWVjaGFuaXNtcy4NCiAgICBUaGlz IGlzIG5vdCBibG9ja2luZywgaG93ZXZlciwgYW5kIHRoZSBkb2N1bWVudCBpcyBSRUFEWSBmb3Ig cHVibGljYXRpb24uDQogICAgDQogICAgDQogICAgDQoNCg== From nobody Sun Apr 14 17:40:40 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B691202C6; Sun, 14 Apr 2019 17:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.338 X-Spam-Level: X-Spam-Status: No, score=-1.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.363, 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=juniper.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 b7AyjIDRlBJZ; Sun, 14 Apr 2019 17:40:35 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 88E5F120222; Sun, 14 Apr 2019 17:40:35 -0700 (PDT) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3F0eMau012392; Sun, 14 Apr 2019 17:40:30 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=UxmsgJMhEE9rwgzIYOu+i7FSeP4uUJYerfwDLiXyTb8=; b=Aw+XwPqebfRd3csbMBir3ajjDcCnC+UG/ms6KIoMrv9whJlz91NqtjqnBfH4OxJu8u7v zyjd0JjgFaTx6oElFY+3198fE1OvaDUeAKtUM10k1rUfAN3ONkl1o+vRsgCSn1gKpsSM HWnqJXD3b05Ko7Op37ExONJjwWNJg73MjQ9JFU6WcVBJvhJMxJFc5w8CkwV3OENFl3BN pURQW4IYWXErJpO/WJa7otzUUIvx5KBYjKaIPVDe1mDJBzk4gtj5YrOxpEN0x/8PyjX/ fEPZiIP/48IlV1mxxmLO66Y6/0OUJHazJxMeUoKzgfTjBSGMyM9CkmrkpkWNJiG2Fk1I pw== Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp2051.outbound.protection.outlook.com [104.47.40.51]) by mx0b-00273201.pphosted.com with ESMTP id 2rudpf21df-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 14 Apr 2019 17:40:29 -0700 Received: from BYAPR05MB4408.namprd05.prod.outlook.com (52.135.202.158) by BYAPR05MB6056.namprd05.prod.outlook.com (20.178.54.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Mon, 15 Apr 2019 00:40:25 +0000 Received: from BYAPR05MB4408.namprd05.prod.outlook.com ([fe80::e948:c7e2:ff08:bad9]) by BYAPR05MB4408.namprd05.prod.outlook.com ([fe80::e948:c7e2:ff08:bad9%7]) with mapi id 15.20.1813.009; Mon, 15 Apr 2019 00:40:25 +0000 From: Ravi Singh To: Routing ADs CC: Routing Directorate , "draft-ietf-netconf-subscribed-notifications.all@ietf.org" , "netconf@ietf.org" Thread-Topic: RtgDir review: draft-ietf-netconf-subscribed-notifications Thread-Index: AdTzIvcBe9EXeFb2ThSKUq3KYi0U2Q== Date: Mon, 15 Apr 2019 00:40:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.164.105.241] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 24f0c3b0-b18d-4fd5-c39b-08d6c13af38c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR05MB6056; x-ms-traffictypediagnostic: BYAPR05MB6056: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(136003)(396003)(366004)(199004)(189003)(71190400001)(6116002)(790700001)(6436002)(15650500001)(3846002)(33656002)(6916009)(71200400001)(7110500001)(74316002)(68736007)(105586002)(55016002)(2420400007)(7736002)(106356001)(26005)(186003)(7696005)(86362001)(102836004)(14454004)(5660300002)(6506007)(476003)(486006)(53936002)(256004)(97736004)(66066001)(9326002)(54896002)(14444005)(2906002)(81166006)(4326008)(25786009)(81156014)(6306002)(8936002)(99286004)(52536014)(8676002)(478600001)(9686003)(316002)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB6056; H:BYAPR05MB4408.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: QlwHXOyr+IkuBSWoDhQuuTRv/pDJVsNJV8oK2kXMcv02d+TeTMOxtDjFUXfljnUaT2zHN5g/Ue1qZUqtXKdpqOadva+Wm/cvkz93Y9rT0SIXENrKr2FtnjTI1IP3E+7ejfPOtw6VZlKIafN/RDSh9xzMtG4mNRlzfANHmjRyNTMICOtQMiQKEOKFnNoXqygkm1CnHqTrzFJW3HCOhhAOXDVJaNePCz0sYlF24fcuNPECBl9XRsAGZxR5fIboP1x4h3RhlcxGA9bsuwCRuYQ3QjH0xdMY+UX2G+g9gMs187Pe+b2GR3XfQ+t6nAUtxa2IWxPYjX6BDEItVBFFvOY5K8KtKYyVd8pq0igAhEKpieDOAlFnJaVUJEb+P5k1IXsNg6RubzO3S8el82ldLrS+HOQMU3/7U7+jjjit6LwfTXU= Content-Type: multipart/alternative; boundary="_000_BYAPR05MB440858805FC9DE9710292BF9AB2B0BYAPR05MB4408namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 24f0c3b0-b18d-4fd5-c39b-08d6c13af38c X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 00:40:25.6225 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB6056 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-15_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904150002 Archived-At: Subject: [netconf] RtgDir review: draft-ietf-netconf-subscribed-notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 00:40:38 -0000 --_000_BYAPR05MB440858805FC9DE9710292BF9AB2B0BYAPR05MB4408namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMg b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCg0KQWx0aG91Z2ggdGhlc2Ug Y29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0 IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBh bnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0 cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRo ZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlm aWNhdGlvbnMNClJldmlld2VyOiBSYXZpIFNpbmdoDQpSZXZpZXcgRGF0ZTogMDQvMTIvMjAxOQ0K SUVURiBMQyBFbmQgRGF0ZTogZGF0ZS1pZi1rbm93bg0KSW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFy ZHMgVHJhY2sNCg0KU3VtbWFyeToNClRoaXMgZG9jdW1lbnQgaXMgYmFzaWNhbGx5IHJlYWR5IGZv ciBwdWJsaWNhdGlvbiwgYnV0IGhhcyBuaXRzIHRoYXQgc2hvdWxkIGJlIGNvbnNpZGVyZWQgcHJp b3IgdG8gcHVibGljYXRpb24uDQoNCkNvbW1lbnRzOg0KSSd2ZSByZXZpZXdlZCB0aGUgZHJhZnQu DQpJdCBpcyB2ZXJ5IGV4aGF1c3RpdmUgYW5kIGdlbmVyYWxseSB3ZWxsIHdyaXR0ZW4uDQpJIGNv bnNpZGVyIGl0IHJlYWR5IGZvciBwdWJsaWNhdGlvbiwgYWZ0ZXIgdGhlIGZvbGxvd2luZyAibml0 cyIgaGF2ZSBiZWVuIGFkZHJlc3NlZC4NCg0KDQoxLiAgICAgICAxLjM6DQoiU3VwcG9ydCBmb3Ig Y29uZmlndXJlZCBzdWJzY3JpcHRpb25zIGlzIG9wdGlvbmFsLCB3aXRoIGl0cyBhdmFpbGFiaWxp dHkgYWR2ZXJ0aXNlZCB2aWEgYSAgWUFORyBmZWF0dXJlLiINClRoZSAiaG93IiBhc3BlY3Qgc2hv dWxkIGJlIGFsbHVkZWQgdG8gaGVyZSwgZXZlbiB0aG91Z2ggc3Vic2VxdWVudCBzZWN0aW9ucyBh ZGRyZXNzIHRoaXMgaW4gZGV0YWlsPw0KVGhpcyB3aWxsIG1ha2UgZm9yIGJldHRlciByZWFkYWJp bGl0eS4NCg0KMi4gICAgICAgIkZvciBjb25uZWN0aW9ubGVzcyBvciBzdGF0ZWxlc3MgdHJhbnNw b3J0cyBsaWtlDQogICAgICBIVFRQLCBhIGxhY2sgb2YgcmVjZWlwdCBhY2tub3dsZWRnbWVudCBv ZiBhIHNlcXVlbnRpYWwgc2V0IG9mDQogICAgICBub3RpZmljYXRpb24gbWVzc2FnZXMgYW5kL29y IGtlZXAtYWxpdmVzIGNhbiBiZSB1c2VkIHRvIHRyaWdnZXIgYQ0KICAgICAgdGVybWluYXRpb24g b2YgYSBkeW5hbWljIHN1YnNjcmlwdGlvbi4iDQpIb3cgbG9uZyB0byB3YWl0PyBBbnkgaW5wdXRz IHRoZSBkcmFmdCB3b3VsZCBsaWtlIHRvIHByb3ZpZGUgb3IgbGVhdmUgdG8gYW4gaW1wbGVtZW50 YXRpb24/DQoNCjMuICAgICAgIFNlY3Rpb24gMi40LjI6DQpXb3VsZCBiZSB1c2VmdWwgdG8gZXhw bGFpbiAid2hlbiByZXBsYXkgc3RvcHMiLCBpZiAicmVwbGF5IiB3YXMgcmVxdWVzdGVkLg0KSXMg dGhpcyBkb25lIGJ5IG1hbmRhdGluZyB0aGF0ICJzdG9wLXRpbWUiIG11c3QgYmUgcHJvdmlkZWQg aWYgcmVwbGF5IHdhcyByZXF1ZXN0ZWQ/DQpTdWJzZXF1ZW50IHNlY3Rpb25zIGFkZHJlc3MgdGhp cywgaG93ZXZlciB3b3VsZCBiZSB1c2VmdWwgdG8gYWxsdWRlIHRvIGluIHRoaXMgc2VjdGlvbuKA pg0KDQo0LiAgICAgICBTZWN0aW9uIDIuNC4zOg0KUGxlYXNlIGVsYWJvcmF0ZSBvbiB0aGUgcHJl c2VuY2Ugb2YgdGhlIGZvbGxvd2luZyBpbiB0aGUgc2NoZW1hOg0KICAgICAgICAgICAgICstLS13 IHN0b3AtdGltZT8NCiAgICAgICAgICAgICAgICAgICAgIHlhbmc6ZGF0ZS1hbmQtdGltZQ0KDQo1 LiAgICAgICAgU2VjdGlvbiAyLjQuNTogbm90IGNsZWFyIHdoZW4gdGhpcyB3b3VsZCBhY3R1YWxs eSBnZXQgdXNlZCwgSU9X4oCmd2hhdCB3b3VsZCBjYXVzZSB0aGVyZSB0byBiZSBzdWNoIGEgc2l0 dWF0aW9uIHdoZXJlIHRoZSBraWxsLXNidXNjcmlwdGlvbiBub3RpZmNhdGlvbiB3b3VsZCBuZWVk IHRvIGJlIHVzZWQuIFdoZW4gd2lsbCBhIHN1YnNjcmlwdGlvbiBub3QgYmUgYXNzb2NpYXRlZCB3 aXRoIGEgdHJhbnNwb3J0IHNlc3Npb24/DQoNCjYuICAgICAgIDIuNC42Og0KYS4gICAgICAgd2h5 IGhhdmUgZXJyb3JzIHcuci50LiAid2VpZ2h0aW5nIiwgYW5kICJkZXBlbmRlbmN5IiBub3QgYmVl biBpbmNsdWRlZD8NCmIuICAgICAgTnVtZXJlZCBwb2ludHMgMS8yLzMgYXJlIGJldHRlciBjb21t dW5pY2F0ZWQgdmlhIGEgdGFibGUgdG8gYXZvaWQgdGhlIGR1cGxpY2F0ZWQgdGV4dC4NCkJyZXZp dHkgbWFrZXMgZm9yIGJldHRlciByZWFkaW5nLg0KDQo3LiAgICAgICBTZWN0aW9ucyAyLjUuMiAt IDIuNS43OiB0aGVzZSBhcmUgYSBiaXQgb2YgYSBkcmFnIHRvIHJlYWQgdGhyb3VnaCwgaW4gYW4g YWxyZWFkeSBsYXJnZSBkb2N1bWVudC4gUmVhZGFiaWxpdHkgZm9yIHRoZXNlIHNlY3Rpb25zIHdv dWxkIGJlIGdyZWF0bHkgaW1wcm92ZWQgaWYgdGhlIG5vdGlmaWNhdGlvbnMgdGhhdCBnZXQgc2Vu dCBvdXQgd2VyZSBsaXN0ZWQgcGljdG9yaWFsbHkgb3IgaW4gYSB0YWJ1bGFyIGZhc2hpb24gYnkg ZW5oYW5jaW5nIHRoZSBzaW1wbGUgRlNNcyBsaXN0ZWQgaW4gc2VjdGlvbiAyLjUuMS4NCg0KOC4g ICAgICAgU2VjdGlvbiA1LjQ6DQoiVGhpcyBjYW4gYmUgYWNjb21wbGlzaCBieSBlc3RhYmxpc2hp bmciIC0+ICJUaGlzIGNhbiBiZSBhY2NvbXBsaXNoZWQgYnkgZXN0YWJsaXNoaW5nIg0KDQpSZWdh cmRzDQpSYXZpDQoNCg0K --_000_BYAPR05MB440858805FC9DE9710292BF9AB2B0BYAPR05MB4408namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5n ZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAy IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9z ZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMDA3NTg0OTQxOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotMjEzNjMwODIyMjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDIgbGZvMg0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6Mjt9DQpAbGlzdCBsMDpsZXZl bDIgbGZvMw0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6Mzt9DQpAbGlzdCBsMDpsZXZlbDIgbGZvNA0K CXttc28tbGV2ZWwtc3RhcnQtYXQ6NDt9DQpAbGlzdCBsMDpsZXZlbDIgbGZvNQ0KCXttc28tbGV2 ZWwtc3RhcnQtYXQ6NTt9DQpAbGlzdCBsMDpsZXZlbDIgbGZvNw0KCXttc28tbGV2ZWwtc3RhcnQt YXQ6Nzt9DQpAbGlzdCBsMDpsZXZlbDIgbGZvOA0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6ODt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+SGVsbG8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmll d2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZp ZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhy b3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMNCiBvbiBz cGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBh c3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQg dGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5BbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUg dXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQg Y29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50 cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoDQog ZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPkRvY3VtZW50OiBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3Rp ZmljYXRpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SZXZpZXdlcjogUmF2aSBTaW5naDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ UmV2aWV3IERhdGU6IDA0LzEyLzIwMTk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPklFVEYgTEMgRW5kIERhdGU6IGRh dGUtaWYta25vd248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNr PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlN1bW1hcnk6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5U aGlzIGRvY3VtZW50IGlzIGJhc2ljYWxseSByZWFkeSBmb3IgcHVibGljYXRpb24sIGJ1dCBoYXMg bml0cyB0aGF0IHNob3VsZCBiZSBjb25zaWRlcmVkIHByaW9yIHRvIHB1YmxpY2F0aW9uLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Db21tZW50czo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkkndmUg cmV2aWV3ZWQgdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SXQgaXMgdmVyeSBleGhhdXN0aXZlIGFu ZCBnZW5lcmFsbHkgd2VsbCB3cml0dGVuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SSBjb25zaWRlciBpdCByZWFk eSBmb3IgcHVibGljYXRpb24sIGFmdGVyIHRoZSBmb2xsb3dpbmcgJnF1b3Q7bml0cyZxdW90OyBo YXZlIGJlZW4gYWRkcmVzc2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMy43NXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDoyMy43NXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDoyMy43NXB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDIgbGZv MTt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4xLjM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIzLjc1cHQiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+JnF1b3Q7U3VwcG9ydCBmb3IgY29uZmlndXJlZCBzdWJzY3JpcHRpb25z IGlzIG9wdGlvbmFsLCB3aXRoIGl0cyBhdmFpbGFiaWxpdHkgYWR2ZXJ0aXNlZCB2aWEgYSZuYnNw OyBZQU5HIGZlYXR1cmUuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIzLjc1cHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+VGhlICZxdW90O2hvdyZxdW90OyBhc3BlY3Qgc2hvdWxkIGJlIGFsbHVkZWQgdG8gaGVy ZSwgZXZlbiB0aG91Z2ggc3Vic2VxdWVudCBzZWN0aW9ucyBhZGRyZXNzIHRoaXMgaW4gZGV0YWls PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDoyMy43NXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoaXMgd2lsbCBtYWtl IGZvciBiZXR0ZXIgcmVhZGFiaWxpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIzLjc1cHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIzLjc1cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 OmwwIGxldmVsMiBsZm8yO3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+DQo8IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZxdW90O0ZvciBjb25uZWN0 aW9ubGVzcyBvciBzdGF0ZWxlc3MgdHJhbnNwb3J0cyBsaWtlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIzLjc1cHQiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhUVFAs IGEgbGFjayBvZiByZWNlaXB0IGFja25vd2xlZGdtZW50IG9mIGEgc2VxdWVudGlhbCBzZXQgb2Y8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MjMuNzVwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgbm90aWZpY2F0aW9uIG1lc3NhZ2VzIGFuZC9vciBrZWVwLWFsaXZlcyBj YW4gYmUgdXNlZCB0byB0cmlnZ2VyIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjMuNzVwdCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGVybWluYXRpb24gb2YgYSBk eW5hbWljIHN1YnNjcmlwdGlvbi4mcXVvdDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjMuNzVwdCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5Ib3cgbG9uZyB0byB3YWl0PyBBbnkgaW5wdXRzIHRoZSBkcmFmdCB3 b3VsZCBsaWtlIHRvIHByb3ZpZGUgb3IgbGVhdmUgdG8gYW4gaW1wbGVtZW50YXRpb24/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjIzLjc1cHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIzLjc1cHQ7 dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMiBsZm8zO3ZlcnRpY2FsLWFsaWdu Om1pZGRsZSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPlNlY3Rpb24gMi40LjI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIzLjc1cHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+V291bGQgYmUgdXNlZnVsIHRvIGV4cGxhaW4gJnF1b3Q7d2hlbiByZXBsYXkgc3Rv cHMmcXVvdDssIGlmICZxdW90O3JlcGxheSZxdW90OyB3YXMgcmVxdWVzdGVkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMy43 NXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPklzIHRoaXMgZG9uZSBieSBtYW5kYXRpbmcg dGhhdCAmcXVvdDtzdG9wLXRpbWUmcXVvdDsgbXVzdCBiZSBwcm92aWRlZCBpZiByZXBsYXkgd2Fz IHJlcXVlc3RlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MjMuNzVwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TdWJz ZXF1ZW50IHNlY3Rpb25zIGFkZHJlc3MgdGhpcywgaG93ZXZlciB3b3VsZCBiZSB1c2VmdWwgdG8g YWxsdWRlIHRvIGluIHRoaXMgc2VjdGlvbuKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMy43NXB0Ij48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMy43NXB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMCBsZXZlbDIgbGZvNDt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPg0KPCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj40LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TZWN0aW9uIDIuNC4z OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDoyMy43NXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlBsZWFzZSBlbGFib3Jh dGUgb24gdGhlIHByZXNlbmNlIG9mIHRoZSBmb2xsb3dpbmcgaW4gdGhlIHNjaGVtYTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MjMuNzVwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0Mzst LS13IHN0b3AtdGltZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjMuNzVwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgeWFuZzpkYXRlLWFuZC10aW1lPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIzLjc1cHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIzLjc1cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 OmwwIGxldmVsMiBsZm81O3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+DQo8IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPjUuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwO1NlY3Rpb24gMi40 LjU6IG5vdCBjbGVhciB3aGVuIHRoaXMgd291bGQgYWN0dWFsbHkgZ2V0IHVzZWQsIElPV+KApndo YXQgd291bGQgY2F1c2UgdGhlcmUgdG8gYmUgc3VjaCBhIHNpdHVhdGlvbiB3aGVyZSB0aGUga2ls bC1zYnVzY3JpcHRpb24gbm90aWZjYXRpb24gd291bGQgbmVlZCB0byBiZSB1c2VkLiBXaGVuIHdp bGwgYSBzdWJzY3JpcHRpb24gbm90DQogYmUgYXNzb2NpYXRlZCB3aXRoIGEgdHJhbnNwb3J0IHNl c3Npb24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjIzLjc1cHQ7dmVydGljYWwtYWxpZ246bWlkZGxlIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMy43NXB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMCBsZXZlbDIgbGZvNTt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPg0KPCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj42LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4yLjQuNjogPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjUwLjc1cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMyBsZm82O3ZlcnRp Y2FsLWFsaWduOm1pZGRsZSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmEuPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPndoeSBoYXZlIGVycm9ycyB3LnIudC4gJnF1b3Q7d2VpZ2h0aW5n JnF1b3Q7LCBhbmQgJnF1b3Q7ZGVwZW5kZW5jeSZxdW90OyBub3QgYmVlbiBpbmNsdWRlZD88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6NTAuNzVwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwzIGxmbzY7dmVy dGljYWwtYWxpZ246bWlkZGxlIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Yi48c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+TnVtZXJlZCBwb2ludHMgMS8yLzMgYXJlIGJldHRlciBjb21tdW5pY2F0 ZWQgdmlhIGEgdGFibGUgdG8gYXZvaWQgdGhlIGR1cGxpY2F0ZWQgdGV4dC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTAuNzVw dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5CcmV2aXR5IG1ha2VzIGZvciBiZXR0ZXIgcmVh ZGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6NTAuNzVwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MjMuNzVwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzc7dmVy dGljYWwtYWxpZ246bWlkZGxlIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Ny48c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+U2VjdGlvbnMgMi41LjIgLSAyLjUuNzogdGhlc2UgYXJlIGEg Yml0IG9mIGEgZHJhZyB0byByZWFkIHRocm91Z2gsIGluIGFuIGFscmVhZHkgbGFyZ2UgZG9jdW1l bnQuIFJlYWRhYmlsaXR5IGZvciB0aGVzZSBzZWN0aW9ucyB3b3VsZCBiZSBncmVhdGx5IGltcHJv dmVkIGlmIHRoZSBub3RpZmljYXRpb25zIHRoYXQgZ2V0IHNlbnQgb3V0IHdlcmUgbGlzdGVkDQog cGljdG9yaWFsbHkgb3IgaW4gYSB0YWJ1bGFyIGZhc2hpb24gYnkgZW5oYW5jaW5nIHRoZSBzaW1w bGUgRlNNcyBsaXN0ZWQgaW4gc2VjdGlvbiAyLjUuMS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjMuNzVwdCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjMuNzVwdDt0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzg7dmVydGljYWwtYWxpZ246bWlkZGxlIj4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+OC48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+U2VjdGlvbiA1 LjQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjIzLjc1cHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+JnF1b3Q7VGhpcyBj YW4gYmUgYWNjb21wbGlzaCBieSBlc3RhYmxpc2hpbmcmcXVvdDsgLSZndDsgJnF1b3Q7VGhpcyBj YW4gYmUgYWNjb21wbGlzaGVkIGJ5IGVzdGFibGlzaGluZyZxdW90OzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMy43NXB0Ij48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UmVnYXJkczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+UmF2aTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDoyMy43NXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BYAPR05MB440858805FC9DE9710292BF9AB2B0BYAPR05MB4408namp_-- From nobody Mon Apr 15 14:05:40 2019 Return-Path: <0100016a22d1b6e2-73101afa-6a8a-44b0-9295-1af1595008ce-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5582612046B for ; Mon, 15 Apr 2019 14:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTv8RvcYR3zI for ; Mon, 15 Apr 2019 14:05:32 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC3E01203DB for ; Mon, 15 Apr 2019 14:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1555362330; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=RbYLHOjxO+/CMwgpsL4ex/msj/UZw1CW4duXPeVpyhM=; b=gxSjoQyv7O0HVLrbTpMhmNBlMBQQXBBTcVJnsKRuNT+ssPMLKny5SxQdQrlbVF+w FzhehL/KcY12T4J+cV8iEAzVTMMWBjlBqAq2XxBa41W+u86g6lhRqZBEsxcOpjqhXjg /WF6OgWBq3gMaRbF6Czt/HpnhJl9vw7/y6x3H85A= From: Kent Watsen Message-ID: <0100016a22d1b6e2-73101afa-6a8a-44b0-9295-1af1595008ce-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B19D34EF-32DA-49C6-AD8C-BFD36C845ADB" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 15 Apr 2019 21:05:30 +0000 In-Reply-To: <20190408154613.ytibxwvjurfcwinp@anna.jacobs.jacobs-university.de> Cc: "netconf@ietf.org" To: Juergen Schoenwaelder References: <01000169fa45ea88-505cd325-94b7-4d48-a529-448a9905f534-000000@email.amazonses.com> <20190408154613.ytibxwvjurfcwinp@anna.jacobs.jacobs-university.de> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.15-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] overview of updates and current issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 21:05:37 -0000 --Apple-Mail=_B19D34EF-32DA-49C6-AD8C-BFD36C845ADB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Juergen, Thanks for your response. >> Current Issues: >>=20 >> 1. Regarding the "demux containers": >>=20 >> Pros: >> - now the NC/RC models look better >> - a convenient place to have a nacm:default-deny-write >>=20 >> Cons: >> - seems overbearing for general use >>=20 >> Question: >>=20 >> Would it be better to revert and instead wrap each "uses" >> statement in the NC/RC models with a container? >>=20 >> Pros: maximum flexibility >> Cons: less consistency? >=20 > What exactly are the demux containers? You mean the > and containers? Yes. This is what what meant by: "Added a top-level "demux container" inside the top-level grouping. By "demux", I'm referring to the namespace problem discussed @104." about 10 lines above. > I have no strong opinion, they may be ok although things get a bit = more verbose. On the "Cons" side, I'm calling the containers = "--parameters". I question is if this is a = good name in all contexts. By removing the "demux container", it lets = the consumer decide what to call it. This brings us to the "less = consistency?" comment; of course there would be little consistency but, = do we care? Regarding "a convenient place to have a nacm:default-deny-write", I = don't see anywhere in RFC 8341 that nacm:default-deny-write can't be = used in a grouping, but it will impact the parent... If the parent has = other descendents besides from the grouping, those descendents would = likely be impacted too, right? Do we care? If we put = nacm:default-deny-write under the grouping statement, then I think that = it subtly enforces consumers to create their own wrapper containers (as = opposed to mixing the descendents in with other nodes). Alternately, = we could float the "if-feature" statement down to each descendent of the = grouping. Not ideal, but works...? >> 2. Only in the RESTCONF draft, http proxy-server weirdness >>=20 >> a) in the "ietf-restconf-client", there's an unwanted = "proxy-server" >> definition (middle of page 43): >>=20 >> = /restconf-client/listen/endpoint/https/http-client-parameters/proxy-server= >>=20 >> An HTTP client that receives a call-home connection does NOT = need >> to initiate a connection and therefore there never is a desire = to >> configure a proxy server, but here it is! >>=20 >> It's here because the "ieft-http-client" grouping defines it, = but >> when that grouping is used, neither "refine" nor "augment" can >> remove the definition. >>=20 >> Sure, a "must" could disable it, but it still shows in the tree >> diagram, which is undesirable... >>=20 >>=20 >> b)in the "ietf-restconf-server", there's a missing "proxy-server" >> definition (bottom of page 48 ): >>=20 >> /restconf-server/call-home/restconf-client/endpoints/endpoint/\ >> https/http-client-parameters/ >>=20 >> An HTTP server that establishes a call-home connection needs >> to initiate a connection and therefore there is a desire to >> configure a proxy server, but the config node is missing! >>=20 >> This is because the "ieft-http-server" grouping doesn't >> defines a proxy-server node (because servers typically >> never need to go through a proxy so, when that grouping >> is used, the definition is missing. >>=20 >> Sure, we could augment it in, but coupled with the above, >> maybe there's a better answer? >>=20 >> What to do? >=20 > No idea. This remains an open issue. >> 3. In either the NETCONF and RESTCONF drafts, does it matter at all >> where a 'must' statement is located, especially if they refer to >> nodes that are conditional by "if-feature" statements? >>=20 >> i.e., search for "case periodic-connection" >>=20 >> Should the "must" statements be located somewhere else? >=20 > I actually wonder whether this must is really desirable. What breaks > if I have TCP keep-alives turned on for a periodic call-home = connection? > Perhaps I want to enable keep-alives to work around a broken firewall. The point of the periodic connection, from which it gets its name, is = that it "frequently" sets-up and tears-down. Thus is self-healing in = the case of a network drop. Our WG's primary use-case for keepalives is a device that has been = configured to periodically call-home (perhaps every midnight), in case = its controller application has any config pending for it (depositing = logs is assumed to be out-of-band). One can imagine the controller = performing a number of steps, potentially with delays between the steps. The ietf-[net/rest]conf-server-grouping groupings say this about the = "periodic-connection" presence container (under "call-home"): "Periodically connect to the NETCONF client. The NETCONF client should close the underlying TCP connection upon completing planned activities. So, if the connection is dropped (do to a lack a keepalives), should the = server interpret that as "the client completed planned activities", and = therefore doesn't need to connect again until next midnight? Separately (not related to the above), the = ietf-[net/rest]conf-client-grouping groupings say (under "initiate"): "Periodically connect to the NETCONF server. The NETCONF server should close the underlying TCP connection upon completing planned activities. which might be right, but somehow it feels odd that the client wouldn't = always do close the connection... >> 4) Only in the NETCONF draft, Section 5 contains the old "Design >> Considerations" text from ~5 years ago. >>=20 >> The idea of removing is was discussed a while back, and someone >> said it was worth keeping... >>=20 >> I'm thinking again to remove it, but rather to deleting it, I'm >> now thinking maybe we could *move* it to an Informational draft: >>=20 >> "Architecture for the Collection of Client and Server Models" >>=20 >> that could also contain a picture like this: >>=20 >> crypto-types >> ^ ^ >> / \ >> / \ >> trust-anchors keystore >> ^ ^------+ ^ >> | \ | >> | +-----------+ >> | / \ >> tcp-client-server ssh-client-server tls-client-server = http-client-server >> ^ ^ ^ ^ ^ = ^ >> | | | | | = | >> | | | +----------+ | = | >> | | | | | = | >> | | | | | = | >> | +--------------|-------|------------+ | = | >> | | | | | = | >> | | | | | = | >> +--------------+ | | | | = +--------+ >> | | | | | | >> | | | | | | >> netconf-client-server restconf-client-server >>=20 >>=20 >>=20 >>=20 >> If there is desire, it would be best to do it now so that all of >> the client/server drafts could reference it. Thus, whichever draft >> a reader begins with, their attention is drawn to the collection and >> thus they can see how the part fits into the whole. >=20 > I like the modularization you are doing but perhaps the problem is > that the packaging of this stuff into documents makes things hard to > follow. For example, why not define crypto-types, trust-anchors, and > keystore into one document? Then this document could explain the top > part of your figure. One could perhaps also put tcp-client-server, > tls-client-server, and http-client-server together, perhaps even > adding ssh-client-server to it. Note that you always revise the > modules are different speeds later on since you can have future RFCs > take over control over a specific module. I'm not interested in doing this work, especially given where we are = now. If there is consensus in the WG, I request someone take over = being Editor for awhile. > That said, I believe we need to document the design of this somewhere > so that others use it instead of rolling their own solutions. So my > preference likely is to do both, merge some closely related modules > into single documents and have a document that explains the overall > design and how it is to be used by others. I support "have a document that explains the overall design and how it = is to be used by others", but I would like someone else to pick up the = pen. In the meanwhile, I think that it is safe to delete Section 5 = (Design Considerations) from the netconf-client-server draft. Someone = can grab it from the archives when needed. Kent --Apple-Mail=_B19D34EF-32DA-49C6-AD8C-BFD36C845ADB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Hi Juergen,

Thanks for your response.


Current Issues:

1. Regarding the = "demux containers":

=     Pros:
=       - now the NC/RC models look = better
      - a convenient = place to have a nacm:default-deny-write

=     Cons:
=       - seems overbearing for general = use

  Question:

    Would it be better to revert and = instead wrap each "uses"
=     statement in the NC/RC models with a = container?

=        Pros: maximum flexibility
       Cons: less = consistency?

What exactly are = the demux containers? You mean the
<tcp-client-parameters> and = <tls-client-parameters> containers? =

Yes.  This = is what what meant by:

  =  "Added a top-level "demux container" inside the top-level = grouping.
    By "demux", I'm referring to the = namespace problem discussed @104."

about 10 lines = above.



I have no strong opinion, they may be ok = although things get a bit more verbose.

On = the "Cons" side, I'm calling the containers = "<protocol>-<client/server>-parameters".  I question is = if this is a good name in all contexts.  By removing the "demux = container",  it lets the consumer decide what to call it. =  This brings us to the "less consistency?" comment;  of course = there would be little consistency but, do we care?

Regarding "a convenient place to have a = nacm:default-deny-write", I don't see anywhere in RFC 8341 that = nacm:default-deny-write can't be used in a grouping, but it will impact = the parent...  If the parent has other descendents besides from the = grouping, those descendents would likely be impacted too, right?   = Do we care?  If we put nacm:default-deny-write under the = grouping statement, then I think that it subtly enforces consumers to = create their own wrapper containers (as opposed to mixing the = descendents in with other nodes).   Alternately, we could float the = "if-feature" statement down to each descendent of the grouping. =  Not ideal, but works...?


2. Only in the RESTCONF = draft, http proxy-server weirdness

=   a) in the "ietf-restconf-client", there's an unwanted = "proxy-server"
     definition =  (middle of page 43):

=      /restconf-client/listen/endpoint/https/http-= client-parameters/proxy-server

=      An HTTP client that receives a call-home = connection does NOT need
     to = initiate a connection and therefore there never is a desire to
     configure a proxy server, but = here it is!

=      It's here because the "ieft-http-client" = grouping defines it, but
=      when that grouping is used, neither = "refine" nor "augment" can
=      remove the definition.

     Sure, a "must" could disable = it, but it still shows in the tree
=      diagram, which is undesirable...


 b)in the = "ietf-restconf-server", there's a missing "proxy-server"
=      definition  (bottom of page 48 ):

=      /restconf-server/call-home/restconf-client/e= ndpoints/endpoint/\
=      https/http-client-parameters/<missing:pro= xy-server/>

=      An HTTP server that establishes a = call-home connection needs
=      to initiate a connection and therefore = there is a desire to
=      configure a proxy server, but the config = node is missing!

=      This is because the "ieft-http-server" = grouping doesn't
     defines a = proxy-server node (because servers typically
=      never need to go through a proxy so, when = that grouping
     is used, the = definition is missing.

=      Sure, we could augment it in, but coupled = with the above,
     maybe = there's a better answer?

 What to = do?

No idea.

This = remains an open issue.


3. In either the NETCONF = and RESTCONF drafts, does it matter at all
=   where a 'must' statement is located, especially if they = refer to
  nodes that are conditional by = "if-feature" statements?

=      i.e., search for "case = periodic-connection"

  Should = the "must" statements be located somewhere else?

I actually wonder whether this = must is really desirable. What breaks
if I have TCP = keep-alives turned on for a periodic call-home connection?
Perhaps I want to enable keep-alives to work around a broken = firewall.

The point of the periodic connection, from which = it gets its name, is that it "frequently" sets-up and tears-down. =  Thus is self-healing in the case of a network drop.

Our WG's primary use-case for keepalives is a = device that has been configured to periodically call-home (perhaps every = midnight), in case its controller application has any config pending for = it (depositing logs is assumed to be out-of-band).    One can = imagine the controller performing a number of steps, potentially with = delays between the steps.

The = ietf-[net/rest]conf-server-grouping groupings say this about the = "periodic-connection" presence container (under "call-home"):

      =                "Periodically = connect to the NETCONF client.  The
  =                     = NETCONF client should close the underlying TCP
 =                     = connection upon completing planned activities.

So, if the connection is dropped (do to a = lack a keepalives), should the server interpret that as "the client = completed planned activities", and therefore doesn't need to connect = again until next midnight?


Separately (not related to the above), the = ietf-[net/rest]conf-client-grouping groupings say (under = "initiate"):

  =                   =  "Periodically connect to the NETCONF server.  The
                =       NETCONF server should close the underlying = TCP
            =           connection upon completing planned = activities.

which might be right, = but somehow it feels odd that the client wouldn't always do close the = connection...




4) Only in the NETCONF = draft, Section 5 contains the old  "Design
=   Considerations" text from ~5 years ago.

  The idea of removing is was discussed a while = back, and someone
  said it was worth = keeping...

  I'm thinking again = to remove it, but rather to deleting it, I'm
=   now thinking maybe we could *move* it to an Informational = draft:

=     "Architecture for the Collection of Client and = Server Models"

  that could also = contain a picture like this:

=             &n= bsp;           &nbs= p;            =   crypto-types
=             &n= bsp;           &nbs= p;            =     ^      ^
=             &n= bsp;           &nbs= p;            =    /        \
=             &n= bsp;           &nbs= p;            =   /          \
=             &n= bsp;           &nbs= p;    trust-anchors =       keystore
=             &n= bsp;           &nbs= p;       ^ =      ^------+    ^
=             &n= bsp;           &nbs= p;       | =             &n= bsp;\   |
=             &n= bsp;           &nbs= p;       | =      +-----------+
=             &n= bsp;           &nbs= p;       |     / =          \
= tcp-client-server     ssh-client-server =      tls-client-server =     http-client-server
=       ^      ^ =             &n= bsp;^ =             &n= bsp;    ^ =           ^ =             &n= bsp; ^
      | =      | =             &n= bsp;| =             &n= bsp;    | =           | =             &n= bsp; |
      | =      | =             &n= bsp;|       +----------+ =           | =             &n= bsp; |
      | =      | =             &n= bsp;|       | =             &n= bsp;        | =             &n= bsp; |
      | =      | =             &n= bsp;|       | =             &n= bsp;        | =             &n= bsp; |
      | =      +--------------|-------|------------+ =         | =             &n= bsp; |
      | =             &n= bsp;       | =       | =            | =         | =             &n= bsp; |
      | =             &n= bsp;       | =       | =            | =         | =             &n= bsp; |
=       +--------------+ =      |       | =            | =         | =      +--------+
=             &n= bsp;        | =      |       | =            | =         | =      |
=             &n= bsp;        | =      |       | =            | =         | =      |
=             &n= bsp;     netconf-client-server =        restconf-client-server




=  If there is desire, it would be best to do it now so that all = of
 the client/server drafts could reference it. =  Thus, whichever draft
 a reader begins with, = their attention is drawn to the collection and
 thus = they can see how the part fits into the whole.

I like the modularization you are = doing but perhaps the problem is
that the packaging of = this stuff into documents makes things hard to
follow. For = example, why not define crypto-types, trust-anchors, and
keystore into one document? Then this document could explain = the top
part of your figure. One could perhaps also put = tcp-client-server,
tls-client-server, and = http-client-server together, perhaps even
adding = ssh-client-server to it. Note that you always revise the
modules are different speeds later on since you can have = future RFCs
take over control over a specific module.

I'm = not interested in doing this work, especially given where we are now. =   If there is consensus in the WG, I request someone take over = being Editor for awhile.


That said, I believe we need to document the design of this = somewhere
so that others use it instead of rolling their = own solutions. So my
preference likely is to do both, = merge some closely related modules
into single documents = and have a document that explains the overall
design and = how it is to be used by others.


I support "have a = document that explains the overall design and how it is to be used by = others", but I would like someone else to pick up the pen.  In the = meanwhile, I think that it is safe to delete Section 5 (Design = Considerations) from the netconf-client-server draft.   Someone can = grab it from the archives when needed.


Kent


= --Apple-Mail=_B19D34EF-32DA-49C6-AD8C-BFD36C845ADB-- From nobody Mon Apr 15 14:34:58 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B69120241 for ; Mon, 15 Apr 2019 14:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXvwuWEAbnDC for ; Mon, 15 Apr 2019 14:34:52 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8AF120233 for ; Mon, 15 Apr 2019 14:34:52 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 930CE35E; Mon, 15 Apr 2019 23:34:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id e9NXLwIUdiOA; Mon, 15 Apr 2019 23:34:50 +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 atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 15 Apr 2019 23:34:50 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 53354200C9; Mon, 15 Apr 2019 23:34:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id src8lKNGwqH4; Mon, 15 Apr 2019 23:34:49 +0200 (CEST) Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id D31D8200C5; Mon, 15 Apr 2019 23:34:49 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Mon, 15 Apr 2019 23:34:49 +0200 Received: by anna.localdomain (Postfix, from userid 501) id C4E2A30084387F; Mon, 15 Apr 2019 23:34:48 +0200 (CEST) Date: Mon, 15 Apr 2019 23:34:48 +0200 From: Juergen Schoenwaelder To: Kent Watsen CC: "netconf@ietf.org" Message-ID: <20190415213448.krsi3ma3fds2u4hh@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: <01000169fa45ea88-505cd325-94b7-4d48-a529-448a9905f534-000000@email.amazonses.com> <20190408154613.ytibxwvjurfcwinp@anna.jacobs.jacobs-university.de> <0100016a22d1b6e2-73101afa-6a8a-44b0-9295-1af1595008ce-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <0100016a22d1b6e2-73101afa-6a8a-44b0-9295-1af1595008ce-000000@email.amazonses.com> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netconf] overview of updates and current issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 21:34:56 -0000 Inline... On Mon, Apr 15, 2019 at 09:05:30PM +0000, Kent Watsen wrote: > > >> Current Issues: > >> > >> 1. Regarding the "demux containers": > >> > >> Pros: > >> - now the NC/RC models look better > >> - a convenient place to have a nacm:default-deny-write > >> > >> Cons: > >> - seems overbearing for general use > >> > >> Question: > >> > >> Would it be better to revert and instead wrap each "uses" > >> statement in the NC/RC models with a container? > >> > >> Pros: maximum flexibility > >> Cons: less consistency? > > > > What exactly are the demux containers? You mean the > > and containers? > > Yes. This is what what meant by: > > "Added a top-level "demux container" inside the top-level grouping. > By "demux", I'm referring to the namespace problem discussed @104." > > about 10 lines above. > > > > > I have no strong opinion, they may be ok although things get a bit more verbose. > > On the "Cons" side, I'm calling the containers "--parameters". I question is if this is a good name in all contexts. By removing the "demux container", it lets the consumer decide what to call it. This brings us to the "less consistency?" comment; of course there would be little consistency but, do we care? > > Regarding "a convenient place to have a nacm:default-deny-write", I don't see anywhere in RFC 8341 that nacm:default-deny-write can't be used in a grouping, but it will impact the parent... If the parent has other descendents besides from the grouping, those descendents would likely be impacted too, right? Do we care? If we put nacm:default-deny-write under the grouping statement, then I think that it subtly enforces consumers to create their own wrapper containers (as opposed to mixing the descendents in with other nodes). Alternately, we could float the "if-feature" statement down to each descendent of the grouping. Not ideal, but works...? > Perhaps instead of being tricky (subtly enforcing consumers to create their own wrapper), why not move the nacm:default-deny-write to the leafs? This seems less subtle and more robust. > >> 3. In either the NETCONF and RESTCONF drafts, does it matter at all > >> where a 'must' statement is located, especially if they refer to > >> nodes that are conditional by "if-feature" statements? > >> > >> i.e., search for "case periodic-connection" > >> > >> Should the "must" statements be located somewhere else? > > > > I actually wonder whether this must is really desirable. What breaks > > if I have TCP keep-alives turned on for a periodic call-home connection? > > Perhaps I want to enable keep-alives to work around a broken firewall. > > The point of the periodic connection, from which it gets its name, is that it "frequently" sets-up and tears-down. Thus is self-healing in the case of a network drop. > > Our WG's primary use-case for keepalives is a device that has been configured to periodically call-home (perhaps every midnight), in case its controller application has any config pending for it (depositing logs is assumed to be out-of-band). One can imagine the controller performing a number of steps, potentially with delays between the steps. The point is that we do not know what will happen once the server has called home - so how can we be sure that keep alives never make sense with call-home? > The ietf-[net/rest]conf-server-grouping groupings say this about the "periodic-connection" presence container (under "call-home"): > > "Periodically connect to the NETCONF client. The > NETCONF client should close the underlying TCP > connection upon completing planned activities. > > So, if the connection is dropped (do to a lack a keepalives), should the server interpret that as "the client completed planned activities", and therefore doesn't need to connect again until next midnight? The server likely does not care, at least likely not more than without call-home. I assume that keep alives are more interesting for a client that is not constantly talking to the server but likes to keep the session open (for whatever reason). > Separately (not related to the above), the ietf-[net/rest]conf-client-grouping groupings say (under "initiate"): > > "Periodically connect to the NETCONF server. The > NETCONF server should close the underlying TCP > connection upon completing planned activities. > > which might be right, but somehow it feels odd that the client wouldn't always do close the connection... > For the use cases I have in mind for this, the server would not really know when to close the connection since the client would take control over what is going on. This may, however, be different from a call-home to stream notifications. Perhaps we should say less. One thing that comes to mind is whether a new callhome attempt should be made in situations where the previous callhome is still alive. Do we want to say something about this or not? /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 Apr 16 10:57:09 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626821205D7; Tue, 16 Apr 2019 10:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGSiERZyGyFU; Tue, 16 Apr 2019 10:56:56 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 064191204A3; Tue, 16 Apr 2019 10:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36988; q=dns/txt; s=iport; t=1555437415; x=1556647015; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ek+RAyr00gGDKZDC2NSF7GKdSXUUr3PBXEy5gTkWbmc=; b=YYlX8qDM27lpp3uia9afWGpli6gHpzuqgoURwN+eSY+6c7D9t+CpNXON 85vjRCzJU/X/cf6H5OwFIxCsfLgCITrn+4OUPaBQDWpQCK8XTMK7OxcW2 PVLcDZ7C13QibYM7job9I8hO2zIEF3fX6ZvKPjSxN9+h249QQy+WN8aED 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAB7FrZc/5pdJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDlMFKmiBBCgKhASIHI0emEmBew4BASOESgI?= =?us-ascii?q?XhXAjNAkOAQMBAQoBAgECbRwMhUoBAQEEIwQGSgIQAgEIEQMBAQEOEwoCAgI?= =?us-ascii?q?wHQgBAQQBDQUIgk9MgR1rD6pofDOKMIEyAYRghmkXgUA/gRGDEj6CVgsCggG?= =?us-ascii?q?CaoJXA4pNEhuCLYQ6h2OMD2MJAoIGhTpRjAYjgghdhT6DZohtiyVEhiyNcQI?= =?us-ascii?q?RFYEwDRI4gVZwFYMnCYsEhT9BMQGPUIEhAQE?= X-IronPort-AV: E=Sophos;i="5.60,358,1549929600"; d="scan'208,217";a="548391154" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Apr 2019 17:56:54 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x3GHurjn019791 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 16 Apr 2019 17:56:54 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.1473.3; Tue, 16 Apr 2019 13:56:52 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Tue, 16 Apr 2019 13:56:53 -0400 From: "Eric Voit (evoit)" To: Ravi Singh , Routing ADs CC: Routing Directorate , "draft-ietf-netconf-subscribed-notifications.all@ietf.org" , "netconf@ietf.org" Thread-Topic: RtgDir review: draft-ietf-netconf-subscribed-notifications Thread-Index: AdTzIvcBe9EXeFb2ThSKUq3KYi0U2QAgfXdQ Date: Tue, 16 Apr 2019 17:56:53 +0000 Message-ID: <86a1564f43fc46169079f83dec3cbbba@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.154.160.56] Content-Type: multipart/alternative; boundary="_000_86a1564f43fc46169079f83dec3cbbbaXCHRTP013ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.152, xch-rtp-012.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [netconf] RtgDir review: draft-ietf-netconf-subscribed-notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 17:57:07 -0000 --_000_86a1564f43fc46169079f83dec3cbbbaXCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmF2aSwNCg0KVGhhbmtzIHZlcnkgbXVjaCBmb3IgdGhlIHJldmlldy4gIEl0IGlzIGFwcHJl Y2lhdGVkLiAgVGhvdWdodHMgaW4tbGluZS4uLg0KDQpGcm9tOiBSYXZpIFNpbmdoIDxyYXZpc0Bq dW5pcGVyLm5ldD4NClNlbnQ6IFN1bmRheSwgQXByaWwgMTQsIDIwMTkgODo0MCBQTQ0KVG86IFJv dXRpbmcgQURzIDxydGctYWRzQHRvb2xzLmlldGYub3JnPg0KQ2M6IFJvdXRpbmcgRGlyZWN0b3Jh dGUgPHJ0Zy1kaXJAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3Rp ZmljYXRpb25zLmFsbEBpZXRmLm9yZzsgbmV0Y29uZkBpZXRmLm9yZw0KU3ViamVjdDogUnRnRGly IHJldmlldzogZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucw0KDQpI ZWxsbywNCg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUg cmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRv IHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFz cyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBv biBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlk ZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJv dXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMudG9v bHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcg0KDQpBbHRob3VnaCB0aGVzZSBj b21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQg d291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFu eSBvdGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3Ry aXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhl IGRyYWZ0Lg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZp Y2F0aW9ucw0KUmV2aWV3ZXI6IFJhdmkgU2luZ2gNClJldmlldyBEYXRlOiAwNC8xMi8yMDE5DQpJ RVRGIExDIEVuZCBEYXRlOiBkYXRlLWlmLWtub3duDQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJk cyBUcmFjaw0KDQpTdW1tYXJ5Og0KVGhpcyBkb2N1bWVudCBpcyBiYXNpY2FsbHkgcmVhZHkgZm9y IHB1YmxpY2F0aW9uLCBidXQgaGFzIG5pdHMgdGhhdCBzaG91bGQgYmUgY29uc2lkZXJlZCBwcmlv ciB0byBwdWJsaWNhdGlvbi4NCg0KQ29tbWVudHM6DQpJJ3ZlIHJldmlld2VkIHRoZSBkcmFmdC4N Ckl0IGlzIHZlcnkgZXhoYXVzdGl2ZSBhbmQgZ2VuZXJhbGx5IHdlbGwgd3JpdHRlbi4NCkkgY29u c2lkZXIgaXQgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLCBhZnRlciB0aGUgZm9sbG93aW5nICJuaXRz IiBoYXZlIGJlZW4gYWRkcmVzc2VkLg0KDQoNCjEuICAgICAgIDEuMzoNCiJTdXBwb3J0IGZvciBj b25maWd1cmVkIHN1YnNjcmlwdGlvbnMgaXMgb3B0aW9uYWwsIHdpdGggaXRzIGF2YWlsYWJpbGl0 eSBhZHZlcnRpc2VkIHZpYSBhICBZQU5HIGZlYXR1cmUuIg0KVGhlICJob3ciIGFzcGVjdCBzaG91 bGQgYmUgYWxsdWRlZCB0byBoZXJlLCBldmVuIHRob3VnaCBzdWJzZXF1ZW50IHNlY3Rpb25zIGFk ZHJlc3MgdGhpcyBpbiBkZXRhaWw/DQpUaGlzIHdpbGwgbWFrZSBmb3IgYmV0dGVyIHJlYWRhYmls aXR5Lg0KPGVyaWM+IEFzIGNhcGFiaWxpdHkgYWR2ZXJ0aXNlbWVudCBpcyBhIGJhc2ljIGluZnJh c3RydWN0dXJlIGNhcGFiaWxpdHkgb2YgWUFORyBpdHNlbGYsIEkgc3VzcGVjdCB0aGF0IHB1dHRp bmcgdGhlc2UgZGV0YWlscyBoZXJlIHdvdWxkIGJlIGZhaXJseSBvYnZpb3VzIHRvIGRldmVsb3Bl cnMgYW5kIG9wZXJhdG9ycyBmYW1pbGlhciB0byBZQU5HLiAgTm90ZTogYXMgYSBkZXNpZ24gb2Jq ZWN0aXZlLCB3ZSBoYXZlIGJlZW4gYXR0ZW1wdGluZyB0byBrZWVwIHRoZSBkb2N1bWVudHMgc21h bGxlciBieSBub3QgYXJ0aWN1bGF0aW5nIGFjY2VwdGVkL2NvcmUgY2FwYWJpbGl0aWVzIG9mIHRo ZSBiYXNlIFlBTkcgc3VpdGUgb2YgZHJhZnRzLg0KDQoyLiAgICAgICAiRm9yIGNvbm5lY3Rpb25s ZXNzIG9yIHN0YXRlbGVzcyB0cmFuc3BvcnRzIGxpa2UNCiAgICAgIEhUVFAsIGEgbGFjayBvZiBy ZWNlaXB0IGFja25vd2xlZGdtZW50IG9mIGEgc2VxdWVudGlhbCBzZXQgb2YNCiAgICAgIG5vdGlm aWNhdGlvbiBtZXNzYWdlcyBhbmQvb3Iga2VlcC1hbGl2ZXMgY2FuIGJlIHVzZWQgdG8gdHJpZ2dl ciBhDQogICAgICB0ZXJtaW5hdGlvbiBvZiBhIGR5bmFtaWMgc3Vic2NyaXB0aW9uLiINCkhvdyBs b25nIHRvIHdhaXQ/IEFueSBpbnB1dHMgdGhlIGRyYWZ0IHdvdWxkIGxpa2UgdG8gcHJvdmlkZSBv ciBsZWF2ZSB0byBhbiBpbXBsZW1lbnRhdGlvbj8NCg0KPGVyaWM+IFRoaXMgZHJhZnQgaGFzIHNw ZWNpZmljIHRyYW5zcG9ydCBkcmFmdHMgd2hpY2ggYXJlIGdvaW5nIHRocm91Z2ggSUVTRyByZXZp ZXdzIGluIHBhcmFsbGVsIHRvIHRoaXMgb25lLiAgU3BlY2lmaWMgdG8geW91ciBxdWVzdGlvbiBv biBjb25uZWN0aW9ubGVzcyB0cmFuc3BvcnQsIGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1u b3RpZi0xMyBTZWN0aW9uIDMuMSBwcm92aWRlcyBndWlkYW5jZSBmb3IgUkVTVENPTkYvSFRUUCBj b25uZWN0aW9ubGVzcyBjb25maWd1cmF0aW9uIGFuZCBvcGVyYXRpb24uICBFLmcuIFRMUyBoZWFy dGJlYXQgW1JGQzY1MjBdIGlzIHJlY29tbWVuZGVkLg0KDQozLiAgICAgICBTZWN0aW9uIDIuNC4y Og0KV291bGQgYmUgdXNlZnVsIHRvIGV4cGxhaW4gIndoZW4gcmVwbGF5IHN0b3BzIiwgaWYgInJl cGxheSIgd2FzIHJlcXVlc3RlZC4NCklzIHRoaXMgZG9uZSBieSBtYW5kYXRpbmcgdGhhdCAic3Rv cC10aW1lIiBtdXN0IGJlIHByb3ZpZGVkIGlmIHJlcGxheSB3YXMgcmVxdWVzdGVkPw0KU3Vic2Vx dWVudCBzZWN0aW9ucyBhZGRyZXNzIHRoaXMsIGhvd2V2ZXIgd291bGQgYmUgdXNlZnVsIHRvIGFs bHVkZSB0byBpbiB0aGlzIHNlY3Rpb27igKYNCjxlcmljPiBJdCBjb3VsZCBiZSBkdWUgdG8gcmVh Y2hpbmcgYSBzdG9wIHRpbWUsIG9yIHdoZW4gdGhlIHJlcGxheSBidWZmZXIgaXMgbm93IGVtcHR5 LCBhbmQgdGhlIGN1cnJlbnQgdGltZSBoYXMgYmVlbiByZWFjaGVkLiAgRG8geW91IHdhbnQgbWUg dG8gYWRkIGEgc2VudGVuY2Ugd2hpY2ggZGVzY3JpYmVzIHRoZSBwdXJwb3NlIGFzOiDigJxUaGlz IGFsbG93cyBhIHRhcmdldGVkIGhpc3Rvcnkgb2YgZXZlbnQgcmVjb3JkcyB0byBiZSBleHRyYWN0 ZWQu4oCdDQoNCg0KNC4gICAgICAgU2VjdGlvbiAyLjQuMzoNClBsZWFzZSBlbGFib3JhdGUgb24g dGhlIHByZXNlbmNlIG9mIHRoZSBmb2xsb3dpbmcgaW4gdGhlIHNjaGVtYToNCiAgICAgICAgICAg ICArLS0tdyBzdG9wLXRpbWU/DQogICAgICAgICAgICAgICAgICAgICB5YW5nOmRhdGUtYW5kLXRp bWUNCg0KPGVyaWM+ICAgVGhpcyBpcyBvbmUgbGVhZiBvZiBtYW55IHVuZGVyIHRoZSBtb2RpZnkg c3Vic2NyaXB0aW9uIFJQQy4gICBUaGlzIGxlYWYgbWVhbnMgdGhhdCBhIHN1YnNjcmlwdGlvbiBp cyBiZWluZyBtb2RpZmllZCB0byBlbmQgYXQgYSB0YXJnZXRlZCBzdG9wIHRpbWUuICAgV2hpbGUg aXQgY291bGQgYmUgcG9zc2libGUgdG8gd3JpdGUgYSBtZWFuaW5nIGZvciBldmVyeSBsZWFmIHdp dGhpbiB0aGUgdHJlZSwgd2UgZGVjaWRlZCB0aGF0IGRvaW5nIHRoaXMgZm9yIGV2ZXJ5IGxlYWYg d291bGQgaGF2ZSBtYWRlIHRoZSBkb2N1bWVudCB2ZXJ5IGxhcmdlLiAgVGhlcmUgaXMgYSBkZXNj cmlwdGlvbiBvZiB3aGF0IHN0b3AtdGltZSBkb2VzIGluIHRoZSBwcmV2aW91cyBzZWN0aW9uLg0K DQoNCjUuICAgICAgICBTZWN0aW9uIDIuNC41OiBub3QgY2xlYXIgd2hlbiB0aGlzIHdvdWxkIGFj dHVhbGx5IGdldCB1c2VkLCBJT1figKZ3aGF0IHdvdWxkIGNhdXNlIHRoZXJlIHRvIGJlIHN1Y2gg YSBzaXR1YXRpb24gd2hlcmUgdGhlIGtpbGwtc2J1c2NyaXB0aW9uIG5vdGlmY2F0aW9uIHdvdWxk IG5lZWQgdG8gYmUgdXNlZC4gV2hlbiB3aWxsIGEgc3Vic2NyaXB0aW9uIG5vdCBiZSBhc3NvY2lh dGVkIHdpdGggYSB0cmFuc3BvcnQgc2Vzc2lvbj8NCg0KPGVyaWM+IEEga2lsbC1zdWJzY3JpcHRp b24gUlBDIGlzIGludGVuZGVkIGZvciBhIG5ldHdvcmsgb3BlcmF0b3IuICBUaGUgb3BlcmF0b3Ig bmVlZHMgdG8gYmUgYWJsZSB0byBoYXZlIHRoZSBhYmlsaXR5IHRvIHRlcm1pbmF0ZSBhbiBhY3Rp dmUgc3Vic2NyaXB0aW9uLiAgIFRoaXMgaXMgZGlmZmVyZW50IGZyb20gZGVsZXRlLXN1YnNjcmlw dGlvbiwgd2hlcmUgdGhlIGludGVuZGVkIHVzZSBpcyBmb3IgdGhlIHJlcXVlc3RvciBvZiBhIHN1 YnNjcmlwdGlvbiB0byBiZSBhYmxlIHRvIGVuZCBpdC4NCg0KNi4gICAgICAgMi40LjY6DQphLiAg ICAgICB3aHkgaGF2ZSBlcnJvcnMgdy5yLnQuICJ3ZWlnaHRpbmciLCBhbmQgImRlcGVuZGVuY3ki IG5vdCBiZWVuIGluY2x1ZGVkPw0KPGVyaWM+IE11Y2ggbGlrZSB0aGUgYW5hbG9nb3VzIEhUVFAy IGNhcGFiaWxpdGllcyB0byB3aGljaCB0aGUgY2FuIGJlIG1hcHBlZCwgZmFpbHVyZXMgaW4gY29u ZmlndXJpbmcgdGhlc2UgcHJvcGVybHkgZG9u4oCZdCBoYXZlIGV4cG9zZWQgZXJyb3IgY29uZGl0 aW9ucy4gIEZvciBleGFtcGxlLCBpZiB5b3UgcG9pbnQgdG8gYSBzdWJzY3JpcHRpb24gZGVwZW5k ZW5jeSB3aGljaCBkb2VzbuKAmXQgZXhpc3QsIHRoZSBkZXBlbmRlbmN5IGlzIHNpbGVudGx5IGRp c2NhcmRlZC4NCg0KDQpiLiAgICAgICBOdW1lcmVkIHBvaW50cyAxLzIvMyBhcmUgYmV0dGVyIGNv bW11bmljYXRlZCB2aWEgYSB0YWJsZSB0byBhdm9pZCB0aGUgZHVwbGljYXRlZCB0ZXh0Lg0KQnJl dml0eSBtYWtlcyBmb3IgYmV0dGVyIHJlYWRpbmcuDQoNCjxlcmljPiAgSW4gZ2VuZXJhbCBJIGFn cmVlIHdpdGggeW91LiAgQW5kIEkgaW5pdGlhbGx5IGF0dGVtcHRlZCBhIHRhYmxlLiAgSG93ZXZl ciB0aGUgbGVhZiBuYW1lcyB3ZXJlIHNvIGxvbmcsIGl0IGdhdmUgdmVyeSBsaXR0bGUgc3BhY2Ug Zm9yIHRoZSBvdGhlciB0ZXh0IHdpdGhpbiB0aGUgdGFibGUsIHNvIEkgZGVmYXVsdGVkIGJhY2sg dG8gd2hhdCBpcyB0aGVyZSBub3cuDQoNCjcuICAgICAgIFNlY3Rpb25zIDIuNS4yIC0gMi41Ljc6 IHRoZXNlIGFyZSBhIGJpdCBvZiBhIGRyYWcgdG8gcmVhZCB0aHJvdWdoLCBpbiBhbiBhbHJlYWR5 IGxhcmdlIGRvY3VtZW50LiBSZWFkYWJpbGl0eSBmb3IgdGhlc2Ugc2VjdGlvbnMgd291bGQgYmUg Z3JlYXRseSBpbXByb3ZlZCBpZiB0aGUgbm90aWZpY2F0aW9ucyB0aGF0IGdldCBzZW50IG91dCB3 ZXJlIGxpc3RlZCBwaWN0b3JpYWxseSBvciBpbiBhIHRhYnVsYXIgZmFzaGlvbiBieSBlbmhhbmNp bmcgdGhlIHNpbXBsZSBGU01zIGxpc3RlZCBpbiBzZWN0aW9uIDIuNS4xLg0KDQo8ZXJpYz4gSSBk byBhZ3JlZSB0aGVyZSBpcyBhIGxvdCBvZiB0ZXh0IGhlcmUuICAgQmFzZWQgb24gdGhlIFdHIGZl ZWRiYWNrLCB0aGluZ3MgZ2V0IHZlcnkgZXhwbGljaXQgaW4gdGhpcyBzZWN0aW9uIG92ZXIgdGlt ZS4gICBQZXJoYXBzIGFub3RoZXIgZm9ybWF0IGNvdWxkIHdvcmsgaGVyZSBhcyB5b3Ugc3VnZ2Vz dC4gSSBhbSBob3BpbmcgdGhhdCB0aGlzIGFsdGVybmF0aXZlIGZvcm1hdHRpbmcgaXNu4oCZdCBu ZWVkZWQgdG8gaW5zZXJ0IGludG8gdGhlIGRvY3VtZW50IGF0IHRoaXMgcG9pbnQNCg0KOC4gICAg ICAgU2VjdGlvbiA1LjQ6DQoiVGhpcyBjYW4gYmUgYWNjb21wbGlzaCBieSBlc3RhYmxpc2hpbmci IC0+ICJUaGlzIGNhbiBiZSBhY2NvbXBsaXNoZWQgYnkgZXN0YWJsaXNoaW5nIg0KPGVyaWM+ICBH b29kIGNhdGNoLiAgSXQgaXMgY29ycmVjdCBpbiBteSBYTUwgcmlnaHQgbm93LCBzbyBJIHN1c3Bl Y3Qgc29tZSBvdGhlciByZXZpZXdlciBhbHNvIHBvaW50ZWQgdGhpcyBvdXQgdG8gbWUuDQoNClRo YW5rcyBhZ2FpbiENCkVyaWMNCg0KDQpSZWdhcmRzDQpSYXZpDQoNCg0K --_000_86a1564f43fc46169079f83dec3cbbbaXCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFy YWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28t c3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsN CgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7 bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6MjAwNzU4NDk0MTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTIxMzYzMDgyMjI7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsMiBsZm8z DQoJe21zby1sZXZlbC1zdGFydC1hdDoyO30NCkBsaXN0IGwwOmxldmVsMiBsZm80DQoJe21zby1s ZXZlbC1zdGFydC1hdDozO30NCkBsaXN0IGwwOmxldmVsMiBsZm81DQoJe21zby1sZXZlbC1zdGFy dC1hdDo0O30NCkBsaXN0IGwwOmxldmVsMiBsZm82DQoJe21zby1sZXZlbC1zdGFydC1hdDo1O30N CkBsaXN0IGwwOmxldmVsMiBsZm84DQoJe21zby1sZXZlbC1zdGFydC1hdDo3O30NCkBsaXN0IGww OmxldmVsMiBsZm85DQoJe21zby1sZXZlbC1zdGFydC1hdDo4O30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUmF2aSw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhbmtzIHZlcnkgbXVjaCBmb3IgdGhlIHJldmlldy4mbmJzcDsgSXQgaXMg YXBwcmVjaWF0ZWQuJm5ic3A7IFRob3VnaHRzIGluLWxpbmUuLi48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj5Gcm9tOjwvYj4gUmF2aSBTaW5naCAmbHQ7cmF2aXNAanVuaXBlci5uZXQmZ3Q7 IDxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIEFwcmlsIDE0LCAyMDE5IDg6NDAgUE08YnI+DQo8 Yj5Ubzo8L2I+IFJvdXRpbmcgQURzICZsdDtydGctYWRzQHRvb2xzLmlldGYub3JnJmd0Ozxicj4N CjxiPkNjOjwvYj4gUm91dGluZyBEaXJlY3RvcmF0ZSAmbHQ7cnRnLWRpckBpZXRmLm9yZyZndDs7 IGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMuYWxsQGlldGYub3Jn OyBuZXRjb25mQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJ0Z0RpciByZXZpZXc6IGRy YWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnM8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SGVsbG8s PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFz IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91 dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1y ZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVT RyByZXZpZXcsIGFuZCBzb21ldGltZXMNCiBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3Nl IG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFE cy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBs ZWFzZSBzZWUg4oCLPGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcv dHJhYy93aWtpL1J0Z0RpciI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJh Yy93aWtpL1J0Z0RpcjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QWx0aG91 Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGlu ZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxv bmcgd2l0aCBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2 ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaA0KIGRpc2N1c3Npb24gb3IgYnkg dXBkYXRpbmcgdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Eb2N1 bWVudDogZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9uczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+UmV2aWV3ZXI6IFJhdmkgU2luZ2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlJldmlldyBEYXRlOiAwNC8x Mi8yMDE5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5JRVRGIExDIEVuZCBEYXRlOiBkYXRlLWlmLWtub3duPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5JbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFjazxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5TdW1tYXJ5OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhpcyBkb2N1bWVudCBpcyBi YXNpY2FsbHkgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLCBidXQgaGFzIG5pdHMgdGhhdCBzaG91bGQg YmUgY29uc2lkZXJlZCBwcmlvciB0byBwdWJsaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Q29tbWVudHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JJ3ZlIHJldmlld2VkIHRoZSBkcmFm dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPkl0IGlzIHZlcnkgZXhoYXVzdGl2ZSBhbmQgZ2VuZXJhbGx5IHdlbGwg d3JpdHRlbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPkkgY29uc2lkZXIgaXQgcmVhZHkgZm9yIHB1YmxpY2F0aW9u LCBhZnRlciB0aGUgZm9sbG93aW5nICZxdW90O25pdHMmcXVvdDsgaGF2ZSBiZWVuIGFkZHJlc3Nl ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MjMuNzVwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MjMuNzVwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjMuNzVwdDt0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzI7dmVydGljYWwtYWxpZ246 bWlkZGxlIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+MS4zOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDoyMy43NXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZx dW90O1N1cHBvcnQgZm9yIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucyBpcyBvcHRpb25hbCwgd2l0 aCBpdHMgYXZhaWxhYmlsaXR5IGFkdmVydGlzZWQgdmlhIGEmbmJzcDsgWUFORyBmZWF0dXJlLiZx dW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDoyMy43NXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSAmcXVvdDto b3cmcXVvdDsgYXNwZWN0IHNob3VsZCBiZSBhbGx1ZGVkIHRvIGhlcmUsIGV2ZW4gdGhvdWdoIHN1 YnNlcXVlbnQgc2VjdGlvbnMgYWRkcmVzcyB0aGlzIGluIGRldGFpbD88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjMuNzVwdCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGlzIHdpbGwgbWFrZSBmb3IgYmV0dGVyIHJlYWRh YmlsaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtl cmljJmd0OyBBcyBjYXBhYmlsaXR5IGFkdmVydGlzZW1lbnQgaXMgYSBiYXNpYyBpbmZyYXN0cnVj dHVyZSBjYXBhYmlsaXR5IG9mIFlBTkcgaXRzZWxmLCBJIHN1c3BlY3QgdGhhdCBwdXR0aW5nIHRo ZXNlIGRldGFpbHMgaGVyZSB3b3VsZCBiZSBmYWlybHkgb2J2aW91cyB0byBkZXZlbG9wZXJzIGFu ZCBvcGVyYXRvcnMgZmFtaWxpYXIgdG8gWUFORy4mbmJzcDsgTm90ZTogYXMgYSBkZXNpZ24gb2Jq ZWN0aXZlLCB3ZSBoYXZlDQogYmVlbiBhdHRlbXB0aW5nIHRvIGtlZXAgdGhlIGRvY3VtZW50cyBz bWFsbGVyIGJ5IG5vdCBhcnRpY3VsYXRpbmcgYWNjZXB0ZWQvY29yZSBjYXBhYmlsaXRpZXMgb2Yg dGhlIGJhc2UgWUFORyBzdWl0ZSBvZiBkcmFmdHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjMuNzVwdCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjMuNzVwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6 bDAgbGV2ZWwyIGxmbzM7dmVydGljYWwtYWxpZ246bWlkZGxlIj4NCjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+JnF1b3Q7Rm9yIGNvbm5lY3Rp b25sZXNzIG9yIHN0YXRlbGVzcyB0cmFuc3BvcnRzIGxpa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjMuNzVwdCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSFRUUCwg YSBsYWNrIG9mIHJlY2VpcHQgYWNrbm93bGVkZ21lbnQgb2YgYSBzZXF1ZW50aWFsIHNldCBvZjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDoyMy43NXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBub3RpZmljYXRpb24gbWVzc2FnZXMgYW5kL29yIGtlZXAtYWxpdmVzIGNh biBiZSB1c2VkIHRvIHRyaWdnZXIgYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMy43NXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0ZXJtaW5hdGlvbiBvZiBhIGR5 bmFtaWMgc3Vic2NyaXB0aW9uLiZxdW90OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMy43NXB0Ij48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPkhvdyBsb25nIHRvIHdhaXQ/IEFueSBpbnB1dHMgdGhlIGRyYWZ0IHdv dWxkIGxpa2UgdG8gcHJvdmlkZSBvciBsZWF2ZSB0byBhbiBpbXBsZW1lbnRhdGlvbj88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtlcmljJmd0OyBUaGlzIGRyYWZ0IGhhcyBzcGVj aWZpYyB0cmFuc3BvcnQgZHJhZnRzIHdoaWNoIGFyZSBnb2luZyB0aHJvdWdoIElFU0cgcmV2aWV3 cyBpbiBwYXJhbGxlbCB0byB0aGlzIG9uZS4gJm5ic3A7U3BlY2lmaWMgdG8geW91ciBxdWVzdGlv biBvbiBjb25uZWN0aW9ubGVzcyB0cmFuc3BvcnQsIGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29u Zi1ub3RpZi0xMyBTZWN0aW9uIDMuMSBwcm92aWRlcyBndWlkYW5jZSBmb3INCiBSRVNUQ09ORi9I VFRQIGNvbm5lY3Rpb25sZXNzIGNvbmZpZ3VyYXRpb24gYW5kIG9wZXJhdGlvbi4mbmJzcDsgRS5n LiBUTFMgaGVhcnRiZWF0IFtSRkM2NTIwXSBpcyByZWNvbW1lbmRlZC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMy43NXB0Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMy43NXB0O3RleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMCBsZXZlbDIgbGZvNDt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPg0KPCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TZWN0aW9u IDIuNC4yOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDoyMy43NXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPldvdWxkIGJl IHVzZWZ1bCB0byBleHBsYWluICZxdW90O3doZW4gcmVwbGF5IHN0b3BzJnF1b3Q7LCBpZiAmcXVv dDtyZXBsYXkmcXVvdDsgd2FzIHJlcXVlc3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjMuNzVwdCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5JcyB0aGlzIGRvbmUgYnkgbWFuZGF0aW5nIHRoYXQgJnF1b3Q7c3RvcC10 aW1lJnF1b3Q7IG11c3QgYmUgcHJvdmlkZWQgaWYgcmVwbGF5IHdhcyByZXF1ZXN0ZWQ/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjIzLjc1cHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+U3Vic2VxdWVudCBzZWN0aW9ucyBh ZGRyZXNzIHRoaXMsIGhvd2V2ZXIgd291bGQgYmUgdXNlZnVsIHRvIGFsbHVkZSB0byBpbiB0aGlz IHNlY3Rpb27igKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bHQ7ZXJpYyZndDsgSXQgY291bGQgYmUgZHVlIHRvIHJlYWNoaW5nIGEgc3RvcCB0aW1lLCBvciB3 aGVuIHRoZSByZXBsYXkgYnVmZmVyIGlzIG5vdyBlbXB0eSwgYW5kIHRoZSBjdXJyZW50IHRpbWUg aGFzIGJlZW4gcmVhY2hlZC4mbmJzcDsgRG8geW91IHdhbnQgbWUgdG8gYWRkIGEgc2VudGVuY2Ug d2hpY2ggZGVzY3JpYmVzIHRoZSBwdXJwb3NlIGFzOiDigJxUaGlzIGFsbG93cyBhIHRhcmdldGVk IGhpc3Rvcnkgb2YgZXZlbnQgcmVjb3Jkcw0KIHRvIGJlIGV4dHJhY3RlZC7igJ08bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIzLjc1cHQiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIzLjc1cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwwIGxldmVsMiBsZm81O3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPjQuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlNlY3Rpb24gMi40LjM6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjIzLjc1cHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UGxlYXNlIGVsYWJvcmF0 ZSBvbiB0aGUgcHJlc2VuY2Ugb2YgdGhlIGZvbGxvd2luZyBpbiB0aGUgc2NoZW1hOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoy My43NXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0t LXcgc3RvcC10aW1lPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDoyMy43NXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB5YW5nOmRhdGUtYW5kLXRpbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjMuNzVwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7ZXJpYyZndDsmbmJzcDsmbmJzcDsgVGhpcyBp cyBvbmUgbGVhZiBvZiBtYW55IHVuZGVyIHRoZSBtb2RpZnkgc3Vic2NyaXB0aW9uIFJQQy4mbmJz cDsmbmJzcDsgVGhpcyBsZWFmIG1lYW5zIHRoYXQgYSBzdWJzY3JpcHRpb24gaXMgYmVpbmcgbW9k aWZpZWQgdG8gZW5kIGF0IGEgdGFyZ2V0ZWQgc3RvcCB0aW1lLiZuYnNwOyZuYnNwOyBXaGlsZSBp dCBjb3VsZCBiZSBwb3NzaWJsZSB0byB3cml0ZSBhIG1lYW5pbmcgZm9yIGV2ZXJ5IGxlYWYgd2l0 aGluIHRoZSB0cmVlLA0KIHdlIGRlY2lkZWQgdGhhdCBkb2luZyB0aGlzIGZvciBldmVyeSBsZWFm IHdvdWxkIGhhdmUgbWFkZSB0aGUgZG9jdW1lbnQgdmVyeSBsYXJnZS4mbmJzcDsgVGhlcmUgaXMg YSBkZXNjcmlwdGlvbiBvZiB3aGF0IHN0b3AtdGltZSBkb2VzIGluIHRoZSBwcmV2aW91cyBzZWN0 aW9uLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMy43NXB0 Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMy43NXB0O3RleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDIgbGZvNjt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj41LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDtTZWN0aW9uIDIuNC41OiBub3QgY2xlYXIgd2hlbiB0aGlzIHdvdWxkIGFjdHVhbGx5 IGdldCB1c2VkLCBJT1figKZ3aGF0IHdvdWxkIGNhdXNlIHRoZXJlIHRvIGJlIHN1Y2ggYSBzaXR1 YXRpb24gd2hlcmUgdGhlIGtpbGwtc2J1c2NyaXB0aW9uIG5vdGlmY2F0aW9uIHdvdWxkIG5lZWQg dG8gYmUgdXNlZC4gV2hlbiB3aWxsIGEgc3Vic2NyaXB0aW9uIG5vdA0KIGJlIGFzc29jaWF0ZWQg d2l0aCBhIHRyYW5zcG9ydCBzZXNzaW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InZlcnRpY2FsLWFsaWduOm1pZGRs ZSI+Jmx0O2VyaWMmZ3Q7IEEga2lsbC1zdWJzY3JpcHRpb24gUlBDIGlzIGludGVuZGVkIGZvciBh IG5ldHdvcmsgb3BlcmF0b3IuJm5ic3A7IFRoZSBvcGVyYXRvciBuZWVkcyB0byBiZSBhYmxlIHRv IGhhdmUgdGhlIGFiaWxpdHkgdG8gdGVybWluYXRlIGFuIGFjdGl2ZSBzdWJzY3JpcHRpb24uJm5i c3A7Jm5ic3A7IFRoaXMgaXMgZGlmZmVyZW50IGZyb20gZGVsZXRlLXN1YnNjcmlwdGlvbiwgd2hl cmUNCiB0aGUgaW50ZW5kZWQgdXNlIGlzIGZvciB0aGUgcmVxdWVzdG9yIG9mIGEgc3Vic2NyaXB0 aW9uIHRvIGJlIGFibGUgdG8gZW5kIGl0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIzLjc1cHQ7dmVydGljYWwtYWxpZ246bWlkZGxlIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMy43NXB0O3RleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDIgbGZvNjt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPg0K PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj42LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4y LjQuNjogPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjUwLjc1cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVs MyBsZm83O3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmEuPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPndoeSBoYXZlIGVycm9ycyB3LnIudC4gJnF1 b3Q7d2VpZ2h0aW5nJnF1b3Q7LCBhbmQgJnF1b3Q7ZGVwZW5kZW5jeSZxdW90OyBub3QgYmVlbiBp bmNsdWRlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6NC41cHQiPiZsdDtlcmljJmd0OyBNdWNoIGxpa2UgdGhlIGFuYWxvZ291 cyBIVFRQMiBjYXBhYmlsaXRpZXMgdG8gd2hpY2ggdGhlIGNhbiBiZSBtYXBwZWQsIGZhaWx1cmVz IGluIGNvbmZpZ3VyaW5nIHRoZXNlIHByb3Blcmx5IGRvbuKAmXQgaGF2ZSBleHBvc2VkIGVycm9y IGNvbmRpdGlvbnMuJm5ic3A7IEZvciBleGFtcGxlLCBpZiB5b3UgcG9pbnQgdG8gYSBzdWJzY3Jp cHRpb24gZGVwZW5kZW5jeQ0KIHdoaWNoIGRvZXNu4oCZdCBleGlzdCwgdGhlIGRlcGVuZGVuY3kg aXMgc2lsZW50bHkgZGlzY2FyZGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InZlcnRpY2FsLWFsaWduOm1pZGRsZSI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idmVydGljYWwtYWxpZ246bWlkZGxlIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1 MC43NXB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDMgbGZvNzt2ZXJ0aWNh bC1hbGlnbjptaWRkbGUiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5iLjxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5OdW1lcmVkIHBvaW50cyAxLzIvMyBhcmUgYmV0dGVyIGNvbW11bmlj YXRlZCB2aWEgYSB0YWJsZSB0byBhdm9pZCB0aGUgZHVwbGljYXRlZCB0ZXh0LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1MC43 NXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkJyZXZpdHkgbWFrZXMgZm9yIGJldHRlciBy ZWFkaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDo1MC43NXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZsdDtlcmljJmd0OyZuYnNwOyBJbiBnZW5lcmFsIEkgYWdyZWUgd2l0aCB5b3Uu ICZuYnNwO0FuZCBJIGluaXRpYWxseSBhdHRlbXB0ZWQgYSB0YWJsZS4mbmJzcDsgSG93ZXZlciB0 aGUgbGVhZiBuYW1lcyB3ZXJlIHNvIGxvbmcsIGl0IGdhdmUgdmVyeSBsaXR0bGUgc3BhY2UgZm9y IHRoZSBvdGhlciB0ZXh0IHdpdGhpbiB0aGUgdGFibGUsIHNvIEkgZGVmYXVsdGVkIGJhY2sgdG8g d2hhdCBpcyB0aGVyZSBub3cuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDoyMy43NXB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDIgbGZvODt2 ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj43LjxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TZWN0aW9ucyAyLjUuMiAtIDIuNS43OiB0aGVzZSBhcmUg YSBiaXQgb2YgYSBkcmFnIHRvIHJlYWQgdGhyb3VnaCwgaW4gYW4gYWxyZWFkeSBsYXJnZSBkb2N1 bWVudC4gUmVhZGFiaWxpdHkgZm9yIHRoZXNlIHNlY3Rpb25zIHdvdWxkIGJlIGdyZWF0bHkgaW1w cm92ZWQgaWYgdGhlIG5vdGlmaWNhdGlvbnMgdGhhdCBnZXQgc2VudCBvdXQgd2VyZSBsaXN0ZWQN CiBwaWN0b3JpYWxseSBvciBpbiBhIHRhYnVsYXIgZmFzaGlvbiBieSBlbmhhbmNpbmcgdGhlIHNp bXBsZSBGU01zIGxpc3RlZCBpbiBzZWN0aW9uIDIuNS4xLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InZlcnRpY2FsLWFs aWduOm1pZGRsZSI+Jmx0O2VyaWMmZ3Q7IEkgZG8gYWdyZWUgdGhlcmUgaXMgYSBsb3Qgb2YgdGV4 dCBoZXJlLiZuYnNwOyZuYnNwOyBCYXNlZCBvbiB0aGUgV0cgZmVlZGJhY2ssIHRoaW5ncyBnZXQg dmVyeSBleHBsaWNpdCBpbiB0aGlzIHNlY3Rpb24gb3ZlciB0aW1lLiZuYnNwOyZuYnNwOyBQZXJo YXBzIGFub3RoZXIgZm9ybWF0IGNvdWxkIHdvcmsgaGVyZSBhcyB5b3Ugc3VnZ2VzdC4gSSBhbSBo b3BpbmcgdGhhdCB0aGlzDQogYWx0ZXJuYXRpdmUgZm9ybWF0dGluZyBpc27igJl0IG5lZWRlZCB0 byBpbnNlcnQgaW50byB0aGUgZG9jdW1lbnQgYXQgdGhpcyBwb2ludDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIzLjc1cHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIzLjc1cHQ7dGV4dC1pbmRlbnQ6LS4yNWlu O21zby1saXN0OmwwIGxldmVsMiBsZm85O3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+DQo8IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPjguPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlNlY3Rpb24g NS40OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDoyMy43NXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZxdW90O1RoaXMg Y2FuIGJlIGFjY29tcGxpc2ggYnkgZXN0YWJsaXNoaW5nJnF1b3Q7IC0mZ3Q7ICZxdW90O1RoaXMg Y2FuIGJlIGFjY29tcGxpc2hlZCBieSBlc3RhYmxpc2hpbmcmcXVvdDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7ZXJpYyZndDsmbmJzcDsgR29vZCBjYXRj aC4mbmJzcDsgSXQgaXMgY29ycmVjdCBpbiBteSBYTUwgcmlnaHQgbm93LCBzbyBJIHN1c3BlY3Qg c29tZSBvdGhlciByZXZpZXdlciBhbHNvIHBvaW50ZWQgdGhpcyBvdXQgdG8gbWUuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBhZ2FpbiE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkVyaWM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjIzLjc1cHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5S ZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5SYXZpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIzLjc1cHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_86a1564f43fc46169079f83dec3cbbbaXCHRTP013ciscocom_-- From nobody Tue Apr 16 15:44:44 2019 Return-Path: <0100016a2852d457-32f463a6-60b8-474c-b976-4476f174d94d-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729A61200F6 for ; Tue, 16 Apr 2019 15:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKjn9JppftNC for ; Tue, 16 Apr 2019 15:44:39 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98512120058 for ; Tue, 16 Apr 2019 15:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1555454678; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=k/9LJ1rlaV1JrCu4RW1V0fFKzFsQaRSh7w08vydt7kc=; b=RlLIMFnVUuMI/8ndrkSWRg/81gXyRSJmEkxb1Pv2SmnJBKhn3xJmqOTy5oQvK+gs vAw33lBFZtR5WJkY7/AxaKNkEwKIy7CQcftOBWxNjmvzsUWxNp6acLs4sh9yAP+6hxn voKcxqNtzUaBubV6o9DGQ8rSDbZArE8OPXN/Hx4M= From: Kent Watsen Message-ID: <0100016a2852d457-32f463a6-60b8-474c-b976-4476f174d94d-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_517122F6-D8C7-44C0-AB31-F383CF00BB63" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 16 Apr 2019 22:44:38 +0000 In-Reply-To: <20190415213448.krsi3ma3fds2u4hh@anna.jacobs.jacobs-university.de> Cc: "netconf@ietf.org" To: Juergen Schoenwaelder References: <01000169fa45ea88-505cd325-94b7-4d48-a529-448a9905f534-000000@email.amazonses.com> <20190408154613.ytibxwvjurfcwinp@anna.jacobs.jacobs-university.de> <0100016a22d1b6e2-73101afa-6a8a-44b0-9295-1af1595008ce-000000@email.amazonses.com> <20190415213448.krsi3ma3fds2u4hh@anna.jacobs.jacobs-university.de> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.16-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] overview of updates and current issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 22:44:42 -0000 --Apple-Mail=_517122F6-D8C7-44C0-AB31-F383CF00BB63 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 15, 2019, at 5:34 PM, Juergen Schoenwaelder = wrote: >=20 > Inline... >=20 > On Mon, Apr 15, 2019 at 09:05:30PM +0000, Kent Watsen wrote: >>=20 >>>> Current Issues: >>>>=20 >>>> 1. Regarding the "demux containers": >>>>=20 >>>> Pros: >>>> - now the NC/RC models look better >>>> - a convenient place to have a nacm:default-deny-write >>>>=20 >>>> Cons: >>>> - seems overbearing for general use >>>>=20 >>>> Question: >>>>=20 >>>> Would it be better to revert and instead wrap each "uses" >>>> statement in the NC/RC models with a container? >>>>=20 >>>> Pros: maximum flexibility >>>> Cons: less consistency? >>>=20 >>> What exactly are the demux containers? You mean the >>> and containers? >>=20 >> Yes. This is what what meant by: >>=20 >> "Added a top-level "demux container" inside the top-level grouping. >> By "demux", I'm referring to the namespace problem discussed = @104." >>=20 >> about 10 lines above. >>=20 >>=20 >>=20 >>> I have no strong opinion, they may be ok although things get a bit = more verbose. >>=20 >> On the "Cons" side, I'm calling the containers = "--parameters". I question is if this is a = good name in all contexts. By removing the "demux container", it lets = the consumer decide what to call it. This brings us to the "less = consistency?" comment; of course there would be little consistency but, = do we care? >>=20 >> Regarding "a convenient place to have a nacm:default-deny-write", I = don't see anywhere in RFC 8341 that nacm:default-deny-write can't be = used in a grouping, but it will impact the parent... If the parent has = other descendents besides from the grouping, those descendents would = likely be impacted too, right? Do we care? If we put = nacm:default-deny-write under the grouping statement, then I think that = it subtly enforces consumers to create their own wrapper containers (as = opposed to mixing the descendents in with other nodes). Alternately, = we could float the "if-feature" statement down to each descendent of the = grouping. Not ideal, but works...? >>=20 >=20 > Perhaps instead of being tricky (subtly enforcing consumers to create > their own wrapper), why not move the nacm:default-deny-write to the > leafs? This seems less subtle and more robust. Right, this was my last sentence: "Alternately, we could float the = "if-feature" statement down to each descendent of the grouping.". Okay, so it's technically possible (the nacm extension), but I feel that = we're still open on if the "demux containers" should be kept or = discarded. =20 I'm personally leaning towards "discard", but I don't want to make the = change until we have a solid decision. >>>> 3. In either the NETCONF and RESTCONF drafts, does it matter at all >>>> where a 'must' statement is located, especially if they refer to >>>> nodes that are conditional by "if-feature" statements? >>>>=20 >>>> i.e., search for "case periodic-connection" >>>>=20 >>>> Should the "must" statements be located somewhere else? >>>=20 >>> I actually wonder whether this must is really desirable. What breaks >>> if I have TCP keep-alives turned on for a periodic call-home = connection? >>> Perhaps I want to enable keep-alives to work around a broken = firewall. >>=20 >> The point of the periodic connection, from which it gets its name, is = that it "frequently" sets-up and tears-down. Thus is self-healing in = the case of a network drop. >>=20 >> Our WG's primary use-case for keepalives is a device that has been = configured to periodically call-home (perhaps every midnight), in case = its controller application has any config pending for it (depositing = logs is assumed to be out-of-band). One can imagine the controller = performing a number of steps, potentially with delays between the steps. >=20 > The point is that we do not know what will happen once the server has > called home - so how can we be sure that keep alives never make sense > with call-home? I'm okay with removing these "must" statements" They can be added in = again later, potentially through an "augment" statement, if need be. >> The ietf-[net/rest]conf-server-grouping groupings say this about the = "periodic-connection" presence container (under "call-home"): >>=20 >> "Periodically connect to the NETCONF client. The >> NETCONF client should close the underlying TCP >> connection upon completing planned activities. >>=20 >> So, if the connection is dropped (due to a lack a keepalives), should = the server interpret that as "the client completed planned activities", = and therefore doesn't need to connect again until next midnight? >=20 > The server likely does not care, at least likely not more than without > call-home. I assume that keep alives are more interesting for a client > that is not constantly talking to the server but likes to keep the > session open (for whatever reason). Unsure. It seems that a packer could drop the TCP connection = immediately after NC/RC starts up. The client would be unable to send = any data to the server. The server MAY think that it was a successful = "no-op" call-home. With NETCONF, the client could send , = but still there is a need to support dropped connections and, besides, = there is no RESTCONF equivalent. >> Separately (not related to the above), the = ietf-[net/rest]conf-client-grouping groupings say (under "initiate"): >>=20 >> "Periodically connect to the NETCONF server. The >> NETCONF server should close the underlying TCP >> connection upon completing planned activities. >>=20 >> which might be right, but somehow it feels odd that the client = wouldn't always close the connection... >>=20 >=20 > For the use cases I have in mind for this, the server would not really > know when to close the connection since the client would take control > over what is going on. This may, however, be different from a > call-home to stream notifications. Perhaps we should say less. I think that you're right. This is NOT for the call-home case (that is = the "listen" subtree, not the "initiate" subtree). I think that the = comment is wrong and should say: "Periodically connect to the NETCONF server. The NETCONF client should close the underlying TCP connection upon completing planned activities. or (since it's not special, as in the matching call-home statement): "Periodically connect to the NETCONF server." To your point: "Perhaps we should say less". > One thing that comes to mind is whether a new callhome attempt should > be made in situations where the previous callhome is still alive. Do > we want to say something about this or not? If that happens, then something is wrong. Either the previous attempt = is "hung" (but I think there is an "idle-timeout" to catch such cases, = maybe only for NC though), or it is legitimately still busy (in which = case it MAY be an indication that the frequency is set too high but, in = either case, it seems that a second connection wouldn't be desired). = There is currently no text stating what to do in this case. It seems = like such text might go into the same description statements discussed = above: "Periodically connect to the . The client SHOULD close the underlying TCP connection upon completing planned activities. In the case that the pervious connection is still = active, establishing a new connection is NOT RECOMMENDED. Thoughts? Kent // contributor --Apple-Mail=_517122F6-D8C7-44C0-AB31-F383CF00BB63 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 15, 2019, at 5:34 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

Inline...

On Mon, Apr 15, 2019 = at 09:05:30PM +0000, Kent Watsen wrote:

Current Issues:

1. Regarding the "demux containers":

   Pros:
=      - now the NC/RC models look better
     - a convenient place to have a = nacm:default-deny-write

=    Cons:
     - = seems overbearing for general use

=  Question:

   Would it = be better to revert and instead wrap each "uses"
=    statement in the NC/RC models with a container?

      Pros: = maximum flexibility
=       Cons: less consistency?

What exactly are the demux = containers? You mean the
<tcp-client-parameters> and = <tls-client-parameters> containers?

Yes.  This is what what meant by:

  "Added a top-level "demux container" inside the = top-level grouping.
   By "demux", I'm = referring to the namespace problem discussed @104."

about 10 lines above.



I have no = strong opinion, they may be ok although things get a bit more = verbose.

On the "Cons" side, = I'm calling the containers = "<protocol>-<client/server>-parameters".  I question is = if this is a good name in all contexts.  By removing the "demux = container",  it lets the consumer decide what to call it. =  This brings us to the "less consistency?" comment;  of course = there would be little consistency but, do we care?

Regarding "a convenient place to have a = nacm:default-deny-write", I don't see anywhere in RFC 8341 that = nacm:default-deny-write can't be used in a grouping, but it will impact = the parent...  If the parent has other descendents besides from the = grouping, those descendents would likely be impacted too, right? =   Do we care?  If we put nacm:default-deny-write under = the grouping statement, then I think that it subtly enforces consumers = to create their own wrapper containers (as opposed to mixing the = descendents in with other nodes).   Alternately, we could = float the "if-feature" statement down to each descendent of the = grouping.  Not ideal, but works...?


Perhaps instead of being tricky = (subtly enforcing consumers to create
their own wrapper), = why not move the nacm:default-deny-write to the
leafs? = This seems less subtle and more robust.

Right, = this was my last sentence: "Alternately, we could float the "if-feature" = statement down to each descendent of the grouping.".

Okay, so it's technically possible (the nacm = extension), but I feel that we're still open on if the "demux = containers" should be kept or discarded.  

I'm personally leaning towards "discard", but I = don't want to make the change until we have a solid = decision.



3. In either the NETCONF = and RESTCONF drafts, does it matter at all
 where a = 'must' statement is located, especially if they refer to
=  nodes that are conditional by "if-feature" statements?

    i.e., search for = "case periodic-connection"

 Should = the "must" statements be located somewhere else?

I actually wonder whether this = must is really desirable. What breaks
if I have TCP = keep-alives turned on for a periodic call-home connection?
Perhaps I want to enable keep-alives to work around a broken = firewall.

The point of the = periodic connection, from which it gets its name, is that it = "frequently" sets-up and tears-down.  Thus is self-healing in the = case of a network drop.

Our WG's primary = use-case for keepalives is a device that has been configured to = periodically call-home (perhaps every midnight), in case its controller = application has any config pending for it (depositing logs is assumed to = be out-of-band).    One can imagine the controller = performing a number of steps, potentially with delays between the = steps.

The point is that we do = not know what will happen once the server has
called home = - so how can we be sure that keep alives never make sense
with call-home?
I'm okay with removing these "must" statements" =  They can be added in again later, potentially through an "augment" = statement, if need be.



The ietf-[net/rest]conf-server-grouping groupings say this = about the "periodic-connection" presence container (under = "call-home"):

=             &n= bsp;       "Periodically connect to = the NETCONF client.  The
=             &n= bsp;        NETCONF client = should close the underlying TCP
=             &n= bsp;        connection upon = completing planned activities.

So, if the = connection is dropped (due to a lack a keepalives), should the server = interpret that as "the client completed planned activities", and = therefore doesn't need to connect again until next midnight?

The server likely does not care, = at least likely not more than without
call-home. I assume = that keep alives are more interesting for a client
that is = not constantly talking to the server but likes to keep the
session open (for whatever reason).

Unsure.=  It seems that a packer could drop the TCP connection immediately = after NC/RC starts up.   The client would be unable to send any = data to the server.  The server MAY think that it was a successful = "no-op" call-home.  With NETCONF, the client could send = <close-session>, but still there is a need to support dropped = connections and, besides, there is no RESTCONF equivalent.


Separately= (not related to the above), the ietf-[net/rest]conf-client-grouping = groupings say (under "initiate"):

=             &n= bsp;       "Periodically connect to = the NETCONF server.  The
=             &n= bsp;        NETCONF server = should close the underlying TCP
=             &n= bsp;        connection upon = completing planned activities.

which might = be right, but somehow it feels odd that the client wouldn't always close = the connection...


For the use cases I have in mind for this, the server would = not really
know when to close the connection since the = client would take control
over what is going on. This may, = however, be different from a
call-home to stream = notifications. Perhaps we should say less.

I = think that you're right.  This is NOT for the call-home case (that = is the "listen" subtree, not the "initiate" subtree).  I think that = the comment is wrong and should say:

              =       "Periodically connect to the NETCONF server. =  The
              =        NETCONF client should close the underlying = TCP
              =        connection upon completing planned = activities.

or (since it's = not special, as in the matching call-home statement):

              =       "Periodically connect to the NETCONF = server."

    To your = point: "Perhaps we should say less".


One thing that comes to mind = is whether a new callhome attempt should
be made in = situations where the previous callhome is still alive. Do
we= want to say something about this or not?


If that happens, = then something is wrong.  Either the previous attempt is "hung" = (but I think there is an "idle-timeout" to catch such cases, maybe only = for NC though), or it is legitimately still busy (in which case it MAY = be an indication that the frequency is set too high but, in either case, = it seems that a second connection wouldn't be desired).   There is = currently no text stating what to do in this case.  It seems like = such text might go into the same description statements discussed = above:


          =           "Periodically connect to the = <protocol> <peer>.  The
    =                 =  <protocol> client SHOULD close the underlying TCP
                =      connection upon completing planned activities.

    =                  In the = case that the pervious connection is still active,
  =                   =  establishing a new connection is NOT RECOMMENDED.


Thoughts?


Kent // = contributor





= --Apple-Mail=_517122F6-D8C7-44C0-AB31-F383CF00BB63-- From nobody Fri Apr 19 20:56:28 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2F0120497; Fri, 19 Apr 2019 20:56:25 -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_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 J-wGQayb79jt; Fri, 19 Apr 2019 20:56:23 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 839361203DD; Fri, 19 Apr 2019 20:56:20 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3K3uDlZ029905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Apr 2019 23:56:15 -0400 Date: Fri, 19 Apr 2019 22:56:13 -0500 From: Benjamin Kaduk To: "Reshad Rahman (rrahman)" Cc: Aanchal Malhotra , "secdir@ietf.org" , "ietf@ietf.org" , "draft-ietf-netconf-restconf-notif.all@ietf.org" , "netconf@ietf.org" Message-ID: <20190420035612.GR51586@kduck.mit.edu> References: <155501965074.14152.2835369201856309773@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [netconf] Secdir last call review of draft-ietf-netconf-restconf-notif-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2019 03:56:25 -0000 On Fri, Apr 12, 2019 at 09:29:35PM +0000, Reshad Rahman (rrahman) wrote: > Hi Aanchal, > > Thanks for the review. Please see inline. > > On 2019-04-11, 5:54 PM, "netconf on behalf of Aanchal Malhotra via Datatracker" wrote: > > Reviewer: Aanchal Malhotra > Review result: Ready > > The document is very clear and concise. I just have one minor clarification question. > Section 3.4 Page 9 that says the following: > "In addition to any required ........SHOULD only be allowed......". > > Is there a reason for using SHOULD instead of MUST? > > There may be reasons why an implementation decides not to enforce this restriction. Going by RFC2119 definitions, this is why we chose SHOULD instead of MUST. If you have some reasons in mind, it is often helpful to list them as examples of when the recommended behavior would not be followed. Thank you Aanchal for the review! -Ben From nobody Mon Apr 22 16:24:42 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 117A012003E; Mon, 22 Apr 2019 16:24:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ibagdona@gmail.com, mjethanandani@gmail.com, netconf-chairs@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155597548101.21208.10087957108587540657.idtracker@ietfa.amsl.com> Date: Mon, 22 Apr 2019 16:24:41 -0700 Archived-At: Subject: [netconf] netconf - New Meeting Session Request for IETF 105 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 23:24:41 -0000 A new meeting session request has just been submitted by Mahesh Jethanandani, a Chair of the netconf working group. --------------------------------------------------------- Working Group Name: Network Configuration Area Name: Operations and Management Area Session Requester: Mahesh Jethanandani Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: netmod Second Priority: opsarea opsawg tsvwg babel idr tcpm Third Priority: sacm saag People who must be present: Mahesh Jethanandani Kent Watsen Ignas Bagdonas Resources Requested: Special Requests: MUST schedule for Monday or Tuesday. --------------------------------------------------------- From nobody Tue Apr 23 00:52:30 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE218120091 for ; Tue, 23 Apr 2019 00:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcOVYQ8ZV2kQ for ; Tue, 23 Apr 2019 00:52:25 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73C82120072 for ; Tue, 23 Apr 2019 00:52:25 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 59A306A0; Tue, 23 Apr 2019 09:52:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id VXklE02NytOj; Tue, 23 Apr 2019 09:52:23 +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 atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 23 Apr 2019 09:52:23 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 430F9200CC; Tue, 23 Apr 2019 09:52:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id cJWgdb5_XRuY; Tue, 23 Apr 2019 09:52:22 +0200 (CEST) Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id BF292200CD; Tue, 23 Apr 2019 09:52:22 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Tue, 23 Apr 2019 09:52:22 +0200 Received: by anna.localdomain (Postfix, from userid 501) id D399C30086F030; Tue, 23 Apr 2019 09:52:21 +0200 (CEST) Date: Tue, 23 Apr 2019 09:52:21 +0200 From: Juergen Schoenwaelder To: Kent Watsen CC: "netconf@ietf.org" Message-ID: <20190423075221.5qx7fowjebxfxoy4@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: <01000169fa45ea88-505cd325-94b7-4d48-a529-448a9905f534-000000@email.amazonses.com> <20190408154613.ytibxwvjurfcwinp@anna.jacobs.jacobs-university.de> <0100016a22d1b6e2-73101afa-6a8a-44b0-9295-1af1595008ce-000000@email.amazonses.com> <20190415213448.krsi3ma3fds2u4hh@anna.jacobs.jacobs-university.de> <0100016a2852d457-32f463a6-60b8-474c-b976-4476f174d94d-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <0100016a2852d457-32f463a6-60b8-474c-b976-4476f174d94d-000000@email.amazonses.com> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netconf] overview of updates and current issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 07:52:29 -0000 On Tue, Apr 16, 2019 at 10:44:38PM +0000, Kent Watsen wrote: > > > > On Apr 15, 2019, at 5:34 PM, Juergen Schoenwaelder wrote: > > > > Inline... > > > > On Mon, Apr 15, 2019 at 09:05:30PM +0000, Kent Watsen wrote: > >> > >>>> Current Issues: > >>>> > >>>> 1. Regarding the "demux containers": > >>>> > >>>> Pros: > >>>> - now the NC/RC models look better > >>>> - a convenient place to have a nacm:default-deny-write > >>>> > >>>> Cons: > >>>> - seems overbearing for general use > >>>> > >>>> Question: > >>>> > >>>> Would it be better to revert and instead wrap each "uses" > >>>> statement in the NC/RC models with a container? > >>>> > >>>> Pros: maximum flexibility > >>>> Cons: less consistency? > >>> > >>> What exactly are the demux containers? You mean the > >>> and containers? > >> > >> Yes. This is what what meant by: > >> > >> "Added a top-level "demux container" inside the top-level grouping. > >> By "demux", I'm referring to the namespace problem discussed @104." > >> > >> about 10 lines above. > >> > >> > >> > >>> I have no strong opinion, they may be ok although things get a bit more verbose. > >> > >> On the "Cons" side, I'm calling the containers "--parameters". I question is if this is a good name in all contexts. By removing the "demux container", it lets the consumer decide what to call it. This brings us to the "less consistency?" comment; of course there would be little consistency but, do we care? > >> > >> Regarding "a convenient place to have a nacm:default-deny-write", I don't see anywhere in RFC 8341 that nacm:default-deny-write can't be used in a grouping, but it will impact the parent... If the parent has other descendents besides from the grouping, those descendents would likely be impacted too, right? Do we care? If we put nacm:default-deny-write under the grouping statement, then I think that it subtly enforces consumers to create their own wrapper containers (as opposed to mixing the descendents in with other nodes). Alternately, we could float the "if-feature" statement down to each descendent of the grouping. Not ideal, but works...? > >> > > > > Perhaps instead of being tricky (subtly enforcing consumers to create > > their own wrapper), why not move the nacm:default-deny-write to the > > leafs? This seems less subtle and more robust. > > Right, this was my last sentence: "Alternately, we could float the "if-feature" statement down to each descendent of the grouping.". > > Okay, so it's technically possible (the nacm extension), but I feel that we're still open on if the "demux containers" should be kept or discarded. > > I'm personally leaning towards "discard", but I don't want to make the change until we have a solid decision. I think we should discard the "demux containers" to give data model writers the freedom to have them or not. > > One thing that comes to mind is whether a new callhome attempt should > > be made in situations where the previous callhome is still alive. Do > > we want to say something about this or not? > > If that happens, then something is wrong. Either the previous attempt is "hung" (but I think there is an "idle-timeout" to catch such cases, maybe only for NC though), or it is legitimately still busy (in which case it MAY be an indication that the frequency is set too high but, in either case, it seems that a second connection wouldn't be desired). There is currently no text stating what to do in this case. It seems like such text might go into the same description statements discussed above: > > "Periodically connect to the . The > client SHOULD close the underlying TCP > connection upon completing planned activities. > > In the case that the pervious connection is still active, > establishing a new connection is NOT RECOMMENDED. Sounds good, this provides a hint that implementers need to track and limit call home connections. /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 Apr 23 06:55:09 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C0912016D for ; Tue, 23 Apr 2019 06:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pO89JLiR2ZiH for ; Tue, 23 Apr 2019 06:55:02 -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 8E1101200B3 for ; Tue, 23 Apr 2019 06:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39400; q=dns/txt; s=iport; t=1556027702; x=1557237302; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3gCTQ1zuuSBmb5Af2baKYR7LciaYH6wMsoe8f2ulrZA=; b=hnSkwXrgrBkDcLHlCdGbxvq+m/4OU3bZ7jVg43HcQbXhTSzn2ScTs8Pm VtnUty/vXT6YL11CtmS4yHHAtP4Ru9t58R7CVvXh3N9KvrSvvxeW8tRbq 9TMp9G/ZWK0RO5fVp7s9meyuymdmy936aG4CEE9AjJR2ba00U/Q41y3wG 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BbAABgGL9c/4MNJK1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZYEPgQJogQQoCpk6mkYOAQGEbQKGJyM4EwEDAQEEAQECAQJ?= =?us-ascii?q?tKIVKAQEBBC1MEAIBCBABAQMBASEBDTIXBggCBAENBQgTgwiBHWupbYotgTK?= =?us-ascii?q?GAIFYgi6BRBeBQD+DJX4+hBAehXcEgVuGH4J9hnUeh1CMGGQJAoIIjheECyO?= =?us-ascii?q?VFIwEkhWCJgIRFYEwNiGBVnAVgyeCGxeOH0Exj1GBIQEB?= X-IronPort-AV: E=Sophos;i="5.60,386,1549929600"; d="scan'208,217";a="266018725" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Apr 2019 13:55:01 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x3NDt1gh014390 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Apr 2019 13:55:01 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 23 Apr 2019 08:55:00 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Tue, 23 Apr 2019 08:55:00 -0500 From: "Rob Wilton (rwilton)" To: Kent Watsen , Juergen Schoenwaelder CC: "netconf@ietf.org" Thread-Topic: [netconf] overview of updates and current issues Thread-Index: AQHU7Z8t/eB4vMQl8ES36uQQl1idmaYyvPaAgAtZhwCAC8Eu0A== Date: Tue, 23 Apr 2019 13:55:00 +0000 Message-ID: <1f351db098b14de0ad5a18ffe072bad9@XCH-RCD-007.cisco.com> References: <01000169fa45ea88-505cd325-94b7-4d48-a529-448a9905f534-000000@email.amazonses.com> <20190408154613.ytibxwvjurfcwinp@anna.jacobs.jacobs-university.de> <0100016a22d1b6e2-73101afa-6a8a-44b0-9295-1af1595008ce-000000@email.amazonses.com> In-Reply-To: <0100016a22d1b6e2-73101afa-6a8a-44b0-9295-1af1595008ce-000000@email.amazonses.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.63.23.60] Content-Type: multipart/alternative; boundary="_000_1f351db098b14de0ad5a18ffe072bad9XCHRCD007ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [netconf] overview of updates and current issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 13:55:06 -0000 --_000_1f351db098b14de0ad5a18ffe072bad9XCHRCD007ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, From: netconf On Behalf Of Kent Watsen Sent: 15 April 2019 22:06 To: Juergen Schoenwaelder Cc: netconf@ietf.org Subject: Re: [netconf] overview of updates and current issues Hi Juergen, Thanks for your response. Current Issues: 1. Regarding the "demux containers": Pros: - now the NC/RC models look better - a convenient place to have a nacm:default-deny-write Cons: - seems overbearing for general use Question: Would it be better to revert and instead wrap each "uses" statement in the NC/RC models with a container? Pros: maximum flexibility Cons: less consistency? What exactly are the demux containers? You mean the and containers? Yes. This is what what meant by: "Added a top-level "demux container" inside the top-level grouping. By "demux", I'm referring to the namespace problem discussed @104." about 10 lines above. I have no strong opinion, they may be ok although things get a bit more ver= bose. On the "Cons" side, I'm calling the containers "--= parameters". I question is if this is a good name in all contexts. By rem= oving the "demux container", it lets the consumer decide what to call it. = This brings us to the "less consistency?" comment; of course there would = be little consistency but, do we care? Regarding "a convenient place to have a nacm:default-deny-write", I don't s= ee anywhere in RFC 8341 that nacm:default-deny-write can't be used in a gro= uping, but it will impact the parent... If the parent has other descendent= s besides from the grouping, those descendents would likely be impacted too= , right? Do we care? If we put nacm:default-deny-write under the groupin= g statement, then I think that it subtly enforces consumers to create their= own wrapper containers (as opposed to mixing the descendents in with other= nodes). Alternately, we could float the "if-feature" statement down to e= ach descendent of the grouping. Not ideal, but works...? [RW] It's not obvious to me what a nacm:default-deny-write means when applied to= a grouping, noting that RFC 7950 section 7.12 indicates that the extension= statement applies to the grouping statement itself, not the data node unde= r which the grouping is used. I wouldn't be surprised if quite a few YANG compilers would just regard thi= s as a bug, or at least they wouldn't all behave in a consistent way. Thanks, Rob 2. Only in the RESTCONF draft, http proxy-server weirdness a) in the "ietf-restconf-client", there's an unwanted "proxy-server" definition (middle of page 43): /restconf-client/listen/endpoint/https/http-client-parameters/proxy-se= rver An HTTP client that receives a call-home connection does NOT need to initiate a connection and therefore there never is a desire to configure a proxy server, but here it is! It's here because the "ieft-http-client" grouping defines it, but when that grouping is used, neither "refine" nor "augment" can remove the definition. Sure, a "must" could disable it, but it still shows in the tree diagram, which is undesirable... b)in the "ietf-restconf-server", there's a missing "proxy-server" definition (bottom of page 48 ): /restconf-server/call-home/restconf-client/endpoints/endpoint/\ https/http-client-parameters/ An HTTP server that establishes a call-home connection needs to initiate a connection and therefore there is a desire to configure a proxy server, but the config node is missing! This is because the "ieft-http-server" grouping doesn't defines a proxy-server node (because servers typically never need to go through a proxy so, when that grouping is used, the definition is missing. Sure, we could augment it in, but coupled with the above, maybe there's a better answer? What to do? No idea. This remains an open issue. 3. In either the NETCONF and RESTCONF drafts, does it matter at all where a 'must' statement is located, especially if they refer to nodes that are conditional by "if-feature" statements? i.e., search for "case periodic-connection" Should the "must" statements be located somewhere else? I actually wonder whether this must is really desirable. What breaks if I have TCP keep-alives turned on for a periodic call-home connection? Perhaps I want to enable keep-alives to work around a broken firewall. The point of the periodic connection, from which it gets its name, is that = it "frequently" sets-up and tears-down. Thus is self-healing in the case o= f a network drop. Our WG's primary use-case for keepalives is a device that has been configur= ed to periodically call-home (perhaps every midnight), in case its controll= er application has any config pending for it (depositing logs is assumed to= be out-of-band). One can imagine the controller performing a number of = steps, potentially with delays between the steps. The ietf-[net/rest]conf-server-grouping groupings say this about the "perio= dic-connection" presence container (under "call-home"): "Periodically connect to the NETCONF client. The NETCONF client should close the underlying TCP connection upon completing planned activities. So, if the connection is dropped (do to a lack a keepalives), should the se= rver interpret that as "the client completed planned activities", and there= fore doesn't need to connect again until next midnight? Separately (not related to the above), the ietf-[net/rest]conf-client-group= ing groupings say (under "initiate"): "Periodically connect to the NETCONF server. The NETCONF server should close the underlying TCP connection upon completing planned activities. which might be right, but somehow it feels odd that the client wouldn't alw= ays do close the connection... 4) Only in the NETCONF draft, Section 5 contains the old "Design Considerations" text from ~5 years ago. The idea of removing is was discussed a while back, and someone said it was worth keeping... I'm thinking again to remove it, but rather to deleting it, I'm now thinking maybe we could *move* it to an Informational draft: "Architecture for the Collection of Client and Server Models" that could also contain a picture like this: crypto-types ^ ^ / \ / \ trust-anchors keystore ^ ^------+ ^ | \ | | +-----------+ | / \ tcp-client-server ssh-client-server tls-client-server http-cli= ent-server ^ ^ ^ ^ ^ = ^ | | | | | = | | | | +----------+ | = | | | | | | = | | | | | | = | | +--------------|-------|------------+ | = | | | | | | = | | | | | | = | +--------------+ | | | | +--------= + | | | | | | | | | | | | netconf-client-server restconf-client-server If there is desire, it would be best to do it now so that all of the client/server drafts could reference it. Thus, whichever draft a reader begins with, their attention is drawn to the collection and thus they can see how the part fits into the whole. I like the modularization you are doing but perhaps the problem is that the packaging of this stuff into documents makes things hard to follow. For example, why not define crypto-types, trust-anchors, and keystore into one document? Then this document could explain the top part of your figure. One could perhaps also put tcp-client-server, tls-client-server, and http-client-server together, perhaps even adding ssh-client-server to it. Note that you always revise the modules are different speeds later on since you can have future RFCs take over control over a specific module. I'm not interested in doing this work, especially given where we are now. = If there is consensus in the WG, I request someone take over being Editor = for awhile. That said, I believe we need to document the design of this somewhere so that others use it instead of rolling their own solutions. So my preference likely is to do both, merge some closely related modules into single documents and have a document that explains the overall design and how it is to be used by others. I support "have a document that explains the overall design and how it is t= o be used by others", but I would like someone else to pick up the pen. In= the meanwhile, I think that it is safe to delete Section 5 (Design Conside= rations) from the netconf-client-server draft. Someone can grab it from t= he archives when needed. Kent --_000_1f351db098b14de0ad5a18ffe072bad9XCHRCD007ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kent,

 = ;

From= : netconf <netconf-bounces@ietf.org> On Behalf Of Kent Watsen
Sent: 15 April 2019 22:06
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de&g= t;
Cc: netconf@ietf.org
Subject: Re: [netconf] overview of updates and current issues

 

 

Hi Juergen,<= /p>

 

Thanks for your respons= e.

 



Current Issues:

1. Regarding the "demux containers":

    Pros:
      - now the NC/RC models look better
      - a convenient place to have a nacm:def= ault-deny-write

    Cons:
      - seems overbearing for general use

  Question:

    Would it be better to revert and instead wrap each = "uses"
    statement in the NC/RC models with a container?

       Pros: maximum flexibility
       Cons: less consistency?


What exactly are the demux containers? You mean the
<tcp-client-parameters> and <tls-client-parameters> containers?=

 

Yes.  This is what= what meant by:

 

   "Ad= ded a top-level "demux container" inside the top-level grouping.<= br>     By "demux", I'm referring to the namespace problem = discussed @104."

 

about 10 lines above.=

 

 



I have no strong o= pinion, they may be ok although things get a bit more verbose.

 

On the "Cons"= side, I'm calling the containers "<protocol>-<client/server&= gt;-parameters".  I question is if this is a good name in all con= texts.  By removing the "demux container",  it lets the= consumer decide what to call it.  This brings us to the "less consistency?" comm= ent;  of course there would be little consistency but, do we care?

 

Regarding "a conve= nient place to have a nacm:default-deny-write", I don't see anywhere i= n RFC 8341 that nacm:default-deny-write can't be used in a grouping, but it= will impact the parent...  If the parent has other descendents besides from the grouping, those descendents would likel= y be impacted too, right?   Do we care?  If we put nacm:defa= ult-deny-write under the grouping statement, then I think that it subtly en= forces consumers to create their own wrapper containers (as opposed to mixing the descendents in with other nodes).   Alterna= tely, we could float the "if-feature" statement down to each desc= endent of the grouping.  Not ideal, but works...?

[RW]

It’s not obvious to me wh= at a nacm:default-deny-write means when applied to a grouping, noting that = RFC 7950 section 7.12 indicates that the extension statement applies to the grouping statement itself, not the data node under which th= e grouping is used.

 

I wouldn’t be surprised i= f quite a few YANG compilers would just regard this as a bug, or at least t= hey wouldn’t all behave in a consistent way.

 

Thanks,
Rob

 

 

 

2. Only in the RESTCONF= draft, http proxy-server weirdness

  a) in the "ietf-restconf-client", there's an unwanted= "proxy-server"
     definition  (middle of page 43):

     /restconf-client/listen/endpoint/https/http-c= lient-parameters/proxy-server

     An HTTP client that receives a call-home conn= ection does NOT need
     to initiate a connection and therefore there = never is a desire to
     configure a proxy server, but here it is!

     It's here because the "ieft-http-client&= quot; grouping defines it, but
     when that grouping is used, neither "ref= ine" nor "augment" can
     remove the definition.

     Sure, a "must" could disable it, bu= t it still shows in the tree
     diagram, which is undesirable...


 b)in the "ietf-restconf-server", there's a missing "pr= oxy-server"
     definition  (bottom of page 48 ):

     /restconf-server/call-home/restconf-client/en= dpoints/endpoint/\
     https/http-client-parameters/<missing:prox= y-server/>

     An HTTP server that establishes a call-home c= onnection needs
     to initiate a connection and therefore there = is a desire to
     configure a proxy server, but the config node= is missing!

     This is because the "ieft-http-server&qu= ot; grouping doesn't
     defines a proxy-server node (because servers = typically
     never need to go through a proxy so, when tha= t grouping
     is used, the definition is missing.

     Sure, we could augment it in, but coupled wit= h the above,
     maybe there's a better answer?

 What to do?


No idea.

 

This remains an open is= sue.

 



3. In either the NETCON= F and RESTCONF drafts, does it matter at all
  where a 'must' statement is located, especially if they refer t= o
  nodes that are conditional by "if-feature" statements= ?

     i.e., search for "case periodic-connecti= on"

  Should the "must" statements be located somewhere els= e?


I actually wonder whether this must is really desirable. What breaks
if I have TCP keep-alives turned on for a periodic call-home connection? Perhaps I want to enable keep-alives to work around a broken firewall.=

 

The point of the period= ic connection, from which it gets its name, is that it "frequently&quo= t; sets-up and tears-down.  Thus is self-healing in the case of a netw= ork drop.

 

Our WG's primary use-ca= se for keepalives is a device that has been configured to periodically call= -home (perhaps every midnight), in case its controller application has any = config pending for it (depositing logs is assumed to be out-of-band).    One can imagine the controller= performing a number of steps, potentially with delays between the steps.

 

The ietf-[net/rest]conf= -server-grouping groupings say this about the "periodic-connection&quo= t; presence container (under "call-home"):

 

      &n= bsp;              "Periodically con= nect to the NETCONF client.  The

      &n= bsp;               NETCONF client should= close the underlying TCP

      &n= bsp;               connection upon compl= eting planned activities.

 

So, if the connection i= s dropped (do to a lack a keepalives), should the server interpret that as = "the client completed planned activities", and therefore doesn't = need to connect again until next midnight?

 

 

Separately (not related= to the above), the ietf-[net/rest]conf-client-grouping groupings say (unde= r "initiate"):

 

      &n= bsp;              "Periodically con= nect to the NETCONF server.  The

      &n= bsp;               NETCONF server should= close the underlying TCP

      &n= bsp;               connection upon compl= eting planned activities.

 

which might be right, b= ut somehow it feels odd that the client wouldn't always do close the connec= tion...

 

 

 



4) Only in the NETCONF = draft, Section 5 contains the old  "Design
  Considerations" text from ~5 years ago.

  The idea of removing is was discussed a while back, and someone=
  said it was worth keeping...

  I'm thinking again to remove it, but rather to deleting it, I'm=
  now thinking maybe we could *move* it to an Informational draft= :

    "Architecture for the Collection of Client and= Server Models"

  that could also contain a picture like this:

            &nb= sp;            =             &nb= sp; crypto-types
            &nb= sp;            =             &nb= sp;   ^      ^
            &nb= sp;            =             &nb= sp;  /        \
            &nb= sp;            =             &nb= sp; /          \
            &nb= sp;            =     trust-anchors       k= eystore
            &nb= sp;            =        ^      ^= ------+    ^
            &nb= sp;            =        |      &= nbsp;       \   |
            &nb= sp;            =        |      &= #43;-----------+
            &nb= sp;            =        |     /  = ;        \
tcp-client-server     ssh-client-server   &nb= sp;  tls-client-server     http-client-server=
      ^      ^  = ;            ^ =             &nb= sp;    ^        &nbs= p;  ^           = ;    ^
      |      |  = ;            | =             &nb= sp;    |        &nbs= p;  |           = ;    |
      |      |  = ;            | =       +----------+    =        |      &= nbsp;        |
      |      |  = ;            | =       |       &= nbsp;           &nbs= p;  |           = ;    |
      |      |  = ;            | =       |       &= nbsp;           &nbs= p;  |           = ;    |
      |      +--= ------------|-------|------------+       =   |           &= nbsp;   |
      |       &= nbsp;           &nbs= p; |       |     &nb= sp;      |      &nbs= p;  |           = ;    |
      |       &= nbsp;           &nbs= p; |       |     &nb= sp;      |      &nbs= p;  |           = ;    |
      +--------------+   &n= bsp;  |       |    &= nbsp;       |     &n= bsp;   |      +--------+             &nb= sp;        |    &nbs= p; |       |     &nb= sp;      |      &nbs= p;  |      |
            &nb= sp;        |    &nbs= p; |       |     &nb= sp;      |      &nbs= p;  |      |
            &nb= sp;     netconf-client-server    &n= bsp;   restconf-client-server




 If there is desire, it would be best to do it now so that all of
 the client/server drafts could reference it.  Thus, whichever dr= aft
 a reader begins with, their attention is drawn to the collection and<= br>  thus they can see how the part fits into the whole.


I like the modularization you are doing but perhaps the problem is
that the packaging of this stuff into documents makes things hard to
follow. For example, why not define crypto-types, trust-anchors, and
keystore into one document? Then this document could explain the top
part of your figure. One could perhaps also put tcp-client-server,
tls-client-server, and http-client-server together, perhaps even
adding ssh-client-server to it. Note that you always revise the
modules are different speeds later on since you can have future RFCs
take over control over a specific module.

 

I'm not interested in d= oing this work, especially given where we are now.   If there is conse= nsus in the WG, I request someone take over being Editor for awhile.

 



That said, I believe we= need to document the design of this somewhere
so that others use it instead of rolling their own solutions. So my
preference likely is to do both, merge some closely related modules
into single documents and have a document that explains the overall
design and how it is to be used by others.

 

 

I support "have a = document that explains the overall design and how it is to be used by other= s", but I would like someone else to pick up the pen.  In the mea= nwhile, I think that it is safe to delete Section 5 (Design Considerations) from the netconf-client-server draft.   Someo= ne can grab it from the archives when needed.

 

 

Kent

 

 

--_000_1f351db098b14de0ad5a18ffe072bad9XCHRCD007ciscocom_-- From nobody Tue Apr 23 13:38:56 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AEC12035F; Tue, 23 Apr 2019 13:38:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ibagdona@gmail.com, mjethanandani@gmail.com, netconf-chairs@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155605193412.32465.13576495156559220644.idtracker@ietfa.amsl.com> Date: Tue, 23 Apr 2019 13:38:54 -0700 Archived-At: Subject: [netconf] netconf - Update to a Meeting Session Request for IETF 105 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 20:38:54 -0000 An update to a meeting session request has just been submitted by Mahesh Jethanandani, a Chair of the netconf working group. --------------------------------------------------------- Working Group Name: Network Configuration Area Name: Operations and Management Area Session Requester: Mahesh Jethanandani Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: netmod Second Priority: opsarea opsawg tsvwg babel idr tcpm Third Priority: sacm saag People who must be present: Mahesh Jethanandani Kent Watsen Ignas Bagdonas Resources Requested: Special Requests: Friday does not work for the WG. --------------------------------------------------------- From nobody Wed Apr 24 05:52:49 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5B01200A1 for ; Wed, 24 Apr 2019 05:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.011 X-Spam-Level: X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoqhVbKhQhw3 for ; Wed, 24 Apr 2019 05:52:43 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80045.outbound.protection.outlook.com [40.107.8.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED5FB120086 for ; Wed, 24 Apr 2019 05:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1aSDbauqddK4SrGnic0MR4teCzlptEgNnuIZC4GGOeg=; b=TWFmTyWsAF3WVJbaRC6VXcPSsM5CpbZOXCJNXVc929XJin4vX1N21Hu7SQgJ2619U7PzEHAx7RnizVFJ4vt0HYHlz7VEHfDF++PWiA5KYdlPiKV+ts7GGOulPOjBH4QoHgwoxAASt4pq+YMlQx4g7myLeCykMLceDrmT7upiscA= Received: from VI1PR07MB4735.eurprd07.prod.outlook.com (20.177.57.146) by VI1PR07MB3870.eurprd07.prod.outlook.com (52.134.26.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.5; Wed, 24 Apr 2019 12:52:34 +0000 Received: from VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::612d:6747:3f58:d6be]) by VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::612d:6747:3f58:d6be%4]) with mapi id 15.20.1835.010; Wed, 24 Apr 2019 12:52:34 +0000 From: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= To: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , Martin Bjorklund , "ietfc@btconnect.com" CC: "netconf@ietf.org" Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpALufsOAAAVM5oADthG5oA== Date: Wed, 24 Apr 2019 12:52:34 +0000 Message-ID: References: <20190404164929.fsfga7s4izn7ucx5@anna.jacobs.jacobs-university.de> <20190404.194623.1178346313710501110.mbj@tail-f.com> <01dd01d4eb9c$b9a04160$4001a8c0@gateway.2wire.net> <20190405.142201.707949273328784535.mbj@tail-f.com> <413d5725-9c27-e50b-2622-1b0e2f35cdb1@ericsson.com> In-Reply-To: <413d5725-9c27-e50b-2622-1b0e2f35cdb1@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c3bfa6a6-2651-4c08-fa05-08d6c8b3b911 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB3870; x-ms-traffictypediagnostic: VI1PR07MB3870: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 00179089FD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(136003)(39860400002)(366004)(396003)(189003)(199004)(13464003)(14454004)(14444005)(66574012)(966005)(7696005)(6506007)(53546011)(790700001)(68736007)(76176011)(97736004)(256004)(478600001)(33656002)(476003)(5660300002)(11346002)(446003)(2906002)(2501003)(71190400001)(71200400001)(486006)(85182001)(8676002)(81166006)(3846002)(81156014)(6116002)(8936002)(66066001)(93886005)(9326002)(86362001)(76116006)(25786009)(55016002)(66556008)(64756008)(66446008)(66946007)(66476007)(186003)(73956011)(26005)(85202003)(4326008)(6436002)(606006)(74316002)(229853002)(53936002)(316002)(102836004)(110136005)(9686003)(54896002)(6306002)(52536014)(236005)(6246003)(99286004)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3870; H:VI1PR07MB4735.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: XlT4gVOYqeTTMRX27zCjmL1ZRnbJRiL5CokrxRE6W9ZqLjuRucgjE5f5obkJ7l6/XJjRgAKp4gPRBtaUE97VGchZl2mAZapCaocYzvAKDCOSgGWGTq9rd4J0tnitqrYKYbjWyWW5nyWYd9vo9DbpKvR3llCou1yQq2mPP9k9IWpT5ioOR4Ir3URiYTXPkBuKnXeHyAIuO14d5YuCrTKPd88VPNP6PNU1Br3wRG/NqYQLTFLr1ioQpRFL1lMGc1Ls9pt/laTcgQtYWj+hRTfQWh6Vp3muAd1KIIl18gvkPgDer/aIEfOwc9PmmpzVXq/K+LILJvLcrjNfM83DVjrWWeLyAEdNUXWX0inYxI0urXE7AF1wqakHwsAPrjUzCLtAEq7f8YKoN+sV/W0C/C0lxuDeJ3Ha3zto4SQk7xabTls= Content-Type: multipart/alternative; boundary="_000_VI1PR07MB4735949BE61335ACC8A975E7833C0VI1PR07MB4735eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: c3bfa6a6-2651-4c08-fa05-08d6c8b3b911 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2019 12:52:34.8057 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3870 Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 12:52:47 -0000 --_000_VI1PR07MB4735949BE61335ACC8A975E7833C0VI1PR07MB4735eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCklzIHRoZXJlIGEgY29uY2x1c2lvbiBvbiB0aGlzIHRocmVhZD8NCg0KQWx0ZXJuYXRp dmVzIEnigJl2ZSBzZWVuOg0KDQoNCiAgMS4gIOKAmGhpZGRlbuKAmSBhY3Rpb25zIGFscmVhZHkg c29sdmUgdGhlIHByb2JsZW0uDQogICAgICogICBCYWNrdXAgb2Yga2V5cyB3b27igJl0IGJlIHN1 cHBvcnRlZCBvciBzcGVjaWFsIHByb2NlZHVyZSBuZWVkZWQuDQogICAgICogICBEZXNjcmlwdGlv bnMgbmVlZCB0byBiZSB1cGRhdGVkIHRvIGdlbmVyYWxpemUgdXNlIGNhc2UgKG5vdCBiZSByZXN0 cmljdGVkIHRvIFRQTXMpLg0KICAyLiAgQ3VycmVudCBhY3Rpb25zIHNvbHZlIHRoZSBwcm9ibGVt LCBidXQgbmV3IHRlcm1pbm9sb2d5IHNob3VsZCBiZSBuZWVkZWQgaW5zdGVhZCBvZiDigJhoaWRk ZW7igJkgYW5kIOKAmHBlcm1hbmVudGx5IGhpZGRlbuKAmS4NCiAgICAgKiAgIEJhY2t1cCBvZiBr ZXlzIHdvbuKAmXQgYmUgc3VwcG9ydGVkIG9yIHNwZWNpYWwgcHJvY2VkdXJlIG5lZWRlZC4NCiAg ICAgKiAgIERlc2NyaXB0aW9ucyB0byBiZSB1cGRhdGVkLg0KICAzLiAgTmV3IGFjdGlvbnMgbmVl ZGVkIHRoYXQgYWZmZWN0IGNvbmZpZ3VyYXRpb24gZm9yIG5vbi1UUE0gdXNlIGNhc2VzDQogICAg ICogICBCYWNrdXAgb2Yga2V5cyBjYW4gYmUgc3VwcG9ydGVkDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGkuICAgICAgUTog aG93IGRvZXMgYSByZXN0b3JlIGRpZmZlciBmcm9tIG5vcm1hbCBjb25maWd1cmF0aW9uIHdoaWNo IHRoZSBnZW5lcmF0ZSBrZXkgYWN0aW9uIHdhcyBzdXBwb3NlZCB0byBjaXJjdW12ZW50IHRvIGZv bGxvdyBzZWN1cml0eSBiZXN0IHByYWN0aWNlPw0KDQpJIGd1ZXNzIHRoZSBsYXRlc3QgbWFpbHMg Y29uZmlybSAxKSBvciAyKS4gV291bGQgYmUgZ29vZCB0byBrbm93IHRoZSB3YXkgZm9yd2FyZC4N Cg0KQnIsDQpCYWxhenMNCg0KRnJvbTogbmV0Y29uZiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3Jn PiBPbiBCZWhhbGYgT2YgQmFsw6F6cyBMZW5neWVsDQpTZW50OiBGcmlkYXksIEFwcmlsIDUsIDIw MTkgNDo1NCBQTQ0KVG86IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPjsgaWV0ZmNA YnRjb25uZWN0LmNvbQ0KQ2M6IG5ldGNvbmZAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0Y29u Zl0gaWV0ZiBjcnlwdG8gdHlwZXMgLSBwZXJtYW5lbnRseSBoaWRkZW4NCg0KDQpIZWxsbywNCg0K V2hpbGUgdXNpbmcgYWN0aW9ucyB0byBjb25maWd1cmUgZGF0YSBub2RlcyBpbnN0ZWFkIG9mIGVk aXQtY29uZmlnIGNsZWFybHkgaGFzIHByb2JsZW1zLCBpbiBzb21lIGNhc2VzIGl0IGlzIG5lZWRl ZC4gRXJpY3Nzb24gZG9lcyB1c2UgaXQsIGJ1dCB3ZSB0cnkgdG8gYmUgVkVSWSghKSByZXN0cmlj dGl2ZSB3aGVuIGl0IGlzIGFsbG93ZWQuIElNSE8gIHNlY3VyaXR5IGJlc3QgcHJhY3RpY2UgY291 bGQgYmUgb25lIGNhc2UuIEFsc28gd2Ugc2hvdWxkIG5vdCBwcmV0ZW5kIHRoaXMgaXMgdGhlIG9u bHkgY2FzZSB3aGVyZSB0aGUgc3lzdGVtIGl0c2VsZiBtYW5pcHVsYXRlcyBjb25maWd1cmF0aW9u Og0KDQogICogICBzZWN1cml0eSBrZXlzDQogICogICBIVyBpbnNlcnRpb24vcmVtb3ZhbCAoaW50 ZXJmYWNlIHR5cGUpDQogICogICBvbmJvYXJkIGF1dG9tYXRpb24gbWF5IGRvIGl0DQogICogICBz ZXJ2ZXIgY2FwYWJpbGl0aWVzIHRoYXQgbmVlZCBhZGRpdGlvbmFsIGNvbmZpZ3VyYXRpb24gKG11 c3QgYmUgaW4gcnVubmluZyBhcyBpdCBpcyByZWZlcmVuY2UgZnJvbSBvdGhlciBwYXJ0cyBvZiB0 aGUgY29uZmlndXJhdGlvbikNCg0KSSBhbHNvIGhvcGUgd2Ugd2lsbCBhcnJpdmUgYXQgYSBzb2x1 dGlvbiB0aGF0IHdvcmtzIGZvciBub24tTk1EQSBzeXN0ZW1zIHRvby4gQUZBSUsgIHdlIG5ldmVy IHN0YXRlZCBpbiBhbnkgUkZDIHRoYXQgTk1EQSBpcyBhIHJlcXVpcmVtZW50IGZvciB0aGUgc29s dXRpb24uIChFeGNlcHQgZm9yIE5NREEgaXRzZWxmIDotKSAgKQ0KDQpyZWdhcmRzIEJhbGF6cw0K T24gMjAxOS4gMDQuIDA1LiAxNDoyMiwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToNCg0KdG9tIHBl dGNoIDxpZXRmY0BidGNvbm5lY3QuY29tPjxtYWlsdG86aWV0ZmNAYnRjb25uZWN0LmNvbT4gd3Jv dGU6DQoNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQoNCkZyb206ICJNYXJ0aW4g QmpvcmtsdW5kIiA8bWJqQHRhaWwtZi5jb20+PG1haWx0bzptYmpAdGFpbC1mLmNvbT4NCg0KVG86 IDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+PG1haWx0bzpqLnNjaG9lbndh ZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+DQoNCkNjOiA8bmV0Y29uZkBpZXRmLm9yZz48bWFp bHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQoNClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwNCwgMjAxOSA2 OjQ2IFBNDQoNCg0KDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNv YnMtdW5pdmVyc2l0eS5kZT48bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0 eS5kZT4gd3JvdGU6DQoNCk9uIFRodSwgQXByIDA0LCAyMDE5IGF0IDA0OjIzOjIzUE0gKzAwMDAs IEtlbnQgV2F0c2VuIHdyb3RlOg0KDQoNCg0KDQoNCldlIGhhdmUgYWx3YXlzIHNhaWQgbm8sIGJ1 dCB0aGUgcmVhc29uaW5nIGlzIHVuY2xlYXIuICBXaGF0IGFyZQ0KDQp0aGUNCg0Kc3BlY2lmaWMg b2JqZWN0aW9ucyBhbmQgaXMgdGhlcmUgYW55d2F5IHRvIGFsbGV2aWF0ZSB0aGVtPw0KDQoNCg0K DQoNCklmIGVkaXRpbmcgb2YgYWxsIGNvbmZpZ3VyYXRpb24gY2FuIGJlIGRvbmUgd2l0aCBhIHNp bmdsZSBlZGl0LWRhdGENCg0KKG9yIGVkaXQtY29uZmlnKSBvcGVyYXRpb24sIHlvdSBzaW1wbGlm eSB0aGUgd29ybGQgYW5kIHlvdSBlbmFibGUNCg0KZ2VuZXJpYyBpbXBsZW1lbnRhdGlvbnMuDQoN Cg0KDQpPbmNlIHlvdSBidWlsZCBzaWxvcyBvZiBkYXRhIHRoYXQgY2FuIG9ubHkgYmUgbWFuaXB1 bGF0ZWQgd2l0aA0KDQpzcGVjaWFsDQoNCnB1cnBvc2Ugb3BlcmF0aW9ucywgeW91IHNheSBnb29k YnllIHRvIHRoZSBpZGVhIG9mIGdlbmVyaWMgY2xpZW50DQoNCmxpYnJhcmllcy4NCg0KDQoNCkFu ZCB5b3UgY2FuIG5vIGxvbmdlciBjcmVhdGUgYWxsIHJlcXVpcmVkIGNvbmZpZyBpbiBvbmUgdHJh bnNhY3Rpb247DQoNCnlvdSBoYXZlIHRvIHNwbGl0IGl0IGludG8gc2VuZGluZyBtdWx0aXBsZSBz cGVjaWFsLXB1cnBvc2UgYWN0aW9ucy4NCg0KUGVyaGFwcyBhbHNvIGluIGEgY2VydGFpbiBvcmRl ciwgdGhhdCB5b3UgaGF2ZSB0byBmaWd1cmUgb3V0IHNvbWVob3csDQoNCnNpbmNlIGNvbmZpZyBt aWdodCBoYXZlIHJlZmVyZXJlbmNlcyB0byBvdGhlciBwYXJ0ZiBvZiB0aGUgY29uZmlnDQoNCmV0 Yy4NCg0KDQoNCllvdSBjYW4gbm8gbG9uZ2VyIHJlc3RvcmUgYSBiYWNrdXAgd2l0aCBqdXN0IGEg Y29weS1jb25maWcuDQoNCg0KDQpXaGljaCBpcyBleGFjdGx5IHdoYXQgSSBoYXZlIHNlZW4gY3Vz dG9tZXJzIC0gdGhpbmsgbWlsaXRhcnkgLSBkby4NCg0KDQoNClNlY3VyaXR5LXJlbGF0ZWQgaW5m b3JtYXRpb24gLSB1c2VyaWQsIHBhc3N3b3Jkcywgc2Vjb25kIGZhY3RvciAsIC4uLi0NCg0KTVVT VCBOT1QgYmUgYmFja2VkIHVwIGxpa2UgZXZlcnl0aGluZyBlbHNlIC0gc3BlY2lhbCBwcm9jZWR1 cmVzIC0NCg0KYXV0aGVudGljYXRpb24sIGVuY3J5cHRpb24gLSAgbXVzdCBiZSB1c2VkLg0KDQoN Cg0KQWdyZWVkISAgQlVULCB0aGVuIGl0IHNob3VsZCBub3QgYmUgbW9kZWxsZWQgYXMgY29uZmln dXJhdGlvbiwgaW1vLg0KDQoNCg0KQW5kIHRoZSBjdXJyZW50IG1vZGVsIGFscmVhZHkgaGFuZGxl cyB0aGlzIGNhc2Ugd2l0aCAiaGlkZGVuIiBrZXlzLg0KDQoNCg0KDQoNCg0KDQoNCg0KL21hcnRp bg0KDQoNCg0KDQoNClRoaXMgaXMgc2VjdXJpdHkgLSBpdCBtYXR0ZXJzLg0KDQoNCg0KVG9tIFBl dGNoDQoNCg0KDQpTbyBJIGRvbid0IHRoaW5rIHRoZSByZWFzb25pbmcgaXMgdW5jbGVhciBhdCBh bGwuDQoNCg0KDQovbWFydGluDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQpuZXRjb25mIG1haWxpbmcgbGlzdA0KDQpuZXRjb25mQGlldGYu b3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmYNCg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KbmV0Y29uZiBtYWlsaW5nIGxpc3QNCg0KbmV0 Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCg0KDQotLQ0KDQpCYWxhenMgTGVuZ3ll bCAgICAgICAgICAgICAgICAgICAgICAgRXJpY3Nzb24gSHVuZ2FyeSBMdGQuDQoNClNlbmlvciBT cGVjaWFsaXN0DQoNCk1vYmlsZTogKzM2LTcwLTMzMC03OTA5ICAgICAgICAgICAgICBlbWFpbDog QmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tPG1haWx0bzpCYWxhenMuTGVuZ3llbEBlcmljc3Nv bi5jb20+DQo= --_000_VI1PR07MB4735949BE61335ACC8A975E7833C0VI1PR07MB4735eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTow aW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpi bGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xv cjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6Nzc3NTM3ODE7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOi0yOTk5ODcwNTA7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxDQoJ e21zby1saXN0LWlkOjc5MTcwNTQ5MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6LTEzMzAwMTI2MiA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5 ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlz dCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDIN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9t YW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJ e21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7 DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50 Oi05LjBwdDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDo4ODE5ODc5NjY7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOi0yMTE1ODgzNjY4O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6 bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3Qt aWQ6MTY2NjU0Mzc5OTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTcwNDYxODM1Njt9DQpAbGlz dCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+SGks PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5JcyB0aGVyZSBhIGNv bmNsdXNpb24gb24gdGhpcyB0aHJlYWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0Ij5BbHRlcm5hdGl2ZXMgSeKAmXZlIHNlZW46PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0 YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9ImNv bG9yOndpbmRvd3RleHQ7bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj4N CuKAmGhpZGRlbuKAmSBhY3Rpb25zIGFscmVhZHkgc29sdmUgdGhlIHByb2JsZW0uIDxvOnA+PC9v OnA+PC9saT48b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iYSI+DQo8 bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O21hcmdp bi1sZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZlbDIgbGZvMyI+DQpCYWNrdXAgb2Yga2V5cyB3b27i gJl0IGJlIHN1cHBvcnRlZCBvciBzcGVjaWFsIHByb2NlZHVyZSBuZWVkZWQuPG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7 bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMiBsZm8zIj4NCkRlc2NyaXB0aW9ucyBu ZWVkIHRvIGJlIHVwZGF0ZWQgdG8gZ2VuZXJhbGl6ZSB1c2UgY2FzZSAobm90IGJlIHJlc3RyaWN0 ZWQgdG8gVFBNcykuDQo8bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7bWFyZ2luLWxlZnQ6MGluO21zby1saXN0 OmwxIGxldmVsMSBsZm8zIj4NCkN1cnJlbnQgYWN0aW9ucyBzb2x2ZSB0aGUgcHJvYmxlbSwgYnV0 IG5ldyB0ZXJtaW5vbG9neSBzaG91bGQgYmUgbmVlZGVkIGluc3RlYWQgb2Yg4oCYaGlkZGVu4oCZ IGFuZCDigJhwZXJtYW5lbnRseSBoaWRkZW7igJkuPG86cD48L286cD48L2xpPjxvbCBzdHlsZT0i bWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIxIiB0eXBlPSJhIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7bWFyZ2luLWxlZnQ6MGluO21zby1saXN0 OmwxIGxldmVsMiBsZm8zIj4NCkJhY2t1cCBvZiBrZXlzIHdvbuKAmXQgYmUgc3VwcG9ydGVkIG9y IHNwZWNpYWwgcHJvY2VkdXJlIG5lZWRlZC48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDttYXJnaW4tbGVmdDowaW47bXNv LWxpc3Q6bDEgbGV2ZWwyIGxmbzMiPg0KRGVzY3JpcHRpb25zIHRvIGJlIHVwZGF0ZWQuPG86cD48 L286cD48L2xpPjwvb2w+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0O21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+DQpO ZXcgYWN0aW9ucyBuZWVkZWQgdGhhdCBhZmZlY3QgY29uZmlndXJhdGlvbiBmb3Igbm9uLVRQTSB1 c2UgY2FzZXM8bzpwPjwvbzpwPjwvbGk+PG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9 IjEiIHR5cGU9ImEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dDttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzMiPg0KQmFj a3VwIG9mIGtleXMgY2FuIGJlIHN1cHBvcnRlZDxvOnA+PC9vOnA+PC9saT48L29sPg0KPC9vbD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS41aW47dGV4 dC1pbmRlbnQ6LTEuNWluO21zby10ZXh0LWluZGVudC1hbHQ6LTkuMHB0O21zby1saXN0OmwxIGxl dmVsMyBsZm8zIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj48c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPmkuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5ROiBob3cg ZG9lcyBhIHJlc3RvcmUgZGlmZmVyIGZyb20gbm9ybWFsIGNvbmZpZ3VyYXRpb24gd2hpY2ggdGhl IGdlbmVyYXRlIGtleSBhY3Rpb24gd2FzIHN1cHBvc2VkIHRvIGNpcmN1bXZlbnQgdG8gZm9sbG93 IHNlY3VyaXR5IGJlc3QgcHJhY3RpY2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0Ij5JIGd1ZXNzIHRoZSBsYXRlc3QgbWFpbHMgY29uZmlybSAxKSBvciAyKS4gV291 bGQgYmUgZ29vZCB0byBrbm93IHRoZSB3YXkgZm9yd2FyZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQiPkJyLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5CYWxhenM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4gbmV0Y29uZiAmbHQ7bmV0Y29uZi1ib3Vu Y2VzQGlldGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5CYWzDoXpzIExlbmd5ZWw8YnI+ DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCA1LCAyMDE5IDQ6NTQgUE08YnI+DQo8Yj5Ubzo8 L2I+IE1hcnRpbiBCam9ya2x1bmQgJmx0O21iakB0YWlsLWYuY29tJmd0OzsgaWV0ZmNAYnRjb25u ZWN0LmNvbTxicj4NCjxiPkNjOjwvYj4gbmV0Y29uZkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW25ldGNvbmZdIGlldGYgY3J5cHRvIHR5cGVzIC0gcGVybWFuZW50bHkgaGlkZGVu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+SGVsbG8sPG86cD48L286cD48L3A+DQo8cD5X aGlsZSB1c2luZyBhY3Rpb25zIHRvIGNvbmZpZ3VyZSBkYXRhIG5vZGVzIGluc3RlYWQgb2YgZWRp dC1jb25maWcgY2xlYXJseSBoYXMgcHJvYmxlbXMsIGluIHNvbWUgY2FzZXMgaXQgaXMgbmVlZGVk LiBFcmljc3NvbiBkb2VzIHVzZSBpdCwgYnV0IHdlIHRyeSB0byBiZSBWRVJZKCEpIHJlc3RyaWN0 aXZlIHdoZW4gaXQgaXMgYWxsb3dlZC4gSU1ITyZuYnNwOyBzZWN1cml0eSBiZXN0IHByYWN0aWNl IGNvdWxkIGJlIG9uZSBjYXNlLiBBbHNvIHdlIHNob3VsZA0KIG5vdCBwcmV0ZW5kIHRoaXMgaXMg dGhlIG9ubHkgY2FzZSB3aGVyZSB0aGUgc3lzdGVtIGl0c2VsZiBtYW5pcHVsYXRlcyBjb25maWd1 cmF0aW9uOjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZvOCI+DQpzZWN1cml0eSBrZXlzPG86cD48L286 cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzgiPg0K SFcgaW5zZXJ0aW9uL3JlbW92YWwgKGludGVyZmFjZSB0eXBlKTxvOnA+PC9vOnA+PC9saT48bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwzIGxldmVsMSBsZm84Ij4NCm9uYm9hcmQgYXV0 b21hdGlvbiBtYXkgZG8gaXQ8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMyBsZXZlbDEgbGZvOCI+DQpzZXJ2ZXIgY2FwYWJpbGl0aWVzIHRoYXQgbmVlZCBh ZGRpdGlvbmFsIGNvbmZpZ3VyYXRpb24gKG11c3QgYmUgaW4gcnVubmluZyBhcyBpdCBpcyByZWZl cmVuY2UgZnJvbSBvdGhlciBwYXJ0cyBvZiB0aGUgY29uZmlndXJhdGlvbik8bzpwPjwvbzpwPjwv bGk+PC91bD4NCjxwPkkgYWxzbyBob3BlIHdlIHdpbGwgYXJyaXZlIGF0IGEgc29sdXRpb24gdGhh dCB3b3JrcyBmb3Igbm9uLU5NREEgc3lzdGVtcyB0b28uIEFGQUlLJm5ic3A7IHdlIG5ldmVyIHN0 YXRlZCBpbiBhbnkgUkZDIHRoYXQgTk1EQSBpcyBhIHJlcXVpcmVtZW50IGZvciB0aGUgc29sdXRp b24uIChFeGNlcHQgZm9yIE5NREEgaXRzZWxmIDotKSZuYnNwOyApPG86cD48L286cD48L3A+DQo8 cD5yZWdhcmRzIEJhbGF6czxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIDIwMTkuIDA0LiAwNS4gMTQ6MjIsIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT50b20gcGV0Y2ggPGEgaHJlZj0ibWFpbHRvOmlldGZj QGJ0Y29ubmVjdC5jb20iPiZsdDtpZXRmY0BidGNvbm5lY3QuY29tJmd0OzwvYT4gd3JvdGU6PG86 cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4tLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPG86cD48L286cD48L3ByZT4NCjxwcmU+RnJvbTogJnF1 b3Q7TWFydGluIEJqb3JrbHVuZCZxdW90OyA8YSBocmVmPSJtYWlsdG86bWJqQHRhaWwtZi5jb20i PiZsdDttYmpAdGFpbC1mLmNvbSZndDs8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+VG86IDxh IGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUiPiZsdDtq LnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7PC9hPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPkNjOiA8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+Jmx0O25ldGNv bmZAaWV0Zi5vcmcmZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNlbnQ6IFRodXJzZGF5 LCBBcHJpbCAwNCwgMjAxOSA2OjQ2IFBNPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHByZT5KdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGEgaHJlZj0ibWFp bHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSI+Jmx0O2ouc2Nob2Vud2Fl bGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDs8L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wcmU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwcmU+T24gVGh1LCBBcHIgMDQsIDIwMTkgYXQgMDQ6MjM6MjNQTSAmIzQzOzAwMDAsIEtl bnQgV2F0c2VuIHdyb3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+V2UgaGF2ZSBhbHdh eXMgc2FpZCBubywgYnV0IHRoZSByZWFzb25pbmcgaXMgdW5jbGVhci4mbmJzcDsgV2hhdCBhcmU8 bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPHByZT50aGU8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5zcGVjaWZpYyBvYmpl Y3Rpb25zIGFuZCBpcyB0aGVyZSBhbnl3YXkgdG8gYWxsZXZpYXRlIHRoZW0/PG86cD48L286cD48 L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SWYgZWRpdGluZyBvZiBhbGwgY29uZmlndXJh dGlvbiBjYW4gYmUgZG9uZSB3aXRoIGEgc2luZ2xlIGVkaXQtZGF0YTxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPihvciBlZGl0LWNvbmZpZykgb3BlcmF0aW9uLCB5b3Ugc2ltcGxpZnkgdGhlIHdvcmxk IGFuZCB5b3UgZW5hYmxlPG86cD48L286cD48L3ByZT4NCjxwcmU+Z2VuZXJpYyBpbXBsZW1lbnRh dGlvbnMuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+T25jZSB5b3UgYnVpbGQgc2lsb3Mgb2YgZGF0YSB0aGF0IGNhbiBvbmx5IGJlIG1hbmlwdWxh dGVkIHdpdGg8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PHByZT5zcGVjaWFsPG86cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPnB1cnBvc2Ugb3BlcmF0aW9u cywgeW91IHNheSBnb29kYnllIHRvIHRoZSBpZGVhIG9mIGdlbmVyaWMgY2xpZW50PG86cD48L286 cD48L3ByZT4NCjxwcmU+bGlicmFyaWVzLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+ DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkFuZCB5b3UgY2FuIG5vIGxvbmdl ciBjcmVhdGUgYWxsIHJlcXVpcmVkIGNvbmZpZyBpbiBvbmUgdHJhbnNhY3Rpb247PG86cD48L286 cD48L3ByZT4NCjxwcmU+eW91IGhhdmUgdG8gc3BsaXQgaXQgaW50byBzZW5kaW5nIG11bHRpcGxl IHNwZWNpYWwtcHVycG9zZSBhY3Rpb25zLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlBlcmhhcHMg YWxzbyBpbiBhIGNlcnRhaW4gb3JkZXIsIHRoYXQgeW91IGhhdmUgdG8gZmlndXJlIG91dCBzb21l aG93LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNpbmNlIGNvbmZpZyBtaWdodCBoYXZlIHJlZmVy ZXJlbmNlcyB0byBvdGhlciBwYXJ0ZiBvZiB0aGUgY29uZmlnPG86cD48L286cD48L3ByZT4NCjxw cmU+ZXRjLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlPllvdSBjYW4gbm8gbG9uZ2VyIHJlc3RvcmUgYSBiYWNrdXAgd2l0aCBqdXN0IGEgY29weS1j b25maWcuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmU+V2hpY2ggaXMgZXhhY3RseSB3aGF0IEkgaGF2ZSBzZWVuIGN1c3Rv bWVycyAtIHRoaW5rIG1pbGl0YXJ5IC0gZG8uPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmU+U2VjdXJpdHktcmVsYXRlZCBpbmZvcm1hdGlvbiAtIHVz ZXJpZCwgcGFzc3dvcmRzLCBzZWNvbmQgZmFjdG9yICwgLi4uLTxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPk1VU1QgTk9UIGJlIGJhY2tlZCB1cCBsaWtlIGV2ZXJ5dGhpbmcgZWxzZSAtIHNwZWNpYWwg cHJvY2VkdXJlcyAtPG86cD48L286cD48L3ByZT4NCjxwcmU+YXV0aGVudGljYXRpb24sIGVuY3J5 cHRpb24gLSZuYnNwOyBtdXN0IGJlIHVzZWQuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90 ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+QWdyZWVkISZuYnNwOyBCVVQs IHRoZW4gaXQgc2hvdWxkIG5vdCBiZSBtb2RlbGxlZCBhcyBjb25maWd1cmF0aW9uLCBpbW8uPG86 cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+QW5kIHRo ZSBjdXJyZW50IG1vZGVsIGFscmVhZHkgaGFuZGxlcyB0aGlzIGNhc2Ugd2l0aCAmcXVvdDtoaWRk ZW4mcXVvdDsga2V5cy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4vbWFydGluPG86cD48 L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIGlzIHNlY3VyaXR5IC0gaXQgbWF0dGVycy48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5Ub20gUGV0 Y2g8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJl PlNvIEkgZG9uJ3QgdGhpbmsgdGhlIHJlYXNvbmluZyBpcyB1bmNsZWFyIGF0IGFsbC48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4vbWFydGluPG86 cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5uZXRjb25mIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhy ZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0Y29uZiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRj b25mPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+ DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+bmV0Y29u ZiBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86bmV0 Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0K PHByZT4tLSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5CYWxhenMgTGVuZ3llbCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBFcmljc3NvbiBIdW5nYXJ5IEx0ZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TZW5p b3IgU3BlY2lhbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk1vYmlsZTogJiM0MzszNi03MC0z MzAtNzkwOSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbWFpbDogPGEgaHJlZj0ibWFpbHRvOkJhbGF6 cy5MZW5neWVsQGVyaWNzc29uLmNvbSI+QmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tPC9hPiA8 bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_VI1PR07MB4735949BE61335ACC8A975E7833C0VI1PR07MB4735eurp_-- From nobody Wed Apr 24 09:07:18 2019 Return-Path: <0100016a5019d7f9-7f737c63-d07c-4c7f-b12e-c5b19d50eeaf-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C0312001B for ; Wed, 24 Apr 2019 09:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLQ745YYZLWI for ; Wed, 24 Apr 2019 09:07:14 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B247E120004 for ; Wed, 24 Apr 2019 09:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556122032; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=wE0ihBB//Q7YQLdbGK8nv1v+0/qnzhmTo+91mav0M2w=; b=R9eeE1weB8LH4DXXIMkMiSQtgXhYAexIvr2zLXiNIWBMhTLIuX4GN2vR9Wf+B8dz 55Gq6F+/2MZ737DGApnv68CN92eSyLon2XKnRBFSfjtx9s3hFlZ5n4deqBl1ojz4EM4 zQajo2T3H4Duxx5U8ugmMP5EZenGFOkRV+M85OWE= From: Kent Watsen Message-ID: <0100016a5019d7f9-7f737c63-d07c-4c7f-b12e-c5b19d50eeaf-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_631C2BF9-43E4-43E4-B197-5BD005697797" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 24 Apr 2019 16:07:12 +0000 In-Reply-To: Cc: =?utf-8?Q?Bal=C3=A1zs_Lengyel?= , Martin Bjorklund , "ietfc@btconnect.com" , "netconf@ietf.org" To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= References: <20190404164929.fsfga7s4izn7ucx5@anna.jacobs.jacobs-university.de> <20190404.194623.1178346313710501110.mbj@tail-f.com> <01dd01d4eb9c$b9a04160$4001a8c0@gateway.2wire.net> <20190405.142201.707949273328784535.mbj@tail-f.com> <413d5725-9c27-e50b-2622-1b0e2f35cdb1@ericsson.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.24-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 16:07:16 -0000 --Apple-Mail=_631C2BF9-43E4-43E4-B197-5BD005697797 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Regarding #1, per previous discussion, the 'permanently-hidden' text = regarding such keys not being backed up or restored has been replaced = (see below). With regards to permanently hidden keys, I think the = current solution with the 'generate-hidden-key' and 'install-hidden-key' = is nearly ideal, if not so. type enumeration { enum permanently-hidden { description "The private key is inaccessible due to being protected by the system (e.g., a cryptographic hardware module). How such keys may be backed-up and restored, if at all, is application specific. =20 Servers MUST fail any attempt by a client to configure this value directly. This value is not set by clients, but rather is set by the 'generate-hidden-key' action."; } } =20 Regarding #2, I'm unclear how a different name would be any better than = "hidden". =46rom the above description text, the key surely seems = "hidden" (from the YANG-driven management engine) to me... Regarding #3, firstly note that the description text doesn't necessitate = use of a TPM, it is merely suggestive that may a motivating reason. = Second, I'm unsure if "new actions" are needed so much as a "new = approach" or maybe "different actions" (is this what you meant?).=20 To dig into this again, it is common best practice to have a device = generate a private key that is considered configuration, albeit = protected by access-control. The reason for this best practice is that = it supports the private key never having to exist outside the device = (backups and HA-replication withstanding) and, in particular, the client = doesn't touch the key (there are no remnants on the client computer = needing to be scrubbed). =20 In addition to the best-practice angle, there's also a simplicity aspect = in that invoking an action is much easier (and perhaps safer) than the = client using a crypto-library. In fact, the only reason a client might = not want the server generate the private key is because of a lack of = confidence in the server's key-generation implementation (e.g., the = strength of the entropy, though TPM-generated entropy is rather = excellent). =20 To be clear, I also support enabling clients to generate private keys = themselves, as there are times when it is important, but feel that it = should be viewed as a special case rather than common procedure. My recommendation is to modify the "generate/install-hidden-key" = (renamed to just "generate/install-key") actions to have a flag = indicating if the key should be "permanently hidden" (perhaps by using a = TPM) or not, in which case configuration is created, same as if the = client had used , but without needing to touch the key. Yes, having an action generate config is a taboo subject, the general = reasoning for which is understood [1], but it seems that exceptions = should be made in special circumstances, such as this one. [1] = https://mailarchive.ietf.org/arch/msg/netconf/ezf5o9GvCsH_hDPiIX-YQKfnxj8 Kent // contributor > On Apr 24, 2019, at 8:52 AM, Bal=C3=A1zs Kov=C3=A1cs = wrote: >=20 > Hi, > =20 > Is there a conclusion on this thread? > =20 > Alternatives I=E2=80=99ve seen: > =20 > =E2=80=98hidden=E2=80=99 actions already solve the problem.=20 > Backup of keys won=E2=80=99t be supported or special procedure needed. > Descriptions need to be updated to generalize use case (not be = restricted to TPMs). > Current actions solve the problem, but new terminology should be = needed instead of =E2=80=98hidden=E2=80=99 and =E2=80=98permanently = hidden=E2=80=99. > Backup of keys won=E2=80=99t be supported or special procedure needed. > Descriptions to be updated. > New actions needed that affect configuration for non-TPM use cases > Backup of keys can be supported > i. = Q: how does a restore differ from normal configuration which the = generate key action was supposed to circumvent to follow security best = practice? > =20 > I guess the latest mails confirm 1) or 2). Would be good to know the = way forward. > =20 > Br, > Balazs > =20 > From: netconf > On Behalf Of Bal=C3=A1zs Lengyel > Sent: Friday, April 5, 2019 4:54 PM > To: Martin Bjorklund >; = ietfc@btconnect.com > Cc: netconf@ietf.org > Subject: Re: [netconf] ietf crypto types - permanently hidden > =20 > Hello, >=20 > While using actions to configure data nodes instead of edit-config = clearly has problems, in some cases it is needed. Ericsson does use it, = but we try to be VERY(!) restrictive when it is allowed. IMHO security = best practice could be one case. Also we should not pretend this is the = only case where the system itself manipulates configuration: >=20 > security keys > HW insertion/removal (interface type) > onboard automation may do it > server capabilities that need additional configuration (must be in = running as it is reference from other parts of the configuration) > I also hope we will arrive at a solution that works for non-NMDA = systems too. AFAIK we never stated in any RFC that NMDA is a = requirement for the solution. (Except for NMDA itself :-) ) >=20 > regards Balazs >=20 > On 2019. 04. 05. 14:22, Martin Bjorklund wrote: > tom petch wrote: > =20 > ----- Original Message ----- > From: "Martin Bjorklund" > To: = > Cc: > Sent: Thursday, April 04, 2019 6:46 PM > =20 > Juergen Schoenwaelder = wrote: > On Thu, Apr 04, 2019 at 04:23:23PM +0000, Kent Watsen wrote: > =20 > =20 > We have always said no, but the reasoning is unclear. What are > the > specific objections and is there anyway to alleviate them? > =20 > =20 > If editing of all configuration can be done with a single edit-data > (or edit-config) operation, you simplify the world and you enable > generic implementations. > =20 > Once you build silos of data that can only be manipulated with > special > purpose operations, you say goodbye to the idea of generic client > libraries. > =20 > And you can no longer create all required config in one transaction; > you have to split it into sending multiple special-purpose actions. > Perhaps also in a certain order, that you have to figure out somehow, > since config might have refererences to other partf of the config > etc. > =20 > You can no longer restore a backup with just a copy-config. > =20 > Which is exactly what I have seen customers - think military - do. > =20 > Security-related information - userid, passwords, second factor , ...- > MUST NOT be backed up like everything else - special procedures - > authentication, encryption - must be used. > =20 > Agreed! BUT, then it should not be modelled as configuration, imo. > =20 > And the current model already handles this case with "hidden" keys. > =20 > =20 > =20 > =20 > /martin > =20 > =20 > This is security - it matters. > =20 > Tom Petch > =20 > So I don't think the reasoning is unclear at all. > =20 > /martin > =20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = > =20 > =20 > =20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = > =20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com =20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = --Apple-Mail=_631C2BF9-43E4-43E4-B197-5BD005697797 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Regarding #1, per previous discussion, = the 'permanently-hidden' text regarding such keys not being backed = up or restored has been replaced (see below).  With regards to = permanently hidden keys, I think the current solution with the = 'generate-hidden-key' and 'install-hidden-key' is nearly ideal, if not = so.

    =     type enumeration {
  =         enum permanently-hidden {
            description
              "The = private key is inaccessible due to being
    =            protected by the system (e.g., = a cryptographic
            =    hardware module).

  =              How such keys may be = backed-up and restored,
          =      if at all, is application specific.
               
              =  Servers MUST fail any attempt by a client to
  =              configure this value = directly.  This value is
      =          not set by clients, but rather is set = by the
              =  'generate-hidden-key' action.";
      =     }
        }

 
Regarding #2, I'm = unclear how a different name would be any better than "hidden". =  =46rom the above description text, the key surely seems "hidden" = (from the YANG-driven management engine) to me...

Regarding #3, firstly note that the description = text doesn't necessitate use of a TPM, it is merely suggestive that may = a motivating reason.  Second, I'm unsure if "new actions" are = needed so much as a "new approach" or maybe "different actions" (is this = what you meant?). 

To dig into = this again, it is common best practice to have a device generate a = private key that is considered configuration, albeit protected by = access-control.  The reason for this best practice is that it = supports the private key never having to exist outside the device = (backups and HA-replication withstanding) and, in particular, the client = doesn't touch the key (there are no remnants on the client computer = needing to be scrubbed).  

In = addition to the best-practice angle, there's also a simplicity aspect in = that invoking an action is much easier (and perhaps safer) than the = client using a crypto-library.  In fact, the only reason a client = might not want the server generate the private key is because of a lack = of confidence in the server's key-generation implementation (e.g., the = strength of the entropy, though TPM-generated entropy is rather = excellent).   

To be = clear, I also support enabling clients to generate private keys = themselves, as there are times when it is important, but feel that it = should be viewed as a special case rather than common = procedure.

My recommendation is to = modify the "generate/install-hidden-key" (renamed to just = "generate/install-key") actions to have a flag indicating if the key = should be "permanently hidden" (perhaps by using a TPM) or not, in which = case configuration is created, same as if the client had used = <edit-config>, but without needing to touch the key.

Yes, having an action generate config is a taboo = subject, the general reasoning for which is understood [1], but it seems = that exceptions should be made in special circumstances, such as this = one.


Kent // = contributor



On Apr 24, 2019, at 8:52 AM, Bal=C3=A1zs = Kov=C3=A1cs <balazs.kovacs@ericsson.com> wrote:

Hi,
 
Is there a = conclusion on this thread?
 
Alternatives = I=E2=80=99ve seen:
 
  1. =E2=80=98hidde= n=E2=80=99 actions already solve the problem. 
    1. Backup of keys won=E2=80=99t be = supported or special procedure needed.
    2. Descriptions = need to be updated to generalize use case (not be restricted to = TPMs).
  2. Current actions solve the = problem, but new terminology should be needed instead of =E2=80=98hidden=E2= =80=99 and =E2=80=98permanently hidden=E2=80=99.
    1. Backup of keys won=E2=80=99t be = supported or special procedure needed.
    2. Descriptions = to be updated.
  3. New actions = needed that affect configuration for non-TPM use cases
    1. Backup of keys can be = supported
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;   i.      Q: how does a restore differ = from normal configuration which the generate key action was supposed to = circumvent to follow security best practice?
 
I guess the = latest mails confirm 1) or 2). Would be good to know the way = forward.
 
Br,
Balazs
 
From: netconf <netconf-bounces@ietf.org> On Behalf = Of Bal=C3=A1zs = Lengyel
Sent: Friday, April 5, 2019 4:54 = PM
To: Martin Bjorklund <mbj@tail-f.com>; ietfc@btconnect.com
Cc: netconf@ietf.org
Subject: Re: [netconf] ietf crypto = types - permanently hidden
 

Hello,

While using actions to configure data = nodes instead of edit-config clearly has problems, in some cases it is = needed. Ericsson does use it, but we try to be VERY(!) restrictive when = it is allowed. IMHO  security best practice could be one case. Also = we should not pretend this is the only case where the system itself = manipulates configuration:

  • security keys
  • HW insertion/removal (interface = type)
  • onboard automation may do it
  • server capabilities that need = additional configuration (must be in running as it is reference from = other parts of the configuration)

I also hope we will arrive at a solution that works for = non-NMDA systems too. AFAIK  we never stated in any RFC that NMDA = is a requirement for the solution. (Except for NMDA itself :-)  = )

regards Balazs

On 2019. 04. 05. 14:22, Martin Bjorklund wrote:
tom =
petch <ietfc@btconnect.com> =
wrote:
 
----- =
Original Message -----
From: "Martin Bjorklund" <mbj@tail-f.com>
To: =
<j.schoenwaelder@jacobs-university.de>
Cc: =
<netconf@ietf.org>
Sent: =
Thursday, April 04, 2019 6:46 PM
 
Juergen=
 Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On =
Thu, Apr 04, 2019 at 04:23:23PM +0000, Kent Watsen wrote:
 
 
We =
have always said no, but the reasoning is unclear.  What are
the
specific objections and is there anyway to alleviate =
them?
 
 
If editing of all configuration can be done with a single =
edit-data
(or edit-config) operation, you simplify the world and you =
enable
generic implementations.
 
Once =
you build silos of data that can only be manipulated with
special
purpose operations, you say goodbye =
to the idea of generic client
libraries.
 
And you can no longer create all required config in one =
transaction;
you have to split it into sending multiple special-purpose =
actions.
Perhaps also in a certain order, that you have to figure out =
somehow,
since config might have refererences to other partf of the =
config
etc.
 
You can no longer restore a backup with just a =
copy-config.
 
Which is exactly what I have seen =
customers - think military - do.
 
Security-related information - userid, passwords, second =
factor , ...-
MUST NOT be backed up like everything else - special =
procedures -
authentication, encryption -  must be used.
 
Agreed!  BUT, then it should not be modelled as =
configuration, imo.
 
And the current model already handles this case with "hidden" =
keys.
 
 
 
 
/martin
 
 
This =
is security - it matters.
 
Tom Petch
 
So I =
don't think the reasoning is unclear at all.
 
/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
 
-- 
Balazs =
Lengyel           &=
nbsp;           =
Ericsson Hungary Ltd.
Senior Specialist
Mobile: =
+36-70-330-7909          =
;    email: Balazs.Lengyel@ericsson.com
_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

= --Apple-Mail=_631C2BF9-43E4-43E4-B197-5BD005697797-- From nobody Wed Apr 24 10:44:50 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792FA1200F6; Wed, 24 Apr 2019 10:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSaianuPf5FD; Wed, 24 Apr 2019 10:44:31 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 6759712009E; Wed, 24 Apr 2019 10:44:28 -0700 (PDT) Received: from LAPTOPR7T053C2 ([73.189.160.186]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MThzC-1hAaU618YC-00QQcI; Wed, 24 Apr 2019 19:44:26 +0200 From: "Alexander Clemm" To: "'Wesley Eddy'" , Cc: , , References: <155421856789.6325.9786625701476465519@ietfa.amsl.com> In-Reply-To: <155421856789.6325.9786625701476465519@ietfa.amsl.com> Date: Wed, 24 Apr 2019 10:44:24 -0700 Message-ID: <105601d4fac5$5cb31ad0$16195070$@clemm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQImeKsXAsmkEFCYMkbOhl/9oS8J9KWomQZA Content-Language: en-us X-Provags-ID: V03:K1:V3++lmidUmnHkqGdmO5gsEifeDcrESRdY4conS0jeRpQywxLS0m oMjUNtI7QrXK42czkIa02xKVvCU/YWy+QJPS2iwxuAqQp3/4t61z5kJynPhDc6+0Y0H2se0 i5Jf2xqk/pHAA03Y1JjhL70hixLNq77JhNGiV9nl3iGR2ODPKd0WM1Xv3nUinRBdQP5vXjG 6dUk7EhqsVMMRxJIloSRw== X-UI-Out-Filterresults: notjunk:1;V03:K0:hc4I2FLYGY4=:WGAKddhanHs39Btx4zs/Ih N+oFg2s9HvdLiuuP07Z5ISFmQclu/rMB3aISrL2g3ydmY3KMFBpjGPgjBbcBce7Z+mhXve7yi qd5NYrMSoQ6e1KUeVhJTIorHVSik9WYYM8I/yg3kYf2md/iQff+/jEH/VtvHwI+gnqFBazT+n 2Kotg9zWMYiCPWYUUIcRs/8+flogBhOJt/E3iNTTnWFso967ytXyjfunopAKwgZd/U9eIID9J kkInGTOFhRtXfQabz5orv78VPCwCz9jNLRcKMxp4UPM+ie2whvzI+yPsckDgn4eCfFPX7uQCh aL+smTIQQdg/qxeSkcQIERzeFQkEzeWYF/vHq2D2umcKCR4iHSYwRHfIdnyfWgNUjqZ/0Npwp EWmlmU/HWKEeTrSccMMcl1X1B+r0MHAs0AQFh4oF0tPnTRRZwgIYaRoShOozSI9iqGVNvSGhP DqGW2gzddJQQwZ1pqajNfjIHm4dYtB8QINweViPADPRA+FGYZASKL9mUlsHckCYr85yNi+s+Q swVwxWnuaJM7fKYNugp+d0QzZh7jpRQiXI/co18hGKW7n9OjTMgffrZbaMa936A4uJ8qq0IGV NcwWzD5jZDdHiAXkUmEcG5E3oUhcVMROzF4md28FKWnB0km5/iWWa2IeJ3/IHJU2A0wt+QHGo +9OhQpi4KjNmAzxWwK7VeX+iPTPFrWJqjoJKzkDzfsZde42P5u75XMhvuPIce6K1AcgiwibTU 45ovJeeXEsR6lToO5B7I5GVKDNFTFDHMYShRb5dOc7NNlPB6Od2XeTvYI+E= Archived-At: Subject: Re: [netconf] Tsvart last call review of draft-ietf-netconf-yang-push-22 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 17:44:34 -0000 Hi Wesley, thank you for your review! --- Alex -----Original Message----- From: netconf On Behalf Of Wesley Eddy via Datatracker Sent: Tuesday, April 2, 2019 8:23 AM To: tsv-art@ietf.org Cc: draft-ietf-netconf-yang-push.all@ietf.org; ietf@ietf.org; netconf@ietf.org Subject: [netconf] Tsvart last call review of draft-ietf-netconf-yang-push-22 Reviewer: Wesley Eddy Review result: Ready This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. I reviewed this in conjunction with the set of related WG documents on NETCONF/RESTCONF subscriptions and event notifications. On this specific document, I didn't find any issues, though I do have comments that will be send on other documents in the set, some of which may influence this once, since they are closely related. _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Apr 24 10:53:17 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8827812011E; Wed, 24 Apr 2019 10:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=YnACJX2K; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=IRXjP3qA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjxrtYd0TVWY; Wed, 24 Apr 2019 10:53:07 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0140012009E; Wed, 24 Apr 2019 10:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2612; q=dns/txt; s=iport; t=1556128387; x=1557337987; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=O0B7WxEbHvykayqkvyDTuWX6mepZyDtXp6vXGsyozxw=; b=YnACJX2K4MDt+Fh4LDH8ShHaNZzcVQ/2srvJ2364lvpkzk/K7wP4aIQq v7GIv4k4A2NDDzA7DU5IXDHHnAWEjLDpuKPpfQMSgSmxDsNfMdYvd0aFE 38ZszcqsAKglGToeHhnixctiT9bi+HEq24V2SM1/5LKFcmt1gz2p/M0Mn Y=; IronPort-PHdr: =?us-ascii?q?9a23=3AZY9dOxM1P33JKBPtGPkl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjhNvfqaiU8NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAAD6ocBc/4sNJK1mDg0BAQEBAwE?= =?us-ascii?q?BAQcDAQEBgVEGAQEBCwGBPVADgT0gBAsohA+DRwOEUoo5gjIllx2BLoF7DgE?= =?us-ascii?q?BLYRAAheGGCM0CQ4BAwEBBAEBAgECbRwMhUsBBSMRDAEBNwEPAgEIGAICCR0?= =?us-ascii?q?CAgIwFRACBA4FgyKBagMcAZ4kAooUcYEvgnkBAQWFAxiCDQmBCycBi0kXgUA?= =?us-ascii?q?/gREnDBOCTD6ERBeCczGCJo0FLJhFZAkCggiOZINGG4ILhimMYKA/AgQCBAU?= =?us-ascii?q?CDgEBBYFPOIFWcBU7KgGCQYIPg2+KGDtygSmPSQEB?= X-IronPort-AV: E=Sophos;i="5.60,390,1549929600"; d="scan'208";a="554394742" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Apr 2019 17:53:06 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x3OHr5gO012972 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Apr 2019 17:53:06 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 24 Apr 2019 12:53:05 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 24 Apr 2019 13:53:03 -0400 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 24 Apr 2019 12:53:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O0B7WxEbHvykayqkvyDTuWX6mepZyDtXp6vXGsyozxw=; b=IRXjP3qAKbqznXuIJzRCVUsu9FYWYWzTfc5bRWD+F0yx2ENXBae5ESaPzUXi8Z7yVpyW/bAXnJGFhurVdxD3yYMyEgK7+I077IBh8w2Nw8pLKmZfnQ5FBi/5zBRSuBneCeQJ3cgih2TysyQtgPi3zDdp8IoOp0pwH9zr7gVeyp8= Received: from DM5PR1101MB2105.namprd11.prod.outlook.com (10.174.104.15) by DM5PR1101MB2186.namprd11.prod.outlook.com (10.174.104.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.18; Wed, 24 Apr 2019 17:53:02 +0000 Received: from DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::a113:a1ba:aae0:4a12]) by DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::a113:a1ba:aae0:4a12%6]) with mapi id 15.20.1813.017; Wed, 24 Apr 2019 17:53:02 +0000 From: "Reshad Rahman (rrahman)" To: Benjamin Kaduk CC: Aanchal Malhotra , "secdir@ietf.org" , "ietf@ietf.org" , "draft-ietf-netconf-restconf-notif.all@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] Secdir last call review of draft-ietf-netconf-restconf-notif-13 Thread-Index: AQHU8LEm3/ufrU/2dEa8pjPJiNurYqY4yTOAgAuvaICABvAQgA== Date: Wed, 24 Apr 2019 17:53:02 +0000 Message-ID: <7820A8E4-692B-43D2-9611-437CC440EBC7@cisco.com> References: <155501965074.14152.2835369201856309773@ietfa.amsl.com> <20190420035612.GR51586@kduck.mit.edu> In-Reply-To: <20190420035612.GR51586@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.6.190114 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [2001:420:2840:1250:2421:2f0a:1dbc:638e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c19eca6c-c162-4c8d-2642-08d6c8ddb22d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM5PR1101MB2186; x-ms-traffictypediagnostic: DM5PR1101MB2186: x-microsoft-antispam-prvs: x-forefront-prvs: 00179089FD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(396003)(366004)(136003)(51914003)(199004)(189003)(66476007)(66446008)(66556008)(91956017)(76176011)(64756008)(66946007)(58126008)(54906003)(73956011)(316002)(486006)(6116002)(8936002)(5660300002)(256004)(8676002)(14444005)(305945005)(7736002)(76116006)(86362001)(82746002)(81156014)(36756003)(81166006)(2906002)(33656002)(6512007)(2616005)(229853002)(4326008)(11346002)(6246003)(68736007)(6436002)(25786009)(6486002)(186003)(476003)(53936002)(71190400001)(71200400001)(6916009)(99286004)(53546011)(6506007)(102836004)(14454004)(83716004)(2171002)(478600001)(46003)(446003)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1101MB2186; H:DM5PR1101MB2105.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: eIexsg5QpVAU8xE/QSPJZsnr5qdaVioqdt1TxP7rQM6+ZbM7xq1x1XZDnSqkNEyvhhu9oFloeLVwvdL/wKKi9Atzxl20wVegRJuBp51b/t/JyUKJ4WuIXBSoxzGOOQUdC+7TGSPpf6CI2s2mZfotfOZuK9Y6qZtZO8dlPd0JjGs9715OpsKKQ8qy7I00otRM1o0hHObjPz48KBRlQgFTR4w7dJyGLRWRuCKE8uXwoWTjFWAqO2MNxrADptJAVkMb5ydfbbBFnEQVvSbUrwpCV/FFNSZ+nIA5nEb+WMfUjWaKonm4Ty/vDUvk/ZNeG2kAA6rCJxqHjFRSfVWZIJsxbeviKA3rgo4UV5xHIsBx5oCzsjVBRg+xEVRsoCYmZ6XRcax8eN7uKSpqYS5G4mXnVFlZYOsII4xB82sTmj8GKlI= Content-Type: text/plain; charset="utf-8" Content-ID: <12916BD1BF47974E99B6D32B44043839@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c19eca6c-c162-4c8d-2642-08d6c8ddb22d X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2019 17:53:02.0743 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2186 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [netconf] Secdir last call review of draft-ietf-netconf-restconf-notif-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 17:53:10 -0000 T24gMjAxOS0wNC0xOSwgMTE6NTYgUE0sICJCZW5qYW1pbiBLYWR1ayIgPGthZHVrQG1pdC5lZHU+ IHdyb3RlOg0KDQogICAgT24gRnJpLCBBcHIgMTIsIDIwMTkgYXQgMDk6Mjk6MzVQTSArMDAwMCwg UmVzaGFkIFJhaG1hbiAocnJhaG1hbikgd3JvdGU6DQogICAgPiBIaSBBYW5jaGFsLA0KICAgID4g DQogICAgPiBUaGFua3MgZm9yIHRoZSByZXZpZXcuIFBsZWFzZSBzZWUgaW5saW5lLg0KICAgID4g DQogICAgPiBPbiAyMDE5LTA0LTExLCA1OjU0IFBNLCAibmV0Y29uZiBvbiBiZWhhbGYgb2YgQWFu Y2hhbCBNYWxob3RyYSB2aWEgRGF0YXRyYWNrZXIiIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcg b24gYmVoYWxmIG9mIG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KICAgID4gDQogICAgPiAgICAg UmV2aWV3ZXI6IEFhbmNoYWwgTWFsaG90cmENCiAgICA+ICAgICBSZXZpZXcgcmVzdWx0OiBSZWFk eQ0KICAgID4gICAgIA0KICAgID4gICAgIFRoZSBkb2N1bWVudCBpcyB2ZXJ5IGNsZWFyIGFuZCBj b25jaXNlLiAgSSBqdXN0IGhhdmUgb25lIG1pbm9yIGNsYXJpZmljYXRpb24gcXVlc3Rpb24uDQog ICAgPiAgICAgU2VjdGlvbiAzLjQgUGFnZSA5IHRoYXQgc2F5cyB0aGUgZm9sbG93aW5nOg0KICAg ID4gICAgICJJbiBhZGRpdGlvbiB0byBhbnkgcmVxdWlyZWQgLi4uLi4uLi5TSE9VTEQgb25seSBi ZSBhbGxvd2VkLi4uLi4uIi4gIA0KICAgID4gICAgIA0KICAgID4gICAgIElzIHRoZXJlIGEgcmVh c29uIGZvciB1c2luZyBTSE9VTEQgaW5zdGVhZCBvZiBNVVNUPyANCiAgICA+IA0KICAgID4gVGhl cmUgbWF5IGJlIHJlYXNvbnMgd2h5IGFuIGltcGxlbWVudGF0aW9uIGRlY2lkZXMgbm90IHRvIGVu Zm9yY2UgdGhpcyByZXN0cmljdGlvbi4gR29pbmcgYnkgUkZDMjExOSBkZWZpbml0aW9ucywgdGhp cyBpcyB3aHkgd2UgY2hvc2UgU0hPVUxEIGluc3RlYWQgb2YgTVVTVC4NCiAgICANCiAgICBJZiB5 b3UgaGF2ZSBzb21lIHJlYXNvbnMgaW4gbWluZCwgaXQgaXMgb2Z0ZW4gaGVscGZ1bCB0byBsaXN0 IHRoZW0gYXMNCiAgICBleGFtcGxlcyBvZiB3aGVuIHRoZSByZWNvbW1lbmRlZCBiZWhhdmlvciB3 b3VsZCBub3QgYmUgZm9sbG93ZWQuDQoNCldoYXQgd2UgaGFkIGluIG1pbmQgaXMgYSAic3VwZXIt dXNlciIgd2hvIGNvdWxkIGJlIGdpdmVuIGFjY2VzcyB0byBzdWJzY3JpcHRpb25zIG9mIG90aGVy IHVzZXJzLiBJcyB0aGlzIG9idmlvdXMgb3Igc2hvdWxkIEkgY2FuIGFkZCB0ZXh0IHRvIHRoYXQg ZWZmZWN0IGF0IHRoZSBlbmQgdGhlIGJ1bGxldCBiZWxvdz8gU29tZXRoaW5nIGFsb25nIHRoZSBs aW5lcyBvZiAiRm9yIGV4YW1wbGUsIGEgUkVTVENPTkYgdXNlcm5hbWUgd2l0aCB0aGUgcmVxdWly ZWQgYWRtaW5pc3RyYXRpdmUgcGVybWlzc2lvbnMgY291bGQgYmUgYWxsb3dlZCB0byBpbnZva2Ug UlBDcyBtb2RpZnktc3Vic2NyaXB0aW9uLCByZXN5bmMtc3Vic2NyaXB0aW9uIGFuZCBkZWxldGUt c3Vic2NyaXB0aW9uIG9uIGEgc3Vic2NyaXB0aW9uIHdoaWNoIHdhcyBjcmVhdGVkIGJ5IGFub3Ro ZXIgdXNlcm5hbWUuIi4NCg0KICAgbyAgSW4gYWRkaXRpb24gdG8gYW55IHJlcXVpcmVkIGFjY2Vz cyBwZXJtaXNzaW9ucyAoZS5nLiwgTkFDTSksIFJQQ3MNCiAgICAgIG1vZGlmeS1zdWJzY3JpcHRp b24sIHJlc3luYy1zdWJzY3JpcHRpb24gYW5kIGRlbGV0ZS1zdWJzY3JpcHRpb24NCiAgICAgIFNI T1VMRCBvbmx5IGJlIGFsbG93ZWQgYnkgdGhlIHNhbWUgUkVTVENPTkYgdXNlcm5hbWUgW1JGQzgw NDBdDQogICAgICB3aGljaCBpbnZva2VkIGVzdGFibGlzaC1zdWJzY3JpcHRpb24uDQoNClJlZ2Fy ZHMsDQpSZXNoYWQuDQogICAgDQogICAgVGhhbmsgeW91IEFhbmNoYWwgZm9yIHRoZSByZXZpZXch DQogICAgDQogICAgLUJlbg0KICAgIA0KDQo= From nobody Wed Apr 24 11:05:20 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977C71201A1 for ; Wed, 24 Apr 2019 11:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxBq5xIFh3W4 for ; Wed, 24 Apr 2019 11:05:17 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4195120226 for ; Wed, 24 Apr 2019 11:05:16 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 6F8B235E; Wed, 24 Apr 2019 20:05:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id U4QAOmwc0fvE; Wed, 24 Apr 2019 20:05: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 atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 24 Apr 2019 20:05:15 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4E233200D5; Wed, 24 Apr 2019 20:05:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id BMtKvMsqc2Vc; Wed, 24 Apr 2019 20:05:15 +0200 (CEST) Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id DC443200D3; Wed, 24 Apr 2019 20:05:14 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Wed, 24 Apr 2019 20:05:14 +0200 Received: by anna.localdomain (Postfix, from userid 501) id EF4F2300874529; Wed, 24 Apr 2019 20:05:13 +0200 (CEST) Date: Wed, 24 Apr 2019 20:05:13 +0200 From: Juergen Schoenwaelder To: Kent Watsen CC: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= , "netconf@ietf.org" Message-ID: <20190424180513.gtxmreicd7iydrpr@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= , "netconf@ietf.org" References: <20190404164929.fsfga7s4izn7ucx5@anna.jacobs.jacobs-university.de> <20190404.194623.1178346313710501110.mbj@tail-f.com> <01dd01d4eb9c$b9a04160$4001a8c0@gateway.2wire.net> <20190405.142201.707949273328784535.mbj@tail-f.com> <413d5725-9c27-e50b-2622-1b0e2f35cdb1@ericsson.com> <0100016a5019d7f9-7f737c63-d07c-4c7f-b12e-c5b19d50eeaf-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <0100016a5019d7f9-7f737c63-d07c-4c7f-b12e-c5b19d50eeaf-000000@email.amazonses.com> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 18:05:20 -0000 On Wed, Apr 24, 2019 at 04:07:12PM +0000, Kent Watsen wrote: > > type enumeration { > enum permanently-hidden { > description > "The private key is inaccessible due to being > protected by the system (e.g., a cryptographic > hardware module). > > How such keys may be backed-up and restored, > if at all, is application specific. Perhaps this should say 'implementation specific' instead 'application specific'. > My recommendation is to modify the "generate/install-hidden-key" (renamed to just "generate/install-key") actions to have a flag indicating if the key should be "permanently hidden" (perhaps by using a TPM) or not, in which case configuration is created, same as if the client had used , but without needing to touch the key. I agree that having a flag to control the behavior is useful and I think there should be explicit text how the action fails in case the requested action cannot be performed. I am not sure I understand install-hidden-key. The description says: "Requests the device to load the specified values into a hidden key. The resulting asymmetric key values are considered operational state and hence present only in ."; So what is the persistence model of this? Does a key installed with install-hidden-key survive reboots? If so, can I delete somehow such a hidden key? (Is the answer that this key is tied to the lifetime of the list element indirectly using this grouping?) Does invoking install-hidden-key twice cause the first installed key to be overwritten? Can the install-hidden-key action fail in any way? This leads to related questions for generate-hidden-key: Does invoking this action twice cause an existing key to be overwritten? Can I explicitely delete a generated hidden key? Does deleting the list item that directly or indirectly uses this grouping delete a hidden key? /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 Apr 24 11:48:42 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D561201F8; Wed, 24 Apr 2019 11:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQycMOg4grZ0; Wed, 24 Apr 2019 11:48:38 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 1652F120100; Wed, 24 Apr 2019 11:48:37 -0700 (PDT) Received: from LAPTOPR7T053C2 ([73.189.160.186]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MNs0D-1hQnbX2FSd-007XFH; Wed, 24 Apr 2019 20:48:32 +0200 From: "Alexander Clemm" To: "'Takeshi Takahashi'" , Cc: , References: <155488041402.1083.9565126428194093115@ietfa.amsl.com> In-Reply-To: <155488041402.1083.9565126428194093115@ietfa.amsl.com> Date: Wed, 24 Apr 2019 11:48:30 -0700 Message-ID: <10a501d4face$513d3600$f3b7a200$@clemm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGkXl6tnNmJZ5U6rvHBJnkUSxkaRKaszf2w Content-Language: en-us X-Provags-ID: V03:K1:nuJdqaepsb4NRn/yC+/vgYtPBnm2jf3YLRt+25/hlOJ1v54mq9e 5y3vAH9ZOPPP8jN9rPg2WrApUvytWaxajyX7Fw5moRjjKd9G5mSZpPtpNLp36IAc86iOvYK YlBX7s9lOsGkFH259Wgqd5Hq37NTy91fRrGrPspX6LshWG+0fIIGRREQjptZ8n3Q2K/jA4+ iNWNp9kl/1c1fbySmK/wQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:eVc5fBhcLhM=:TQC8pC0+otFfJYgJ9ffzUD NbKtjF6cf6tckragEXGJZWlnve/JbbVpJwHuIVkx9Op4BYGbKXa8WEW7brgAZMtnUPZ7tCDKJ H01ETGIr+DpCXP7GVLbaAfCrir3ZR8z/1rlKIN7m5gWbfX5UpFvaYUNBujQaE+xDpOJc2u+AH 3RLre7TxbGAXw8PnVLyXzUwHm+/p4BUBcmA9z9REAQ2Do+xRAO9I3keqZmKu/trnYHkgbdtTQ v0kTAlvqE65pb03Ra3OTHGdp167ZH7dck/j1sQYvPpMnyJae6xLU4yy8JH4TGZ45sSwXOi/ED KfXnSDiRYhEyWTn2CZizE1eUuzCGrnaZuvDaUDYE55t+3684dZ3WHd2UHLhvQv9bpPZ7L6FIu Z4ZDsOd5+oJ/xmBGYxQIU7oRe1DDEn8W5Fwc9Uz5WqRKTR1eOo1ZK0gKStPDuDHYvGYfpakPC bmOmCd/llq+NhxEccrN2EVamzHSPwoRbjzPi0rYa7CPo8zzCGDic+OPI7qB/+4O/wIUj8UDMc h0RMxghrIEwWaobki0eRITrjrfPdh3JJLL00Fi49V4M+aRbDpwpwS0f1MHJ4h+yUFjhnT5vB3 OtkqBiyklABiGadYaCPFqu3bsWK0cXzXacitHTYODRU5WxFrSwTH1Eoz1P47hF53s9dvmkr6z 2emBASd2GiAhaFPfp9VwZKBVj3QoudGUO0LFBXm4SFNMvX0fTUah0Vawgg66umkaOl1X+NIWB 7NK/+CWCzgKsYC08rG4RotzrflKVMmlYHKktoCV5f/Wta8jlVgXALgnh3T8= Archived-At: Subject: Re: [netconf] Secdir last call review of draft-ietf-netconf-yang-push-22 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 18:48:41 -0000 Hi Takeshi, Thank you for your review! Please see replies inline, --- Alex -----Original Message----- From: netconf On Behalf Of Takeshi Takahashi via Datatracker Sent: Wednesday, April 10, 2019 12:14 AM To: secdir@ietf.org Cc: draft-ietf-netconf-yang-push.all@ietf.org; netconf@ietf.org Subject: [netconf] Secdir last call review of draft-ietf-netconf-yang-push-22 Reviewer: Takeshi Takahashi Review result: Has Nits This draft talks about push-type update notifications of YANG datastore. It provides two types of subscriptions: periodic and on-change. I have one comments (item 4) and four clarification questions (items 1-3) below. 1. on the on-change subscription (in sections 3.3 and 3.10) The draft says "it will be important for client applications to have a way to identify for which objects on-change notifications are supported and for which ones they are not supported," but this issue is currently left to the implementation. It would be nice if you could provide some example solutions to this problem so that the implementers of this draft will not be confused. When a publisher accept on-change subscription even when the scope of the subscription contains objects for which on-change is not supported, I wonder sending some notification message on the situation could be helpful for the subscriber. By reading other part of the draft, I feel that the draft is indeed recommending to implement such comprehensive notifications. If so, it had better be clearly mentioned in this section. I also think it is not a bad idea to define such a comprehensive notification in this draft, though it is up to the authors. Because the solution to the topic of knowing for which objects on-change notifications are supported is indeed complex, this is actually being deferred to a different draft, draft-ietf-netconf-notification-capabilities, which allows a subscriber to precisely discover where this is supported and where not. As to what to do when a subscription's scope contains objects not capable of on-change notifications, section 3.3 states "Whether or not to accept or reject on-change subscription requests when the scope of the subscription contains objects for which on-change is not supported is up to the publisher implementation." There are no separate notifications that will be sent; instead this is handled through replies to the request. Notifications are only sent when the state of the subscription changes, which would include scenarios in which the server decides it can no longer support the subscription (due to dynamic changes, or whatever) after all. 2. on the differing dampening periods for multiple objects(in section 3) The draft says "In case whether a subscriber wants to have separate dampening periods for different objects, the subscriber has the option to create multiple subscriptions with different selection filters." That is a good solution. Then are the any other options for allowing to have separate dampening periods for different objects? The sentence gave me the impression that there are multiple options; so I am asking this question only for clarification. No, this is the only option. Within a subscription only one dampening period applies. Anything else would make configuration and figuring out what is going on super complex. Hence the solution of applying separate subscription if an application indeed requires different settings for different subscribed objects. 3. imcomplete-update flag (in sections 3.11.1 and 4.3.2) I am not sure what would be the expected actions of the subscribers when they receive a message with incomplete-update flag on. Some navigations would be appreciated. Meanwhile, according to section 4.3.2, a publisher MAY subsequently send a push-update containing a full selection snapshot of subscribed data. If such a push-update is subsequently sent, does the publisher need to send anoter message with incomplete-update flag on prior to the push-update with a full selection snapshot of subscribed data? When a message with an incomplete-update flag is received, what it will do is really up to the receiver. Really, the flag is there only for exceptions to let the receiver know if due to some unforeseen and unavoidable circumstance the server is not able to fulfill its obligation per the terms of the subscription. The actual exception handling that a receiver application would apply when receiving a push-update with an incomplete flag depends on the application. A receiver could choose to resynch (retrieving all subscribed information). It could choose to wait (some applications may be okay with the loss of some information, but at least they know). It could choose to tear down the subscription and start a new one, perhaps with a lesser scope. We will add this sentence to make this clear; will this address your concerns? I am not clear on the second part of your question regarding sending another message with incomplete flag. The goal of the push-update with a full selection snapshot of subscribed data is to make sure that the receiver is again in sync with the subscribed data; only if for some reason that would fail (and be incomplete again) an incomplete flag would be set. Obviously, if there are continuous problems (i.e. incomplete-update occurs all the time, no resync possible), this constitutes an error condition; the publisher may suspend the subscription in this case (as stated) and the subscribing application may decide that the subscription of the publisher are useless. 4. security considerations (in section 7) This section enumerates four threats that are newly introduced by this draft. Some countermeasures, or directions to address these threats, had better be provided here. Not exactly sure what to put here. We do mention that NACM should be used to restrict access. Since most of the attacks involve modifying the terms of the subscription, we can add a sentence to the effect of: "A subscriber could monitor the subscription configuration itself for any unexpected changes. For this, they should monitor notifications regarding updates to their subscriptions to validate that these updates were indeed intended. They could even subscribe to updates to the YANG datastore nodes that represent their datastore subscriptions." Will this address your concern? _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Apr 24 12:07:52 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30F7120229; Wed, 24 Apr 2019 12:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qT33DKyZoVs; Wed, 24 Apr 2019 12:07:36 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 2636E12031B; Wed, 24 Apr 2019 12:07:36 -0700 (PDT) Received: from LAPTOPR7T053C2 ([73.189.160.186]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MN33W-1hPxsc1F7o-006hut; Wed, 24 Apr 2019 21:07:34 +0200 From: "Alexander Clemm" To: "'Stewart Bryant'" , Cc: , , References: <155492884208.22557.5359832641233656648@ietfa.amsl.com> In-Reply-To: <155492884208.22557.5359832641233656648@ietfa.amsl.com> Date: Wed, 24 Apr 2019 12:07:33 -0700 Message-ID: <10b201d4fad0$f9c70ba0$ed5522e0$@clemm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHrc+2ifezD3Octa5HoVdP9sewhBKYetUPg Content-Language: en-us X-Provags-ID: V03:K1:8hFbDztrTFEsdngsv3W4flfJE9efXPx+diorVWGAcGc46Ivi7PU GlB8zCUYGrSGmMnDVS0ZS2KyKFcww5oCAblq1p8genhVd02u5ZQoZrfFvljhQX4VvJorjWo iPMnhRO4XOefNPj5s70EnDR4358uED158Y5n9WLMMO90LLPTYo+/uH4VvaNI2XTy+0EyQQB 6L6vtf3jpB+zsSJa5+tqQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:fDTKLxFDV4g=:FMWpHn0zp0UPUf6p8EEi89 NulZGFFb4A4xXvzcPaCExWh+R0ihQWMLd40VogeKefG9RJcs9BWks2on2484owDzx2ZDh8qUC XSVwfW4e3Qx5cWxUPPaaNFlPE6aM4OZinbxmhOcmqoCESvU9GS+xrgs/ZflEwoOsTxRVgOD5t gzF6UxRhxLmKQe3yn02smoGd5J0xl7iOjF2rq8W2TZfdxcAPm6pCGHmZXtwb8tWjoVB9KGizX Ajl1AoIWfKNDOmhYNrjY/kRvNSeguwP2hgef3nzxU1VM0LktvwEb28Iv5uapeWg4eXI04Igct rtOnK7Lkq+O6oESLUgUuVhKOB99up99S/caBHW/+5wWNHYrDfL4ziTOzyPvlGFUekGLSNuiZe lDTSFraqs/Ttyx3U4qoNI44ROfYeq+GpQHwupjVfbjapvYNCMbVy+JXLyx9YSxFKNaep4WNe7 lJpqFV28rAi5SzOFDNWv7dyz1yikB4as9xb+k2NAfNnSrEbGnc+2kIWArZx57Ds2GlFQWQThb H++OQ1DwlBQWoFC67F9UFG4odwbjuW7rYUUbWhDw0IYC2iFQuRWhGLjI56Kiyu1fzyTRcGLBz RlrzQZxY5C0r17JfuIjxwEzfoCv7jDzwUk67tA9KxizEj8cb0fGWTjm87ynFwpPvD6Rbn57tf Yqyqkk2V2fJoozLFycmCZvWSg4Y8ntCq+nTSeXWeoj/gTySIXD+iOEC44tbPiaGw+cpc5Ve3K IP9sQw2Cgr4A2raydRWMNzFX0zqVTQwtlSX9XvJlO1rPcRnB3who4pg9nt8= Archived-At: Subject: Re: [netconf] Genart last call review of draft-ietf-netconf-yang-push-22 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 19:07:39 -0000 Hi Stewart, Thank you for your comments! Please find replies inline, --- Alex -----Original Message----- From: netconf On Behalf Of Stewart Bryant via Datatracker Sent: Wednesday, April 10, 2019 1:41 PM To: gen-art@ietf.org Cc: draft-ietf-netconf-yang-push.all@ietf.org; ietf@ietf.org; netconf@ietf.org Subject: [netconf] Genart last call review of draft-ietf-netconf-yang-push-22 Reviewer: Stewart Bryant Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-netconf-yang-push-22 Reviewer: Stewart Bryant Review Date: 2019-04-10 IETF LC End Date: 2019-04-12 IESG Telechat date: Not scheduled for a telechat Summary: A well written document with just a small nuber of minor matter in the nits section that need to be considered. Major issues: None Minor issues: None Nits/editorial comments: ** Obsolete normative reference: RFC 7895 (Obsoleted by RFC 8525) ============ We will update the reference. SB> I assume that the ADs are happy with seven front page authors. =========== Abstract Via the mechanism described in this document, subscriber applications SB> I am not sure if starting a sentence with "via" is good English but SB> I have not seen it done before. we think "via" is fine; if you prefer it to say "using", please let us know and we will change it. =========== Traditional approaches to providing visibility into managed entities from remote have been built on polling. SB> from remote what? from a remote system, a remote application, a remote location. I do think this is clear; if you prefer it to say "from a remote system" we will change; please let us know if you would prefer to make that change. =========== 3.10. On-Change Notifiable Datastore Nodes In some cases, a publisher supporting on-change notifications may not be able to push on-change updates for some object types. Reasons for this might be that the value of the datastore node changes frequently (e.g., [RFC8343]'s in-octets counter), that small object changes are frequent and meaningless (e.g., a temperature gauge changing 0.1 degrees), or that the implementation is not capable of on-change notification for a particular object. SB> I could not see the parameter range specifiy what is regarded as SB> trivial specified in the model. It seems that it perhaps ought to be. =================== This will depend heavily on the object and its intended use. Basically we are giving only reasons why an implementation might choose to not support on-change notifications for a particular object. Going deeper into reasoning behind such implementation choices, what size would be "small" or "large", and over what time interval, etc, would IMHO go beyond the scope of this document. We prefer not to make a change to the document. (Please note that there is another draft on smart filters for push updates, which might in the future add the ability for users to e.g. configure this and other things.) The next figure depicts augmentations of module ietf-yang-push to the notifications that are specified in module ietf-subscribed- notifications. The augmentations allow to include subscription SB> s/allow to include/allow the inclusion of/ =============== We will make this change. _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Apr 24 12:08:23 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B44120416; Wed, 24 Apr 2019 12:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwNUPJ7ohNc5; Wed, 24 Apr 2019 12:08:00 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 A02B61203F4; Wed, 24 Apr 2019 12:08:00 -0700 (PDT) Received: from LAPTOPR7T053C2 ([73.189.160.186]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0Lgnku-1gypom2NYk-00oEKm; Wed, 24 Apr 2019 21:07:58 +0200 From: "Alexander Clemm" To: "'Dan Romascanu'" , Cc: , , References: <155505204479.14152.7199403462087388546@ietfa.amsl.com> In-Reply-To: <155505204479.14152.7199403462087388546@ietfa.amsl.com> Date: Wed, 24 Apr 2019 12:07:57 -0700 Message-ID: <10b901d4fad1$083ea8a0$18bbf9e0$@clemm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKw43otqaGpXoXOtddsrPLMlZ53hKST2wnA Content-Language: en-us X-Provags-ID: V03:K1:SJSBZTGXRn37+9aNn8mBirfzOdzKjlp3zdTxr4PSDYXHzVFlLBc TM3Em0Csl2pjN+7YrFrLi5kz83eddxVP6I1pjn+1ZCmzI/PUmoTF/AXxmrjMzpmYGIlhPAE 0vVEHWmgVRSYrfWdayPiABgwtdfdUJgDcZhTc5v/51QisKnalKZDaNwWnfbQTPNT8d23aSj vpFylY+L0SOCKM7fs2d3w== X-UI-Out-Filterresults: notjunk:1;V03:K0:i5PpDSJ2Z5M=:qB9yJ1+gRMgCj8gESdA/IJ t8m9RT4+WjNt6vnszU39qVhasxPHURsGnpLH8cfL8htSqkRPFBhiuHVnFKvKwkS9bQx53YE5h OJ8X6m+Dt8RdpULn8IWijsj8THMHaILPpRJzq1Z4Zr14TSzNgo+TUU8HK+KxjIgu3D6Su2COh 5d+skulST3cULCGJZMZmZuLc1y3a4NXCvgSNxJ4oHTiwZl7HwEZt7FMwJQ4z8PgV9/7lCGrrq 8EDSS0CQkieYT0Shq0pvMizq/ajzXDZbgBwHjMUR2wIsOB2z2poOsTm1jqY7VwrRZnW89fGfQ X4bjCpsGHXDgFO0HKIPPqRtTfTE/r5wg5elT++kJe2wn5VQ+rMRzAo/9zJyRFfQVLe9p3sRD6 eMA1P3m2LOJhYrSwIlyUjWRyuZjagieQFP4ukG7DedhIyfHaGFE9bBA9BBGXBdu1IqZRcTJQl KnvRQcG5wfKZELf++Vlt2Q1niI9dg8Zk/9DabrYGnzasSMvg7jrfsh0Ea2HY8nMQz7LfFT9Vb 0JuTC1CRZDHVyVoqoeARUubPLAtPGKvEGBI5jx5Lo5kZ18yICM8LqMV5JbAVgfivmXp90ggv+ ULWGI09ygJnvm0lzq/rT8mkz7JOxlH45MfeguSpOIuFSmmMHutVM5pGks7+jZIWEDfkXd3yue 9mPUG/JN6BQqaqrb9vca0z6oOz7FJGRvXtNlhYPRF5+yBmz9ksVHXKUvNKQOeyCMwQaEncRbN Mi8a1YJtWdOXHn84//zkxAgHeVtmnv33v9ZFAuE9GcaAl0wxBiTRPNf7+Oo= Archived-At: Subject: Re: [netconf] Opsdir last call review of draft-ietf-netconf-restconf-notif-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 19:08:08 -0000 Hello Dan, Thank you for your review! --- Alex -----Original Message----- From: Dan Romascanu via Datatracker =20 Sent: Thursday, April 11, 2019 11:54 PM To: ops-dir@ietf.org Cc: netconf@ietf.org; ietf@ietf.org; = draft-ietf-netconf-restconf-notif.all@ietf.org; dromasca@gmail.com Subject: Opsdir last call review of draft-ietf-netconf-restconf-notif-13 Reviewer: Dan Romascanu Review result: Ready This document describes the RESTCONF binding to the dynamic subscription = capability of both subscribed notifications and YANG-Push. It's a useful = and important addition to the RESTCONF protocol mechanisms, and = operators should pay attention. The document is not easy reading, as it = relies on several other documents, but the references in the text help. = It would have helped if some notes were added concerning the possible = actions that the operators need to take in order to ensure optimal = behavior (initial configuration for example) or indications about when = to use one or the other of the notifications mechanisms. This is not blocking, however, and the document is READY for = publication. From nobody Wed Apr 24 13:29:49 2019 Return-Path: <0100016a510a3038-7671e146-e23f-4bc9-9f93-ea2314b5d4e7-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED36F120132 for ; Wed, 24 Apr 2019 13:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnC3spVvrr00 for ; Wed, 24 Apr 2019 13:29:44 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74BA1200DF for ; Wed, 24 Apr 2019 13:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556137783; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=9e0h22rAspWk6EVSRvhlRR5iMi+ePTQlTtAU5PI5M4Q=; b=fKE/zaSfwOz0P4Uqu/9CF9bNWgnrYX07Qz/0aI00E0WN/B36rPPyaGDF/+izgya2 ajSIg330ewy5yCppU2AwI4DnmLxnFXGmyP2Fq9G3BtTDGV7Bg51jOC+0TwZOZnTdoV2 lXJbpGJp4zFQnmvZyWlVh8LrZvqR4hH2d0M65SiI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Kent Watsen In-Reply-To: <20190424180513.gtxmreicd7iydrpr@anna.jacobs.jacobs-university.de> Date: Wed, 24 Apr 2019 20:29:43 +0000 Cc: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <0100016a510a3038-7671e146-e23f-4bc9-9f93-ea2314b5d4e7-000000@email.amazonses.com> References: <20190404164929.fsfga7s4izn7ucx5@anna.jacobs.jacobs-university.de> <20190404.194623.1178346313710501110.mbj@tail-f.com> <01dd01d4eb9c$b9a04160$4001a8c0@gateway.2wire.net> <20190405.142201.707949273328784535.mbj@tail-f.com> <413d5725-9c27-e50b-2622-1b0e2f35cdb1@ericsson.com> <0100016a5019d7f9-7f737c63-d07c-4c7f-b12e-c5b19d50eeaf-000000@email.amazonses.com> <20190424180513.gtxmreicd7iydrpr@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.24-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 20:29:47 -0000 Hi Juergen, > Perhaps this should say 'implementation specific' instead 'application > specific'. Changed in my local copy. >> My recommendation is to modify the "generate/install-hidden-key" = (renamed to just "generate/install-key") actions to have a flag = indicating if the key should be "permanently hidden" (perhaps by using a = TPM) or not, in which case configuration is created, same as if the = client had used , but without needing to touch the key. >=20 > I agree that having a flag to control the behavior is useful and I > think there should be explicit text how the action fails in case the > requested action cannot be performed. >=20 > I am not sure I understand install-hidden-key. The description says: >=20 > "Requests the device to load the specified values into > a hidden key. The resulting asymmetric key values are > considered operational state and hence present only in > ."; >=20 > So what is the persistence model of this? Does a key installed with > install-hidden-key survive reboots? If so, can I delete somehow such a > hidden key? (Is the answer that this key is tied to the lifetime of > the list element indirectly using this grouping?) Does invoking > install-hidden-key twice cause the first installed key to be > overwritten? Can the install-hidden-key action fail in any way? >=20 > This leads to related questions for generate-hidden-key: Does invoking > this action twice cause an existing key to be overwritten? Can I > explicitely delete a generated hidden key? Does deleting the list item > that directly or indirectly uses this grouping delete a hidden key? [Disclaimer: the below reflect my understanding of how the current model = works, and does not necessarily reflect if we were to flip things around = by letting the actions generate configuration.] The expectation is that the "permanently hidden" keys would persist, = presumably with origin=3Dsystem. In the YANG, the "permanently-hidden" enum only appears in the = "asymmetric-key-pair-grouping" grouping. Consuming data models are = expected to "use" this grouping under a "config true" node. This = grouping's description statement is noteworthy: grouping asymmetric-key-pair-grouping { description "A private/public key pair. =20 The 'algorithm', 'public-key', and 'private-key' nodes are not mandatory because they MAY be defined in . Implementations SHOULD assert that these values are either configured or that they exist in ."; ... } Thusly it is expected that the client will create the parent node (e.g., = via ) and then invoke either the generate or install hidden = key action. Presumably, the lifetime of the permanently hidden key = would be tied to the lifetime of its parent. Regarding what happens when the actions are invoked a second time, it's = not specified. One choice, perhaps the safe choice, would be to deny = subsequent attempts, forcing the client to create a new parent node = instead. If the parent node is in a list, such as in the keystore, then = the second key could be created, with certificates bound to it, before = mapping reference to the old-key to the new-key. However, if the key is = not in a list, such as when using a "local-definition", then in in-place = migration, along with service disruption, would be required. Of course, one has to ask how often/likely is it that a client wants to = regenerate the private key. Presumably it would only be due to the = concern that the key had been compromised (which shouldn't happen if = "permanently hidden") or, perhaps, due to a proactive key-rotation = policy, thinking (misguided, I believe, proven false now) that the = private key's entropy expires over time. Regardless, the point is that = it seems to be an action that would seldomly occur and, when/if it does, = the effort to create another parent node (in keystore or a = local-definition) might not be a big deal. PS: words such as "expectation" and "presumably" are used above to = indicate a likely need for the text to be more explicit. Kent // contributor From nobody Wed Apr 24 20:22:59 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989BB120105 for ; Wed, 24 Apr 2019 20:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LhEWh8g_vYQ for ; Wed, 24 Apr 2019 20:22:55 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6796A12008F for ; Wed, 24 Apr 2019 20:22:55 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 239154B5C7E8B3C4EEBD for ; Thu, 25 Apr 2019 04:22:53 +0100 (IST) Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 25 Apr 2019 04:22:52 +0100 Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 25 Apr 2019 04:22:52 +0100 Received: from SINEML702-CAH.china.huawei.com (10.223.161.52) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Thu, 25 Apr 2019 04:22:52 +0100 Received: from SINEML521-MBX.china.huawei.com ([169.254.1.204]) by SINEML702-CAH.china.huawei.com ([169.254.255.221]) with mapi id 14.03.0415.000; Thu, 25 Apr 2019 11:22:47 +0800 From: Wang Haiguang To: "netconf@ietf.org" Thread-Topic: The maintenance of the algorithm identifiers in draft-ietf-crypto-types Thread-Index: AdT7E8hZAPIgEzoMT+CWvaCRHboBxw== Date: Thu, 25 Apr 2019 03:22:46 +0000 Message-ID: <0AE05CBFB1A6A0468C8581DAE58A31309E3CB0F5@SINEML521-MBX.china.huawei.com> Accept-Language: en-SG, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.37.82] Content-Type: multipart/alternative; boundary="_000_0AE05CBFB1A6A0468C8581DAE58A31309E3CB0F5SINEML521MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 03:22:57 -0000 --_000_0AE05CBFB1A6A0468C8581DAE58A31309E3CB0F5SINEML521MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, everyone. Recently there are some discussions in i2nsf group over the crypto algorith= m identifiers defined in the draft-ietf-cryoto-types. Please refer to the email thread below for the discussion there: https://mailarchive.ietf.org/arch/msg/i2nsf/XZevQcuifa_PN6OeZMLaMch3mAo The basic concerns in the email is as follows: 1. Crypto-types contains a generic list of crypto algorithms. Some of= them are not supported by IPSec, how should they handle this. a. Somebody suggest to include a subset of the supported algorithms i= n their draft. I think it is a good idea. 2. Some deprecated algorithm are needed by their draft. a. Some expert suggested to define those identifiers by them own with= in their draft. I think this is a feasible solution. For the above issue, I think we can add some text in draft-ietf-crypto-type= s to guide users from other group how to handle the above two issues. Beside that, in the future, some new algorithms might be added and some al= gorithms will be deprecated, we have to figure out how to made the algorith= m list defined by crypto-types flexible. If you have any suggestion, please post it on the mailing list. Let's discuss and find a feasible solution to it. Best Regards. Haiguang --_000_0AE05CBFB1A6A0468C8581DAE58A31309E3CB0F5SINEML521MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, everyone.

 

Recently there are some discussions in i2nsf group o= ver the crypto algorithm identifiers defined in the draft-ietf-cryoto-types= .

Please refer to the email thread below for the discu= ssion there:

https://mailarchive.ietf.org/arch/msg/i2nsf/XZevQcuifa_PN6OeZMLaMch3mAo

 

The basic concerns in the email is as follows:<= /o:p>

1.     &= nbsp; Crypto-types contains a generic list of crypto algo= rithms. Some of them are not supported by IPSec, how should they handle thi= s.  

a.       Somebody suggest to include a subset of the support= ed algorithms in their draft. I think it is a good idea.  <= /p>

2.     &= nbsp; Some deprecated algorithm are needed by their draft= .

a.       Some expert suggested to define those identifiers b= y them own within their draft. I think this is a feasible solution.

 

For the above issue, I think we can add some text in= draft-ietf-crypto-types to guide users from other group how to handle the = above two issues.

 

Beside that,  in the future, some new algorithm= s might be added and some algorithms will be deprecated, we have to figure = out how to made the algorithm list defined by crypto-types flexible.

 

If you have any suggestion, please post it on the ma= iling list.

 

Let’s discuss and find a feasible solution to = it.

 

Best Regards.

 

Haiguang

--_000_0AE05CBFB1A6A0468C8581DAE58A31309E3CB0F5SINEML521MBXchi_-- From nobody Wed Apr 24 23:42:11 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0484D1200EA for ; Wed, 24 Apr 2019 23:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqDfYHDkPHtA for ; Wed, 24 Apr 2019 23:42:06 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D78C120133 for ; Wed, 24 Apr 2019 23:42:05 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 3FE83DAC; Thu, 25 Apr 2019 08:42:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 7UbaEr3BPMsq; Thu, 25 Apr 2019 08:42:04 +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 atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 25 Apr 2019 08:42:04 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 207F1200D5; Thu, 25 Apr 2019 08:42:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id DkUyGYf0qLow; Thu, 25 Apr 2019 08:42:03 +0200 (CEST) Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id A2950200D3; Thu, 25 Apr 2019 08:42:03 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Thu, 25 Apr 2019 08:42:03 +0200 Received: by anna.localdomain (Postfix, from userid 501) id 7C01F300894B8A; Thu, 25 Apr 2019 08:42:02 +0200 (CEST) Date: Thu, 25 Apr 2019 08:42:01 +0200 From: Juergen Schoenwaelder To: Wang Haiguang CC: "netconf@ietf.org" Message-ID: <20190425064201.lfuwspbkkwatbg6h@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Wang Haiguang , "netconf@ietf.org" References: <0AE05CBFB1A6A0468C8581DAE58A31309E3CB0F5@SINEML521-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <0AE05CBFB1A6A0468C8581DAE58A31309E3CB0F5@SINEML521-MBX.china.huawei.com> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 06:42:10 -0000 On Thu, Apr 25, 2019 at 03:22:46AM +0000, Wang Haiguang wrote: > Hello, everyone. > > Recently there are some discussions in i2nsf group over the crypto algorithm identifiers defined in the draft-ietf-cryoto-types. > Please refer to the email thread below for the discussion there: > https://mailarchive.ietf.org/arch/msg/i2nsf/XZevQcuifa_PN6OeZMLaMch3mAo > > The basic concerns in the email is as follows: > > 1. Crypto-types contains a generic list of crypto algorithms. Some of them are not supported by IPSec, how should they handle this. > > a. Somebody suggest to include a subset of the supported algorithms in their draft. I think it is a good idea. > I am not sure what "include a subset of the supported algorithms in their draft" means. Please explain. This issue touches on an open issue that we never managed to solve: Given an arbitrarily extensible set of identifiers, how does an implementation announce the subset actually supported? And related to that, can a YANG module define a subset that is expected to be supported (i.e., a conformance requirement)? I am not sure we have a YANG next issue for this, but we should. > 2. Some deprecated algorithm are needed by their draft. > > a. Some expert suggested to define those identifiers by them own within their draft. I think this is a feasible solution. > This sounds a bit like hiding deprecated crypto somehow under the carpet. What if multiple technologies need the same deprecated crypto algorithm? They create multiple identifiers for the same thing or they get interesting module dependencies? Crypto algorithms come and go and ietf-crypto-types will sooner or later have identities that will need to be deprecated because the crypt algorithm is not considered secure enough anymore. So in the long term, hiding deprecated crypto algorithms in some corners "under the carpet" will not work. My point is that "we only have good crypto algorithms defined in ietf-crypto-types" is not going to work for long. > For the above issue, I think we can add some text in draft-ietf-crypto-types to guide users from other group how to handle the above two issues. > > Beside that, in the future, some new algorithms might be added and some algorithms will be deprecated, we have to figure out how to made the algorithm list defined by crypto-types flexible. The obvious way of dealing with this is to deprecate the identities when algorithms are considered to be not secure enough anymore. /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 Apr 25 04:01:57 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F79120071 for ; Thu, 25 Apr 2019 04:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.247 X-Spam-Level: X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKd3dXhWT4rx for ; Thu, 25 Apr 2019 04:01:52 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80102.outbound.protection.outlook.com [40.107.8.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55FB8120021 for ; Thu, 25 Apr 2019 04:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wSUevAkgVTrxZMjLRDujwJ4FQ0MSTE45DSax1hBvBYw=; b=Gu6UcK+l39ekrSfnV4I4kfNwdZJ282wsQDsTV3rrS7aYWd6BX3EJpdPCj8DVB3f2HHZtr1aI20FNT9Y1nF8ovde/m6nxVxTrZHlZxJDRq89kM2fk5I1qpXUYHB6byb56x6Y4RpK0QNqc45lMl3mYMjysmi3ZmCvsj3DPf8aprDo= Received: from DB7PR07MB5562.eurprd07.prod.outlook.com (20.178.46.212) by DB7PR07MB4997.eurprd07.prod.outlook.com (20.177.193.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.5; Thu, 25 Apr 2019 11:01:49 +0000 Received: from DB7PR07MB5562.eurprd07.prod.outlook.com ([fe80::89bf:8194:3f8c:ff65]) by DB7PR07MB5562.eurprd07.prod.outlook.com ([fe80::89bf:8194:3f8c:ff65%6]) with mapi id 15.20.1835.010; Thu, 25 Apr 2019 11:01:49 +0000 From: tom petch To: Wang Haiguang , "netconf@ietf.org" Thread-Topic: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types Thread-Index: AQHU+1ZHgZ5Vg/wJskmQTLEgbjEyCQ== Date: Thu, 25 Apr 2019 11:01:49 +0000 Message-ID: <01e301d4fb55$d1cc3500$4001a8c0@gateway.2wire.net> References: <0AE05CBFB1A6A0468C8581DAE58A31309E3CB0F5@SINEML521-MBX.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0226.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:b::22) To DB7PR07MB5562.eurprd07.prod.outlook.com (2603:10a6:10:7b::20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.215.234] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5994c3c1-9f07-46a7-e028-08d6c96d69c4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DB7PR07MB4997; x-ms-traffictypediagnostic: DB7PR07MB4997: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0018A2705B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(39860400002)(396003)(366004)(346002)(189003)(199004)(13464003)(81156014)(81166006)(8676002)(84392002)(81686011)(61296003)(81816011)(256004)(99286004)(44736005)(86362001)(76176011)(2906002)(6486002)(71190400001)(6436002)(66476007)(97736004)(25786009)(52116002)(66556008)(64756008)(66446008)(73956011)(66946007)(110136005)(316002)(4720700003)(71200400001)(186003)(66066001)(53936002)(6116002)(68736007)(6506007)(386003)(26005)(86152003)(2501003)(44716002)(62236002)(476003)(446003)(486006)(229853002)(6246003)(3846002)(9686003)(6512007)(6306002)(966005)(14454004)(305945005)(7736002)(50226002)(478600001)(1556002)(102836004)(5660300002)(14496001)(8936002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB4997; H:DB7PR07MB5562.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: L4KhPvhz9sAC4AFqyaeZBpaeRROVB1rppWf+TJP7EhpNkGpgSlhwPBSFKH1VYfGOGcPDqj7QH1/5JswOUAGt6GTW5wZUu7x3CfSc1B72fKU7a+KfJPevBRshqjkujzHujpzTDFYjBDrgutF+fwUrliH9f1wowzzhSrPPCpJoFbxDoxyhasHAqtZgZmtnPirGPghHlrpCvzE35XK6hrCmi271QPTRHLvSrnof++z6dDdjqHcEPKkLydUgVC4VmQ39Itof4jMxNYkcoxm2o6E5m2s4wLx7z17vkhz735hHrQ00OfWkdPKe93wBcMhkBgbg5xSC7FTpF3XOojI1EONdUQ1YjTkevA9E3A3GPnm9/g4A4LEjKSzgK0TyJyJVwEChAeAafqd8hjD+YfLr7plaGGd42LGDR0mFSJ55KElqkKE= Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1AA877A44D1EC142832F3868063EDEEE@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5994c3c1-9f07-46a7-e028-08d6c96d69c4 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2019 11:01:49.5881 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4997 Archived-At: Subject: Re: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 11:01:55 -0000 ----- Original Message ----- From: "Wang Haiguang" Sent: Thursday, April 25, 2019 4:22 AM Hello, everyone. Recently there are some discussions in i2nsf group over the crypto algorithm identifiers defined in the draft-ietf-cryoto-types. Please refer to the email thread below for the discussion there: https://mailarchive.ietf.org/arch/msg/i2nsf/XZevQcuifa_PN6OeZMLaMch3mAo The basic concerns in the email is as follows: 1. Crypto-types contains a generic list of crypto algorithms. Some of them are not supported by IPSec, how should they handle this. a. Somebody suggest to include a subset of the supported algorithms in their draft. I think it is a good idea. 2. Some deprecated algorithm are needed by their draft. a. Some expert suggested to define those identifiers by them own within their draft. I think this is a feasible solution. For the above issue, I think we can add some text in draft-ietf-crypto-types to guide users from other group how to handle the above two issues. Beside that, in the future, some new algorithms might be added and some algorithms will be deprecated, we have to figure out how to made the algorithm list defined by crypto-types flexible. To state the obvious (?), the larger something is the more unstable it is so putting in the kitchen sink - KEX, HASH, MAC... - all into one module is going to increase the churn on that module, as opposed to having separate (sub-?)modules for e.g. KEX, MAC. HASH. Again, to state the obvious, if this mega-module is published as an RFC, then it must be updated by further RFC, once agreement has been reached on what has become obsolete, too insecure etc. Two technological solutions come to mind; divide the module up into smaller pieces which would require more changes in total but fewer for any one of the subdivided modules. And make the module(s) IANA-controlled which allows a spectrum of ways in which updates can be performed, from FCFS to Standards Track RFC and which allows different approaches for e.g. KEX and HASH. Tom Petch If you have any suggestion, please post it on the mailing list. Let's discuss and find a feasible solution to it. Best Regards. Haiguang ------------------------------------------------------------------------ -------- > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Thu Apr 25 09:15:28 2019 Return-Path: <0100016a554785f6-a0f918fc-5396-4410-8320-701f65abf6c0-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F50120289 for ; Thu, 25 Apr 2019 09:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vy7ZosNifbg6 for ; Thu, 25 Apr 2019 09:15:14 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06CEC120400 for ; Thu, 25 Apr 2019 09:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556208912; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=E2oQyomusubDoAKUcn/g+fqrsZhFsDM9Af6U5kca3i4=; b=OYfwq+EnqO8QVpYChfiLB12/3vzIPOZAvjbcv0kWKG5uEZSEeoCT+Aw8FZGUfutr 91nVJxFhfc6DlqzlBAzGtPaV0ZQsfTtscGSJO6yOBv745S5gckLqJXxGy2XdK52wmFA 5OZQImiE2PKcwJx/msMB1x+nDSsMRdSODXr0J9Lg= From: Kent Watsen Message-ID: <0100016a554785f6-a0f918fc-5396-4410-8320-701f65abf6c0-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BA02C17D-7AF5-439D-BB8F-4CCB2E865EB5" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 25 Apr 2019 16:15:11 +0000 In-Reply-To: <20190425064201.lfuwspbkkwatbg6h@anna.jacobs.jacobs-university.de> Cc: Wang Haiguang , "netconf@ietf.org" To: Juergen Schoenwaelder References: <0AE05CBFB1A6A0468C8581DAE58A31309E3CB0F5@SINEML521-MBX.china.huawei.com> <20190425064201.lfuwspbkkwatbg6h@anna.jacobs.jacobs-university.de> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.25-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 16:15:27 -0000 --Apple-Mail=_BA02C17D-7AF5-439D-BB8F-4CCB2E865EB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > This issue touches on an open issue that we never managed to solve: > Given an arbitrarily extensible set of identifiers, how does an > implementation announce the subset actually supported? And related to > that, can a YANG module define a subset that is expected to be > supported (i.e., a conformance requirement)? I am not sure we have > a YANG next issue for this, but we should. Just submitted https://github.com/netmod-wg/yang-next/issues/80 = . Perhaps YANG Library be used for this? >=20 >> 2. Some deprecated algorithm are needed by their draft. >>=20 >> a. Some expert suggested to define those identifiers by them = own within their draft. I think this is a feasible solution. >>=20 >=20 > This sounds a bit like hiding deprecated crypto somehow under the > carpet. What if multiple technologies need the same deprecated crypto > algorithm? They create multiple identifiers for the same thing or they > get interesting module dependencies? Crypto algorithms come and go and > ietf-crypto-types will sooner or later have identities that will need > to be deprecated because the crypt algorithm is not considered secure > enough anymore. So in the long term, hiding deprecated crypto > algorithms in some corners "under the carpet" will not work. My point > is that "we only have good crypto algorithms defined in > ietf-crypto-types" is not going to work for long. Agreed. It would seem that crypto-types should define the universe of = all known algorithms, even it deprecated or obsoleted, and let the = solution to Issue #80 enable implementations identify the subset they = support. >> For the above issue, I think we can add some text in = draft-ietf-crypto-types to guide users from other group how to handle = the above two issues. >>=20 >> Beside that, in the future, some new algorithms might be added and = some algorithms will be deprecated, we have to figure out how to made = the algorithm list defined by crypto-types flexible. >=20 > The obvious way of dealing with this is to deprecate the identities > when algorithms are considered to be not secure enough anymore. Yes, the identity takes "status" as a substatement, so this can be done. = =20 This discussion makes me wonder if the module should be called = iana-crytpo-types and have IANA maintain the module. Kent // contributor --Apple-Mail=_BA02C17D-7AF5-439D-BB8F-4CCB2E865EB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Perhaps YANG Library be used for = this?




2. =       Some deprecated algorithm are needed = by their draft.

a. =       Some expert suggested to define = those identifiers by them own within their draft. I think this is a = feasible solution.


This sounds a bit like hiding deprecated crypto somehow under = the
carpet. What if multiple technologies need the same = deprecated crypto
algorithm? They create multiple = identifiers for the same thing or they
get interesting = module dependencies? Crypto algorithms come and go and
ietf-crypto-types will sooner or later have identities that = will need
to be deprecated because the crypt algorithm is = not considered secure
enough anymore. So in the long term, = hiding deprecated crypto
algorithms in some corners "under = the carpet" will not work. My point
is that "we only have = good crypto algorithms defined in
ietf-crypto-types" is = not going to work for long.

Agreed.=  It would seem that crypto-types should define the universe of all = known algorithms, even it deprecated or obsoleted, and let the solution = to Issue #80 enable implementations identify the subset they = support.


For the above issue, I = think we can add some text in draft-ietf-crypto-types to guide users = from other group how to handle the above two issues.

Beside that,  in the future, some new algorithms might = be added and some algorithms will be deprecated, we have to figure out = how to made the algorithm list defined by crypto-types flexible.

The obvious way of dealing with = this is to deprecate the identities
when algorithms are = considered to be not secure enough = anymore.

Yes, the = identity takes "status" as a substatement, so this can be done. =   

This discussion makes = me wonder if the module should be called iana-crytpo-types and have IANA = maintain the module.

Kent // = contributor

= --Apple-Mail=_BA02C17D-7AF5-439D-BB8F-4CCB2E865EB5-- From nobody Thu Apr 25 09:51:23 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930DA120223 for ; Thu, 25 Apr 2019 09:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOSCzZYmsNCq for ; Thu, 25 Apr 2019 09:51: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 C58F01201DC for ; Thu, 25 Apr 2019 09:51:19 -0700 (PDT) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 21C8A1AE03B5; Thu, 25 Apr 2019 18:51:17 +0200 (CEST) Date: Thu, 25 Apr 2019 18:51:16 +0200 (CEST) Message-Id: <20190425.185116.1747028954255365462.mbj@tail-f.com> To: kent@watsen.net Cc: j.schoenwaelder@jacobs-university.de, wang.haiguang.shieldlab@huawei.com, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016a554785f6-a0f918fc-5396-4410-8320-701f65abf6c0-000000@email.amazonses.com> References: <0AE05CBFB1A6A0468C8581DAE58A31309E3CB0F5@SINEML521-MBX.china.huawei.com> <20190425064201.lfuwspbkkwatbg6h@anna.jacobs.jacobs-university.de> <0100016a554785f6-a0f918fc-5396-4410-8320-701f65abf6c0-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 16:51:22 -0000 Kent Watsen wrote: > > > > This issue touches on an open issue that we never managed to solve: > > Given an arbitrarily extensible set of identifiers, how does an > > implementation announce the subset actually supported? And related to > > that, can a YANG module define a subset that is expected to be > > supported (i.e., a conformance requirement)? I am not sure we have > > a YANG next issue for this, but we should. > > Just submitted https://github.com/netmod-wg/yang-next/issues/80 > . > > Perhaps YANG Library be used for this? This requirement is already captured in #40. /martin From nobody Thu Apr 25 10:51:53 2019 Return-Path: <0100016a559fd6c6-0deaad17-593f-434c-94b6-111ac0619a3c-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18F41201C7 for ; Thu, 25 Apr 2019 10:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5h1sS8MEdR2C for ; Thu, 25 Apr 2019 10:51:48 -0700 (PDT) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1691202E6 for ; Thu, 25 Apr 2019 10:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556214700; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=hKfQf6cxtmHG32qsvA4eHRIHyUHCz7dYa3FWlzjxCcs=; b=NRNEvGZzOLPz9Y0F3+dB50x/gQNXksg0LuTMDa6+4igYMmqvqmuS+yPAPVtdjsNk TOB61FBocQ9s7DaMQw4z5m2mTsSYtK1TsU8lz3QCqFlbDbr7hq9aIjnBXRs9HK4ceJx tGQms8crAQHzzODd6kODH5Fjpb5V3RSOHw1yKof4= From: Kent Watsen Message-ID: <0100016a559fd6c6-0deaad17-593f-434c-94b6-111ac0619a3c-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CF90D05C-DB7F-4372-992D-E37A270C8671" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 25 Apr 2019 17:51:39 +0000 In-Reply-To: <20190425.185116.1747028954255365462.mbj@tail-f.com> Cc: Wang Haiguang , "netconf@ietf.org" To: Martin Bjorklund References: <0AE05CBFB1A6A0468C8581DAE58A31309E3CB0F5@SINEML521-MBX.china.huawei.com> <20190425064201.lfuwspbkkwatbg6h@anna.jacobs.jacobs-university.de> <0100016a554785f6-a0f918fc-5396-4410-8320-701f65abf6c0-000000@email.amazonses.com> <20190425.185116.1747028954255365462.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.25-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 17:51:51 -0000 --Apple-Mail=_CF90D05C-DB7F-4372-992D-E37A270C8671 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 25, 2019, at 12:51 PM, Martin Bjorklund wrote: >=20 > Kent Watsen wrote: >>=20 >>=20 >>> This issue touches on an open issue that we never managed to solve: >>> Given an arbitrarily extensible set of identifiers, how does an >>> implementation announce the subset actually supported? And related = to >>> that, can a YANG module define a subset that is expected to be >>> supported (i.e., a conformance requirement)? I am not sure we have >>> a YANG next issue for this, but we should. >>=20 >> Just submitted https://github.com/netmod-wg/yang-next/issues/80 >> . >>=20 >> Perhaps YANG Library can be used for this? >=20 > This requirement is already captured in #40. The issues are related, but seem like two sides of a coin: #40 regards deviating away what is not supported #80 regards expressing what is supported Of course, what is supported could be form of implementing the module = and then deviating away what's not used, but is it ideal? =20 For instance, a server may implement different modules that use = different sets of identities (e.g., because they use different libraries = in the backend), such that what is not supported in one module (and = hence the deviated away) is supported in the other (and hence shouldn't = be deviated away). Kent // contributor --Apple-Mail=_CF90D05C-DB7F-4372-992D-E37A270C8671 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 25, 2019, at 12:51 PM, Martin Bjorklund <mbj@tail-f.com> = wrote:

Kent Watsen <kent@watsen.net> wrote:


This issue touches on an open issue that we = never managed to solve:
Given an arbitrarily extensible = set of identifiers, how does an
implementation announce = the subset actually supported? And related to
that, can a = YANG module define a subset that is expected to be
supported= (i.e., a conformance requirement)? I am not sure we have
a = YANG next issue for this, but we should.

Just submitted https://github.com/netmod-wg/yang-next/issues/80
<https://github.com/netmod-wg/yang-next/issues/80>.

Perhaps YANG Library can be used for this?

This requirement is already = captured in #40.

The issues are related, but seem like two = sides of a coin:

   #40 regards deviating away what is not = supported
   #80 regards expressing what = is supported

Of = course, what is supported could be form of implementing the module and = then deviating away what's not used, but is it ideal? =   

For= instance, a server may implement different modules that use different = sets of identities (e.g., because they use different libraries in the = backend), such that what is not supported in one module (and hence the = deviated away) is supported in the other (and hence shouldn't be = deviated away).


Kent // = contributor


= --Apple-Mail=_CF90D05C-DB7F-4372-992D-E37A270C8671-- From nobody Thu Apr 25 11:50:56 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36A3120252 for ; Thu, 25 Apr 2019 11:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38byqyL4YdHd for ; Thu, 25 Apr 2019 11:50:52 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 50F58120227 for ; Thu, 25 Apr 2019 11:50:43 -0700 (PDT) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 887801AE03B5; Thu, 25 Apr 2019 20:50:39 +0200 (CEST) Date: Thu, 25 Apr 2019 20:50:39 +0200 (CEST) Message-Id: <20190425.205039.1112892422143145313.mbj@tail-f.com> To: kent@watsen.net Cc: wang.haiguang.shieldlab@huawei.com, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016a559fd6c6-0deaad17-593f-434c-94b6-111ac0619a3c-000000@email.amazonses.com> References: <0100016a554785f6-a0f918fc-5396-4410-8320-701f65abf6c0-000000@email.amazonses.com> <20190425.185116.1747028954255365462.mbj@tail-f.com> <0100016a559fd6c6-0deaad17-593f-434c-94b6-111ac0619a3c-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 18:50:55 -0000 Kent Watsen wrote: > > > > On Apr 25, 2019, at 12:51 PM, Martin Bjorklund wrote: > > > > Kent Watsen wrote: > >> > >> > >>> This issue touches on an open issue that we never managed to solve: > >>> Given an arbitrarily extensible set of identifiers, how does an > >>> implementation announce the subset actually supported? And related to > >>> that, can a YANG module define a subset that is expected to be > >>> supported (i.e., a conformance requirement)? I am not sure we have > >>> a YANG next issue for this, but we should. > >> > >> Just submitted https://github.com/netmod-wg/yang-next/issues/80 > >> . > >> > >> Perhaps YANG Library can be used for this? > > > > This requirement is already captured in #40. > > The issues are related, but seem like two sides of a coin: > > #40 regards deviating away what is not supported > #80 regards expressing what is supported > > Of course, what is supported could be form of implementing the module > and then deviating away what's not used, but is it ideal? Right, this is part of #40. IMO #40 states the *problem* but not the solution. It is unfortunate that the title indicates a solution, but that is the case for many of our other issues as well. /martin > > For instance, a server may implement different modules that use > different sets of identities (e.g., because they use different > libraries in the backend), such that what is not supported in one > module (and hence the deviated away) is supported in the other (and > hence shouldn't be deviated away). > > > Kent // contributor > > From nobody Thu Apr 25 14:21:48 2019 Return-Path: <0100016a5660266f-69525394-213b-4cc1-ae5c-89d8d93a6160-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41ADE120226 for ; Thu, 25 Apr 2019 14:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWtcetFythLh for ; Thu, 25 Apr 2019 14:21:44 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9604B12015D for ; Thu, 25 Apr 2019 14:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556227303; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=f0olK7TuJxE4tr0yQ4/OZhWRhokjlhUnRf2p981t1xc=; b=bF0d+l+5Sxf3QWDjihG+gng8qMnqA24b8K1Eqqe9/QeUJl25pjLM8qz75SoJ5p10 UKVFLPK6+8xBdggNLW32KUlafpXImrgWH6HJ2T6EJF3Ko8ZnLrJ+BscfZltOnBxtWwf ts5TawxasrEeVaEryOZ1nkTkVwHtBr5Ws0zTxZsA= From: Kent Watsen Message-ID: <0100016a5660266f-69525394-213b-4cc1-ae5c-89d8d93a6160-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B3E01AAF-0356-46B5-B87D-FE11323C22B2" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 25 Apr 2019 21:21:43 +0000 In-Reply-To: <20190425.205039.1112892422143145313.mbj@tail-f.com> Cc: wang.haiguang.shieldlab@huawei.com, "netconf@ietf.org" To: Martin Bjorklund References: <0100016a554785f6-a0f918fc-5396-4410-8320-701f65abf6c0-000000@email.amazonses.com> <20190425.185116.1747028954255365462.mbj@tail-f.com> <0100016a559fd6c6-0deaad17-593f-434c-94b6-111ac0619a3c-000000@email.amazonses.com> <20190425.205039.1112892422143145313.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.25-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 21:21:47 -0000 --Apple-Mail=_B3E01AAF-0356-46B5-B87D-FE11323C22B2 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii >>> This requirement is already captured in #40. >> >> The issues are related, but seem like two sides of a coin: >> >> #40 regards deviating away what is not supported >> #80 regards expressing what is supported >> >> Of course, what is supported could be form of implementing the module >> and then deviating away what's not used, but is it ideal? > > Right, this is part of #40. IMO #40 states the *problem* but not the > solution. It is unfortunate that the title indicates a solution, but > that is the case for many of our other issues as well. The titles can and should be updated to reflect the true problem. Could you update #40 and close #80 with label "Duplicate"? In the meanwhile, what's the stop-gap solution? - crypto-types shouldn't be blocked on YANG Next... Kent --Apple-Mail=_B3E01AAF-0356-46B5-B87D-FE11323C22B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

This requirement is = already captured in #40.

The = issues are related, but seem like two sides of a coin:

  #40 regards deviating away what is not = supported
  #80 regards expressing what is = supported

Of course, what is supported = could be form of implementing the module
and then = deviating away what's not used, but is it ideal?

Right, this is part of #40. =  IMO #40 states the *problem* but not the
solution. =  It is unfortunate that the title indicates a solution, but
that is the case for many of our other issues as well.

The titles can = and should be updated to reflect the true problem.
Could you = update #40 and close #80 with label "Duplicate"?

In the meanwhile, what's the stop-gap solution? =   - crypto-types
shouldn't be blocked on YANG = Next...

Kent

= --Apple-Mail=_B3E01AAF-0356-46B5-B87D-FE11323C22B2-- From nobody Thu Apr 25 14:45:26 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD5D120317 for ; Thu, 25 Apr 2019 14:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPwBBiDLcdn8 for ; Thu, 25 Apr 2019 14:45:20 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60474120308 for ; Thu, 25 Apr 2019 14:45:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 3E7F01F; Thu, 25 Apr 2019 23:45:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id RPDKFaOMzjPw; Thu, 25 Apr 2019 23:45:18 +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 atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 25 Apr 2019 23:45:18 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id F1B2E200D8; Thu, 25 Apr 2019 23:45:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id b2J0gvyC_yUp; Thu, 25 Apr 2019 23:45:17 +0200 (CEST) Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id A0CEF200D5; Thu, 25 Apr 2019 23:45:17 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Thu, 25 Apr 2019 23:45:17 +0200 Received: by anna.localdomain (Postfix, from userid 501) id C056E300896C59; Thu, 25 Apr 2019 23:45:16 +0200 (CEST) Date: Thu, 25 Apr 2019 23:45:16 +0200 From: Juergen Schoenwaelder To: Kent Watsen CC: Martin Bjorklund , , "netconf@ietf.org" Message-ID: <20190425214516.n2fi3bc3volpv5lr@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , Martin Bjorklund , wang.haiguang.shieldlab@huawei.com, "netconf@ietf.org" References: <0100016a554785f6-a0f918fc-5396-4410-8320-701f65abf6c0-000000@email.amazonses.com> <20190425.185116.1747028954255365462.mbj@tail-f.com> <0100016a559fd6c6-0deaad17-593f-434c-94b6-111ac0619a3c-000000@email.amazonses.com> <20190425.205039.1112892422143145313.mbj@tail-f.com> <0100016a5660266f-69525394-213b-4cc1-ae5c-89d8d93a6160-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <0100016a5660266f-69525394-213b-4cc1-ae5c-89d8d93a6160-000000@email.amazonses.com> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 21:45:24 -0000 On Thu, Apr 25, 2019 at 09:21:43PM +0000, Kent Watsen wrote: > > In the meanwhile, what's the stop-gap solution? - crypto-types > shouldn't be blocked on YANG Next... > What we have been doing so far is publishing identities / enumerations without having a common way for implementations to declare the subset they do support. This seems reasonable since once we add a common mechanism to report the subset actually implemented, we do not have to go back and revise the definitions of identities and enumerations. /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 Apr 26 07:25:51 2019 Return-Path: <0100016a5a09b22c-052a4155-dd9d-466d-a16f-9e84adfbc852-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7598512014B for ; Fri, 26 Apr 2019 07:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xN6s-ya7bnnA for ; Fri, 26 Apr 2019 07:25:47 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9496312004B for ; Fri, 26 Apr 2019 07:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556288746; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=PanmhyJlhsJK1PEccuBjc2a0oemcPPge0ucMHULtVjE=; b=VxWytMH0Vkw/tVeIKZ0gf/WfG0wbzTvzc9Y4y9ZSR9qxkBn2a6Yp24bur8S6350g HaJTWvzwOLTXTLi++yjq8DjEfhGMXq4cKZ+F00pAgxsE4OiRIVjiFOmxOYQWXhpyrmE 5O70UCvEZq+dlWTfWWHNd+nHncBvKKexK0D6Ars0= From: Kent Watsen Message-ID: <0100016a5a09b22c-052a4155-dd9d-466d-a16f-9e84adfbc852-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E5966A6B-C1D3-4AB3-8051-6B92283D7129" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 26 Apr 2019 14:25:46 +0000 In-Reply-To: <20190425214516.n2fi3bc3volpv5lr@anna.jacobs.jacobs-university.de> Cc: Martin Bjorklund , wang.haiguang.shieldlab@huawei.com, "netconf@ietf.org" To: Juergen Schoenwaelder References: <0100016a554785f6-a0f918fc-5396-4410-8320-701f65abf6c0-000000@email.amazonses.com> <20190425.185116.1747028954255365462.mbj@tail-f.com> <0100016a559fd6c6-0deaad17-593f-434c-94b6-111ac0619a3c-000000@email.amazonses.com> <20190425.205039.1112892422143145313.mbj@tail-f.com> <0100016a5660266f-69525394-213b-4cc1-ae5c-89d8d93a6160-000000@email.amazonses.com> <20190425214516.n2fi3bc3volpv5lr@anna.jacobs.jacobs-university.de> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.26-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 14:25:49 -0000 --Apple-Mail=_E5966A6B-C1D3-4AB3-8051-6B92283D7129 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 25, 2019, at 5:45 PM, Juergen Schoenwaelder = wrote: >=20 > On Thu, Apr 25, 2019 at 09:21:43PM +0000, Kent Watsen wrote: >>=20 >> In the meanwhile, what's the stop-gap solution? - crypto-types >> shouldn't be blocked on YANG Next... >>=20 >=20 > What we have been doing so far is publishing identities / enumerations > without having a common way for implementations to declare the subset > they do support. This seems reasonable since once we add a common > mechanism to report the subset actually implemented, we do not have to > go back and revise the definitions of identities and enumerations. Sounds right, with the clarification that crypto-types should have = identities for all (within reason) known algorithms, even if deprecated = or obsolete, and that for those algorithms that are deprecated or = obsolete, the identity's "status" statement should be set to = "deprecated" or "obsolete" accordingly. Haiguang, can you please point the i2nsf group to this thread? Thanks, Kent --Apple-Mail=_E5966A6B-C1D3-4AB3-8051-6B92283D7129 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 25, 2019, at 5:45 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On = Thu, Apr 25, 2019 at 09:21:43PM +0000, Kent Watsen wrote:

In the = meanwhile, what's the stop-gap solution?   - crypto-types
shouldn't be blocked on YANG Next...


What we have been doing so far is = publishing identities / enumerations
without having a = common way for implementations to declare the subset
they = do support. This seems reasonable since once we add a common
mechanism to report the subset actually implemented, we do = not have to
go back and revise the definitions of = identities and enumerations.

Sounds right, with the clarification that crypto-types should have identities for all = (within reason) known algorithms, even if deprecated or obsolete, and that for = those algorithms that are deprecated or obsolete, the identity's = "status" statement should be set to "deprecated" or "obsolete" = accordingly.

Haiguang, can you please point the i2nsf group to this = thread?

Thanks,
Kent

= --Apple-Mail=_E5966A6B-C1D3-4AB3-8051-6B92283D7129-- From nobody Sun Apr 28 01:31:28 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E153E12008A for ; Sun, 28 Apr 2019 01:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONT2abJK5MUI for ; Sun, 28 Apr 2019 01:31:24 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF070120006 for ; Sun, 28 Apr 2019 01:31:23 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id B2A55EF99623940A8E2F; Sun, 28 Apr 2019 09:31:21 +0100 (IST) Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 28 Apr 2019 09:31:21 +0100 Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Sun, 28 Apr 2019 09:31:21 +0100 Received: from SINEML705-CAH.china.huawei.com (10.223.161.55) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Sun, 28 Apr 2019 09:31:20 +0100 Received: from SINEML521-MBX.china.huawei.com ([169.254.1.224]) by SINEML705-CAH.china.huawei.com ([10.223.161.55]) with mapi id 14.03.0415.000; Sun, 28 Apr 2019 16:31:16 +0800 From: Wang Haiguang To: Kent Watsen , Juergen Schoenwaelder CC: Martin Bjorklund , "netconf@ietf.org" Thread-Topic: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types Thread-Index: AdT7E8hZAPIgEzoMT+CWvaCRHboBx///tkyAgACgJICAAAoVAIAAEN+AgAAQfICAACo1gIAABpQAgAEXiQCAA0bhxA== Date: Sun, 28 Apr 2019 08:31:16 +0000 Message-ID: <0AE05CBFB1A6A0468C8581DAE58A31309E3DD12B@SINEML521-MBX.china.huawei.com> References: <0100016a554785f6-a0f918fc-5396-4410-8320-701f65abf6c0-000000@email.amazonses.com> <20190425.185116.1747028954255365462.mbj@tail-f.com> <0100016a559fd6c6-0deaad17-593f-434c-94b6-111ac0619a3c-000000@email.amazonses.com> <20190425.205039.1112892422143145313.mbj@tail-f.com> <0100016a5660266f-69525394-213b-4cc1-ae5c-89d8d93a6160-000000@email.amazonses.com> <20190425214516.n2fi3bc3volpv5lr@anna.jacobs.jacobs-university.de>, <0100016a5a09b22c-052a4155-dd9d-466d-a16f-9e84adfbc852-000000@email.amazonses.com> In-Reply-To: <0100016a5a09b22c-052a4155-dd9d-466d-a16f-9e84adfbc852-000000@email.amazonses.com> Accept-Language: en-SG, en-US Content-Language: en-SG X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.46.157] Content-Type: multipart/alternative; boundary="_000_0AE05CBFB1A6A0468C8581DAE58A31309E3DD12BSINEML521MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2019 08:31:26 -0000 --_000_0AE05CBFB1A6A0468C8581DAE58A31309E3DD12BSINEML521MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Kent and all Sorry for the late reply due to time differences. I will post the link to i2nsf tonight and let them aware the discussion in = netconf. Best regards. Haiguang ________________________________ From: Kent Watsen [kent+ietf@watsen.net] Sent: Friday, 26 April, 2019 10:25:46 PM To: Juergen Schoenwaelder Cc: Martin Bjorklund; Wang Haiguang; netconf@ietf.org Subject: Re: [netconf] The maintenance of the algorithm identifiers in draf= t-ietf-crypto-types On Apr 25, 2019, at 5:45 PM, Juergen Schoenwaelder > wrote: On Thu, Apr 25, 2019 at 09:21:43PM +0000, Kent Watsen wrote: In the meanwhile, what's the stop-gap solution? - crypto-types shouldn't be blocked on YANG Next... What we have been doing so far is publishing identities / enumerations without having a common way for implementations to declare the subset they do support. This seems reasonable since once we add a common mechanism to report the subset actually implemented, we do not have to go back and revise the definitions of identities and enumerations. Sounds right, with the clarification that crypto-types should have identiti= es for all (within reason) known algorithms, even if deprecated or obsolete= , and that for those algorithms that are deprecated or obsolete, the identi= ty's "status" statement should be set to "deprecated" or "obsolete" accordi= ngly. Haiguang, can you please point the i2nsf group to this thread? Thanks, Kent --_000_0AE05CBFB1A6A0468C8581DAE58A31309E3DD12BSINEML521MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi, Kent and all

Sorry for the late reply due to time differences.

I will post the link to i2nsf tonight and let them aware the discussio= n in netconf. 

Best regards.

Haiguang 


From: Kent Watsen [kent+ietf@watsen.n= et]
Sent: Friday, 26 April, 2019 10:25:46 PM
To: Juergen Schoenwaelder
Cc: Martin Bjorklund; Wang Haiguang; netconf@ietf.org
Subject: Re: [netconf] The maintenance of the algorithm identifiers = in draft-ietf-crypto-types



On Apr 25, 2019, at 5:45 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de&= gt; wrote:

On Thu, Apr 25, 2019 at 09:21:43PM +0000, Kent Watsen w= rote:

In the meanwhile, what's the stop-gap solution?   - crypto-types<= br class=3D""> shouldn't be blocked on YANG Next...


What we have been doing so far is publishing identities / enumerations
without having a common way for implementations to declare the subset
they do support. This seems reasonable since once we add a common
mechanism to report the subset actually implemented, we do not have to
go back and revise the definitions of identities and enumerations.

Sounds right, with the clarification t= hat crypto-types should have identities for all (within reason) known algor= ithms, even if deprecated or obsolete, and that for those algorithms that are deprecated or obsolete, the identity's "status" statement should be set to "deprecated" or &q= uot;obsolete" accordingly.

Haiguang, can you please point the i2ns= f group to this thread?

Thanks,
Kent

--_000_0AE05CBFB1A6A0468C8581DAE58A31309E3DD12BSINEML521MBXchi_-- From nobody Sun Apr 28 17:02:37 2019 Return-Path: <0100016a66666e21-ee25fda4-4886-46e1-b4b4-b150b8412805-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C1F120131 for ; Sun, 28 Apr 2019 17:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnguPbk62kAK for ; Sun, 28 Apr 2019 17:02:33 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 714B9120122 for ; Sun, 28 Apr 2019 17:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556496150; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=00VinLpdXb7OlruNEW7/xjvQQUqz4PftdBvweRVkTm8=; b=F0mK0bibVG9iVHxWkV8cTawYs04ZPWHXDAu7WE+6vcNUwOqGG8Gd85CNuRwsjTla 0dzc/dz8pBJ2jN3NBfQStvb24ZGBixwHMp7QrK9z63fuNrmsrdZm70OfxuO9EvxzNxt jqJ4nVXJJoE4VUz6iciT/v+OpkSopPYDgh/oZ4mA= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_8076C19B-71AD-4747-B62B-2ED5EEBE2586" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-ID: <0100016a66666e21-ee25fda4-4886-46e1-b4b4-b150b8412805-000000@email.amazonses.com> Date: Mon, 29 Apr 2019 00:02:30 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.29-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] reverting back to feature statements with boolean expressions X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 00:02:36 -0000 --Apple-Mail=_8076C19B-71AD-4747-B62B-2ED5EEBE2586 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The netconf-client-server and restconf-client-server drafts define = top-level features ("initiate", "listen", and "call home"), under which = there are fine-grained if-feature statements (e.g. "ssh-listen", = tis-listen", ssh-call-home, tls-call-home, etc.). These can be seen in the following tree diagrams: netconf-client-server: - = https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-11#se= ction-3.1 = - = https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-11#se= ction-4.1 = restconf-client-server: - = https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-11#s= ection-2.1 = - = https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-11#s= ection-3.1 = This begs the question, why aren't these drafts using "if-feature" = statements with boolean expression, as this was the use case for adding = them to RFC 7950: https://tools.ietf.org/html/rfc7950#section-7.20.2.1 = . We originally had the boolean expressions, but reverted them because (I = think) tools (pyang, yanglint, etc.) didn't understand them. =20 I just switched the "if-feature" statements back to their original forms = using boolean expressions (i.e. if-feature "listen" ---> if-feature = "ssh-listen or tls-listen") and all the tooling seems to work. Thusly, I propose to make this change permanent. Unless there are any = objections raised, this change will be in the next published update. Kent // contributor --Apple-Mail=_8076C19B-71AD-4747-B62B-2ED5EEBE2586 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

The = netconf-client-server and restconf-client-server drafts define top-level = features ("initiate", "listen", and "call home"), under which there are = fine-grained if-feature statements (e.g. "ssh-listen", tis-listen", = ssh-call-home, tls-call-home, etc.).

These can be seen in the following tree = diagrams:

 = netconf-client-server:
    - https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-s= erver-11#section-3.1
    - https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-s= erver-11#section-4.1

  restconf-client-server:
    - https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-= server-11#section-2.1
    - https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-= server-11#section-3.1


This begs the question, = why aren't these drafts using "if-feature" statements with boolean = expression, as this was the use case for adding them to RFC = 7950: https://tools.ietf.org/html/rfc7950#section-7.20.2.1.
=

We originally had = the boolean expressions, but reverted them because (I think) tools = (pyang, yanglint, etc.) didn't understand them.  

I just switched the = "if-feature" statements back to their original forms using boolean = expressions (i.e. if-feature "listen"  --->  if-feature = "ssh-listen or tls-listen") and all the tooling seems to work.

Thusly, I propose to = make this change permanent.  Unless there are any objections = raised, this change will be in the next published update.

Kent // = contributor


= --Apple-Mail=_8076C19B-71AD-4747-B62B-2ED5EEBE2586-- From nobody Sun Apr 28 20:00:20 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5148120295; Sun, 28 Apr 2019 20:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGmeJKWRIDbl; Sun, 28 Apr 2019 20:00:11 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 8AFCD120294; Sun, 28 Apr 2019 20:00:10 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3T304G3025484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Apr 2019 23:00:05 -0400 Date: Sun, 28 Apr 2019 22:00:03 -0500 From: Benjamin Kaduk To: "Reshad Rahman (rrahman)" Cc: Aanchal Malhotra , "secdir@ietf.org" , "ietf@ietf.org" , "draft-ietf-netconf-restconf-notif.all@ietf.org" , "netconf@ietf.org" Message-ID: <20190429030003.GJ60332@kduck.mit.edu> References: <155501965074.14152.2835369201856309773@ietfa.amsl.com> <20190420035612.GR51586@kduck.mit.edu> <7820A8E4-692B-43D2-9611-437CC440EBC7@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7820A8E4-692B-43D2-9611-437CC440EBC7@cisco.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [netconf] Secdir last call review of draft-ietf-netconf-restconf-notif-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 03:00:13 -0000 On Wed, Apr 24, 2019 at 05:53:02PM +0000, Reshad Rahman (rrahman) wrote: > On 2019-04-19, 11:56 PM, "Benjamin Kaduk" wrote: > > On Fri, Apr 12, 2019 at 09:29:35PM +0000, Reshad Rahman (rrahman) wrote: > > Hi Aanchal, > > > > Thanks for the review. Please see inline. > > > > On 2019-04-11, 5:54 PM, "netconf on behalf of Aanchal Malhotra via Datatracker" wrote: > > > > Reviewer: Aanchal Malhotra > > Review result: Ready > > > > The document is very clear and concise. I just have one minor clarification question. > > Section 3.4 Page 9 that says the following: > > "In addition to any required ........SHOULD only be allowed......". > > > > Is there a reason for using SHOULD instead of MUST? > > > > There may be reasons why an implementation decides not to enforce this restriction. Going by RFC2119 definitions, this is why we chose SHOULD instead of MUST. > > If you have some reasons in mind, it is often helpful to list them as > examples of when the recommended behavior would not be followed. > > What we had in mind is a "super-user" who could be given access to subscriptions of other users. Is this obvious or should I can add text to that effect at the end the bullet below? Something along the lines of "For example, a RESTCONF username with the required administrative permissions could be allowed to invoke RPCs modify-subscription, resync-subscription and delete-subscription on a subscription which was created by another username.". > > o In addition to any required access permissions (e.g., NACM), RPCs > modify-subscription, resync-subscription and delete-subscription > SHOULD only be allowed by the same RESTCONF username [RFC8040] > which invoked establish-subscription. I think it might help to have such text, though I would suggest a slightly pithier "Such a restriction generally serves to preserve users' privacy, but exceptions might be made for administrators that may need to modify or delete other users' subscriptions." Thanks, Ben From nobody Mon Apr 29 05:24:53 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A1912012B for ; Mon, 29 Apr 2019 05:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfHz3th_YoYt for ; Mon, 29 Apr 2019 05:24:49 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on062f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C52A12012A for ; Mon, 29 Apr 2019 05:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SSJSbXR0zj9lEaRTX8WNlkPRP3MOLjvpaEL/oJuFbRQ=; b=gzYzOJpKUjGXtVvHfUt2iHZ48y0x6MDOCzbssUkrcE48ByX8v5ifc8WnQ9rKCZa0+Mc6xKd3fWihxw3inVSMtT9ad/vSrGzkac4h55OnIRsRbjnoRicEvAWOwwcuKy/TL8JiHcjzaEojSMPtsnNIEhgH+neY5d+dIuVcDiKEX9A= Received: from VI1PR07MB4735.eurprd07.prod.outlook.com (20.177.57.146) by VI1PR07MB5312.eurprd07.prod.outlook.com (20.178.11.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.5; Mon, 29 Apr 2019 12:24:46 +0000 Received: from VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::dc72:dfff:beb3:3b47]) by VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::dc72:dfff:beb3:3b47%7]) with mapi id 15.20.1856.008; Mon, 29 Apr 2019 12:24:46 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Kov=E1cs?= To: Kent Watsen , Juergen Schoenwaelder CC: "netconf@ietf.org" Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpALufsOAAAVM5oADthG5oAAICCMAAAQfJ4AABQvugADqJOIA Date: Mon, 29 Apr 2019 12:24:45 +0000 Message-ID: References: <20190404164929.fsfga7s4izn7ucx5@anna.jacobs.jacobs-university.de> <20190404.194623.1178346313710501110.mbj@tail-f.com> <01dd01d4eb9c$b9a04160$4001a8c0@gateway.2wire.net> <20190405.142201.707949273328784535.mbj@tail-f.com> <413d5725-9c27-e50b-2622-1b0e2f35cdb1@ericsson.com> <0100016a5019d7f9-7f737c63-d07c-4c7f-b12e-c5b19d50eeaf-000000@email.amazonses.com> <20190424180513.gtxmreicd7iydrpr@anna.jacobs.jacobs-university.de> <0100016a510a3038-7671e146-e23f-4bc9-9f93-ea2314b5d4e7-000000@email.amazonses.com> In-Reply-To: <0100016a510a3038-7671e146-e23f-4bc9-9f93-ea2314b5d4e7-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 659cd67f-827c-4f26-6097-08d6cc9daa75 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB5312; x-ms-traffictypediagnostic: VI1PR07MB5312: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0022134A87 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(366004)(136003)(396003)(13464003)(189003)(199004)(97736004)(71190400001)(71200400001)(52536014)(64756008)(66556008)(66476007)(76176011)(316002)(4326008)(66446008)(7696005)(76116006)(6436002)(66946007)(5660300002)(73956011)(68736007)(7736002)(53936002)(99286004)(66574012)(45776006)(305945005)(74316002)(25786009)(9686003)(14454004)(229853002)(93886005)(486006)(86362001)(186003)(66066001)(26005)(256004)(14444005)(53546011)(476003)(102836004)(81156014)(8676002)(11346002)(446003)(81166006)(8936002)(6506007)(6246003)(478600001)(55016002)(110136005)(2906002)(33656002)(6116002)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5312; H:VI1PR07MB4735.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Rnp54ev/pJzJ5wzn4QVZR/iOAJM6EdjHnn4T0X/LxPQ5o6n9PzhgHuhb/17QSS9/3q8G4+jxlaA409GA2z1DpcxErn7Sinhafn0h05N3GUqMy7hwNf6dicIPvPVzUupvTvPGqcCXZxeWWP7I4FhqgD+VbEg3E0A0hwgeIUVAxqr63VLlEZ+r3Y4P0TJ3ik3opkaC+yqFi+7CltxGdpUAkPH0Ls/sFTP9bwVnyFI/koNiyvOoXfKFPlqqwpO3PIVF5waGK9E9r+bWOCFYWzNx8CQX1ecALmiL2MAYjUDTuYUPNNA+g/egM6HaIYyyA7Id/pJxjDLmlAh8xQfaAXoJHAgAjnZXT2hNdL7BMOmXqRJcu2oWL5hsD26RfNMH/IafCRLvWB09jla7zfoVcAm/cgedWKuJqNIHlr+rAztk0sY= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 659cd67f-827c-4f26-6097-08d6cc9daa75 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2019 12:24:45.9985 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5312 Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 12:24:53 -0000 Hi, Kent, I'm fine with your proposals. Regarding subsequent calls to the actions, I agree the safe choice would be= to deny them; otherwise, one could run into invalid key pairs (where a cer= tificate was already configured) and authentication failures with network p= eers (especially in SSH-key-based-authentication case).=20 Br, Balazs > -----Original Message----- > From: Kent Watsen > Sent: Wednesday, April 24, 2019 10:30 PM > To: Juergen Schoenwaelder > Cc: Bal=E1zs Kov=E1cs ; netconf@ietf.org > Subject: Re: [netconf] ietf crypto types - permanently hidden >=20 > Hi Juergen, >=20 >=20 > > Perhaps this should say 'implementation specific' instead 'application > > specific'. >=20 > Changed in my local copy. >=20 >=20 > >> My recommendation is to modify the "generate/install-hidden-key" > (renamed to just "generate/install-key") actions to have a flag indicatin= g if > the key should be "permanently hidden" (perhaps by using a TPM) or not, i= n > which case configuration is created, same as if the client had used config>, but without needing to touch the key. > > > > I agree that having a flag to control the behavior is useful and I > > think there should be explicit text how the action fails in case the > > requested action cannot be performed. > > > > I am not sure I understand install-hidden-key. The description says: > > > > "Requests the device to load the specified values into > > a hidden key. The resulting asymmetric key values are > > considered operational state and hence present only in > > ."; > > > > So what is the persistence model of this? Does a key installed with > > install-hidden-key survive reboots? If so, can I delete somehow such a > > hidden key? (Is the answer that this key is tied to the lifetime of > > the list element indirectly using this grouping?) Does invoking > > install-hidden-key twice cause the first installed key to be > > overwritten? Can the install-hidden-key action fail in any way? > > > > This leads to related questions for generate-hidden-key: Does invoking > > this action twice cause an existing key to be overwritten? Can I > > explicitely delete a generated hidden key? Does deleting the list item > > that directly or indirectly uses this grouping delete a hidden key? >=20 > [Disclaimer: the below reflect my understanding of how the current model > works, and does not necessarily reflect if we were to flip things around = by > letting the actions generate configuration.] >=20 > The expectation is that the "permanently hidden" keys would persist, > presumably with origin=3Dsystem. >=20 > In the YANG, the "permanently-hidden" enum only appears in the > "asymmetric-key-pair-grouping" grouping. Consuming data models are > expected to "use" this grouping under a "config true" node. This groupin= g's > description statement is noteworthy: >=20 > grouping asymmetric-key-pair-grouping { > description > "A private/public key pair. >=20 > The 'algorithm', 'public-key', and 'private-key' nodes are > not mandatory because they MAY be defined in . > Implementations SHOULD assert that these values are either > configured or that they exist in ."; > ... > } >=20 > Thusly it is expected that the client will create the parent node (e.g., = via > ) and then invoke either the generate or install hidden key > action. Presumably, the lifetime of the permanently hidden key would be > tied to the lifetime of its parent. >=20 > Regarding what happens when the actions are invoked a second time, it's > not specified. One choice, perhaps the safe choice, would be to deny > subsequent attempts, forcing the client to create a new parent node inste= ad. > If the parent node is in a list, such as in the keystore, then the second= key > could be created, with certificates bound to it, before mapping reference= to > the old-key to the new-key. However, if the key is not in a list, such a= s when > using a "local-definition", then in in-place migration, along with servic= e > disruption, would be required. >=20 > Of course, one has to ask how often/likely is it that a client wants to > regenerate the private key. Presumably it would only be due to the conce= rn > that the key had been compromised (which shouldn't happen if > "permanently hidden") or, perhaps, due to a proactive key-rotation policy= , > thinking (misguided, I believe, proven false now) that the private key's > entropy expires over time. Regardless, the point is that it seems to be = an > action that would seldomly occur and, when/if it does, the effort to crea= te > another parent node (in keystore or a local-definition) might not be a bi= g > deal. >=20 > PS: words such as "expectation" and "presumably" are used above to > indicate a likely need for the text to be more explicit. >=20 > Kent // contributor >=20 From nobody Mon Apr 29 06:12:52 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B991202FF; Mon, 29 Apr 2019 06:12:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-netconf-yang-push@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <155654356221.15895.6935060528947597341.idtracker@ietfa.amsl.com> Date: Mon, 29 Apr 2019 06:12:42 -0700 Archived-At: Subject: [netconf] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-netconf-yang-push-22=3A_=28with_COMMENT=29?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 13:12:42 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-netconf-yang-push-22: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Getting a streaming telemetry for changes in datastore appears quite useful. Please note that I did not review in depth after the section 4. Comments -------- C1) Out of curiosity, it is surprising for a netconf wg document to have 7 errors indicated by the YANG validator. Are they real errors or is the `pyang` validator incorrect or missing references? C2) 7 authors... the limit is usually 5 authors max. Can you justify? C3) section 2. It should be RFC 8174 without citing RFC 2119. C4) section 3.7, why not forcing a resynch (and a patch-id of 0) rather than simply rolling explicitly the patch-id to 0. The latter seems to me as prone to synchronization errors. Nits ---- N1) unsure why all Cisco Systems authors are not grouped together N2) "Xpath": should be described (or having a reference) before first use in section 3.6 N3) a couple of "yang" in lowercase while I believe "YANG" is always written in uppercase From nobody Mon Apr 29 06:21:09 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEE81200EC; Mon, 29 Apr 2019 06:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=iaqVj3vH; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=aty5f4bw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wvq8vemzup7; Mon, 29 Apr 2019 06:20:59 -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 8C5AD1200B4; Mon, 29 Apr 2019 06:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2878; q=dns/txt; s=iport; t=1556544059; x=1557753659; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1ZtQxQoFaQ+Q5n7HrN9a+IC+GkmhVbUk/LD4MKqnzrY=; b=iaqVj3vHVFOcYrF7k0BoEJ4RvRNm2yqbTYet7b13lIJ0GXcKSEDAuLpC yaQbPWcmM7gZG4bSEMIl7eiWooUUFTvmcg/Wjb8RIsAceLp460rjcDzuL vM4lw/r4iWQVTaZjZOGC0Tm/TSir23OicI6ulEvJiUqnvABgwSH01mu8K A=; IronPort-PHdr: =?us-ascii?q?9a23=3AKsc+CBaOz1LcsU0oXLDcKDX/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gebRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavncT08F8dPfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BeBwDE+MZc/5RdJa1mH4F4gT5QA2h?= =?us-ascii?q?VIAQLKIQQg0cDjwyCMpdHgS4UgRADVA4BASMKhEACF4YbIzUIDgEDAQEEAQE?= =?us-ascii?q?CAQJtHAyFSwIEEhERDAEBNwEPAgEIGgImAgICMBUFCwIEDgUigwABgWkDHAE?= =?us-ascii?q?CDKImAoE1iF9xgS+CeQEBBYFGQYJyGIIOAwaBCyeLSheBQD+BOAwTgkw+gmE?= =?us-ascii?q?CAQIBgSoBDAYBNoJzMoImiwWCN5k/CQKCCYYRiFmDSRuCDYY0jGaDCY9Fjgw?= =?us-ascii?q?CBAIEBQIOAQEFgVABNmVYEQhwFWUBgkGCGxcUgziFFIU/cgGBKJBAAQ0XB4I?= =?us-ascii?q?lAQE?= X-IronPort-AV: E=Sophos;i="5.60,409,1549929600"; d="scan'208";a="269682860" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Apr 2019 13:20:58 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x3TDKw4u026283 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Apr 2019 13:20:58 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 29 Apr 2019 08:20:57 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 29 Apr 2019 09:20:56 -0400 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 29 Apr 2019 08:20:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1ZtQxQoFaQ+Q5n7HrN9a+IC+GkmhVbUk/LD4MKqnzrY=; b=aty5f4bwBKBSdlScRIt9FrJ42b2PvOCloX8qF7s5UlXH3ubIcJSihN+/5pvmsBYzBiv1xyF+ieYXSEflpDKqjJxCj6v0VHP6g70shdRGbzag11XnQpFSsRwDjblu0kNOkQX8QuzVoeutlVjQY/1nRO6/jxkyRZHADJEzs7cgxLk= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB3823.namprd11.prod.outlook.com (20.178.254.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.14; Mon, 29 Apr 2019 13:20:55 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::3822:32af:5c31:b48f]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::3822:32af:5c31:b48f%3]) with mapi id 15.20.1835.010; Mon, 29 Apr 2019 13:20:55 +0000 From: "Eric Vyncke (evyncke)" To: The IESG CC: "netconf@ietf.org" , "draft-ietf-netconf-yang-push@ietf.org" , "kent+ietf@watsen.net" , "netconf-chairs@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtbmV0?= =?utf-8?Q?conf-yang-push-22:_(with_COMMENT)?= Thread-Index: AQHU/o1ChHc7Q7eNKUqqXSLc5/bp5KZTMGcA Date: Mon, 29 Apr 2019 13:20:54 +0000 Message-ID: References: <155654356221.15895.6935060528947597341.idtracker@ietfa.amsl.com> In-Reply-To: <155654356221.15895.6935060528947597341.idtracker@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.18.0.190414 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:44f0:1252:e8f5:d737:aace:ff2b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: efae2c51-3089-4d69-dbf5-08d6cca5828a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR11MB3823; x-ms-traffictypediagnostic: MN2PR11MB3823: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0022134A87 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(376002)(39860400002)(136003)(346002)(189003)(199004)(91956017)(66574012)(6306002)(54906003)(46003)(966005)(8936002)(76116006)(53936002)(14454004)(97736004)(102836004)(224303003)(4326008)(58126008)(68736007)(25786009)(6512007)(73956011)(316002)(478600001)(486006)(82746002)(6116002)(36756003)(229853002)(83716004)(66946007)(71200400001)(6486002)(2616005)(6246003)(14444005)(446003)(186003)(476003)(7736002)(71190400001)(305945005)(2906002)(256004)(5660300002)(76176011)(6506007)(6436002)(11346002)(81166006)(33656002)(81156014)(86362001)(6916009)(66476007)(66556008)(99286004)(64756008)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3823; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5FJBz4YdLqP/dDdBv+7DeQ3057gAAH89wIIbjooolAB1eIaZGP+b9Y9XZemY7saCytzmUaMXODRkH6ONMCZtfu/9/3L242kkBVxwGdn2epVulyMgiX6YcEbYKX7mx0LtYxg2BuFKao0ZEOpgvnYno4ZF3XWCK2TKiaQNLJFAAbWCqK3e0ZlChSOKcfa/qujcd8boBC6p9LEjRYIxRpy6jcuWQldDQSegxvG4/1AZ6kLPyaR42BdHLshN99PLyZQ8iQe0jlD+xFIcFYvaAuH3V+ppDaufba6UEVvyLNgH/AKnNn66VZR2AdQ5Nup2yyfRCoKYYXCVnUyJDNAu1kBuX+nUd8pG5Vf9b24R10HSVog97KztjcfhbiisQlpx1LR7uxiU3BlKKEhmdmloMXoDZ60LaP9flS0r/a/h2SeoMgw= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: efae2c51-3089-4d69-dbf5-08d6cca5828a X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2019 13:20:54.9441 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3823 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.23, xch-rcd-013.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [netconf] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-netconf-yang-push-22=3A_=28with_COMMENT=29?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 13:21:01 -0000 UGxlYXNlIGlnbm9yZSBteSBjb21tZW50IEMzLCBteSBiYWQuLi4NCg0KLcOpcmljDQoNCu+7v09u IDI5LzA0LzIwMTksIDE1OjEyLCAiaWVzZyBvbiBiZWhhbGYgb2Ygw4lyaWMgVnluY2tlIHZpYSBE YXRhdHJhY2tlciIgPGllc2ctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygbm9yZXBseUBp ZXRmLm9yZz4gd3JvdGU6DQoNCiAgICDDiXJpYyBWeW5ja2UgaGFzIGVudGVyZWQgdGhlIGZvbGxv d2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQogICAgZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVz aC0yMjogTm8gT2JqZWN0aW9uDQogICAgDQogICAgV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2Vl cCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQogICAgZW1haWwgYWRk cmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0 IHRoaXMNCiAgICBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCiAgICANCiAgICAN CiAgICBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQv ZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQogICAgZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVT RyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCiAgICANCiAgICANCiAgICBUaGUgZG9j dW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhl cmU6DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRj b25mLXlhbmctcHVzaC8NCiAgICANCiAgICANCiAgICANCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAg Q09NTUVOVDoNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgDQogICAgR2V0dGluZyBhIHN0cmVhbWlu ZyB0ZWxlbWV0cnkgZm9yIGNoYW5nZXMgaW4gZGF0YXN0b3JlIGFwcGVhcnMgcXVpdGUgdXNlZnVs Lg0KICAgIA0KICAgIFBsZWFzZSBub3RlIHRoYXQgSSBkaWQgbm90IHJldmlldyBpbiBkZXB0aCBh ZnRlciB0aGUgc2VjdGlvbiA0Lg0KICAgIA0KICAgIENvbW1lbnRzDQogICAgLS0tLS0tLS0NCiAg ICANCiAgICBDMSkgT3V0IG9mIGN1cmlvc2l0eSwgaXQgaXMgc3VycHJpc2luZyBmb3IgYSBuZXRj b25mIHdnIGRvY3VtZW50IHRvIGhhdmUgNw0KICAgIGVycm9ycyBpbmRpY2F0ZWQgYnkgdGhlIFlB TkcgdmFsaWRhdG9yLiBBcmUgdGhleSByZWFsIGVycm9ycyBvciBpcyB0aGUgYHB5YW5nYA0KICAg IHZhbGlkYXRvciBpbmNvcnJlY3Qgb3IgbWlzc2luZyByZWZlcmVuY2VzPw0KICAgIA0KICAgIEMy KSA3IGF1dGhvcnMuLi4gdGhlIGxpbWl0IGlzIHVzdWFsbHkgNSBhdXRob3JzIG1heC4gQ2FuIHlv dSBqdXN0aWZ5Pw0KICAgIA0KICAgIEMzKSBzZWN0aW9uIDIuIEl0IHNob3VsZCBiZSBSRkMgODE3 NCB3aXRob3V0IGNpdGluZyBSRkMgMjExOS4NCiAgICANCiAgICBDNCkgc2VjdGlvbiAzLjcsIHdo eSBub3QgZm9yY2luZyBhIHJlc3luY2ggKGFuZCBhIHBhdGNoLWlkIG9mIDApIHJhdGhlciB0aGFu DQogICAgc2ltcGx5IHJvbGxpbmcgZXhwbGljaXRseSB0aGUgcGF0Y2gtaWQgdG8gMC4gVGhlIGxh dHRlciBzZWVtcyB0byBtZSBhcyBwcm9uZSB0bw0KICAgIHN5bmNocm9uaXphdGlvbiBlcnJvcnMu DQogICAgDQogICAgTml0cw0KICAgIC0tLS0NCiAgICANCiAgICBOMSkgdW5zdXJlIHdoeSBhbGwg Q2lzY28gU3lzdGVtcyBhdXRob3JzIGFyZSBub3QgZ3JvdXBlZCB0b2dldGhlcg0KICAgIA0KICAg IE4yKSAiWHBhdGgiOiBzaG91bGQgYmUgZGVzY3JpYmVkIChvciBoYXZpbmcgYSByZWZlcmVuY2Up IGJlZm9yZSBmaXJzdCB1c2UgaW4NCiAgICBzZWN0aW9uIDMuNg0KICAgIA0KICAgIE4zKSBhIGNv dXBsZSBvZiAieWFuZyIgaW4gbG93ZXJjYXNlIHdoaWxlIEkgYmVsaWV2ZSAiWUFORyIgaXMgYWx3 YXlzIHdyaXR0ZW4gaW4NCiAgICB1cHBlcmNhc2UNCiAgICANCiAgICANCiAgICANCg0K From nobody Mon Apr 29 06:51:11 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 835C612031D; Mon, 29 Apr 2019 06:51:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-netconf-subscribed-notifications@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <155654586253.15817.17779514484895935501.idtracker@ietfa.amsl.com> Date: Mon, 29 Apr 2019 06:51:02 -0700 Archived-At: Subject: [netconf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-netconf-subscribed-notifications-23=3A_=28with_COMMENT?= =?utf-8?q?=29?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 13:51:03 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-netconf-subscribed-notifications-23: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) Sec 2.3: “Where TCP is used, a publisher which supports the "dscp" feature SHOULD ensure that a subscription's notification messages are returned within a single TCP transport session where all traffic shares the subscription's "dscp" leaf value.“ This should probably be generalised to “If a connection-oriented protocol is used, …”, however, I’m not sure I understand the sentence correctly. It is no problem to have multiple TCP session using the same DSCP value, however, what should be avoided is using different DCSP values within the same TCP connection. Can you please clarify what this sentence is supposed to say? 2) Also sec 2.3: “For the "weighting" parameter, when concurrently dequeuing notification messages from multiple subscriptions to a receiver, the publisher MUST allocate bandwidth to each subscription proportionally to the weights assigned to those subscriptions.” I’m also wondering about this sentence. Should this really be a MUST? I can assume that there could also be cases where there is a local policy to prioritise some notification. And do you really mean bandwidth (which would mean taking the message size into account), or would it make sense to leave the details to the exact implementation of the publisher and maybe talk just about “resources” instead? 3) Sec 1.3 says “ the loss of the transport session will result in the immediate termination of any associated dynamic subscriptions.” However, there is the following text in section 2.4.5: “The "kill-subscription" operation permits an operator to end a dynamic subscription which is not associated with the transport session used for the RPC.” If the subscription is anyway immediately terminated when the transport session is lost, why is the kill-subscription operation still needed? 4) Sec 2.5: Please expand VRF. 5) Figure 8: I would recommend to call the second “evaluate” event “re-evaluate” instead. From nobody Mon Apr 29 09:00:06 2019 Return-Path: <0100016a69d2e950-218c4aa5-2d10-405f-b1ee-6396dda0d3c6-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25531203C0 for ; Mon, 29 Apr 2019 09:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PBNnHaV-vqj for ; Mon, 29 Apr 2019 09:00:00 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8FE1203EC for ; Mon, 29 Apr 2019 08:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556553591; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=a8XofmJE9HVY5ZYBsCFgNH++pGHHrvkEkrfGQhIMjxI=; b=Mg8AXu54NHAg4sWKj5qHMDCdCb0bi2O1/W7/YK6U2xK29/qroand9Q0Aag6BgDbj xy/6MB89jfh9e1HJBMjZNjjvBgXFXGt8PXAe7kL4Iqg9w3+9joNlA8YaS7SNxs9vm04 Wv0JEZKNmBthGmrQ0b7VSmORCXr5qMXja0vYSELw= From: Kent Watsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-ID: <0100016a69d2e950-218c4aa5-2d10-405f-b1ee-6396dda0d3c6-000000@email.amazonses.com> Date: Mon, 29 Apr 2019 15:59:51 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.29-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] client authentication in the ietf-[ssh/tls/http]-server models X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 16:00:04 -0000 The ietf-ssh/tls/http-server models have, or should have, to some extent = or another, configuration for client authentication, but there appears = to be a fine line between configuring the kind of authentication needed = versus configuring to perform the authentication itself. To clarify: 1) The SSH protocol requires client authentication and itself prompts = for a username. Additionally the SSH server needs to be configured as = to what kinds of client auth it supports (passwords, rsa-key, client = certs per RFC 6187, etc.). 2) The TLS protocol does not require client authentication, but has a = configurable option for if the TLS server requests the TLS client to = send a client certificate. When client certificates are provided, there = is a further distinction between authenticating the certificate versus = extracting an identity from the certificate. 3) The HTTP protocol does not require authentication but, when it does, = the authentication mechanism resolves to a username. 4) NETCONF-over-SSH inherits SSH's guarantee for username extraction. = NETCONF-over-TLS needs to configure the TLS-layer to prompt for the = client certificate and have configuration for how to extract a username = from the certificate (i.e., cert-maps). 5) RESTCONF is only HTTP-over-TLS, but leaves it open as to if client = authentication occurs at the TLS or HTTP (or both) layers. If client = auth occurs at the TLS layer, there needs to be configuration for how to = extract a username from the certificate (i.e., cert-maps). In general (and exhibited by RFC 7317's "users" model), there is a = desire to colocate the client auth credentials within the "client" = nodes, outside of the "transport" tree. For instance, suppose a hypothetical app has two RESTCONF interfaces; a = northbound interface for "users" and a southbound interface for = "devices". At a very high-level, the app's model looks like this: +-- transport | +-- restconf-server-config | +-- listen | +-- endpoint | +-- ... (for northbound interface) | +-- endpoint | +-- ... (for southbound interface) +-- users | +-- user | +-- name | +-- http-auth | +-- basic-auth-password +-- devices +-- device +-- name +-- tls-auth | +-- trust-anchor-certificate | +-- cert-map +-- http-auth +-- basic-auth-password Not that, in the above tree diagram, having a trust-anchor-certificate = and cert-map configured per-device is very flexible, but likely overkill = for most circumstances. In trying to square all of the above, I believe that the = "client-authentication" nodes in the various -server models = need to be reworked. My idea is to add a combination of "presence" and = "choice" node indicating if client authentication 1) is prompted for at = all, 2) is required or optional, 3) is locally or externally defined, = and 4) if local, the configuration necessary to perform the local = configuration. Whilst a fairly isolated problem (client auth in just the "server" = models), it is still a pretty complicated edit and difficult to = describe. My idea is to make the edit and then publish an update to the = drafts so it can be seen. If folks don't like it, we can roll it back. = That said, given that I've been staring at this for a few days now, my = guess/hope is that folks will see it as "better" and we can fine-tune = tweak it from there. An updated suite of drafts will be posted this week! (These updates = will also address the various other issues raised on list recently). Kent // contributor From nobody Mon Apr 29 09:17:56 2019 Return-Path: <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F45120168 for ; Mon, 29 Apr 2019 09:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuEL1aHAogIh for ; Mon, 29 Apr 2019 09:17:52 -0700 (PDT) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50E612032A for ; Mon, 29 Apr 2019 09:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556554671; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=a0C1nJ42ohP9FEL3z4FKnHYYnEKlLZcjvlak9Dv9ZkY=; b=hBp8QPnnCaQ3XHCuIVqWx6XU1v/6jcE1CUs0+PAz4Fo5CA0/5qf6/F7eAcEQwd+C iKG+nJLTLBBIwY5nI9fSOepE9p4UNs7/tYAUKY3CygLAL49aEa8dSAueqi7C5NMuiwc kC8RUB4wSehgRL1AtMlAUFlKztRNIoj+97fgCwAg= From: Kent Watsen Message-ID: <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_337CEA86-1976-4F0E-BADD-0964C68E94A8" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 29 Apr 2019 16:17:51 +0000 In-Reply-To: Cc: Juergen Schoenwaelder , "netconf@ietf.org" To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= References: <20190404164929.fsfga7s4izn7ucx5@anna.jacobs.jacobs-university.de> <20190404.194623.1178346313710501110.mbj@tail-f.com> <01dd01d4eb9c$b9a04160$4001a8c0@gateway.2wire.net> <20190405.142201.707949273328784535.mbj@tail-f.com> <413d5725-9c27-e50b-2622-1b0e2f35cdb1@ericsson.com> <0100016a5019d7f9-7f737c63-d07c-4c7f-b12e-c5b19d50eeaf-000000@email.amazonses.com> <20190424180513.gtxmreicd7iydrpr@anna.jacobs.jacobs-university.de> <0100016a510a3038-7671e146-e23f-4bc9-9f93-ea2314b5d4e7-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.29-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 16:17:54 -0000 --Apple-Mail=_337CEA86-1976-4F0E-BADD-0964C68E94A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Okay, I've added the following text into the generate/install-hidden-key = descriptions: OLD: The resulting asymmetric key values are considered operational state and hence present only in ."; NEW: The resulting asymmetric key values are considered operational state and hence present only in and bound to the lifetime of the parent 'config true' node. Subsequent invokaions of this or the '-hidden-key' action are denied."; where is the name of the other action (generate vs. = install). Kent > On Apr 29, 2019, at 8:24 AM, Bal=C3=A1zs Kov=C3=A1cs = wrote: >=20 > Hi, >=20 > Kent, I'm fine with your proposals. >=20 > Regarding subsequent calls to the actions, I agree the safe choice = would be to deny them; otherwise, one could run into invalid key pairs = (where a certificate was already configured) and authentication failures = with network peers (especially in SSH-key-based-authentication case).=20 >=20 > Br, > Balazs >=20 >> -----Original Message----- >> From: Kent Watsen >> Sent: Wednesday, April 24, 2019 10:30 PM >> To: Juergen Schoenwaelder >> Cc: Bal=C3=A1zs Kov=C3=A1cs ; = netconf@ietf.org >> Subject: Re: [netconf] ietf crypto types - permanently hidden >>=20 >> Hi Juergen, >>=20 >>=20 >>> Perhaps this should say 'implementation specific' instead = 'application >>> specific'. >>=20 >> Changed in my local copy. >>=20 >>=20 >>>> My recommendation is to modify the "generate/install-hidden-key" >> (renamed to just "generate/install-key") actions to have a flag = indicating if >> the key should be "permanently hidden" (perhaps by using a TPM) or = not, in >> which case configuration is created, same as if the client had used = > config>, but without needing to touch the key. >>>=20 >>> I agree that having a flag to control the behavior is useful and I >>> think there should be explicit text how the action fails in case the >>> requested action cannot be performed. >>>=20 >>> I am not sure I understand install-hidden-key. The description says: >>>=20 >>> "Requests the device to load the specified values into >>> a hidden key. The resulting asymmetric key values are >>> considered operational state and hence present only in >>> ."; >>>=20 >>> So what is the persistence model of this? Does a key installed with >>> install-hidden-key survive reboots? If so, can I delete somehow such = a >>> hidden key? (Is the answer that this key is tied to the lifetime of >>> the list element indirectly using this grouping?) Does invoking >>> install-hidden-key twice cause the first installed key to be >>> overwritten? Can the install-hidden-key action fail in any way? >>>=20 >>> This leads to related questions for generate-hidden-key: Does = invoking >>> this action twice cause an existing key to be overwritten? Can I >>> explicitely delete a generated hidden key? Does deleting the list = item >>> that directly or indirectly uses this grouping delete a hidden key? >>=20 >> [Disclaimer: the below reflect my understanding of how the current = model >> works, and does not necessarily reflect if we were to flip things = around by >> letting the actions generate configuration.] >>=20 >> The expectation is that the "permanently hidden" keys would persist, >> presumably with origin=3Dsystem. >>=20 >> In the YANG, the "permanently-hidden" enum only appears in the >> "asymmetric-key-pair-grouping" grouping. Consuming data models are >> expected to "use" this grouping under a "config true" node. This = grouping's >> description statement is noteworthy: >>=20 >> grouping asymmetric-key-pair-grouping { >> description >> "A private/public key pair. >>=20 >> The 'algorithm', 'public-key', and 'private-key' nodes are >> not mandatory because they MAY be defined in . >> Implementations SHOULD assert that these values are either >> configured or that they exist in ."; >> ... >> } >>=20 >> Thusly it is expected that the client will create the parent node = (e.g., via >> ) and then invoke either the generate or install hidden = key >> action. Presumably, the lifetime of the permanently hidden key would = be >> tied to the lifetime of its parent. >>=20 >> Regarding what happens when the actions are invoked a second time, = it's >> not specified. One choice, perhaps the safe choice, would be to deny >> subsequent attempts, forcing the client to create a new parent node = instead. >> If the parent node is in a list, such as in the keystore, then the = second key >> could be created, with certificates bound to it, before mapping = reference to >> the old-key to the new-key. However, if the key is not in a list, = such as when >> using a "local-definition", then in in-place migration, along with = service >> disruption, would be required. >>=20 >> Of course, one has to ask how often/likely is it that a client wants = to >> regenerate the private key. Presumably it would only be due to the = concern >> that the key had been compromised (which shouldn't happen if >> "permanently hidden") or, perhaps, due to a proactive key-rotation = policy, >> thinking (misguided, I believe, proven false now) that the private = key's >> entropy expires over time. Regardless, the point is that it seems to = be an >> action that would seldomly occur and, when/if it does, the effort to = create >> another parent node (in keystore or a local-definition) might not be = a big >> deal. >>=20 >> PS: words such as "expectation" and "presumably" are used above to >> indicate a likely need for the text to be more explicit. >>=20 >> Kent // contributor >>=20 >=20 --Apple-Mail=_337CEA86-1976-4F0E-BADD-0964C68E94A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Okay,= I've added the following text into the generate/install-hidden-key = descriptions:

OLD:
        =  The resulting asymmetric key values are
  =        considered operational state and hence = present only in
        =  <operational>.";

NEW:
    =      The resulting asymmetric key values are
         considered operational = state and hence present only in
      =    <operational> and bound to the lifetime of the
         parent 'config true' = node.  Subsequent invokaions of
    =      this or the '<other>-hidden-key' action = are denied.";

  =   where <other> is the name of the other action (generate vs. = install).


Kent


On Apr = 29, 2019, at 8:24 AM, Bal=C3=A1zs Kov=C3=A1cs <balazs.kovacs@ericsson.com> wrote:

Hi,
Kent, I'm fine with your proposals.

Regarding subsequent calls to the actions, I = agree the safe choice would be to deny them; otherwise, one could run = into invalid key pairs (where a certificate was already configured) and = authentication failures with network peers (especially in = SSH-key-based-authentication case).

Br,
Balazs

-----Original Message-----
From: Kent Watsen = <kent+ietf@watsen.net>
Sent: Wednesday, = April 24, 2019 10:30 PM
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Cc: = Bal=C3=A1zs Kov=C3=A1cs <balazs.kovacs@ericsson.com>; netconf@ietf.org
Subject: Re: [netconf] ietf crypto types - permanently = hidden

Hi Juergen,


Perhaps = this should say 'implementation specific' instead 'application
specific'.

Changed = in my local copy.


My = recommendation is to modify the "generate/install-hidden-key"
(renamed to just = "generate/install-key") actions to have a flag indicating if
the key should be "permanently hidden" (perhaps by using a = TPM) or not, in
which case configuration is created, same = as if the client had used <edit-
config>, but = without needing to touch the key.

I agree that having a flag to control the = behavior is useful and I
think there should be explicit = text how the action fails in case the
requested action = cannot be performed.

I am not sure I = understand install-hidden-key. The description says:

=          "Requests the = device to load the specified values into
=           a hidden = key.  The resulting asymmetric key values are
=           considered = operational state and hence present only in
=           <operationa= l>.";

So what is the persistence model = of this? Does a key installed with
install-hidden-key = survive reboots? If so, can I delete somehow such a
hidden = key? (Is the answer that this key is tied to the lifetime of
the list element indirectly using this grouping?) Does = invoking
install-hidden-key twice cause the first = installed key to be
overwritten? Can the = install-hidden-key action fail in any way?

This leads to related questions for generate-hidden-key: Does = invoking
this action twice cause an existing key to be = overwritten? Can I
explicitely delete a generated hidden = key? Does deleting the list item
that directly or = indirectly uses this grouping delete a hidden key?

[Disclaimer: the below reflect my = understanding of how the current model
works, and does not = necessarily reflect if we were to flip things around by
letting the actions generate configuration.]

The expectation is that the "permanently hidden" keys would = persist,
presumably with origin=3Dsystem.

In the YANG, the "permanently-hidden" enum only appears in = the
"asymmetric-key-pair-grouping" grouping. =   Consuming data models are
expected to "use" = this grouping under a "config true" node.  This grouping's
description statement is noteworthy:

grouping asymmetric-key-pair-grouping {
=    description
=      "A private/public key pair.

      The = 'algorithm', 'public-key', and 'private-key'  nodes are
      not mandatory because = they MAY be defined in <operational>.
=       Implementations SHOULD assert that = these values are either
=       configured or that they exist in = <operational>.";
   ...
= }

Thusly it is expected that the client = will create the parent node (e.g., via
<edit-config>) = and then invoke either the generate or install hidden key
action.  Presumably, the lifetime of the permanently = hidden key would be
tied to the lifetime of its parent.

Regarding what happens when the actions are = invoked a second time, it's
not specified.  One = choice, perhaps the safe choice, would be to deny
subsequent= attempts, forcing the client to create a new parent node instead.
If the parent node is in a list, such as in the keystore, = then the second key
could be created, with certificates = bound to it, before mapping reference to
the old-key to = the new-key.  However, if the key is not in a list, such as when
using a "local-definition", then in in-place migration, along = with service
disruption, would be required.

Of course, one has to ask how often/likely is = it that a client wants to
regenerate the private key. =  Presumably it would only be due to the concern
that = the key had been compromised (which shouldn't happen if
"permanently hidden") or, perhaps, due to a proactive = key-rotation policy,
thinking (misguided, I believe, = proven false now) that the private key's
entropy expires = over time.  Regardless, the point is that it seems to be an
action that would seldomly occur and, when/if it does, the = effort to create
another parent node (in keystore or a = local-definition) might not be a big
deal.
PS: words such as "expectation" and "presumably" are used = above to
indicate a likely need for the text to be more = explicit.

Kent // contributor



= --Apple-Mail=_337CEA86-1976-4F0E-BADD-0964C68E94A8-- From nobody Mon Apr 29 10:06:03 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827621203FB for ; Mon, 29 Apr 2019 10:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k56i0hEeIVcx for ; Mon, 29 Apr 2019 10:05:59 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DEC120335 for ; Mon, 29 Apr 2019 10:05:58 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 35B766B6; Mon, 29 Apr 2019 19:05:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id HCRXvSp0nXTt; Mon, 29 Apr 2019 19:05:57 +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 atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 29 Apr 2019 19:05:57 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E635200DF; Mon, 29 Apr 2019 19:05:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id hjAxY5JalQsn; Mon, 29 Apr 2019 19:05:56 +0200 (CEST) Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id B5416200DE; Mon, 29 Apr 2019 19:05:56 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Mon, 29 Apr 2019 19:05:55 +0200 Received: by anna.localdomain (Postfix, from userid 501) id A3FDF3008A09D2; Mon, 29 Apr 2019 19:05:55 +0200 (CEST) Date: Mon, 29 Apr 2019 19:05:55 +0200 From: Juergen Schoenwaelder To: Kent Watsen CC: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= , "netconf@ietf.org" Message-ID: <20190429170555.fxggfy7555mklihh@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= , "netconf@ietf.org" References: <20190404.194623.1178346313710501110.mbj@tail-f.com> <01dd01d4eb9c$b9a04160$4001a8c0@gateway.2wire.net> <20190405.142201.707949273328784535.mbj@tail-f.com> <413d5725-9c27-e50b-2622-1b0e2f35cdb1@ericsson.com> <0100016a5019d7f9-7f737c63-d07c-4c7f-b12e-c5b19d50eeaf-000000@email.amazonses.com> <20190424180513.gtxmreicd7iydrpr@anna.jacobs.jacobs-university.de> <0100016a510a3038-7671e146-e23f-4bc9-9f93-ea2314b5d4e7-000000@email.amazonses.com> <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 17:06:01 -0000 On Mon, Apr 29, 2019 at 04:17:51PM +0000, Kent Watsen wrote: > Okay, I've added the following text into the generate/install-hidden-key descriptions: > > OLD: > The resulting asymmetric key values are > considered operational state and hence present only in > ."; > > NEW: > The resulting asymmetric key values are > considered operational state and hence present only in > and bound to the lifetime of the > parent 'config true' node. Subsequent invokaions of > this or the '-hidden-key' action are denied."; > > where is the name of the other action (generate vs. install). Is it sufficiently clear what 'is denied' means, i.e., how a server has to report the failure of the action? /js PS: s/invokaions/invocations/ -- 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 Apr 29 10:28:29 2019 Return-Path: <0100016a6a24006f-6e5cc3ba-ecd3-4190-8432-f8e91bb0c3ae-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141CB1203D0 for ; Mon, 29 Apr 2019 10:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHUHHlOrIykv for ; Mon, 29 Apr 2019 10:28:27 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC05120025 for ; Mon, 29 Apr 2019 10:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556558905; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=/MaYVlVK1qi5S6CjTyjlNUZn1s2Zk4b1REsq331gMMM=; b=WPCEuUpyPu2NpG9vfRqLU0kBJato+cj2GmB0KFs1sxHOGDtk1h8/68ZhJlgYYBAb 35RDCtJnZvP6gBofluqc7ZCliWrkb64GKmhxpptdgg5XeEPX/O04fkYtL/vDYIrn3Tz Lla2HuFg7PQMK2ipIyk/2XojI6cMDFZ5MjFy59jk= From: Kent Watsen Message-ID: <0100016a6a24006f-6e5cc3ba-ecd3-4190-8432-f8e91bb0c3ae-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_66567D0E-865A-4C70-A35C-9B8960610EBB" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 29 Apr 2019 17:28:25 +0000 In-Reply-To: <20190429170555.fxggfy7555mklihh@anna.jacobs.jacobs-university.de> Cc: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= , "netconf@ietf.org" To: Juergen Schoenwaelder References: <20190404.194623.1178346313710501110.mbj@tail-f.com> <01dd01d4eb9c$b9a04160$4001a8c0@gateway.2wire.net> <20190405.142201.707949273328784535.mbj@tail-f.com> <413d5725-9c27-e50b-2622-1b0e2f35cdb1@ericsson.com> <0100016a5019d7f9-7f737c63-d07c-4c7f-b12e-c5b19d50eeaf-000000@email.amazonses.com> <20190424180513.gtxmreicd7iydrpr@anna.jacobs.jacobs-university.de> <0100016a510a3038-7671e146-e23f-4bc9-9f93-ea2314b5d4e7-000000@email.amazonses.com> <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com> <20190429170555.fxggfy7555mklihh@anna.jacobs.jacobs-university.de> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.29-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 17:28:28 -0000 --Apple-Mail=_66567D0E-865A-4C70-A35C-9B8960610EBB Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > Is it sufficiently clear what 'is denied' means, i.e., how a server > has to report the failure of the action? Shall we use the 'data-exists' error-tag? > PS: s/invokaions/invocations/ Fixed. --Apple-Mail=_66567D0E-865A-4C70-A35C-9B8960610EBB Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Is it sufficiently clear what 'is denied' means, i.e., how a server
has to report the failure of the action?

Shall we use the 'data-exists' error-tag?


PS: s/invokaions/invocations/

Fixed.




--Apple-Mail=_66567D0E-865A-4C70-A35C-9B8960610EBB-- From nobody Mon Apr 29 10:40:41 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C685E120436; Mon, 29 Apr 2019 10:40:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-netconf-subscribed-notifications@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155655963180.15870.3650019434718355043.idtracker@ietfa.amsl.com> Date: Mon, 29 Apr 2019 10:40:31 -0700 Archived-At: Subject: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-23: (with DISCUSS) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 17:40:32 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-netconf-subscribed-notifications-23: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- [putting this out early in the hopes it can be resolved quickly; I'm just starting to review the document.] This document started life as a rfc5277bis, published in July 2008, before RFC 5378 (BCP 78) was published in November of 2008. If we are using any text from RFC 5277 and did not gain the additional rights declaration from the authors of that document, this document needs to use a different boilerplate text (the "pre-2008" text). I look at the sibling document draft-ietf-netfonf-yang-push of this document, which does use the pre-2008 boilerplate, and am having a hard time understanding why this document does not also have the pre-2008 boilerplate. From nobody Mon Apr 29 10:58:35 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE791200CD; Mon, 29 Apr 2019 10:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEsUX5BBYt9I; Mon, 29 Apr 2019 10:58:23 -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 710E4120096; Mon, 29 Apr 2019 10:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3042; q=dns/txt; s=iport; t=1556560703; x=1557770303; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mD1jfCSksHUkgO2BThu6Z906TtH9dfe6nboUbKmcRVk=; b=YbrberVSiHaGCx9gmHiDVwdBO14i9GuXliqAynPOsPYrLgGU9GfDO7Tt oZ4/51TUOxFAQgd3ALfpR7/T5uomTAWBBBfKXUlFH9NYAIeq5zDgWN7b3 4q4ShktYIwFTC209ZsYDPQQk9o9tdb4EBzCmyG9fOTEMytpLNMnij3exO c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAABAOsdc/5xdJa1mDgwBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVEFAQEBAQsBgWYqgWwoCoQGiByNEphQFIFnDgEBhG0CF4Y?= =?us-ascii?q?bIzQJDgEDAQEEAQECAQJtKIVKAQEBBCMROAoBAgwEAgEIFQIDAiYCAgIwFQg?= =?us-ascii?q?IAgQBDQUIEYI+glSuTIEvijGBCycBi0kXgUA/hCM+hAmDRYJYBIsBgjeZPwk?= =?us-ascii?q?CggmOaoEdgiQjgg2TGowNgR6PJoQJAhEVgTAfOIFWcBWDJ4IbFxRtAQmMWTt?= =?us-ascii?q?BMZMfgSEBAQ?= X-IronPort-AV: E=Sophos;i="5.60,410,1549929600"; d="scan'208";a="264444237" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Apr 2019 17:58:21 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x3THwKQo018465 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Apr 2019 17:58:21 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 29 Apr 2019 13:58:20 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Mon, 29 Apr 2019 13:58:20 -0400 From: "Eric Voit (evoit)" To: Benjamin Kaduk , The IESG CC: "draft-ietf-netconf-subscribed-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-23: (with DISCUSS) Thread-Index: AQHU/rKoAXBzztdqKUKWeXbDQMBk+KZTatEw Date: Mon, 29 Apr 2019 17:58:19 +0000 Message-ID: <717530026d2d4af0a92c318ecbdbb4bd@XCH-RTP-013.cisco.com> References: <155655963180.15870.3650019434718355043.idtracker@ietfa.amsl.com> In-Reply-To: <155655963180.15870.3650019434718355043.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.233] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.153, xch-rtp-013.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-23: (with DISCUSS) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 17:58:25 -0000 SGkgQmVuamFtaW4sDQoNCkkgdGhpbmsgeW91IGFyZSBhc2tpbmcgd2h5IHRoZSBmb2xsb3dpbmcg Ym9pbGVycGxhdGUgdGV4dCB3YXNuJ3QgaW5jbHVkZWQuLi4NCg0KICAgVGhpcyBkb2N1bWVudCBt YXkgY29udGFpbiBtYXRlcmlhbCBmcm9tIElFVEYgRG9jdW1lbnRzIG9yIElFVEYNCiAgIENvbnRy aWJ1dGlvbnMgcHVibGlzaGVkIG9yIG1hZGUgcHVibGljbHkgYXZhaWxhYmxlIGJlZm9yZSBOb3Zl bWJlcg0KICAgMTAsIDIwMDguICBUaGUgcGVyc29uKHMpIGNvbnRyb2xsaW5nIHRoZSBjb3B5cmln aHQgaW4gc29tZSBvZiB0aGlzDQogICBtYXRlcmlhbCBtYXkgbm90IGhhdmUgZ3JhbnRlZCB0aGUg SUVURiBUcnVzdCB0aGUgcmlnaHQgdG8gYWxsb3cNCiAgIG1vZGlmaWNhdGlvbnMgb2Ygc3VjaCBt YXRlcmlhbCBvdXRzaWRlIHRoZSBJRVRGIFN0YW5kYXJkcyBQcm9jZXNzLg0KICAgV2l0aG91dCBv YnRhaW5pbmcgYW4gYWRlcXVhdGUgbGljZW5zZSBmcm9tIHRoZSBwZXJzb24ocykgY29udHJvbGxp bmcNCiAgIHRoZSBjb3B5cmlnaHQgaW4gc3VjaCBtYXRlcmlhbHMsIHRoaXMgZG9jdW1lbnQgbWF5 IG5vdCBiZSBtb2RpZmllZA0KICAgb3V0c2lkZSB0aGUgSUVURiBTdGFuZGFyZHMgUHJvY2Vzcywg YW5kIGRlcml2YXRpdmUgd29ya3Mgb2YgaXQgbWF5DQogICBub3QgYmUgY3JlYXRlZCBvdXRzaWRl IHRoZSBJRVRGIFN0YW5kYXJkcyBQcm9jZXNzLCBleGNlcHQgdG8gZm9ybWF0DQogICBpdCBmb3Ig cHVibGljYXRpb24gYXMgYW4gUkZDIG9yIHRvIHRyYW5zbGF0ZSBpdCBpbnRvIGxhbmd1YWdlcyBv dGhlcg0KICAgdGhhbiBFbmdsaXNoLg0KDQpUaGlzIHdhcyBsaWtlbHkgYW4gb3ZlcnNpZ2h0IGR1 cmluZyB0aGUgaW5pdGlhbCBhdXRob3IncyBzdWJtaXNzaW9uLiAgSWYgdGhpcyB0ZXh0IHdhcyBp bmNsdWRlZCBhbmQgdXBsb2FkZWQgYXMgYSAtMjQgdXBkYXRlLCB3b3VsZCB0aGF0IGNvdmVyIHlv dXIgY29uY2Vybj8NCg0KQlRXOiB0aGUgc2FtZSBib2lsZXJwbGF0ZSB1cGRhdGUgc2hvdWxkIGFs c28gYmUgbWFkZSB0byANCmRyYWZ0LWlldGYtbmV0Y29uZi1uZXRjb25mLWV2ZW50LW5vdGlmaWNh dGlvbiAgYW5kIGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZg0KDQpUaGFua3MsDQpF cmljDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW5qYW1pbiBL YWR1ayB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IEJlbmph bWluIEthZHVrJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC0NCj4g bm90aWZpY2F0aW9ucy0yMzogKHdpdGggRElTQ1VTUykNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g RElTQ1VTUzoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gW3B1dHRpbmcgdGhpcyBvdXQgZWFybHkg aW4gdGhlIGhvcGVzIGl0IGNhbiBiZSByZXNvbHZlZCBxdWlja2x5OyBJJ20ganVzdCBzdGFydGlu ZyB0bw0KPiByZXZpZXcgdGhlIGRvY3VtZW50Ll0NCj4gDQo+IFRoaXMgZG9jdW1lbnQgc3RhcnRl ZCBsaWZlIGFzIGEgcmZjNTI3N2JpcywgcHVibGlzaGVkIGluIEp1bHkgMjAwOCwgYmVmb3JlIFJG Qw0KPiA1Mzc4IChCQ1AgNzgpIHdhcyBwdWJsaXNoZWQgaW4gTm92ZW1iZXIgb2YgMjAwOC4gIElm IHdlIGFyZSB1c2luZyBhbnkgdGV4dCBmcm9tDQo+IFJGQyA1Mjc3IGFuZCBkaWQgbm90IGdhaW4g dGhlIGFkZGl0aW9uYWwgcmlnaHRzIGRlY2xhcmF0aW9uIGZyb20gdGhlIGF1dGhvcnMgb2YNCj4g dGhhdCBkb2N1bWVudCwgdGhpcyBkb2N1bWVudCBuZWVkcyB0byB1c2UgYSBkaWZmZXJlbnQgYm9p bGVycGxhdGUgdGV4dCAodGhlICJwcmUtDQo+IDIwMDgiIHRleHQpLiAgSSBsb29rIGF0IHRoZSBz aWJsaW5nIGRvY3VtZW50IGRyYWZ0LWlldGYtbmV0Zm9uZi15YW5nLXB1c2ggb2YgdGhpcw0KPiBk b2N1bWVudCwgd2hpY2ggZG9lcyB1c2UgdGhlIHByZS0yMDA4IGJvaWxlcnBsYXRlLCBhbmQgYW0g aGF2aW5nIGEgaGFyZCB0aW1lDQo+IHVuZGVyc3RhbmRpbmcgd2h5IHRoaXMgZG9jdW1lbnQgZG9l cyBub3QgYWxzbyBoYXZlIHRoZSBwcmUtMjAwOCBib2lsZXJwbGF0ZS4NCj4gDQo+IA0KPiANCg0K From nobody Mon Apr 29 11:25:19 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91528120628; Mon, 29 Apr 2019 11:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUS1KKEt12qw; Mon, 29 Apr 2019 11:25:09 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 910481205E1; Mon, 29 Apr 2019 11:25:09 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3TIP4PN005662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 29 Apr 2019 14:25:06 -0400 Date: Mon, 29 Apr 2019 13:25:03 -0500 From: Benjamin Kaduk To: "Eric Voit (evoit)" Cc: The IESG , "draft-ietf-netconf-subscribed-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" Message-ID: <20190429182503.GC60332@kduck.mit.edu> References: <155655963180.15870.3650019434718355043.idtracker@ietfa.amsl.com> <717530026d2d4af0a92c318ecbdbb4bd@XCH-RTP-013.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <717530026d2d4af0a92c318ecbdbb4bd@XCH-RTP-013.cisco.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-23: (with DISCUSS) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 18:25:12 -0000 On Mon, Apr 29, 2019 at 05:58:19PM +0000, Eric Voit (evoit) wrote: > Hi Benjamin, > > I think you are asking why the following boilerplate text wasn't included... > > This document may contain material from IETF Documents or IETF > Contributions published or made publicly available before November > 10, 2008. The person(s) controlling the copyright in some of this > material may not have granted the IETF Trust the right to allow > modifications of such material outside the IETF Standards Process. > Without obtaining an adequate license from the person(s) controlling > the copyright in such materials, this document may not be modified > outside the IETF Standards Process, and derivative works of it may > not be created outside the IETF Standards Process, except to format > it for publication as an RFC or to translate it into languages other > than English. Exactly so. > > This was likely an oversight during the initial author's submission. If this text was included and uploaded as a -24 update, would that cover your concern? Definitely. (Note that there's an XML keyword for this; IIRC, .) > BTW: the same boilerplate update should also be made to > draft-ietf-netconf-netconf-event-notification and draft-ietf-netconf-restconf-notif Thanks for spotting those early! -Ben > > > > -----Original Message----- > > From: Benjamin Kaduk via Datatracker > > Subject: Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed- > > notifications-23: (with DISCUSS) > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > [putting this out early in the hopes it can be resolved quickly; I'm just starting to > > review the document.] > > > > This document started life as a rfc5277bis, published in July 2008, before RFC > > 5378 (BCP 78) was published in November of 2008. If we are using any text from > > RFC 5277 and did not gain the additional rights declaration from the authors of > > that document, this document needs to use a different boilerplate text (the "pre- > > 2008" text). I look at the sibling document draft-ietf-netfonf-yang-push of this > > document, which does use the pre-2008 boilerplate, and am having a hard time > > understanding why this document does not also have the pre-2008 boilerplate. > > > > > > > From nobody Mon Apr 29 12:13:57 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B321206A5; Mon, 29 Apr 2019 12:13:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155656523533.1258.17295148147293489039@ietfa.amsl.com> Date: Mon, 29 Apr 2019 12:13:55 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-subscribed-notifications-24.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 19:13:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : Subscription to YANG Event Notifications Authors : Eric Voit Alexander Clemm Alberto Gonzalez Prieto Einar Nilsen-Nygaard Ambika Prasad Tripathy Filename : draft-ietf-netconf-subscribed-notifications-24.txt Pages : 79 Date : 2019-04-29 Abstract: This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request for and receive a continuous, custom feed of publisher generated information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifications-24 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-subscribed-notifications-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-subscribed-notifications-24 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 29 12:16:34 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C04A1206AD; Mon, 29 Apr 2019 12:16:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155656538409.1133.13571288348418765712@ietfa.amsl.com> Date: Mon, 29 Apr 2019 12:16:24 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-netconf-event-notifications-18.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 19:16: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 WG of the IETF. Title : Dynamic subscription to YANG Events and Datastores over NETCONF Authors : Eric Voit Alexander Clemm Alberto Gonzalez Prieto Einar Nilsen-Nygaard Ambika Prasad Tripathy Filename : draft-ietf-netconf-netconf-event-notifications-18.txt Pages : 20 Date : 2019-04-29 Abstract: This document provides a NETCONF binding to the dynamic subscription capability of both subscribed notifications and YANG-Push. RFC Editor note: please replace the four references to pre-RFC normative drafts with the actual assigned RFC numbers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-notifications/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-netconf-event-notifications-18 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-event-notifications-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-netconf-event-notifications-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 29 12:25:29 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3AAE12066F; Mon, 29 Apr 2019 12:25:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155656591975.1214.3877293588342889790@ietfa.amsl.com> Date: Mon, 29 Apr 2019 12:25:19 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-netconf-event-notifications-19.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 19:25:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : Dynamic subscription to YANG Events and Datastores over NETCONF Authors : Eric Voit Alexander Clemm Alberto Gonzalez Prieto Einar Nilsen-Nygaard Ambika Prasad Tripathy Filename : draft-ietf-netconf-netconf-event-notifications-19.txt Pages : 20 Date : 2019-04-29 Abstract: This document provides a NETCONF binding to the dynamic subscription capability of both subscribed notifications and YANG-Push. RFC Editor note: please replace the four references to pre-RFC normative drafts with the actual assigned RFC numbers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-notifications/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-netconf-event-notifications-19 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-event-notifications-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-netconf-event-notifications-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 29 12:31:54 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04ABE1206D8; Mon, 29 Apr 2019 12:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOrOKfL3TaCH; Mon, 29 Apr 2019 12:31:43 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36C051206E2; Mon, 29 Apr 2019 12:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2823; q=dns/txt; s=iport; t=1556566303; x=1557775903; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KMku+PBZIYQWkF54gzrx0z1rPG4BMnmcCct1vaGaBmg=; b=f2CLWfwGCT7wUDWiG0uV4vgs3soNHDNTDk/BffbLb6jeuSwOtg5V15XJ NDjT8blpWttpCkHwYZ7cDY+cIgYvqov0aZnS8695qlhhcphUcyx/4qzQz mmaAllaswKd1eSykKgPw2Q2MWg7/MP1R8kFKsCK6pDCVwmru5qgeRJK09 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAB7UMdc/5xdJa1mDgwBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVEFAQEBAQsBgWYqgWwoCowijRSYUBSBZw4BAYRtAoYyIzQ?= =?us-ascii?q?JDgEDAQEEAQECAQJtKIVKAQEBAwE6MgoBAgUHBAIBCBUCAR4QMh0IAgQOBQg?= =?us-ascii?q?Rgj6CRQ+vfIozgTIBi0kXgUA/gRGDEj6ECYYdBIsBm3YJAoIJjmqDQSOCDZM?= =?us-ascii?q?ajSuTLwIRFYEwHziBVnAVgyeCGxcUbQEJjFk7QTGTH4EhAQE?= X-IronPort-AV: E=Sophos;i="5.60,410,1549929600"; d="scan'208";a="541645701" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Apr 2019 19:31:41 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x3TJVf0e004563 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Apr 2019 19:31:41 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 29 Apr 2019 15:31:40 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Mon, 29 Apr 2019 15:31:40 -0400 From: "Eric Voit (evoit)" To: Benjamin Kaduk CC: The IESG , "draft-ietf-netconf-subscribed-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-23: (with DISCUSS) Thread-Index: AQHU/rKoAXBzztdqKUKWeXbDQMBk+KZTatEwgABMkYD//88ZAA== Date: Mon, 29 Apr 2019 19:31:40 +0000 Message-ID: <94d0b3e325ee46e283d84204243bdf69@XCH-RTP-013.cisco.com> References: <155655963180.15870.3650019434718355043.idtracker@ietfa.amsl.com> <717530026d2d4af0a92c318ecbdbb4bd@XCH-RTP-013.cisco.com> <20190429182503.GC60332@kduck.mit.edu> In-Reply-To: <20190429182503.GC60332@kduck.mit.edu> 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.233] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.154, xch-rtp-014.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-23: (with DISCUSS) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 19:31:45 -0000 ipr=3D"pre5378Trust200902" change made and uploaded as v24 Eric > From: Benjamin Kaduk, April 29, 2019 2:25 PM >=20 > On Mon, Apr 29, 2019 at 05:58:19PM +0000, Eric Voit (evoit) wrote: > > Hi Benjamin, > > > > I think you are asking why the following boilerplate text wasn't includ= ed... > > > > This document may contain material from IETF Documents or IETF > > Contributions published or made publicly available before November > > 10, 2008. The person(s) controlling the copyright in some of this > > material may not have granted the IETF Trust the right to allow > > modifications of such material outside the IETF Standards Process. > > Without obtaining an adequate license from the person(s) controlling > > the copyright in such materials, this document may not be modified > > outside the IETF Standards Process, and derivative works of it may > > not be created outside the IETF Standards Process, except to format > > it for publication as an RFC or to translate it into languages other > > than English. >=20 > Exactly so. >=20 > > > > This was likely an oversight during the initial author's submission. I= f this text > was included and uploaded as a -24 update, would that cover your concern? >=20 > Definitely. > (Note that there's an XML keyword for this; IIRC, ipr=3D"pre5378Trust200902">.) >=20 > > BTW: the same boilerplate update should also be made to > > draft-ietf-netconf-netconf-event-notification and > > draft-ietf-netconf-restconf-notif >=20 > Thanks for spotting those early! >=20 > -Ben >=20 > > > > > > > -----Original Message----- > > > From: Benjamin Kaduk via Datatracker > > > Subject: Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed- > > > notifications-23: (with DISCUSS) > > > > > > -------------------------------------------------------------------- > > > -- > > > DISCUSS: > > > -------------------------------------------------------------------- > > > -- > > > > > > [putting this out early in the hopes it can be resolved quickly; I'm > > > just starting to review the document.] > > > > > > This document started life as a rfc5277bis, published in July 2008, > > > before RFC > > > 5378 (BCP 78) was published in November of 2008. If we are using > > > any text from RFC 5277 and did not gain the additional rights > > > declaration from the authors of that document, this document needs > > > to use a different boilerplate text (the "pre- 2008" text). I look > > > at the sibling document draft-ietf-netfonf-yang-push of this > > > document, which does use the pre-2008 boilerplate, and am having a ha= rd > time understanding why this document does not also have the pre-2008 > boilerplate. > > > > > > > > > > > From nobody Mon Apr 29 13:04:10 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0128E1203D6; Mon, 29 Apr 2019 13:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=WZGbFsoN; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QbBdaKx4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m12pnPu3-x7; Mon, 29 Apr 2019 13:03:59 -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 44A30120142; Mon, 29 Apr 2019 13:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3486; q=dns/txt; s=iport; t=1556568239; x=1557777839; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Io0VrkoD9LFMD5OqGIBNKpBJVKBwdIC45BSId7eKYgc=; b=WZGbFsoNk/cRY42qYSjYTiKbk/on1XC/F5MRdDDi8/2H70fmC5DqVj6S D96DOBpF0auVhRcLMGA6dQ949ei8PWVq3CdSKYN7GGkm4qhAWq30KW4W7 0zTIEWEsmyuHHC6ORiuYDhVeaRkLndfBF0QnbKA8Mp1b/JN+wemK+TUHh s=; IronPort-PHdr: =?us-ascii?q?9a23=3Ax/XaMRM38KhgMF2ruyol6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjhNvfqaiU8NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAAAmWMdc/4ENJK1mDg4BAQEEAQE?= =?us-ascii?q?HBAEBgVMFAQELAYE9UAOBPSAECyiEEINHA48PgjIllyKBLoEkA1QOAQEthEA?= =?us-ascii?q?CF4YbIzYHDgEDAQEEAQECAQJtHAyFSwEBBBIREQwBATcBDwIBCBgCAgkdAgI?= =?us-ascii?q?CMBUQAgQOBSKDAIFqAxwBo08CgTWIX3GBL4J5AQEFhQUYgg4JgQsnAYtJF4F?= =?us-ascii?q?AP4ERJwwTgkw+hFuCczKCJo0QLJhaZQkCggmOaoNJG4INhjSMZqBaAgQCBAU?= =?us-ascii?q?CDgEBBYFWAy6BVnAVOyoBgkGCDweDaIoYO3KBKZMXAQE?= X-IronPort-AV: E=Sophos;i="5.60,410,1549929600"; d="scan'208";a="266535598" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Apr 2019 20:03:58 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x3TK3wp3009274 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Apr 2019 20:03:58 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 29 Apr 2019 15:03:57 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 29 Apr 2019 15:03:56 -0500 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 29 Apr 2019 15:03:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Io0VrkoD9LFMD5OqGIBNKpBJVKBwdIC45BSId7eKYgc=; b=QbBdaKx4BF5v1KCz1LNXXYncUatFfPZSI83c0qjv79dcB1tWQnIWVnbY9mOG05ZxUmR8hu9VUy38g3e7EjP5pRyxe6MmzDJw+D0mFbhsanrduohTKAvf8dGNL7ZZX4+pro1IvqO2jJLY1i64F//tQkQRMTw0ZppN/KZMHO65jkg= Received: from DM5PR1101MB2105.namprd11.prod.outlook.com (10.174.104.15) by DM5PR1101MB2188.namprd11.prod.outlook.com (10.174.104.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.13; Mon, 29 Apr 2019 20:03:55 +0000 Received: from DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::a113:a1ba:aae0:4a12]) by DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::a113:a1ba:aae0:4a12%6]) with mapi id 15.20.1835.010; Mon, 29 Apr 2019 20:03:55 +0000 From: "Reshad Rahman (rrahman)" To: Benjamin Kaduk CC: Aanchal Malhotra , "secdir@ietf.org" , "ietf@ietf.org" , "draft-ietf-netconf-restconf-notif.all@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] Secdir last call review of draft-ietf-netconf-restconf-notif-13 Thread-Index: AQHU8LEm3/ufrU/2dEa8pjPJiNurYqY4yTOAgAuvaICABvAQgIAHJTqAgADbAgA= Date: Mon, 29 Apr 2019 20:03:55 +0000 Message-ID: <67A8986B-4406-4CF4-8F64-42AFAF48EC1B@cisco.com> References: <155501965074.14152.2835369201856309773@ietfa.amsl.com> <20190420035612.GR51586@kduck.mit.edu> <7820A8E4-692B-43D2-9611-437CC440EBC7@cisco.com> <20190429030003.GJ60332@kduck.mit.edu> In-Reply-To: <20190429030003.GJ60332@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.6.190114 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [2001:420:2840:1250:2421:2f0a:1dbc:638e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0e0d505c-4171-4200-bdcd-08d6ccddcefa x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM5PR1101MB2188; x-ms-traffictypediagnostic: DM5PR1101MB2188: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0022134A87 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(366004)(396003)(136003)(346002)(51914003)(189003)(199004)(71200400001)(2616005)(71190400001)(58126008)(6486002)(486006)(7736002)(476003)(305945005)(83716004)(6916009)(11346002)(5660300002)(316002)(81156014)(81166006)(8936002)(229853002)(86362001)(76176011)(6436002)(99286004)(91956017)(76116006)(73956011)(102836004)(66476007)(64756008)(66556008)(66946007)(66446008)(46003)(36756003)(82746002)(25786009)(54906003)(97736004)(68736007)(93886005)(6116002)(53546011)(2906002)(14444005)(6506007)(4326008)(53936002)(256004)(6512007)(33656002)(478600001)(6246003)(8676002)(2171002)(186003)(446003)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1101MB2188; H:DM5PR1101MB2105.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: uXrrSe7MkyCdkpS2llxyuIjxueqN9hns110qnC+gE4GEr6iy4xpk+XDcAmJoQYVCk/nh1hbnhR4MxqxaWof+u9BZAm2Birn6j74q8oGUhPUuuamBUBVY85v3VRjj4W8Km7MtFvd/RvJkErWg6UaqR4HatdAf3+GVMtvekhc48kbF7J9OXGK23tGrzJhblZgT5d8W1ZlqkbzcWGXeIGnDjG/1uv2ceCPmufm98qilFBwUndzc0HjQic2AyCBVLooE4iVmwvweB8zLRO233FBtxt1zHw3dnD6e5j9XSyXHh8rvuKGMgu/EGEZhBAVPt4PV6z0LfWD9idy+Zm50U76q/H8zCJ5L9pt4lwI3NSRGYySHUo+Vqu2jLl7Z+8QB438rS8vXNKu497CpeQCpnIFdv23TKM0jXsyDjRSO6G6tDkg= Content-Type: text/plain; charset="utf-8" Content-ID: <343776AEE8F75E4D8D171FD2514360B5@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0e0d505c-4171-4200-bdcd-08d6ccddcefa X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2019 20:03:55.0650 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2188 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [netconf] Secdir last call review of draft-ietf-netconf-restconf-notif-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 20:04:01 -0000 T24gMjAxOS0wNC0yOCwgMTE6MDAgUE0sICJCZW5qYW1pbiBLYWR1ayIgPGthZHVrQG1pdC5lZHU+ IHdyb3RlOg0KDQogICAgT24gV2VkLCBBcHIgMjQsIDIwMTkgYXQgMDU6NTM6MDJQTSArMDAwMCwg UmVzaGFkIFJhaG1hbiAocnJhaG1hbikgd3JvdGU6DQogICAgPiBPbiAyMDE5LTA0LTE5LCAxMTo1 NiBQTSwgIkJlbmphbWluIEthZHVrIiA8a2FkdWtAbWl0LmVkdT4gd3JvdGU6DQogICAgPiANCiAg ICA+ICAgICBPbiBGcmksIEFwciAxMiwgMjAxOSBhdCAwOToyOTozNVBNICswMDAwLCBSZXNoYWQg UmFobWFuIChycmFobWFuKSB3cm90ZToNCiAgICA+ICAgICA+IEhpIEFhbmNoYWwsDQogICAgPiAg ICAgPiANCiAgICA+ICAgICA+IFRoYW5rcyBmb3IgdGhlIHJldmlldy4gUGxlYXNlIHNlZSBpbmxp bmUuDQogICAgPiAgICAgPiANCiAgICA+ICAgICA+IE9uIDIwMTktMDQtMTEsIDU6NTQgUE0sICJu ZXRjb25mIG9uIGJlaGFsZiBvZiBBYW5jaGFsIE1hbGhvdHJhIHZpYSBEYXRhdHJhY2tlciIgPG5l dGNvbmYtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygbm9yZXBseUBpZXRmLm9yZz4gd3Jv dGU6DQogICAgPiAgICAgPiANCiAgICA+ICAgICA+ICAgICBSZXZpZXdlcjogQWFuY2hhbCBNYWxo b3RyYQ0KICAgID4gICAgID4gICAgIFJldmlldyByZXN1bHQ6IFJlYWR5DQogICAgPiAgICAgPiAg ICAgDQogICAgPiAgICAgPiAgICAgVGhlIGRvY3VtZW50IGlzIHZlcnkgY2xlYXIgYW5kIGNvbmNp c2UuICBJIGp1c3QgaGF2ZSBvbmUgbWlub3IgY2xhcmlmaWNhdGlvbiBxdWVzdGlvbi4NCiAgICA+ ICAgICA+ICAgICBTZWN0aW9uIDMuNCBQYWdlIDkgdGhhdCBzYXlzIHRoZSBmb2xsb3dpbmc6DQog ICAgPiAgICAgPiAgICAgIkluIGFkZGl0aW9uIHRvIGFueSByZXF1aXJlZCAuLi4uLi4uLlNIT1VM RCBvbmx5IGJlIGFsbG93ZWQuLi4uLi4iLiAgDQogICAgPiAgICAgPiAgICAgDQogICAgPiAgICAg PiAgICAgSXMgdGhlcmUgYSByZWFzb24gZm9yIHVzaW5nIFNIT1VMRCBpbnN0ZWFkIG9mIE1VU1Q/ IA0KICAgID4gICAgID4gDQogICAgPiAgICAgPiBUaGVyZSBtYXkgYmUgcmVhc29ucyB3aHkgYW4g aW1wbGVtZW50YXRpb24gZGVjaWRlcyBub3QgdG8gZW5mb3JjZSB0aGlzIHJlc3RyaWN0aW9uLiBH b2luZyBieSBSRkMyMTE5IGRlZmluaXRpb25zLCB0aGlzIGlzIHdoeSB3ZSBjaG9zZSBTSE9VTEQg aW5zdGVhZCBvZiBNVVNULg0KICAgID4gICAgIA0KICAgID4gICAgIElmIHlvdSBoYXZlIHNvbWUg cmVhc29ucyBpbiBtaW5kLCBpdCBpcyBvZnRlbiBoZWxwZnVsIHRvIGxpc3QgdGhlbSBhcw0KICAg ID4gICAgIGV4YW1wbGVzIG9mIHdoZW4gdGhlIHJlY29tbWVuZGVkIGJlaGF2aW9yIHdvdWxkIG5v dCBiZSBmb2xsb3dlZC4NCiAgICA+IA0KICAgID4gV2hhdCB3ZSBoYWQgaW4gbWluZCBpcyBhICJz dXBlci11c2VyIiB3aG8gY291bGQgYmUgZ2l2ZW4gYWNjZXNzIHRvIHN1YnNjcmlwdGlvbnMgb2Yg b3RoZXIgdXNlcnMuIElzIHRoaXMgb2J2aW91cyBvciBzaG91bGQgSSBjYW4gYWRkIHRleHQgdG8g dGhhdCBlZmZlY3QgYXQgdGhlIGVuZCB0aGUgYnVsbGV0IGJlbG93PyBTb21ldGhpbmcgYWxvbmcg dGhlIGxpbmVzIG9mICJGb3IgZXhhbXBsZSwgYSBSRVNUQ09ORiB1c2VybmFtZSB3aXRoIHRoZSBy ZXF1aXJlZCBhZG1pbmlzdHJhdGl2ZSBwZXJtaXNzaW9ucyBjb3VsZCBiZSBhbGxvd2VkIHRvIGlu dm9rZSBSUENzIG1vZGlmeS1zdWJzY3JpcHRpb24sIHJlc3luYy1zdWJzY3JpcHRpb24gYW5kIGRl bGV0ZS1zdWJzY3JpcHRpb24gb24gYSBzdWJzY3JpcHRpb24gd2hpY2ggd2FzIGNyZWF0ZWQgYnkg YW5vdGhlciB1c2VybmFtZS4iLg0KICAgID4gDQogICAgPiAgICBvICBJbiBhZGRpdGlvbiB0byBh bnkgcmVxdWlyZWQgYWNjZXNzIHBlcm1pc3Npb25zIChlLmcuLCBOQUNNKSwgUlBDcw0KICAgID4g ICAgICAgbW9kaWZ5LXN1YnNjcmlwdGlvbiwgcmVzeW5jLXN1YnNjcmlwdGlvbiBhbmQgZGVsZXRl LXN1YnNjcmlwdGlvbg0KICAgID4gICAgICAgU0hPVUxEIG9ubHkgYmUgYWxsb3dlZCBieSB0aGUg c2FtZSBSRVNUQ09ORiB1c2VybmFtZSBbUkZDODA0MF0NCiAgICA+ICAgICAgIHdoaWNoIGludm9r ZWQgZXN0YWJsaXNoLXN1YnNjcmlwdGlvbi4NCiAgICANCiAgICBJIHRoaW5rIGl0IG1pZ2h0IGhl bHAgdG8gaGF2ZSBzdWNoIHRleHQsIHRob3VnaCBJIHdvdWxkIHN1Z2dlc3QgYSBzbGlnaHRseQ0K ICAgIHBpdGhpZXIgIlN1Y2ggYSByZXN0cmljdGlvbiBnZW5lcmFsbHkgc2VydmVzIHRvIHByZXNl cnZlIHVzZXJzJyBwcml2YWN5LCBidXQNCiAgICBleGNlcHRpb25zIG1pZ2h0IGJlIG1hZGUgZm9y IGFkbWluaXN0cmF0b3JzIHRoYXQgbWF5IG5lZWQgdG8gbW9kaWZ5IG9yDQogICAgZGVsZXRlIG90 aGVyIHVzZXJzJyBzdWJzY3JpcHRpb25zLiINCg0KR29vZCB3aXRoIG1lLCB0aGFua3MuIEknbGwg bWFrZSB0aGlzIGFkZGl0aW9uIGluIHRoZSBuZXh0IHJldi4NCg0KUmVnYXJkcywNClJlc2hhZC4N Cg0KICAgIFRoYW5rcywNCiAgICANCiAgICBCZW4NCiAgICANCg0K From nobody Mon Apr 29 19:29:00 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 487651200E5; Mon, 29 Apr 2019 19:28:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155659133026.12943.7548966623237720491@ietfa.amsl.com> Date: Mon, 29 Apr 2019 19:28:50 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-crypto-types-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 02:28:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : Common YANG Data Types for Cryptography Authors : Kent Watsen Wang Haiguang Filename : draft-ietf-netconf-crypto-types-06.txt Pages : 58 Date : 2019-04-29 Abstract: This document defines YANG identities, typedefs, the groupings useful for cryptographic applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-06 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 29 19:29:17 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBA3120243; Mon, 29 Apr 2019 19:29:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155659134888.12891.10896546954467532217@ietfa.amsl.com> Date: Mon, 29 Apr 2019 19:29:08 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-keystore-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 02:29:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG Data Model for a Centralized Keystore Mechanism Author : Kent Watsen Filename : draft-ietf-netconf-keystore-09.txt Pages : 22 Date : 2019-04-29 Abstract: This document defines a YANG 1.1 module called "ietf-keystore" that enables centralized configuration of asymmetric keys and their associated certificates, and notification for when configured certificates are about to expire. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-keystore/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-keystore-09 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-keystore-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-keystore-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 Mon Apr 29 19:29:54 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A999B1207DA; Mon, 29 Apr 2019 19:29:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155659138161.12927.3234071484496112685@ietfa.amsl.com> Date: Mon, 29 Apr 2019 19:29:41 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-trust-anchors-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 02:29:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG Data Model for Global Trust Anchors Author : Kent Watsen Filename : draft-ietf-netconf-trust-anchors-04.txt Pages : 17 Date : 2019-04-29 Abstract: This document defines a YANG 1.1 data model for configuring global sets of X.509 certificates and SSH host-keys that can be referenced by other data models for trust. While the SSH host-keys are uniquely for the SSH protocol, the X.509 certificates may have multiple uses, including authenticating protocol peers and verifying signatures. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "XXXX" --> the assigned RFC value for this draft o "YYYY" --> the assigned RFC value for draft-ietf-netconf-crypto- types Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2019-04-29" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-trust-anchors/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-04 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trust-anchors-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-trust-anchors-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 29 19:33:40 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E342512022C; Mon, 29 Apr 2019 19:33:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155659161283.12951.5248387604727435190@ietfa.amsl.com> Date: Mon, 29 Apr 2019 19:33:32 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-ssh-client-server-13.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 02:33:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG Groupings for SSH Clients and SSH Servers Authors : Kent Watsen Gary Wu Liang Xia Filename : draft-ietf-netconf-ssh-client-server-13.txt Pages : 48 Date : 2019-04-29 Abstract: This document defines three YANG modules: the first defines groupings for a generic SSH client, the second defines groupings for a generic SSH server, and the third defines common identities and groupings used by both the client and the server. It is intended that these groupings will be used by applications using the SSH protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-ssh-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-13 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-ssh-client-server-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-ssh-client-server-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 29 19:34:02 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CC31207EC; Mon, 29 Apr 2019 19:33:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155659163520.12987.10073829867268361319@ietfa.amsl.com> Date: Mon, 29 Apr 2019 19:33:55 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-tls-client-server-12.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 02:34:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG Groupings for TLS Clients and TLS Servers Authors : Kent Watsen Gary Wu Liang Xia Filename : draft-ietf-netconf-tls-client-server-12.txt Pages : 45 Date : 2019-04-29 Abstract: This document defines three YANG modules: the first defines groupings for a generic TLS client, the second defines groupings for a generic TLS server, and the third defines common identities and groupings used by both the client and the server. It is intended that these groupings will be used by applications using the TLS protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-tls-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-12 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tls-client-server-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-tls-client-server-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 29 19:37:32 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 073F612021D; Mon, 29 Apr 2019 19:37:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155659184995.12855.808865200478554494@ietfa.amsl.com> Date: Mon, 29 Apr 2019 19:37:30 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-netconf-client-server-12.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 02:37:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : NETCONF Client and Server Models Author : Kent Watsen Filename : draft-ietf-netconf-netconf-client-server-12.txt Pages : 64 Date : 2019-04-29 Abstract: This document defines two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server. Both modules support both the SSH and TLS transport protocols, and support both standard NETCONF and NETCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. This document contains references to other drafts in progress, both in the Normative References section, as well as in body text throughout. Please update the following references to reflect their final RFC assignments: o I-D.ietf-netconf-keystore o I-D.ietf-netconf-tcp-client-server o I-D.ietf-netconf-ssh-client-server o I-D.ietf-netconf-tls-client-server Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "XXXX" --> the assigned RFC value for this draft o "AAAA" --> the assigned RFC value for I-D.ietf-netconf-tcp-client- server o "YYYY" --> the assigned RFC value for I-D.ietf-netconf-ssh-client- server o "ZZZZ" --> the assigned RFC value for I-D.ietf-netconf-tls-client- server Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2019-04-29" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix B. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-12 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-client-server-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-netconf-client-server-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 29 19:37:50 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4B31207EF; Mon, 29 Apr 2019 19:37:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155659186272.12935.14248851613042564780@ietfa.amsl.com> Date: Mon, 29 Apr 2019 19:37:42 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-restconf-client-server-12.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 02:37:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : RESTCONF Client and Server Models Author : Kent Watsen Filename : draft-ietf-netconf-restconf-client-server-12.txt Pages : 55 Date : 2019-04-29 Abstract: This document defines two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. Both modules support the TLS transport protocol with both standard RESTCONF and RESTCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. This document contains references to other drafts in progress, both in the Normative References section, as well as in body text throughout. Please update the following references to reflect their final RFC assignments: o I-D.ietf-netconf-keystore o I-D.ietf-netconf-tcp-client-server o I-D.ietf-netconf-tls-client-server o I-D.ietf-netconf-http-client-server Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "XXXX" --> the assigned RFC value for this draft o "AAAA" --> the assigned RFC value for I-D.ietf-netconf-tcp-client- server o "BBBB" --> the assigned RFC value for I-D.ietf-netconf-tls-client- server o "CCCC" --> the assigned RFC value for I-D.ietf-netconf-http- client-server Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2019-04-29" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix B. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-12 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-client-server-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-client-server-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 29 20:37:22 2019 Return-Path: <0100016a6c516906-a2beb17b-d32c-4368-81f1-fe81e17b3755-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00DE120284 for ; Mon, 29 Apr 2019 20:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u497TgdO8-pQ for ; Mon, 29 Apr 2019 20:37:17 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA27120287 for ; Mon, 29 Apr 2019 20:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556595436; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=eZh7Ib+hBpYcVRdBpbfFoOizAhfe0TRAUa5AqGJfMNE=; b=jiDMJdgK0Oh4dAP+7wLzIihrCHdILQtfPBx4ceyqS+M/IgNINjzwt7j5vZolStAk cMSeaFL0RjaQZtEF/GJgzp3T3XZSVw4B8lYx79wcDozrNaorQpqT7p5XF+CKY6+Ho2V AUAZTfju/5O/fC04jM4VCgNzvsACgSTUCYwjc9ZQ= From: Kent Watsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-ID: <0100016a6c516906-a2beb17b-d32c-4368-81f1-fe81e17b3755-000000@email.amazonses.com> Date: Tue, 30 Apr 2019 03:37:15 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.30-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] updates to the suite of client/server drafts X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 03:37:20 -0000 Below are the change logs for each draft just submitted. Highlights: - all issues from the tcp adoption call have been addressed. Lowlights: - some issues from the http adoption call remain. - there are some "fixme" comments left in the models. - the tree-diagram in Sections 2.1 and 3.1 in both the NC and RC drafts are a bit off (GitHub issue reported). K. // contributor =3D=3D=3D change logs =3D=3D=3D crypto-types o Added NACM annotations. o Updated Security Considerations section. o Added 'asymmetric-key-pair-with-cert-grouping' grouping. o Removed text from 'permanently-hidden' enum regarding such keys not being backed up or restored. o Updated the boilerplate text in module-level "description" statement to match copyeditor convention. o Added an explanation to the 'public-key-grouping' and 'asymmetric- key-pair-grouping' statements as for why the nodes are not mandatory (e.g., because they may exist only in . o Added 'must' expressions to the 'public-key-grouping' and 'asymmetric-key-pair-grouping' statements ensuring sibling nodes either all exist or do not all exist. o Added an explanation to the 'permanently-hidden' that the value cannot be configured directly by clients and servers MUST fail any attempt to do so. o Added 'trust-anchor-certs-grouping' and 'end-entity-certs- grouping' (the plural form of existing groupings). o Now states that keys created in by the *-hidden-key actions are bound to the lifetime of the parent 'config true' node, and that subsequent invocations of either action results in a failure. keystore o Added a 'description' statement to the 'must' in the /keystore/ asymmetric-key node explaining that the descendent values may exist in only, and that implementation MUST assert that the values are either configured or that they exist in . o Copied above 'must' statement (and description) into the local-or- keystore-asymmetric-key-grouping, local-or-keystore-asymmetric- key-with-certs-grouping, and local-or-keystore-end-entity-cert- with-key-grouping statements. trust-anchors o Added groupings 'local-or-truststore-certs-grouping' and 'local- or-truststore-host-keys-grouping', matching similar definitions in the keystore draft. Note new (and incomplete) "truststore" usage! o Related to above, also added features 'truststore-supported' and 'local-trust-anchors-supported'. tcp-client-server o addressed issues raised by Michael Scharf, TCPM WG chair and now = co-author o this version resolves the adoption-call comments (okay to = resubmit as "ietf" now?) ssh-client-server o Removed the "demux containers", floating the nacm:default-deny- write to each descendent node, and adding a note to model designers regarding the potential need to add their own demux containers. o In the server model, replaced with and introduced 'local-or-external' choice. tls-client-server o In server model, made 'client-authentication' a 'presence' node indicating that the server supports client authentication. o In the server model, added a 'required-or-optional' choice to 'client-authentication' to better support protocols such as RESTCONF. o In the server model, added a 'local-or-external' choice to 'client-authentication' to better support consuming data models that prefer to keep client auth with client definitions than in a model principally concerned with the "transport". o In both models, removed the "demux containers", floating the nacm:default-deny-write to each descendent node, and adding a note to model designers regarding the potential need to add their own demux containers. http-client-server o number of "improvements" (i hope) o not reviewed by HTTP WG chairs yet o likely needs finessing before asking them to review it again netconf-client-server o Removed the "Design Considerations" section. o Removed the 'must' statement limiting keepalives in periodic connections. o Updated models and examples to reflect removal of the "demux" containers in the imported models. o Updated the "periodic-connnection" description statements to be more like the RESTCONF draft, especially where it described dropping the underlying TCP connection. o Updated text to better reference where certain examples come from (e.g., which Section in which draft). o In the server model, commented out the "must 'pinned-ca-certs or pinned-client-certs'" statement to reflect change made in the TLS draft whereby the trust anchors MAY be defined externally. o Replaced the 'listen', 'initiate', and 'call-home' features with boolean expressions. restconf-client-server o Removed the 'must' statement limiting keepalives in periodic connections. o Updated models and examples to reflect removal of the "demux" containers in the imported models. o Updated the "periodic-connnection" description statements to better describe behavior when connections are not closed gracefully. o Updated text to better reference where certain examples come from (e.g., which Section in which draft). o In the server model, commented out the "must 'pinned-ca-certs or pinned-client-certs'" statement to reflect change made in the TLS draft whereby the trust anchors MAY be defined externally. o Replaced the 'listen', 'initiate', and 'call-home' features with boolean expressions. From nobody Mon Apr 29 21:54:01 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6CA120108; Mon, 29 Apr 2019 21:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yX1SEkvgjTwl; Mon, 29 Apr 2019 21:53:57 -0700 (PDT) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 7F8F8120103; Mon, 29 Apr 2019 21:53:57 -0700 (PDT) Received: by mail-it1-x132.google.com with SMTP id x132so2649399itf.2; Mon, 29 Apr 2019 21:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=lv6BpJne90QncZJnMlOIYZDPFg2LfYH9edZ8hicPdAQ=; b=KIpKmMp1PKAH8jdYA0UudlM+zvRCXJg2aotEb0g3D8Bf9gFHjnRNrmmuzR+vwIwdD2 IrWCn8QQP9PMHSO8r1MzmfWWwCVh1YlviWj2L/AgElkRoRohbgYViusaTeBNOzHz6hKA PlvbMoBo2tMTDH3FC0PtCQUEBz+rYjvWqcqwYRMp335lpbX4bFF7VKhTSgmVeHX3GRCk 4WW3ugwIbmrBX4YsHeL8OxxUGrfTGQHuxE2asHBsAwUQnTk/VQREN55a3EMWTJJhz3+m fijZylDBYNY03R0bmp+qQFeSS024q3CtGyhEQEl0MMebIM+1GyogfQayUboKwe+Wfo/v WQiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=lv6BpJne90QncZJnMlOIYZDPFg2LfYH9edZ8hicPdAQ=; b=OwmF/tu7hUalI2bADIa6R1WsCCTUyJc19txORUErE4J1Ifbz1KJld/pR+AQ4XYe345 +JzgMI6n2x/2zJBt6sW/iJU2NCO+spYmEGsWKKypd6PoDe5uIyFHjXGdyFEHeVp1+T5N ShihoUHRCbv1FsByT9rbr7POjSHbWA/02zIscdz9scNcUxmlRZ6lIAMLPnLSxUs2wA+3 GLHG5a88aecpsYpwhFqaj6mPVCGlw2dPW70HGUVozJOKoZiA6YI7ebmBTOVCc59qbK0/ 47uFnleijr5/H3qUa8x+AUYZpaZI+IjgG2mHGdAGXf0a6xa9XMsDlFj1I1tyzeaF5bty xv+A== X-Gm-Message-State: APjAAAX3xe5Y4P/vqJ5folZ8LSTEefQnSPwQQSCDPR4q48fqb+PIowMA vzFtb1iI+yfEM7jEeqye8cRBSGK4RrcvzRW8DEAu8dR+ X-Google-Smtp-Source: APXvYqzPftaQnmdwcrhu/6qgFlJ+zWSEZWnvfH9KhxlwLu5HoqMYNmi0FrqSTmaEZseSNFz4eu4btF2QFXPKhxOraYk= X-Received: by 2002:a24:1c0b:: with SMTP id c11mr2111830itc.67.1556600036440; Mon, 29 Apr 2019 21:53:56 -0700 (PDT) MIME-Version: 1.0 From: Dhruv Dhody Date: Tue, 30 Apr 2019 10:23:20 +0530 Message-ID: To: "" Cc: rtg-dir@ietf.org, draft-ietf-netconf-netconf-event-notifications.all@ietf.org, netconf@ietf.org, Dhruv Dhody Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 04:54:00 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-netconf-netconf-event-notifications-17 Reviewer: Dhruv Dhody Review Date: 2019-04-29 IETF LC End Date: 2019-04-12 Intended Status: Standards Track Summary: -------- I have some minor concerns about this document that I think should be resolved before publication. Comments: --------- This document provides a binding for events streamed over the NETCONF for dynamic subscriptions. This is a companion document to draft-ietf-netconf- subscribed-notifications and this capability for RESTCONF is defined in draft-ietf-netconf-restconf-notif. The document is overall well written, it makes an assumption that the reader is well versed in this area and thus sparse in providing details in the Introduction section. The appendix provides good examples. I don't see any Routing Yang model specific issue. Major Issues: ------------- Note - An IETF process issue, but worth handling right away. Section 11 says - 11. Notes to the RFC Editor This section can be removed by the RFC editor after the requests have been performed. It further says - RFC 6241 needs to be updated based on the needs of this draft. RFC-6241 section 1.2 bullet "(2)" targets RFC-5277 (actually it identifies RFC 5717, but that was an error fixed after RFC publication). Anyway the current phrasing in RFC-5277 says that a notification message can only be sent after a successful "create- subscription". Therefore the reference text must be modified to also allow notification messages be sent after a successful "establish- subscription". Proposed text for bullet (2) of RFC-6241 would be: (2) The Messages layer provides a simple, transport-independent framing mechanism for encoding RPCs and notifications. Section 4 documents the RPC messages, [RFC5277] documents Notifications sent as a result of a RPC, and [RFC xxxx] documents Notifications sent as a result of an RPC. (where xxxx is replaced with this RFC number) I am not sure if this is correct. I don't think RFC editor can do the action you are asking them to do on their own. They would need an errata (which is not correct here) or another document that updates RFC 6241. In my view this document should just update RFC 6241 (and mark that in this document's header) and do necessary text changes to reflect that. Minor Issues: ------------- (1) Abstract & Introduction, It is not clear what does the 'binding' mean and who are the parties to this binding? If this is the document that mentions 'binding' first, so please add some more clarifying text. (2) Section 3, since you use MUST in the error handling, isn't it better to use normative in below sentence as well - OLD: However a single NETCONF transport session cannot support both this specification and a subscription established by [RFC5277]'s "create-subscription" RPC. NEW: However a single NETCONF transport session MUST NOT support both this specification and a subscription established by [RFC5277]'s "create-subscription" RPC. (3) Section 6, You have - And per [RFC5277]'s "eventTime" object definition, the "eventTime" MUST be populated with the event occurrence time. Is this a new requirement, or just re-stating RFC5277? RFC5277 says - eventTime The time the event was generated by the event source. This parameter is of type dateTime and compliant to [RFC3339]. Implementations must support time zones. Also contains notification-specific tagged content, if any. With the exception of , the content of the notification is beyond the scope of this document. Maybe remove MUST? If you are trying to refine the text from RFC5277, then please re-word. Nits: ----- (1) Abstract RFC Editor note: please replace the four references to pre-RFC normative drafts with the actual assigned RFC numbers. I see two drafts in the reference section. Why four? Also, since those two are normative references, these would be published as a cluster as a part of normal RFC editor processing right? (2) Regarding NETCONF, the RFC editor says [1] - NETCONF - Network Configuration Protocol (NETCONF) [Not typically expanded in titles, but expand in abstract] Please expand. (3) s/[I-D.draft-ietf-netconf-subscribed-notifications] /[I-D.ietf-netconf-subscribed-notifications] Just so that you have the same style of draft reference in the document. I get that it would be replaced with a RFC number anyways :) [1] https://www.rfc-editor.org/materials/abbrev.expansion.txt Thanks! Dhruv From nobody Tue Apr 30 01:32:14 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45CD21201EE; Tue, 30 Apr 2019 01:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxUC52CFGwCR; Tue, 30 Apr 2019 01:32:04 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50081.outbound.protection.outlook.com [40.107.5.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE923120099; Tue, 30 Apr 2019 01:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7ivYEiRFsFFnZmOPUGpk8tjbkmb3ATayHjsXMsbaTcw=; b=V62U2pkCUV4mVu8PyTU7SQvWcnqBxoz90zowqQOo8wV634cghK7x3PlSVlZIYRUDFTMDPoHiA3R0LhC1IRuUKwbyON27upp2kS3SNi3AIVxvPdAhyoKsiWPWx+W38knNySPRTeLkOFKlEDUnukL8PGGMwAq4p0S7LXIPNEoIbUQ= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2236.eurprd07.prod.outlook.com (10.168.31.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.5; Tue, 30 Apr 2019 08:32:00 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723%3]) with mapi id 15.20.1856.008; Tue, 30 Apr 2019 08:32:00 +0000 From: Magnus Westerlund To: "Eric Voit (evoit)" , Benjamin Kaduk CC: "draft-ietf-netconf-subscribed-notifications@ietf.org" , "netconf@ietf.org" , Kent Watsen , The IESG , "netconf-chairs@ietf.org" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-23: (with DISCUSS) Thread-Index: AQHU/rKtCIs3MFSYbUWn2jaVvwTXvw== Date: Tue, 30 Apr 2019 08:32:00 +0000 Message-ID: References: <155655963180.15870.3650019434718355043.idtracker@ietfa.amsl.com> <717530026d2d4af0a92c318ecbdbb4bd@XCH-RTP-013.cisco.com> <20190429182503.GC60332@kduck.mit.edu> <94d0b3e325ee46e283d84204243bdf69@XCH-RTP-013.cisco.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.82] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 31196258-8382-4824-f5d4-08d6cd465090 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2236; x-ms-traffictypediagnostic: HE1PR0701MB2236: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 00235A1EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(39860400002)(376002)(136003)(366004)(189003)(199004)(13464003)(74316002)(14444005)(81166006)(6116002)(3846002)(8936002)(476003)(81156014)(8676002)(66476007)(76116006)(66946007)(73956011)(66446008)(71200400001)(53936002)(5660300002)(52536014)(66556008)(256004)(64756008)(229853002)(6246003)(2906002)(478600001)(2171002)(110136005)(316002)(15650500001)(66066001)(6506007)(86362001)(53546011)(7696005)(26005)(14454004)(76176011)(68736007)(97736004)(186003)(54906003)(25786009)(99286004)(102836004)(33656002)(9686003)(6436002)(305945005)(71190400001)(55016002)(446003)(486006)(7736002)(4326008)(44832011)(93886005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2236; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: BPT0J8UhbjYLrpKWoXICC0PIAWhYj4ZaxgFY+gOFMRsFKppomp890g1ojL+sWAThml5j4GfDujO/4QUj4fyzsjXJPrJ7lQv2apcebyqwEF3e98PjlVBUMtok3sCaXZRMtA7Wwa12nw7tyZo/zYNcQjAZsWzU2O0s2bkLLSClpAQCA8dInOhu76Ecu+qKPPg6Z5gU/oi9LjDaz/6krqxnha5T6t5swYOvFX77HmtFB1m3gVOvHA5yvNOWvDn3tgWuelNu7q1gs9UXGBcyKd/DAseEcjkN9gMZ1U6ISNBwV9Dgi0vffPLSmy0Axn83Rls9nIKpdF9z3YZnCuAmxb+A4a6YtMgRw+UuZ5t4zNZr8MPCSaFGypsDq+jENCJ0j9QHE/pZJgZQfMeMp9UBUOJwTnXFrsHYSb2RuxLz9Zic4NQ= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 31196258-8382-4824-f5d4-08d6cd465090 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2019 08:32:00.1254 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2236 Archived-At: Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-23: (with DISCUSS) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 08:32:06 -0000 Hi,=0A= =0A= I think it should be avoided if possible to add the pre-5378=0A= boilerplate, it is better to get the rights. Especially in this=0A= situation where there has been many version published stating that the=0A= rights have been had. Is there a problem of getting the rights?=0A= =0A= Cheers=0A= =0A= Magnus=0A= =0A= On 2019-04-29 21:31, Eric Voit (evoit) wrote:=0A= > ipr=3D"pre5378Trust200902"=0A= >=0A= > change made and uploaded as v24=0A= >=0A= > Eric=0A= >=0A= >> From: Benjamin Kaduk, April 29, 2019 2:25 PM=0A= >>=0A= >> On Mon, Apr 29, 2019 at 05:58:19PM +0000, Eric Voit (evoit) wrote:=0A= >>> Hi Benjamin,=0A= >>>=0A= >>> I think you are asking why the following boilerplate text wasn't includ= ed...=0A= >>>=0A= >>> This document may contain material from IETF Documents or IETF=0A= >>> Contributions published or made publicly available before November= =0A= >>> 10, 2008. The person(s) controlling the copyright in some of this= =0A= >>> material may not have granted the IETF Trust the right to allow=0A= >>> modifications of such material outside the IETF Standards Process.= =0A= >>> Without obtaining an adequate license from the person(s) controlling= =0A= >>> the copyright in such materials, this document may not be modified= =0A= >>> outside the IETF Standards Process, and derivative works of it may= =0A= >>> not be created outside the IETF Standards Process, except to format= =0A= >>> it for publication as an RFC or to translate it into languages other= =0A= >>> than English.=0A= >> Exactly so.=0A= >>=0A= >>> This was likely an oversight during the initial author's submission. I= f this text=0A= >> was included and uploaded as a -24 update, would that cover your concern= ?=0A= >>=0A= >> Definitely.=0A= >> (Note that there's an XML keyword for this; IIRC, > ipr=3D"pre5378Trust200902">.)=0A= >>=0A= >>> BTW: the same boilerplate update should also be made to=0A= >>> draft-ietf-netconf-netconf-event-notification and=0A= >>> draft-ietf-netconf-restconf-notif=0A= >> Thanks for spotting those early!=0A= >>=0A= >> -Ben=0A= >>=0A= >>>=0A= >>>> -----Original Message-----=0A= >>>> From: Benjamin Kaduk via Datatracker =0A= >>>> Subject: Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-=0A= >>>> notifications-23: (with DISCUSS)=0A= >>>>=0A= >>>> --------------------------------------------------------------------= =0A= >>>> --=0A= >>>> DISCUSS:=0A= >>>> --------------------------------------------------------------------= =0A= >>>> --=0A= >>>>=0A= >>>> [putting this out early in the hopes it can be resolved quickly; I'm= =0A= >>>> just starting to review the document.]=0A= >>>>=0A= >>>> This document started life as a rfc5277bis, published in July 2008,=0A= >>>> before RFC=0A= >>>> 5378 (BCP 78) was published in November of 2008. If we are using=0A= >>>> any text from RFC 5277 and did not gain the additional rights=0A= >>>> declaration from the authors of that document, this document needs=0A= >>>> to use a different boilerplate text (the "pre- 2008" text). I look=0A= >>>> at the sibling document draft-ietf-netfonf-yang-push of this=0A= >>>> document, which does use the pre-2008 boilerplate, and am having a har= d=0A= >> time understanding why this document does not also have the pre-2008=0A= >> boilerplate.=0A= >>>>=0A= >>>>=0A= >=0A= =0A= -- =0A= =0A= Magnus Westerlund =0A= =0A= ----------------------------------------------------------------------=0A= Network Architecture & Protocols, Ericsson Research=0A= ----------------------------------------------------------------------=0A= Ericsson AB | Phone +46 10 7148287=0A= Torshamnsgatan 23 | Mobile +46 73 0949079=0A= SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A= ----------------------------------------------------------------------=0A= =0A= From nobody Tue Apr 30 04:30:27 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E971202C9 for ; Tue, 30 Apr 2019 04:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.022 X-Spam-Level: X-Spam-Status: No, score=-1.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQWJAC010wBr for ; Tue, 30 Apr 2019 04:30:22 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20044.outbound.protection.outlook.com [40.107.2.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4DCD12008C for ; Tue, 30 Apr 2019 04:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xvNmkILV0YV8EaIIQqf6WdtHyuSommOs3g1oMA8sByM=; b=mwLFwKlyTAknFelXD4ShAh1MePjTRpKpUBndLkCCHq8oyJTVm6aE0NAeyM8tuph8SlVWIRgPfLe6Ks3YhqxcjOKvZNqIjNNFamnxAs5Az423yFhPhCNQwpWdxyIlx9oSl3eig0jPrLe3Ake1+aG9WzdFqKjqIVQ/sWDvq0aNcsg= Received: from VI1PR07MB4735.eurprd07.prod.outlook.com (20.177.57.146) by VI1PR07MB4512.eurprd07.prod.outlook.com (20.177.56.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.4; Tue, 30 Apr 2019 11:30:19 +0000 Received: from VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::dc72:dfff:beb3:3b47]) by VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::dc72:dfff:beb3:3b47%7]) with mapi id 15.20.1856.008; Tue, 30 Apr 2019 11:30:19 +0000 From: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= To: Kent Watsen CC: Juergen Schoenwaelder , "netconf@ietf.org" Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpALufsOAAAVM5oADthG5oAAICCMAAAQfJ4AABQvugADqJOIAAAiERYAAKAZY4A== Date: Tue, 30 Apr 2019 11:30:19 +0000 Message-ID: References: <20190404164929.fsfga7s4izn7ucx5@anna.jacobs.jacobs-university.de> <20190404.194623.1178346313710501110.mbj@tail-f.com> <01dd01d4eb9c$b9a04160$4001a8c0@gateway.2wire.net> <20190405.142201.707949273328784535.mbj@tail-f.com> <413d5725-9c27-e50b-2622-1b0e2f35cdb1@ericsson.com> <0100016a5019d7f9-7f737c63-d07c-4c7f-b12e-c5b19d50eeaf-000000@email.amazonses.com> <20190424180513.gtxmreicd7iydrpr@anna.jacobs.jacobs-university.de> <0100016a510a3038-7671e146-e23f-4bc9-9f93-ea2314b5d4e7-000000@email.amazonses.com> <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com> In-Reply-To: <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4b3a0dad-175d-406a-8018-08d6cd5f39b0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB4512; x-ms-traffictypediagnostic: VI1PR07MB4512: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 00235A1EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(396003)(136003)(366004)(199004)(189003)(5660300002)(55016002)(316002)(4744005)(14454004)(102836004)(6506007)(54906003)(478600001)(52536014)(99286004)(186003)(53936002)(33656002)(790700001)(7736002)(6116002)(26005)(256004)(3846002)(9686003)(14444005)(66066001)(486006)(8676002)(2906002)(93886005)(6436002)(85202003)(81166006)(6306002)(86362001)(81156014)(68736007)(9326002)(25786009)(76176011)(97736004)(66556008)(476003)(71190400001)(54896002)(64756008)(66446008)(6246003)(66476007)(74316002)(76116006)(73956011)(71200400001)(66946007)(4326008)(8936002)(85182001)(446003)(229853002)(561944003)(7696005)(11346002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4512; H:VI1PR07MB4735.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: nLxyMHWkOl3nLfmRr0bOTsttXt+SUXRSEy/Nh0/vuUX3d59uIHCCy/7kBA7RGqUWDxfh8HnBVv073zK3a+7GVk3m57zgA/cNIC1r4hcPBHOC6nIz+xzgyE8w/2P/zQUGq3zFWbTf3ntfTaG3El2vNPVygQsXQHPFc8HroFnaYuwRJK/ehVCINhPmXznOfSvh2iI062W2/mWCOnojrOW7aPSw3Xyddk2kBMsnuYA7/7iaT82PXZdKelXDlmR6VNc7BoWgWoNT12PVxWmLgX5NgZ1PWy2F9RcZKOhjOPsn/LZRS7w5E9VHEpxEQcyzsDbpRoo/q4CzHLUKRd7oFT8gUAgF2ElmSHFt9TRsQpLwX77y5lBB5jZjw7TO5UpmRuxC0RPmGUfQTmF0YRXE8E7ULn11N7x85j8wnit+K2v0ypA= Content-Type: multipart/alternative; boundary="_000_VI1PR07MB47353B20AF138B5B8B702285833A0VI1PR07MB4735eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4b3a0dad-175d-406a-8018-08d6cd5f39b0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2019 11:30:19.1250 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4512 Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 11:30:26 -0000 --_000_VI1PR07MB47353B20AF138B5B8B702285833A0VI1PR07MB4735eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VudCwNCg0KSSBkb27igJl0IHNlZSB0aGUgeW91ciBwcm9wb3NhbCBiZWxvdyBhZGRyZXNz ZWQgaW4gbGF0ZXN0IHVwZGF0ZSAgKGtleXN0b3JlLTA5KS4gV2FzIGl0IG1pc3NlZD8NCg0KTXkg cmVjb21tZW5kYXRpb24gaXMgdG8gbW9kaWZ5IHRoZSAiZ2VuZXJhdGUvaW5zdGFsbC1oaWRkZW4t a2V5Ig0KKHJlbmFtZWQgdG8ganVzdCAiZ2VuZXJhdGUvaW5zdGFsbC1rZXkiKSBhY3Rpb25zIHRv IGhhdmUgYSBmbGFnIGluZGljYXRpbmcgaWYNCnRoZSBrZXkgc2hvdWxkIGJlICJwZXJtYW5lbnRs eSBoaWRkZW4iIChwZXJoYXBzIGJ5IHVzaW5nIGEgVFBNKSBvciBub3QsIGluDQp3aGljaCBjYXNl IGNvbmZpZ3VyYXRpb24gaXMgY3JlYXRlZCwgc2FtZSBhcyBpZiB0aGUgY2xpZW50IGhhZCB1c2Vk IDxlZGl0LQ0KY29uZmlnPiwgYnV0IHdpdGhvdXQgbmVlZGluZyB0byB0b3VjaCB0aGUga2V5Lg0K DQoNCkkgYWdyZWUgdGhhdCBoYXZpbmcgYSBmbGFnIHRvIGNvbnRyb2wgdGhlIGJlaGF2aW9yIGlz IHVzZWZ1bCBhbmQgSQ0KdGhpbmsgdGhlcmUgc2hvdWxkIGJlIGV4cGxpY2l0IHRleHQgaG93IHRo ZSBhY3Rpb24gZmFpbHMgaW4gY2FzZSB0aGUNCnJlcXVlc3RlZCBhY3Rpb24gY2Fubm90IGJlIHBl cmZvcm1lZC4NCg0KQnIsDQpCYWxhenMNCg== --_000_VI1PR07MB47353B20AF138B5B8B702285833A0VI1PR07MB4735eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBLZW50LDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGRvbuKAmXQgc2VlIHRoZSB5b3VyIHByb3Bvc2FsIGJlbG93IGFkZHJlc3NlZCBp biBsYXRlc3QgdXBkYXRlICZuYnNwOyhrZXlzdG9yZS0wOSkuIFdhcyBpdCBtaXNzZWQ/PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+TXkgcmVjb21tZW5k YXRpb24gaXMgdG8gbW9kaWZ5IHRoZSAmcXVvdDtnZW5lcmF0ZS9pbnN0YWxsLWhpZGRlbi1rZXkm cXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDoxLjBpbiI+KHJlbmFtZWQgdG8ganVzdCAmcXVvdDtnZW5lcmF0ZS9pbnN0YWxsLWtleSZx dW90OykgYWN0aW9ucyB0byBoYXZlIGEgZmxhZyBpbmRpY2F0aW5nIGlmPGJyPg0KdGhlIGtleSBz aG91bGQgYmUgJnF1b3Q7cGVybWFuZW50bHkgaGlkZGVuJnF1b3Q7IChwZXJoYXBzIGJ5IHVzaW5n IGEgVFBNKSBvciBub3QsIGluPGJyPg0Kd2hpY2ggY2FzZSBjb25maWd1cmF0aW9uIGlzIGNyZWF0 ZWQsIHNhbWUgYXMgaWYgdGhlIGNsaWVudCBoYWQgdXNlZCAmbHQ7ZWRpdC08YnI+DQpjb25maWcm Z3Q7LCBidXQgd2l0aG91dCBuZWVkaW5nIHRvIHRvdWNoIHRoZSBrZXkuPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PGJyPg0KSSBhZ3JlZSB0aGF0IGhhdmluZyBhIGZsYWcgdG8gY29udHJvbCB0aGUgYmVoYXZp b3IgaXMgdXNlZnVsIGFuZCBJPGJyPg0KdGhpbmsgdGhlcmUgc2hvdWxkIGJlIGV4cGxpY2l0IHRl eHQgaG93IHRoZSBhY3Rpb24gZmFpbHMgaW4gY2FzZSB0aGU8YnI+DQpyZXF1ZXN0ZWQgYWN0aW9u IGNhbm5vdCBiZSBwZXJmb3JtZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJyLDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFsYXpzPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_VI1PR07MB47353B20AF138B5B8B702285833A0VI1PR07MB4735eurp_-- From nobody Tue Apr 30 05:03:57 2019 Return-Path: <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99A512004F for ; Tue, 30 Apr 2019 05:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laWoIQVQ7zHv for ; Tue, 30 Apr 2019 05:03:51 -0700 (PDT) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75497120045 for ; Tue, 30 Apr 2019 05:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556625830; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=jC0BAQjrdLnCyaFqzkz9um3S84pA54ZCKE1bL/qz1iw=; b=baFIdcPwNW48ENLuxKQG4Q4J+2IVu540j+XK0hXs+qzR23QN0W+N/QQzpfNHVnYK +wdMihPUt+D0ipwDxV2cIxP42M/d0BY0hLMKU02oKVnN2cPOnvoNyEjt95iL2sYRjDA yL1rEsICmEAkEM8xekXLAx2bgTuexgLmeFtGenXY= Content-Type: multipart/alternative; boundary=Apple-Mail-2DBF3C4E-7DA7-403A-A52B-12647CDE84B1 Mime-Version: 1.0 (1.0) From: Kent Watsen X-Mailer: iPad Mail (16E227) In-Reply-To: Date: Tue, 30 Apr 2019 12:03:50 +0000 Cc: Juergen Schoenwaelder , "netconf@ietf.org" Content-Transfer-Encoding: 7bit Message-ID: <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> References: <20190404164929.fsfga7s4izn7ucx5@anna.jacobs.jacobs-university.de> <20190404.194623.1178346313710501110.mbj@tail-f.com> <01dd01d4eb9c$b9a04160$4001a8c0@gateway.2wire.net> <20190405.142201.707949273328784535.mbj@tail-f.com> <413d5725-9c27-e50b-2622-1b0e2f35cdb1@ericsson.com> <0100016a5019d7f9-7f737c63-d07c-4c7f-b12e-c5b19d50eeaf-000000@email.amazonses.com> <20190424180513.gtxmreicd7iydrpr@anna.jacobs.jacobs-university.de> <0100016a510a3038-7671e146-e23f-4bc9-9f93-ea2314b5d4e7-000000@email.amazonses.com> <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com> To: =?utf-8?Q?Bal=C3=A1zs_Kov=C3=A1cs?= X-SES-Outgoing: 2019.04.30-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 12:03:54 -0000 --Apple-Mail-2DBF3C4E-7DA7-403A-A52B-12647CDE84B1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Correct, as I didn=E2=80=99t think there was consensus yet. Perhaps there i= s rough-consensus, and it may be that the only way to gauge that is to try a= nd see how much push back there is. Okay, so how about this, based on this thread, there appears to be support t= o add a flag to control if a key should be =E2=80=9Cpermanently hidden=E2=80= =9D or not, in which case configuration is created. This change will be in the next update, in about a week=E2=80=99s time, if n= o objections are raised. Kent // contributor > On Apr 30, 2019, at 7:30 AM, Bal=C3=A1zs Kov=C3=A1cs wrote: >=20 > Hi Kent, > =20 > I don=E2=80=99t see the your proposal below addressed in latest update (k= eystore-09). Was it missed? > =20 > My recommendation is to modify the "generate/install-hidden-key" > (renamed to just "generate/install-key") actions to have a flag indicating= if > the key should be "permanently hidden" (perhaps by using a TPM) or not, in= > which case configuration is created, same as if the client had used config>, but without needing to touch the key. >=20 >=20 > I agree that having a flag to control the behavior is useful and I > think there should be explicit text how the action fails in case the > requested action cannot be performed. > =20 > Br, > Balazs --Apple-Mail-2DBF3C4E-7DA7-403A-A52B-12647CDE84B1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Correct, as I didn=E2=80=99t= think there was consensus yet.  Perhaps there is rough-consensus, and i= t may be that the only way to gauge that is to try and see how much push bac= k there is.

Okay, so how about this, based on this thread= , there appears to be support to add a flag to control if a key should be =E2= =80=9Cpermanently hidden=E2=80=9D or not, in which case configuration is cre= ated.

This change will be in the next update, in ab= out a week=E2=80=99s time, if no objections are raised.

=
Kent // contributor


= On Apr 30, 2019, at 7:30 AM, Bal=C3=A1zs Kov=C3=A1cs <balazs.kovacs@ericsson.com> wrote:

=

Hi Kent,

 

I don=E2=80=99t see the your proposal below addressed= in latest update  (keystore-09). Was it missed?

 

My recommendation is to m= odify the "generate/install-hidden-key"

(renamed to just "generat= e/install-key") actions to have a flag indicating if
the key should be "permanently hidden" (perhaps by using a TPM) or not, in which case configuration is created, same as if the client had used <edit= -
config>, but without needing to touch the key.


I agree that having a flag to control the behavior is useful and I
think there should be explicit text how the action fails in case the
requested action cannot be performed.

 

Br,

Balazs

= --Apple-Mail-2DBF3C4E-7DA7-403A-A52B-12647CDE84B1-- From nobody Tue Apr 30 05:49:37 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6B212001B for ; Tue, 30 Apr 2019 05:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riW4Rth_wjix for ; Tue, 30 Apr 2019 05:49:33 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7996F120006 for ; Tue, 30 Apr 2019 05:49:33 -0700 (PDT) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id AD2B21AE0589; Tue, 30 Apr 2019 14:49:30 +0200 (CEST) Date: Tue, 30 Apr 2019 14:49:30 +0200 (CEST) Message-Id: <20190430.144930.844252169549242587.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: balazs.kovacs@ericsson.com, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> References: <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com> <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 12:49:36 -0000 S2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0PiB3cm90ZToNCj4gDQo+IENvcnJlY3Qs IGFzIEkgZGlkbuKAmXQgdGhpbmsgdGhlcmUgd2FzIGNvbnNlbnN1cyB5ZXQuICBQZXJoYXBzIHRo ZXJlIGlzDQo+IHJvdWdoLWNvbnNlbnN1cywgYW5kIGl0IG1heSBiZSB0aGF0IHRoZSBvbmx5IHdh eSB0byBnYXVnZSB0aGF0IGlzIHRvDQo+IHRyeSBhbmQgc2VlIGhvdyBtdWNoIHB1c2ggYmFjayB0 aGVyZSBpcy4NCj4gDQo+IE9rYXksIHNvIGhvdyBhYm91dCB0aGlzLCBiYXNlZCBvbiB0aGlzIHRo cmVhZCwgdGhlcmUgYXBwZWFycyB0byBiZQ0KPiBzdXBwb3J0IHRvIGFkZCBhIGZsYWcgdG8gY29u dHJvbCBpZiBhIGtleSBzaG91bGQgYmUg4oCccGVybWFuZW50bHkNCj4gaGlkZGVu4oCdIG9yIG5v dCwgaW4gd2hpY2ggY2FzZSBjb25maWd1cmF0aW9uIGlzIGNyZWF0ZWQuDQoNCkkgKHN0aWxsKSBv YmplY3QgdG8gdGhpcy4gIEFjdGlvbnMgc2hvdWxkbid0IGNyZWF0ZSBjb25maWcuICBXZQ0KYWxy ZWFkeSBoYXZlIGdlbmVyaWMgcHJvdGNvbCBvcGVyYXRpb25zIHRvIGRvIHRoaXMuICBXZSBnbyBm cm9tIGENCmRvY3VtZW50LW9yaWVudGVkIGNvbmZpZ3VyYXRpb24gbW9kZWwgdG93YXJkcyBhIGNv bW1hbmQtb3JpZW50ZWQNCm1vZGVsLiAgTm90IGdvb2QuICBJbiBSRVNUQ09ORiwgdGhlIGdlbmVy aWMgbWV0aG9kcyBzdXBwb3J0IHRoaW5ncw0KbGlrZSBFVGFncywgd2hpY2ggSSBzdXNwZWN0IHlv dSBkb24ndCB3YW50IHRvIHJlcGxpY2F0ZSBpbiB0aGlzDQphY3Rpb24/ICAgV2lsbCB0aGUgYWN0 aW9uIHN1cHBvcnQgYWxsIGVycm9yLW9wdGlvbnMgb2YgZWRpdC1jb25maWcsDQpsaWtlIHJvbGxi YWNrLW9uLWVycm9yPw0KDQoNClNvbWUgY29tbWVudHMgb24gdGhlIG5ldyB0ZXh0Og0KDQpJbiBh Y3Rpb24gZ2VuZXJhdGUtaGlkZGVuLWtleSwgaXQgc2hvdWxkIGJlIHN0YXRlZCB0aGF0IHRoZSBw dWJsaWMta2V5DQp3aWxsIGJlIHBvcHVsYXRlZCwgYW5kIHRoYXQgdGhlIHByaXZhdGUta2V5IHdp bGwgZXhpc3QgYnV0IHJlcG9ydA0KJ3Blcm1hbmVudGx5LWhpZGRlbicuDQoNCkluIGFjdGlvbiBp bnN0YWxsLWhpZGRlbi1rZXksIHNob3VsZG4ndCBib3RoIHB1YmxpYy1rZXkgYW5kDQpwcml2YXRl LWtleSBiZSBtYW5kYXRvcnk/ICBBbHNvIHN0YXRlIHRoYXQgdGhlIHByaXZhdGUta2V5IHdpbGwg cmVwb3J0DQoncGVybWFuZW50bHktaGlkZGVuJy4NCg0KSW4gbGVhZiBwcml2YXRlLWtleSwgdGhl IHR5cGUgYmluYXJ5IHBhcnQgb2YgdGhlIHVuaW9uIGRvZXNuJ3QgaGF2ZSBhDQpkZXNjcmlwdGlv biwgYW5kIHRoZSBkZXNjcmlwdGlvbiBmb3IgdGhlIGxlYWYgaXRzZWxmIHNheXM6DQoNCiAgICAg ICBBIGJpbmFyeSB0aGF0IGNvbnRhaW5zIHRoZSB2YWx1ZSBvZiB0aGUgcHJpdmF0ZSBrZXkuDQoN CndoaWNoIGlzIG5vdCBxdWl0ZSBjb3JyZWN0Lg0KDQpJIHRoaW5rIHdlIHNob3VsZCBzdGF0ZSB0 aGF0IHRoZSBlbnVtICdwZXJtYW5lbnRseS1oaWRkZW4nIGlzIG9ubHkNCnJlcG9ydGVkIGluIG9w ZXJhdGlvbmFsIHN0YXRlLg0KDQpUaGUgbmV3IGRlc2NyaXB0aW9ucyBzYXk6DQoNCiAgICAgICAg ICAgIFsuLi5dIHByZXNlbnQgb25seSBpbg0KICAgICAgICAgICAgPG9wZXJhdGlvbmFsPiBhbmQg Ym91bmQgdG8gdGhlIGxpZmV0aW1lIG9mIHRoZSBwYXJlbnQNCiAgICAgICAgICAgICdjb25maWcg dHJ1ZScgbm9kZS4NCg0KQXJlbid0IGFsbCBub2RlcyBib3VuZCB0byB0aGUgbGlmZXRpbWUgb2Yg dGhlaXIgcGFyZW50Pw0KVGhlIGFjdGlvbiBpcyBpbnZva2VkIGluIGEgbm9kZSB0aGF0IGV4aXN0 cyBpbiA8b3BlcmF0aW9uYWw+IGFuZCBpdA0KY3JlYXRlcyBhIGtleS4gIFdoYXQgZG9lcyB0aGUg c3RhdGVtZW50IHRlbGwgbWU/DQoNCg0KL21hcnRpbg0KDQoNCg0KPiANCj4gVGhpcyBjaGFuZ2Ug d2lsbCBiZSBpbiB0aGUgbmV4dCB1cGRhdGUsIGluIGFib3V0IGEgd2Vla+KAmXMgdGltZSwgaWYg bm8NCj4gb2JqZWN0aW9ucyBhcmUgcmFpc2VkLg0KPiANCj4gS2VudCAvLyBjb250cmlidXRvcg0K PiANCj4gDQo+ID4gT24gQXByIDMwLCAyMDE5LCBhdCA3OjMwIEFNLCBCYWzDoXpzIEtvdsOhY3MN Cj4gPiA8YmFsYXpzLmtvdmFjc0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPiA+IA0KPiA+IEhpIEtl bnQsDQo+ID4gIA0KPiA+IEkgZG9u4oCZdCBzZWUgdGhlIHlvdXIgcHJvcG9zYWwgYmVsb3cgYWRk cmVzc2VkIGluIGxhdGVzdCB1cGRhdGUNCj4gPiAoa2V5c3RvcmUtMDkpLiBXYXMgaXQgbWlzc2Vk Pw0KPiA+ICANCj4gPiBNeSByZWNvbW1lbmRhdGlvbiBpcyB0byBtb2RpZnkgdGhlICJnZW5lcmF0 ZS9pbnN0YWxsLWhpZGRlbi1rZXkiDQo+ID4gKHJlbmFtZWQgdG8ganVzdCAiZ2VuZXJhdGUvaW5z dGFsbC1rZXkiKSBhY3Rpb25zIHRvIGhhdmUgYSBmbGFnDQo+ID4gaW5kaWNhdGluZyBpZg0KPiA+ IHRoZSBrZXkgc2hvdWxkIGJlICJwZXJtYW5lbnRseSBoaWRkZW4iIChwZXJoYXBzIGJ5IHVzaW5n IGEgVFBNKSBvcg0KPiA+IG5vdCwgaW4NCj4gPiB3aGljaCBjYXNlIGNvbmZpZ3VyYXRpb24gaXMg Y3JlYXRlZCwgc2FtZSBhcyBpZiB0aGUgY2xpZW50IGhhZCB1c2VkDQo+ID4gPGVkaXQtDQo+ID4g Y29uZmlnPiwgYnV0IHdpdGhvdXQgbmVlZGluZyB0byB0b3VjaCB0aGUga2V5Lg0KPiA+IA0KPiA+ IA0KPiA+IEkgYWdyZWUgdGhhdCBoYXZpbmcgYSBmbGFnIHRvIGNvbnRyb2wgdGhlIGJlaGF2aW9y IGlzIHVzZWZ1bCBhbmQgSQ0KPiA+IHRoaW5rIHRoZXJlIHNob3VsZCBiZSBleHBsaWNpdCB0ZXh0 IGhvdyB0aGUgYWN0aW9uIGZhaWxzIGluIGNhc2UgdGhlDQo+ID4gcmVxdWVzdGVkIGFjdGlvbiBj YW5ub3QgYmUgcGVyZm9ybWVkLg0KPiA+ICANCj4gPiBCciwNCj4gPiBCYWxhenMNCg== From nobody Tue Apr 30 06:14:50 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8316B12001B; Tue, 30 Apr 2019 06:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjOVBuOUJ6rT; Tue, 30 Apr 2019 06:14:46 -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 C3D1E120006; Tue, 30 Apr 2019 06:14:46 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 84CFBB820EE; Tue, 30 Apr 2019 06:14:35 -0700 (PDT) To: andy@yumaworks.com, andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: ibagdona@gmail.com, iesg@ietf.org, netconf@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190430131435.84CFBB820EE@rfc-editor.org> Date: Tue, 30 Apr 2019 06:14:35 -0700 (PDT) Archived-At: Subject: [netconf] [Errata Verified] RFC8040 (5504) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 13:14:49 -0000 The following errata report has been verified for RFC8040, "RESTCONF Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5504 -------------------------------------- Status: Verified Type: Editorial Reported by: Andy Bierman Date Reported: 2018-09-22 Verified by: Ignas Bagdonas (IESG) Section: B.3.8 Original Text ------------- GET /mystreams/NETCONF?start-time=2014-10-25T10%3A02%3A00Z\ &stop-time=2014-10-25T12%3A31%3A00Z Corrected Text -------------- GET /streams/NETCONF?start-time=2014-10-25T10%3A02%3A00Z\ &stop-time=2014-10-25T12%3A31%3A00Z Notes ----- The node 'mystreams' is incorrect. -------------------------------------- RFC8040 (draft-ietf-netconf-restconf-18) -------------------------------------- Title : RESTCONF Protocol Publication Date : January 2017 Author(s) : A. Bierman, M. Bjorklund, K. Watsen Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Apr 30 07:45:46 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B31E712004E; Tue, 30 Apr 2019 07:45:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-netconf-yang-push@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <155663553672.13008.11692876138086440730.idtracker@ietfa.amsl.com> Date: Tue, 30 Apr 2019 07:45:36 -0700 Archived-At: Subject: [netconf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-netconf-yang-push-22=3A_=28with_COMMENT=29?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 14:45:37 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-netconf-yang-push-22: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A small comment/question mostly regarding section 3.4: I wondering what happens if the system crashes or is in a state where not even a notification can be sent anymore...? Is the assumption that a crash could be detected because the transport connection goes away? However, that would mean that there is requirement that the transport must be connection-oriented and maybe also support some kind of keep-alive mechanism. Given this document tries to be transport-agnostic (as it relies on I-D.draft-ietf-netconf-subscribed-notifications), I don't think that is a safe assumption and should at least be further discussed. My understanding was that I-D.draft-ietf-netconf-subscribed-notifications assumes an active connection for dynamic subscriptions, but I guess this does not have to be the case for a configured subscription...? Also there seems to be an implicit assumption that the chosen transport is reliable in order for the system to work as expected. If that is the case, I think that it could be good to spelled that out in the document as a requirement as well. I guess all transports available today for YANG (NETCONF/RETSCONF) are reliable but that might not be the case in future. From nobody Tue Apr 30 08:40:10 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA051202D6 for ; Tue, 30 Apr 2019 08:40:00 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 oohaALrOJd4H for ; Tue, 30 Apr 2019 08:39:59 -0700 (PDT) Received: from us-smtp-delivery-128.mimecast.com (us-smtp-delivery-128.mimecast.com [216.205.24.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 039F91202DB for ; Tue, 30 Apr 2019 08:39:57 -0700 (PDT) Received: from ex-hc2.corp.adtran.com (ex-hc3.adtran.com [76.164.174.83]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-17-Ca9LWsK4OA68MqxobueGpQ-1; Tue, 30 Apr 2019 11:39:55 -0400 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc2.corp.adtran.com ([fe80::a019:449b:3f62:28e5%10]) with mapi id 14.03.0382.000; Tue, 30 Apr 2019 10:39:54 -0500 From: Nick Hancock To: Kent Watsen , "netconf@ietf.org" Thread-Topic: [netconf] draft-ietf-netconf-keystore-09.txt Thread-Index: AdT/Ypeae5Jx2/tnSQGaoI1kbpVxTQ== Date: Tue, 30 Apr 2019 15:39:53 +0000 Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0FEVFJBTiIsImlkIjoiM2EwMWQ4OWUtZThkNC00YjMzLWE2MTMtMGM3ZTA3Y2E5MTVhIiwicHJvcHMiOlt7Im4iOiJDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiR0IifV19LHsibiI6IlF1ZXN0aW9uMSIsInZhbHMiOltdfSx7Im4iOiJRdWVzdGlvbjIiLCJ2YWxzIjpbXX0seyJuIjoiUXVlc3Rpb24zIiwidmFscyI6W119XX0sIlN1YmplY3RMYWJlbHMiOltdLCJUTUNWZXJzaW9uIjoiMTcuMi4xMS4wIiwiVHJ1c3RlZExhYmVsSGFzaCI6IjE2UXV4ZGlKcXY4MHd0dmdxVnptZjBkSkh0OWk1K1BKS2JBcnZ6bzZlUmRFTExpbE51MGxPUVBxbWF0azFXUjYifQ== x-originating-ip: [172.20.48.41] x-c2processedorg: 13f501ad-3ef3-410f-a3f9-976ea23ce952 MIME-Version: 1.0 X-MC-Unique: Ca9LWsK4OA68MqxobueGpQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [netconf] draft-ietf-netconf-keystore-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 15:40:09 -0000 Hi Kent, I have just noticed a issue with the leaf 'keystore-reference' used=20 in the grouping 'local-or-keystore-end-entity-cert-with-key-grouping'=20 in ietf-keystore. This leafref uses the typedef 'asymmetric-key-certificate-ref', but,=20 unless I am missing something, this alone will not work, because a=20 predicate for the list 'asymmetric-key' is missing.=20 I would expect something like the following: case keystore { if-feature "keystore-supported"; leaf asymmetric-key-name { type ks:asymmetric-key-ref; description "A reference to an asymmetric key that exists in the keystore. ";=20 } leaf certificate-name { type leafref { path=20 "/ks:keystore" + "/ks:asymmetric-keys" + "/ks:asymmetric-key" + "[ks:name=3Dcurrent()/../"=20 + "asymmetric-key-name]"=20 + "/ks:certificates"=20 + "/ks:certificate/ks:name"; } description "A reference to a specific certificate associated=20 with the given private key, stored in the keystore."; =20 } } Regards Nick From nobody Tue Apr 30 09:12:31 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571771201F8 for ; Tue, 30 Apr 2019 09:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzoAGUJTclb7 for ; Tue, 30 Apr 2019 09:12:26 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA79120193 for ; Tue, 30 Apr 2019 09:12:26 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 39D06B62; Tue, 30 Apr 2019 18:12:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id E2lx97uUd5E0; Tue, 30 Apr 2019 18:12:25 +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 atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 30 Apr 2019 18:12:25 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1AF51200E0; Tue, 30 Apr 2019 18:12:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id APC4zjSxP8ui; Tue, 30 Apr 2019 18:12:24 +0200 (CEST) Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id A0880200DE; Tue, 30 Apr 2019 18:12:24 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Tue, 30 Apr 2019 18:12:24 +0200 Received: by anna.localdomain (Postfix, from userid 501) id B36063008A3970; Tue, 30 Apr 2019 18:12:23 +0200 (CEST) Date: Tue, 30 Apr 2019 18:12:23 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund CC: , Message-ID: <20190430161223.cwqfsyyxbtnkqbl7@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Martin Bjorklund , kent+ietf@watsen.net, netconf@ietf.org References: <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com> <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> <20190430.144930.844252169549242587.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <20190430.144930.844252169549242587.mbj@tail-f.com> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 16:12:29 -0000 On Tue, Apr 30, 2019 at 02:49:30PM +0200, Martin Bjorklund wrote: > Kent Watsen wrote: > >=20 > > Correct, as I didn=E2=80=99t think there was consensus yet. Perhaps = there is > > rough-consensus, and it may be that the only way to gauge that is to > > try and see how much push back there is. > >=20 > > Okay, so how about this, based on this thread, there appears to be > > support to add a flag to control if a key should be =E2=80=9Cpermanen= tly > > hidden=E2=80=9D or not, in which case configuration is created. >=20 > I (still) object to this. Actions shouldn't create config. We > already have generic protcol operations to do this. We go from a > document-oriented configuration model towards a command-oriented > model. Not good. In RESTCONF, the generic methods support things > like ETags, which I suspect you don't want to replicate in this > action? Will the action support all error-options of edit-config, > like rollback-on-error? > Martin, do you have any proposal how to support the requirement to generate a key on the device that is workable with a document-oriented configuration model? Do you propose that the action/rpc returns the public key information as result data that then needs to be written back to the server and somehow matched to the key that is cached on the device? Perhaps you have other ideas I can't think of? I think I would be happy to not have this special hack but then we need a workable alternative. Key generation on devices is something that is being used - and may be even more used in the future the more we get special hardware support for storing keys. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Apr 30 09:21:07 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5FF1202DF; Tue, 30 Apr 2019 09:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9p5NpI8exG2A; Tue, 30 Apr 2019 09:20:55 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 926961202CC; Tue, 30 Apr 2019 09:20:55 -0700 (PDT) Received: from LAPTOPR7T053C2 ([73.189.160.186]) by mrelay.perfora.net (mreueus001 [74.208.5.2]) with ESMTPSA (Nemesis) id 0LtH6j-1gcB761oHD-012qQK; Tue, 30 Apr 2019 18:20:47 +0200 From: "Alexander Clemm" To: =?utf-8?Q?'Mirja_K=C3=BChlewind'?= , "'The IESG'" Cc: , "'Kent Watsen'" , , References: <155663553672.13008.11692876138086440730.idtracker@ietfa.amsl.com> In-Reply-To: <155663553672.13008.11692876138086440730.idtracker@ietfa.amsl.com> Date: Tue, 30 Apr 2019 09:20:45 -0700 Message-ID: <03da01d4ff70$ac029f20$0407dd60$@clemm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJLjYSl5UyY4DNo/EqwcNAwrUcmOaVnxaVA Content-Language: en-us X-Provags-ID: V03:K1:KJ4VRkQTIP/uTqSlEYjKBQA2pGmF/I5aIGlbCCHJBb5Kgvkaq0w qy4SHhRndxlbFctYUeLKKifAaJKN6Mixt+8oY37mUdh4VyVmjLg4pK6RZuVLiYuY8jDW4uB eP6hQfLy2FZoqdsok7iDTRhYAmwPAKYGFFtqK4GHXyudHEYExn2UiwyJV8hxFKSrAAjUg4l foausNVZWpD4JXDQjqOng== X-UI-Out-Filterresults: notjunk:1;V03:K0:kNtfRAw7voQ=:pHRhRE5Zm2NKdpD4cds9t6 6eZEECU/ClhxNNF8M0bLdR5Eq/FkdfSdBc4faT9v9BlrSTehK+AYHHUaURxLRG7ZN0+U3fKgN lYPKjKlD4Kqw3/AWCCHZocu0QefwAXn5OPIFesPdmERNacGQ0MrJrKgHnfT2KSlc4U2IeY9iv /2kQ7XEmgQgYA2YfCh+OK4STdBnUBEhSigydx+oMHFCCm0L4uE8btrWR63kBqTMaSgGahe+Yh gdD1Fdvm66kzqNVZlxu/uL82AyGbr8jsArpIs8Q+qow8cRfAp0TDURGzS6Vut706A4WMHzYqn 651fSJzyvu9IwXiA5x0x4TELOmKjsYb9Gj2EeLyHASPXg4WfwP0i1khfIcCmBUgT0koDLjQqX nQYii2mJubicc7TElq31Xj//yl1CuEiIVXZ3R4d5x5lv/mtjrFKc3B5OlWJfwNYV7ltyRCAi4 DDmFI5j1zywSa72mmkHx20SQIFijQX+0GZL67oFVbKKkwKHVep0+qffSkGdeyATGFpIDJrG/x TtUpHlYvrqlPIR5NB63oDnGyuFma7jsYFm74BvXr9TubrnFaA4BYOovPFzZQcN4hHqrCr4vus a9Cf5uP8GsQEfkKHwcUm0C1nYxYncngKDffV5TnZlu0v6kCYG1gTrRYIg4ZFnF638MxK9xXGW f+fU93tcWVW7gi8pnR+pK22llp7qD6EJdPU+1uX5ZTcxPbez60HTT397Zz9iayRsWnZeQyDZt l+aOHbXA/399QeFn1vm/C/743l8GQtL5UXO/oP7LICk+HQqqP3FzkCe3P7Y= Archived-At: Subject: Re: [netconf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-netconf-yang-push-22=3A_=28with_COMMENT=29?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 16:20:59 -0000 Hello Mirja,=20 Thank you for your review! Response inline, --- Alex -----Original Message----- From: Mirja K=C3=BChlewind via Datatracker =20 Sent: Tuesday, April 30, 2019 7:46 AM To: The IESG Cc: draft-ietf-netconf-yang-push@ietf.org; Kent Watsen = ; netconf-chairs@ietf.org; kent+ietf@watsen.net; = netconf@ietf.org Subject: Mirja K=C3=BChlewind's No Objection on = draft-ietf-netconf-yang-push-22: (with COMMENT) Mirja K=C3=BChlewind has entered the following ballot position for draft-ietf-netconf-yang-push-22: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A small comment/question mostly regarding section 3.4: I wondering what happens if the system crashes or is in a state where = not even a notification can be sent anymore...? Is the assumption that a = crash could be detected because the transport connection goes away? = However, that would mean that there is requirement that the transport = must be connection-oriented and maybe also support some kind of = keep-alive mechanism. Given this document tries to be transport-agnostic = (as it relies on I-D.draft-ietf-netconf-subscribed-notifications), I = don't think that is a safe assumption and should at least be further = discussed. My understanding was that = I-D.draft-ietf-netconf-subscribed-notifications assumes an active = connection for dynamic subscriptions, but I guess this does not have to = be the case for a configured subscription...? Also there seems to be an implicit assumption that the chosen transport = is reliable in order for the system to work as expected. If that is the = case, I think that it could be good to spelled that out in the document = as a requirement as well. I guess all transports available today for = YANG (NETCONF/RETSCONF) are reliable but that might not be the case in = future. =20 Your comment is implied by the fact that the solution builds on = subscribed-notifications, which spells this out very clearly (e.g. in = section 1.3 there). To make it clearer, we can add the following text = to address your concern: "The solution builds on . As = defined there, any loss of underlying transport connection will be = detected and result in subscription termination (in case of dynamic = subscriptions) or suspension (in case of configured subscriptions), = ensuring that situations will not occur in which the loss of update = notifications would go unnoticed." From nobody Tue Apr 30 09:21:39 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435691202E2; Tue, 30 Apr 2019 09:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LshFLEi3Xdsl; Tue, 30 Apr 2019 09:21:34 -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 1B7BD1202E0; Tue, 30 Apr 2019 09:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4604; q=dns/txt; s=iport; t=1556641294; x=1557850894; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jaSonJCP7nmFX+yq7uI5bZuOkk+DhfuZYipT8lbqstY=; b=NPuBkXtkbqrW+M+jgvL/VJoeR9lkzLF2qnSHebzex2AI1w2w8RjkN8Xf /xDw2EmT8TNI8MFVTG5yvzxvm7h7nEOOvd8PTFhMU1SGtPqcfQKVjUN0k dd5F1/kojtcck45TsMcyONHt831j0tfcjnIAoiloNFzhijy3oDesnnnXe s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADMdMhc/5ldJa1mDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYFmKoE9MCgKjCKNFJhQFIFnDgEBhG0?= =?us-ascii?q?ChjEjNAkOAQMBAQQBAQIBAm0ohUoBAQEDAToyBgQBAgUHAgICAQgSAwIBHgk?= =?us-ascii?q?HGxcUAwYIAgQBDQUIEYI+gkcPsB+KNAWBLQGLSReBQD+BEYMSPoQJhh0Eiwi?= =?us-ascii?q?bfAkCggmOb4NDI4INkyKMDoEekFSCXwIRFYEwHziBVnAVgyeCGxcUbQEJjFk?= =?us-ascii?q?7QTGTFoEhAQE?= X-IronPort-AV: E=Sophos;i="5.60,414,1549929600"; d="scan'208";a="549150377" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Apr 2019 16:21:32 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x3UGLW5W024601 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Apr 2019 16:21:32 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 30 Apr 2019 12:21:31 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Tue, 30 Apr 2019 12:21:31 -0400 From: "Eric Voit (evoit)" To: Magnus Westerlund , Benjamin Kaduk CC: "draft-ietf-netconf-subscribed-notifications@ietf.org" , "netconf@ietf.org" , Kent Watsen , The IESG , "netconf-chairs@ietf.org" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-23: (with DISCUSS) Thread-Index: AQHU/rKoAXBzztdqKUKWeXbDQMBk+KZUvwVA Date: Tue, 30 Apr 2019 16:21:31 +0000 Message-ID: References: <155655963180.15870.3650019434718355043.idtracker@ietfa.amsl.com> <717530026d2d4af0a92c318ecbdbb4bd@XCH-RTP-013.cisco.com> <20190429182503.GC60332@kduck.mit.edu> <94d0b3e325ee46e283d84204243bdf69@XCH-RTP-013.cisco.com> 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.233] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.151, xch-rtp-011.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-23: (with DISCUSS) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 16:21:37 -0000 > From: Magnus Westerlund, April 30, 2019 4:32 AM >=20 > Hi, >=20 > I think it should be avoided if possible to add the pre-5378 boilerplate,= it is better > to get the rights. Especially in this situation where there has been many= version > published stating that the rights have been had. Is there a problem of ge= tting the > rights? Hi Magnus, Here is the current status... There are no full sentences from RFC-5277 used in this document. However t= here are a few sentence fragments in the terminology, as well as quite a fe= w concepts adopted based on RFC5277. On the basis of that Benjamin's DISCU= SS however, it felt like we should err on the side of caution by adding his= suggestion. =20 Along with this, at the end of 2016 the original authors of RFC-5277 (Sharo= n & Hector) stated they no longer needed to be on this draft. I haven't be= en in contact with them since. So without a relationship here, it seemed l= ike the including the "pre5378Trust200902" text was again erring on the sid= e of caution. Eric > Cheers >=20 > Magnus >=20 > On 2019-04-29 21:31, Eric Voit (evoit) wrote: > > ipr=3D"pre5378Trust200902" > > > > change made and uploaded as v24 > > > > Eric > > > >> From: Benjamin Kaduk, April 29, 2019 2:25 PM > >> > >> On Mon, Apr 29, 2019 at 05:58:19PM +0000, Eric Voit (evoit) wrote: > >>> Hi Benjamin, > >>> > >>> I think you are asking why the following boilerplate text wasn't incl= uded... > >>> > >>> This document may contain material from IETF Documents or IETF > >>> Contributions published or made publicly available before November > >>> 10, 2008. The person(s) controlling the copyright in some of this > >>> material may not have granted the IETF Trust the right to allow > >>> modifications of such material outside the IETF Standards Process. > >>> Without obtaining an adequate license from the person(s) controlli= ng > >>> the copyright in such materials, this document may not be modified > >>> outside the IETF Standards Process, and derivative works of it may > >>> not be created outside the IETF Standards Process, except to forma= t > >>> it for publication as an RFC or to translate it into languages oth= er > >>> than English. > >> Exactly so. > >> > >>> This was likely an oversight during the initial author's submission. > >>> If this text > >> was included and uploaded as a -24 update, would that cover your conce= rn? > >> > >> Definitely. > >> (Note that there's an XML keyword for this; IIRC, >> ipr=3D"pre5378Trust200902">.) > >> > >>> BTW: the same boilerplate update should also be made to > >>> draft-ietf-netconf-netconf-event-notification and > >>> draft-ietf-netconf-restconf-notif > >> Thanks for spotting those early! > >> > >> -Ben > >> > >>> > >>>> -----Original Message----- > >>>> From: Benjamin Kaduk via Datatracker > >>>> Subject: Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed- > >>>> notifications-23: (with DISCUSS) > >>>> > >>>> ------------------------------------------------------------------- > >>>> - > >>>> -- > >>>> DISCUSS: > >>>> ------------------------------------------------------------------- > >>>> - > >>>> -- > >>>> > >>>> [putting this out early in the hopes it can be resolved quickly; > >>>> I'm just starting to review the document.] > >>>> > >>>> This document started life as a rfc5277bis, published in July 2008, > >>>> before RFC > >>>> 5378 (BCP 78) was published in November of 2008. If we are using > >>>> any text from RFC 5277 and did not gain the additional rights > >>>> declaration from the authors of that document, this document needs > >>>> to use a different boilerplate text (the "pre- 2008" text). I look > >>>> at the sibling document draft-ietf-netfonf-yang-push of this > >>>> document, which does use the pre-2008 boilerplate, and am having a > >>>> hard > >> time understanding why this document does not also have the pre-2008 > >> boilerplate. > >>>> > >>>> > > >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Network Architecture & Protocols, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From nobody Tue Apr 30 09:25:47 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A6B1202DF; Tue, 30 Apr 2019 09:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxfevAopvhds; Tue, 30 Apr 2019 09:25:36 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 93AFE12008D; Tue, 30 Apr 2019 09:25:36 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3UGPROh014806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Apr 2019 12:25:30 -0400 Date: Tue, 30 Apr 2019 11:25:27 -0500 From: Benjamin Kaduk To: "Eric Voit (evoit)" Cc: Magnus Westerlund , "draft-ietf-netconf-subscribed-notifications@ietf.org" , "netconf@ietf.org" , Kent Watsen , The IESG , "netconf-chairs@ietf.org" Message-ID: <20190430162527.GI60332@kduck.mit.edu> References: <155655963180.15870.3650019434718355043.idtracker@ietfa.amsl.com> <717530026d2d4af0a92c318ecbdbb4bd@XCH-RTP-013.cisco.com> <20190429182503.GC60332@kduck.mit.edu> <94d0b3e325ee46e283d84204243bdf69@XCH-RTP-013.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-23: (with DISCUSS) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 16:25:39 -0000 On Tue, Apr 30, 2019 at 04:21:31PM +0000, Eric Voit (evoit) wrote: > > From: Magnus Westerlund, April 30, 2019 4:32 AM > > > > Hi, > > > > I think it should be avoided if possible to add the pre-5378 boilerplate, it is better > > to get the rights. Especially in this situation where there has been many version > > published stating that the rights have been had. Is there a problem of getting the > > rights? > > Hi Magnus, > > Here is the current status... > > There are no full sentences from RFC-5277 used in this document. However there are a few sentence fragments in the terminology, as well as quite a few concepts adopted based on RFC5277. On the basis of that Benjamin's DISCUSS however, it felt like we should err on the side of caution by adding his suggestion. > > Along with this, at the end of 2016 the original authors of RFC-5277 (Sharon & Hector) stated they no longer needed to be on this draft. I haven't been in contact with them since. So without a relationship here, it seemed like the including the "pre5378Trust200902" text was again erring on the side of caution. To be clear, I don't have any favored resolution I'm trying to push, here (though Magnus' point is fairly compelling) -- I was just noting the cross-document disparity and, in the absence of a note explaining it in the shepherd writeup(s), wondering how to bring the documents in line with each other. If we think that the pre-5378 boilerplate is not actually needed here and have explictly thought about the question, I am happy to accept that as well. -Ben From nobody Tue Apr 30 09:32:38 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6812112025E; Tue, 30 Apr 2019 09:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekuvzK1gh2hW; Tue, 30 Apr 2019 09:32:25 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 59C2C1200B4; Tue, 30 Apr 2019 09:32:25 -0700 (PDT) Received: from 200116b82c3e9600bdad822fcb19daa6.dip.versatel-1u1.de ([2001:16b8:2c3e:9600:bdad:822f:cb19:daa6]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hLVg4-0000Bo-IO; Tue, 30 Apr 2019 18:32:20 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Mirja Kuehlewind In-Reply-To: <03da01d4ff70$ac029f20$0407dd60$@clemm.org> Date: Tue, 30 Apr 2019 18:32:19 +0200 Cc: The IESG , netconf@ietf.org, draft-ietf-netconf-yang-push@ietf.org, Kent Watsen , netconf-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2EB9BED9-5866-4938-B8C2-3D6D551F9364@kuehlewind.net> References: <155663553672.13008.11692876138086440730.idtracker@ietfa.amsl.com> <03da01d4ff70$ac029f20$0407dd60$@clemm.org> To: Alexander Clemm X-Mailer: Apple Mail (2.3445.104.8) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1556641945;34caf8ab; X-HE-SMSGID: 1hLVg4-0000Bo-IO Archived-At: Subject: Re: [netconf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-netconf-yang-push-22=3A_=28with_COMMENT=29?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 16:32:28 -0000 Hi Alex, Thanks for double-checking! I guess that should be fine. However, = stating this explicitly in the draft, can hurt. Your take! Mirja > On 30. Apr 2019, at 18:20, Alexander Clemm wrote: >=20 > Hello Mirja,=20 > Thank you for your review! > Response inline, > --- Alex >=20 > -----Original Message----- > From: Mirja K=C3=BChlewind via Datatracker =20 > Sent: Tuesday, April 30, 2019 7:46 AM > To: The IESG > Cc: draft-ietf-netconf-yang-push@ietf.org; Kent Watsen = ; netconf-chairs@ietf.org; kent+ietf@watsen.net; = netconf@ietf.org > Subject: Mirja K=C3=BChlewind's No Objection on = draft-ietf-netconf-yang-push-22: (with COMMENT) >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-netconf-yang-push-22: No Objection >=20 > When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > A small comment/question mostly regarding section 3.4: > I wondering what happens if the system crashes or is in a state where = not even a notification can be sent anymore...? Is the assumption that a = crash could be detected because the transport connection goes away? = However, that would mean that there is requirement that the transport = must be connection-oriented and maybe also support some kind of = keep-alive mechanism. Given this document tries to be transport-agnostic = (as it relies on I-D.draft-ietf-netconf-subscribed-notifications), I = don't think that is a safe assumption and should at least be further = discussed. My understanding was that = I-D.draft-ietf-netconf-subscribed-notifications assumes an active = connection for dynamic subscriptions, but I guess this does not have to = be the case for a configured subscription...? >=20 > Also there seems to be an implicit assumption that the chosen = transport is reliable in order for the system to work as expected. If = that is the case, I think that it could be good to spelled that out in = the document as a requirement as well. I guess all transports available = today for YANG > (NETCONF/RETSCONF) are reliable but that might not be the case in = future. >=20 > =20 > Your comment is implied by the fact that the solution builds on = subscribed-notifications, which spells this out very clearly (e.g. in = section 1.3 there). To make it clearer, we can add the following text = to address your concern: > "The solution builds on . As = defined there, any loss of underlying transport connection will be = detected and result in subscription termination (in case of dynamic = subscriptions) or suspension (in case of configured subscriptions), = ensuring that situations will not occur in which the loss of update = notifications would go unnoticed." > >=20 >=20 From nobody Tue Apr 30 09:33:37 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA53120193; Tue, 30 Apr 2019 09:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLmxjHKpeiuv; Tue, 30 Apr 2019 09:33:34 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 24F1E120092; Tue, 30 Apr 2019 09:33:34 -0700 (PDT) Received: from LAPTOPR7T053C2 ([73.189.160.186]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0LniZN-1gqYWT3Lp9-00hrYO; Tue, 30 Apr 2019 18:33:31 +0200 From: "Alexander Clemm" To: "'Eric Vyncke \(evyncke\)'" , "'The IESG'" Cc: , , , References: <155654356221.15895.6935060528947597341.idtracker@ietfa.amsl.com> In-Reply-To: Date: Tue, 30 Apr 2019 09:33:29 -0700 Message-ID: <03ed01d4ff72$730837a0$5918a6e0$@clemm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKKqKE9+S3wnTB+qiITRsADDzqY4wGaVvVypNy9Y8A= Content-Language: en-us X-Provags-ID: V03:K1:mMD4c4IlJb0rPoNP9fbrKcsndPW4pEwCo48zIVEmXUHHIAWEcbw n7GtJhKQch3etvstdrHRdkdkpex6Wp6F/aZ21Tb0G2PBXjtGaMdER+17gOzHmbUWb0jPQRm hf3q5sL5wjim9snIQYG/iPqlOZfBeZXDFVPwsWJgnVkRlIcSmVTIUlEBo/as8gKuAcytPFm BkR2BMxE40fJZrwoPENYA== X-UI-Out-Filterresults: notjunk:1;V03:K0:/T/WNPFUL58=:cahi4kvPsrrrsI6jR++P0y vH8H4P/4jjoKwe03tUGHCL3a2VhvLYP93el9x76rjP0aVoektpBMGdfF0WBOy48SSA2hl8tKb 98NYgHJFahSP/BdK1Cmk3pjeH4M1+otX8I9+CijPZznyHkxiK9mrdT1PePiTeD9XQQ7OG5dC2 PfdIIhkhgdnIOqomCZm9xgeeHrEPxGhlZLTKuFkNpvh8wI25kpLlgki9k4x+h4/v0+FQ9dZNG /LENOYeO9auKVpWSrHkCssifzxZs5vX13NeLkka2wQCWQQTbyIXZy8pHgOypBMrrREdC3djsD Pa1TeGhAHzcJGZtatOa9IPQUjZChGnCATRnPY5evEkZfiWePHFSXHbfle6lvsXd94pp8tGxBx fPpCGRMm0J0/NNNcHF72ZlEr00GE0F7CqkKTz4lWNbjcHJxHZjn+wH5g41g3Aii3oLnC59qne ZkDMFkDW3iVYZBLLIXaPKuhQlR9swH38SYz3+HbrbAv1Xt1w/Qre19IP/YuN6FzRzQCNTbL1P Rqwj5DWhYsFVfJxJbtPHMS8kmCdmahtaOgQ8U0lJu7fuzt6E1eZY5xVnFZTlDelVFYoWm3BmE cCvVmNV505n01a23AUK549SPe5eWwyCUm+evfYYNpL14oOhFFx9bRqML3exxHsatB1yblng8O 8COiZhhQxKLygREzuFT/Ku3Zu7oEEEfbllc5Ma4bFU2loa9NzqidHI4YY2xI0spIJc0ZXqPj3 GZ8Y3KFYv7Zsm/7/DOczELzLOAQYMlUyP/9/a4YqprlTWJO4e2OheLcfiqg= Archived-At: Subject: Re: [netconf] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-netconf-yang-push-22=3A_=28with_COMMENT=29?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 16:33:36 -0000 Hello Eric, Thank you for your review! Replies inline, --- Alex -----Original Message----- From: Eric Vyncke (evyncke) =20 Sent: Monday, April 29, 2019 6:21 AM To: The IESG Cc: netconf@ietf.org; draft-ietf-netconf-yang-push@ietf.org; = kent+ietf@watsen.net; netconf-chairs@ietf.org Subject: Re: =C3=89ric Vyncke's No Objection on = draft-ietf-netconf-yang-push-22: (with COMMENT) Please ignore my comment C3, my bad... -=C3=A9ric =EF=BB=BFOn 29/04/2019, 15:12, "iesg on behalf of =C3=89ric Vyncke via = Datatracker" = wrote: =C3=89ric Vyncke has entered the following ballot position for draft-ietf-netconf-yang-push-22: No Objection =20 When responding, please keep the subject line intact and reply to = all email addresses included in the To and CC lines. (Feel free to cut = this introductory paragraph, however.) =20 =20 Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. =20 =20 The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ =20 =20 =20 = ---------------------------------------------------------------------- COMMENT: = ---------------------------------------------------------------------- =20 Getting a streaming telemetry for changes in datastore appears quite = useful. =20 Please note that I did not review in depth after the section 4. =20 Comments -------- =20 C1) Out of curiosity, it is surprising for a netconf wg document to = have 7 errors indicated by the YANG validator. Are they real errors or is = the `pyang` validator incorrect or missing references? There is a bug in the validator, which has been encountered for a = while and which Eric can explain. =20 =20 C2) 7 authors... the limit is usually 5 authors max. Can you = justify? All of the authors have made substantial contributions to the = document over the span of several years. We do believe this is = justified and can provide further explanation of each individual = author's contributions if needed. =20 =20 C3) section 2. It should be RFC 8174 without citing RFC 2119. =20 C4) section 3.7, why not forcing a resynch (and a patch-id of 0) = rather than simply rolling explicitly the patch-id to 0. The latter seems to me = as prone to synchronization errors. =20 We don't believe synchronization errors due to this scenario are = an issue. Note that the rolling back to 0 occurs only once every = 4294967295 updates, if no resynch ever occurred prior. If an = application were ever concerned with loss of synchronization, it could = also simply request one manually (as opposed to being forced to, which = would appear more disruptive than the proposed solution). =20 Nits ---- =20 N1) unsure why all Cisco Systems authors are not grouped together =20 Over the course of the document, some author affiliations have = changed N2) "Xpath": should be described (or having a reference) before = first use in section 3.6 =20 Added the following brief explanation at the first occurrence: = "(XPath is a query language for selecting nodes in an XML document.) "=20 N3) a couple of "yang" in lowercase while I believe "YANG" is always = written in uppercase Updated many of those, except where used e.g. in file names. = =20 =20 From nobody Tue Apr 30 09:38:02 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F72E1202EE; Tue, 30 Apr 2019 09:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 qGxW1bpPaguT; Tue, 30 Apr 2019 09:37:51 -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 ED53C1202E8; Tue, 30 Apr 2019 09:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2039; q=dns/txt; s=iport; t=1556642271; x=1557851871; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9BP+gxWS+pht5evx3zS47/CBs7vdgPQLTZEnXjyuDU0=; b=lpnB6y6S3kovOQXjjhpZqRNK0tjP2TK1tL/fdf828UqFKthl1ADtqr0R bq8cDyTa2XTjAgZC64KS6I6HokAQEtk6LSlNva7EW02tE/jvEk++4RR3n kEXnxWozE+DP5Co3RJWRoi9hnvU1nKm2KoPQY92NJpjKy6dKMTCszVv+6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACJechc/5BdJa1mDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYIQgT0wMowiiweCDZhQFIFnDgEBhG0?= =?us-ascii?q?ChjEjNAkOAQMBAQQBAQIBAm0ohUoBAQEDATo4BQIFCwIBCBUDHhAyJQIEDg2?= =?us-ascii?q?FFg+wNoo2gTIBi0kXgUA/hCM+hAmGHQSnBAkCggmSMiOVL54Agl8CERWBMB8?= =?us-ascii?q?4gVZwFYMogkWNUDtBk0eBIQEB?= X-IronPort-AV: E=Sophos;i="5.60,414,1549929600"; d="scan'208";a="269426682" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Apr 2019 16:37:28 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x3UGbR1S020837 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Apr 2019 16:37:27 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 30 Apr 2019 12:37: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.1473.003; Tue, 30 Apr 2019 12:37:27 -0400 From: "Eric Voit (evoit)" To: Benjamin Kaduk CC: Magnus Westerlund , "draft-ietf-netconf-subscribed-notifications@ietf.org" , "netconf@ietf.org" , Kent Watsen , The IESG , "netconf-chairs@ietf.org" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-23: (with DISCUSS) Thread-Index: AQHU/rKoAXBzztdqKUKWeXbDQMBk+KZUvwVAgABpR4D//74agA== Date: Tue, 30 Apr 2019 16:37:26 +0000 Message-ID: References: <155655963180.15870.3650019434718355043.idtracker@ietfa.amsl.com> <717530026d2d4af0a92c318ecbdbb4bd@XCH-RTP-013.cisco.com> <20190429182503.GC60332@kduck.mit.edu> <94d0b3e325ee46e283d84204243bdf69@XCH-RTP-013.cisco.com> <20190430162527.GI60332@kduck.mit.edu> In-Reply-To: <20190430162527.GI60332@kduck.mit.edu> 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.233] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.151, xch-rtp-011.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-23: (with DISCUSS) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 16:37:54 -0000 > From: Benjamin Kaduk, April 30, 2019 12:25 PM >=20 > On Tue, Apr 30, 2019 at 04:21:31PM +0000, Eric Voit (evoit) wrote: > > > From: Magnus Westerlund, April 30, 2019 4:32 AM > > > > > > Hi, > > > > > > I think it should be avoided if possible to add the pre-5378 > > > boilerplate, it is better to get the rights. Especially in this > > > situation where there has been many version published stating that > > > the rights have been had. Is there a problem of getting the rights? > > > > Hi Magnus, > > > > Here is the current status... > > > > There are no full sentences from RFC-5277 used in this document. Howev= er > there are a few sentence fragments in the terminology, as well as quite a= few > concepts adopted based on RFC5277. On the basis of that Benjamin's DISCU= SS > however, it felt like we should err on the side of caution by adding his > suggestion. > > > > Along with this, at the end of 2016 the original authors of RFC-5277 (S= haron & > Hector) stated they no longer needed to be on this draft. I haven't been= in > contact with them since. So without a relationship here, it seemed like = the > including the "pre5378Trust200902" text was again erring on the side of c= aution. >=20 > To be clear, I don't have any favored resolution I'm trying to push, here= (though > Magnus' point is fairly compelling) -- I was just noting the cross-docume= nt > disparity and, in the absence of a note explaining it in the shepherd wri= teup(s), > wondering how to bring the documents in line with each other. If we thin= k that > the pre-5378 boilerplate is not actually needed here and have explictly t= hought > about the question, I am happy to accept that as well. Is there a process in the IETF to determine copyright coverage based on a c= ouple sentence fragments and concept reuse? I don't feel capable of provid= ing a legal opinion here. That is why I l felt converging on the narrower = "pre5378Trust200902" boilerplate was safer. Eric =20 > -Ben From nobody Tue Apr 30 09:39:47 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4281200B6; Tue, 30 Apr 2019 09:39:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155664238530.7643.4617862140531006564@ietfa.amsl.com> Date: Tue, 30 Apr 2019 09:39:45 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-yang-push-23.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 16:39:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : Subscription to YANG Datastores Authors : Alexander Clemm Eric Voit Alberto Gonzalez Prieto Ambika Prasad Tripathy Einar Nilsen-Nygaard Andy Bierman Balazs Lengyel Filename : draft-ietf-netconf-yang-push-23.txt Pages : 58 Date : 2019-04-30 Abstract: Via the mechanism described in this document, subscriber applications may request a continuous, customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-yang-push-23 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-push-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-push-23 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 Apr 30 09:49:48 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8131202ED; Tue, 30 Apr 2019 09:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5alDIyDOU3sY; Tue, 30 Apr 2019 09:49:44 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D41C12029C; Tue, 30 Apr 2019 09:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6028; q=dns/txt; s=iport; t=1556642983; x=1557852583; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=t9aocQcylJqowleiUiacDyZvPhRefZ9oTmeP/AurITM=; b=PHyXgnXxWG0Q+lXVlpRRm6p0D7sa0BBxYUwPUJmtVpljW+b0HwHa10al cp7lg2yRgr7uTf8QcelkkDiT3mcdXV68naELtJ/SvHKhF49HfE2RC3nTL sfHTUZBa6rWH0huxRTAs80XNnC9VAUgumfVPJcVBsmK8kVXt7sMzmppAK g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAADoe8hc/40NJK1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBghBpVDAoCoQGiByNFI4wiiAUgWcOAQE?= =?us-ascii?q?lhEgCF4YaIzQJDgEDAQEEAQECAQJtHAyFSgEBAQMBIxFFBQcEAgEIDgMEAQE?= =?us-ascii?q?BAgImAgICMBUFAwgCBAENBQgTgwiBew8Prn+BL4RGQYUoBoELJwGEYYZoF4F?= =?us-ascii?q?AP4ERgxI+gmECAQIBgSoBDAYBJhAhAoJQglgEiwiCN5hmXwkCggmGFYhag0M?= =?us-ascii?q?jgg2GN4xrgwmJBYZDjg4CERWBMB84ZVgRCHAVgnMBM4IbFxSITIU/QTEBkWU?= =?us-ascii?q?BDRcHgQSBIQEB?= X-IronPort-AV: E=Sophos;i="5.60,414,1549929600"; d="scan'208";a="541986459" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Apr 2019 16:49:42 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x3UGngKM003813 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Apr 2019 16:49:42 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 30 Apr 2019 12:49:41 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Tue, 30 Apr 2019 12:49:41 -0400 From: "Eric Voit (evoit)" To: Alexander Clemm , "Eric Vyncke (evyncke)" , "'The IESG'" CC: "netconf@ietf.org" , "draft-ietf-netconf-yang-push@ietf.org" , "kent+ietf@watsen.net" , "netconf-chairs@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtbmV0?= =?utf-8?Q?conf-yang-push-22:_(with_COMMENT)?= Thread-Index: AQKKqKE9+S3wnTB+qiITRsADDzqY4wGaVvVypNy9Y8CAAAaOcA== Date: Tue, 30 Apr 2019 16:49:41 +0000 Message-ID: References: <155654356221.15895.6935060528947597341.idtracker@ietfa.amsl.com> <03ed01d4ff72$730837a0$5918a6e0$@clemm.org> In-Reply-To: <03ed01d4ff72$730837a0$5918a6e0$@clemm.org> 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.233] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.151, xch-rtp-011.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [netconf] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-netconf-yang-push-22=3A_=28with_COMMENT=29?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 16:49:47 -0000 PiBGcm9tOiBBbGV4YW5kZXIgQ2xlbW0sIEFwcmlsIDMwLCAyMDE5IDEyOjMzIFBNDQo+IA0KPiBI ZWxsbyBFcmljLA0KPiANCj4gVGhhbmsgeW91IGZvciB5b3VyIHJldmlldyEgIFJlcGxpZXMgaW5s aW5lLCA8QUxFWD4NCj4gDQo+IC0tLSBBbGV4DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBFcmljIFZ5bmNrZSAoZXZ5bmNrZSkgPGV2eW5ja2VAY2lzY28uY29tPg0K PiBTZW50OiBNb25kYXksIEFwcmlsIDI5LCAyMDE5IDY6MjEgQU0NCj4gVG86IFRoZSBJRVNHIDxp ZXNnQGlldGYub3JnPg0KPiBDYzogbmV0Y29uZkBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1uZXRjb25m LXlhbmctcHVzaEBpZXRmLm9yZzsNCj4ga2VudCtpZXRmQHdhdHNlbi5uZXQ7IG5ldGNvbmYtY2hh aXJzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24g b24gZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaC0yMjoNCj4gKHdpdGggQ09NTUVOVCkNCj4g DQo+IFBsZWFzZSBpZ25vcmUgbXkgY29tbWVudCBDMywgbXkgYmFkLi4uDQo+IA0KPiAtw6lyaWMN Cj4gDQo+IO+7v09uIDI5LzA0LzIwMTksIDE1OjEyLCAiaWVzZyBvbiBiZWhhbGYgb2Ygw4lyaWMg VnluY2tlIHZpYSBEYXRhdHJhY2tlciIgPGllc2ctDQo+IGJvdW5jZXNAaWV0Zi5vcmcgb24gYmVo YWxmIG9mIG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KPiANCj4gICAgIMOJcmljIFZ5bmNrZSBo YXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gICAgIGRyYWZ0 LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMjI6IE5vIE9iamVjdGlvbg0KPiANCj4gICAgIFdoZW4g cmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5 IHRvIGFsbA0KPiAgICAgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0Mg bGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCj4gICAgIGludHJvZHVjdG9yeSBwYXJhZ3Jh cGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+ICAgICBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+ICAgICBmb3Ig bW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25z Lg0KPiANCj4gDQo+ICAgICBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBv c2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+ICAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wdXNoLw0KPiANCj4gDQo+IA0KPiAg ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiAgICAgQ09NTUVOVDoNCj4gICAgIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g DQo+ICAgICBHZXR0aW5nIGEgc3RyZWFtaW5nIHRlbGVtZXRyeSBmb3IgY2hhbmdlcyBpbiBkYXRh c3RvcmUgYXBwZWFycyBxdWl0ZSB1c2VmdWwuDQo+IA0KPiAgICAgUGxlYXNlIG5vdGUgdGhhdCBJ IGRpZCBub3QgcmV2aWV3IGluIGRlcHRoIGFmdGVyIHRoZSBzZWN0aW9uIDQuDQo+IA0KPiAgICAg Q29tbWVudHMNCj4gICAgIC0tLS0tLS0tDQo+IA0KPiAgICAgQzEpIE91dCBvZiBjdXJpb3NpdHks IGl0IGlzIHN1cnByaXNpbmcgZm9yIGEgbmV0Y29uZiB3ZyBkb2N1bWVudCB0byBoYXZlIDcNCj4g ICAgIGVycm9ycyBpbmRpY2F0ZWQgYnkgdGhlIFlBTkcgdmFsaWRhdG9yLiBBcmUgdGhleSByZWFs IGVycm9ycyBvciBpcyB0aGUgYHB5YW5nYA0KPiAgICAgdmFsaWRhdG9yIGluY29ycmVjdCBvciBt aXNzaW5nIHJlZmVyZW5jZXM/DQo+IA0KPiA8QUxFWD4gVGhlcmUgaXMgYSBidWcgaW4gdGhlIHZh bGlkYXRvciwgd2hpY2ggaGFzIGJlZW4gZW5jb3VudGVyZWQgZm9yIGEgd2hpbGUNCj4gYW5kIHdo aWNoIEVyaWMgY2FuIGV4cGxhaW4uDQo+IDwvQUxFWD4NCg0KVGhlIFlBTkcgdmFsaWRhdG9yIGVy cm9ycyBhcmUgZHVlIHRvIGEgc29sdmVkIGJ1ZyBpbiB5YW5nbGludC4gICANCg0KQXMgS2VudCBk aXNjdXNzZXMgaW4gaGlzICJkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRp b25zIiBzaGVwaGVyZCB3cml0ZXVwLCB0aGUgZXJyb3JzIGNsZWFyIHdpdGggbmV3IHZlcnNpb25z IG9mIHlhbmdsaW50Lg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucy9zaGVwaGVyZHdyaXRldXAvIA0KDQog ICBbU0hFUEhFUkRdIGBweWFuZ2AgYW5kIGB5YW5nbGludGAgd2VyZSB1c2VkIHRvIHZhbGlkYXRl IHRoZSBZQU5HIG1vZHVsZSANCiAgIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4gIE5vdGUgdGhh dCBEYXRhdHJhY2tlciBzaG93cyBZQU5HIHZhbGlkYXRpb24gDQogICBlcnJvcnMsIGJ1dCB0aGUg bW9kdWxlIHZhbGlkYXRlcyBmaW5lIG9uIG15IG1hY2hpbmUgKEknbSB1c2luZyB5YW5nbGludA0K ICAgMC4xNi4xMTAsIHdoZXJlYXMgRGF0YVRyYWNrZXIgaXMgdXNpbmcgeWFuZ2xpbnQgMC4xNC44 MCkuDQoNCkVyaWMNCg0KIA0KPiAgICAgQzIpIDcgYXV0aG9ycy4uLiB0aGUgbGltaXQgaXMgdXN1 YWxseSA1IGF1dGhvcnMgbWF4LiBDYW4geW91IGp1c3RpZnk/DQo+IDxBTEVYPiBBbGwgb2YgdGhl IGF1dGhvcnMgaGF2ZSBtYWRlIHN1YnN0YW50aWFsIGNvbnRyaWJ1dGlvbnMgdG8gdGhlIGRvY3Vt ZW50DQo+IG92ZXIgdGhlIHNwYW4gb2Ygc2V2ZXJhbCB5ZWFycy4gIFdlIGRvIGJlbGlldmUgdGhp cyBpcyBqdXN0aWZpZWQgYW5kIGNhbiBwcm92aWRlDQo+IGZ1cnRoZXIgZXhwbGFuYXRpb24gb2Yg ZWFjaCBpbmRpdmlkdWFsIGF1dGhvcidzIGNvbnRyaWJ1dGlvbnMgaWYgbmVlZGVkLg0KPiA8L0FM RVg+DQo+IA0KPiAgICAgQzMpIHNlY3Rpb24gMi4gSXQgc2hvdWxkIGJlIFJGQyA4MTc0IHdpdGhv dXQgY2l0aW5nIFJGQyAyMTE5Lg0KPiANCj4gICAgIEM0KSBzZWN0aW9uIDMuNywgd2h5IG5vdCBm b3JjaW5nIGEgcmVzeW5jaCAoYW5kIGEgcGF0Y2gtaWQgb2YgMCkgcmF0aGVyIHRoYW4NCj4gICAg IHNpbXBseSByb2xsaW5nIGV4cGxpY2l0bHkgdGhlIHBhdGNoLWlkIHRvIDAuIFRoZSBsYXR0ZXIg c2VlbXMgdG8gbWUgYXMgcHJvbmUgdG8NCj4gICAgIHN5bmNocm9uaXphdGlvbiBlcnJvcnMuDQo+ IA0KPiA8QUxFWD4gV2UgZG9uJ3QgYmVsaWV2ZSBzeW5jaHJvbml6YXRpb24gZXJyb3JzIGR1ZSB0 byB0aGlzIHNjZW5hcmlvIGFyZSBhbg0KPiBpc3N1ZS4gIE5vdGUgdGhhdCB0aGUgcm9sbGluZyBi YWNrIHRvIDAgb2NjdXJzIG9ubHkgb25jZSBldmVyeSA0Mjk0OTY3Mjk1DQo+IHVwZGF0ZXMsIGlm IG5vIHJlc3luY2ggZXZlciBvY2N1cnJlZCBwcmlvci4gIElmIGFuIGFwcGxpY2F0aW9uIHdlcmUg ZXZlcg0KPiBjb25jZXJuZWQgd2l0aCBsb3NzIG9mIHN5bmNocm9uaXphdGlvbiwgaXQgY291bGQg YWxzbyBzaW1wbHkgcmVxdWVzdCBvbmUNCj4gbWFudWFsbHkgKGFzIG9wcG9zZWQgdG8gYmVpbmcg Zm9yY2VkIHRvLCB3aGljaCB3b3VsZCBhcHBlYXIgbW9yZSBkaXNydXB0aXZlDQo+IHRoYW4gdGhl IHByb3Bvc2VkIHNvbHV0aW9uKS4NCj4gPC9BTEVYPg0KPiANCj4gICAgIE5pdHMNCj4gICAgIC0t LS0NCj4gDQo+ICAgICBOMSkgdW5zdXJlIHdoeSBhbGwgQ2lzY28gU3lzdGVtcyBhdXRob3JzIGFy ZSBub3QgZ3JvdXBlZCB0b2dldGhlcg0KPiANCj4gPEFMRVg+IE92ZXIgdGhlIGNvdXJzZSBvZiB0 aGUgZG9jdW1lbnQsIHNvbWUgYXV0aG9yIGFmZmlsaWF0aW9ucyBoYXZlDQo+IGNoYW5nZWQgPC9B TEVYPg0KPiAgICAgTjIpICJYcGF0aCI6IHNob3VsZCBiZSBkZXNjcmliZWQgKG9yIGhhdmluZyBh IHJlZmVyZW5jZSkgYmVmb3JlIGZpcnN0IHVzZSBpbg0KPiAgICAgc2VjdGlvbiAzLjYNCj4gDQo+ IDxBTEVYPiBBZGRlZCB0aGUgZm9sbG93aW5nIGJyaWVmIGV4cGxhbmF0aW9uIGF0IHRoZSBmaXJz dCBvY2N1cnJlbmNlOiAgIihYUGF0aCBpcw0KPiBhIHF1ZXJ5IGxhbmd1YWdlIGZvciBzZWxlY3Rp bmcgbm9kZXMgaW4gYW4gWE1MIGRvY3VtZW50LikgIg0KPiA8L0FMRVg+DQo+ICAgICBOMykgYSBj b3VwbGUgb2YgInlhbmciIGluIGxvd2VyY2FzZSB3aGlsZSBJIGJlbGlldmUgIllBTkciIGlzIGFs d2F5cyB3cml0dGVuIGluDQo+ICAgICB1cHBlcmNhc2UNCj4gPEFMRVg+IFVwZGF0ZWQgbWFueSBv ZiB0aG9zZSwgZXhjZXB0IHdoZXJlIHVzZWQgZS5nLiBpbiBmaWxlIG5hbWVzLiA8L0FMRVg+DQo+ IA0KPiANCj4gDQoNCg== From nobody Tue Apr 30 10:06:08 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE70B1202ED; Tue, 30 Apr 2019 10:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=dr9JhDqC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=MGYC54CU Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtBdDWza_Aa6; Tue, 30 Apr 2019 10:06:04 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E79F12008D; Tue, 30 Apr 2019 10:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4386; q=dns/txt; s=iport; t=1556643964; x=1557853564; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=oyG4U8u3ZHgpHZUHSMbtOSr7Tl1RNYrBij9ben/Faq4=; b=dr9JhDqC3mkCAlzZlqWnMYXQtEQ+M9uW+lSEpxFEXu2EecM2pIDvlJdW /wKFZoR5sw2DDjIWXq9J/ZtWGYR+lPOBQXAM5hweZKrvzEByC77Rvowj2 iJpn8ccT6XZDR9QwXZBZTpHufptMWewItX47fZVJ7RpLYVbp/kUDXqas3 U=; IronPort-PHdr: =?us-ascii?q?9a23=3ADHhEYh2DAJFlzF6qsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKHt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQE1fyLPvjaQQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAACjf8hc/51dJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBPVADaVUgBAsohBCDRwOEUoo9gleXIoEuFIE?= =?us-ascii?q?QA1QOAQElCIRAAheGGiM0CQ4BAwEBBAEBAgECbRwMhUoBAQEDARIREQwBATc?= =?us-ascii?q?BCwYBCBEEAQEBAgImAgQwFQUDCgQBDQUigwABgWoDDg8BDqQCAoE1iF9xgS+?= =?us-ascii?q?CeQEBBYEyARNBgn8Ygg4DBoELJwGEYYZoF4FAP4ERJx+CTD6CYQIBAgGBKgE?= =?us-ascii?q?SAQ8XECECglAygiaLDII3mGZfCQKCCYYViFqDSxuCDYY3jGuDCYkFhSOBII4?= =?us-ascii?q?OAgQCBAUCDgEBBYFPOGVYEQhwFWUBgg0BM4IPDBcUgziFFIU/cgGBKJA+DRc?= =?us-ascii?q?HgiUBAQ?= X-IronPort-AV: E=Sophos;i="5.60,414,1549929600"; d="scan'208";a="265578303" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Apr 2019 17:06:03 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x3UH62A9025051 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Apr 2019 17:06:03 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 30 Apr 2019 12:06:02 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 30 Apr 2019 12:06:02 -0500 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 30 Apr 2019 12:06:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oyG4U8u3ZHgpHZUHSMbtOSr7Tl1RNYrBij9ben/Faq4=; b=MGYC54CU5RI9P/6se0heh/CMH17eOEjr87byLAxB5wUILkN1kWFwEyvPPVcSzblTfMDadXZh0O8CJ6UntLQlAxxVj5xw4TiVuNjCv+uPBU+xlVab8OjRvLPtzJBkuAnTM1PmbWZurDGoiwneRmkY+R8I6N/GXGU25nfUascRGoE= Received: from DM5PR1101MB2105.namprd11.prod.outlook.com (10.174.104.15) by DM5PR1101MB2121.namprd11.prod.outlook.com (10.174.104.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.10; Tue, 30 Apr 2019 17:06:00 +0000 Received: from DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::a113:a1ba:aae0:4a12]) by DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::a113:a1ba:aae0:4a12%6]) with mapi id 15.20.1835.010; Tue, 30 Apr 2019 17:06:00 +0000 From: "Reshad Rahman (rrahman)" To: "Eric Voit (evoit)" , Alexander Clemm , "Eric Vyncke (evyncke)" , "'The IESG'" CC: "draft-ietf-netconf-yang-push@ietf.org" , "netconf@ietf.org" , "netconf-chairs@ietf.org" Thread-Topic: =?utf-8?B?W25ldGNvbmZdICDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJh?= =?utf-8?Q?ft-ietf-netconf-yang-push-22:_(with_COMMENT)?= Thread-Index: AQHU/3b8vQfuk8IrZECnJQ9aK8WPBw== Date: Tue, 30 Apr 2019 17:06:00 +0000 Message-ID: <244A8033-612B-4A31-BA37-CDD4AF93502B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.6.190114 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [2001:420:2840:1250:2421:2f0a:1dbc:638e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: df5477e8-0362-4fa2-23d2-08d6cd8e1ee3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM5PR1101MB2121; x-ms-traffictypediagnostic: DM5PR1101MB2121: x-ms-exchange-purlcount: 4 x-ld-processed: 5ae1af62-9505-4097-a69a-c1553ef7840e,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 00235A1EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(366004)(346002)(396003)(39860400002)(13464003)(189003)(199004)(316002)(99286004)(25786009)(305945005)(6306002)(54906003)(110136005)(6512007)(53936002)(7736002)(966005)(14454004)(97736004)(33656002)(14444005)(256004)(6436002)(86362001)(76116006)(229853002)(66946007)(66446008)(66476007)(66556008)(64756008)(6246003)(478600001)(4326008)(6486002)(91956017)(58126008)(6116002)(82746002)(2906002)(66574012)(36756003)(81166006)(68736007)(73956011)(8936002)(71200400001)(81156014)(71190400001)(224303003)(83716004)(186003)(46003)(5660300002)(6506007)(53546011)(476003)(2616005)(486006)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1101MB2121; H:DM5PR1101MB2105.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ha0aLgKlXAv9757qdy3RJbhn/QAQLUGoHgrV0OiUTXNsLYVNY578Hrvt2xtyyfUFFpb3Wd6HVgxZ9xfODt7IExUOwrZOUF5LmUj5p/f/Fe3V3/AwXyWT7stgkCPV07+ZYnWIAfkoeDjNMhgWImRqp4Vg4hYth0LEdenzOJK8sh2Bo0B7L4s129cWcQ6BeTRbAPt8wo9ZAuJPcqnEjRgioKoTco9htWU5j/zLkB6jYEVSS9F8vaKqQRusvPDDGzFmbUXkvJ7GWts99dSdnkbsNNELhLqtKVzifx4FtlPHfw7jszdJRFcKM+l53SdKlv6GWEnbw65EUoJC1R/xBt0MiVq/2smzMLlPgt8KMBBUi30a6CLklW/Y9VE662q4t3tZm4NgtEMxk3QbOU0g/hRfGyQmuH+Vrb9N0FD7IlVPhbw= Content-Type: text/plain; charset="utf-8" Content-ID: <10928D96A291924C8A0FB48F8FF710E0@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: df5477e8-0362-4fa2-23d2-08d6cd8e1ee3 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2019 17:06:00.6035 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2121 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [netconf] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-netconf-yang-push-22=3A_=28with_COMMENT=29?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 17:06:07 -0000 T24gMjAxOS0wNC0zMCwgMTI6NTAgUE0sICJuZXRjb25mIG9uIGJlaGFsZiBvZiBFcmljIFZvaXQg KGV2b2l0KSIgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgZXZvaXRAY2lz Y28uY29tPiB3cm90ZToNCg0KICAgID4gRnJvbTogQWxleGFuZGVyIENsZW1tLCBBcHJpbCAzMCwg MjAxOSAxMjozMyBQTQ0KICAgID4gDQogICAgPiBIZWxsbyBFcmljLA0KICAgID4gDQogICAgPiBU aGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3ISAgUmVwbGllcyBpbmxpbmUsIDxBTEVYPg0KICAgID4g DQogICAgPiAtLS0gQWxleA0KICAgID4gDQogICAgPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KICAgID4gRnJvbTogRXJpYyBWeW5ja2UgKGV2eW5ja2UpIDxldnluY2tlQGNpc2NvLmNvbT4N CiAgICA+IFNlbnQ6IE1vbmRheSwgQXByaWwgMjksIDIwMTkgNjoyMSBBTQ0KICAgID4gVG86IFRo ZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KICAgID4gQ2M6IG5ldGNvbmZAaWV0Zi5vcmc7IGRyYWZ0 LWlldGYtbmV0Y29uZi15YW5nLXB1c2hAaWV0Zi5vcmc7DQogICAgPiBrZW50K2lldGZAd2F0c2Vu Lm5ldDsgbmV0Y29uZi1jaGFpcnNAaWV0Zi5vcmcNCiAgICA+IFN1YmplY3Q6IFJlOiDDiXJpYyBW eW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaC0yMjoN CiAgICA+ICh3aXRoIENPTU1FTlQpDQogICAgPiANCiAgICA+IFBsZWFzZSBpZ25vcmUgbXkgY29t bWVudCBDMywgbXkgYmFkLi4uDQogICAgPiANCiAgICA+IC3DqXJpYw0KICAgID4gDQogICAgPiBP biAyOS8wNC8yMDE5LCAxNToxMiwgImllc2cgb24gYmVoYWxmIG9mIMOJcmljIFZ5bmNrZSB2aWEg RGF0YXRyYWNrZXIiIDxpZXNnLQ0KICAgID4gYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yg bm9yZXBseUBpZXRmLm9yZz4gd3JvdGU6DQogICAgPiANCiAgICA+ICAgICDDiXJpYyBWeW5ja2Ug aGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQogICAgPiAgICAg ZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaC0yMjogTm8gT2JqZWN0aW9uDQogICAgPiANCiAg ICA+ICAgICBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50 YWN0IGFuZCByZXBseSB0byBhbGwNCiAgICA+ICAgICBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQg aW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KICAgID4gICAg IGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KICAgID4gDQogICAgPiANCiAgICA+ ICAgICBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQv ZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQogICAgPiAgICAgZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJv dXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCiAgICA+IA0KICAgID4gDQog ICAgPiAgICAgVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMs IGNhbiBiZSBmb3VuZCBoZXJlOg0KICAgID4gICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gvDQogICAgPiANCiAgICA+IA0KICAg ID4gDQogICAgPiAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgID4gICAgIENPTU1FTlQ6DQogICAgPiAg ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KICAgID4gDQogICAgPiAgICAgR2V0dGluZyBhIHN0cmVhbWluZyB0 ZWxlbWV0cnkgZm9yIGNoYW5nZXMgaW4gZGF0YXN0b3JlIGFwcGVhcnMgcXVpdGUgdXNlZnVsLg0K ICAgID4gDQogICAgPiAgICAgUGxlYXNlIG5vdGUgdGhhdCBJIGRpZCBub3QgcmV2aWV3IGluIGRl cHRoIGFmdGVyIHRoZSBzZWN0aW9uIDQuDQogICAgPiANCiAgICA+ICAgICBDb21tZW50cw0KICAg ID4gICAgIC0tLS0tLS0tDQogICAgPiANCiAgICA+ICAgICBDMSkgT3V0IG9mIGN1cmlvc2l0eSwg aXQgaXMgc3VycHJpc2luZyBmb3IgYSBuZXRjb25mIHdnIGRvY3VtZW50IHRvIGhhdmUgNw0KICAg ID4gICAgIGVycm9ycyBpbmRpY2F0ZWQgYnkgdGhlIFlBTkcgdmFsaWRhdG9yLiBBcmUgdGhleSBy ZWFsIGVycm9ycyBvciBpcyB0aGUgYHB5YW5nYA0KICAgID4gICAgIHZhbGlkYXRvciBpbmNvcnJl Y3Qgb3IgbWlzc2luZyByZWZlcmVuY2VzPw0KICAgID4gDQogICAgPiA8QUxFWD4gVGhlcmUgaXMg YSBidWcgaW4gdGhlIHZhbGlkYXRvciwgd2hpY2ggaGFzIGJlZW4gZW5jb3VudGVyZWQgZm9yIGEg d2hpbGUNCiAgICA+IGFuZCB3aGljaCBFcmljIGNhbiBleHBsYWluLg0KICAgID4gPC9BTEVYPg0K ICAgIA0KICAgIFRoZSBZQU5HIHZhbGlkYXRvciBlcnJvcnMgYXJlIGR1ZSB0byBhIHNvbHZlZCBi dWcgaW4geWFuZ2xpbnQuICAgDQogICAgDQogICAgQXMgS2VudCBkaXNjdXNzZXMgaW4gaGlzICJk cmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIiBzaGVwaGVyZCB3cml0 ZXVwLCB0aGUgZXJyb3JzIGNsZWFyIHdpdGggbmV3IHZlcnNpb25zIG9mIHlhbmdsaW50Lg0KICAg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1zdWJz Y3JpYmVkLW5vdGlmaWNhdGlvbnMvc2hlcGhlcmR3cml0ZXVwLyANCiAgICANCiAgICAgICBbU0hF UEhFUkRdIGBweWFuZ2AgYW5kIGB5YW5nbGludGAgd2VyZSB1c2VkIHRvIHZhbGlkYXRlIHRoZSBZ QU5HIG1vZHVsZSANCiAgICAgICBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuICBOb3RlIHRoYXQg RGF0YXRyYWNrZXIgc2hvd3MgWUFORyB2YWxpZGF0aW9uIA0KICAgICAgIGVycm9ycywgYnV0IHRo ZSBtb2R1bGUgdmFsaWRhdGVzIGZpbmUgb24gbXkgbWFjaGluZSAoSSdtIHVzaW5nIHlhbmdsaW50 DQogICAgICAgMC4xNi4xMTAsIHdoZXJlYXMgRGF0YVRyYWNrZXIgaXMgdXNpbmcgeWFuZ2xpbnQg MC4xNC44MCkuDQogICAgDQogICAgRXJpYw0KDQpJdCB3YXMgZml4ZWQgaW4gMC4xNi41OQ0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy90b29scy9pZXRmZGIvdGlja2V0LzI2NjcNCg0KUmVnYXJkcywN ClJlc2hhZC4NCg0K From nobody Tue Apr 30 10:44:43 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1671F120314; Tue, 30 Apr 2019 10:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3jZIMPVWcXz; Tue, 30 Apr 2019 10:44:22 -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 415A81202F6; Tue, 30 Apr 2019 10:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9398; q=dns/txt; s=iport; t=1556646262; x=1557855862; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qNh+k1P0aFA46WUYnMovzj6H1R69v1ISdRMkRuJCYH0=; b=ewGhd2+TfZHWFVzcr0cXs+xfhOMloshK3VW4OdKF+T5TbNSdkv0d/aUJ LYQuOEiAPuIlvVZeR0XqAbF7pnhzakdM+PFrDYw20D48WIl6KvKfM3DLB lsFbjUoJUP6HZw8Zbq6AfGsYT/zQWgKp9gfc6IxKMK6ZBKZv6jQbQ2m2q 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAADbiMhc/5pdJa1mGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUwQBAQELAYFmKmlUMCgKhAaVMJhQFIFnDgEBI4RKAheGGiM2Bw4?= =?us-ascii?q?BAwEBBAEBAgECbRwMhUoBAQEDASMRQwIFCwIBCBQBBQIJHQICAjAVEAIEAQ0?= =?us-ascii?q?Ngk9LAYF7Dw+vCoEvijSBCycBhGGGaBeBQD+BEYIUfj6CVgsCgUkvgnOCWAS?= =?us-ascii?q?KdhKCCyyMPo0HCQKCCYYVjB0jgg1fhVgFjGaDFoh4gR6FJYgQhX4CERWBMCY?= =?us-ascii?q?BMIFWcBWDJwmLCYU/QTEBAZMUgSEBAQ?= X-IronPort-AV: E=Sophos;i="5.60,414,1549929600"; d="scan'208";a="467468326" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Apr 2019 17:44:20 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x3UHiJQa013614 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Apr 2019 17:44:20 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 30 Apr 2019 13:44:19 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Tue, 30 Apr 2019 13:44:19 -0400 From: "Eric Voit (evoit)" To: Dhruv Dhody , "kent+ietf@watsen.net" CC: "rtg-dir@ietf.org" , "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "netconf@ietf.org" , Dhruv Dhody , "" Thread-Topic: RtgDir review: draft-ietf-netconf-netconf-event-notifications-17 Thread-Index: AQHU/xC8WbWTXSPvekeZmlnK7/xOtqZU7OSw Date: Tue, 30 Apr 2019 17:44:19 +0000 Message-ID: <7395d7e5db4b48e1ba582c9c48c29913@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.233] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.153, xch-rtp-013.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 17:44:34 -0000 SGkgRGhydXYsDQpIaSBLZW50LA0KDQpUaGFua3MgdmVyeSBtdWNoIGZvciB0aGUgY29tbWVudHMg RGhydXYuICBUaG91Z2h0cyBpbi1saW5lLCB3aXRoIG9uZSBxdWVzdGlvbiB0byBLZW50Li4uDQoN Cj4gRnJvbTogRGhydXYgRGhvZHksIEFwcmlsIDMwLCAyMDE5IDEyOjUzIEFNDQo+DQo+IEhlbGxv LA0KPiANCj4gSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUg cmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZQ0KPiBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtz IHRvIHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkN Cj4gcGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0 aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QuDQo+IFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMg dG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUNCj4gaW5m b3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUNCj4gaHR0 cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcg0KPiANCj4g QWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUg Um91dGluZyBBRHMsIGl0IHdvdWxkDQo+IGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVy IHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwNCj4gY29tbWVudHMgdGhh dCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNz aW9uIG9yIGJ5DQo+IHVwZGF0aW5nIHRoZSBkcmFmdC4NCj4gDQo+IERvY3VtZW50OiBkcmFmdC1p ZXRmLW5ldGNvbmYtbmV0Y29uZi1ldmVudC1ub3RpZmljYXRpb25zLTE3DQo+IFJldmlld2VyOiBE aHJ1diBEaG9keQ0KPiBSZXZpZXcgRGF0ZTogMjAxOS0wNC0yOQ0KPiBJRVRGIExDIEVuZCBEYXRl OiAyMDE5LTA0LTEyDQo+IEludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrDQo+IA0KPiBT dW1tYXJ5Og0KPiAtLS0tLS0tLQ0KPiBJIGhhdmUgc29tZSBtaW5vciBjb25jZXJucyBhYm91dCB0 aGlzIGRvY3VtZW50IHRoYXQgSSB0aGluayBzaG91bGQgYmUgcmVzb2x2ZWQNCj4gYmVmb3JlIHB1 YmxpY2F0aW9uLg0KPiANCj4gQ29tbWVudHM6DQo+IC0tLS0tLS0tLQ0KPiBUaGlzIGRvY3VtZW50 IHByb3ZpZGVzIGEgYmluZGluZyBmb3IgZXZlbnRzIHN0cmVhbWVkIG92ZXIgdGhlIE5FVENPTkYg Zm9yDQo+IGR5bmFtaWMgc3Vic2NyaXB0aW9ucy4gVGhpcyBpcyBhIGNvbXBhbmlvbiBkb2N1bWVu dCB0byBkcmFmdC1pZXRmLW5ldGNvbmYtDQo+IHN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyBhbmQg dGhpcyBjYXBhYmlsaXR5IGZvciBSRVNUQ09ORiBpcyBkZWZpbmVkIGluIGRyYWZ0LWlldGYtDQo+ IG5ldGNvbmYtcmVzdGNvbmYtbm90aWYuDQo+IA0KPiBUaGUgZG9jdW1lbnQgaXMgb3ZlcmFsbCB3 ZWxsIHdyaXR0ZW4sIGl0IG1ha2VzIGFuIGFzc3VtcHRpb24gdGhhdCB0aGUgcmVhZGVyIGlzDQo+ IHdlbGwgdmVyc2VkIGluIHRoaXMgYXJlYSBhbmQgdGh1cyBzcGFyc2UgaW4gcHJvdmlkaW5nIGRl dGFpbHMgaW4gdGhlIEludHJvZHVjdGlvbg0KPiBzZWN0aW9uLiBUaGUgYXBwZW5kaXggcHJvdmlk ZXMgZ29vZCBleGFtcGxlcy4NCj4gDQo+IEkgZG9uJ3Qgc2VlIGFueSBSb3V0aW5nIFlhbmcgbW9k ZWwgc3BlY2lmaWMgaXNzdWUuDQo+IA0KPiBNYWpvciBJc3N1ZXM6DQo+IC0tLS0tLS0tLS0tLS0N Cj4gTm90ZSAtIEFuIElFVEYgcHJvY2VzcyBpc3N1ZSwgYnV0IHdvcnRoIGhhbmRsaW5nIHJpZ2h0 IGF3YXkuDQo+IA0KPiBTZWN0aW9uIDExIHNheXMgLQ0KPiANCj4gMTEuICBOb3RlcyB0byB0aGUg UkZDIEVkaXRvcg0KPiANCj4gICAgVGhpcyBzZWN0aW9uIGNhbiBiZSByZW1vdmVkIGJ5IHRoZSBS RkMgZWRpdG9yIGFmdGVyIHRoZSByZXF1ZXN0cyBoYXZlDQo+ICAgIGJlZW4gcGVyZm9ybWVkLg0K PiANCj4gSXQgZnVydGhlciBzYXlzIC0NCj4gDQo+ICAgIFJGQyA2MjQxIG5lZWRzIHRvIGJlIHVw ZGF0ZWQgYmFzZWQgb24gdGhlIG5lZWRzIG9mIHRoaXMgZHJhZnQuDQo+ICAgIFJGQy02MjQxIHNl Y3Rpb24gMS4yIGJ1bGxldCAiKDIpIiB0YXJnZXRzIFJGQy01Mjc3IChhY3R1YWxseSBpdA0KPiAg ICBpZGVudGlmaWVzIFJGQyA1NzE3LCBidXQgdGhhdCB3YXMgYW4gZXJyb3IgZml4ZWQgYWZ0ZXIg UkZDDQo+ICAgIHB1YmxpY2F0aW9uKS4gIEFueXdheSB0aGUgY3VycmVudCBwaHJhc2luZyBpbiBS RkMtNTI3NyBzYXlzIHRoYXQgYQ0KPiAgICBub3RpZmljYXRpb24gbWVzc2FnZSBjYW4gb25seSBi ZSBzZW50IGFmdGVyIGEgc3VjY2Vzc2Z1bCAiY3JlYXRlLQ0KPiAgICBzdWJzY3JpcHRpb24iLiAg VGhlcmVmb3JlIHRoZSByZWZlcmVuY2UgdGV4dCBtdXN0IGJlIG1vZGlmaWVkIHRvIGFsc28NCj4g ICAgYWxsb3cgbm90aWZpY2F0aW9uIG1lc3NhZ2VzIGJlIHNlbnQgYWZ0ZXIgYSBzdWNjZXNzZnVs ICJlc3RhYmxpc2gtDQo+ICAgIHN1YnNjcmlwdGlvbiIuICBQcm9wb3NlZCB0ZXh0IGZvciBidWxs ZXQgKDIpIG9mIFJGQy02MjQxIHdvdWxkIGJlOg0KPiANCj4gICAgICAoMikgIFRoZSBNZXNzYWdl cyBsYXllciBwcm92aWRlcyBhIHNpbXBsZSwgdHJhbnNwb3J0LWluZGVwZW5kZW50DQo+ICAgICAg ICAgICBmcmFtaW5nIG1lY2hhbmlzbSBmb3IgZW5jb2RpbmcgUlBDcyBhbmQgbm90aWZpY2F0aW9u cy4NCj4gICAgICAgICAgIFNlY3Rpb24gNCBkb2N1bWVudHMgdGhlIFJQQyBtZXNzYWdlcywgW1JG QzUyNzddIGRvY3VtZW50cw0KPiAgICAgICAgICAgTm90aWZpY2F0aW9ucyBzZW50IGFzIGEgcmVz dWx0IG9mIGEgPGNyZWF0ZS1zdWJzY3JpcHRpb24+IFJQQywNCj4gICAgICAgICAgIGFuZCBbUkZD IHh4eHhdIGRvY3VtZW50cyBOb3RpZmljYXRpb25zIHNlbnQgYXMgYSByZXN1bHQgb2YNCj4gICAg ICAgICAgIGFuIDxlc3RhYmxpc2gtc3Vic2NyaXB0aW9uPiBSUEMuDQo+IA0KPiAgICAgICAod2hl cmUgeHh4eCBpcyByZXBsYWNlZCB3aXRoIHRoaXMgUkZDIG51bWJlcikNCj4gDQo+IEkgYW0gbm90 IHN1cmUgaWYgdGhpcyBpcyBjb3JyZWN0LiBJIGRvbid0IHRoaW5rIFJGQyBlZGl0b3IgY2FuIGRv IHRoZSBhY3Rpb24geW91IGFyZQ0KPiBhc2tpbmcgdGhlbSB0byBkbyBvbiB0aGVpciBvd24uIFRo ZXkgd291bGQgbmVlZCBhbiBlcnJhdGEgKHdoaWNoIGlzIG5vdCBjb3JyZWN0DQo+IGhlcmUpIG9y IGFub3RoZXIgZG9jdW1lbnQgdGhhdCB1cGRhdGVzIFJGQyA2MjQxLiBJbiBteSB2aWV3IHRoaXMg ZG9jdW1lbnQNCj4gc2hvdWxkIGp1c3QgdXBkYXRlIFJGQyA2MjQxIChhbmQgbWFyayB0aGF0IGlu IHRoaXMgZG9jdW1lbnQncw0KPiBoZWFkZXIpIGFuZCBkbyBuZWNlc3NhcnkgdGV4dCBjaGFuZ2Vz IHRvIHJlZmxlY3QgdGhhdC4NCg0KSSBhbSBoYXBweSB0byBmb2xsb3cgd2hhdGV2ZXIgcHJvY2Vz cyBpcyBjbGVhbmVzdC4gICANCg0KS2VudCwgYXJlIHlvdSBjb21mb3J0YWJsZSB3aXRoIHRoaXMg ZG9jdW1lbnQgZGlyZWN0bHkgcmV2aXNpbmcgIHdvcmRpbmcgb2YgUkZDLTYyNDEgc2VjdGlvbiAx LjIgYnVsbGV0ICIoMikiIGFib3ZlPyAgICBJZiB5ZXMsIGl0IHdvdWxkIGJlIGdyZWF0IHRvIGhh dmUgeW91ciB0aG91Z2h0cyBvbiB3aGF0IG5lZWRzIHRvIGdvIGludG8gdGhpcyBkb2N1bWVudC4g ICBFc3BlY2lhbGx5IGFzIFJGQy02MjQxIHNlY3Rpb24gMS4yIGJ1bGxldCAiKDIpIiBhbHJlYWR5 IGhhZCBhIGZpeCBhcHBsaWVkIGFnYWluc3QgaXQuIA0KDQo+IE1pbm9yIElzc3VlczoNCj4gLS0t LS0tLS0tLS0tLQ0KPiAoMSkgQWJzdHJhY3QgJiBJbnRyb2R1Y3Rpb24sIEl0IGlzIG5vdCBjbGVh ciB3aGF0IGRvZXMgdGhlICdiaW5kaW5nJyBtZWFuIGFuZCB3aG8NCj4gYXJlIHRoZSBwYXJ0aWVz IHRvIHRoaXMgYmluZGluZz8gSWYgdGhpcyBpcyB0aGUgZG9jdW1lbnQgdGhhdCBtZW50aW9ucyAn YmluZGluZycNCj4gZmlyc3QsIHNvIHBsZWFzZSBhZGQgc29tZSBtb3JlIGNsYXJpZnlpbmcgdGV4 dC4NCj4gDQo+ICgyKSBTZWN0aW9uIDMsIHNpbmNlIHlvdSB1c2UgTVVTVCBpbiB0aGUgZXJyb3Ig aGFuZGxpbmcsIGlzbid0IGl0IGJldHRlciB0byB1c2UNCj4gbm9ybWF0aXZlIGluIGJlbG93IHNl bnRlbmNlIGFzIHdlbGwgLQ0KPiBPTEQ6DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBIb3dldmVyIGEgc2luZ2xlDQo+ICAgIE5FVENPTkYg dHJhbnNwb3J0IHNlc3Npb24gY2Fubm90IHN1cHBvcnQgYm90aCB0aGlzIHNwZWNpZmljYXRpb24g YW5kDQo+ICAgIGEgc3Vic2NyaXB0aW9uIGVzdGFibGlzaGVkIGJ5IFtSRkM1Mjc3XSdzICJjcmVh dGUtc3Vic2NyaXB0aW9uIiBSUEMuDQo+IE5FVzoNCj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEhvd2V2ZXIgYSBzaW5nbGUNCj4gICAgTkVU Q09ORiB0cmFuc3BvcnQgc2Vzc2lvbiBNVVNUIE5PVCBzdXBwb3J0IGJvdGggdGhpcyBzcGVjaWZp Y2F0aW9uIGFuZA0KPiAgICBhIHN1YnNjcmlwdGlvbiBlc3RhYmxpc2hlZCBieSBbUkZDNTI3N10n cyAiY3JlYXRlLXN1YnNjcmlwdGlvbiIgUlBDLg0KDQpNYWtlcyBzZW5zZS4gIEkgaGF2ZSBtYWRl IHRoZSBjaGFuZ2UsIGFuZCB3aWxsIHBvc3QgdGhlIHVwZGF0ZSB3aGVuIHRoZSAiTWFqb3IgaXNz dWUiIGZyb20gYWJvdmUgaXMgcmVzb2x2ZWQuDQoNCj4gKDMpIFNlY3Rpb24gNiwgWW91IGhhdmUg LQ0KPiANCj4gICAgQW5kIHBlciBbUkZDNTI3N10ncyAiZXZlbnRUaW1lIiBvYmplY3QgZGVmaW5p dGlvbiwgdGhlDQo+ICAgICJldmVudFRpbWUiIE1VU1QgYmUgcG9wdWxhdGVkIHdpdGggdGhlIGV2 ZW50IG9jY3VycmVuY2UgdGltZS4NCj4gDQo+IElzIHRoaXMgYSBuZXcgcmVxdWlyZW1lbnQsIG9y IGp1c3QgcmUtc3RhdGluZyBSRkM1Mjc3PyBSRkM1Mjc3IHNheXMgLQ0KPiANCj4gICAgICAgZXZl bnRUaW1lDQo+IA0KPiAgICAgICAgICBUaGUgdGltZSB0aGUgZXZlbnQgd2FzIGdlbmVyYXRlZCBi eSB0aGUgZXZlbnQgc291cmNlLiAgVGhpcw0KPiAgICAgICAgICBwYXJhbWV0ZXIgaXMgb2YgdHlw ZSBkYXRlVGltZSBhbmQgY29tcGxpYW50IHRvIFtSRkMzMzM5XS4NCj4gICAgICAgICAgSW1wbGVt ZW50YXRpb25zIG11c3Qgc3VwcG9ydCB0aW1lIHpvbmVzLg0KPiANCj4gICAgICAgQWxzbyBjb250 YWlucyBub3RpZmljYXRpb24tc3BlY2lmaWMgdGFnZ2VkIGNvbnRlbnQsIGlmIGFueS4gIFdpdGgN Cj4gICAgICAgdGhlIGV4Y2VwdGlvbiBvZiA8ZXZlbnRUaW1lPiwgdGhlIGNvbnRlbnQgb2YgdGhl IG5vdGlmaWNhdGlvbiBpcw0KPiAgICAgICBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1l bnQuDQo+IA0KPiBNYXliZSByZW1vdmUgTVVTVD8gSWYgeW91IGFyZSB0cnlpbmcgdG8gcmVmaW5l IHRoZSB0ZXh0IGZyb20gUkZDNTI3NywgdGhlbg0KPiBwbGVhc2UgcmUtd29yZC4NCg0KWW91IGFy ZSBjb3JyZWN0LiAgVGhlIE1VU1QgaXMgcmVkdW5kYW50IHdpdGggUkZDLTUyNzcncyBYU0QgZGVm aW5pdGlvbi4gICBUaGVyZWZvcmUgSSBoYXZlIHJlbW92ZWQgIk1VU1QgYmUiLg0KDQo+IE5pdHM6 DQo+IC0tLS0tDQo+ICgxKSBBYnN0cmFjdA0KPiANCj4gICAgUkZDIEVkaXRvciBub3RlOiBwbGVh c2UgcmVwbGFjZSB0aGUgZm91ciByZWZlcmVuY2VzIHRvIHByZS1SRkMNCj4gICAgbm9ybWF0aXZl IGRyYWZ0cyB3aXRoIHRoZSBhY3R1YWwgYXNzaWduZWQgUkZDIG51bWJlcnMuDQo+IA0KPiBJIHNl ZSB0d28gZHJhZnRzIGluIHRoZSByZWZlcmVuY2Ugc2VjdGlvbi4gV2h5IGZvdXI/DQoNCllvdSBh cmUgY29ycmVjdC4gIEkgcmVtb3ZlZCB0aGUgd29yZCAiZm91ciIuICANCg0KPiBBbHNvLCBzaW5j ZSB0aG9zZSB0d28gYXJlIG5vcm1hdGl2ZSByZWZlcmVuY2VzLCB0aGVzZSB3b3VsZCBiZSBwdWJs aXNoZWQgYXMgYQ0KPiBjbHVzdGVyIGFzIGEgcGFydCBvZiBub3JtYWwgUkZDIGVkaXRvciBwcm9j ZXNzaW5nIHJpZ2h0Pw0KDQpZZXMuDQogDQo+ICgyKSBSZWdhcmRpbmcgTkVUQ09ORiwgdGhlIFJG QyBlZGl0b3Igc2F5cyBbMV0gLQ0KPiANCj4gTkVUQ09ORiAgICAtIE5ldHdvcmsgQ29uZmlndXJh dGlvbiBQcm90b2NvbCAoTkVUQ09ORikNCj4gICAgICAgICAgICAgICAgW05vdCB0eXBpY2FsbHkg ZXhwYW5kZWQgaW4gdGl0bGVzLCBidXQgZXhwYW5kIGluIGFic3RyYWN0XQ0KPiANCj4gUGxlYXNl IGV4cGFuZC4NCg0KRG9uZS4NCg0KPiAoMykgcy9bSS1ELmRyYWZ0LWlldGYtbmV0Y29uZi1zdWJz Y3JpYmVkLW5vdGlmaWNhdGlvbnNdDQo+ICAgICAgL1tJLUQuaWV0Zi1uZXRjb25mLXN1YnNjcmli ZWQtbm90aWZpY2F0aW9uc10NCg0KQWN0dWFsbHkgSSBjaGFuZ2VkIHRoZSBbSS1ELmlldGYtbmV0 Y29uZi15YW5nLXB1c2hdICB0byAgW0ktRC5kcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wdXNoXQ0K DQpUaGlzIG1ha2VzIGl0IGNvbnNpc3RlbnQgYWNyb3NzIGFsbCBmb3VyIGRyYWZ0cy4NCg0KVGhh bmtzIGFnYWluIQ0KRXJpYw0KDQo+IEp1c3Qgc28gdGhhdCB5b3UgaGF2ZSB0aGUgc2FtZSBzdHls ZSBvZiBkcmFmdCByZWZlcmVuY2UgaW4gdGhlIGRvY3VtZW50LiBJIGdldA0KPiB0aGF0IGl0IHdv dWxkIGJlIHJlcGxhY2VkIHdpdGggYSBSRkMgbnVtYmVyIGFueXdheXMgOikNCj4gDQo+IFsxXSBo dHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9tYXRlcmlhbHMvYWJicmV2LmV4cGFuc2lvbi50eHQN Cj4gDQo+IFRoYW5rcyENCj4gRGhydXYNCg== From nobody Tue Apr 30 10:57:13 2019 Return-Path: <0100016a6f64a438-50e97747-d12b-429b-8147-8bf6ed82bdac-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D485D120321 for ; Tue, 30 Apr 2019 10:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBjPphLyh8i5 for ; Tue, 30 Apr 2019 10:57:09 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D566120329 for ; Tue, 30 Apr 2019 10:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556647028; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=UunYTGwdE5/EnSAavPxD5KhtrZ2yICbQl+elryl72eo=; b=YNZY5r5OCiCqPW+++4tdfmtJ03lYurvu4cCVjflcHtLgOr01z16cg8XSOFDVfKwl u28v1WM3VO/m+vB7TsU8WXoS6075U/7HarvgfY7IjbZUMv19Gsr69z3qlhaaXfxtuMs M0DNMCjWd51nQYpjXBRlYXy3VQumLSUHlUVA3y0E= From: Kent Watsen Message-ID: <0100016a6f64a438-50e97747-d12b-429b-8147-8bf6ed82bdac-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3DC919B8-DF9E-4C7F-8E65-7FA49758BA63" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 30 Apr 2019 17:57:07 +0000 In-Reply-To: <20190430.144930.844252169549242587.mbj@tail-f.com> Cc: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= , "netconf@ietf.org" To: Martin Bjorklund References: <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com> <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> <20190430.144930.844252169549242587.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.04.30-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 17:57:13 -0000 --Apple-Mail=_3DC919B8-DF9E-4C7F-8E65-7FA49758BA63 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > I (still) object to this. Actions shouldn't create config. We > already have generic protcol operations to do this. We go from a > document-oriented configuration model towards a command-oriented > model. Not good. In RESTCONF, the generic methods support things > like ETags, which I suspect you don't want to replicate in this > action? Will the action support all error-options of edit-config, > like rollback-on-error? The specifics for how this could work would need to be defined. Given = that it is a special case, I think that we could constrain it heavily = and target simple solution. Depending how much text is required to = describe it, it might be good to define an extension statement that = could be placed on the actions. While an extension statement may seem = like it opens the gates for general use, we could further define the = extension statement as being something that MUST NOT be used when = general purpose operations are suitable such that, at least with the = IETF, it could only be used in extraordinary circumstances. > Some comments on the new text: >=20 > In action generate-hidden-key, it should be stated that the public-key > will be populated, and that the private-key will exist but report > 'permanently-hidden'. Okay, but before making the edit, see comment below about lifetimes... > In action install-hidden-key, shouldn't both public-key and > private-key be mandatory? Also state that the private-key will report > 'permanently-hidden'. Indeed, fixed. > In leaf private-key, the type binary part of the union doesn't have a > description, and the description for the leaf itself says: >=20 > A binary that contains the value of the private key. >=20 > which is not quite correct. >=20 > I think we should state that the enum 'permanently-hidden' is only > reported in operational state. The 'type' statement doesn't have 'description' as a substatement,=20 but, point taken, two updates: In leaf private-key: OLD: A binary that contains the value of the private key. NEW: Either a binary that contains the value of the private key or, in=20= the case of a hidden key, the value 'permanently-hidden'. In enum permanently-hidden: OLD: The private key is inaccessible due to being protected by the system (e.g., a cryptographic hardware module). NEW: The private key is inaccessible due to being protected by the system (e.g., a cryptographic hardware module). Since hidden keys are only ever reported in , the value 'permanently-hidden' never appears in . > The new descriptions say: >=20 > [...] present only in > and bound to the lifetime of the parent > 'config true' node. >=20 > Aren't all nodes bound to the lifetime of their parent? > The action is invoked in a node that exists in and it > creates a key. What does the statement tell me? This seems like something new (and maybe wrong) and hence needs to be = explained. This seems new because we are saying that the lifetime of an = operational value is tied to the lifetime of a configured value. = Normally we talk about how operational values exist on their own and = that, if one wants to override/extend them (e.g., associate a = certificate to the private key created by the manufacturer), = configuration would overlay the operational values. By extension, if = the configuration is removed, the operational values go back to their = original state (i.e., existing on their own). Here we're saying that, = if the configuration (for the parent node) is removed, the operational = values are removed as well. Note that this statement was added because Juergen asked about how = hidden keys could be removed/replaced. We iterated towards not wanting = to support the "replace" case, and this seemed like an easy way to = handle the "remove" case. Another way to do this would be via another = action such as 'remove-hidden-key'. What do you think would be best? Kent // contributor --Apple-Mail=_3DC919B8-DF9E-4C7F-8E65-7FA49758BA63 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

I (still) object to this.  Actions shouldn't create = config.  We
already have = generic protcol operations to do this.  We go from a
document-oriented configuration model towards a = command-oriented
model.  Not good.  In RESTCONF, = the generic methods support things
like ETags, which I = suspect you don't want to replicate in this
action? =   Will the action support all error-options of edit-config,
like rollback-on-error?

The = specifics for how this could work would need to be defined.  Given = that it is a special case, I think that we could constrain it heavily = and target simple solution.   Depending how much text is required = to describe it, it might be good to define an extension statement that = could be placed on the actions.  While an extension statement may = seem like it opens the gates for general use, we could further define = the extension statement as being something that MUST NOT be used when = general purpose operations are suitable such that, at least with the = IETF, it could only be used in extraordinary = circumstances.


Some comments = on the new text:

In action = generate-hidden-key, it should be stated that the public-key
will be populated, and that the private-key will exist but = report
'permanently-hidden'.

Okay, but = before making the edit, see comment below about lifetimes...



In action install-hidden-key, shouldn't both public-key = and
private-key be mandatory?  Also state that the = private-key will report
'permanently-hidden'.

Indeed, = fixed.


In leaf = private-key, the type binary part of the union doesn't have a
description, and the description for the leaf itself says:

      A binary = that contains the value of the private key.

which is not quite correct.

I = think we should state that the enum 'permanently-hidden' is only
reported in operational state.

The = 'type' statement doesn't have 'description' as a = substatement, 
but, point taken, two = updates:

In leaf private-key:
  = OLD:
      A binary that contains the value of = the private key.
  NEW:
      = Either a binary that contains the value of the private key or, = in 
      the case of a hidden key, the = value 'permanently-hidden'.

In = enum permanently-hidden:
  OLD:
  =      The private key is inaccessible due to = being protected by the
       system = (e.g., a cryptographic hardware module).
  = NEW:
       The private key is = inaccessible due to being protected by the
    =    system (e.g., a cryptographic hardware module). =  Since hidden
       keys are only = ever reported in <operational>, the value
    =    'permanently-hidden' never appears in = <intended>.


The new descriptions say:

=            [...] = present only in
=            <oper= ational> and bound to the lifetime of the parent
=            'config = true' node.

Aren't all nodes bound to the = lifetime of their parent?
The action is invoked in a node = that exists in <operational> and it
creates a key. =  What does the statement tell me?

This seems = like something new (and maybe wrong) and hence needs to be explained. =  This seems new because we are saying that the lifetime of an = operational value is tied to the lifetime of a configured value. =  Normally we talk about how operational values exist on their own = and that, if one wants to override/extend them (e.g., associate a = certificate to the private key created by the manufacturer), = configuration would overlay the operational values.  By extension, = if the configuration is removed, the operational values go back to their = original state (i.e., existing on their own).   Here we're saying = that, if the configuration (for the parent node) is removed, the = operational values are removed as well.

Note that this statement was added because Juergen = asked about how hidden keys could be removed/replaced.   We = iterated towards not wanting to support the "replace" case, and this = seemed like an easy way to handle the "remove" case.  Another way = to do this would be via another action such as 'remove-hidden-key'. =   What do you think would be best?


Kent // = contributor

= --Apple-Mail=_3DC919B8-DF9E-4C7F-8E65-7FA49758BA63-- From nobody Tue Apr 30 11:07:44 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AF01202F6 for ; Tue, 30 Apr 2019 11:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEZuDPSIPasp for ; Tue, 30 Apr 2019 11:07:40 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 15E241202CC for ; Tue, 30 Apr 2019 11:07:40 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id d15so1708700ljc.7 for ; Tue, 30 Apr 2019 11:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nhL8vmxc5wvQxDYjg2tqIjTF0cq+B33k+wnrLmqJwaM=; b=eode0nWdwgW9fuhcEUf0fMXQy8cSAOVoAYl9QGoookCCgAUs4Bm0WC53Awy0u4h6KF JPTL9K1s5MniGVr+EKKIQVN67osqNDpLDsmq85mfbQMbIUu64gKCPdyrfkHTewmHen/b z8hqihILC2SO57wlPPcb1nYOe02u3GvQCHWRuIpzlsACcrpiS5xYYYyccDlAzGrDF+EY W7EALHeqsyFt68a+jUSMqjqBfTYS4fkWSfo0EZjETO8Heuav13aeXNwexkopq92BP/fs 0BTM62fJjTt9rEt8wwwwdaiyKXR1cCvPxVWBOjgCQ/WAt0QUMWf3xdLbJDdyLUpkHuOX sa/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nhL8vmxc5wvQxDYjg2tqIjTF0cq+B33k+wnrLmqJwaM=; b=FTpBi69W4gZUZRzyv9lOckAIPxVbpKhLXWTRrn0nSEpGusgkKqiPmJf2Ye5O1PTx5b 44nMITC3rPT4GcQoJF/gXGeAwCLK5ljL3b9vs2lpm/jWkMSjOW7tbc3jlXdFE1Zp9SpL iGf6dck0BJeL4wabG6wOxNnEq8IhFV+zTssaqCmfYHQ+QjZWjLzEquUvzBxFb28zTdRt q/MSTCGH6SLwvwV2TDwkbAutUDHwEgfqeMR5FVsWbD04ltMay7v8VwzXsRpnjqi8Ux4D dr8IAVhJ5Y5QYEkECDGb/Q6DD/oTzniL69RH+vys7XzWJjoZBAkTy7RRwshexRxew96d PNAw== X-Gm-Message-State: APjAAAWAG5bdPwWnwVRt/RtTgs6LAGPdEQCnY7w2Apu8l0YrOziTxxXO VrtWV14HRuEHfVl0RSLc9A8268+Rr9mgPUmUxFZg4w== X-Google-Smtp-Source: APXvYqwpdZAjjP0gPaDN1dGD5auErdXtaGIYKQB++/ZQ0Igy6K09XGY9WHTMCma7FnmAWRo2CPrtiYxXwnaI4FvIRcQ= X-Received: by 2002:a2e:80d4:: with SMTP id r20mr13972017ljg.173.1556647657958; Tue, 30 Apr 2019 11:07:37 -0700 (PDT) MIME-Version: 1.0 References: <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com> <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> <20190430.144930.844252169549242587.mbj@tail-f.com> In-Reply-To: <20190430.144930.844252169549242587.mbj@tail-f.com> From: Andy Bierman Date: Tue, 30 Apr 2019 11:07:26 -0700 Message-ID: To: Martin Bjorklund Cc: Kent Watsen , Netconf Content-Type: multipart/alternative; boundary="000000000000b185050587c3466c" Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 18:07:43 -0000 --000000000000b185050587c3466c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 30, 2019 at 5:49 AM Martin Bjorklund wrote: > Kent Watsen wrote: > > > > Correct, as I didn=E2=80=99t think there was consensus yet. Perhaps th= ere is > > rough-consensus, and it may be that the only way to gauge that is to > > try and see how much push back there is. > > > > Okay, so how about this, based on this thread, there appears to be > > support to add a flag to control if a key should be =E2=80=9Cpermanentl= y > > hidden=E2=80=9D or not, in which case configuration is created. > > I (still) object to this. Actions shouldn't create config. We > already have generic protcol operations to do this. We go from a > document-oriented configuration model towards a command-oriented > model. Not good. In RESTCONF, the generic methods support things > like ETags, which I suspect you don't want to replicate in this > action? Will the action support all error-options of edit-config, > like rollback-on-error? > > > Strongly agree with Martin. This issue of "server-generated config" has been around from the start. NMDA was supposed to solve it. (It didn't). There seems to be a need for standardized mechanisms to tell the server how to magically instantiate data in that does not appear in . The solution should be consistent and not ad-hoc. This is a similar problem to config templates (which also lack any standard solution). Andy Some comments on the new text: > > In action generate-hidden-key, it should be stated that the public-key > will be populated, and that the private-key will exist but report > 'permanently-hidden'. > > In action install-hidden-key, shouldn't both public-key and > private-key be mandatory? Also state that the private-key will report > 'permanently-hidden'. > > In leaf private-key, the type binary part of the union doesn't have a > description, and the description for the leaf itself says: > > A binary that contains the value of the private key. > > which is not quite correct. > > I think we should state that the enum 'permanently-hidden' is only > reported in operational state. > > The new descriptions say: > > [...] present only in > and bound to the lifetime of the parent > 'config true' node. > > Aren't all nodes bound to the lifetime of their parent? > The action is invoked in a node that exists in and it > creates a key. What does the statement tell me? > > > /martin > > > > > > > This change will be in the next update, in about a week=E2=80=99s time,= if no > > objections are raised. > > > > Kent // contributor > > > > > > > On Apr 30, 2019, at 7:30 AM, Bal=C3=A1zs Kov=C3=A1cs > > > wrote: > > > > > > Hi Kent, > > > > > > I don=E2=80=99t see the your proposal below addressed in latest updat= e > > > (keystore-09). Was it missed? > > > > > > My recommendation is to modify the "generate/install-hidden-key" > > > (renamed to just "generate/install-key") actions to have a flag > > > indicating if > > > the key should be "permanently hidden" (perhaps by using a TPM) or > > > not, in > > > which case configuration is created, same as if the client had used > > > > > config>, but without needing to touch the key. > > > > > > > > > I agree that having a flag to control the behavior is useful and I > > > think there should be explicit text how the action fails in case the > > > requested action cannot be performed. > > > > > > Br, > > > Balazs > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000b185050587c3466c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Apr 30, 2019 at 5:49 AM Marti= n Bjorklund <mbj@tail-f.com> wr= ote:
Kent Watsen= <kent+ietf@= watsen.net> wrote:
>
> Correct, as I didn=E2=80=99t think there was consensus yet.=C2=A0 Perh= aps there is
> rough-consensus, and it may be that the only way to gauge that is to > try and see how much push back there is.
>
> Okay, so how about this, based on this thread, there appears to be
> support to add a flag to control if a key should be =E2=80=9Cpermanent= ly
> hidden=E2=80=9D or not, in which case configuration is created.

I (still) object to this.=C2=A0 Actions shouldn't create config.=C2=A0 = We
already have generic protcol operations to do this.=C2=A0 We go from a
document-oriented configuration model towards a command-oriented
model.=C2=A0 Not good.=C2=A0 In RESTCONF, the generic methods support thing= s
like ETags, which I suspect you don't want to replicate in this
action?=C2=A0 =C2=A0Will the action support all error-options of edit-confi= g,
like rollback-on-error?




Strongly agree with Mar= tin.
This issue of "server-generated config" has been a= round from the start.
NMDA was supposed to solve it. (It didn'= ;t).
There seems to be a need for standardized mechanisms to tell= the
server how to magically instantiate data in <intended>= that does not appear in <running>.

The solu= tion should be consistent and not ad-hoc.
This is a similar probl= em to config templates (which also lack any standard solution).
<= br>

Andy

Some comments on the new text:

In action generate-hidden-key, it should be stated that the public-key
will be populated, and that the private-key will exist but report
'permanently-hidden'.

In action install-hidden-key, shouldn't both public-key and
private-key be mandatory?=C2=A0 Also state that the private-key will report=
'permanently-hidden'.

In leaf private-key, the type binary part of the union doesn't have a description, and the description for the leaf itself says:

=C2=A0 =C2=A0 =C2=A0 =C2=A0A binary that contains the value of the private = key.

which is not quite correct.

I think we should state that the enum 'permanently-hidden' is only<= br> reported in operational state.

The new descriptions say:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [...] present only in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <operational> and bound to = the lifetime of the parent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 'config true' node.

Aren't all nodes bound to the lifetime of their parent?
The action is invoked in a node that exists in <operational> and it creates a key.=C2=A0 What does the statement tell me?


/martin



>
> This change will be in the next update, in about a week=E2=80=99s time= , if no
> objections are raised.
>
> Kent // contributor
>
>
> > On Apr 30, 2019, at 7:30 AM, Bal=C3=A1zs Kov=C3=A1cs
> > <balazs.kovacs@ericsson.com> wrote:
> >
> > Hi Kent,
> >=C2=A0
> > I don=E2=80=99t see the your proposal below addressed in latest u= pdate
> > (keystore-09). Was it missed?
> >=C2=A0
> > My recommendation is to modify the "generate/install-hidden-= key"
> > (renamed to just "generate/install-key") actions to hav= e a flag
> > indicating if
> > the key should be "permanently hidden" (perhaps by usin= g a TPM) or
> > not, in
> > which case configuration is created, same as if the client had us= ed
> > <edit-
> > config>, but without needing to touch the key.
> >
> >
> > I agree that having a flag to control the behavior is useful and = I
> > think there should be explicit text how the action fails in case = the
> > requested action cannot be performed.
> >=C2=A0
> > Br,
> > Balazs
_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000b185050587c3466c-- From nobody Tue Apr 30 12:00:18 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0772120341; Tue, 30 Apr 2019 12:00:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-netconf-subscribed-notifications@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <155665081164.7668.3304106941009307050.idtracker@ietfa.amsl.com> Date: Tue, 30 Apr 2019 12:00:11 -0700 Archived-At: Subject: [netconf] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-netconf-subscribed-notifications-24=3A_=28with_COMMENT=29?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 19:00:17 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-netconf-subscribed-notifications-24: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I appreciate the goal of this document to specify another telemetry streaming than gRPC. As the I-D has been reviewed by YANG-doctors, I did not look in the YANG module. Comments -------- C1) section 1.3, should the published check authorization before accepting an subscription? There is some text in section 3.1 is about authorization but I would prefer to have this authorization stated as early as possible C2) end of section 1.3, "transport drafts" shouldn't rather be "transport specifications" ? C3) end of section 1.3, upon termination decided by the publisher, is there a need for any explanation message sent to the subscriber? C4) is there any reason why the YANG module validation but the datatracker fails? Outdated/invalid PYANG ? C5) section 2.2 "all event records on an event stream are to be sent", should there be a mention of publisher being out of ressource ? C6) section 2.4.1 "insufficient CPU or bandwidth available" but there may be other reasons (e.g. memory), what about using "insufficient CPU, bandwidth unavailable or other lack of ressource" C7) for my curiosity, in section 2.4.2.1, how deep could realistically be a replay buffer? Minutes? C8) the term 'transport' is used quite often in the document but it seems to refer to NETCONF and not so much to my understanding of 'transport' in an IETF document (which is TCP, UDP, SCTP, ...). Is it obvious to the readers? If so, then I do not mind. Else, it may be useful to clarify in section 1.2 Nits ---- N1) is there any reason why not all Cisco authors are not grouped together? (even if another one has changed affiliation) N2) abstract s/information/data/ also applicable in other sections IMHO N3) section 1.3, expand RPC even if obvious N4) section 2.3, expand QoS even if obvious From nobody Tue Apr 30 12:24:05 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71551200F4; Tue, 30 Apr 2019 12:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMUrjEvEwPyt; Tue, 30 Apr 2019 12:23:54 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20070.outbound.protection.outlook.com [40.107.2.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE0512004F; Tue, 30 Apr 2019 12:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RhCgwGEodUf/Ma/AtbDXJnxa6jPNXm4d916etv2s47s=; b=VflOkaFJsP2ubYGhuy/RM6YL5UF42Br7mbR2jVjDUPHmECwvLG7N3IOIzVfzZpPs1tp/10BI4J9Xoen36BNOoy4BLXiCNLkREkNM8XhJm0AR3HFQ08+KAg/Yw/9MEQ1WRDkawjxTRr9pxrREqkOvtac3ZhLFzmgNZQ6JAzaT0/8= Received: from AM0PR07MB6098.eurprd07.prod.outlook.com (20.178.112.202) by AM0PR07MB3921.eurprd07.prod.outlook.com (52.134.80.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.7; Tue, 30 Apr 2019 19:23:50 +0000 Received: from AM0PR07MB6098.eurprd07.prod.outlook.com ([fe80::51c1:e0b4:df3a:9508]) by AM0PR07MB6098.eurprd07.prod.outlook.com ([fe80::51c1:e0b4:df3a:9508%7]) with mapi id 15.20.1856.008; Tue, 30 Apr 2019 19:23:50 +0000 From: Daniele Ceccarelli To: " (rtg-ads@ietf.org)" CC: "rtg-dir@ietf.org" , "netconf@ietf.org" , "draft-ietf-netconf-yang-push.all@ietf.org" Thread-Topic: RtgDir review: draft-ietf-netconf-yang-push-22 Thread-Index: AdT/ibE/okhBBmTeRrmMbA4t2aolTg== Date: Tue, 30 Apr 2019 19:23:50 +0000 Message-ID: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [90.232.1.210] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5c5d932b-9cf3-4128-aa09-08d6cda16033 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:AM0PR07MB3921; x-ms-traffictypediagnostic: AM0PR07MB3921: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00235A1EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(136003)(376002)(346002)(396003)(189003)(199004)(71190400001)(5660300002)(71200400001)(66946007)(66556008)(66446008)(64756008)(66476007)(2906002)(14444005)(256004)(66066001)(478600001)(186003)(44832011)(102836004)(52536014)(316002)(54906003)(14454004)(486006)(86362001)(26005)(6506007)(476003)(6306002)(8936002)(9686003)(25786009)(54896002)(53936002)(74316002)(97736004)(8676002)(236005)(68736007)(81156014)(81166006)(7736002)(606006)(33656002)(450100002)(6116002)(790700001)(99286004)(73956011)(7696005)(76116006)(3846002)(6436002)(55016002)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB3921; H:AM0PR07MB6098.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /HIpNyYyLFHYqiZc5ddZqgbdDlFRTXqAP0oTar77PAWlETNv0Y0qMd9TYcASDlDCqBYHB1ObESzcECf2I2O04zSwQdDZxDGZSbHLJ3q3LyErtqzyPC0WiSyYJEg3jErMWMfEu75/4W18Q7HptuBsDhBlcDY7oa78i2v9rTVP6ztguy+hapawskeb+SSFUCLu/ZOth+AAgO0P5K9munmlxjcRNqmKsPKZBAbglqNGnjVFQ4DZeZfP1oIuRDKbljBZDikk3C+/liEyN3L5mF8WzqtJ8pkYf9zx1tS/p0bWFkhC429pq2AIUkUbQZFupf7bk7J3JZFlogldmsp8XCMcM0txsxJVPsIeK9MoYhjVYlwM9Y9JyVF1DRcNj1f5UQwX6JM13f3bpBK0HtHIc+6UdluTZaZKCzZ76Akf8xl4yDY= Content-Type: multipart/alternative; boundary="_000_AM0PR07MB609874A375A159709AC41C3FF03A0AM0PR07MB6098eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5c5d932b-9cf3-4128-aa09-08d6cda16033 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2019 19:23:50.5931 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB3921 Archived-At: Subject: [netconf] RtgDir review: draft-ietf-netconf-yang-push-22 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 19:23:58 -0000 --_000_AM0PR07MB609874A375A159709AC41C3FF03A0AM0PR07MB6098eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMg b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXI8aHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcj4NCg0KQWx0aG91Z2ggdGhlc2UgY29t bWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdv dWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkg b3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2 ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBk cmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMjINClJldmll d2VyOiBEYW5pZWxlIGNlY2NhcmVsbGkNClJldmlldyBEYXRlOiAyMDE5LTA0LTMwDQpJRVRGIExD IEVuZCBEYXRlOg0KSW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sNCg0KU3VtbWFyeToN Cg0KKiAgICAgICBUaGlzIGRvY3VtZW50IGlzIGJhc2ljYWxseSByZWFkeSBmb3IgcHVibGljYXRp b24sIGJ1dCBoYXMgbml0cyB0aGF0IHNob3VsZCBiZSBjb25zaWRlcmVkIHByaW9yIHRvIHB1Ymxp Y2F0aW9uLg0KDQpDb21tZW50czoNCg0KKiAgICAgICBUaGUgZHJhZnQgaXMgd2VsbCBzdHJ1Y3R1 cmVkIGFuZCBjb3ZlcnMgYSBsb3Qgb2YgZGlmZmVyZW50IGFzcGVjdHMgb2YgdGhlIHByb3Bvc2Vk IG1ldGhvZC4gSSBvbmx5IGhhdmUgc29tZSBjb25jZXJucyBvbiByZWFkYWJpbGl0eSBhbmQgcXVh bGl0eSBvZiBFbmdsaXNoLiBBIHJldmlldyBmcm9tIGEgbW90aGVyIHRvbmd1ZSB3b3VsZCBpbXBy b3ZlIGl0IHNpZ25pZmljYW50bHkuIChtYXliZSB0aGUgUkZDIGVkaXRvciBzaG91bGQgYmUgZW5v dWdoKS4NCg0KTWFqb3IgSXNzdWVzOg0KDQoqICAgICAgIE5vIG1ham9yIGlzc3VlcyBmb3VuZA0K DQpNaW5vciBJc3N1ZXM6DQoNCiogICAgICAgTnVtYmVyIG9mIGF1dGhvcnMgb24gdGhlIGZyb250 IHBhZ2U6IHNob3VsZG7igJl0IGl0IGJlIDUgbWF4Pw0KKiAgICAgICBTZWN0aW9uIDM6IOKAnFRo aXMgc29sdXRpb24gc3VwcG9ydHMgZHluYW1pYyBhcyB3ZWxsIGFzIGNvbmZpZ3VyZWQgc3Vic2Ny aXB0aW9ucyB0byB1cGRhdGVzIG9mIGRhdGFzdG9yZSBub2Rl4oCdLiBXaGF0IGRvZXMgZHluYW1p YyBhbmQgY29uZmlndXJlZCBtZWFuPyBJdOKAmXMgcHJvYmFibHkgZGVmaW5lZCBpbiBvdGhlciBk b2N1bWVudHM/DQoqICAgICAgIFNlY3Rpb24gMy4yLiDigJxIb3dldmVyLCB0aGVyZSBhcmUgbm8g Z3VhcmFudGVlcyB0aGF0IHN1YnNlcXVlbnQgcmVxdWVzdHMgd2hpY2ggY29uc2lkZXIgdGhlc2Ug aGludHMgd2lsbCBiZSBhY2NlcHRlZC7igJ0gV2hhdCBoYXBwZW5zIHRoZW4/IFVuZGVmaW5lZCBu dW1iZXIgb2YgcmV0cmllcz8NCiogICAgICAgMy41LjEuICBQZXJpb2RpYyBTdWJzY3JpcHRpb25z OuKAnUluIGEgcGVyaW9kaWMgc3Vic2NyaXB0aW9uLCB0aGUgZGF0YSBpbmNsdWRlZCBhcyBwYXJ0 IG9mIGFuIHVwZGF0ZSByZWNvcmQgY29ycmVzcG9uZHMgdG8gZGF0YSB0aGF0IGNvdWxkIGhhdmUg YmVlbiByZWFkIHVzaW5nIGEgcmV0cmlldmFsIG9wZXJhdGlvbi7igJ0uIElzIGl0IG5vdCBwb3Nz aWJsZSB0byBoYXZlIHBlcmlvZGljIHN1YnNjcmlwdGlvbnMgd2l0aCBqdXN0IHRoZSBkZWx0YSBi ZXR3ZWVuIHRoZSBwcmV2aW91cyB1cGRhdGUgYW5kIHRoZSBsYXN0IG9uZT8gRXZlcnl0aGluZyBu ZWVkcyB0byBiZSBzZW50IGF0IGFueSB0aW1lPw0KDQpOaXRzOg0KDQoqICAgICAgIEFic3RyYWN0 OiBzdWdnZXN0IHRvIGNoYW5nZSDigJxjb250aW51b3VzLCBjdXN0b21pemVk4oCdIHdpdGgg4oCc Y29udGludW91cyBhbmQgY3VzdG9taXplZOKAnS4NCiogICAgICAgTWF5YmUgaXTigJlzIGJldHRl ciB0byBjaGFuZ2UgdGhlIGZpcnN0IHNlbnRlbmNlIGVudGlyZWx5LiBIb3cgYWJvdXQ6IOKAnCAg VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZWNoYW5pc20gdGhhdCBhbGxvd3Mgc3Vic2NyaWJl ciBhcHBsaWNhdGlvbnMgcmVxdWVzdGluZyBhIGNvbnRpbnVvdXMgYW5kIGN1c3RvbWl6ZWQgc3Ry ZWFtIG9mIHVwZGF0ZXMgZnJvbSBhIFlBTkcgZGF0YXN0b3JlLuKAnQ0KKiAgICAgICDigJxUcmFk aXRpb25hbCBhcHByb2FjaGVzIHRvIHByb3ZpZGluZ+KAnSwgc2hvdWxkbuKAmXQgdGhpcyBiZSDi gJx0byBwcm92aWRl4oCdIG9yIOKAnG9mIHByb3ZpZGluZ+KAnT8NCiogICAgICAgUG9sbGluZyBp bmN1cnMgc2lnbmlmaWNhbnQgbGF0ZW5jeS4gVGhpcyBsYXRlbmN5IHByb2hpYml0cyBtYW55IGFw cGxpY2F0aW9uIHR5cGVzLiDigJMgQWxzbyB0aGlzIHNlbnRlbmNlIGRvZXNu4oCZdCBsb29rIHZl cnkgY29ycmVjdC4gQWN0dWFsbHkgdGhlIGVudGlyZSBzZWN0aW9uIGNhbiBiZSBpbXByb3ZlZCBm cm9tIGEgbGFuZ3VhZ2UgcGVyc3BlY3RpdmUuIChlLmcuIOKAnHlldCBmb3Igd2hpY2ggYXBwbGlj YXRpb25zIG5lZWQgdG8gYmUgcXVpY2tseSBub3RpZmllZCB3aGVuZXZlciBhIGNoYW5nZSBkb2Vz IG9jY3VyIHdpdGggbWluaW1hbCBkZWxheS7igJ0pDQoqICAgICAgIFtJLUQuZHJhZnQtaWV0Zi1u ZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9uc10gdXN1YWxseSBhIG1vcmUgZnJpZW5kbHkg cmVmZXJlbmNlIGlzIHVzZWQsIGUuZy4gW1NVQi1OT1RdDQoNCkJSDQoNCkRhbmllbGUNCg0KDQoN Cg== --_000_AM0PR07MB609874A375A159709AC41C3FF03A0AM0PR07MB6098eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uaWNvbg0KCXttc28tc3R5 bGUtbmFtZTppY29uO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBE ZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MzUyMzM5NDU0Ow0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotNjY5NzE1MjE2O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci Ow0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjM5MzMxMjcxMzsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEwOTU2MjExNzI7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcy LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3Qg bDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6OTg3OTAwMTMx Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjA1NDc1ODk2NDt9DQpAbGlzdCBsMjpsZXZlbDEN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpA bGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxMjI4 OTYwMzg5Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNjA2NTUxODIyO30NCkBsaXN0IGwzOmxl dmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i O30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwz OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0DQoJe21zby1saXN0LWlk OjE0MzYyNDc1ODQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE0MTk2NzQyODI7fQ0KQGxpc3Qg bDQ6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7fQ0KQGxpc3QgbDQ6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1 Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDQ6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRv bTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iU1YiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SGVsbG8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO2Zv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogMjt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93 czogMjstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7dGV4dC1kZWNvcmF0aW9uLXN0eWxl OiBpbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjogaW5pdGlhbDt3b3JkLXNwYWNpbmc6MHB4 Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkkgaGF2ZSBiZWVu IHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRy YWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcg b3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaA0KIElFVEYgbGFz dCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3Qu IFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRo ZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGly ZWN0b3JhdGUsIHBsZWFzZSBzZWUmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj48YSBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dp a2kvUnRnRGlyIj48c3BhbiBjbGFzcz0iaWNvbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiNCQjAwMDA7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPuKAizwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojQkIwMDAwIj5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90 cmFjL3dpa2kvUnRnRGlyPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGU7Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7b3JwaGFuczogMjt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogMjstd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOiBpbml0aWFsO3Rl eHQtZGVjb3JhdGlvbi1jb2xvcjogaW5pdGlhbDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkFsdGhvdWdoIHRoZXNlIGNvbW1lbnRz IGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBpdCB3b3VsZCBi ZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVy IElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91DQogcmVjZWl2ZSwgYW5kIHN0cml2ZSB0 byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFm dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTtmb250 LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBo YW5zOiAyO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiAyOy13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDt0ZXh0LWRlY29yYXRpb24tc3R5bGU6IGluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNv bG9yOiBpbml0aWFsO3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+RG9jdW1lbnQ6Jm5ic3A7ZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmct cHVzaC0yMjxicj4NClJldmlld2VyOiBEYW5pZWxlIGNlY2NhcmVsbGkmbmJzcDs8YnI+DQpSZXZp ZXcgRGF0ZTogMjAxOS0wNC0zMDxicj4NCklFVEYgTEMgRW5kIERhdGU6IDxicj4NCkludGVuZGVk IFN0YXR1czogU3RhbmRhcmRzIFRyYWNrPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpTViI+U3VtbWFyeTo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6U1YiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJk aXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDQgbGV2 ZWwxIGxmbzE7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlm O21zby1mYXJlYXN0LWxhbmd1YWdlOlNWIj5UaGlzIGRvY3VtZW50IGlzIGJhc2ljYWxseSByZWFk eSBmb3IgcHVibGljYXRpb24sIGJ1dCBoYXMgbml0cyB0aGF0IHNob3VsZCBiZSBjb25zaWRlcmVk IHByaW9yIHRvIHB1YmxpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpTViI+Q29tbWVudHM6PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6U1YiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzI7YmFja2dyb3VuZDp3aGl0ZSI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOlNWIj5U aGUgZHJhZnQgaXMgd2VsbCBzdHJ1Y3R1cmVkIGFuZCBjb3ZlcnMgYSBsb3Qgb2YgZGlmZmVyZW50 IGFzcGVjdHMgb2YgdGhlIHByb3Bvc2VkIG1ldGhvZC4gSSBvbmx5IGhhdmUgc29tZSBjb25jZXJu cyBvbiByZWFkYWJpbGl0eSBhbmQgcXVhbGl0eSBvZiBFbmdsaXNoLg0KIEEgcmV2aWV3IGZyb20g YSBtb3RoZXIgdG9uZ3VlIHdvdWxkIGltcHJvdmUgaXQgc2lnbmlmaWNhbnRseS4gKG1heWJlIHRo ZSBSRkMgZWRpdG9yIHNob3VsZCBiZSBlbm91Z2gpLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91 bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpTViI+TWFqb3IgSXNzdWVz Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1 YWdlOlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8zO2JhY2tn cm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1s YW5ndWFnZTpTViI+Tm8gbWFqb3IgaXNzdWVzIGZvdW5kPG86cD48L286cD48L3NwYW4+PC9saT48 L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlNWIj5NaW5vciBJc3N1 ZXM6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6U1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzQ7YmFj a2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0 LWxhbmd1YWdlOlNWIj5OdW1iZXIgb2YgYXV0aG9ycyBvbiB0aGUgZnJvbnQgcGFnZTogc2hvdWxk buKAmXQgaXQgYmUgNSBtYXg/PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm80O2JhY2tncm91bmQ6d2hp dGUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpT ViI+U2VjdGlvbiAzOiDigJxUaGlzIHNvbHV0aW9uIHN1cHBvcnRzIGR5bmFtaWMgYXMgd2VsbCBh cyBjb25maWd1cmVkIHN1YnNjcmlwdGlvbnMgdG8gdXBkYXRlcyBvZiBkYXRhc3RvcmUgbm9kZeKA nS4gV2hhdCBkb2VzIGR5bmFtaWMgYW5kIGNvbmZpZ3VyZWQgbWVhbj8gSXTigJlzIHByb2JhYmx5 DQogZGVmaW5lZCBpbiBvdGhlciBkb2N1bWVudHM/IDxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvNDti YWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6U1YiPlNlY3Rpb24gMy4yLiDigJxIb3dldmVyLCB0aGVyZSBhcmUgbm8gZ3Vh cmFudGVlcyB0aGF0IHN1YnNlcXVlbnQgcmVxdWVzdHMgd2hpY2ggY29uc2lkZXIgdGhlc2UgaGlu dHMgd2lsbCBiZSBhY2NlcHRlZC7igJ0gV2hhdCBoYXBwZW5zIHRoZW4/IFVuZGVmaW5lZCBudW1i ZXIgb2YNCiByZXRyaWVzPzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvNDtiYWNrZ3JvdW5kOndoaXRl Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6U1Yi PjMuNS4xLiZuYnNwOyBQZXJpb2RpYyBTdWJzY3JpcHRpb25zOuKAnUluIGEgcGVyaW9kaWMgc3Vi c2NyaXB0aW9uLCB0aGUgZGF0YSBpbmNsdWRlZCBhcyBwYXJ0IG9mIGFuIHVwZGF0ZSByZWNvcmQg Y29ycmVzcG9uZHMgdG8gZGF0YSB0aGF0IGNvdWxkIGhhdmUgYmVlbiByZWFkIHVzaW5nDQogYSBy ZXRyaWV2YWwgb3BlcmF0aW9uLuKAnS4gSXMgaXQgbm90IHBvc3NpYmxlIHRvIGhhdmUgcGVyaW9k aWMgc3Vic2NyaXB0aW9ucyB3aXRoIGp1c3QgdGhlIGRlbHRhIGJldHdlZW4gdGhlIHByZXZpb3Vz IHVwZGF0ZSBhbmQgdGhlIGxhc3Qgb25lPyBFdmVyeXRoaW5nIG5lZWRzIHRvIGJlIHNlbnQgYXQg YW55IHRpbWU/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlNWIj5OaXRzOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFn ZTpTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZvNTtiYWNrZ3Jv dW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6U1YiPkFic3RyYWN0OiBzdWdnZXN0IHRvIGNoYW5nZSDigJxjb250aW51b3VzLCBjdXN0 b21pemVk4oCdIHdpdGgg4oCcY29udGludW91cyBhbmQgY3VzdG9taXplZOKAnS48bzpwPjwvbzpw Pjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6 bDMgbGV2ZWwxIGxmbzU7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z LXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOlNWIj5NYXliZSBpdOKAmXMgYmV0dGVyIHRvIGNo YW5nZSB0aGUgZmlyc3Qgc2VudGVuY2UgZW50aXJlbHkuIEhvdyBhYm91dDog4oCcJm5ic3A7IFRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dzIHN1YnNjcmliZXIg YXBwbGljYXRpb25zIHJlcXVlc3RpbmcgYQ0KIGNvbnRpbnVvdXMgYW5kIGN1c3RvbWl6ZWQgc3Ry ZWFtIG9mIHVwZGF0ZXMgZnJvbSBhIFlBTkcgZGF0YXN0b3JlLuKAnTxvOnA+PC9vOnA+PC9zcGFu PjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMyBsZXZl bDEgbGZvNTtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6U1YiPuKAnFRyYWRpdGlvbmFsIGFwcHJvYWNoZXMgdG8gcHJv dmlkaW5n4oCdLCBzaG91bGRu4oCZdCB0aGlzIGJlIOKAnHRvIHByb3ZpZGXigJ0gb3Ig4oCcb2Yg cHJvdmlkaW5n4oCdPzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZvNTtiYWNrZ3JvdW5kOndoaXRlIj4N CjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6U1YiPlBv bGxpbmcgaW5jdXJzIHNpZ25pZmljYW50IGxhdGVuY3kuIFRoaXMgbGF0ZW5jeSBwcm9oaWJpdHMg bWFueSBhcHBsaWNhdGlvbiB0eXBlcy4g4oCTIEFsc28gdGhpcyBzZW50ZW5jZSBkb2VzbuKAmXQg bG9vayB2ZXJ5IGNvcnJlY3QuIEFjdHVhbGx5IHRoZSBlbnRpcmUgc2VjdGlvbg0KIGNhbiBiZSBp bXByb3ZlZCBmcm9tIGEgbGFuZ3VhZ2UgcGVyc3BlY3RpdmUuIChlLmcuIOKAnHlldCBmb3Igd2hp Y2ggYXBwbGljYXRpb25zIG5lZWQgdG8gYmUgcXVpY2tseSBub3RpZmllZCB3aGVuZXZlciBhIGNo YW5nZSBkb2VzIG9jY3VyIHdpdGggbWluaW1hbCBkZWxheS7igJ0pPG86cD48L286cD48L3NwYW4+ PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwzIGxldmVs MSBsZm81O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtt c28tZmFyZWFzdC1sYW5ndWFnZTpTViI+W0ktRC5kcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJl ZC1ub3RpZmljYXRpb25zXSB1c3VhbGx5IGEgbW9yZSBmcmllbmRseSByZWZlcmVuY2UgaXMgdXNl ZCwgZS5nLiBbU1VCLU5PVF08bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QlI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJJVCIgc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOlNWIj5EYW5pZWxlJm5ic3A7IDxvOnA+DQo8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_AM0PR07MB609874A375A159709AC41C3FF03A0AM0PR07MB6098eurp_-- From nobody Tue Apr 30 12:49:47 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1648120048; Tue, 30 Apr 2019 12:49:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-netconf-subscribed-notifications@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <155665377891.7475.13101015755522983059.idtracker@ietfa.amsl.com> Date: Tue, 30 Apr 2019 12:49:38 -0700 Archived-At: Subject: [netconf] Roman Danyliw's Discuss on draft-ietf-netconf-subscribed-notifications-24: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 19:49:39 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-netconf-subscribed-notifications-24: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Sections 2.4.2.1 and 2.5.6 seems to describe a mechanism (replay) to access historical data that was potentially collected prior to a given subscriber having access to it. This appears to be an explicitly designed feature. No push back on that. However, I believe that explicitly stating this arrangement is warranted. Perhaps something on the order of the following could be added to the Security Considerations -- “The replay mechanisms described in Sections 2.4.2.1 and 2.5.6 provides access to historical event records. By design, the access control model that protects these records could enable subscribers to view data to which they were not authorized at the time of collection.” ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) Section 2.5.1. Per Figure 8, if a modify operation fails re-evaluation (the “no (2)” branch) wouldn’t it go directly to “invalid” (instead of through “unsupportable->invalid”)? (2) Section 2.5.2, what are “transport specific call-home operations”? (3) Section 2.5.6. Typos s/timegap/time gap/ s/successfully/successfully/ From nobody Tue Apr 30 13:01:44 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA644120355; Tue, 30 Apr 2019 13:01:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-netconf-yang-push@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <155665449478.7617.650600167993918660.idtracker@ietfa.amsl.com> Date: Tue, 30 Apr 2019 13:01:34 -0700 Archived-At: Subject: [netconf] Roman Danyliw's No Objection on draft-ietf-netconf-yang-push-23: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 20:01:35 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-netconf-yang-push-23: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Per Section 3.7: -- Is the re-synchronization behavior/value of patch-id different with dynamic vs. configured subscriptions, especially if the publisher crashed or lost the connection? -- I’d recommend being explicit about the value by which patch-id gets incremented (1?) so that there won’t be ambiguity on the lost/out-of-sequence detection. From nobody Tue Apr 30 14:11:07 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DF312003E for ; Tue, 30 Apr 2019 14:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 vp4Std36r29A for ; Tue, 30 Apr 2019 14:10:54 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 E93B212004D for ; Tue, 30 Apr 2019 14:10:53 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id f25so18024747qtc.8 for ; Tue, 30 Apr 2019 14:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X1f7NvOillIptXBQ8bYAkjgMLkYleqejo0xuneF59IU=; b=gApq6SfgHiAIg7NvHsngFN/nXJ9SiYda67kK5TgbskB2+diuvO6ims6+Vwyjvsku1R nxmdOT0a7CRcU1C/kdnQbAkt1SkJbDJxIiuRIohqrsVoZ1d6jnJGNjpB6QTno7N/7+Wg GMQovx+BMBRFV3TjBHeseJbMY5uiVwqxBzBAMsL0zWoSF3W+fgupven/7kLDrlSxP2bh w5HXbI4WVGoIMYbOpYgniQgeYjjQRUKaDrY6dnjhTi92hPmSYPxkbatb3uDcYLeNwQbi KBTM0mZ7v05SJc07al3wZ+C+WDY5OEegmlLAEcB9P+Rgiofeq/+CVbzLDG/vhtNyoyfA CWvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=X1f7NvOillIptXBQ8bYAkjgMLkYleqejo0xuneF59IU=; b=IZWxF1NmtpsklHZvqwgyT8H27mEG3Ja9/pQ6TfX5Iu7s3qpEpr1GLpTZtNsoGtKzfJ YrWoPZjQQejQgzO3NGqxc+VrMJpehYvYSlYJY0i6GCD+cUdBscfb+qvx22X011/+WVkX eV7v/ZZqayXIWYGJ5QmFH/qezGqLalvAVtNa0mda+5tmcO6ZspqYaOAIRR0mhgRT03aC w3qAeELZoW125os9mhRpNKn+oKaLEZG1I+SOtR7rBzkfT6wFgyG670aW/egfxprdqn1G 8Yj1Ch5hdf18rzXGhRHSZNKy1E4gIF6GrQntS1HoG+kvpL0iPsxK7I023e/cY0/OCBwz 1Zxg== X-Gm-Message-State: APjAAAUTqldkz7p2v0KTd9Quv0+1CqVA61oiIj9sfo7WnsbwgW/tIz1i UPAKTWLYH2xPbTvpyDHyucZIrZAEI7nGm+kIkqBefg== X-Google-Smtp-Source: APXvYqzCfM+93O2XknzGJTJho8TTCVFch2Fi2VT51ezEq/qM/+D3jXep/86gDEDpWV/J/KpZHfLuG30aKq4l89tbmRQ= X-Received: by 2002:a0c:96fd:: with SMTP id b58mr12552818qvd.112.1556658652647; Tue, 30 Apr 2019 14:10:52 -0700 (PDT) MIME-Version: 1.0 References: <155451947938.10151.12663725914439778891@ietfa.amsl.com> <3e994b49f5c2405cb72d1f0345c5e496@XCH-RTP-013.cisco.com> <87c35eec471440358c8ca99feee35ca5@XCH-RTP-013.cisco.com> In-Reply-To: From: Warren Kumari Date: Tue, 30 Apr 2019 17:10:16 -0400 Message-ID: To: "Carlos Pignataro (cpignata)" Cc: "Eric Voit (evoit)" , "ops-dir@ietf.org" , "draft-ietf-netconf-subscribed-notifications.all@ietf.org" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="00000000000007251d0587c5d65e" Archived-At: Subject: Re: [netconf] Opsdir last call review of draft-ietf-netconf-subscribed-notifications-23 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 21:10:58 -0000 --00000000000007251d0587c5d65e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [ - some lists ] Thank you Carlos for the OpsDir review, and to the authors for addressing the comments - I think that this has noticeably improved the document. W On Fri, Apr 12, 2019 at 11:02 AM Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hi, Eric, > > Thanks for the quick response, and for considering these comments! > > A top-post response to acknowledge that your approach on both issues belo= w > seems great to me. Thank you! > > =E2=80=94 > Carlos Pignataro, carlos@cisco.com > > *=E2=80=9CSometimes I use big words that I do not fully understand, to ma= ke myself > sound more photosynthesis."* > > On Apr 11, 2019, at 4:35 PM, Eric Voit (evoit) wrote: > > Hi Carlos, > > *From:* Carlos Pignataro, April 10, 2019 11:11 AM > > > Hi, Eric, > > > On Apr 9, 2019, at 5:03 PM, Eric Voit (evoit) wrote: > > Hi Carlos, > > Thanks for the review. Some thoughts in-line=E2=80=A6 > > > Thanks for the follow-up. > > > From: Carlos Pignataro, April 5, 2019 10:58 PM > > Reviewer: Carlos Pignataro > Review result: Has Nits > > Hi, > > I have reviewed this document as part of the Operational directorate's > ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving the operational aspect= s > of > the IETF drafts. Comments that are not addressed in last call may be > included in > AD reviews during the IESG review. Document editors and WG chairs should > treat these comments just like any other last call comments. > > Summary: Almost Ready > > This is a comprehensive very well written document. > > > From an operational point of view, as per the ops-dir review, I have no > > concerns or comments. Might be nice to collect some of the operational > points > in an Operations Consideration section, particularly given the document > structure of Section 5.x, "ZZZ Considerations". > > > In "implementation considerations" there are a couple which are really > operational considerations. For example the first and third bullets migh= t > qualify as operational. The hard part is that the operational > considerations to expose will vary by the subset of feature which are > selected. So I can imagine that much text could be written on best > operational practices. I am hoping that such documents could follow this > one based on specific deployment contexts. > > > Sorry I was not explicit. While many of these considerations have > operational implications, I meant things like Appendix A of RFC 5706, mor= e > deployment than implementation. > > > Hi Carlos, > Per our call, I refined the section definition to =E2=80=9CImplementation= and > Deployment Considerations=E2=80=9D. I do agree that a number of the ele= ments from > RFC-5706 Appendix A are covered elsewhere across specific sections of the > document. > > > I do have one important question for consideration, which is: what is > *really* > the relationship of this (+ draft-ietf-netconf-netconf-event-notification= s > potentially) with RFC 5277? A Normative reference, this doc has no metada= ta > regarding Updating, Obsoleting, etc. Yet lots of it is indeed a superset > of it. > > > We went around and around in the WG on this for a bit. The initial > decision was that we were going to obsolete RFC-5277. However the problem > was that RFC-5277 Section 4 has a element defined which we > are not replacing yet. This is used in several important > places. Examples include RFC-8040 section 6.4 and RFC-7950 Section 7.16.= 2. > > > Does this describe an Update of specific sections then? Or would want to > bring in the notification and do a full bis? > > The WG talked about this several times. (In fact the adopted draf= t > was originally draft-ietf-netconf-rfc5277bis.) But where we ended up w= as > that we were not ready to assert obsolescence until we had the new > element nailed down. So progressing the current set of > drafts in IESG review gave us a good step in that direction. And when we > have structured this document so that when we do complete > draft-ietf-netconf-notification-messages, things should integrate cleanly= . > The hard question will be how to handle the meta-references properly. I > believe this is best attempted when an full set of documents which is abl= e > to obsolete RFC-5277 is available. > > > So we didn't want to recommend an obsolete without a replacement of that > . The good news is that we are working on a replacement fo= r > this notification. See: draft-ietf-netconf-notification-messages But > this still has a while to go before it is ready. As a result we are left > with Section 1.4 of draft-ietf-netconf-subscribed-notifications which > describes the relationship with RFC-5277. > > > This is still somewhat confusing. Section 1.4 says: > > This document is intended to provide a superset of the subscription > capabilities initially defined within [RFC5277]. > > But if it is really a superset, is it obsoleting it? > > > The subscription capabilities are a superset. I.e., the control > plane can do everything in RFC-5277. However the element > work was deferred. > > S1.4 further goes: > > Especially when > extending an existing [RFC5277] implementation, it is important to > understand what has been reused and what has been replaced. > > Similarly, reuse+replace means obsolete? Or update? :-) > > For the reasons above, not obsolete. Perhaps =E2=80=98update=E2= =80=99 might > apply. But honestly I don=E2=80=99t know the meta-reference convention w= hen two > documents (draft-ietf-netconf-subscribed-notifications & > draft-ietf-netconf-netconf-event-notifications) improve upon the majority > of what is in another document (RFC-5277). For that reason, doing nothin= g > in meta-referencing until a full functional replacement was available > seemed like the best path. > > Thanks, > Eric > > > I recommend the authors+ADs consider whether there is any more formal > relationship with RFC 5277 that would require meta-tagging the RFC. > > > I think that this is fully appropriate as we finish > draft-ietf-netconf-notification-messages > > > I do not think you need to wait for > draft-ietf-netconf-notification-messages (and delay > draft-ietf-netconf-subscribed-notifications) in order to have an > appropriate meta-reference. > Perhaps draft-ietf-netconf-notification-messages will update something > (draft-ietf-netconf-subscribed-notifications?) > > Thanks, > > Carlos. > > > > Thanks! > Eric > > > Thanks, > > Carlos Pignataro. > > > > > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --00000000000007251d0587c5d65e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[ - some lists ]=C2=A0

Thank you Carlos for the OpsDir re= view, and to the authors for addressing the comments - I think that this ha= s noticeably improved the document.

W

On Fri, Apr 12, 2019 at 11:= 02 AM Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hi, Eric,

Thanks for the quick response, and for considering these comments!

A top-post response to acknowledge that your approach on both issues b= elow seems great to me. Thank you!

=E2=80=94
Carlos Pignataro,=C2=A0carlos@cisco.com

=E2=80=9CSometimes I use big words that I do not fully understand, to ma= ke myself sound more photosynthesis."

On Apr 11, 2019, at 4:35 PM, Eric Voit (evoit) <evoit@cisco.com> wrote:

Hi Carlos,
=C2=A0
From:=C2=A0Carlos Pignataro, April 10, 2019 11:11 AM

=C2=A0
Hi, Eric,
=C2=A0
On Apr 9, 2019, at 5:03 PM, Eric Voit (evoit) <evoit@cisco.com> wrote:
=C2=A0
Hi Carlos,<= br>
Thanks for the review.=C2=A0 Some thoughts in-line=E2=80=A6

=C2=A0
Thanks for the follow-up.


From: Carlo= s Pignataro, April 5, 2019 10:58 PM

Reviewer: Carlos Pignataro
Review result: Has Nits

Hi,

I have reviewed this document as part of the Operational directorate's = ongoing
effort to review all IETF documents being processed by the IESG.=C2=A0 Thes= e
comments were written with the intent of improving the operational aspects = of
the IETF drafts. Comments that are not addressed in last call may be includ= ed in
AD reviews during the IESG review.=C2=A0 Document editors and WG chairs sho= uld
treat these comments just like any other last call comments.

Summary: Almost Ready

This is a comprehensive very well written document.


From an ope= rational point of view, as per the ops-dir review, I have no<= /span>
concerns or= comments. Might be nice to collect some of the operational points
in an Operations Consideration section, particularly given the document
structure of Section 5.x, "ZZZ Considerations".

In "implementation considerations" there are a couple which are r= eally operational considerations.=C2=A0 For example the first and third bul= lets might qualify as operational.=C2=A0 The hard part is that the operatio= nal considerations to expose will vary by the subset of feature which are selected.=C2=A0 So I can imagine that much text could= be written on best operational practices.=C2=A0 I am hoping that such docu= ments could follow this one based on specific deployment contexts.
=C2=A0
Sorry I was not explicit. While many of these considerations have operation= al implications, I meant things like Appendix A of RFC 5706, more deploymen= t than implementation.
=C2=A0
<eric> Hi Carlos,
Per our call, I refined the section definition to =E2=80=9CImplementation a= nd Deployment Considerations=E2=80=9D.=C2=A0=C2=A0 I do agree that a number= of the elements from RFC-5706 Appendix A are covered elsewhere across spec= ific sections of the document.


I do have o= ne important question for consideration, which is: what is *really*
the relationship of this (+ draft-ietf-netconf-netconf-event-notifications<= br> potentially) with RFC 5277? A Normative reference, this doc has no metadata=
regarding Updating, Obsoleting, etc. Yet lots of it is indeed a superset of= it.

We went around and around in the WG on this for a bit.=C2=A0 The initial de= cision was that we were going to obsolete RFC-5277. However the problem was= that RFC-5277 Section 4 has a <notification> element defined which w= e are not replacing yet. This <notification> is used in several important places.=C2=A0 Examples include RFC-8040 secti= on 6.4 and RFC-7950 Section 7.16.2.
=C2=A0
Does this describe an Update of specific sections then? Or would want to br= ing in the notification and do a full bis?
=C2=A0
<eric> The WG talked about this several times.=C2=A0 (In fact the ado= pted draft was originally draft-ietf-netconf-rfc5277bis.) =C2=A0=C2=A0=C2= =A0But where we ended up was that we were not ready to assert obsolescence = until we had the new <notification> element nailed down.=C2=A0=C2=A0 = So progressing the current set of drafts in IESG review gave us a good step i= n that direction.=C2=A0 And when we have structured this document so that w= hen we do complete draft-ietf-netconf-notification-messages, things should = integrate cleanly.=C2=A0 The hard question will be how to handle the meta-references properly.=C2=A0 I believe this i= s best attempted when an full set of documents which is able to obsolete RF= C-5277 is available.

So we didn't want to recommend an obsolete without a replacement of tha= t <notification>.=C2=A0 The good news is that we are working on a rep= lacement for this notification.=C2=A0 See: draft-ietf-netconf-notification-= messages =C2=A0=C2=A0=C2=A0=C2=A0But this still has a while to go before it is ready.=C2=A0 As a result we are left with Section 1.4 of draft-ietf-= netconf-subscribed-notifications which describes the relationship with RFC-= 5277.
=C2=A0
This is still somewhat confusing. Section 1.4 says:
=C2=A0
=C2=A0 =C2=A0This document is intended to provide a superset of the subscri= ption
=C2=A0 =C2=A0capabilities initially defined within [RFC5277]. =C2=A0=

But if it is really a superset, is it obsoleting it?=C2=A0
=C2=A0
=C2=A0
<eric> The subscription capabilities are a superset.=C2=A0 I.e., the = control plane can do everything in RFC-5277.=C2=A0 However the <notifica= tion> element work was deferred.
=C2=A0
S1.4 further goes:
=C2=A0
=C2=A0 =C2=A0Especially when
=C2=A0 =C2=A0extending an existing [RFC5277] implementation, it is importan= t to
=C2=A0 =C2=A0understand what has been reused and what has been replaced.=C2= =A0

Similarly, reuse+replace means obsolete? Or update? :-)
=C2=A0
<eric> For the reasons above, not obsolete.=C2=A0 Perhaps =E2=80=98up= date=E2=80=99 might apply.=C2=A0 But honestly I don=E2=80=99t know the meta= -reference convention when two documents (draft-ietf-netconf-subscribed-not= ifications & draft-ietf-netconf-netconf-event-notifications) improve up= on the majority of what is in another document (RFC-5277).=C2=A0 For that rea= son, doing nothing in meta-referencing until a full functional replacement = was available seemed like the best path.
=C2=A0
Thanks,
Eric


I recommend= the authors+ADs consider whether there is any more formal
relationship with RFC 5277 that would require meta-tagging the RFC.<= u>

I think that this is fully appropriate as we finish draft-ietf-netconf-noti= fication-messages
=C2=A0
I do not think you need to wait for draft-ietf-netconf-notification-message= s=C2=A0(and delay draft-ietf-netconf-subscribed-notifications) in order to = have an appropriate meta-reference. Perhaps=C2=A0draft-ietf-netconf-notific= ation-messages will update something (draft-ietf-netconf-subscribed-notific= ations?)
=C2=A0
Thanks,
=C2=A0
Carlos.



Thanks!
Eric


Thanks,

Carlos Pignataro.
=C2=A0



--
I don't think the execution is relevant when= it was obviously a bad idea in the first place.
This is like putting ra= bid weasels in your pants, and later expressing regret at having chosen tho= se particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf<= /div> --00000000000007251d0587c5d65e-- From nobody Tue Apr 30 14:11:22 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FFC1203E3; Tue, 30 Apr 2019 14:11:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-netconf-subscribed-notifications@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155665867115.7536.12392383474714269681.idtracker@ietfa.amsl.com> Date: Tue, 30 Apr 2019 14:11:11 -0700 Archived-At: Subject: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-24: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 21:11:14 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-netconf-subscribed-notifications-24: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for this document; I just have a few minor "housekeeping" points that should get resolved before publication. (Please also note the substantive comments in the COMMENT section as well, particularly those relating to the transport requirements and security considerations.) I'm not sure that we state clearly enough what is required to have a specification for a transport for notifications. Specifically (see COMMENT), in the module we seem to say that the specification must indicate what the default encoding is to be used if not otherwise specified, but that's not enumerated as a requirement on such a specification anywhere I see. I also think that we could probably require (as opposed to "highly recommend" in the current security considerations) that the transport provide message confidentiality and integrity protection. I'm also unsure that I properly understand the use of the "reset" RPC -- if it has no effect when transit connectivity already exists, then what entity is going to call "reset" in the case of publisher timeout when trying to reach a receiver? Surely not the publisher itself, since that would just be publisher-internal functionality with no need for an external-facing RPC. I'm also a little unclear on the mechanics of the list of subscriptions described in Section 3.3. Does it provide a way for a low-privilege client (that can only access one or a handful of the subscriptions) to enumerate all subscriptions that exist, including subscriptions used by high-privilege clients? If so, we may want to think about some security considerations text to that effect; if not, we may want to say that the access-control will limit which leafs are visible to some clients. Finally, we have a few instances of "leaf filter-failure-hint" that's of type "string", providing "Information describing where and/or why a provided filter was unsupportable for a subscription."; I don't understand why it's a string as opposed to some form of machine-readable data. Is it supposed to be human-readable? Does that bring in any internationalization considerations? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1.3 Also note that transport specific transport drafts based on this specification MUST detail the life cycle of dynamic subscriptions, as well as the lifecycle of configured subscriptions (if supported). I'm not sure I understand what additional specification is needed for the lifecycle of configured subscriptions -- doesn't the previous text tightly tie their lifecycle to the presence of configuration in the configuration datastore? nit: please be consistent about "life cycle" vs. "lifecycle" throughout. Section 2.1 An event stream is a named entity on a publisher which exposes a continuously updating set of YANG encoded event records. [...] nit: I don't think "YANG encoded" is well-defined (here and below), in that YANG structures generate data models but can be encoded into various formats (like XML and JSON). Section 2.3 If the publisher supports the "dscp" feature, then a subscription with a "dscp" leaf MUST result in a corresponding [RFC2474] DSCP marking being placed within the IP header of any resulting notification messages and subscription state change notifications. Where TCP is used, a publisher which supports the "dscp" feature SHOULD ensure that a subscription's notification messages are returned within a single TCP transport session where all traffic shares the subscription's "dscp" leaf value. Where this cannot be guaranteed, any "establish subscription" RPC request SHOULD be rejected with a "dscp-unavailable" error I can't decide whether we need to be more explicit in the second and/or third sentences that this remains contingent on the subscription in question having a "dscp" leaf. nit: end sentence with a full stop I share the TSV-ART reviewer's confusion about how the weighting (as well as DSCP) functionality is intended to work. Section 2.4.2.1 Replay provides the ability to establish a subscription which is also capable of passing recently generated event records. In other words, nit/editorial: this language could probably be more clear about "recently generated" meaning "in the past", that is, records for events that have already happened when the subscription is established. Section 2.4.3 any number of times. Dynamic subscriptions can only be modified via this RPC using a transport session connecting to the subscriber. If nit(?): is this more readable as "connecting to" or "connecting from" the subscriber? (The same wording shows up throughout the document, but I'll try to just comment once.) Section 2.4.5 Is there any distinction between "killing a subscription" and "administratively deleting a subscription"? It's unclear to me that we need the extra connotations of the word "kill", here. Section 2.4.6 As a result of this mixture, how subscription errors are encoded nit: "mixture" doesn't seem like the right word to me; "variety" or "varied population" are the first alternatives that come to mind, though they are not perfect either. Is there some sort of "access denied" error that could result from kill-subscription RPCs? (The table/artwork only lists "no-such-subscription".) Section 2.5 It's interesting to see a slight dichotomy between dynamic and configured subscriptions, in that (IIUC) for dynamic subscriptions, a modification event un-suspends a subscription immediately, but for configured subscriptions the publisher seems to have some latitude to retain the subscription in the suspended state for some time before un-suspending it and sending the "subscription-modified" state change message. In this case, a separate dynamic subscription can be established to retransmit the missing event records. Do you want to put in a pointer to replay-start-time here? Section 2.5.1 Event records are only sent to active receivers. Receivers of a configured subscription remain active if both transport connectivity can be verified to the receiver, and event records are not being dropped due to a publisher buffer overflow. [...] nit: "buffer overflow" is a technical term in security circles indicating a potentially exploitable security flaw; would "publisher buffer capacity being reached" be an acceptable substitute (here and below)? Section 2.7.7 This notification indicates that all of the event records prior to the current time have been passed to a receiver. It is sent before any notification message containing an event record with a timestamp later than (1) the "stop-time" or (2) the subscription's start time. nit(?): this text seems to imply that a notification message with a timestamp later than the "stop-time" might actually be sent, which IIUC is not the case. Section 2.9 nit: the name "supports-vrf" for the feature doesn't really parallel the other feature names, that don't include a word like "support" and rather just describe the actual feature. Section 3.1 Is there any risk of collision in event stream names from vendor-specific streams? (We don't seem to create an IANA registry for them, for example.) Section 4 identity subscription-suspended-reason { description "Problem condition communicated to a receiver as part of a 'subscription-terminated' notification."; } identity subscription-terminated-reason { description "Problem condition communicated to a receiver as part of a 'subscription-terminated' notification."; } Are these descriptions supposed to be the same? identity configurable-encoding { description "If a transport identity derives from this identity, it means that it supports configurable encodings. An example of a [...] Is it intended that such future transports (or future encodings?) will derive from both this and the normal base identity (i.e., "transport")? I guess I'm asking why this identity does not derive from the corresponding base, but that's just a style question and not really a protocol matter, making this question a side note. leaf weighting { if-feature "qos"; type uint8 { range "0 .. 255"; } description "Relative weighting for a subscription. Allows an underlying transport layer perform informed load balance allocations between various subscriptions"; reference "RFC-7540, section 5.3.2"; Do we want to chase the reference for readers and say that larger weights get more resources? leaf encoding { when 'not(../transport) or derived-from(../transport, "sn:configurable-encoding")'; type encoding; description "The type of encoding for notification messages. For a dynamic subscription, if not included as part of an establish- subscription RPC, the encoding will be populated with the encoding used by that RPC. For a configured subscription, if not explicitly configured the encoding with be the default encoding for an underlying transport."; Where is the default encoding for an underlying transport specified? Section 5.3 does not seem to say that a transport specification must provide this information, nor does Section 1.3 (which mentions that transport specifications must detail the lifecycle of dynamic subscriptions), nor does Section 2.5.7 (that discusses the need for a separate model augmenting /subscriptions/subscription/receivers/receiver to provide transport details). choice notification-message-origin { if-feature "configured"; description "Identifies the egress interface on the publisher from which notification messages are to be sent."; nit: given the address-originated case, perhaps "the egress interface" is not quite correct anymore. enum connecting { value 3; if-feature "configured"; description "A subscription has been configured, but a 'subscription-started' subscription state change notification needs to be successfully received before notification messages are sent. nit: successful receipt happens on the receiver but sending happens on the publisher, so there's a bit of a mismatch in the sentence subject here. Perhaps we could talk about "successfully sent" state-changes to resolve things. config false; mandatory true; description "Specifies the state of a subscription from the perspective of a particular receiver. With this info it is possible to determine whether a subscriber is currently generating notification messages intended for that receiver."; nit: is it the subscriber that is generating messages or the publisher? Section 5.3 A secure transport is highly recommended and the publisher MUST ensure that the receiver has sufficient authorization to perform the function they are requesting against the specific subset of content involved. "secure transport" usually means that it provides message confidentiality, integrity protection, and source authenticity (akin to the mutual authentication). This is qualitatively different from implementing authorization checks, and it's surprising to see them squashed into the same sentence. Do we want to say anything about discovery for support of new transports, and what workflow would be used to negotiate the use of a new transport? Section 5.4 I can think of a couple other considerations to mention here: - Using DNS names for receiver "name" lookup can cause situations where the name resolves differently on the publisher and subscriber, so the recipient would be different than expected. - Using the publisher's boot time for deduplication protection on replayed messages introduces a dependency on accurate time. We don't have a great secure time story at present, so this is more of a "beware of risk" situation than something we can mitigate, but it does seem that an attacker that could (e.g.) spoof the NTP traffic to the publisher on boot could cause it to send duplicate notifications to recipients that requested historical data. Some other comments on what's already there (which is pretty good; thanks for it!) follow. Container: "/filters" o "stream-subtree-filter": updating a filter could increase the computational complexity of all referencing subscriptions. o "stream-xpath-filter": updating a filter could increase the computational complexity of all referencing subscriptions. Do we want to say anything about modifying either of these causing the set of notifications delivered to recipients to shrink (or become unmanageably large)? I guess it may not be necessary, since the recipient gets a notification about the modification that includes the details of the filter. Container: "/subscriptions" o "excluded-event-records": leaf can provide information about filtered event records. A network operator should have permissions to know about such filtering. To be clear, this is event records filtered either via explicit filter or via access control restrictions. Specifically, it can allow a receiver to learn that there exists access controls that deny it access to some data, in the case when they did not apply any filtering rules explicitly. This potential for information leakage (of the existence of ACLs) should be mentioned explicitly. Appendix A This example transport module does not specify the life cycle of dynamic subscriptions per Section 1.3, and a couple other things required from a transport module specification. Perhaps we are okay claiming that since this is just an example YANG model and not a full transport example, the omission is okay, but it may be worth mentioning the omission for clarity. From nobody Tue Apr 30 14:29:59 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D83A120147; Tue, 30 Apr 2019 14:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yff_8jHUmIMV; Tue, 30 Apr 2019 14:29:48 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F96120154; Tue, 30 Apr 2019 14:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4258; q=dns/txt; s=iport; t=1556659788; x=1557869388; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JUGt4tUlmLAyJhq9s6rmIgyJQOGYlN/47xbEp5LfGek=; b=am9AB/Llxvkqck1rDcYm2thK/XhMmoAghOXXbyh85X33NAeF8o8QfwzI HdR4HStvKLjzZNamnce3UmW4EsWDl+ZWpUglrIj2+j0zF5Dgg5g0lSYZT nIPL2fBqloQO8NACPbqhzasRVpIp0oQynss16a0IbrFYDlCMYf5682Srn g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAACKvchc/5NdJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAIBAQEBCwGBZippgQQoCoQGlTCYZIFnDgEBJYRIAheGGiM?= =?us-ascii?q?3Bg4BAwEBBAEBAgECbRwMhUoBAQEDASMEDUMCBQsCAQgOBwUCCRYHAgICMBU?= =?us-ascii?q?QAgQBDQ2CT0yBew8Pr098M4RGQYUpBoELJwGLSheBQD+EIz6CYQIBAgGBKgE?= =?us-ascii?q?SAYMpglgEiwiCN4w+jQcJAoIJhhWELYdwI4INhjeMa4wOhkOODgIRFYEwNSJ?= =?us-ascii?q?lWBEIcBWDJ4JGiEyFP0ExAZF1gSKBIQEB?= X-IronPort-AV: E=Sophos;i="5.60,414,1549929600"; d="scan'208";a="556754014" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Apr 2019 21:29:45 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x3ULTjwd013541 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Apr 2019 21:29:45 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.1473.3; Tue, 30 Apr 2019 17:29:44 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Tue, 30 Apr 2019 17:29:44 -0400 From: "Eric Voit (evoit)" To: Roman Danyliw , The IESG CC: "draft-ietf-netconf-subscribed-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: Roman Danyliw's Discuss on draft-ietf-netconf-subscribed-notifications-24: (with DISCUSS and COMMENT) Thread-Index: AQHU/43eaU0mVheLMEKEty0C2KlleqZVLZdA Date: Tue, 30 Apr 2019 21:29:44 +0000 Message-ID: <257ba0408739443e8a1af9d3a888fa8b@XCH-RTP-013.cisco.com> References: <155665377891.7475.13101015755522983059.idtracker@ietfa.amsl.com> In-Reply-To: <155665377891.7475.13101015755522983059.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.233] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.152, xch-rtp-012.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [netconf] Roman Danyliw's Discuss on draft-ietf-netconf-subscribed-notifications-24: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 21:29:50 -0000 VGhhbmtzIHZlcnkgbXVjaCBmb3IgdGhlIGNvbW1lbnRzIFJvbWFuLiAgICBTb21lIHRob3VnaHRz IGluLWxpbmUuLi4NCg0KPiBGcm9tOiBSb21hbiBEYW55bGl3IHZpYSBEYXRhdHJhY2tlciAtLSBU dWVzZGF5LCBBcHJpbCAzMCwgMjAxOSAzOjUwIFBNDQo+IA0KPiBSb21hbiBEYW55bGl3IGhhcyBl bnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLW5l dGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zLTI0OiBEaXNjdXNzDQo+IA0KPiBXaGVuIHJl c3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0 byBhbGwgZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMu IChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5DQo+IHBhcmFncmFwaCwgaG93ZXZl ci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cv c3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBh Ym91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBk b2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQg aGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRj b25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucy8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiBESVNDVVNTOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBTZWN0aW9ucyAyLjQuMi4xIGFu ZCAyLjUuNiBzZWVtcyB0byBkZXNjcmliZSBhIG1lY2hhbmlzbSAocmVwbGF5KSB0byBhY2Nlc3MN Cj4gaGlzdG9yaWNhbCBkYXRhIHRoYXQgd2FzIHBvdGVudGlhbGx5IGNvbGxlY3RlZCBwcmlvciB0 byBhIGdpdmVuIHN1YnNjcmliZXIgaGF2aW5nDQo+IGFjY2VzcyB0byBpdC4gIFRoaXMgYXBwZWFy cyB0byBiZSBhbiBleHBsaWNpdGx5IGRlc2lnbmVkIGZlYXR1cmUuICBObyBwdXNoIGJhY2sgb24N Cj4gdGhhdC4gIEhvd2V2ZXIsIEkgYmVsaWV2ZSB0aGF0IGV4cGxpY2l0bHkgc3RhdGluZyB0aGlz IGFycmFuZ2VtZW50IGlzIHdhcnJhbnRlZC4NCj4gUGVyaGFwcyBzb21ldGhpbmcgb24gdGhlIG9y ZGVyIG9mIHRoZSBmb2xsb3dpbmcgY291bGQgYmUgYWRkZWQgdG8gdGhlIFNlY3VyaXR5DQo+IENv bnNpZGVyYXRpb25zIC0tIOKAnFRoZSByZXBsYXkgbWVjaGFuaXNtcyBkZXNjcmliZWQgaW4gU2Vj dGlvbnMNCj4gMi40LjIuMSBhbmQgMi41LjYgcHJvdmlkZXMgYWNjZXNzIHRvIGhpc3RvcmljYWwg ZXZlbnQgcmVjb3Jkcy4gIEJ5IGRlc2lnbiwgdGhlDQo+IGFjY2VzcyBjb250cm9sIG1vZGVsIHRo YXQgcHJvdGVjdHMgdGhlc2UgcmVjb3JkcyBjb3VsZCBlbmFibGUgc3Vic2NyaWJlcnMgdG8NCj4g dmlldyBkYXRhIHRvIHdoaWNoIHRoZXkgd2VyZSBub3QgYXV0aG9yaXplZCBhdCB0aGUgdGltZSBv ZiBjb2xsZWN0aW9uLuKAnQ0KDQpJIGhhdmUgbm8gcHJvYmxlbXMgYXQgYWxsIHdpdGggdGhpcyBl eGFjdCBzdGF0ZW1lbnQgYmVpbmcgcGxhY2VkIGludG8gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zIHNlY3Rpb24uICAgU28gSSBqdXN0IGFkZGVkIGl0IHZlcmJhdGltLiAgIChJIGRvbid0IGV4 cGVjdCB0aGlzIHRvIGJlIGNvbnRyb3ZlcnNpYWwgYXMgdGhpcyBpcyB0aGUgc2FtZSBiZWhhdmlv ciB3aGljaCBpcyBhdmFpbGFibGUgZnJvbSBSRkMtNTI3NyBpbXBsZW1lbnRhdGlvbnMuKQ0KDQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gKDEpIFNl Y3Rpb24gMi41LjEuICBQZXIgRmlndXJlIDgsIGlmIGEgbW9kaWZ5IG9wZXJhdGlvbiBmYWlscyBy ZS1ldmFsdWF0aW9uICh0aGUg4oCcbm8NCj4gKDIp4oCdIGJyYW5jaCkgd291bGRu4oCZdCBpdCBn byBkaXJlY3RseSB0byDigJxpbnZhbGlk4oCdIChpbnN0ZWFkIG9mIHRocm91Z2gNCj4g4oCcdW5z dXBwb3J0YWJsZS0+aW52YWxpZOKAnSk/DQoNCkVmZmVjdGl2ZWx5IGl0IGRvZXMgZ28gcmlnaHQg dG8gaW52YWxpZCwgYXMgJ3Vuc3VwcG9ydGFibGUnIGlzbid0IGEgc3RhdGUuICBUaGUgbWVyZ2Ug d2FzIGEgc29tZXRoaW5nIGluIHRoZSBkaWFncmFtIHdoaWNoIHdhcyBpbnRlbmRlZCB0byBzYXZl IHNvbWUgc3BhY2UuICBCYXNpY2FsbHkgYm90aCAoMikgYW5kICgzKSBnbyB0aHJvdWdoICJ1bnN1 cHBvcnRhYmxlIiB0byBleHBsaWNpdGx5IHNob3cgdGhhdCBhICJzdWJzY3JpcHRpb24gdGVybWlu YXRlZCIgbWVzc2FnZSBuZWVkcyB0byBiZSBzZW50IHRvIGFueSBjdXJyZW50bHkgYWN0aXZlIGJ1 dCBzb29uIGRpc2Nvbm5lY3RlZCByZWNlaXZlcnMuICANCg0KPiAoMikgU2VjdGlvbiAyLjUuMiwg d2hhdCBhcmUg4oCcdHJhbnNwb3J0IHNwZWNpZmljIGNhbGwtaG9tZSBvcGVyYXRpb25z4oCdPw0K DQpBIHRyYW5zcG9ydCBzcGVjaWZpYyBkb2N1bWVudCBuZWVkcyB0byBkZWZpbmUgaG93IHRvIGVz dGFibGlzaCBhIHRyYW5zcG9ydCBjb25uZWN0aW9uIGZyb20gYSBjb25maWd1cmVkIHB1Ymxpc2hl ciB0byBhbiBpbnRlbmRlZCByZWNlaXZlci4gICAgQW4gZXhhbXBsZSBvZiB0aGUgb3BlcmF0aW9u cyB3b3VsZCBiZSBpbiBzZWN0aW9ucyAzICYgNCBvZiAgUkZDIDgwNzEgKE5FVENPTkYgQ2FsbCBI b21lIGFuZCBSRVNUQ09ORiBDYWxsIEhvbWUuKQ0KDQo+ICgzKSBTZWN0aW9uIDIuNS42LiAgVHlw b3MNCj4gDQo+IHMvdGltZWdhcC90aW1lIGdhcC8NCj4gcy9zdWNjZXNzZnVsbHkvc3VjY2Vzc2Z1 bGx5Lw0KDQpGaXhlZC4NCg0KVGhhbmtzIQ0KRXJpYw0K From nobody Tue Apr 30 16:29:16 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D52112012E; Tue, 30 Apr 2019 16:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGLETlaoULp2; Tue, 30 Apr 2019 16:29:11 -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 7B17A1200A3; Tue, 30 Apr 2019 16:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7498; q=dns/txt; s=iport; t=1556666951; x=1557876551; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dsrkGobkwnYY0tNrqN2l3xlrc+QEYlCvCmRqt2sONws=; b=LpiN3DG6V0c18c/2dG2spgIdnfnhgI2wk6jFehlFCGjIT+ohCMdHpjCf wisg4THgjn4Om1UE+EaV8rdCmUFuPRVjXcSSYWcAZ/gOLr+uV197ADfSk zVxcB+tPJelJsZK5bTXN5L8WZg4JUmRae7joEnZUOkRTIq6hNYx8tQC/f 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAAAp2chc/4ENJK1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwMBAQEBCwGBZippgQQoCoQGlTCOMIogFIFnDgEBJYRIAhe?= =?us-ascii?q?GGyM2Bw4BAwEBBAEBAgECbRwMhUoBAQEDASMRQwIFCwIBCBIDBQIJHQICAjA?= =?us-ascii?q?VAgMLAgQBDQ2CT0yBew8PrxGBL4QyARNBhSwGgQsnAYtKF4FAP4ERgxI+gmE?= =?us-ascii?q?CAQIBgSoBAREBD4MaglgEinYOBII3jD6MImUJAoIJhhWELYdwI4INhjeMa4M?= =?us-ascii?q?JiQWFI4Egjg4CERWBMCYOI2VYEQhwFYJzATOBGIEDFxSITIU/QTEBkWcBDRc?= =?us-ascii?q?HgQSBIQEB?= X-IronPort-AV: E=Sophos;i="5.60,415,1549929600"; d="scan'208";a="267161295" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Apr 2019 23:29:10 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x3UNTA0Z009685 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Apr 2019 23:29:10 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.1473.3; Tue, 30 Apr 2019 19:29:09 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Tue, 30 Apr 2019 19:29:09 -0400 From: "Eric Voit (evoit)" To: "Eric Vyncke (evyncke)" , The IESG CC: "draft-ietf-netconf-subscribed-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtbmV0?= =?utf-8?B?Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMtMjQ6ICh3aXRoIENPTU1F?= =?utf-8?Q?NT)?= Thread-Index: AQHU/4b2whg08n3Vakm6if6ntmzZoaZVT0zA Date: Tue, 30 Apr 2019 23:29:09 +0000 Message-ID: References: <155665081164.7668.3304106941009307050.idtracker@ietfa.amsl.com> In-Reply-To: <155665081164.7668.3304106941009307050.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.233] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.152, xch-rtp-012.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [netconf] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-netconf-subscribed-notifications-24=3A_=28with_COMMENT=29?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 23:29:15 -0000 SGkgw4lyaWMsIA0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cy4gIFRob3VnaHRzIGluLWxpbmUu Li4NCg0KPiBGcm9tOiDDiXJpYyBWeW5ja2UsIEFwcmlsIDMwLCAyMDE5IDM6MDAgUE0NCj4gDQo+ IMOJcmljIFZ5bmNrZSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBm b3INCj4gZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucy0yNDogTm8g T2JqZWN0aW9uDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0 IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1ZGVk IGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0 b3J5DQo+IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0 dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0K PiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9z aXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3Qg cG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucy8NCj4g DQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ IA0KPiBJIGFwcHJlY2lhdGUgdGhlIGdvYWwgb2YgdGhpcyBkb2N1bWVudCB0byBzcGVjaWZ5IGFu b3RoZXIgdGVsZW1ldHJ5IHN0cmVhbWluZw0KPiB0aGFuIGdSUEMuDQoNCkFjdHVhbGx5IHRoaXMg d29yayBwcmUtZGF0ZXMgZ1JQQyBiYXNlZCBUZWxlbWV0cnkuICBCdXQgaXQgdG9vayB0aGUgZG9j dW1lbnRzIHRpbWUgdG8gZ2V0IHRvIHRoZSBJRVNHLiA6LSkNCg0KPiBBcyB0aGUgSS1EIGhhcyBi ZWVuIHJldmlld2VkIGJ5IFlBTkctZG9jdG9ycywgSSBkaWQgbm90IGxvb2sgaW4gdGhlDQo+IFlB TkcgbW9kdWxlLg0KPiANCj4gQ29tbWVudHMNCj4gLS0tLS0tLS0NCj4gDQo+IEMxKSBzZWN0aW9u IDEuMywgc2hvdWxkIHRoZSBwdWJsaXNoZWQgY2hlY2sgYXV0aG9yaXphdGlvbiBiZWZvcmUgYWNj ZXB0aW5nIGFuDQo+IHN1YnNjcmlwdGlvbj8gVGhlcmUgaXMgc29tZSB0ZXh0IGluIHNlY3Rpb24g My4xIGlzIGFib3V0IGF1dGhvcml6YXRpb24gYnV0IEkgd291bGQNCj4gcHJlZmVyIHRvIGhhdmUg dGhpcyBhdXRob3JpemF0aW9uIHN0YXRlZCBhcyBlYXJseSBhcyBwb3NzaWJsZQ0KDQpBcyB5b3Ug Zm91bmQgbGF0ZXIgaW4gdGhlIGRvY3VtZW50LCB0aGUgcHVibGlzaGVyIGRvZXMgYXV0aG9yaXph dGlvbi4gIEluIG9sZGVyIHZlcnNpb25zIG9mIHRoaXMgZG9jdW1lbnQgd2UgZGlkIGhhdmUgc29t ZSBvZiB0aGUgYXV0aG9yaXphdGlvbiBpdGVtcyB1cCBmcm9udCBpbiB0aGUgaW50cm8uICBCdXQg Zm91bmQgaXQgc2xvd2VkIGRvd24gdGhlIGludHJvIG9mIHdoYXQgd2FzIGFscmVhZHkgYSBsb25n IGRvY3VtZW50LiAgU28gd2Uga2VwdCB0aGUgaW50cm8gYXMgc2hvcnRlciBieSBwdXNoaW5nIHRo YXQgbGF0ZXIgaW4gdGhlIGRvYy4NCiANCj4gQzIpIGVuZCBvZiBzZWN0aW9uIDEuMywgInRyYW5z cG9ydCBkcmFmdHMiIHNob3VsZG4ndCByYXRoZXIgYmUgInRyYW5zcG9ydA0KPiBzcGVjaWZpY2F0 aW9ucyIgPw0KDQpXb3JrcyBmb3IgbWUuICBDaGFuZ2UgbWFkZS4NCiANCj4gQzMpIGVuZCBvZiBz ZWN0aW9uIDEuMywgdXBvbiB0ZXJtaW5hdGlvbiBkZWNpZGVkIGJ5IHRoZSBwdWJsaXNoZXIsIGlz IHRoZXJlIGENCj4gbmVlZCBmb3IgYW55IGV4cGxhbmF0aW9uIG1lc3NhZ2Ugc2VudCB0byB0aGUg c3Vic2NyaWJlcj8NCg0KWWVzLCB0aGUgZGV0YWlscyBvbiB0aGlzIGFyZSBsYWlkIG91dCBhcyBw YXJ0IG9mIHRoZSBzdGF0ZSBtYWNoaW5lcyBpbiBTZWN0aW9uIDIuNC4xIGFuZCAyLjUuMS4NCg0K PiBDNCkgaXMgdGhlcmUgYW55IHJlYXNvbiB3aHkgdGhlIFlBTkcgbW9kdWxlIHZhbGlkYXRpb24g YnV0IHRoZSBkYXRhdHJhY2tlcg0KPiBmYWlscz8gT3V0ZGF0ZWQvaW52YWxpZCBQWUFORyA/DQoN CkV4YWN0bHksIHRoZSBZQU5HIHZhbGlkYXRvciBlcnJvcnMgYXJlIGR1ZSB0byBhIHNvbHZlZCBi dWcgaW4geWFuZ2xpbnQuICAgIEFzIEtlbnQgZGlzY3Vzc2VzIGluIGhpcyBzaGVwaGVyZCB3cml0 ZXVwLCB0aGUgZXJyb3JzIGNsZWFyIHdpdGggbmV3IHZlcnNpb25zIG9mIHlhbmdsaW50Lg0KICAg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1zdWJz Y3JpYmVkLW5vdGlmaWNhdGlvbnMvc2hlcGhlcmR3cml0ZXVwLyANCiAgICANCiAgICAgICBbU0hF UEhFUkRdIGBweWFuZ2AgYW5kIGB5YW5nbGludGAgd2VyZSB1c2VkIHRvIHZhbGlkYXRlIHRoZSBZ QU5HIG1vZHVsZSANCiAgICAgICBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuICBOb3RlIHRoYXQg RGF0YXRyYWNrZXIgc2hvd3MgWUFORyB2YWxpZGF0aW9uIA0KICAgICAgIGVycm9ycywgYnV0IHRo ZSBtb2R1bGUgdmFsaWRhdGVzIGZpbmUgb24gbXkgbWFjaGluZSAoSSdtIHVzaW5nIHlhbmdsaW50 DQogICAgICAgMC4xNi4xMTAsIHdoZXJlYXMgRGF0YVRyYWNrZXIgaXMgdXNpbmcgeWFuZ2xpbnQg MC4xNC44MCkuDQogICAgDQpGWUkgdGhlIGJ1ZyB3YXMgZml4ZWQgaW4geWFuZ2xpbnQgMC4xNi41 OQ0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy90b29scy9pZXRmZGIvdGlja2V0LzI2NjcNCg0KPiBD NSkgc2VjdGlvbiAyLjIgImFsbCBldmVudCByZWNvcmRzIG9uIGFuIGV2ZW50IHN0cmVhbSBhcmUg dG8gYmUgc2VudCIsIHNob3VsZA0KPiB0aGVyZSBiZSBhIG1lbnRpb24gb2YgcHVibGlzaGVyIGJl aW5nIG91dCBvZiByZXNzb3VyY2UgPw0KDQpZZXMsIHRoZXJlIGFyZSBzZXZlcmFsICJvdXQgb2Yg cmVzb3VyY2UiIGVycm9ycyBkaXNjdXNzZWQgYWNyb3NzIFNlY3Rpb24gMi40LCAyLjUsIGFuZCBp biB0aGUgWUFORyBtb2RlbC4gIFlvdSBkbyBub3RlIHNvbWUgb2YgdGhvc2UgYmVsb3cuICBBZ2Fp biBieSBkZWxheWluZyBzb21lIG9mIHRoZSBkaXNjdXNzaW9ucyB0byBsYXRlciBpbiB0aGUgZG9j dW1lbnQgdGhlIGRpc2N1c3Npb25zIGFyZSBsZXNzIGZyYWdtZW50ZWQgaW4gcGxhY2VzLg0KDQo+ IEM2KSBzZWN0aW9uIDIuNC4xICJpbnN1ZmZpY2llbnQgQ1BVIG9yIGJhbmR3aWR0aCBhdmFpbGFi bGUiIGJ1dCB0aGVyZSBtYXkgYmUNCj4gb3RoZXIgcmVhc29ucyAoZS5nLiBtZW1vcnkpLCB3aGF0 IGFib3V0IHVzaW5nICJpbnN1ZmZpY2llbnQgQ1BVLCBiYW5kd2lkdGgNCj4gdW5hdmFpbGFibGUg b3Igb3RoZXIgbGFjayBvZiByZXNzb3VyY2UiDQoNCldlIGhhdmUgYmVlbiBhc3N1bWluZyB0aGF0 IHRvIGxpdHRsZSBtZW1vcnkgaXMgYSBmdW5jdGlvbiBvZiBzdHJlYW0ncyBldmVudCBidWZmZXJz IGJlaW5nIGV4Y2VlZGVkLCBhbmQgdGhhdCBpcyBhIGZ1bmN0aW9uIG9mIENQVSBiZWluZyBpbnN1 ZmZpY2llbnQgdG8gaGFuZGxlIHRoZSBsb2FkIGZyb20gdGhlIHN0cmVhbS4gIFNvIG9uZSBlcnJv ciBzZWVtcyB0byBjb3ZlciB0aGUgY2FzZSB3aXRob3V0IHB1Ymxpc2hlciBkZXZlbG9wZXJzIGhh dmluZyB0byBtYWtlIGEganVkZ2VtZW50IGNhbGwgb24gd2hpY2ggb2YgdGhlc2Ugd2FzIHJlc3Bv bnNpYmxlIGZvciB0aGUgbGFjayBvZiByZXNvdXJjZXMuICANCiANCj4gQzcpIGZvciBteSBjdXJp b3NpdHksIGluIHNlY3Rpb24gMi40LjIuMSwgaG93IGRlZXAgY291bGQgcmVhbGlzdGljYWxseSBi ZSBhIHJlcGxheQ0KPiBidWZmZXI/IE1pbnV0ZXM/DQoNCkl0IGNvdWxkIGJlIGhvdXJzIGFuZCBk YXlzIGZvciBsb3cgdm9sdW1lIGV2ZW50cy4gICBGb3IgZXhhbXBsZSwgZm9yIHNlY3VyaXR5IGNh c2VzIHN1Y2ggYXMgdGhlIEludGVncml0eSBNYW5hZ2VtZW50IEFyY2hpdGVjdHVyZSAoSU1BKSwg eW91IG1pZ2h0IG5lZWQgIHRvIGtub3cgZXZlcnkgSU1BIHJlbGF0ZWQgZXZlbnQgc2luY2UgYm9v dC4NCiANCj4gQzgpIHRoZSB0ZXJtICd0cmFuc3BvcnQnIGlzIHVzZWQgcXVpdGUgb2Z0ZW4gaW4g dGhlIGRvY3VtZW50IGJ1dCBpdCBzZWVtcyB0byByZWZlcg0KPiB0byBORVRDT05GIGFuZCBub3Qg c28gbXVjaCB0byBteSB1bmRlcnN0YW5kaW5nIG9mICd0cmFuc3BvcnQnIGluIGFuIElFVEYNCj4g ZG9jdW1lbnQgKHdoaWNoIGlzIFRDUCwgVURQLCBTQ1RQLCAuLi4pLiBJcyBpdCBvYnZpb3VzIHRv IHRoZSByZWFkZXJzPyBJZiBzbywgdGhlbiBJDQo+IGRvIG5vdCBtaW5kLiBFbHNlLCBpdCBtYXkg YmUgdXNlZnVsIHRvIGNsYXJpZnkgaW4gc2VjdGlvbiAxLjINCg0KSG9wZWZ1bGx5IGl0IGlzIG9i dmlvdXMgdG8gdGhlIHJlYWRlcnMuICAgV2Ugd2VudCBiYWNrLWFuZC1mb3J0aCBhIGZldyB5ZWFy cyBhZ28gb24gdGhlIHByb3BlciB0ZXJtaW5vbG9neSBoZXJlLiAgIEkgZmVhciB0b3VjaGluZyB0 aGUgd29yZCBhcyB0b3VjaGluZyB0ZXJtaW5vbG9neSBtaWdodCBpbmR1Y2UgdW5mb3Jlc2VlYWJs ZSBzaWRlLWVmZmVjdHMuDQoNCj4gTml0cw0KPiAtLS0tDQo+IA0KPiBOMSkgaXMgdGhlcmUgYW55 IHJlYXNvbiB3aHkgbm90IGFsbCBDaXNjbyBhdXRob3JzIGFyZSBub3QgZ3JvdXBlZCB0b2dldGhl cj8NCj4gKGV2ZW4gaWYgYW5vdGhlciBvbmUgaGFzIGNoYW5nZWQgYWZmaWxpYXRpb24pDQoNCk5v IHJlYWwgcmVhc29uLiAgQmFzaWNhbGx5IHdlIGhhZCBhbiBpbml0aWFsIG9yZGVyLiAgQW5kIHRo ZW4gc29tZSBhdXRob3JzIG1vdmVkIGNvbXBhbmllcywgYnV0IHdlIGtlcHQgdGhlIG9yZGVyLiAg SWYgdGhpcyBpcyBhbiBpc3N1ZSBmb3IgdGhlIElFU0csIHdlIGNhbiByZXNlcXVlbmNlLg0KDQo+ IE4yKSBhYnN0cmFjdCBzL2luZm9ybWF0aW9uL2RhdGEvIGFsc28gYXBwbGljYWJsZSBpbiBvdGhl ciBzZWN0aW9ucyBJTUhPDQoNCkVpdGhlciB3b3JrcyBmb3IgbWUgaG9uZXN0bHkuICAgQnV0IHNv IG1hbnkgcGVvcGxlIGhhZCBhbiBvcGluaW9uIG92ZXIgdGhlIHllYXJzIG9uIHRoaXMsIGFuZCB3 ZSBoYXZlIHR3ZWFrZWQgdGhpcyBzbyBtYW55IHRpbWVzLCB0aGF0IEkgYW0gYWZyYWlkIG9mIG1h a2luZyBhIGNoYW5nZSBoZXJlLg0KIA0KPiBOMykgc2VjdGlvbiAxLjMsIGV4cGFuZCBSUEMgZXZl biBpZiBvYnZpb3VzDQoNCkRvbmUNCg0KPiBONCkgc2VjdGlvbiAyLjMsIGV4cGFuZCBRb1MgZXZl biBpZiBvYnZpb3VzDQoNCkRvbmUuDQoNClRoYW5rcyBhZ2FpbiBmb3IgdGhlIHJldmlldyENCg0K RXJpYw0K From nobody Tue Apr 30 17:13:20 2019 Return-Path: <0100016a70bcffc5-d7f2dbef-b296-4df0-9e9d-56b4a3c0fb65-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042791203F6 for ; Tue, 30 Apr 2019 17:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_vmoqdc5-Aj for ; Tue, 30 Apr 2019 17:13:17 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AF691200DE for ; Tue, 30 Apr 2019 17:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556669595; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=Lw1QFSURH6UWA2qgp40WHO7VaGu+Av38YFYKkUS1yRw=; b=mKsuZLEGLllH9ex+ykbtvrX9u+AzN4Mjtn0qFJpbow1nE+s+/G0BYDmM2seHsu/b UWjygbFn4klPLxTsY8sukJIwqnNeCSYEhA9pMtNnqz7gSCPCD3WdATl0P+44zz1xfyb 8SA0gYoF3uvC9CeToHePHeL8cLiT/0w7wZuI7yKw= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_866A6D24-7C38-4324-AE70-951332853410" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-ID: <0100016a70bcffc5-d7f2dbef-b296-4df0-9e9d-56b4a3c0fb65-000000@email.amazonses.com> Date: Wed, 1 May 2019 00:13:15 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.05.01-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] draft 104 minutes posted X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 00:13:19 -0000 --Apple-Mail=_866A6D24-7C38-4324-AE70-951332853410 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The draft minutes (actually an audio transcription) from the 104 meeting = have been posted here: = https://datatracker.ietf.org/meeting/104/materials/minutes-104-netconf-00.= txt = The chair actions coming out of the meeting include: 1) Re-issue adoption call for the tcp-client-server draft - The chairs feel that this is important because the original = adoption poll was on the -00 version, which received several comments that = have been addressed in the currently posted -02 version. - The chairs feel that the HTTP draft is not yet ready for = adoption; that another adoption poll will be required after all issues have been = addressed. 2) Issue an adoption call on the Subscription to Multiple Stream = Originators draft - Recall that we intend to more forward with this draft and let the = adopted=20 UPD Pub Sub draft expire. Kent and Mahesh --Apple-Mail=_866A6D24-7C38-4324-AE70-951332853410 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

The draft minutes = (actually an audio transcription) from the 104 meeting have been posted = here:
    https://datatracker.ietf.org/meeting/104/materials/minutes-104-= netconf-00.txt


The chair actions coming = out of the meeting include:

1)  Re-issue adoption call for the tcp-client-server = draft

  =     - The chairs feel that this is important because the = original adoption poll
        =  was on the -00 version, which received several comments that = have
         been = addressed in the currently posted -02 version.

     - The chairs feel = that the HTTP draft is not yet ready for adoption; that = another
       adoption poll = will be required after all issues have been addressed.

2) Issue an adoption = call on the Subscription to Multiple Stream Originators = draft

  =    - Recall that we intend to more forward with this draft and = let the adopted 
      =  UPD Pub Sub draft expire.


Kent= and Mahesh


= --Apple-Mail=_866A6D24-7C38-4324-AE70-951332853410-- From nobody Tue Apr 30 21:56:41 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126491200B1; Tue, 30 Apr 2019 21:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68CKAIdX2E5j; Tue, 30 Apr 2019 21:56:31 -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 3C2F412001E; Tue, 30 Apr 2019 21:56:31 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8B99BB8124B; Tue, 30 Apr 2019 21:56:19 -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 Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, netconf@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190501045619.8B99BB8124B@rfc-editor.org> Date: Tue, 30 Apr 2019 21:56:19 -0700 (PDT) Archived-At: Subject: [netconf] =?utf-8?q?RFC_8572_on_Secure_Zero_Touch_Provisioning_?= =?utf-8?b?KFNaVFAp?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 04:56:33 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8572 Title: Secure Zero Touch Provisioning (SZTP) Author: K. Watsen, I. Farrer, M. Abrahamsson Status: Standards Track Stream: IETF Date: April 2019 Mailbox: kent+ietf@watsen.net, ian.farrer@telekom.de, mikael.abrahamsson@t-systems.se Pages: 87 Characters: 196186 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netconf-zerotouch-29.txt URL: https://www.rfc-editor.org/info/rfc8572 DOI: 10.17487/RFC8572 This document presents a technique to securely provision a networking device when it is booting in a factory-default state. Variations in the solution enable it to be used on both public and private networks. The provisioning steps are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs. The updated device is subsequently able to establish secure connections with other systems. For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems. 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 Tue Apr 30 22:49:00 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908911200C5; Tue, 30 Apr 2019 22:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 Ll2oxh_V60zU; Tue, 30 Apr 2019 22:48:49 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDCB61200E0; Tue, 30 Apr 2019 22:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37276; q=dns/txt; s=iport; t=1556689728; x=1557899328; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Pe0Ft8os5HqvAgMWSUlvQuPtTPCw/5tsZi4Pzr90gsg=; b=FplRgt/azfnUk7ufRaMj34zAk2p2j1V+5x4xrezNg5AJxz6tlLLeWCHd wzpZvTKFgtj7ZaNaABFQDp91Sh8PxNu5CuqGaQmUsg2MlqTTuqmkENXln Be1iUp8tYc2WeYvXDTRgSZocoMzZvYraJsRf/4ZGop9nioZSNCDuUX3Ba o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BdAADkMclc/5tdJa1dAgcODAEBAQE?= =?us-ascii?q?BAgEBAQEHAgEBAQGBZYFnKmmBBCgKg0ZAlS9+l2aBZw4BASWESAIXhhsjOBM?= =?us-ascii?q?BAwEBBAEBAgECbRwMhUoBAQEDAQwCDAkRMQcGBQIFCwIBBgIVBQIJFgcCAgI?= =?us-ascii?q?wFRACBAENDRGCPkyBew8PkX6bZYEvhEZBhSoGgQsniiGBKxeBQD+BEYIUSTU?= =?us-ascii?q?+gmEBAQEBAQGBKgEIBAYBBwEEgx2CWASKdQMSJguCBoRpgW6FbIwjZQkCggm?= =?us-ascii?q?CU4NEjB8jgg2GN4xvjBGGRY4TAhEVgTA2IWVYEQhwFTuCOAEzghsXFG0BAga?= =?us-ascii?q?HVoUEO0ExAZEmAQ4XA4EIgSEBAQ?= X-IronPort-AV: E=Sophos;i="5.60,416,1549929600"; d="scan'208";a="552505885" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 May 2019 05:48:46 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x415mk6g012715 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 May 2019 05:48:46 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 1 May 2019 01:48:45 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Wed, 1 May 2019 01:48:45 -0400 From: "Eric Voit (evoit)" To: Benjamin Kaduk , The IESG CC: "draft-ietf-netconf-subscribed-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-24: (with DISCUSS and COMMENT) Thread-Index: AQHU/5lDbPOEHPnGa0+OxIdeqCy7a6ZVXYMA Date: Wed, 1 May 2019 05:48:45 +0000 Message-ID: References: <155665867115.7536.12392383474714269681.idtracker@ietfa.amsl.com> In-Reply-To: <155665867115.7536.12392383474714269681.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.232] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.153, xch-rtp-013.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-24: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 05:48:53 -0000 SGkgQmVuamFtaW4sDQoNCj4gRnJvbTogQmVuamFtaW4gS2FkdWssIEFwcmlsIDMwLCAyMDE5IDU6 MTEgUE0NCj4gDQo+IEJlbmphbWluIEthZHVrIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFs bG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmlj YXRpb25zLTI0OiBEaXNjdXNzDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRo ZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwNCj4gYWRkcmVzc2Vz IGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMg aW50cm9kdWN0b3J5DQo+IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJl ZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVy aWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENP TU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhl ciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0 aW9ucy8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBESVNDVVNTOg0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IA0KPiBUaGFua3MgZm9yIHRoaXMgZG9jdW1lbnQ7IEkganVzdCBoYXZlIGEgZmV3 IG1pbm9yICJob3VzZWtlZXBpbmciIHBvaW50cyB0aGF0DQo+IHNob3VsZCBnZXQgcmVzb2x2ZWQg YmVmb3JlIHB1YmxpY2F0aW9uLiAgKFBsZWFzZSBhbHNvIG5vdGUgdGhlIHN1YnN0YW50aXZlDQo+ IGNvbW1lbnRzIGluIHRoZSBDT01NRU5UIHNlY3Rpb24gYXMgd2VsbCwgcGFydGljdWxhcmx5IHRo b3NlIHJlbGF0aW5nIHRvIHRoZQ0KPiB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzIGFuZCBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucy4pDQo+IA0KPiBJJ20gbm90IHN1cmUgdGhhdCB3ZSBzdGF0ZSBjbGVh cmx5IGVub3VnaCB3aGF0IGlzIHJlcXVpcmVkIHRvIGhhdmUgYQ0KPiBzcGVjaWZpY2F0aW9uIGZv ciBhIHRyYW5zcG9ydCBmb3Igbm90aWZpY2F0aW9ucy4gIFNwZWNpZmljYWxseSAoc2VlIENPTU1F TlQpLCBpbg0KPiB0aGUgbW9kdWxlIHdlIHNlZW0gdG8gc2F5IHRoYXQgdGhlIHNwZWNpZmljYXRp b24gbXVzdCBpbmRpY2F0ZSB3aGF0IHRoZSBkZWZhdWx0DQo+IGVuY29kaW5nIGlzIHRvIGJlIHVz ZWQgaWYgbm90IG90aGVyd2lzZSBzcGVjaWZpZWQsIGJ1dCB0aGF0J3Mgbm90IGVudW1lcmF0ZWQg YXMgYQ0KPiByZXF1aXJlbWVudCBvbiBzdWNoIGEgc3BlY2lmaWNhdGlvbiBhbnl3aGVyZSBJIHNl ZS4gDQoNCkkgcHJvdmlkZSBtb3JlIGluZm8gaW4tbGluZSBiZWxvdyB3aXRoIHlvdXIgY29tbWVu dC4gIEJ1dCBoZXJlIGlzIGEgc3VtbWFyeS4uLg0KDQpGb3IgZHluYW1pYyBzdWJzY3JpcHRpb25z LCB0aGUgZGVmYXVsdCBlbmNvZGluZyBpcyBub3JtYWxseSBzcGVjaWZpZWQgYnkgd2hhdGV2ZXIg aXMgdXNlZCB3aXRoaW4gdGhlIGVzdGFibGlzaC1zdWJzY3JpcHRpb24gUlBDLiAgU28gdGhlcmUg aXMgbm90IGEgbmVlZCBmb3IgYSBkZWZhdWx0IGhlcmUgYXMgdGhlIHN1YnNjcmliZXIgaGFzIGFs cmVhZHkgZW5jb2RlZCBpbiB0aGUgUlBDIHdoYXQgaXQgd2FudHMuICANCg0KRm9yIGNvbmZpZ3Vy ZWQgc3Vic2NyaXB0aW9ucywgdGhlIGRlZmF1bHQgKGFuZCBvbmx5KSBlbmNvZGluZyBpcyBvZnRl biBkcml2ZW4gYnkgdGhlIHRyYW5zcG9ydCBzZWxlY3Rpb24uICBBbmQgdGhpcyBpcyBkZWZpbmVk IGJ5IGV4aXN0aW5nIHRyYW5zcG9ydCBSRkNzIHdoaWNoIHRoZW1zZWx2ZXMgZGVmaW5lIHN1cHBv cnRlZCBlbmNvZGluZ3MgKGUuZy4sICJORVRDT05GICsgWE1MIiAsICJSRVNUQ09ORiArIEpTT04i KS4gIA0KDQpCdXQgZW5jb2RpbmdzIGNhbiB2YXJ5IChlLmcuLCB0aGUgdXNlIG9mIENCT1Igd2l0 aGluIGRyYWZ0LWJpcmtob2x6LXlhbmctcHVzaC1jb2FwLXByb2JsZW1zdGF0ZW1lbnQpLiAgU3Vw cG9ydGluZyB0aGlzIG5lZWQgaXMgdGhlIHB1cnBvc2Ugb2YgdGhlIGlkZW50aXR5ICJjb25maWd1 cmFibGUtZW5jb2RpbmciIGluIHRoZSBZQU5HIG1vZGVsLiAgIEFuZCB0aGlzIGlkZW50aXR5IGRv ZXMgc2F5IHRoYXQgIkZ1cnRoZXIgZGV0YWlscyBmb3IgYW55IHNwZWNpZmljIGNvbmZpZ3VyYWJs ZSBlbmNvZGluZyB3b3VsZCBiZSBleHBsb3JlZCBpbiBhIHRyYW5zcG9ydCBkb2N1bWVudCBiYXNl ZCBvbiB0aGlzIHNwZWNpZmljYXRpb24uIiAgSSBndWVzcyB0aGlzIGluZm9ybWF0aW9uIGNvdWxk IGJlIHJlcGVhdGVkIGFzIGEgc2VwYXJhdGUgcmVxdWlyZW1lbnQgaW4gU2VjdGlvbiA1LjMgaWYg eW91IGZlZWwgdGhpcyBpcyBpbnN1ZmZpY2llbnRseSBkZWZpbmVkLg0KDQo+IEkgYWxzbyB0aGlu ayB0aGF0IHdlIGNvdWxkDQo+IHByb2JhYmx5IHJlcXVpcmUgKGFzIG9wcG9zZWQgdG8gImhpZ2hs eSByZWNvbW1lbmQiIGluIHRoZSBjdXJyZW50IHNlY3VyaXR5DQo+IGNvbnNpZGVyYXRpb25zKSB0 aGF0IHRoZSB0cmFuc3BvcnQgcHJvdmlkZSBtZXNzYWdlIGNvbmZpZGVudGlhbGl0eSBhbmQgaW50 ZWdyaXR5DQo+IHByb3RlY3Rpb24uDQoNCkkgZm9yIHN1cmUgbGlrZSB0aGUgaWRlYSBvZiBlbmNy eXB0aW9uLiBBbmQgSSBhYnNvbHV0ZWx5IGxpa2UgdGhlIGlkZWEgb2Ygc2lnbmF0dXJlcyB0b28u ICBIb3dldmVyIHNldmVyYWwgeWVhcnMgYWdvIG9uIGJhc2VkIG9uIHdvcmsgd2l0aCBNU0RDIC8g Y2xvdWQgcHJvdmlkZXJzIGRlc2lyaW5nIHRlbGVtZXRyeSwgdGhlcmUgd2VyZSByZXF1ZXN0cyBm b3IgZGVwbG95bWVudHMgd2hlcmUgdGhlIHZvbHVtZSBvZiB0ZWxlbWV0cnkgZ2VuZXJhdGVkIGNv dWxkIG92ZXJ3aGVsbSB0aGUgQ1BVIG9mIHRoZSBob3N0IHJvdXRlci4gIEFuZCBhcyB0aGUgdGVs ZW1ldHJ5IHdhcyBiZWluZyBkZWxpdmVyZWQgd2l0aGluIGEgZnVsbHkgcHJvdGVjdGVkIE1TREMg ZG9tYWluL2Vudmlyb25tZW50LCB0aGVzZSBNU0RDIHByb3ZpZGVycyBzYWlkIHRoZXkgd2FudGVk ICphbGwqIHRoZSByb3V0ZXIgZGF0YSBtb3JlIHRoYW4gdGhleSBuZWVkZWQgbWVzc2FnZSBjb25m aWRlbnRpYWxpdHkgYW5kIGludGVncml0eSBwcm90ZWN0aW9uLiAgSS5lLiwgdGhlIHdhbnRlZCB0 byBoYXZlIG1vcmUgZGF0YSByYXRoZXIgdGhhbiBiZWluZyBjb25zdHJhaW5lZCB0aGUgaG9zdCBD UFUgZG9pbmcgZnVuY3Rpb25zIHdoaWNoIHJlZHVjZWQgdGhlIHZvbHVtZSBvZiBkYXRhIGJlaW5n IGRlbGl2ZXJlZC4gICAgDQoNClNvIHBlcnNvbmFsbHksIEkgd2FudCBsb3cgdm9sdW1lIHRlbGVt ZXRyeSB3aXRoIGZ1bGwgc2VjdXJpdHkgcHJvdGVjdGlvbnMgYXBwbGllZC4gIEJ1dCBieSBsZWF2 aW5nIGl0IGF0ICJoaWdobHkgcmVjb21tZW5kIiB3ZSBkb24ndCB1bmludGVudGlvbmFsbHkgaW5o aWJpdCBhcHBsaWNhYmlsaXR5IHRvIE1TREMgaW1wbGVtZW50YXRpb25zIGluIGEgcHJvdGVjdGVk IGRvbWFpbi4gIFRoZXkgZXhwbGljaXRseSBzYWlkIHRoZXkgZGlkbid0IHdhbnQgaXQuDQoNCj4g SSdtIGFsc28gdW5zdXJlIHRoYXQgSSBwcm9wZXJseSB1bmRlcnN0YW5kIHRoZSB1c2Ugb2YgdGhl ICJyZXNldCIgUlBDIC0tIGlmIGl0IGhhcw0KPiBubyBlZmZlY3Qgd2hlbiB0cmFuc2l0IGNvbm5l Y3Rpdml0eSBhbHJlYWR5IGV4aXN0cywgdGhlbiB3aGF0IGVudGl0eSBpcyBnb2luZyB0bw0KPiBj YWxsICJyZXNldCIgaW4gdGhlIGNhc2Ugb2YgcHVibGlzaGVyIHRpbWVvdXQgd2hlbiB0cnlpbmcg dG8gcmVhY2ggYSByZWNlaXZlcj8NCj4gU3VyZWx5IG5vdCB0aGUgcHVibGlzaGVyIGl0c2VsZiwg c2luY2UgdGhhdCB3b3VsZCBqdXN0IGJlIHB1Ymxpc2hlci1pbnRlcm5hbA0KPiBmdW5jdGlvbmFs aXR5IHdpdGggbm8gbmVlZCBmb3IgYW4gZXh0ZXJuYWwtZmFjaW5nIFJQQy4NCg0KVGhlIHJlc2V0 IFJQQyBvZiBzZWN0aW9uIDIuNS41IGlzIFlBTkcgbW9kZWwgZXhwb3NlZCBvcGVyYXRpb25hbCBr bm9iIGJhc2VkIG9uIHRoZSBZQU5HIDEuMSBsYW5ndWFnZSBjb25zdHJ1Y3QgImFjdGlvbiI6DQpo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzk1MCNzZWN0aW9uLTcuMTUgDQoNCkFuIG9w ZXJhdGlvbmFsIGludGVyZmFjZSBjYW4gY2FsbCB0aGlzIGFjdGlvbi4gIEkuZS4sIGFuIGVudGl0 eSB3aXRoIHRoZSBwcm9wZXIgYWRtaW5pc3RyYXRpdmUgcHJpdmlsZWdlcyBjYW4gYWNjZXNzICJy ZXNldCIuICAgIFRoaXMgbWVhbnMgYSBSRVNUIGludGVyZmFjZSBjb3VsZCBiZSBleHBvc2VkIHVw b24gYSBjb250cm9sbGVyIGZvciB0aGF0IHB1Ymxpc2hlci4gIEFuZCB3aGVuIHNvbWVib2R5IGZp bmQgdGhhdCB0aGUgc3Vic2NyaXB0aW9uIGlzbid0IHJlc3BvbnNpdmUgKGZvciBhIHZhcmlldHkg b2YgcmVhc29ucykgdGhhdCBSRVNUIGludGVyZmFjZSBjYW4gYmUgY2FsbGVkLCBhbmQgdGhlIHB1 Ymxpc2hlciBjYW4gc3RhcnQgdHJ5aW5nIHRvIG1ha2UgY29ubmVjdGlvbnMgKHN1Y2ggYXMgUkZD IDgwNzEgY2FsbCBob21lIGNvbm5lY3Rpb25zKSB0byBhIHJlY2VpdmVyLg0KDQogDQo+IEknbSBh bHNvIGEgbGl0dGxlIHVuY2xlYXIgb24gdGhlIG1lY2hhbmljcyBvZiB0aGUgbGlzdCBvZiBzdWJz Y3JpcHRpb25zIGRlc2NyaWJlZCBpbg0KPiBTZWN0aW9uIDMuMy4gIERvZXMgaXQgcHJvdmlkZSBh IHdheSBmb3IgYSBsb3ctcHJpdmlsZWdlIGNsaWVudCAodGhhdCBjYW4gb25seQ0KPiBhY2Nlc3Mg b25lIG9yIGEgaGFuZGZ1bCBvZiB0aGUgc3Vic2NyaXB0aW9ucykgdG8gZW51bWVyYXRlIGFsbCBz dWJzY3JpcHRpb25zIHRoYXQNCj4gZXhpc3QsIGluY2x1ZGluZyBzdWJzY3JpcHRpb25zIHVzZWQg YnkgaGlnaC1wcml2aWxlZ2UgY2xpZW50cz8gIElmIHNvLCB3ZSBtYXkgd2FudA0KPiB0byB0aGlu ayBhYm91dCBzb21lIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRleHQgdG8gdGhhdCBlZmZlY3Q7 IGlmIG5vdCwgd2UgbWF5DQo+IHdhbnQgdG8gc2F5IHRoYXQgdGhlIGFjY2Vzcy1jb250cm9sIHdp bGwgbGltaXQgd2hpY2ggbGVhZnMgYXJlIHZpc2libGUgdG8gc29tZQ0KPiBjbGllbnRzLg0KDQpZ b3VyIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnRzIGNvbXBsZXRlbHkgdmFsaWQuICBJIGJlbGlldmUg dGhleSBhcmUgY292ZXJlZCBieSBhIHNldCBvZiBvdGhlciBZQU5HIFJGQyB3aGljaCBkaWN0YXRl IHdoby93aGF0IGNhbiBhY2Nlc3MgdmFyaW91cyBlbGVtZW50cyBvZiBZQU5HIGRhdGEuICBHb29k IGV4YW1wbGUgZG9jdW1lbnRzIHRvIGxvb2sgYXQgaGVyZSBhcmUgb25lcyBsaWtlOg0KDQpSRkMt ODM0MSAtIE5ldHdvcmsgQ29uZmlndXJhdGlvbiBBY2Nlc3MgQ29udHJvbCBNb2RlbA0KDQpBbiB1 bmRlcnN0YW5kaW5nIG9mIHRoZXNlIGRvY3VtZW50cyBhcmUgYXNzdW1lZCwgYW5kIGxpc3RlZCBp biBwbGFjZXMgbGlrZSB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4gU2VjdGlvbiA1LjQu DQogDQo+IEZpbmFsbHksIHdlIGhhdmUgYSBmZXcgaW5zdGFuY2VzIG9mICJsZWFmIGZpbHRlci1m YWlsdXJlLWhpbnQiIHRoYXQncyBvZiB0eXBlDQo+ICJzdHJpbmciLCBwcm92aWRpbmcNCj4gICAg ICAgICAgICAgICJJbmZvcm1hdGlvbiBkZXNjcmliaW5nIHdoZXJlIGFuZC9vciB3aHkgYSBwcm92 aWRlZCBmaWx0ZXINCj4gICAgICAgICAgICAgICB3YXMgdW5zdXBwb3J0YWJsZSBmb3IgYSBzdWJz Y3JpcHRpb24uIjsgSSBkb24ndCB1bmRlcnN0YW5kIHdoeSBpdCdzIGENCj4gc3RyaW5nIGFzIG9w cG9zZWQgdG8gc29tZSBmb3JtIG9mIG1hY2hpbmUtcmVhZGFibGUgZGF0YS4gIElzIGl0IHN1cHBv c2VkIHRvIGJlDQo+IGh1bWFuLXJlYWRhYmxlPyAgRG9lcyB0aGF0IGJyaW5nIGluIGFueSBpbnRl cm5hdGlvbmFsaXphdGlvbiBjb25zaWRlcmF0aW9ucz8NCg0KVGhlcmUgYXJlIG1hbnkgcmVhc29u cyB3aHkgYSBmaWx0ZXIgbWlnaHQgZmFpbC4gIFRoZSBhdXRob3JzIGRpZG4ndCBiZWxpZXZlIHRo YXQgdGhlcmUgd2FzIGVub3VnaCBvcGVyYXRpb25hbCBleHBlcmllbmNlIHRvIHN1ZmZpY2llbnRs eSBkb2N1bWVudCB0aGUgdW5pdmVyc2Ugb2YgZmFpbHVyZSB0eXBlcyBhY3Jvc3MgdGhlIHNldCBv ZiBpbnRlcmVzdGVkIHBhcnRpZXMuICBBcyBhIHJlc3VsdCwgdGhlIG9wdGlvbiBzZWVtZWQgdG8g YmUgdG8gcHJvdmlkZSBubyBndWlkYW5jZSBvbiB0aGUgZmFpbHVyZSByZWFzb24sIG9yIHRvIGxl dCB0aGUgdmVuZG9ycyBwcm92aWRlIHNvbWUgZ3VpZGFuY2UgKGFsYmVpdCBqdXN0IGEgJ3N0cmlu ZycpLiAgU28gYXQgdGhpcyBwb2ludCB3aXRoIHRoZSBzcGVjaWZpY2F0aW9uLCBpdCB3b3VsZCBi ZSB1cCB0byB0aGUgdmVuZG9yIHRvIGRldGVybWluZSB3aGV0aGVyIGl0IGlzIGh1bWFuIHJlYWRh YmxlLCBvciB3aGV0aGVyIGludGVybmF0aW9uYWxpemF0aW9uIGNvbnNpZGVyYXRpb25zIHNob3Vs ZCBiZSBjb3ZlcmVkLiAgSG9wZWZ1bGx5IHdpdGggZW5vdWdoIGRlcGxveW1lbnRzIHRoaXMgbWln aHQgYmUgcmV2aXNpdGVkIGF0IGEgZnV0dXJlIGRhdGUuDQoNCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBD T01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBTZWN0aW9uIDEuMw0KPiANCj4gICAgQWxz byBub3RlIHRoYXQgdHJhbnNwb3J0IHNwZWNpZmljIHRyYW5zcG9ydCBkcmFmdHMgYmFzZWQgb24g dGhpcw0KPiAgICBzcGVjaWZpY2F0aW9uIE1VU1QgZGV0YWlsIHRoZSBsaWZlIGN5Y2xlIG9mIGR5 bmFtaWMgc3Vic2NyaXB0aW9ucywgYXMNCj4gICAgd2VsbCBhcyB0aGUgbGlmZWN5Y2xlIG9mIGNv bmZpZ3VyZWQgc3Vic2NyaXB0aW9ucyAoaWYgc3VwcG9ydGVkKS4NCj4gDQo+IEknbSBub3Qgc3Vy ZSBJIHVuZGVyc3RhbmQgd2hhdCBhZGRpdGlvbmFsIHNwZWNpZmljYXRpb24gaXMgbmVlZGVkIGZv ciB0aGUgbGlmZWN5Y2xlDQo+IG9mIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucyAtLSBkb2Vzbid0 IHRoZSBwcmV2aW91cyB0ZXh0IHRpZ2h0bHkgdGllIHRoZWlyIGxpZmVjeWNsZQ0KPiB0byB0aGUg cHJlc2VuY2Ugb2YgY29uZmlndXJhdGlvbiBpbiB0aGUgY29uZmlndXJhdGlvbiBkYXRhc3RvcmU/ DQoNCkZvciB0aGUgbW9zdCBwYXJ0IGl0IGRvZXMuICBIb3dldmVyIHRoZXJlIGlzIGEgcmVsYXRp b25zaGlwIGZvciBleGFjdGx5IHdoZW4gdG8gZXN0YWJsaXNoIHRyYW5zcG9ydCBjb25uZWN0aXZp dHkgYmFzZWQgb24gdGhlIHN0YXRlIG9mIGVhY2ggcmVjZWl2ZXIgb2YgYSBjb25maWd1cmVkIHN1 YnNjcmlwdGlvbi4NCg0KQXMgYW4gZXhhbXBsZSBvZiB3aGF0IHNob3VsZCBiZSBzcGVjaWZpZWQs IHNlZSBTZWN0aW9uIDUuMiBvZg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1uZXRjb25mLW5ldGNvbmYtZXZlbnQtbm90aWZpY2F0aW9ucy8xMC8NCkhlcmUgeW91 IGNhbiBzZWUgaG93IE5FVENPTkYgY2FsbCBob21lIGlzIGludm9rZWQgYXQgdGhlIHByb3BlciBw b2ludHMgaW4gdGhlIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIHN0YXRlIG1hY2hpbmUuDQoNCj4g bml0OiBwbGVhc2UgYmUgY29uc2lzdGVudCBhYm91dCAibGlmZSBjeWNsZSIgdnMuICJsaWZlY3lj bGUiIHRocm91Z2hvdXQuDQoNCkZpeGVkIG5pdCB0byAibGlmZWN5Y2xlIi4NCg0KPiBTZWN0aW9u IDIuMQ0KPiANCj4gICAgQW4gZXZlbnQgc3RyZWFtIGlzIGEgbmFtZWQgZW50aXR5IG9uIGEgcHVi bGlzaGVyIHdoaWNoIGV4cG9zZXMgYQ0KPiAgICBjb250aW51b3VzbHkgdXBkYXRpbmcgc2V0IG9m IFlBTkcgZW5jb2RlZCBldmVudCByZWNvcmRzLiAgWy4uLl0NCj4gDQo+IG5pdDogSSBkb24ndCB0 aGluayAiWUFORyBlbmNvZGVkIiBpcyB3ZWxsLWRlZmluZWQgKGhlcmUgYW5kIGJlbG93KSwgaW4g dGhhdCBZQU5HDQo+IHN0cnVjdHVyZXMgZ2VuZXJhdGUgZGF0YSBtb2RlbHMgYnV0IGNhbiBiZSBl bmNvZGVkIGludG8gdmFyaW91cyBmb3JtYXRzIChsaWtlDQo+IFhNTCBhbmQgSlNPTikuDQoNClRo aXMgaXMgdHJ1ZS4gIEkgbWFkZSB0aGUgdHdvIG9jY3VycmVuY2VzIG9mICJZQU5HIGVuY29kZWQi IGludG8gIllBTkcgZGVmaW5lZCIuDQogDQo+IFNlY3Rpb24gMi4zDQo+IA0KPiAgICBJZiB0aGUg cHVibGlzaGVyIHN1cHBvcnRzIHRoZSAiZHNjcCIgZmVhdHVyZSwgdGhlbiBhIHN1YnNjcmlwdGlv bg0KPiAgICB3aXRoIGEgImRzY3AiIGxlYWYgTVVTVCByZXN1bHQgaW4gYSBjb3JyZXNwb25kaW5n IFtSRkMyNDc0XSBEU0NQDQo+ICAgIG1hcmtpbmcgYmVpbmcgcGxhY2VkIHdpdGhpbiB0aGUgSVAg aGVhZGVyIG9mIGFueSByZXN1bHRpbmcNCj4gICAgbm90aWZpY2F0aW9uIG1lc3NhZ2VzIGFuZCBz dWJzY3JpcHRpb24gc3RhdGUgY2hhbmdlIG5vdGlmaWNhdGlvbnMuDQo+ICAgIFdoZXJlIFRDUCBp cyB1c2VkLCBhIHB1Ymxpc2hlciB3aGljaCBzdXBwb3J0cyB0aGUgImRzY3AiIGZlYXR1cmUNCj4g ICAgU0hPVUxEIGVuc3VyZSB0aGF0IGEgc3Vic2NyaXB0aW9uJ3Mgbm90aWZpY2F0aW9uIG1lc3Nh Z2VzIGFyZQ0KPiAgICByZXR1cm5lZCB3aXRoaW4gYSBzaW5nbGUgVENQIHRyYW5zcG9ydCBzZXNz aW9uIHdoZXJlIGFsbCB0cmFmZmljDQo+ICAgIHNoYXJlcyB0aGUgc3Vic2NyaXB0aW9uJ3MgImRz Y3AiIGxlYWYgdmFsdWUuICBXaGVyZSB0aGlzIGNhbm5vdCBiZQ0KPiAgICBndWFyYW50ZWVkLCBh bnkgImVzdGFibGlzaCBzdWJzY3JpcHRpb24iIFJQQyByZXF1ZXN0IFNIT1VMRCBiZQ0KPiAgICBy ZWplY3RlZCB3aXRoIGEgImRzY3AtdW5hdmFpbGFibGUiIGVycm9yDQo+IA0KPiBJIGNhbid0IGRl Y2lkZSB3aGV0aGVyIHdlIG5lZWQgdG8gYmUgbW9yZSBleHBsaWNpdCBpbiB0aGUgc2Vjb25kIGFu ZC9vciB0aGlyZA0KPiBzZW50ZW5jZXMgdGhhdCB0aGlzIHJlbWFpbnMgY29udGluZ2VudCBvbiB0 aGUgc3Vic2NyaXB0aW9uIGluIHF1ZXN0aW9uIGhhdmluZyBhDQo+ICJkc2NwIiBsZWFmLg0KDQpU aGUgc2VudGVuY2VzIHdlcmUgYWxyZWFkeSBsb25nLCBpdCBmZWVscyB0byBtZSBsaWtlIGl0IHdv dWxkIGJlIG1vcmUgY29uZnVzaW5nIHRvIHB1dCBpbiBtb3JlIHdvcmRzIGhlcmUuIA0KDQo+IG5p dDogZW5kIHNlbnRlbmNlIHdpdGggYSBmdWxsIHN0b3ANCg0KUGVyaW9kIGFkZGVkLg0KDQo+IEkg c2hhcmUgdGhlIFRTVi1BUlQgcmV2aWV3ZXIncyBjb25mdXNpb24gYWJvdXQgaG93IHRoZSB3ZWln aHRpbmcgKGFzIHdlbGwgYXMNCj4gRFNDUCkgZnVuY3Rpb25hbGl0eSBpcyBpbnRlbmRlZCB0byB3 b3JrLg0KDQpTaG9ydCBhbnN3ZXI6ICBFYXJsaWVyIHZlcnNpb25zIG9mIHRoaXMgZHJhZnQgbWFk ZSBleHBsaWNpdCBwYXJhbGxlbHMgb2YgdGhlIHdlaWdodGluZyBtZXRob2QgdG8gSFRUUDIgUkZD LTc0NTAgc2VjdGlvbiA1LjMuMi4gIFRoZSBvcGVyYXRpb24gb2Ygd2VpZ2h0aW5nIGlzIGV4YWN0 bHkgdGhlIHNhbWUgSFRUUDIgZGVwZW5kZW5jeSB3ZWlnaHRpbmcuICBUaGVyZSBpcyBhZGRpdGlv bmFsIGRlZmluaXRpb24gb2YgaG93IHRoaXMgaXMgc3VwcG9zZWQgdG8gd29yayBpbiBTZWN0aW9u IDQgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLW5vdGlmICh3aGljaCBpcyBhbHNvIGN1 cnJlbnRseSB1cCBmb3IgcmV2aWV3KS4NCg0KTG9uZyBhbnN3ZXI6IFRTVi1BUlQgaXMgYWJzb2x1 dGVseSBjb3JyZWN0IHRoYXQgYSBwdWJsaXNoZXIgbWlnaHQgZ2VuZXJhdGUgYSBsb3Qgb2YgdHJh ZmZpYy4gIEluIG1hbnkgd2F5cywgaGlnaCB0cmFmZmljIHZvbHVtZXMgd291bGQgYmUgYSBzdWNj ZXNzZnVsIG91dGNvbWUgZm9yIHRoaXMgd29yay4gICBBcyBhIHJlc3VsdCwgbWl0aWdhdGluZyBk aWZmZXJlbnQgZGltZW5zaW9ucyBvZiB0aGlzIHZvbHVtZSByaXNrIGhhcyBiZWVuIGEgZGVzaWdu IGdvYWwgc2luY2UgdGhpcyBlZmZvcnTigJlzIGluY2VwdGlvbi4gIEFuZCB0aGlzIGlzIHRoZSBy ZWFzb24gcm9idXN0IFFvUyBtZWNoYW5pc21zIHdlcmUgaW5jbHVkZWQuICBUaGlzIGluY2x1ZGVz IGJvdGggRFNDUCBhbmQgd2VpZ2h0aW5nLg0KDQpIZXJlIGlzIGEgcXVpY2sgc3VtbWFyeSBvZiBz b21lIFFvUyBtZWNoYW5pc21zIGF2YWlsYWJsZSBpbiB0aGlzIGRyYWZ0Li4uDQoNCjEuIFRoZSBw dWJsaXNoZXIgaXMgYWxsb3dlZCB0byBkZWNsaW5lIGEgZHluYW1pYyBzdWJzY3JpcHRpb24uICBP bmUgb2YgdGhlc2UgcmVhc29ucyBpcyB0aGF0IHRoZSBpbmNyZW1lbnRhbCB0cmFmZmljIGdlbmVy YXRlZCBieSBhIHBhcnRpY3VsYXIgaW5jcmVtZW50YWwgc3Vic2NyaXB0aW9uIHdpbGwgYmUgdG9v IGhpZ2guICBUaGVyZSBhcmUgZXJyb3JzIGJhY2sgdG8gdGhlIHN1YnNjcmliZXIgaW5kaWNhdGlu ZyB0aGlzIGNvbmRpdGlvbiBleGlzdC4NCjIuIEEgcHVibGlzaGVyIGNhbiBzdXNwZW5kIGFueSBz dWJzY3JpcHRpb24gZm9yIGNhcGFjaXR5IHJlYXNvbnMsIGFuZCBhIHJlY2VpdmVyIG11c3QgYmUg YWJsZSB0byBncmFjZWZ1bGx5IGFjY2VwdCB0aGlzIHN1c3BlbnNpb24uIA0KMy4gTXVjaCBsaWtl IHdpdGggSFRUUDIgc3RyZWFtcywgaGlnaGVyIHByaW9yaXR5IHN1YnNjcmlwdGlvbnMgaW50ZW5k ZWQgZm9yIGEgcGFydGljdWxhciByZWNlaXZlciBjYW4gYmUgZGVxdWV1ZWQgZmlyc3QgZnJvbSBh IHB1Ymxpc2hlci4gDQo0LiBNdWNoIGxpa2Ugd2l0aCBIVFRQMiBzdHJlYW1zLCBwcm9wb3J0aW9u YWwgc3Vic2NyaXB0aW9uIGRlcXVldWluZyBpbnRlbmRlZCBmb3IgYSBwYXJ0aWN1bGFyIHJlY2Vp dmVyIGNhbiBiZSBwZXJmb3JtZWQgYSBwdWJsaXNoZXIuDQo1LiBEU0NQIG1hcmtpbmdzIGNhbiBi ZSBwbGFjZWQgb24gc3Vic2NyaWJlZCBkYXRhLg0KNi4gTWVjaGFuaXNtcyBmb3IgZGV0ZWN0aW5n IGFuZCByZWFjdGluZyB0byBkaWZmZXJlbnQgdHlwZXMgb2Ygc3Vic2NyaWJlZCBkYXRhIGxvc3Mg aGF2ZSBiZWVuIGVtYmVkZGVkLg0KNy4gTWV0aG9kcyBoYXZlIGJlZW4gaW5jbHVkZWQgdG8gZW5z dXJlIGEgY29uZmlndXJlZCByZWNlaXZlciDigJxva+KAmXPigJ0gaW5mb3JtYXRpb24gcHVzaCBi ZWZvcmUgc3Vic2NyaWJlZCBkYXRhIGlzIHNlbnQuIChUaGlzIHNob3VsZCByZWR1Y2Ugb25lIERE b1MgdmVjdG9yLikNCjguIEtlZXAgYWxpdmUgbWVjaGFuaXNtcyBhcmUgZXN0YWJsaXNoZWQgZm9y IGRpZmZlcmVudCB0cmFuc3BvcnQgdHlwZXMsIHNvIHRoYXQgc3Vic2NyaWJlZCBkYXRhIGlzbuKA mXQgYmVpbmcgc2VudCB3aGVuIHRoZSBpcyBubyByZWNlaXZlciBsaXN0ZW5pbmcuDQoNCk1lY2hh bmlzbSAoNCkgaXMgaW4gcXVlc3Rpb24gaGVyZS4gICBBcyBkZWZpbmVkIGJ5IGRyYWZ0LWlldGYt bmV0Y29uZi1yZXN0Y29uZi1ub3RpZiwgdGhpcyBpcyBzdXBwb3NlZCB0byB3b3JrIGlkZW50aWNh bGx5IHRvIEhUVFAyIFJGQy03NDUwIHNlY3Rpb24gNS4zLjIuICAgSG93ZXZlciB0aGVyZSB3ZXJl IFdHIG1lbWJlcnMgd2hvIGRpZCBub3Qgd2FudCB0byBpbmNsdWRlIGEgZnVuY3Rpb25hbCByZXF1 aXJlbWVudCBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIHRoYXQgSFRUUDIgdHJhbnNwb3J0IGluIHRo aXMgZG9jdW1lbnQgaG93ZXZlci4gIFRoZXJlZm9yZSB0aGUgcmVmZXJlbmNlIHRvIEhUUDIgd2Fz IHJlbW92ZWQuDQoNCkluIHRoZSBlbmQsIEkgZG9uJ3QgdGhpbmsgd2UgY2FuIGFmZm9yZCB0byBn ZXQgcmlkIG9mIHN1cHBvcnQgZm9yICg0KSBmcm9tIHRoZSBzcGVjaWZpY2F0aW9uLiAgIFRoaXMg d2VpZ2h0aW5nIGNhcGFiaWxpdHkgaXMgcXVpdGUgcG93ZXJmdWwsIGFuZCBjYW4gZWFzaWx5IGJl IGFkZGVkIHRvIEdSUEMgYmFzZWQgc3Vic2NyaXB0aW9uIGFsdGVybmF0aXZlcy4NCg0KPiBTZWN0 aW9uIDIuNC4yLjENCj4gDQo+ICAgIFJlcGxheSBwcm92aWRlcyB0aGUgYWJpbGl0eSB0byBlc3Rh Ymxpc2ggYSBzdWJzY3JpcHRpb24gd2hpY2ggaXMgYWxzbw0KPiAgICBjYXBhYmxlIG9mIHBhc3Np bmcgcmVjZW50bHkgZ2VuZXJhdGVkIGV2ZW50IHJlY29yZHMuICBJbiBvdGhlciB3b3JkcywNCj4g DQo+IG5pdC9lZGl0b3JpYWw6IHRoaXMgbGFuZ3VhZ2UgY291bGQgcHJvYmFibHkgYmUgbW9yZSBj bGVhciBhYm91dCAicmVjZW50bHkNCj4gZ2VuZXJhdGVkIiBtZWFuaW5nICJpbiB0aGUgcGFzdCIs IHRoYXQgaXMsIHJlY29yZHMgZm9yIGV2ZW50cyB0aGF0IGhhdmUgYWxyZWFkeQ0KPiBoYXBwZW5l ZCB3aGVuIHRoZSBzdWJzY3JpcHRpb24gaXMgZXN0YWJsaXNoZWQuDQoNClR3ZWFrZWQgdG8gImV2 ZW50IHJlY29yZHMgZ2VuZXJhdGVkIGluIHRoZSByZWNlbnQgcGFzdCINCiANCj4gU2VjdGlvbiAy LjQuMw0KPiANCj4gICAgYW55IG51bWJlciBvZiB0aW1lcy4gIER5bmFtaWMgc3Vic2NyaXB0aW9u cyBjYW4gb25seSBiZSBtb2RpZmllZCB2aWENCj4gICAgdGhpcyBSUEMgdXNpbmcgYSB0cmFuc3Bv cnQgc2Vzc2lvbiBjb25uZWN0aW5nIHRvIHRoZSBzdWJzY3JpYmVyLiAgSWYNCj4gDQo+IG5pdCg/ KTogaXMgdGhpcyBtb3JlIHJlYWRhYmxlIGFzICJjb25uZWN0aW5nIHRvIiBvciAiY29ubmVjdGlu ZyBmcm9tIg0KPiB0aGUgc3Vic2NyaWJlcj8gIChUaGUgc2FtZSB3b3JkaW5nIHNob3dzIHVwIHRo cm91Z2hvdXQgdGhlIGRvY3VtZW50LCBidXQgSSdsbA0KPiB0cnkgdG8ganVzdCBjb21tZW50IG9u Y2UuKQ0KDQpJIGV4cGVjdCB0aGF0IGl0IHNob3VsZCBiZSBjbGVhciBlbm91Z2ggZWl0aGVyIHdh eS4gIEkgYmVsaWV2ZSBsZWF2aW5nIHRoZSBjdXJyZW50IHRleHQgc2hvdWxkIG5vdCBpbXBhY3Qg aW1wbGVtZW50YXRpb25zLg0KDQo+IFNlY3Rpb24gMi40LjUNCj4gDQo+IElzIHRoZXJlIGFueSBk aXN0aW5jdGlvbiBiZXR3ZWVuICJraWxsaW5nIGEgc3Vic2NyaXB0aW9uIiBhbmQgImFkbWluaXN0 cmF0aXZlbHkNCj4gZGVsZXRpbmcgYSBzdWJzY3JpcHRpb24iPyAgSXQncyB1bmNsZWFyIHRvIG1l IHRoYXQgd2UgbmVlZCB0aGUgZXh0cmEgY29ubm90YXRpb25zDQo+IG9mIHRoZSB3b3JkICJraWxs IiwgaGVyZS4NCg0KV2UgY2hvc2UgdG8gdXNlIGEgZGlmZmVyZW50IFJQQyBuYW1lIHNvIHRoYXQg YWRtaW5pc3RyYXRpdmUgYWNjZXNzIGNvbnRyb2wgcGVybWlzc2lvbnMgZGlmZmVyZW5jZXMgYmV0 d2VlbiB0aGUga2lsbC1zdWJzY3JpcHRpb24gYW5kIGRlbGV0ZS1zdWJzY3JpcHRpb24gd291bGQg YmUgZXhwbGljaXQgYW5kIG9idmlvdXMuICBBbmQgb25jZSB3ZSBoYWQgYSBuZXcgUlBDIG5hbWUs IGl0IHNlZW1lZCBlYXNpZXIgZm9yIHRoZSByZWFkZXIgdG8gY29udGludWUgdXNpbmcgdGhlICJr aWxsIiB3b3JkIGZvciB0aGF0IFJQQy4NCg0KPiBTZWN0aW9uIDIuNC42DQo+IA0KPiAgICBBcyBh IHJlc3VsdCBvZiB0aGlzIG1peHR1cmUsIGhvdyBzdWJzY3JpcHRpb24gZXJyb3JzIGFyZSBlbmNv ZGVkDQo+IA0KPiBuaXQ6ICJtaXh0dXJlIiBkb2Vzbid0IHNlZW0gbGlrZSB0aGUgcmlnaHQgd29y ZCB0byBtZTsgInZhcmlldHkiIG9yICJ2YXJpZWQNCj4gcG9wdWxhdGlvbiIgYXJlIHRoZSBmaXJz dCBhbHRlcm5hdGl2ZXMgdGhhdCBjb21lIHRvIG1pbmQsIHRob3VnaCB0aGV5IGFyZSBub3QNCj4g cGVyZmVjdCBlaXRoZXIuDQoNCkNoYW5nZWQgdG8gJ3ZhcmlldHknLg0KDQo+IElzIHRoZXJlIHNv bWUgc29ydCBvZiAiYWNjZXNzIGRlbmllZCIgZXJyb3IgdGhhdCBjb3VsZCByZXN1bHQgZnJvbSBr aWxsLQ0KPiBzdWJzY3JpcHRpb24gUlBDcz8gIChUaGUgdGFibGUvYXJ0d29yayBvbmx5IGxpc3Rz DQo+ICJuby1zdWNoLXN1YnNjcmlwdGlvbiIuKQ0KDQpBY2Nlc3MgZGVuaWVkIHdoZW4gYW4gUlBD IGZhaWxzIGFjY2VzcyBjb250cm9sIGlzIHBhcnQgb2YgdGhlIGJhc2UgdHJhbnNwb3J0IGVycm9y IHR5cGVzIGZvciB0aGUgUlBDLiAgIEkuZS4sIHRyYW5zcG9ydHMgbGlrZSBORVRDT05GIGFuZCBS RVNUQ09ORiBhbHJlYWR5IGhhdmUgbm9uLXN1YnNjcmlwdGlvbi1zcGVjaWZpYyBlcnJvcnMgbGlr ZSB0aGlzIG9uZSBhbHJlYWR5IGNvdmVyZWQuDQoNCj4gU2VjdGlvbiAyLjUNCj4gDQo+IEl0J3Mg aW50ZXJlc3RpbmcgdG8gc2VlIGEgc2xpZ2h0IGRpY2hvdG9teSBiZXR3ZWVuIGR5bmFtaWMgYW5k IGNvbmZpZ3VyZWQNCj4gc3Vic2NyaXB0aW9ucywgaW4gdGhhdCAoSUlVQykgZm9yIGR5bmFtaWMg c3Vic2NyaXB0aW9ucywgYSBtb2RpZmljYXRpb24gZXZlbnQgdW4tDQo+IHN1c3BlbmRzIGEgc3Vi c2NyaXB0aW9uIGltbWVkaWF0ZWx5LCBidXQgZm9yIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucyB0 aGUNCj4gcHVibGlzaGVyIHNlZW1zIHRvIGhhdmUgc29tZSBsYXRpdHVkZSB0byByZXRhaW4gdGhl IHN1YnNjcmlwdGlvbiBpbiB0aGUNCj4gc3VzcGVuZGVkIHN0YXRlIGZvciBzb21lIHRpbWUgYmVm b3JlIHVuLXN1c3BlbmRpbmcgaXQgYW5kIHNlbmRpbmcgdGhlDQo+ICJzdWJzY3JpcHRpb24tbW9k aWZpZWQiIHN0YXRlIGNoYW5nZSBtZXNzYWdlLg0KPiANCj4gICAgICAgICAgICAgICAgICBJbiB0 aGlzIGNhc2UsIGEgc2VwYXJhdGUgZHluYW1pYyBzdWJzY3JpcHRpb24gY2FuIGJlDQo+ICAgIGVz dGFibGlzaGVkIHRvIHJldHJhbnNtaXQgdGhlIG1pc3NpbmcgZXZlbnQgcmVjb3Jkcy4NCj4gDQo+ IERvIHlvdSB3YW50IHRvIHB1dCBpbiBhIHBvaW50ZXIgdG8gcmVwbGF5LXN0YXJ0LXRpbWUgaGVy ZT8NCg0KSSB0aG91Z2h0IGdldHRpbmcgdG8gdGhhdCBsZXZlbCBvZiBkZXRhaWwgaW4gdGhlIGlu dHJvIHdhcyBjb25mdXNpbmcgZm9yIHRoaXMgaW50cm8gc2VjdGlvbi4NCiANCj4gU2VjdGlvbiAy LjUuMQ0KPiANCj4gICAgICAgICAgRXZlbnQgcmVjb3JkcyBhcmUgb25seSBzZW50IHRvIGFjdGl2 ZSByZWNlaXZlcnMuICBSZWNlaXZlcnMgb2YNCj4gICAgYSBjb25maWd1cmVkIHN1YnNjcmlwdGlv biByZW1haW4gYWN0aXZlIGlmIGJvdGggdHJhbnNwb3J0DQo+ICAgIGNvbm5lY3Rpdml0eSBjYW4g YmUgdmVyaWZpZWQgdG8gdGhlIHJlY2VpdmVyLCBhbmQgZXZlbnQgcmVjb3JkcyBhcmUNCj4gICAg bm90IGJlaW5nIGRyb3BwZWQgZHVlIHRvIGEgcHVibGlzaGVyIGJ1ZmZlciBvdmVyZmxvdy4gIFsu Li5dDQo+IA0KPiBuaXQ6ICJidWZmZXIgb3ZlcmZsb3ciIGlzIGEgdGVjaG5pY2FsIHRlcm0gaW4g c2VjdXJpdHkgY2lyY2xlcyBpbmRpY2F0aW5nIGENCj4gcG90ZW50aWFsbHkgZXhwbG9pdGFibGUg c2VjdXJpdHkgZmxhdzsgd291bGQgInB1Ymxpc2hlciBidWZmZXIgY2FwYWNpdHkgYmVpbmcNCj4g cmVhY2hlZCIgYmUgYW4gYWNjZXB0YWJsZSBzdWJzdGl0dXRlIChoZXJlIGFuZCBiZWxvdyk/DQoN CkNoYW5nZSBtYWRlDQogDQo+IFNlY3Rpb24gMi43LjcNCj4gDQo+ICAgIFRoaXMgbm90aWZpY2F0 aW9uIGluZGljYXRlcyB0aGF0IGFsbCBvZiB0aGUgZXZlbnQgcmVjb3JkcyBwcmlvciB0bw0KPiAg ICB0aGUgY3VycmVudCB0aW1lIGhhdmUgYmVlbiBwYXNzZWQgdG8gYSByZWNlaXZlci4gIEl0IGlz IHNlbnQgYmVmb3JlDQo+ICAgIGFueSBub3RpZmljYXRpb24gbWVzc2FnZSBjb250YWluaW5nIGFu IGV2ZW50IHJlY29yZCB3aXRoIGEgdGltZXN0YW1wDQo+ICAgIGxhdGVyIHRoYW4gKDEpIHRoZSAi c3RvcC10aW1lIiBvciAoMikgdGhlIHN1YnNjcmlwdGlvbidzIHN0YXJ0IHRpbWUuDQo+IA0KPiBu aXQoPyk6IHRoaXMgdGV4dCBzZWVtcyB0byBpbXBseSB0aGF0IGEgbm90aWZpY2F0aW9uIG1lc3Nh Z2Ugd2l0aCBhIHRpbWVzdGFtcA0KPiBsYXRlciB0aGFuIHRoZSAic3RvcC10aW1lIiBtaWdodCBh Y3R1YWxseSBiZSBzZW50LCB3aGljaCBJSVVDIGlzIG5vdCB0aGUgY2FzZS4NCg0KWW91IGFyZSBj b3JyZWN0IHRoYXQgaXQgaXMgbm90IHNlbnQuICBCdXQgdGhlIGV2ZW50IHJlY29yZCBkb2VzIGV4 aXN0IG9uIHRoZSBzdHJlYW0uICANCg0KSSB0aGluayBpdCBvYnZpb3VzLCBidXQgaWYgeW91IHdh bnQgSSBjb3VsZCBhZGQgdGhlIGZvbGxvd2luZyBzZW50ZW5jZSB0byB0aGUgZW5kIG9mIHRoZSBz dWJzZXF1ZW50IHBhcmFncmFwaC4gICJJZiBhIHN0b3AtdGltZSBoYXMgYmVlbiBleGNlZWQgZHVy aW5nIHJlcGxheSwgbm8gc3Vic2VxdWVudCBldmVudCByZWNvcmRzIGFyZSBzZW50IGZvbGxvd2lu ZyB0aGUgc2VuZGluZyBvZiBhICJyZXBsYXktY29tcGxldGVkIiBub3RpZmljYXRpb24uIg0KDQoN Cj4gU2VjdGlvbiAyLjkNCj4gDQo+IG5pdDogdGhlIG5hbWUgInN1cHBvcnRzLXZyZiIgZm9yIHRo ZSBmZWF0dXJlIGRvZXNuJ3QgcmVhbGx5IHBhcmFsbGVsIHRoZSBvdGhlcg0KPiBmZWF0dXJlIG5h bWVzLCB0aGF0IGRvbid0IGluY2x1ZGUgYSB3b3JkIGxpa2UgInN1cHBvcnQiIGFuZCByYXRoZXIg anVzdCBkZXNjcmliZQ0KPiB0aGUgYWN0dWFsIGZlYXR1cmUuDQoNClRoaXMgaXMgdHJ1ZS4gIFNl dmVyYWwgeWVhcnMgYWdvIHdoZW4gc29tZW9uZSBwcm9wb3NlZCB0aGlzIG5hbWUsIHRoZXJlIHdh cyBhIHJlYXNvbi4gIEJ1dCBJIGNhbid0IHJlbWVtYmVyIHdoYXQgaXQgaXMgcmlnaHQgbm93LiAg U28gaG9wZWZ1bGx5IHdlIGNhbiBsZWF2ZSBpdCBzbyBhcyBub3QgdG8gYnJlYWsgc29tZW9uZSdz IHRoaW5raW5nLg0KDQo+IFNlY3Rpb24gMy4xDQo+IA0KPiBJcyB0aGVyZSBhbnkgcmlzayBvZiBj b2xsaXNpb24gaW4gZXZlbnQgc3RyZWFtIG5hbWVzIGZyb20gdmVuZG9yLXNwZWNpZmljDQo+IHN0 cmVhbXM/ICAoV2UgZG9uJ3Qgc2VlbSB0byBjcmVhdGUgYW4gSUFOQSByZWdpc3RyeSBmb3IgdGhl bSwgZm9yIGV4YW1wbGUuKQ0KDQpJbiB0aGVvcnkgeWVzLiAgQnV0IGl0IGhhcyBub3QgcHJvdmVu IHRvIGJlIGFuIGlzc3VlIHdpdGggUkZDLTUyNzcgc3RyZWFtcywgc28gaXQgZG9lc24ndCBzZWVt IHdvcnRoIGl0IHRvIGRvIHNvbWV0aGluZyBuZXcgbm93LiAgIFNvIGluIHRoaXMgZG9jdW1lbnQs IHdlIGhhdmUgb25lIElFVEYgc3RyZWFtICJORVRDT05GIiBkZWZpbmVkIGluIFNlY3Rpb24gMi4x LiAgSG9wZWZ1bGx5IGl0IGlzIGVub3VnaCB0byBoYXJkLWNvZGUgdGhpcy4gICBXZSBjYW4gYWx3 YXlzIHJldmlzaXQgaWYgSUVURiBncm91cHMgd2FudCB0byBzdGFydCBkZWZpbmluZyBzdHJlYW1z DQoNCj4gU2VjdGlvbiA0DQo+IA0KPiAgICBpZGVudGl0eSBzdWJzY3JpcHRpb24tc3VzcGVuZGVk LXJlYXNvbiB7DQo+ICAgICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICAiUHJvYmxlbSBjb25kaXRp b24gY29tbXVuaWNhdGVkIHRvIGEgcmVjZWl2ZXIgYXMgcGFydCBvZiBhDQo+ICAgICAgICAnc3Vi c2NyaXB0aW9uLXRlcm1pbmF0ZWQnIG5vdGlmaWNhdGlvbi4iOw0KPiAgICB9DQo+IA0KPiAgICBp ZGVudGl0eSBzdWJzY3JpcHRpb24tdGVybWluYXRlZC1yZWFzb24gew0KPiAgICAgICBkZXNjcmlw dGlvbg0KPiAgICAgICAgIlByb2JsZW0gY29uZGl0aW9uIGNvbW11bmljYXRlZCB0byBhIHJlY2Vp dmVyIGFzIHBhcnQgb2YgYQ0KPiAgICAgICAgJ3N1YnNjcmlwdGlvbi10ZXJtaW5hdGVkJyBub3Rp ZmljYXRpb24uIjsNCj4gICAgfQ0KPiANCj4gQXJlIHRoZXNlIGRlc2NyaXB0aW9ucyBzdXBwb3Nl ZCB0byBiZSB0aGUgc2FtZT8NCg0KR29vZCBjYXRjaC4gICBGaXhlZCB0aGUgJ3N1YnNjcmlwdGlv bi1zdXNwZW5kZWQnIGRlc2NyaXB0aW9uLg0KIA0KPiAgICBpZGVudGl0eSBjb25maWd1cmFibGUt ZW5jb2Rpbmcgew0KPiAgICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICAiSWYgYSB0cmFuc3BvcnQg aWRlbnRpdHkgZGVyaXZlcyBmcm9tIHRoaXMgaWRlbnRpdHksIGl0IG1lYW5zDQo+ICAgICAgICAg dGhhdCBpdCBzdXBwb3J0cyBjb25maWd1cmFibGUgZW5jb2RpbmdzLiAgQW4gZXhhbXBsZSBvZiBh IFsuLi5dDQo+IA0KPiBJcyBpdCBpbnRlbmRlZCB0aGF0IHN1Y2ggZnV0dXJlIHRyYW5zcG9ydHMg KG9yIGZ1dHVyZSBlbmNvZGluZ3M/KSB3aWxsIGRlcml2ZSBmcm9tDQo+IGJvdGggdGhpcyBhbmQg dGhlIG5vcm1hbCBiYXNlIGlkZW50aXR5IChpLmUuLCAidHJhbnNwb3J0Iik/DQo+IEkgZ3Vlc3Mg SSdtIGFza2luZyB3aHkgdGhpcyBpZGVudGl0eSBkb2VzIG5vdCBkZXJpdmUgZnJvbSB0aGUgY29y cmVzcG9uZGluZyBiYXNlLA0KPiBidXQgdGhhdCdzIGp1c3QgYSBzdHlsZSBxdWVzdGlvbiBhbmQg bm90IHJlYWxseSBhIHByb3RvY29sIG1hdHRlciwgbWFraW5nIHRoaXMNCj4gcXVlc3Rpb24gYSBz aWRlIG5vdGUuDQoNClllcy4gIEZ1dHVyZSBpZGVudGl0aWVzIGNhbiBkZXJpdmUgZnJvbSBjb25m aWd1cmFibGUtZW5jb2RpbmcNCg0KPiAgICAgIGxlYWYgd2VpZ2h0aW5nIHsNCj4gICAgICAgIGlm LWZlYXR1cmUgInFvcyI7DQo+ICAgICAgICB0eXBlIHVpbnQ4IHsNCj4gICAgICAgICAgIHJhbmdl ICIwIC4uIDI1NSI7DQo+ICAgICAgICB9DQo+ICAgICAgICBkZXNjcmlwdGlvbg0KPiAgICAgICAg ICAiUmVsYXRpdmUgd2VpZ2h0aW5nIGZvciBhIHN1YnNjcmlwdGlvbi4gQWxsb3dzIGFuIHVuZGVy bHlpbmcNCj4gICAgICAgICAgIHRyYW5zcG9ydCBsYXllciBwZXJmb3JtIGluZm9ybWVkIGxvYWQg YmFsYW5jZSBhbGxvY2F0aW9ucw0KPiAgICAgICAgICAgYmV0d2VlbiB2YXJpb3VzIHN1YnNjcmlw dGlvbnMiOw0KPiAgICAgICAgcmVmZXJlbmNlDQo+ICAgICAgICAgICJSRkMtNzU0MCwgc2VjdGlv biA1LjMuMiI7DQo+IA0KPiBEbyB3ZSB3YW50IHRvIGNoYXNlIHRoZSByZWZlcmVuY2UgZm9yIHJl YWRlcnMgYW5kIHNheSB0aGF0IGxhcmdlciB3ZWlnaHRzIGdldA0KPiBtb3JlIHJlc291cmNlcz8N Cg0KSSBwdXQgaW4gIkxhcmdlciB3ZWlnaHRzIGdldCBtb3JlIHJlc291cmNlcy4iIGFzIHNlbnRl bmNlIHR3byBvZiB0aGUgZGVzY3JpcHRpb24uDQoNCj4gICAgICBsZWFmIGVuY29kaW5nIHsNCj4g ICAgICAgIHdoZW4gJ25vdCguLi90cmFuc3BvcnQpIG9yIGRlcml2ZWQtZnJvbSguLi90cmFuc3Bv cnQsDQo+ICAgICAgICAic246Y29uZmlndXJhYmxlLWVuY29kaW5nIiknOw0KPiAgICAgICAgdHlw ZSBlbmNvZGluZzsNCj4gICAgICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICAgICJUaGUgdHlwZSBv ZiBlbmNvZGluZyBmb3Igbm90aWZpY2F0aW9uIG1lc3NhZ2VzLiAgIEZvciBhDQo+ICAgICAgICAg IGR5bmFtaWMgc3Vic2NyaXB0aW9uLCBpZiBub3QgaW5jbHVkZWQgYXMgcGFydCBvZiBhbiBlc3Rh Ymxpc2gtDQo+ICAgICAgICAgIHN1YnNjcmlwdGlvbiBSUEMsIHRoZSBlbmNvZGluZyB3aWxsIGJl IHBvcHVsYXRlZCB3aXRoIHRoZQ0KPiAgICAgICAgICBlbmNvZGluZyB1c2VkIGJ5IHRoYXQgUlBD LiAgRm9yIGEgY29uZmlndXJlZCBzdWJzY3JpcHRpb24sIGlmDQo+ICAgICAgICAgIG5vdCBleHBs aWNpdGx5IGNvbmZpZ3VyZWQgdGhlIGVuY29kaW5nIHdpdGggYmUgdGhlIGRlZmF1bHQNCj4gICAg ICAgICAgZW5jb2RpbmcgZm9yIGFuIHVuZGVybHlpbmcgdHJhbnNwb3J0LiI7DQo+IA0KPiBXaGVy ZSBpcyB0aGUgZGVmYXVsdCBlbmNvZGluZyBmb3IgYW4gdW5kZXJseWluZyB0cmFuc3BvcnQgc3Bl Y2lmaWVkPw0KPiBTZWN0aW9uIDUuMyBkb2VzIG5vdCBzZWVtIHRvIHNheSB0aGF0IGEgdHJhbnNw b3J0IHNwZWNpZmljYXRpb24gbXVzdCBwcm92aWRlIHRoaXMNCj4gaW5mb3JtYXRpb24sIG5vciBk b2VzIFNlY3Rpb24gMS4zICh3aGljaCBtZW50aW9ucyB0aGF0IHRyYW5zcG9ydCBzcGVjaWZpY2F0 aW9ucw0KPiBtdXN0IGRldGFpbCB0aGUgbGlmZWN5Y2xlIG9mIGR5bmFtaWMgc3Vic2NyaXB0aW9u cyksIG5vciBkb2VzIFNlY3Rpb24gMi41LjcgKHRoYXQNCj4gZGlzY3Vzc2VzIHRoZSBuZWVkIGZv ciBhIHNlcGFyYXRlIG1vZGVsIGF1Z21lbnRpbmcNCj4gL3N1YnNjcmlwdGlvbnMvc3Vic2NyaXB0 aW9uL3JlY2VpdmVycy9yZWNlaXZlcg0KPiB0byBwcm92aWRlIHRyYW5zcG9ydCBkZXRhaWxzKS4N Cg0KRm9yIG1hbnkgdHJhbnNwb3J0cywgdGhlIGVuY29kaW5nIGlzIHJlZHVuZGFudCBpbmZvcm1h dGlvbi4gIFRoZSByZWFzb24gaXMgdGhhdCB0cmFuc3BvcnQgUkZDcyB0aGVtc2VsdmVzIGRlZmlu ZSBzdXBwb3J0ZWQgZW5jb2RpbmdzIChlLmcuLCAiTkVUQ09ORiArIFhNTCIgLCAiUkVTVENPTkYg KyBKU09OIikuICBBbmQgV0cgbWVtYmVycyB3aG8gYnVpbHQgdGhvc2UgdHJhbnNwb3J0IFJGQ3Mg ZGlkIG5vdCB3YW50IHRvIGFsbG93IG9wZXJhdG9ycyB0byBtaXNjb25maWd1cmUgYW55dGhpbmcg aGVyZS4gIChBcyBhbiBhc2lkZSwgdGhpcyBkZXNpcmUgdG8gc2lnbmlmaWNhbnRseSByZWR1Y2Ug dGhlIG9wcG9ydHVuaXR5IGZvciBtaXNjb25maWd1cmF0aW9uIGlzIHdoYXQgZHJvdmUgdGhlIGlu dGVyZXN0aW5nICd3aGVuJyBzdGF0ZW1lbnQgYWJvdmUuKQ0KDQpCdXQgZW5jb2RpbmdzIGNhbiB2 YXJ5LiAgVGhpcyBpcyB0aGUgcHVycG9zZSBvZiB0aGUgaWRlbnRpdHkgImNvbmZpZ3VyYWJsZS1l bmNvZGluZyIgaW4gdGhlIFlBTkcgbW9kZWwuICAgQW5kIHRoaXMgaWRlbnRpdHkgZG9lcyBzYXkg dGhhdCAiRnVydGhlciBkZXRhaWxzIGZvciBhbnkgc3BlY2lmaWMgY29uZmlndXJhYmxlIGVuY29k aW5nIHdvdWxkIGJlIGV4cGxvcmVkIGluIGEgdHJhbnNwb3J0IGRvY3VtZW50IGJhc2VkIG9uIHRo aXMgc3BlY2lmaWNhdGlvbi4iICBJIGd1ZXNzIHRoaXMgaW5mb3JtYXRpb24gY291bGQgYmUgcmVw ZWF0ZWQgaW4gU2VjdGlvbiA1LjMgaWYgbmVjZXNzYXJ5Lg0KDQo+ICAgICAgICBjaG9pY2Ugbm90 aWZpY2F0aW9uLW1lc3NhZ2Utb3JpZ2luIHsNCj4gICAgICAgICAgaWYtZmVhdHVyZSAiY29uZmln dXJlZCI7DQo+ICAgICAgICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICAgICAgIklkZW50aWZpZXMg dGhlIGVncmVzcyBpbnRlcmZhY2Ugb24gdGhlIHB1Ymxpc2hlciBmcm9tIHdoaWNoDQo+ICAgICAg ICAgICAgIG5vdGlmaWNhdGlvbiBtZXNzYWdlcyBhcmUgdG8gYmUgc2VudC4iOw0KPiANCj4gbml0 OiBnaXZlbiB0aGUgYWRkcmVzcy1vcmlnaW5hdGVkIGNhc2UsIHBlcmhhcHMgInRoZSBlZ3Jlc3Mg aW50ZXJmYWNlIg0KPiBpcyBub3QgcXVpdGUgY29ycmVjdCBhbnltb3JlLg0KDQpFdmVyeSBhbHRl cm5hdGl2ZSBJIGNvbWUgdXAgd2l0aCBzZWVtcyBtb3JlIHByb2JsZW1hdGljLiAgIEkgYmVsaWV2 ZSByZWFkZXJzIHNob3VsZCBiZSBhYmxlIHRvIHVuZGVyc3RhbmQgYmFzZWQgb24gdGhlIGNhc2Vz IGJlbG93Lg0KIA0KPiAgICAgICAgICAgICAgICBlbnVtIGNvbm5lY3Rpbmcgew0KPiAgICAgICAg ICAgICAgICAgIHZhbHVlIDM7DQo+ICAgICAgICAgICAgICAgICAgaWYtZmVhdHVyZSAiY29uZmln dXJlZCI7DQo+ICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCj4gICAgICAgICAgICAgICAg ICAgICJBIHN1YnNjcmlwdGlvbiBoYXMgYmVlbiBjb25maWd1cmVkLCBidXQgYQ0KPiAgICAgICAg ICAgICAgICAgICAgJ3N1YnNjcmlwdGlvbi1zdGFydGVkJyBzdWJzY3JpcHRpb24gc3RhdGUgY2hh bmdlDQo+ICAgICAgICAgICAgICAgICAgICBub3RpZmljYXRpb24gbmVlZHMgdG8gYmUgc3VjY2Vz c2Z1bGx5IHJlY2VpdmVkIGJlZm9yZQ0KPiAgICAgICAgICAgICAgICAgICAgbm90aWZpY2F0aW9u IG1lc3NhZ2VzIGFyZSBzZW50Lg0KPiANCj4gbml0OiBzdWNjZXNzZnVsIHJlY2VpcHQgaGFwcGVu cyBvbiB0aGUgcmVjZWl2ZXIgYnV0IHNlbmRpbmcgaGFwcGVucyBvbiB0aGUNCj4gcHVibGlzaGVy LCBzbyB0aGVyZSdzIGEgYml0IG9mIGEgbWlzbWF0Y2ggaW4gdGhlIHNlbnRlbmNlIHN1YmplY3Qg aGVyZS4gIFBlcmhhcHMNCj4gd2UgY291bGQgdGFsayBhYm91dCAic3VjY2Vzc2Z1bGx5IHNlbnQi IHN0YXRlLWNoYW5nZXMgdG8gcmVzb2x2ZSB0aGluZ3MuDQoNClRoaXMgd29yZGluZyBpcyBhcyBp bnRlbmRlZC4gIEJhc2ljYWxseSBpdCBpcyBoaWdobHkgZGVzaXJhYmxlIGZvciBjb25maWd1cmVk IHJlY2VpdmVycyB3aWxsIG5lZWQgdG8gYWNrbm93bGVkZ2VtZW50IG9mIHN1Y2Nlc3NmdWwgcmVj ZWlwdCBvZiBhICJzdWJzY3JpcHRpb24tc3RhcnRlZCIgYmVmb3JlIHNlbmRpbmcgZXZlbnQgcmVj b3Jkcy4gIFRoaXMgaGVscHMgcHJldmVudCBERE9TIGF0dGFja3MuICBUaGUgbWVjaGFuaXNtIGZv ciBnYWluaW5nIGFuIGFja25vd2xlZGdlbWVudCB2YXJpZXMgYnkgdHJhbnNwb3J0LiAgQXMgYW4g ZXhhbXBsZSBvZiB3aGF0IHdlIGhhdmUgYmVlbiB0aGlua2luZyBhYm91dCBoZXJlLCBzZWUNCg0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rj b25mLW5vdGlmLzA0LyAgIFNlY3Rpb24gMy4xLjIgDQpIb3BlZnVsbHkgdGhpcyB0eXBlIG9mIG1l Y2hhbmlzbSB3aWxsIGJlIHJldml2ZWQgaW4gZnV0dXJlIGRyYWZ0cy4NCg0KPiAgICAgICAgICAg ICAgY29uZmlnIGZhbHNlOw0KPiAgICAgICAgICAgICAgbWFuZGF0b3J5IHRydWU7DQo+ICAgICAg ICAgICAgICBkZXNjcmlwdGlvbg0KPiAgICAgICAgICAgICAgICAiU3BlY2lmaWVzIHRoZSBzdGF0 ZSBvZiBhIHN1YnNjcmlwdGlvbiBmcm9tIHRoZQ0KPiAgICAgICAgICAgICAgICBwZXJzcGVjdGl2 ZSBvZiBhIHBhcnRpY3VsYXIgcmVjZWl2ZXIuICBXaXRoIHRoaXMgaW5mbyBpdA0KPiAgICAgICAg ICAgICAgICBpcyBwb3NzaWJsZSB0byBkZXRlcm1pbmUgd2hldGhlciBhIHN1YnNjcmliZXIgaXMN Cj4gICAgICAgICAgICAgICAgY3VycmVudGx5IGdlbmVyYXRpbmcgbm90aWZpY2F0aW9uIG1lc3Nh Z2VzIGludGVuZGVkIGZvcg0KPiAgICAgICAgICAgICAgICB0aGF0IHJlY2VpdmVyLiI7DQo+IA0K PiBuaXQ6IGlzIGl0IHRoZSBzdWJzY3JpYmVyIHRoYXQgaXMgZ2VuZXJhdGluZyBtZXNzYWdlcyBv ciB0aGUgcHVibGlzaGVyPw0KDQpHb29kIGNhdGNoLiAgQ2hhbmdlZCB0byBwdWJsaXNoZXIuDQog DQo+IFNlY3Rpb24gNS4zDQo+IA0KPiAgICBBIHNlY3VyZSB0cmFuc3BvcnQgaXMgaGlnaGx5IHJl Y29tbWVuZGVkIGFuZCB0aGUgcHVibGlzaGVyIE1VU1QNCj4gICAgZW5zdXJlIHRoYXQgdGhlIHJl Y2VpdmVyIGhhcyBzdWZmaWNpZW50IGF1dGhvcml6YXRpb24gdG8gcGVyZm9ybSB0aGUNCj4gICAg ZnVuY3Rpb24gdGhleSBhcmUgcmVxdWVzdGluZyBhZ2FpbnN0IHRoZSBzcGVjaWZpYyBzdWJzZXQg b2YgY29udGVudA0KPiAgICBpbnZvbHZlZC4NCj4gDQo+ICJzZWN1cmUgdHJhbnNwb3J0IiB1c3Vh bGx5IG1lYW5zIHRoYXQgaXQgcHJvdmlkZXMgbWVzc2FnZSBjb25maWRlbnRpYWxpdHksDQo+IGlu dGVncml0eSBwcm90ZWN0aW9uLCBhbmQgc291cmNlIGF1dGhlbnRpY2l0eSAoYWtpbiB0byB0aGUg bXV0dWFsIGF1dGhlbnRpY2F0aW9uKS4NCj4gVGhpcyBpcyBxdWFsaXRhdGl2ZWx5IGRpZmZlcmVu dCBmcm9tIGltcGxlbWVudGluZyBhdXRob3JpemF0aW9uIGNoZWNrcywgYW5kIGl0J3MNCj4gc3Vy cHJpc2luZyB0byBzZWUgdGhlbSBzcXVhc2hlZCBpbnRvIHRoZSBzYW1lIHNlbnRlbmNlLg0KDQpU d2Vha2VkIHRvICJBIHNlY3VyZSB0cmFuc3BvcnQgaXMgaGlnaGx5IHJlY29tbWVuZGVkLiAgQmV5 b25kIHRoaXMsIHRoZSBwdWJsaXNoZXIgTVVTVCIuDQoNCj4gRG8gd2Ugd2FudCB0byBzYXkgYW55 dGhpbmcgYWJvdXQgZGlzY292ZXJ5IGZvciBzdXBwb3J0IG9mIG5ldyB0cmFuc3BvcnRzLCBhbmQN Cj4gd2hhdCB3b3JrZmxvdyB3b3VsZCBiZSB1c2VkIHRvIG5lZ290aWF0ZSB0aGUgdXNlIG9mIGEg bmV3IHRyYW5zcG9ydD8NCg0KTm90IGF0IHRoaXMgcG9pbnQuICANCg0KPiBTZWN0aW9uIDUuNA0K PiANCj4gSSBjYW4gdGhpbmsgb2YgYSBjb3VwbGUgb3RoZXIgY29uc2lkZXJhdGlvbnMgdG8gbWVu dGlvbiBoZXJlOg0KPiANCj4gLSBVc2luZyBETlMgbmFtZXMgZm9yIHJlY2VpdmVyICJuYW1lIiBs b29rdXAgY2FuIGNhdXNlIHNpdHVhdGlvbnMgd2hlcmUNCj4gICB0aGUgbmFtZSByZXNvbHZlcyBk aWZmZXJlbnRseSBvbiB0aGUgcHVibGlzaGVyIGFuZCBzdWJzY3JpYmVyLCBzbyB0aGUNCj4gICBy ZWNpcGllbnQgd291bGQgYmUgZGlmZmVyZW50IHRoYW4gZXhwZWN0ZWQuDQo+IA0KPiAtIFVzaW5n IHRoZSBwdWJsaXNoZXIncyBib290IHRpbWUgZm9yIGRlZHVwbGljYXRpb24gcHJvdGVjdGlvbiBv bg0KPiAgIHJlcGxheWVkIG1lc3NhZ2VzIGludHJvZHVjZXMgYSBkZXBlbmRlbmN5IG9uIGFjY3Vy YXRlIHRpbWUuICBXZSBkb24ndA0KPiAgIGhhdmUgYSBncmVhdCBzZWN1cmUgdGltZSBzdG9yeSBh dCBwcmVzZW50LCBzbyB0aGlzIGlzIG1vcmUgb2YgYQ0KPiAgICJiZXdhcmUgb2YgcmlzayIgc2l0 dWF0aW9uIHRoYW4gc29tZXRoaW5nIHdlIGNhbiBtaXRpZ2F0ZSwgYnV0IGl0IGRvZXMNCj4gICBz ZWVtIHRoYXQgYW4gYXR0YWNrZXIgdGhhdCBjb3VsZCAoZS5nLikgc3Bvb2YgdGhlIE5UUCB0cmFm ZmljIHRvIHRoZQ0KPiAgIHB1Ymxpc2hlciBvbiBib290IGNvdWxkIGNhdXNlIGl0IHRvIHNlbmQg ZHVwbGljYXRlIG5vdGlmaWNhdGlvbnMgdG8NCj4gICByZWNpcGllbnRzIHRoYXQgcmVxdWVzdGVk IGhpc3RvcmljYWwgZGF0YS4NCg0KSSB0d2Vha2VkIGFuZCBpbnNlcnRlZCB0aGUgdHdvIHBhcmFn cmFwaHMgZnJvbSB5b3UuLi4NCg0KIlVzaW5nIEROUyBuYW1lcyBmb3IgY29uZmlndXJlZCBzdWJz Y3JpcHRpb24gcmVjZWl2ZXIgIm5hbWUiIGxvb2t1cCBjYW4gY2F1c2Ugc2l0dWF0aW9ucyB3aGVy ZSB0aGUgbmFtZSByZXNvbHZlcyB1bmV4cGVjdGVkbHkgZGlmZmVyZW50bHkgb24gdGhlIHB1Ymxp c2hlciwgc28gdGhlIHJlY2lwaWVudCB3b3VsZCBiZSBkaWZmZXJlbnQgdGhhbiBleHBlY3RlZC4i DQogDQoiVXNpbmcgdGhlIHB1Ymxpc2hlcidzIGJvb3QgdGltZSBmb3IgZGVkdXBsaWNhdGlvbiBw cm90ZWN0aW9uIG9uIHJlcGxheWVkIG1lc3NhZ2VzIGludHJvZHVjZXMgYSBkZXBlbmRlbmN5IG9u IGFjY3VyYXRlIHRpbWUuIg0KDQoNCj4gU29tZSBvdGhlciBjb21tZW50cyBvbiB3aGF0J3MgYWxy ZWFkeSB0aGVyZSAod2hpY2ggaXMgcHJldHR5IGdvb2Q7IHRoYW5rcyBmb3INCj4gaXQhKSBmb2xs b3cuDQo+IA0KPiAgICBDb250YWluZXI6ICIvZmlsdGVycyINCj4gDQo+ICAgIG8gICJzdHJlYW0t c3VidHJlZS1maWx0ZXIiOiB1cGRhdGluZyBhIGZpbHRlciBjb3VsZCBpbmNyZWFzZSB0aGUNCj4g ICAgICAgY29tcHV0YXRpb25hbCBjb21wbGV4aXR5IG9mIGFsbCByZWZlcmVuY2luZyBzdWJzY3Jp cHRpb25zLg0KPiANCj4gICAgbyAgInN0cmVhbS14cGF0aC1maWx0ZXIiOiB1cGRhdGluZyBhIGZp bHRlciBjb3VsZCBpbmNyZWFzZSB0aGUNCj4gICAgICAgY29tcHV0YXRpb25hbCBjb21wbGV4aXR5 IG9mIGFsbCByZWZlcmVuY2luZyBzdWJzY3JpcHRpb25zLg0KPiANCj4gRG8gd2Ugd2FudCB0byBz YXkgYW55dGhpbmcgYWJvdXQgbW9kaWZ5aW5nIGVpdGhlciBvZiB0aGVzZSBjYXVzaW5nIHRoZSBz ZXQgb2YNCj4gbm90aWZpY2F0aW9ucyBkZWxpdmVyZWQgdG8gcmVjaXBpZW50cyB0byBzaHJpbmsg KG9yIGJlY29tZSB1bm1hbmFnZWFibHkgbGFyZ2UpPw0KPiBJIGd1ZXNzIGl0IG1heSBub3QgYmUg bmVjZXNzYXJ5LCBzaW5jZSB0aGUgcmVjaXBpZW50IGdldHMgYSBub3RpZmljYXRpb24gYWJvdXQg dGhlDQo+IG1vZGlmaWNhdGlvbiB0aGF0IGluY2x1ZGVzIHRoZSBkZXRhaWxzIG9mIHRoZSBmaWx0 ZXIuDQoNClllcywgdGhhdCB3YXMgdGhlIHRoaW5raW5nLg0KDQo+ICAgIENvbnRhaW5lcjogIi9z dWJzY3JpcHRpb25zIg0KPiANCj4gICAgbyAgImV4Y2x1ZGVkLWV2ZW50LXJlY29yZHMiOiBsZWFm IGNhbiBwcm92aWRlIGluZm9ybWF0aW9uIGFib3V0DQo+ICAgICAgIGZpbHRlcmVkIGV2ZW50IHJl Y29yZHMuICBBIG5ldHdvcmsgb3BlcmF0b3Igc2hvdWxkIGhhdmUNCj4gICAgICAgcGVybWlzc2lv bnMgdG8ga25vdyBhYm91dCBzdWNoIGZpbHRlcmluZy4NCj4gDQo+IFRvIGJlIGNsZWFyLCB0aGlz IGlzIGV2ZW50IHJlY29yZHMgZmlsdGVyZWQgZWl0aGVyIHZpYSBleHBsaWNpdCBmaWx0ZXIgb3Ig dmlhIGFjY2Vzcw0KPiBjb250cm9sIHJlc3RyaWN0aW9ucy4gDQoNClllcy4gIA0KDQo+IFNwZWNp ZmljYWxseSwgaXQgY2FuIGFsbG93IGEgcmVjZWl2ZXIgdG8gbGVhcm4gdGhhdCB0aGVyZSBleGlz dHMNCj4gYWNjZXNzIGNvbnRyb2xzIHRoYXQgZGVueSBpdCBhY2Nlc3MgdG8gc29tZSBkYXRhLCBp biB0aGUgY2FzZSB3aGVuIHRoZXkgZGlkIG5vdA0KPiBhcHBseSBhbnkgZmlsdGVyaW5nIHJ1bGVz IGV4cGxpY2l0bHkuICANCg0KWWVzLiAgDQoNCj5UaGlzIHBvdGVudGlhbCBmb3IgaW5mb3JtYXRp b24gbGVha2FnZSAob2YgdGhlDQo+IGV4aXN0ZW5jZSBvZg0KPiBBQ0xzKSBzaG91bGQgYmUgbWVu dGlvbmVkIGV4cGxpY2l0bHkuDQoNCkFkZGVkIHRoZSBzZW50ZW5jZTogIkltcHJvcGVyIGNvbmZp Z3VyYXRpb24gY291bGQgcHJvdmlkZSBhIHJlY2VpdmVyIHdpdGggaW5mb3JtYXRpb24gbGVha2Fn ZSBjb25zaXN0aW5nIG9mIHRoZSBkcm9wcGluZyBvZiBldmVudCByZWNvcmRzLiINCg0KDQo+IEFw cGVuZGl4IEENCj4gDQo+IFRoaXMgZXhhbXBsZSB0cmFuc3BvcnQgbW9kdWxlIGRvZXMgbm90IHNw ZWNpZnkgdGhlIGxpZmUgY3ljbGUgb2YgZHluYW1pYw0KPiBzdWJzY3JpcHRpb25zIHBlciBTZWN0 aW9uIDEuMywgYW5kIGEgY291cGxlIG90aGVyIHRoaW5ncyByZXF1aXJlZCBmcm9tIGENCj4gdHJh bnNwb3J0IG1vZHVsZSBzcGVjaWZpY2F0aW9uLiAgUGVyaGFwcyB3ZSBhcmUgb2theSBjbGFpbWlu ZyB0aGF0IHNpbmNlIHRoaXMgaXMNCj4ganVzdCBhbiBleGFtcGxlIFlBTkcgbW9kZWwgYW5kIG5v dCBhIGZ1bGwgdHJhbnNwb3J0IGV4YW1wbGUsIHRoZSBvbWlzc2lvbiBpcw0KPiBva2F5LCBidXQg aXQgbWF5IGJlIHdvcnRoIG1lbnRpb25pbmcgdGhlIG9taXNzaW9uIGZvciBjbGFyaXR5Lg0KDQpJ IGFkZGVkIGFzIHRoZSBzZWNvbmQgc2VudGVuY2UNCiIgVGhpcyBleGFtcGxlIGlzIG5vdCBpbnRl bmRlZCB0byBiZSBhIGNvbXBsZXRlIHRyYW5zcG9ydCBtb2RlbC4iDQoNClRoYW5rcyBhZ2FpbiBm b3IgdGhlIHJldmlldywgaXQgd2FzIGV4Y2VsbGVudGx5IGRvbmUuDQoNCkVyaWMNCg== From nobody Tue Apr 30 23:35:32 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63171200E0; Tue, 30 Apr 2019 23:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=b/94fhZz; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=mZsT65Mf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fv7ri2bcCuZP; Tue, 30 Apr 2019 23:35:20 -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 363EE1200EB; Tue, 30 Apr 2019 23:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8470; q=dns/txt; s=iport; t=1556692520; x=1557902120; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TtzUbmvqRxf5PoY4Y4Y7uN3Z9Ax2ZKgwq/xwU0Kgd3w=; b=b/94fhZze/nEDX7NBvRFf1bUht9e3TNeaeeohE2HB+Me/KWrluNGo3Q1 bH2t6qHC7SGgCNHH6ydusBVDuLd2532HhIrYegLkSdLBg553lUw3hGAwy qgMj/yOP1k+e9DmKLbrlNdA0Lt7IsynVH1CTHeRT1xADm32QullqWHNZb k=; IronPort-PHdr: =?us-ascii?q?9a23=3Ay32QHBSe3APzIhlweFCqakqdr9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBdfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOiEkDcJJV1JN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BsAADaPclc/4QNJK1mGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBVAMBAQELAYE9KScDaVUgBAsohBCDRwOPDoJXlyKBQoEQA1QOAQE?= =?us-ascii?q?lCIRAAheGGyM3Bg4BAwEBBAEBAgECbRwMhUoBAQEDARIREQwBATUCAQ8CAQg?= =?us-ascii?q?SAwUCCR0CAgIwFQIDCwIEAQ0FIoI1SwGBagMODwECDKJTAoE1iF9xgS+CeQE?= =?us-ascii?q?BBYEyARNBgwEYgg4DBoELJwGLSxeBQD+BEScfgkw+gmECAQIBgSoBAREBDye?= =?us-ascii?q?CczKCJop8DgSCN4xDjCNlCQKCCYYXhC2HehuCDYY3jG+DCokHhSWBII4TAgQ?= =?us-ascii?q?CBAUCDgEBBYFlImVYEQhwFWUBgg0BM4EYdwwXFIM4hRSFP3IBgSiPfwENFwe?= =?us-ascii?q?CJQEB?= X-IronPort-AV: E=Sophos;i="5.60,416,1549929600"; d="scan'208";a="270626308" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 May 2019 06:35:17 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x416ZHDs029705 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 May 2019 06:35:17 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 1 May 2019 01:35:17 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 1 May 2019 01:35:16 -0500 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 1 May 2019 01:35:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TtzUbmvqRxf5PoY4Y4Y7uN3Z9Ax2ZKgwq/xwU0Kgd3w=; b=mZsT65MflQHqZCJuj7HI/37PmT8dWvV8ev9EN84ZYkMyglp0+ItSOFobGzCxUXMukMJzxKsi/R5vuenpes5P68U+HdwiFPsNSL9NXmE4JFSo7piqF/DEjmEBXUGBy6cGvFKs99t8P+gF7qKFTe42IBaov1hLdtdcro6wh5A2wTU= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB4141.namprd11.prod.outlook.com (20.179.150.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.14; Wed, 1 May 2019 06:35:14 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::3822:32af:5c31:b48f]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::3822:32af:5c31:b48f%3]) with mapi id 15.20.1835.010; Wed, 1 May 2019 06:35:13 +0000 From: "Eric Vyncke (evyncke)" To: "Eric Voit (evoit)" , The IESG CC: "draft-ietf-netconf-subscribed-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtbmV0?= =?utf-8?B?Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMtMjQ6ICh3aXRoIENPTU1F?= =?utf-8?Q?NT)?= Thread-Index: AQHU/4b2whg08n3Vakm6if6ntmzZoaZVT0zAgACjOwA= Date: Wed, 1 May 2019 06:35:13 +0000 Message-ID: <8CA8A02E-311E-4BC8-B565-21349FA298EC@cisco.com> References: <155665081164.7668.3304106941009307050.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.18.0.190414 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:e051:9a9d:c67a:3548] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 10f1d89e-5020-4ac8-cf11-08d6cdff2ae6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR11MB4141; x-ms-traffictypediagnostic: MN2PR11MB4141: x-ms-exchange-purlcount: 4 x-ld-processed: 5ae1af62-9505-4097-a69a-c1553ef7840e,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00246AB517 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(366004)(39860400002)(376002)(346002)(189003)(199004)(51914003)(6512007)(66574012)(966005)(53936002)(15650500001)(305945005)(68736007)(478600001)(316002)(86362001)(14454004)(4326008)(71200400001)(82746002)(6486002)(83716004)(6246003)(14444005)(6306002)(7736002)(71190400001)(256004)(36756003)(229853002)(446003)(91956017)(66946007)(6116002)(64756008)(476003)(81156014)(8936002)(81166006)(5660300002)(6436002)(66446008)(66556008)(2616005)(11346002)(186003)(76176011)(99286004)(25786009)(58126008)(76116006)(73956011)(486006)(54906003)(33656002)(66476007)(102836004)(224303003)(46003)(6506007)(110136005)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4141; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: r1NslcQMexc899EHwFQQ+nNvIBt4nGhRFStcGWEa2t9B27ZjKtOYP9IE15StyIXo0TiTG/eIAU+whwHdq0ZJBNV8QTLL/lezDDojHRgWkRMJHarGuG5SDvU6HyIZ8t8/VbSR0O+0CVnYrsGEejO/w4ZEDQj0QuJ1XFJS4YJjQdREjdOagXQeUOlsY6yIF5r8gGhF1ayDw4KABPZey3d8jt6+DvXCxfzv24gHRlsQ+tRkrFQXMTjPrv7T8Igh7iD+OqI9f4u5v7LZ25pWB7aB9uCCviPrd0bQjbWdFOZ2t8CORIVQJyzIxwyk78VcfZ1Pu3kkQaC8wY5FJ5cMhxFc96XwGi7NNN9yb6b65iVkPjn5aW4fby3DztjMBKyJEo2czm2cbhHL5iKWnAnsmRSygP+qkUB5i58Gm5nu0YekpRU= Content-Type: text/plain; charset="utf-8" Content-ID: <72D84F30E561B845A84662CDDF2CA308@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 10f1d89e-5020-4ac8-cf11-08d6cdff2ae6 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 May 2019 06:35:13.7676 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4141 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [netconf] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-netconf-subscribed-notifications-24=3A_=28with_COMMENT=29?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 06:35:23 -0000 w4lyaWMNCg0KVGhhbmsgeW91IGZvciB5b3VyIHJlcGxpZXMgdG8gbXkgY29tbWVudHMuIEkgYWdy ZWUgd2l0aCB0aGUgcmVwbGllcyBleGNlcHQgb24gQzYgYnV0IEkgYW0gdHJ1c3RpbmcgeW91ciBq dWRnZW1lbnQgb24gdGhpcyBvbmUuDQoNCkxldCdzIGdvIGFuZCBkbyBub3QgZGVsYXkgdGhlIHB1 YmxpY2F0aW9uIGFueW1vcmUgOy0pDQoNCi3DqXJpYw0KDQrvu79PbiAwMS8wNS8yMDE5LCAwMToy OSwgIkVyaWMgVm9pdCAoZXZvaXQpIiA8ZXZvaXRAY2lzY28uY29tPiB3cm90ZToNCg0KICAgIEhp IMOJcmljLA0KICAgIA0KICAgIFRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLiAgVGhvdWdodHMgaW4t bGluZS4uLg0KICAgIA0KICAgID4gRnJvbTogw4lyaWMgVnluY2tlLCBBcHJpbCAzMCwgMjAxOSAz OjAwIFBNDQogICAgPg0KICAgID4gw4lyaWMgVnluY2tlIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dp bmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KICAgID4gZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmli ZWQtbm90aWZpY2F0aW9ucy0yNDogTm8gT2JqZWN0aW9uDQogICAgPg0KICAgID4gV2hlbiByZXNw b25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8g YWxsIGVtYWlsDQogICAgPiBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5l cy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkNCiAgICA+IHBhcmFncmFwaCwg aG93ZXZlci4pDQogICAgPg0KICAgID4NCiAgICA+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3 dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCiAgICA+IGZv ciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlv bnMuDQogICAgPg0KICAgID4NCiAgICA+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBi YWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCiAgICA+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNh dGlvbnMvDQogICAgPg0KICAgID4NCiAgICA+DQogICAgPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiBD T01NRU5UOg0KICAgID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgID4NCiAgICA+IEkgYXBwcmVjaWF0ZSB0 aGUgZ29hbCBvZiB0aGlzIGRvY3VtZW50IHRvIHNwZWNpZnkgYW5vdGhlciB0ZWxlbWV0cnkgc3Ry ZWFtaW5nDQogICAgPiB0aGFuIGdSUEMuDQogICAgDQogICAgQWN0dWFsbHkgdGhpcyB3b3JrIHBy ZS1kYXRlcyBnUlBDIGJhc2VkIFRlbGVtZXRyeS4gIEJ1dCBpdCB0b29rIHRoZSBkb2N1bWVudHMg dGltZSB0byBnZXQgdG8gdGhlIElFU0cuIDotKQ0KICAgIA0KICAgID4gQXMgdGhlIEktRCBoYXMg YmVlbiByZXZpZXdlZCBieSBZQU5HLWRvY3RvcnMsIEkgZGlkIG5vdCBsb29rIGluIHRoZQ0KICAg ID4gWUFORyBtb2R1bGUuDQogICAgPg0KICAgID4gQ29tbWVudHMNCiAgICA+IC0tLS0tLS0tDQog ICAgPg0KICAgID4gQzEpIHNlY3Rpb24gMS4zLCBzaG91bGQgdGhlIHB1Ymxpc2hlZCBjaGVjayBh dXRob3JpemF0aW9uIGJlZm9yZSBhY2NlcHRpbmcgYW4NCiAgICA+IHN1YnNjcmlwdGlvbj8gVGhl cmUgaXMgc29tZSB0ZXh0IGluIHNlY3Rpb24gMy4xIGlzIGFib3V0IGF1dGhvcml6YXRpb24gYnV0 IEkgd291bGQNCiAgICA+IHByZWZlciB0byBoYXZlIHRoaXMgYXV0aG9yaXphdGlvbiBzdGF0ZWQg YXMgZWFybHkgYXMgcG9zc2libGUNCiAgICANCiAgICBBcyB5b3UgZm91bmQgbGF0ZXIgaW4gdGhl IGRvY3VtZW50LCB0aGUgcHVibGlzaGVyIGRvZXMgYXV0aG9yaXphdGlvbi4gIEluIG9sZGVyIHZl cnNpb25zIG9mIHRoaXMgZG9jdW1lbnQgd2UgZGlkIGhhdmUgc29tZSBvZiB0aGUgYXV0aG9yaXph dGlvbiBpdGVtcyB1cCBmcm9udCBpbiB0aGUgaW50cm8uICBCdXQgZm91bmQgaXQgc2xvd2VkIGRv d24gdGhlIGludHJvIG9mIHdoYXQgd2FzIGFscmVhZHkgYSBsb25nIGRvY3VtZW50LiAgU28gd2Ug a2VwdCB0aGUgaW50cm8gYXMgc2hvcnRlciBieSBwdXNoaW5nIHRoYXQgbGF0ZXIgaW4gdGhlIGRv Yy4NCiAgICANCiAgICA+IEMyKSBlbmQgb2Ygc2VjdGlvbiAxLjMsICJ0cmFuc3BvcnQgZHJhZnRz IiBzaG91bGRuJ3QgcmF0aGVyIGJlICJ0cmFuc3BvcnQNCiAgICA+IHNwZWNpZmljYXRpb25zIiA/ DQogICAgDQogICAgV29ya3MgZm9yIG1lLiAgQ2hhbmdlIG1hZGUuDQogICAgDQogICAgPiBDMykg ZW5kIG9mIHNlY3Rpb24gMS4zLCB1cG9uIHRlcm1pbmF0aW9uIGRlY2lkZWQgYnkgdGhlIHB1Ymxp c2hlciwgaXMgdGhlcmUgYQ0KICAgID4gbmVlZCBmb3IgYW55IGV4cGxhbmF0aW9uIG1lc3NhZ2Ug c2VudCB0byB0aGUgc3Vic2NyaWJlcj8NCiAgICANCiAgICBZZXMsIHRoZSBkZXRhaWxzIG9uIHRo aXMgYXJlIGxhaWQgb3V0IGFzIHBhcnQgb2YgdGhlIHN0YXRlIG1hY2hpbmVzIGluIFNlY3Rpb24g Mi40LjEgYW5kIDIuNS4xLg0KICAgIA0KICAgID4gQzQpIGlzIHRoZXJlIGFueSByZWFzb24gd2h5 IHRoZSBZQU5HIG1vZHVsZSB2YWxpZGF0aW9uIGJ1dCB0aGUgZGF0YXRyYWNrZXINCiAgICA+IGZh aWxzPyBPdXRkYXRlZC9pbnZhbGlkIFBZQU5HID8NCiAgICANCiAgICBFeGFjdGx5LCB0aGUgWUFO RyB2YWxpZGF0b3IgZXJyb3JzIGFyZSBkdWUgdG8gYSBzb2x2ZWQgYnVnIGluIHlhbmdsaW50LiAg ICBBcyBLZW50IGRpc2N1c3NlcyBpbiBoaXMgc2hlcGhlcmQgd3JpdGV1cCwgdGhlIGVycm9ycyBj bGVhciB3aXRoIG5ldyB2ZXJzaW9ucyBvZiB5YW5nbGludC4NCiAgICAgICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZp Y2F0aW9ucy9zaGVwaGVyZHdyaXRldXAvDQogICAgDQogICAgICAgICAgIFtTSEVQSEVSRF0gYHB5 YW5nYCBhbmQgYHlhbmdsaW50YCB3ZXJlIHVzZWQgdG8gdmFsaWRhdGUgdGhlIFlBTkcgbW9kdWxl DQogICAgICAgICAgIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4gIE5vdGUgdGhhdCBEYXRhdHJh Y2tlciBzaG93cyBZQU5HIHZhbGlkYXRpb24NCiAgICAgICAgICAgZXJyb3JzLCBidXQgdGhlIG1v ZHVsZSB2YWxpZGF0ZXMgZmluZSBvbiBteSBtYWNoaW5lIChJJ20gdXNpbmcgeWFuZ2xpbnQNCiAg ICAgICAgICAgMC4xNi4xMTAsIHdoZXJlYXMgRGF0YVRyYWNrZXIgaXMgdXNpbmcgeWFuZ2xpbnQg MC4xNC44MCkuDQogICAgDQogICAgRllJIHRoZSBidWcgd2FzIGZpeGVkIGluIHlhbmdsaW50IDAu MTYuNTkNCiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL3Rvb2xzL2lldGZkYi90aWNrZXQvMjY2 Nw0KICAgIA0KICAgID4gQzUpIHNlY3Rpb24gMi4yICJhbGwgZXZlbnQgcmVjb3JkcyBvbiBhbiBl dmVudCBzdHJlYW0gYXJlIHRvIGJlIHNlbnQiLCBzaG91bGQNCiAgICA+IHRoZXJlIGJlIGEgbWVu dGlvbiBvZiBwdWJsaXNoZXIgYmVpbmcgb3V0IG9mIHJlc3NvdXJjZSA/DQogICAgDQogICAgWWVz LCB0aGVyZSBhcmUgc2V2ZXJhbCAib3V0IG9mIHJlc291cmNlIiBlcnJvcnMgZGlzY3Vzc2VkIGFj cm9zcyBTZWN0aW9uIDIuNCwgMi41LCBhbmQgaW4gdGhlIFlBTkcgbW9kZWwuICBZb3UgZG8gbm90 ZSBzb21lIG9mIHRob3NlIGJlbG93LiAgQWdhaW4gYnkgZGVsYXlpbmcgc29tZSBvZiB0aGUgZGlz Y3Vzc2lvbnMgdG8gbGF0ZXIgaW4gdGhlIGRvY3VtZW50IHRoZSBkaXNjdXNzaW9ucyBhcmUgbGVz cyBmcmFnbWVudGVkIGluIHBsYWNlcy4NCiAgICANCiAgICA+IEM2KSBzZWN0aW9uIDIuNC4xICJp bnN1ZmZpY2llbnQgQ1BVIG9yIGJhbmR3aWR0aCBhdmFpbGFibGUiIGJ1dCB0aGVyZSBtYXkgYmUN CiAgICA+IG90aGVyIHJlYXNvbnMgKGUuZy4gbWVtb3J5KSwgd2hhdCBhYm91dCB1c2luZyAiaW5z dWZmaWNpZW50IENQVSwgYmFuZHdpZHRoDQogICAgPiB1bmF2YWlsYWJsZSBvciBvdGhlciBsYWNr IG9mIHJlc3NvdXJjZSINCiAgICANCiAgICBXZSBoYXZlIGJlZW4gYXNzdW1pbmcgdGhhdCB0byBs aXR0bGUgbWVtb3J5IGlzIGEgZnVuY3Rpb24gb2Ygc3RyZWFtJ3MgZXZlbnQgYnVmZmVycyBiZWlu ZyBleGNlZWRlZCwgYW5kIHRoYXQgaXMgYSBmdW5jdGlvbiBvZiBDUFUgYmVpbmcgaW5zdWZmaWNp ZW50IHRvIGhhbmRsZSB0aGUgbG9hZCBmcm9tIHRoZSBzdHJlYW0uICBTbyBvbmUgZXJyb3Igc2Vl bXMgdG8gY292ZXIgdGhlIGNhc2Ugd2l0aG91dCBwdWJsaXNoZXIgZGV2ZWxvcGVycyBoYXZpbmcg dG8gbWFrZSBhIGp1ZGdlbWVudCBjYWxsIG9uIHdoaWNoIG9mIHRoZXNlIHdhcyByZXNwb25zaWJs ZSBmb3IgdGhlIGxhY2sgb2YgcmVzb3VyY2VzLg0KICAgIA0KICAgID4gQzcpIGZvciBteSBjdXJp b3NpdHksIGluIHNlY3Rpb24gMi40LjIuMSwgaG93IGRlZXAgY291bGQgcmVhbGlzdGljYWxseSBi ZSBhIHJlcGxheQ0KICAgID4gYnVmZmVyPyBNaW51dGVzPw0KICAgIA0KICAgIEl0IGNvdWxkIGJl IGhvdXJzIGFuZCBkYXlzIGZvciBsb3cgdm9sdW1lIGV2ZW50cy4gICBGb3IgZXhhbXBsZSwgZm9y IHNlY3VyaXR5IGNhc2VzIHN1Y2ggYXMgdGhlIEludGVncml0eSBNYW5hZ2VtZW50IEFyY2hpdGVj dHVyZSAoSU1BKSwgeW91IG1pZ2h0IG5lZWQgIHRvIGtub3cgZXZlcnkgSU1BIHJlbGF0ZWQgZXZl bnQgc2luY2UgYm9vdC4NCiAgICANCiAgICA+IEM4KSB0aGUgdGVybSAndHJhbnNwb3J0JyBpcyB1 c2VkIHF1aXRlIG9mdGVuIGluIHRoZSBkb2N1bWVudCBidXQgaXQgc2VlbXMgdG8gcmVmZXINCiAg ICA+IHRvIE5FVENPTkYgYW5kIG5vdCBzbyBtdWNoIHRvIG15IHVuZGVyc3RhbmRpbmcgb2YgJ3Ry YW5zcG9ydCcgaW4gYW4gSUVURg0KICAgID4gZG9jdW1lbnQgKHdoaWNoIGlzIFRDUCwgVURQLCBT Q1RQLCAuLi4pLiBJcyBpdCBvYnZpb3VzIHRvIHRoZSByZWFkZXJzPyBJZiBzbywgdGhlbiBJDQog ICAgPiBkbyBub3QgbWluZC4gRWxzZSwgaXQgbWF5IGJlIHVzZWZ1bCB0byBjbGFyaWZ5IGluIHNl Y3Rpb24gMS4yDQogICAgDQogICAgSG9wZWZ1bGx5IGl0IGlzIG9idmlvdXMgdG8gdGhlIHJlYWRl cnMuICAgV2Ugd2VudCBiYWNrLWFuZC1mb3J0aCBhIGZldyB5ZWFycyBhZ28gb24gdGhlIHByb3Bl ciB0ZXJtaW5vbG9neSBoZXJlLiAgIEkgZmVhciB0b3VjaGluZyB0aGUgd29yZCBhcyB0b3VjaGlu ZyB0ZXJtaW5vbG9neSBtaWdodCBpbmR1Y2UgdW5mb3Jlc2VlYWJsZSBzaWRlLWVmZmVjdHMuDQog ICAgDQogICAgPiBOaXRzDQogICAgPiAtLS0tDQogICAgPg0KICAgID4gTjEpIGlzIHRoZXJlIGFu eSByZWFzb24gd2h5IG5vdCBhbGwgQ2lzY28gYXV0aG9ycyBhcmUgbm90IGdyb3VwZWQgdG9nZXRo ZXI/DQogICAgPiAoZXZlbiBpZiBhbm90aGVyIG9uZSBoYXMgY2hhbmdlZCBhZmZpbGlhdGlvbikN CiAgICANCiAgICBObyByZWFsIHJlYXNvbi4gIEJhc2ljYWxseSB3ZSBoYWQgYW4gaW5pdGlhbCBv cmRlci4gIEFuZCB0aGVuIHNvbWUgYXV0aG9ycyBtb3ZlZCBjb21wYW5pZXMsIGJ1dCB3ZSBrZXB0 IHRoZSBvcmRlci4gIElmIHRoaXMgaXMgYW4gaXNzdWUgZm9yIHRoZSBJRVNHLCB3ZSBjYW4gcmVz ZXF1ZW5jZS4NCiAgICANCiAgICA+IE4yKSBhYnN0cmFjdCBzL2luZm9ybWF0aW9uL2RhdGEvIGFs c28gYXBwbGljYWJsZSBpbiBvdGhlciBzZWN0aW9ucyBJTUhPDQogICAgDQogICAgRWl0aGVyIHdv cmtzIGZvciBtZSBob25lc3RseS4gICBCdXQgc28gbWFueSBwZW9wbGUgaGFkIGFuIG9waW5pb24g b3ZlciB0aGUgeWVhcnMgb24gdGhpcywgYW5kIHdlIGhhdmUgdHdlYWtlZCB0aGlzIHNvIG1hbnkg dGltZXMsIHRoYXQgSSBhbSBhZnJhaWQgb2YgbWFraW5nIGEgY2hhbmdlIGhlcmUuDQogICAgDQog ICAgPiBOMykgc2VjdGlvbiAxLjMsIGV4cGFuZCBSUEMgZXZlbiBpZiBvYnZpb3VzDQogICAgDQog ICAgRG9uZQ0KICAgIA0KICAgID4gTjQpIHNlY3Rpb24gMi4zLCBleHBhbmQgUW9TIGV2ZW4gaWYg b2J2aW91cw0KICAgIA0KICAgIERvbmUuDQogICAgDQogICAgVGhhbmtzIGFnYWluIGZvciB0aGUg cmV2aWV3IQ0KICAgIA0KICAgIEVyaWMNCiAgICANCg0K